How to Avoid Payment Infrastructure Lock-In

When you choose a payment processor, you make one of the most consequential infrastructure technology decisions for your fintech business. Unlike most software vendor lock-in problems, switching payment processors simultaneously impacts your live transaction processing, card certification bodies, and regulatory compliance.

For most fintech companies, this kind of problem is not something that is seriously considered until it comes up due to a dispute with your provider or some other circumstance that forces the question of whether or not you can actually switch providers.

What Is Payment Infrastructure Lock-In?

Payment infrastructure lock-in is distinct from typical software lock-in because it spans three separate layers of your payment infrastructure simultaneously, not just one.

Vendor lock-in within the payments industry generally occurs due to three different factors:

Where most software lock-in vendor problems are limited to the digital products that are being sold to the customer, with payment infrastructure lock-in, switching payment processors has an impact on three separate areas of your fintech business. You have to manage the process of moving your data to another provider, re-certifying with your cards, and ensuring compliance with PSD2 regulations.

Why Is Vendor Lock-In for Payments a Problem for Your Business?

As with most problems in the fintech space, vendor lock-in for payments creates exposure in three separate areas of your business.

Financial exposure due to the need to re-certify with your payment cards, such as Mastercard, Visa, and UnionPay, which can take months to complete. Additionally, you may be penalised for the process of migrating your payments to another provider, as well as the engineering effort to move your systems. These factors can make it financially difficult to exit your current vendor.

Growth limitations: Your growth could be limited by using a processor that does not support the individual card schemes you wish to support, such as those in Asia with UnionPay support. Alternatively, they may not offer tokenized support for systems like Apple Pay or Google Pay, limiting your development of digital wallets for users.

Compliance risk: There is a compliance risk with regulations like PSD2's requirement for Strong Customer Authentication (SCA). Your processor must support features like 3D Secure v2.2, out-of-band authentication, and biometric authentication. If your vendor does not support these features in a timely manner, then you have to deal with the implementation of those features into your systems. Additionally, because the migration process takes time, you can't simply switch to a vendor that supports all of the required SCA features when the regulation is implemented during your business's peak period.

Warning Signs of Vendor Lock-In

Several technical and contractual patterns signal vendor lock-in, indicating that a vendor has structured its offering in a way that makes it difficult to leave.

Proprietary Integration Protocols

One of the first warning signs of vendor lock-in for your payment processor is whether you have built your system with a proprietary protocol that the vendor uses, but that other processor companies do not use. Companies that utilise REST APIs or ISO 8583 message standards for payments can generally switch their integration to another vendor with ease. However, if your system utilises a proprietary protocol, you will have to build out the integration from the ground up if you should ever need to switch companies.

Another aspect of proprietary integration protocols is whether or not your vendor publishes documentation for their APIs. If they do not, and there is no publicly accessible documentation that anyone outside of your organisation can read and use for implementing some system change, then that is also a sign that they may be locking you into their vendor. Public documentation for APIs signals that they do not depend upon giving you information asymmetries to retain your business.

Data You Can't Easily Export

Your ability to retrieve your transaction history, tokenized data for each of your cards, and other reporting software data is a critical data export issue. If your data is stored within the vendor's systems and you have no easy way of retrieving that information, you may find yourself having to manually retrieve your transaction data from another vendor. This could require a fee or a transformation of that data to another format before it can be used in another application.

Another issue with your data is the tokenization of your cards. Proprietary tokenization vaults mean that your tokenized data for each cardholder cannot be used once you switch to another provider. However, tokens that are network-anchored to the card schemes, such as Mastercard MDES or Visa VTS, will move the cardholder with their card to the processing vendor. This is because the relationship between the token service provider and the card issuing company is separate from your vendor and the vendor with whom you are currently contracting.

Choose Vendor-Agnostic APIs and Open Standards

Open standards reduce the scope of switching from a full platform re-engineering to a scoped integration task.

Look for the use of standard protocols, specifically REST APIs and ISO 8583 switching protocols, as a means of connecting to each card processor. By choosing these types of standards over proprietary protocols, you will find that integrating a new type of card processor is a scoped task rather than a major platform integration task.

Ensure that there is public documentation for the APIs that are deployed by the processor. This will allow for full inspection and auditing of the system and a transfer of that integration to another party. Consider that the absence of this documentation is a sign that the vendor is not committed to providing an easy exit strategy for their customers.

Ensure that the vendor is certified with standards like PCI DSS Level 1, ISO 27001, ISO 9001, and holds accreditation from Mastercard, Visa, and UnionPay. These types of certifications require detailed and external audits of the vendor's systems, something that closed proprietary systems do not often undertake to gain such certifications.

Build a Multi-Provider Strategy

A multi-provider strategy is essential because relying on a single processor creates a concentration of risk across authorisation, certification, and geographic coverage.

Single Provider Dependency Risks

A single card processor is the only means of authorising card transactions for your organisation. Should that vendor experience an outage, there is no alternative means of authorising transactions. Furthermore, there is no fallback to another card scheme for the transactions to be authorised, and the same is true of other systems that are integrated with your authorisation system.

Furthermore, the vendor may no longer have the certifications required to support your transactions. For instance, a vendor that is certified to support European markets may not be certified for APAC regions, limiting its value as a vendor for your expanding markets. Furthermore, should they lose their authorisation for one of your markets, they can no longer support any transactions that occur in those markets.

How to Structure Multi-Provider Payment Flows

By routing certain types of transactions or certain card schemes to different card processing vendors, you can avoid the necessity of having all of your transactions pass through the same provider. For instance, you may have a European-based card acquiring program and an Asia-based issuing program for your customers, indicating a need for separate vendors to support each of these markets.

Furthermore, a vendor that is certified to support European merchants does not have to provide the same services as those that support APAC markets like UnionPay.

Choose vendor-agnostic APIs and open standards again in this strategy to enable your provider to support multiple vendors by simply adding them to your integration. If the vendor dependencies are proprietary systems that integrate with your system directly, adding a second provider will require a re-engineering of your current integration.

Design for Data Portability and a Clean Exit

The vendor's implementation of tokens or tokenisation systems should be decoupled from your system prior to signing an agreement with the vendor. Proprietary implementations of tokens that the vendor manages themselves will make it extremely difficult to exit your agreement with that vendor and transfer your data to another.

Ensure that the vendor will provide you with data export rights. Prior to signing an agreement with a vendor, you should be able to pre-negotiate the terms under which you would like to access your transaction history upon exiting the agreement. Such terms should include:

Ensure that your own system is still implemented and managed by yourself. By routing your transactions through your own system, you can maintain control over your relationship with your processor. Should you exit your relationship with that vendor's processors, you can still route your transactions through your own system.

How to Evaluate a New Processor for Lock-In Risk

Before signing with any processor, evaluate its lock-in risk against both technical and contractual criteria. The table below summarises the key areas to examine.

The more third-party vendors that are incorporated into a vendor's system in such a way that they are closed and internal systems (such as fraud, tokenization, 3DS, and their own reporting tools), the more locked into their vendor you will become.

Exit provisions for the vendor agreement should be published, and they should be as straightforward as possible to fulfil. A vendor that takes great care to provide a thorough, well-specified contractual agreement is likely providing a vendor relationship that is difficult to exit.

When Some Vendor Dependency Is Acceptable

Not all vendor dependency is a problem. Some integrations bring enough functional value that the dependency is justified.

A vendor that is certified with token provisioning to systems like Apple Pay, Google Pay, Samsung Pay, and Garmin Pay has invested in the infrastructure to provide customers with features like contactless payments, in-application purchases, and eCommerce functionality without exposing their actual card numbers. Such a vendor dependency is justified through the benefits of the provided functionality. Furthermore, because the vendor uses network-anchored tokens, the vendor is not locked into the data of the customer's payment systems.

For any vendor dependencies that are created in the integration, the question is not whether the vendor is dependent on that third party and what their features are, but rather how difficult it would be to exit that vendor, and what systems would need to be re-engineered or replaced as a result.

Building Long-Term Payment Flexibility

Maintaining payment flexibility is an ongoing process, not a one-time architectural decision.

While authorisation and switching, card lifecycle, fraud and dispute, and reporting can each exist as separate layers within a payment system, they can also often be implemented as a vendor that controls and manages all of these functions at once. Migrating only the authorisation and switching functions from a vendor that manages those other functions is one thing; migrating a vendor that manages all of those functions at once is another.

Maintaining flexibility in your payment system can occur through an annual review of your provider map to ensure that you are up to date with any changes to the system. What may have been an appropriate relationship with a payment provider when the organisation was just starting up may not be the same relationship that is appropriate as your organisation expands into new markets, begins to offer different types of products, and begins to implement systems like tokenization to improve security.

How DECTA Helps You Avoid Payment Infrastructure Lock-In

DECTA is a third-party technical payment processor built to help you avoid payment infrastructure lock-in, accredited by Mastercard, Visa and UnionPay and operating in both the European Union and the APAC region. Its systems and data networks are specifically built in a way that helps to avoid the lock-in risks that are described in this article.