As companies look for ways to make operations more efficient, many are developing custom payment integrations to save time on their transactions. Instead of changing their business processes to work with a third-party credit card gateway, they’re doing the exact opposite: building a payment module into their existing software. This lets them keep their established technologies and workflows.
A custom payment integration may seem like a more time-intensive process. It certainly can be; at least, up front. There’s plenty of discovery, development, and testing to be done. Realistically, it can take several months to a year, depending on the complexity. However, once the new system is up and running, companies can spend much less time on the day-to-day aspects of payment processing.
- Sales reps and customer service teams can process credit and debit card payments in the applications they already use. They don’t have to waste time moving from system to system or manually re-entering the details.
- Customers can store a card on file for future purchases. There’s no need to re-enter the same card details every time a transaction is processed. Every single sale is faster to process – as are adjustments and refunds.
- Finance and accounting teams can automate their daily settlement process. This means less repetitive work and more timely deposits.
So: what does it take to make these benefits a reality? The Curbstone team takes us behind the scenes of a custom payment integration.
When do companies usually decide that it’s time to integrate their payments? Do you tend to see a common “tipping point” where standard payment processing is no longer working?
Russell Gilmer, Sales Manager: “Every company has a different motivation for integrating credit card payments, but it comes down to fractured and disjointed systems. Merchants want their transactions to be part of a smooth flow.
Pre-integration, they may be lacking the ability to trigger an EMV transaction from their IBM i order entry screen. They may be spending too much time on manual reconciliation, where someone has to go through the records and hand-match credit card receipts to the corresponding transactions. Or, they may have a website that’s running on another platform while their IBM i runs their inventory management system; when a customer pays via PayPal on their website, their inventory system doesn’t know to update items or quantities. An online payment integration becomes a matter of tying all those pieces together when the legacy approach is no longer sustainable.”
What’s the typical process for a payment integration?
Gilmer: “It sounds cliché, but it all depends on what the merchant is trying to do. That’s the whole point of the integration – to build something specific to the customer’s unique business process.”
However, a basic roadmap – after a customer has chosen Curbstone as their payment integrator and decided on the specific technologies they’ll be using – usually looks something like this:
- Install Curbstone’s payment software
- Apply the temporary license key
- Install the test configuration file
- Work with their bank, acquirer, and network
- Purchase and set up EMV terminals and/or IPT devices, if applicable
- Obtain tear sheets from their acquirer
- Review the base programs for their interface
- Complete the programming and network testing
- Obtain the permanent license key
- Install and test the live configuration
- Train employees
- Go live with integrated payments
Vito Mangiaracina, Curbstone’s Project Manager, explains further: “The process starts with a kick-off call. At this point, we’ve already explained Curbstone’s payment processing technologies to the customer – now it’s a matter of figuring out how to implement them.
Our goal throughout the entire process is to work credit and debit card payments into the customer’s existing transaction workflows. We want to make it as simple as possible – like it’s a natural extension of their existing process. Because Curbstone is a payment processing engine – not a typical gateway – it’s flexible enough to support a wide range of use cases. Our kick-off call sets the plan to execute whatever the customer is looking to achieve.
During this phase, we’re happy to share the best practices we’ve identified after 20+ years in the payment industry – but it’s always a customer-led process. They set the requirements for their credit card integration and we support them however we can.”
Gilmer: “One thing we explain on almost every kick-off call: we’re not to here to tell you how to run your business. You know how your transactions occur and what you want to do to make them more efficient; we’re just here to make it happen.”
What’s involved as far as programming?
Mangiaracina: “Our customers do the actual programming. The most common question we get in that regard is ‘how do we make this piece of the Curbstone software fit into this flow that we’ve currently defined?’
Most of the time, we have tons of documentation on hand to provide a clear answer. That’s true of everything from setting up EMV terminals to configuring IPT devices. We have detailed guides to make the process as straightforward as possible. If there’s ever a case where the answer can’t be found in the documentation, we’re here to go over the steps one-on-one.
Sometimes there are more technical issues, such as ‘I’m trying to install this license key and I’m getting an error’, or ‘we’ve started the software, but we’re not getting responses from the portal’. There too, we can walk merchants through the specific details.
Alan O’Guin, Product Manager, also notes the importance of Curbstone’s example programs and testing resources.
“We have a test environment – a sandbox – where customers can send transactions to test. We also have testing utilities, which are ways that a merchant can simulate running the different types of transactions that they’ll have to program to. For instance: if they’re planning to modify their software to send an EMV transaction, they can use our C3 test EMV utility to send a sample transaction and see the result.”
What goes on behind the scenes of a payment integration?
O’Guin: “Integrations are very much a hands-on, back and forth process.”
Gilmer: “Exactly. Our merchants are comfortable with their processes and their flows. They’ve built what they need to support their business. What we then do is add our payment technologies to that process without impacting the existing flow.”
Mangiaracina: “We also provide as much of the source code and example programming – for instance, a set of APIs. All the merchant has to do is select the parameters that they send when they call that API. Of course, we walk them through that process and help them decide what they need to send. From there, the Curbstone software will do whatever it is that they have instructed it to do.”
Gilmer: “The biggest benefit here is – as Vito is saying with the API calls – our merchants aren’t trying to take something that isn’t designed with the AS/400 in mind – like PayPal – and figure out how to make it play nice with their 400. [That process] is extremely complicated, but with the Curbstone solutions that are designed exclusively for the iSeries – users are already familiar with what the terminology means and how to do it.”
O’Guin: “Exactly. They don’t have to make as many modifications, and the modifications they do need to make…they’re already comfortable making.
In most cases, those modifications are minimal. With Curbstone, merchants typically only have to add a few lines of code to their RPG program. Because the system only uses one request/response data structure – abstracting all of the network differences for a single, consistent merchant interface – it’s easy to adopt.”
Working with other third parties
Many times, the effort involves third parties. Curbstone helps coordinate all of the efforts.
Mangiaracina: “When it comes to the e-commerce piece, for instance: a lot of our customers use outside web application companies to manage their websites. We’ll work with the third-party vendor to help them understand what needs to be done to integrate credit card processing into their online checkout. This eliminates some of the extra work on the merchant’s part.”
How can a business future-proof their credit card integration? It’s important to make sure that the technologies they invest in now are part of their long-term picture.
Gilmer: “Thinking about future needs is the core of what we do.
We had one client who was using both an IBM i-based order entry program and a Salesforce-based order entry process, but they wanted to start taking payments over the phone using a voice scope elimination tool. As we started working with them on their integration, we discovered that they eventually wanted to process automatic payments online as well. We helped them map out their future needs so they could make sure they’re setting themselves up for a successful future.
Another part of being in the payments industry is keeping up with industry changes and PCI requirements. We monitor and adjust for these updates on our end so our customers don’t have to.”
O’Guin: “A great example of that was the recent mandate to change our connection from SSL to TLS. We made the changes on our end, then put out an update. The merchants installed the update and everything just worked.
Another example was when the card brands started introducing returns so that credits were no longer an offline process. Same thing; we changed our software and released the update. Those changes were invisible to our customers, but the payment programs ran differently on the back end. They didn’t have to worry about the technical aspects.”
Phased implementation
Often, developing a future-minded solution necessitates a phased approach.
Mangiaracina: “Customers usually come to us with a plan in mind. Some want to go live with everything all at once, but many want to do a phased approach.
In these cases, we’ll often have the merchant start off with IPT for their phone orders and/or PLP for their e-commerce transactions. From there, we’ll move on to EMV. With EMV, they have to purchase and configure the physical terminals, so it can be more involved.
Whichever way they want to do it – we’ll move at their pace.”
End to end, how long does the integration process usually take?
O’Guin: “That’s a wide range. Some customers have gone live in a matter of weeks. That takes an immense commitment, though. The more typical time frame is a few months.”
Mangiaracina: “Lots of things can influence the time frame. One of the most impactful is staffing, and having their programming resources available to start right away. If their programmers have other things on their plate, it can take longer.”
And for merchants that don’t have an RPG programmer on staff – or who need to supplement their existing team’s availability?
Mangiaracina: “When a business needs help programming their payment integration, we have several resources to recommend. That can even speed up the process further; programmers who have worked with Curbstone multiple times are already familiar with it and can get it done more quickly.”
Preparedness also comes into play.
O’Guin: “Sometimes we see the process be extended due to administrative items, like negotiating merchant agreements and getting credentials. That can cause a bottleneck, but we’re ready to move as soon as we can put a configuration in place.”
Gilmer: “We’re here and ready to work as fast as our customers are.”
Related Content: The Top 5 Things to Look For When Choosing an Integrated Payments Solution
Learn More About a Custom Payment Integration for Your IBM i-Based Applications
At Curbstone, we’ve spent more than 20 years in the payments industry, working exclusively with companies that run the IBM i operating system.
Our team has developed custom payment integrations for some of the leading commercial ERP packages – from Iptor to InTempo – as well as custom-built RPG applications. Learn more about integrated payment processing for applications on the IBM i Series (AS/400), or let us know which system you use and we’ll help you add seamless, real-time payments.
