Billions have been made by building, deploying and supporting payments API infrastructure. However, has the time come to retire customer facing APIs and move onto something better?

The near ubiquitous presence of APIs in payments has been transformative. It has enabled significant more flexibility in the way payment users interact with the payments ecosystem. APIs first emerged to manage authorisation messages for cards, but they can now be found across the lifecycle of payment products from merchant onboarding to reporting as well as a whole ecosystem of adjacent products from lending to issuing and fraud. APIs infrastructure has underpinned the emergence of the current breed of intermediary platforms for embedded finance from PayFacs to SaaS/ISVs because of their security, flexibility and richness.  

However, APIs have a number of significant drawbacks for both merchants and platforms (SaaS, marketplaces, etc.) users: 

It’s particularly the last issue that the payments industry will need to watch closely (the other two issues have been around for a while). Regulators have already expressed their displeasure with the BaaS world in both the US and Europe and its reliance on third party compliance programmes. As embedded finance gets more popular, this issue of layering is likely to grow in importance. APIs are not really fit for purpose to support the growth of the embedded finance model, particularly in regions with proactive regulators with strong compliance mandates.  

Given the limitations outlined above, is there a better alternative? History provides a strong clue by looking back at what happened to the original payment API, the authorisation request. Initially merchants had a choice between integrating into acquirer’s APIs or using (rather clunky) hosted payment pages. More recently acquirers began offering hosted payment fields (AKA drop-in UI, components, elements, etc.). These break out core elements of the payments page and allow merchants to customise the location and look and feel (font, colour, etc.) of fields while the data within them is still controlled by the acquirer. This integration approach is now the dominant model for merchants who want to control their check-out experience.  

So is this a model for other payment APIs, particularly in the increasingly popular embedded finance world? First, let’s look at the benefits to merchant/platform users… 

…and there are also several benefits to PSPs themselves:

We already see innovative players offering this service in embedded finance for a wider range of use cases beyond authorisation, e.g. onboarding, reporting, support. This includes early offerings from Stripe and a number of specialist players such as UniPaaS and Rainforest.  

The value of drop-in elements is particularly clear in the more complex use cases which PSPs are starting to support, such as where marketplaces or platforms are onboarding merchants across multiple countries as documents, languages and types of business all differ by market. Building a dynamic UI to capture and pass the correct data elements to onboarding APIs, and deal with the many possible exception conditions, is a lot of work for these marketplaces/platforms. It’s far better to let the PSP develop the UI once and simply embed it. As well as the set-up benefits, a centrally managed service means changes to compliance requirements can be implemented once by the PSP and automatically appear in all users’ UX.  

So does this mean the payment API will disappear completely? I would argue that for all but the very largest players, the drop-in UI model will gradually displace the API for many customer–facing scenarios, as it has for the authorisation request. However, there are still likely to be back–office processes where the raw API (inc. webhooks) still has value, e.g. transaction lifecycle status, or integrating reporting data into a data lake. Equally, fully hosted pages are still going to have relevance for smaller users who prefer a plug–and–play service. It’s therefore likely that payment providers will need to keep APIs alongside drop-in components, and fully hosted pages, for some time. The API is not quite ready for retirement, but it is going to have to share the stage with a more attractive, flexible co-star…