What is payment orchestration?

What payment orchestration means

Payment orchestration is a software layer that sits between the places where payments are accepted and the acquirers that process them, and decides for each transaction where it goes. It applies in person, where the payment starts at a terminal, a SoftPOS phone, a vending machine, an EV charge point or a transit validator.

An in-person payment orchestration platform connects those devices to several acquirers and processing centres through one integration. Rules decide which acquirer takes each transaction, a backup takes over when one stops answering, and the platform translates every message into the protocol the chosen acquirer expects.

Two related terms come up in the same conversations. A payment gateway carries transactions to an acquirer. A payment switch is the engine that receives transactions, applies the routing rules and translates each message, and an orchestration platform is built around such a switch.

Why in-person orchestration is a different problem

Online, a merchant adds a second payment provider with an API integration and a contract. At a counter, the payment runs through certified hardware. The terminal holds a payment application, encryption keys and EMV parameters, and in many markets that software is written for one acquirer's host. Changing acquirer can then mean new software on every device, a new certification or new terminals.

Card-present payments also come with conditions that a web checkout does not have. A kiosk or a charge point has no cashier to retry a failed payment. A transit validator accepts a tap as the passenger boards, and the fare is often worked out after the trip. Terminals lose connectivity and need offline rules, and cash register integrations tie the terminal to the point of sale software. An orchestration layer for this world has to handle devices, keys and card-present messages, not only API calls.

Payment orchestration features for in-person payments

A platform between the device and the acquirer does six jobs. Our platform also adds tokenisation, dynamic currency conversion, offline acceptance and alternative payment methods on the same layer.

Routing

Rules decide which acquirer or processor receives each transaction. Typical criteria are the card type, the amount, the merchant, the terminal and the country. Routing can follow cost, approval performance or regional coverage, and it changes as configuration rather than as a software release.

Failover

When an acquirer does not answer, the platform sends the transaction to a backup acquirer and the sale still completes. With a single acquirer and no failover, an outage at that acquirer stops card acceptance across the whole fleet.

Protocol translation

Acquirers and processing centres each expect their own message format and connection. The platform maps every transaction into the format of the chosen host, so the devices keep one integration while the hosts behind them change.

One integration to many acquirers

Devices and cash registers connect once. Adding an acquirer, a domestic scheme, a fleet card issuer or a wallet then becomes a configuration step on the platform instead of a project on every device.

Terminal management

In person, the platform also runs the fleet. A terminal management system pushes parameters, firmware, applications and keys to the devices and shows their live status, so a new route or payment method does not need a site visit.

Reporting

Every transaction passes through the same layer, so reports and reconciliation cover all acquirers and devices in one place instead of one portal per acquirer.

How a transaction flows through an in-person platform

The steps below follow one card payment from the tap to the report. The path is the same whether the payment starts at a counter terminal, a SoftPOS phone or an unattended device.

1. 1

   Card read on the device

   The cardholder taps a card or a phone, or inserts a card. The payment application reads the card and encrypts the card data on the device.

2. 2

   Request sent to the platform

   The device sends the authorisation request over its one connection to the orchestration platform, not to a fixed acquirer.

3. 3

   Routing rules applied

   The platform checks the rules for that merchant and terminal, such as card type, amount and country, and selects the acquirer.

4. 4

   Message translated

   The platform maps the request into the format and protocol the selected host expects and sends it host to host.

5. 5

   Failover if needed

   If the host does not answer in time, the rules send the transaction to the backup acquirer, and the device still gets a response.

6. 6

   Response returned

   The approval or decline travels back through the platform to the device, which completes the sale and issues the receipt.

7. 7

   Logged, cleared and reported

   The platform logs the transaction, passes it on for clearing and settlement, and shows it in reports across all acquirers.

When a business needs payment orchestration

Orchestration adds a layer, a contract and a dependency, so it has to pay for itself. It usually does when at least one of these conditions applies.

• You work with more than one acquirer, for cost, for coverage or because each country has its own.
• An acquirer outage costs sales that never come back, as at unattended machines and EV charge points.
• The fleet mixes Linux counter terminals, Android terminals, SoftPOS phones and unattended readers.
• Your merchants need methods the acquirer does not process, such as fleet cards, meal vouchers, domestic schemes or account to account payments.
• You run acceptance for other businesses as a bank, acquirer, PSP or ISO and want it under your own brand.

When a single acquirer is enough

A merchant in one country with a small fleet and no plan to add a provider can start with a single acquirer, and that is a Switchio setup too. The platform then runs with one acquirer, which keeps it even simpler to manage and deploy, and a second acquirer can be added later as configuration. The guide on payment orchestration vs payment gateway compares the two setups in a table.

How Switchio does it

Switchio is the in-person payment orchestration platform of MONET+. At its core is a payment switch that routes transactions from Linux and Android terminals, SoftPOS phones and unattended devices to 40+ acquirers, with automatic backup routing and protocol translation. Terminal management, merchant portals and reporting run on the same core.

MOL Group used to process bank cards on one terminal and fleet cards on another. With Switchio one terminal accepts both, and the group takes the switch as software as a service for its network of 1,900 service stations. The MOL Group story lists what changed.

Questions people ask