Online payments now span far more options than cards alone. Digital wallets, account-to-account payments and local methods sit alongside a growing number of acquirers and specialist providers.
That fragmentation is welcome. It gives customers more ways to pay, creates room for innovation and allows banks and payment companies to bring competitive new products into the market.
Merchants still have to make all of that choice work together. Every new method, acquirer or local connection has to be brought into the payment flow, linked to existing systems and maintained, often by technical teams that are already stretched.
When payment methods, rules and provider connections are fixed, growing choice becomes harder to use. Customers see options that do not fit their preferences, while merchants take longer to react to new markets, changing behaviour or a drop in provider performance.
Choice needs context
Adding more methods to a payment page can create a longer list without creating a better journey. A customer paying on an iPhone, a returning buyer making a familiar purchase and someone shopping in a new market may all be shown the same options in the same order, when in fact their needs and preferences might be quite different. The bottom line is that a ‘one-size-fits-all’ approach no longer works.
The checkout already has useful signals available that can help merchants shape the right experience, these include device, location, currency, transaction value and customer history. This data can help decide which methods appear first and which route is most likely to complete successfully.
On mobile, wallets should be easy to find; in markets where domestic options are preferred, then those local methods should sit near the top. Returning customers should also be able to find the option they used before without trawling through the full list again.
The commercial value comes from making relevant choices easier to find – almost an automatic choice for the consumer. A customer who has to scroll, re-enter details or work through multiple steps is more likely to abandon the payment before it is complete.
Risk changes from one payment to the next
An established account that has used the same payment method for months does not present the same risk as a new account attempting a much larger transaction. Yet both can end up subject to the same steps and checks.
Merchant-set rules need to leave room for those differences. An authentication or fraud screening process that works for one type of transaction can be too complex, or even too short for another, particularly when customer history, transaction value, risk signals and market conditions vary.
Who controls the change?
A hosted payment page often comes from the company processing the transaction. At the start, that is convenient. The merchant has one supplier to deal with and less plumbing to build.
Then the business wants to add a second provider, bring in a local method or change what appears first on the page. Suddenly, the original supplier’s technology and release schedule can become a blocker.
An independent payment orchestration layer above the processors gives the merchant more room to act. The customer journey stays in place while methods are added, routes change and different providers operate behind it.
When every change needs a release
The payment team knows what needs changing, but the work still starts with a ticket. Customers can continue abandoning one method while engineering deals with other priorities.
Reordering methods, adjusting a limit or changing the provider behind a transaction should be routine payment work. Giving payment teams control over those changes also leaves developers free to concentrate on the core products and services.
What happens after the click
The option shown on the page is only part of the transaction. Once the customer chooses how to pay, the result still depends on the provider, market, currency and route behind it.
Payment teams can usually see when a route is going wrong. Approval rates dip, response times lengthen or failures start clustering in one market. The harder part is acting on it. The problem has been identified, yet the next transaction can still follow the same route.
With more flexibility in the payment layer, the team can reroute transactions, remove an unavailable method from the page or favour another provider while the issue is resolved. Otherwise, customers keep running into a problem the business has already spotted.
A live payment page is a low bar. What counts is how quickly the business can change what customers see, add a new method and react when provider performance drops.
When those decisions are tied to one supplier’s timetable or a crowded development queue, sales can disappear even when the checkout still appears to be working.
Jacob Spencer, CRO, BR-DGE
