Pitfalls of a Forward API
A payments forward API sounds like the answer. Route to any processor, reduce PCI-DSS scope, and rarely miss a transaction.
And it can be, if a merchant plans for the scenarios that occur after the integration. To ensure successful transactions, with the lowest possible processing fees, and the smallest PCI scope, a forward API combined with tokenization and a programmable payments vault may offer the sweet spot.
But that doesn’t mean the strategy is without challenges.
What is a payments forward API?
A payments forward API is a specialized service that allows a merchant to request processing of a transaction to virtually any endpoint, without bringing the customer information into their systems in plain text. The benefits are clear:
- Work with as many payment service providers (PSPs) and/or gateways as the merchant prefers and not be limited to a single, full-service PSP. This flexibility is desirable in an ecommerce market that is increasingly leaning toward a multi-provider environment.
- Having contracted with multiple PSPs, the merchant can forward each transaction to the provider most likely to deliver a successful outcome, whether that be due to offering the right payment methods, being located in the same geography as the customer, or offering specialized services (say for high-risk items)
- Rather than relying on the flat fee schedule of a full-service PSP, the merchant can use sophisticated routing to deliver each transaction to the provider that will charge the least. This protects margins and improves unit economics.
- When the forward API is offered in conjunction with a programmable payments vault, the merchant can avoid bringing personally identifiable information (PII) into their systems, reducing the cost and resource demands of maintaining full PCI compliance.
Are there different kinds of payment forward APIs?
Not every payments forward API operates the same way, and the differences matter.
Although a payments forward API delivers the most value when combined with an independent vault—which empowers the merchant to build a stable of trusted PSP partners—that is not to say that a full-service PSP won’t offer their own. In other words, a merchant can concentrate all their transactions with a single PSP, then use that partner’s services to ensure that all PII is collected and stored outside their own system, keeping PCI scope limited.
A payments forward API offered by an individual PSP, though, has one key challenge: it is owned and operated by a downstream partner that has a vested interest in keeping the merchant’s business in one place. The PSP actually makes its money not by providing a forward API, but by transacting the deals for the merchant, and as such is disincentivized from making it easy to expand into a multi-processor setup.
Pitfalls of a Forward API
The benefits of a forward API does not mean merchants should not be wary of challenges that this approach can create. Many, if not most, are associated with planning rather than operations.
As the old saying goes, failing to plan is planning to fail.
Failing to plan for multiple payment endpoints.
The primary purpose of payments forward APIs is to create flexibility, allowing a neutral third party to collect and secure payment details, and to provide a safe way to transmit those details to a payments endpoint (PSP or gateway) for transactions. As a result, it is important to plan ahead for a multi-processor payments system, identifying the service providers who can be connected to create a situation where the merchant can improve their outcomes.
This might include finding PSPs that offer alternative payment methods, conduct business in geographies where the merchant’s customers live, and offering services for high-risk offerings. Merchants should also plan to review their PSP partners regularly, ensuring that they are contracting with providers who can deliver the best outcomes as time passes.
Not having a strategy for compliance.
Although a programmable payments vault that offers a payments forward API can definitely limit the PCI-DSS scope of a merchant’s payments system, it does not, by any means, eliminate the need to maintain a secure environment.
Indeed, every merchant should be prepared to perform the annual PCI process for all the elements of their payments system that are in scope. This may include audit trails for support staff, physical security of systems that can impact customer data, and more. A solid, workable plan from the start prevents challenges down the line.
Plan for the Scenarios Before They Find You
This is a more complicated proposition than simply embedding a PSP’s integrations into a payment page, which is why those PSPs are able to charge a premium for their services. However, with planning and care, a decisioning engine, potentially enhanced by AI, can:
- Ensure all transactions are sent to the PSP with the highest potential for successful processing.
- Deliver all transactions to the lowest-cost provider.
- Add extra security steps to protect merchants and customers alike.
- Provide additional revenue streams by, for instance, managing currency conversion.
With a well-designed multi-processor payments system, anchored by an independent vault, merchants can massively improve their transaction throughput, reduce their compliance costs, and drive meaningful changes to their unit economics.
Like all great strategies, the key determinant of success is planning. The key is knowing your compliance obligations, choosing partners that deliver real flexibility, and building architecture that can route intelligently at scale.
Ready to go deeper? Read how an independent, programmable payments vault gives merchants full control over their payments stack.