Provider Lock-in

In the context of payments, vendor lock-in can occur when a merchant becomes highly dependent on a particular payments service provider or acquirer. While switching to an alternative provider may be appealing, the cost of integration and migration to a new provider can be prohibitive.

Certain capabilities, such as card-on-file payments may be tied to a particular vendor due to tokenized payment instruments being stored in that vendor’s proprietary vault. Switching vendors in this case requires transferring the tokenized payment details to the new provider, or getting existing customer’s to re-enter their previously stored payment information, and increase churn as a result. The latter route is the only option in cases where the payment provider has gone out of business and the merchant is unable to migrate the tokens.

Being reliant on a single vendor introduces various risks. First and foremost, if that vendor goes out of business, the merchant’s business can also be put at risk. The Wirecard scandal illustrates the risk of relying on a single payments provider. Providers may also be acquired by a new owner with a different business strategy, resulting in contract termination and the need to find a new provider at short notice.

Being locked in to a specific vendor means that a merchant is unable to profit from the advantages of another provider. While another vendor may offer more attractive conditions or offer local acquiring services in a specific region with higher authorization rates, the merchant is beholden to their current provider in order to continue servicing legacy customers, e.g. for card on file transactions. While tokens can be migrated between providers, this process takes time and requires cooperation from both the merchant’s old and new providers.

Furthermore, cascading a failed transaction by routing it to a different provider is not possible if payment methods are reliant on a particular provider as a result of tokenization. This can have negative impacts on a merchant’s bottom line, as transactions that receive a soft decline from the provider cannot be recovered by trying an alternative provider.

Merchants can avoid being locked in to a single payments provider by integrating several payment providers that handle the same payment methods, and using tokens that can be used with any provider. Payment orchestration provides a solution here. Tokenization is performed by the payment orchestration platform itself, and the payment instruments are stored in the platform, rather than at individual PSPs.

This allows the same tokenized payment instrument (e.g. a credit card or digital wallet) to be used for transactions processed via any payments provider that is integrated with the payment orchestration platform.

This has additional advantages. If one provider is temporarily unavailable or goes out of business, the merchant can continue processing transactions via another provider without any interruptions; to the consumer, it is just business as usual. Furthermore, because all payment providers are integrated using the payment orchestration platform’s API, switching providers or adding new payment options with a new vendor requires no additional development. The API has already been integrated and new payment providers can be brought online within minutes, provided a contract has been signed with the provider.

IXOPAY offers its own tokenization and vaulting services, meaning that merchants can tokenize and store their customers’ payment details in IXOPAY. With hundreds of vendors connected to IXOPAY via a single API, merchants can easily add new providers, switch to a provider with more attractive conditions at short notice and retain full control over their payments setup. This can also prove an advantage in negotiations with vendors, as the cost of switching to a new provider is much lower than in cases where doing so would be disruptive to the merchant’s business. This shifts the balance of power from the vendor to the merchant.

Furthermore, using a payment orchestration platform like IXOPAY makes it easy to implement cascading and fallback options. If a transaction is declined by one vendor, the merchant can retry the transaction with another vendor. This can result in the recovery of a significant number of transactions that would otherwise be lost. This approach is not possible if the payment instrument is tokenized at the vendor itself.

IXOPAY is completely provider-agnostic. All transactions, irrespective of the vendor, are treated as equal by IXOPAY. With no incentive to route transactions to a particular vendor and tokenization of payment instruments handled by the platform itself, merchants are free to choose which payment providers they wish to handle an individual transaction.

IXOPAY can help migrate your existing tokens into IXOPAY. Processes are also in place to allow merchants to export tokens from IXOPAY to ensure they are not locked in to the IXOPAY platform.