Unlocking Flexible Payment Routing While Keeping Your Current Vault

This article explores all the avenues of card storage or vaulting that a business can choose from as part of payment processing, and talks about the natural progression in the storage choice that we have observed as businesses mature. It then delves into the value unlock that happens when a business chooses to have its own orchestration layer with an independent vault and processing across multiple PSPs.

Vaulting or storing a card can happen at 3 different layers: PSP, independent vault or orchestration layer.

Storing the card with the PSP is the most obvious and easiest choice when you are on a single PSP or are starting off with one. The PSP stores the card and gives back a token, and the business continues processing the transactions using the token. This approach is great but starts having issues once you introduce more PSPs. Now the business ends up with PSP-specific tokens each tied to the underlying PSP that is storing the raw card associated with it. This now gives rise to a few challenges:
 

• Payment routing using payment method attributes like issuer, bin, network, card type, card program, and more is not possible 

• Payment retries for user-present transactions cannot be done silently in the background without involving the end-user

• Payment retries for failed subscriptions cannot be run across PSPs

• Dependence on PSP capabilities for network features like tokenisation, Account Updater, and more 

• Inability to truly run A/B experiments across PSPs 

• Integrating more PSPs or payment methods because of global expansion or business needs continues to be a real bottleneck 

Introducing an independent third-party vault

To solve the above challenges businesses introduce an independent vault, usually a third-party SaaS vault. It functions as follows: the end-user enters their card in the third-party vault that will store the card and return a PCI-compliant token back to the merchant. The merchant then uses that token in the PSP payments request and sends it to the PSP via a forward-proxy endpoint of the vault. During this operation, the vault replaces the token with the raw card (while leaving the rest of the request untouched) and forwards it to the PSP. This setup solves the majority of the challenges above just by virtue of card collection and storage being done independent of the underlying PSP that processes it. 

However, the merchant still needs to invest their own engineering resources and effort into capturing all the value that an "independent vault” unlocked. This effort includes writing, enhancing and maintaining:

• Integrations to more PSPs or payment methods. This continues to be the biggest pain point for the merchant as it delays product go-lives or business expansion, as well as holds back the growth of business to something as basic as the ability to collect payments. 

• Payment routing logic based on transaction attributes, real-time PSP performance and cost 

• Error code unification across PSPs

• Payment retry logic

• Right depth of observability to run experimentation and more

Introducing an orchestration layer that works with independent third-party vault

To solve the above challenges businesses introduce a payment orchestration layer or platform. The majority of orchestration layers bring their own vault and require the business to migrate to their vault. A modular open-source orchestration layer like Hyperswitch understands this evolution and is able to function at the same level with its default vault or an independent third-party vault. It supports various configurations that are needed based on the business requirements and use-cases. The configurations are nothing but a simple set of questions:

1. Who powers the payment experience for cards, wallets and APMs? 

2. Which system stores the credentials?

3. Who forms the payload for each PSP?

4. Where does the PCI boundary sit?

Let’s start with the payment experience, whether it is powered by the orchestrator or the independent third-party vault:

One key aspect of the payment experience is about powering the cards in a PCI-compliant way. Beyond that, there is so much to the payment experience in terms of merchant customizations, ability to support key wallets like Apple Pay and Google Pay with the right implementation of load time, consuming their new features, collecting all the required info needed for the underlying PSPs (in case of dynamic payment routing or retry) and more. 

Let’s look at who handles the raw card (collection, storage or processing) and how that impacts PCI liability for the orchestrator or the independent third-party vault:

The reason Hyperswitch supports such a variety of configurations with independent third-party vaults is to

1. Support self-hosting merchants who may or may not like to take on the PCI burden - As you can see from Table 2, the merchant is outside the PCI scope under all the possible configurations; however, the orchestrator is in the PCI scope for this engagement in some of the configurations. When a merchant is self-hosting Hyperswitch, it becomes their own system hosted within their infrastructure. In case they are looking to stay outside the scope of PCI then they would prefer to go with configurations 1.1 and 3 (in Table 2), where the orchestrator is also outside the scope of PCI.
     

2. Allow businesses with existing vault relationships to bring their vault provider within the Hyperswitch orchestrator and continue running payments while leveraging all the rich PSP integrations and core payment features offered

What complexities decoupling vault introduces

Every configuration described above introduces more systems into the authorization path, and each of them has to perform. This brings in a set of complexities that the business now owns:

• More systems that need to talk to each other, and every hop between them adds latency. An API call between the orchestrator and the vault sits on the critical path for every stored-credential transaction

• Debugging and issue resolution spans the merchant's engine or the orchestration layer, the vault and the PSP, instead of sitting within a single system

• Ongoing enhancements, maintenance and support across each of these integrations

Additionally, depending on the configuration chosen by the business, there may be certain other limitations such as: merchant, customer and payment method segmentation and sharing or alternate credentials per payment method, to retry and uplift SR or managing multiple payment credentials per customer.

Decoupling the vault simply makes the orchestration decision and the PCI boundary revisable without touching the stored credentials.

In closing

Storing a card can happen at 3 different layers - PSP, independent vault or orchestration layer - and businesses tend to move through them in that order as they mature.

Storing with the PSP is the easiest starting point, and works well on a single PSP. It starts breaking down once more PSPs come in, with PSP-specific tokens blocking payment routing on payment method attributes, silent retries, cross-PSP subscription retries, network features like tokenisation and account updater, and A/B testing.

An independent third-party vault solves most of this by making card collection and storage independent of the PSP that processes the transaction. What it does not solve is the engineering effort that sits above it - PSP integrations, routing logic, error code unification, retry logic and observability.

An orchestration layer solves that gap, but most of them require the business to migrate to their own vault to do it.

A modular open-source orchestration platform like Hyperswitch supports a range of configurations precisely so that this migration is not necessary. The four questions - who powers the payment experience, which system stores the credentials, who forms the payload for each PSP, and where the PCI boundary sits - can each be answered independently, and a business with an existing vault relationship can bring that vault into the orchestrator and carry on.