Payment routing is judged in the payment step, where the shopper only sees whether it worked
In August 2024 Digital Transactions reported on a vendor evaluation by the research firm Datos Insights, which concluded that payment orchestration platforms now have to work harder to set themselves apart. The report names smart payment routing as a key differentiator and lists what that covers: payment flows tailored to the merchant, A/B tests between processors, and a second route that takes over when the first provider is down. Read as a market report, it is about vendors competing with each other. Read from the checkout, it describes things the shopper never sees until the moment one of them goes wrong.
That second reading is the useful one. Nobody chooses a webshop for its routing logic. A shopper notices the back end only through the payment step: which methods appear, in which order, under which names, and what happens after pressing pay. Every capability on the Datos list ends up as one of those four things, or as nothing the shopper can tell apart from any other shop.
The list of payment methods can follow the order instead of a fixed template
Check whether your own payment step shows the same list to every shopper, in the order it was set up at launch. A December 2022 commentary in the same publication, written by the chief executive of an orchestration provider, describes the alternative: a payment step that decides per shopper which methods appear and in what order, using the contents of the basket or the shopper’s purchase history. The examples are concrete. A payment option whose processor does not allow certain products is hidden when those products are in the basket, and above a set order value, $1,000 in the example, a buy now, pay later or bank payment option moves to the top of the list while the other methods stay available.
The principle matters more than the technology behind it. A shopper who selects a method and is then told it cannot be used for this order has hit a dead end at the last step. Removing the option in advance is better than an error message afterwards. Order value works the same way: someone spending a large amount weighs payment options differently from someone buying a phone case, and the order of the list can reflect that. Keep the variation modest, though. A list that reshuffles from one visit to the next makes returning customers search for the method they used last time, and the method most of your shoppers use belongs in a stable, visible place at the top.
Payments are local, and so is what the shopper recognises
Thad Peterson of Datos Insights put one of the drivers behind orchestration in a single line, “Commerce is global but payments are local”, and added that merchants have to offer customers the payment options they want to use. In the Netherlands that starts with iDEAL, which the Betaalvereniging reports is used for 71% of online purchases. A Dutch shopper who does not see it near the top of the payment step will look for it before looking at anything else.
Selling across borders multiplies this. Each market has its own default method, with its own name and logo, and shoppers scan for that logo rather than read the list. One combined list for every country puts methods in front of shoppers who have never heard of them and pushes the familiar one down. Show the methods per delivery country, with the local method first and the label shoppers in that market know, and check that the language of the payment step matches the language of the rest of the checkout.
A fallback the shopper notices is a second checkout
Fallback routing sounds like something that happens entirely out of sight, and when a route is unavailable before the shopper has done anything, it can. The picture changes once the shopper is involved. Many payments now ask the shopper to confirm in a banking app or with their card issuer. If an attempt fails after that step and the payment is tried again elsewhere, the shopper may be asked to confirm a second time, or may see a failure message while their banking app shows an amount reserved. To the shopper each of those moments looks like a broken shop, whatever is happening behind it.
A/B tests between processors raise a similar point. Datos lists them as a feature, and the usual yardstick is how many payments are approved. That figure does not show how long the shopper waited, how many were sent to an extra confirmation step, or how many gave up on the screen that followed a decline. Approved payments and completed orders are not the same number, and only the second one reaches your revenue. Any test that changes what happens around the payment should be read on completed orders per payment attempt, broken down by method and by device.
Write down what the shopper sees when a payment fails
Describe the payment step from the shopper’s side for each failure, not from the routing diagram. For a declined card, an unavailable method, a bank confirmation that times out and a payment tried a second time, note what appears on screen, whether the basket and the entered details are still there, whether another method is offered right away, and what the order confirmation and the banking app show if the second attempt goes through. Then run each case yourself on a phone. Wherever the answer is an empty basket, a generic error or an amount the shopper cannot explain, the routing may have done its job, but the checkout has not.
Sources: digitaltransactions.net, digitaltransactions.net and betaalvereniging.nl
