Forward APIs and What a Merchant Should Know
Forward APIs and In-N-Out Burger used to have a lot in common: Accessing a Forward API from a payment service provider (PSP) used to be like ordering off a secret menu—you had to know what to ask for, and how to ask for it.
Just as the secret menu became less secret, so did Forward APIs.
Forward APIs created a world where a merchant could execute a multi-payment processor strategy while contracting with a single PSP and relying solely on its connections. Those full-service PSPs started being more accepting of merchants' desire to operate with multiple processors, even though it is demonstrably not in the PSP's best interests to lose transaction volume.
So, PSPs provide customers with a Forward API that enables raw payment data, such as credit card information, to be sent to a third-party. This third-party can be another payment processor, fraud monitor, analytics platform, token vault, etc. The Forward API submits requests to a destination API on behalf of the merchant, and the request includes data stored within the PSP’s systems, and is never available in plain text to the merchant.
How does the PSP allow the merchant to access that securely stored data? The merchant uses a PSP-provided interface for initial payments, safely collecting the customer’s information, and storing it locally. Once the customer information is in place, a token is sent back to the merchant, which can be used in future transactions to instruct the PSP to send the original data to an approved third party. These tokens can be affiliated with a specific card network, payment method, or PSP.
However, PSPs are not always willing to forward this data unless incentivized. The user experience can be limited for the merchant to control, and managing the flow of information can be extremely tricky. And, of course, the Forward API will only work with the PSP's existing connections.
Which PSPs offer a Forward API?
Several PSPs offer Forward APIs. These are some of the most common:
- Stripe Forward API allows for the collection of card details using Stripe Payment Elements.
- Braintree is the OG of Forward APIs. This is particularly useful with external fraud services and loyalty programs.
- Dots designed its Forward API for payouts across various payment methods. Primarily used in B2B payments.
When a merchant uses a Forward API, the PSP powering the transactions gains visibility into the business operations of their merchant customer, seeing where they send transactions, and the volumes involved. A merchant’s negotiating power is lost because the PSP can see how much volume is sent to other PSPs.
Merchant Concerns When Using a Forward API
A single PSP, regardless of whether or not the merchant is utilizing a Forward API, creates the risk of a single point of failure. There is no failover from a primary to a secondary provider because a merchant's whole network of services is accessed through its full-service PSP. This is critical for merchants to understand because reliance on a single system means when that system is not functional, the merchant’s ability to conduct business is dead in the water.
Other concerns a merchant can have when using a Forward API:
- Scalability: Can the Forward API handle spikes in transaction volume? Does the API connect with the PSPs favored by the merchant’s customers?
- Compliance Risk: Is the Forward API PCI DSS compliant? During an outage, will it fall out of compliance? This could lead to potential financial penalties for the merchant.
- Lack of Flexibility to Route Payments: The Forward API is often tied to a very limited array of downstream PSPs or gateways, meaning that if a merchant customer wants to use a bank not supported by the PSP and its Forward API, that customer cannot transact.
Cost-wise, expect to be charged a flat fee to store a credit card, and then a separate charge each time that card data is forwarded out of the vault.
From a technical perspective, adding a Forward API to a merchant’s payment systems can introduce some unexpected challenges. For instance, when submitting a payment through a Forward API, there is a two-step process to understanding whether the transaction was successful:
- The Forward API returns a success/fail code. However, this only tells the merchant system whether the request was successful. In other words, a ‘200’ success code only tells the merchant that the API call was completed.
- The Forward API returns the success/fail code of the actual transaction as part of the response details. Having noted that the call was successful, the merchant system must now parse the (likely JSON-based) payload of the response to find out whether the downstream service provider successfully executed the requested action.
Meanwhile, the merchant must prepare for unsuccessful processing attempts: how will the system manage soft declines, non-matching addresses, or even subsequent charges related to subscription agreements? By being at arm’s length, separated from the ultimate service provider by an independent PSP’s Forward API, creates very real coding logic challenges.
Forward API Use Cases
These are some examples of Forward APIs being used:
Churn Reduction for Subscription Companies
Paying for a subscription at the point of sale can go through the primary PSP. However, when it's time for renewal, the primary PSP may experience an increase in failed transactions due to outdated credit card information with the subscription payment. With a Forward API, the primary PSP can forward the payment details to a backup PSP or use an alternative payment method to renew the subscription and approve the transaction potentially.
Loyalty Programs
External loyalty platforms can be receivers, enabling automatic discounts or rewards based on transaction data.
Advanced Fraud Detections
A Forward API can send payment data to third-party fraud detection systems to analyze transaction patterns or risk signals. This can help reduce chargebacks and reduce the likelihood of failed transactions. That said, the third-party service would need to be superior to that offered by the primary PSP and deliver meaningful improvements to justify the additional time and cost investment.
A feature such as Account Updater becomes extremely valuable in this use case.
Independent Payment Vaulting
What we believe is a better experience for both the merchant and the customers does not involve a Forward API, but a payment token vault. Agnostic payment vaults like Basis Theory work with Forward APIs, too, but can also unlock more flexibility for a merchant, compared to the limited lifestyle that comes with a Forward API. By decoupling the larger group of PSP partners from a primary full-service PSP provider, merchants can:
- Build Robust Systems: Payment systems built using a programmable payments vault by design assume an API call for all transactions. So, when one PSP is down, the system can seamlessly switch to an alternative. In the unlikely event that the vault is unavailable, the system can switch to a full-service PSP. The single-point-of-failure threat is eliminated by design.
- Merchants can partner with virtually any provider they like, so long as the partner has an accessible API. Because the programmable payments vault is PSP-agnostic, merchants are not limited in their scope.
- Ensure full PCI-DSS compatibility for their end-to-end payments infrastructure while keeping their internal systems out of scope.
While it’s true that merchants can consider themselves “multi-processors” by using a Forward API, they should prepare for a limited world bound by the agreements independently made by the primary PSP.
Working with a programmable payments vault delivers substantially higher value than using a Forward API, in terms of flexibility, availability, and overall cost.
Consider your options for becoming a multi-payment gateway merchant, and before making any decisions, explore payment orchestration 2.0.
