Why a multi-PSP approach should happen on the back end
Today’s merchants know they are on a white-knuckle ride to squeeze as much cost and risk out of their business as possible in the face of tight margins. Most are now looking at optimal ways to automate their payment processes to maximize their successfully closed deals—while keeping their processing costs as low as possible.
Generally, this requires the merchant to have relationships with multiple payment processors and to choose which to use for each transaction according to a set of business rules. Integrating multiple processors, however, can be done in several ways, some of which have longer, deeper benefits than others.
Why switch between processors?
As merchants have learned over the last few years, relying upon a single full-service processor, while quicker to implement and often easier to maintain, creates significant risk. That processor acts not only as a single point of failure but also:
- Offers a single, flat-rate processing fee schedule, eliminating the opportunity for the merchant to take advantage of lower fees in different geographies or payment methods.
- May operate in only a subset of the countries where the merchant needs to transact business, lowering the potential close rate for deals that would be better processed in-country.
- Likely retains the actual records of the merchant’s customer’s cardholder data, making it difficult for the merchant to switch providers, and virtually impossible for them to use that data to submit transactions to other processors alongside their primary PSP.
By maintaining a stable of payment service provider (PSP) partners, a merchant can, therefore, increase their successful transaction close rate, decrease the cost of processing, and reclaim control of their customers’ stored payment data.
What is front-end and back-end processor switching?
When a customer interacts with a merchant that has a processor switching process in operation, that switching can happen either two points:
- Front-end processor switching means that based on some value (often the user’s IP address), logic on the payment page decides which provider’s third-party form will be displayed to capture payment information.
- Back-end processor switching means that based on the logic operating within the systems the merchant employs within their internal infrastructure, the cardholder’s information—however collected—will be submitted to a preferred provider. This can be known as orchestrating or routing.
While, in each case, the customer has their transaction delivered to a selected processor, the difference in logic, sophistication, and benefits is substantial.
Front-End Switching
Front-end switching can seem like a simple solution: simply build into your payment page logic a function that determines something about the buyer (generally their location via IP address), then selects which PSP’s form to write to the page. And indeed, of course, whichever form is selected has all the normal benefits provided by the PSP.
For example, if the customer has already purchased through that provider, their details may be available for easy re-use. However, there are some real challenges here, including:
- The switching process, almost by necessity, is likely to be very coarse-grained and based entirely on customer data. While one can go way beyond the simple IP address and store items in cookies with the customer, because the switch occurs at the browser or app level, one cannot apply non-customer-based logic. This eliminates the option to, for instance, route transactions to a particular PSP to fulfill volume guarantees (or away from it once those guarantees have been met).
- Although each selected PSP form may provide access to stored customer cardholder data for repeat buyers, there is no cross-pollination. As a result, if the front-end switch relies upon, say, IP address, and a repeat customer happens to be outside their normal geography, they may be asked to re-enter their payment data, as their record is not available to the local PSP.
- Subscription payments are locked to the original PSP, as it is that provider that holds the approval and necessary transactional information.
- Perhaps worst of all, switching providers in the front end only solves one problem: offering the PSP that makes sense, almost certainly based on geography, for a single shot at a transaction.
If the transaction fails, it fails—there’s no way to take the customer’s information and, assuming a weak soft decline, re-submit it through an alternative provider.
Back-End Switching
Back-end switching can seem like a hassle. And certainly, if one were to try to collect a range of information, analyze it, then dynamically select one form or another to send back to the user interface, it really could be.
Just keeping the styling and layout consistent could become complex as the number of potential PSP partners grew.
However, most merchants who commit to back-end switching do it through a third-party programmable vault, which cuts through a lot of the complexity: essentially, the same user interface appears, regardless of the selected payment provider, and details are embedded to let the vault know which PSP to send the transaction to.
The benefits are significant:
- The merchant has direct access to the stored cardholder data, accessed with a token, and can submit it to substantially any PSP they choose, without having to push different forms to the page.
- There is no functional limit to how many payment partners can be involved! A back-end switching system can simply have a range of options, with a decisioning engine that selects based on geography, alignment with the product MCC, size of deal, payment type, or anything else. This has a profound impact on both conversion rates and overall processing fees.
- Failed transactions can be tried again in cases where there is a soft decline that suggests a reasonable chance of success. This increases conversion rates, improves margins, and provides a more satisfying experience to customers.
- The merchant can also set up a fallback option, in which they simply call up a full-service (or other) PSP form in the event that there are any communications issues with the programmable token vault.
- Reputable programmable token vault providers maintain a commitment to releasing stored PAN and PII should the merchant opt for a different vaulting service.
The ROI is Undeniable
Using back-end switching, powered by a programmable token vault, improves conversion rates, delivers superior customer experiences, and allows for fully optimizing processing costs.
Meanwhile, the vault takes on the responsibility for protecting and securing customer data, both at rest and in motion, and keeping the merchant’s payment system out of PCI-DSS scope, which translates to meaningful reductions in administrative overhead and costs.
As merchants explore ways to optimize their payment processes, consider embracing mobile payments and using multiple PSPs. Our blog shares more ideas on payment optimization.
