How to Use Composable Apps in Payments

Software can be designed and implemented in any number of ways, but a core architectural approach can be instrumental in producing tools that are ideally suited to their purpose. Increasingly, CFOs and the rest of the financial apparatus of organizations are looking to composable applications to give them the flexibility to adjust their approach at the speed of business. More than just a ‘best-of-breed’ approach, composable applications are designed to decouple individual elements of any system so that they can be swapped out, updated, and replaced as part of a broader optimization goal.

What are composable applications?

Composable architecture is a design methodology intended to reuse independent modules, combining them to create robust solutions to specific problems quickly and easily. It is normally based on microservices and APIs, allowing the software designer/developer to focus their efforts on orchestration rather than on building the core features and capabilities. 

This is, of course, a standard approach to building things in the physical world: a contractor updating a bathroom, for instance, would not personally manufacture a bath, or a shower head, or even the tiles that will be used to line the floor and walls. In software engineering, however, there has always been an undercurrent of ‘not invented here’, in which developers are often inclined to build everything from the ground up.

Composable architecture grew out of the services-oriented architecture movement, in which developers, arguably for the first time, started to call upon shared capabilities (services) published by other providers to achieve specific purposes. It has been a long time, for instance, since any developer coded their own email-sending capability - it is easier to simply pass information to an existing service and allow that service to push messages into the ether.

Headwinds Slowing Composable Applications in Payments

The payments industry has long been focused on making things as easy for users as possible, whether those users are the buyers or the sellers. Perhaps the best-known services for sellers are full-service payment service providers (PSPs) like Stripe, who make it simple for merchants to simply use provided APIs and SDKs to pass off the vast majority of the payment process to the PSP. While this model does, indeed, accelerate time to market for new offerings, the reality is that it suffers from the same challenge that many other proprietary systems have: all the merchants using the system are reliant upon a single development team to create any and all new features.

Why Composable Payments Applications are the Future

The reality is that the payment process has a dizzying array of opportunities for improvement once it gets moving. Merchants can improve their chances of successfully closing transactions by offering many payment methods, currency choices, and even signing up with multiple geographically-distributed PSPs, whose security systems aren’t tripped by cross-border transactions. They can also reduce their overall cost-to-transact by conditionally delivering transactions to preferred PSPs under different circumstances - whether it be based on payment method, location, or even type of product or service being purchased.

Given the pace of change in the payments industry - spoiler alert: it’s fast! - a composable architecture, in which different services can be simply added to, edited, or removed, is a near-necessity. This is because merchants are quickly realizing the need to partner with more than one PSP in order to maximize their sell-through and minimize their processing costs.

How to Structure Composable Payments Applications

The core requirement, without which a composable payments application is essentially impossible to operate, is full control over customer payment details, particularly credit and debit card numbers. Without full access to this information, and the unchecked ability to submit it to a selected PSP, the system simply cannot operate: it is extremely difficult, and arguably not possible, to manipulate a full-service PSP into redirecting transactions to your choice of alternative processor.

Taking control of cardholder data, however, can come with some unwelcome consequences for merchants trying to save that information within their own systems. For with the storage of that valuable information comes the requirement to adhere to (and potentially prove that the system adheres to) the PCI-DSS standard; failure to protect cardholder data to that exacting standard can lead to a merchant being excluded from the payment processing ecosystem.

It is, therefore becoming more popular for merchants to structure their composable payments applications using

• A programmable payments token vault: a third-party service, such as that offered by Basis Theory, accepts, stores, and protects customer cardholder data to the exacting PCI-DSS level one level, while providing programmatic access to submit that data to any secure destination selected by the merchant
• An orchestration, or decisioning, engine: a decision-making module, which considers each transaction as it is proposed by a customer and directs it to the best-fit among available PSP options. A dynamic piece of software, this engine can add, edit, or remove partners at will, and can adjust the logic at any time, so that, as PSP partners come and go, or as contractual arrangements change, the ‘right’ selection is always in the merchant’s hands
• Additional security and optimization services: third-party services that support the orchestration engine in its decisioning. For instance, checking addresses against up-to-date records to reduce stolen credit card fraud; risk assessment services, which can be used to determine whether a given transaction should be routed to a high-risk processor; and risk evaluators, to determine whether the amount of a transaction will exceed the risk tolerances of the merchant and trigger a rejection of the transaction altogether.

A Composable Payments Application is Indispensable

For any merchant, margins are at the heart of profitability, and the ability to reduce costs by dynamically switching between payments providers (while maintaining the highest transaction close rate possible) can be the difference between a strong and a weak quarter. Having the flexibility to add and remove PSPs at will empowers a merchant to add the best payment methods, eliminate partners delivering poor service, and ensure robust business continuity. Getting the core programmable payments vault in place is central to the strategy, as it provides full control over cardholder data, without incurring potentially ruinous compliance costs.