OPERATOR GUIDE Convert → Recover → Operate 7 min read Lifecycle

Why payment orchestration matters in LATAM

Payment orchestration is one of the most over-pitched and under-explained categories in LATAM commerce. The honest version is narrower and more useful than the vendor narrative. It's worth understanding before you buy.

Why this matters

LATAM is not one payments market. It is a federation of national rails, regional wallets, and legacy card networks operating under very different approval economics.

Colombia runs Bre-B, PSE, Nequi, Daviplata, and cards through acquirers whose approval rates can sit 20-40 points apart on the same BIN. Mexico runs SPEI for high-ticket, OXXO for cash, and cards routed through a small set of acquirers with very different issuer relationships. Brazil runs Pix as the dominant rail, with boleto as the cash backstop and cards still doing meaningful volume on subscriptions. Chile leans on Khipu, Klap, and cards. Peru runs Tupay, Yape, PagoEfectivo, and cards. Ecuador runs Payphone and cards. Argentina is its own situation entirely.

The operator question is rarely “should we accept method X.” It is “given a transaction with this amount, this customer history, this issuer, in this city, on this hour, what path gives us the highest expected revenue, net of cost.” That question doesn’t have a single answer, which is exactly why orchestration exists as a category.

What this guide is not: a pitch to buy an orchestrator. Orchestration adds operational complexity, integration debt, and a layer of opaque routing logic between you and your acquirers. It is worth it above a certain scale and a certain margin profile, and it isn’t always worth it. The goal here is to give you the operator frame to decide.

What goes wrong

The most common failure mode is not “single-PSP setups underperform.” It is more subtle:

  • Approval rate is benchmarked once, then never re-checked. A merchant picks a PSP, sees 78% approval at launch, and assumes that number is the ceiling. Two years later that PSP’s approval rate on the same BINs has drifted to 71% and nobody noticed because nobody is measuring counterfactuals.
  • Recovery is implemented as same-card retry. The card declined for issuer reason 05. Three minutes later the same card is retried through the same acquirer. It declines again. The customer is now annoyed and the issuer has logged a second failure on the same merchant.
  • Reconciliation cost grows superlinearly with PSP count. Adding a second PSP without orchestration roughly doubles finance workload. Adding a third triples it. The orchestration value here is not in routing, it’s in the unified ledger.
  • Method coverage is confused with method optimisation. “We accept Pix” is not the same as “we route to Pix when Pix is the highest-expected-value option for this transaction.” The first is a checkout decision. The second is an orchestration decision.
  • Vendor lock-in by orchestrator. Some orchestration platforms own the customer relationship with the acquirer, which solves one problem and creates a worse one. The honest version of orchestration leaves the acquirer contracts with the merchant.

Operating model

Orchestration is best thought of as three jobs that happen to live in the same system. Each maps to a stage of the lifecycle.

Operating model

Convert. At authorisation time, choose the method and acquirer most likely to approve this specific transaction. Inputs: amount, BIN, issuer, customer history, time-of-day, prior failures on this card. Output: a routing decision that maximises expected approval net of fee.

Recover. When a transaction fails, decide whether to retry, and if so, on what rail. The default should rarely be “same card, same acquirer, in 30 seconds.” Alternative-method recovery, offering Bre-B, PSE, Pix, SPEI, or a wallet, usually beats same-card retry by a wide margin.

Operate. Maintain one source of truth across PSPs. One ledger, one reconciliation pipeline, one chargeback queue, one settlement view. The operational win compounds as the number of PSPs grows.

A team that treats orchestration as only the Convert job tends to underprice it. The Recover and Operate jobs are where most of the long-term value sits.

A few principles that hold across most LATAM operators:

Earn the right to orchestrate by measuring first. Before you add a routing layer, instrument approval rates per PSP, per method, per BIN range, per ticket size. Most teams discover their single-PSP performance is more variable than they thought, and the orchestration case writes itself.

Start with method coverage, not routing logic. The biggest conversion gains in LATAM still come from accepting the right local methods at all, Bre-B in Colombia, Pix in Brazil, SPEI in Mexico, rather than from optimising routing between them. Don’t put a routing layer on top of a thin method set.

Make the recovery rail different from the failure rail. If the customer’s card failed at Acquirer A, your first recovery attempt should not be the same card at Acquirer A. It should be an alternative method, or a different acquirer for the same card, in that order.

Keep contractual relationships with acquirers. The orchestration layer should be configuration, not custody. You should be able to switch orchestrators without renegotiating your acquirer agreements.

Build the ledger before the routing. A unified ledger across PSPs is the most boring and most valuable part of orchestration. It is also the part you cannot retrofit easily once you have three PSPs and four months of unreconciled volume.

Be honest about the threshold. Below roughly USD 1-2M/month in card volume in a single country, orchestration is usually premature. The operational cost of running three PSPs outweighs the routing gains. Above that, the math flips fast.

Example architecture

A working reference for a LATAM operator running orchestration seriously:

Architecture
Checkout / chat / agentic surface

Method selector (local rails surfaced by country)

Orchestration layer
    → routing decision (PSP, acquirer, method)
    → 3DS / risk decision per route

PSP A   PSP B   PSP C   local-rail processor (Bre-B / Pix / SPEI)
    ↓       ↓       ↓                   ↓
Authorisation result
    → approved → ledger entry → settlement queue
    → declined → decline classifier
                    → soft → alternative-method recovery
                    → hard → suppression

Unified ledger (one truth across rails)

Reconciliation + chargeback + reporting

Three pieces of this matter more than the rest: the decline classifier (so retries are smart, not lazy), the alternative-method recovery loop (because same-card retries are the wrong default in LATAM), and the unified ledger (because operational pain is what kills multi-PSP setups, not technical pain).

Metrics to watch

Approval rate uplift
3-8 pts
Recovery rate (alternative-method)
15-30%
Reconciliation cycle
daily, not monthly
PSPs to break even
2-3

Approval rate uplift is the headline metric and the easiest one to over-claim. A clean test is a holdout where a defined slice of traffic continues to route to a single PSP for a measurement window; the uplift you see against that holdout is the real number. Anything else is a vendor estimate.

Reconciliation cycle is the boring metric that tells you whether the orchestration setup is sustainable. If finance is still closing books monthly with manual CSV joining, the routing wins are being eaten by operational drag. Daily reconciliation, automated, is the bar.

What to read next