Payment orchestration: the layer above the gateway

When selling software in Latin America, the ISV (Independent Software Vendor, a software company that sells its product to other businesses) discovers that the approval rate fell, that half the boleto invoices expired unpaid and that each country opened a different account to reconcile. The gateway processes the transaction. It does not solve the rest.

What is the payment orchestration layer above the gateway?

The orchestration layer above the gateway sits between the ISV application and the processors. It decides which acquirer or rail each charge goes through, retries a decline intelligently and reassembles the events into a single reconcilable statement. The gateway executes the payment. The orchestration governs how it is routed.

That distinction sounds semantic until the day a Mexican card decline takes down the renewal of a client who had been paying for two years. The gateway honored its contract: it took the data, sent it to the configured acquirer, returned the decline code. The problem was not in the processing, it was in the decision to route everything through a single acquirer, in a country where approval depends on which acquirer sees the transaction.

Where one ends and the other begins

A gateway is a door: it translates the charge into the acquirer's format and returns the response. Orchestration is the layer that decides which door to use, in what order to try and what to do when the first one closes. When the ISV has a single acquirer, a single geography and low volume, the second door does not exist to be chosen, and the upper layer becomes operational weight. This is not a flaw in orchestration, it is its adoption criterion, and it is what this guide delivers at the end.

What does orchestration solve beyond the gateway?

Orchestration solves four problems that the gateway, by definition, does not touch: routing across multiple acquirers, intelligent retry of declines, reconciliation of events coming from different sources and presentation of local currency and method by country. The gateway stays in the same place: processing each transaction the layer above it decided to send.

It is worth separating what changes place. The gateway does not disappear with orchestration, and orchestration does not replace the gateway. The two coexist, and confusing them is what makes a CFO sign for the wrong layer. The table below contrasts the two responsibilities.

The reading of the table matters less for what orchestration does and more for what it requires in order to work. Every line of "Yes" in the right column assumes that the ISV has more than one acquirer, more than one rail or more than one currency in operation. Without that fragmentation, the layer adds a moving part without moving the needle on the result.

Multi-acquirer: why does routing across acquirers change the approval rate?

Routing across acquirers changes the approval rate because the decline of a legitimate transaction is usually a decision by the acquirer, not by the client. An acquirer that rejects a corporate card from a bank it treats with a conservative rule can approve the same charge when another acquirer, with different BIN tables, sees the transaction.

In Latin American markets, the approval difference across acquirers is observable. Mexico operates with several competing acquirers, each with its own risk rules and BIN coverage. Brazil concentrates volume in a few players. Alternative methods, PIX and boleto, follow their own settlement rules, and acquirer coverage in Colombia and Chile varies by card type and by issuer, which makes the avoidable decline of a legitimate corporate card show up far from any cost discussion. For the ISV selling in the five markets, the revenue lost on the renewal is the first number finance should look at.

The decline that is not delinquency

There is a confusion that costs money in subscription renewal. A decline can mean three distinct things: insufficient funds, invalid data or a risk decision by the acquirer. The first two call for action by the client. The third calls for routing action, and no gateway alone distinguishes it. A generic "transaction not authorized" error code hides those three cases under the same name.

The orchestration layer reads that code, applies the retry rule and, if the case is a risk case, forwards the charge through an acquirer with a different approval profile. That decision, made transaction by transaction, is what separates one approval rate from another. Chargeback prevention in cross-border SaaS works the opposite side, the side of real fraud, and the two fronts do not replace each other. For a comparison of the platforms that do this routing, see payment orchestration: what it is and how to choose platforms.

Smart retry and reconciliation: what are they, in practice, for the ISV?

Smart retry is the retry that chooses when, through which rail and how many times to try a declined charge again, instead of repeating the same call on the same rail. Reconciliation is the process of matching each payment, approval, reversal and settlement event with the corresponding invoice, in a single statement that closes.

A naive retry repeats the call to the same acquirer, in the same minute, and gets the same decline. Smart retry does something else:

1. It classifies the cause of the decline from the returned code, separating technical failure from risk and from invalid data.
2. It defines the retry window, because a decline for insufficient funds on the due date can approve three days later.
3. It chooses the alternative acquirer or rail when the cause is risk, not funds.
4. It stops retrying after a limit, so it does not generate attempt cost or irritate the client.

Reconciliation completes the cycle. Without it, the ISV closes the month with a statement from acquirer A, another from acquirer B, a PIX report and a boleto spreadsheet, and the sum does not match recognized revenue. Payment reconciliation is what turns four statements into a single revenue line. On the side of real fraud, and not the avoidable decline, the work is different, detailed in chargeback prevention in cross-border SaaS.

When is orchestration NOT worth it?

Orchestration is not worth it when the ISV has a single acquirer, operates in a single geography, processes low volume, already reconciles without friction and carries no currency or receivable risk. With all five conditions true, the layer adds a system to integrate, a contract to maintain and a point of failure to monitor, without moving any metric finance tracks.

The common mistake is treating orchestration as an automatic upgrade over the gateway, something every ISV should have as soon as it grows. It is not. It is a conditional decision, and the conditions are concrete. When a company bills USD 30 thousand a year in a single country, with a single acquirer and a gateway that resolves 96% of transactions, what is the upper layer for? It is for adding fixed cost to an operation that already works.

The "not worth it" criterion

It is worth naming the conditions in which the layer does not pay for itself. If all five below are true, orchestration is unnecessary cost:

• A single acquirer covers more than 95% of volume, with no relevant risk declines.
• A single geography concentrates the whole operation, and the main local method is one.
• The current reconciliation closes the month without relevant manual adjustment.
• The volume does not justify an additional contract or a team dedicated to monitoring the layer.
• The ISV has no currency or receivable risk to absorb: it does not receive in foreign currency nor carry the buyer's term.

When any of those conditions stops holding, the calculation inverts. Fragmentation is the variable that decides, not the size of the company. A small ISV that sells in four countries fragments more than a large operation in a single country.

How to decide: a checklist for the international ISV

The international ISV decides by the count of real fragmentations, not by the size of the operation. How many acquirers and rails the operation needs, how many countries it covers, what the current approval rate is and what the cost of an avoidable decline on the renewal is. The answer to those questions decides whether the layer pays for itself.

The checklist below turns intuition into math. It works both to hire an orchestration layer and to diagnose whether the problem is really in the payments layer or somewhere else in the operation.

1. Ask who holds the acquiring contract today. The international ISV does not obtain a direct acquirer contract in Latin America without a local entity or a licensed provider. If acquiring runs through an intermediary, fragmentation already exists and it is the intermediary who decides the routing.
2. Count the active acquirers and rails. A single acquirer rarely justifies the layer. Three acquirers plus PIX and boleto, with distinct rules, almost always justify it.
3. Measure the approval rate by market. Avoidable decline above 3% in any country is money left on the table, and it is the first argument for the layer.
4. Add up the cost of the decline on the renewal. An annual subscription declined for acquirer risk costs the value of the entire renewal, not the transaction fee. Multiply it by the client base in the country.
5. Estimate the cost of manual reconciliation. Add up the finance hours closing statements from different sources. If the number is small, the layer solves a problem that does not exist.
6. Check local currency and method coverage. Every country that requires its own currency and its own method adds a line to reconciliation and an argument for the layer.
7. Decide by fragmentation, not by ambition. If the count above is low, the path is to postpone the layer and solve the root of the problem by another means.

Step seven is the one most people skip. Where fragmentation does not exist, it becomes a solution in search of a problem. The math decides on its own.

The orchestration layer is a response to fragmentation, never an automatic upgrade.

How Nexforce Marketplace removes the layer for the ISV

Nexforce Marketplace removes the need for the orchestration layer for the international ISV that sells in Latin America because it solves fragmentation at the root, instead of managing it from above. Nexforce contracts in the capacity of a local reseller: an operation in the region that buys the licenses and resells them to the buyer in the country, takes on the local contract and the acquiring, and pays the ISV in its own currency. The ISV does not build the multi-acquirer, multi-country and multi-currency structure. It delivers the software and gets paid in its own currency, with currency and receivable risk staying with the local operation, not with its balance sheet.

The logic is that of this article's own criterion. Fragmentation decides. Orchestration pays off when there is fragmentation, and Nexforce Marketplace works so that fragmentation never reaches the ISV. Instead of the vendor opening a fiscal entity in each country and reconciling acquirers and rails, it sells to Nexforce's local operation and keeps its own process. A practical path to understanding that comparison is in local payments: the cost of selling SaaS in Latin America.

What the ISV gains, in facts

• No cost to the ISV and no minimum deal size. The vendor does not pay to enter, and Nexforce does not require a minimum volume of operation.
• Local currency for the buyer, the ISV's currency for the vendor. The buyer pays in local currency and method; the local operation absorbs the currency and receivable risk, and the ISV is paid in its own currency, with the exchange lock set in the contract. Not in Brazil alone.
• Payment methods of the region. PIX, boleto, local cards and installments enter the operation without the ISV building each integration. The detail of each rail is in PIX, SPEI and boleto: local payment for the SaaS vendor.
• The local operation buys and pays the ISV upfront, and lets the buyer pay in up to 12 installments. It is a commercial resale condition, under the local reseller capacity: the ISV gets paid upfront in its own currency and carries no receivable, while the buyer gains terms. The working capital asymmetry belongs to the local operation, not to the ISV's balance sheet.
• The ISV's own contract and programs. The local operation contracts under the contract standard and partnership programs the vendor already uses, without rewriting its commercial process.
• Cloud agnostic and a reseller network. Transacting with Nexforce requires no commitment to a specific cloud, and the reseller network opens channels the ISV would not reach alone.
• Leverage on the rest of the software spend. Nexforce identifies savings on other licenses the client has already bought and uses that gain to make the ISV's deal viable, a commercial mechanism with no tax treatment of its own in this article.

For the ISV still weighing the structural decision between an intermediary and its own operation in the region, reading Merchant of Record vs own operation in LatAm complements this criterion. The orchestration layer and the decision about who takes on the local operation are distinct questions, and the second usually comes first. The solution page is at Nexforce Marketplace.

Frequently asked questions

Does payment orchestration replace the gateway?

No. Orchestration sits above the gateway and decides which acquirer or rail each charge goes through. The gateway continues to do the capture, the tokenization and the communication with the acquirer. The two coexist, and orchestration only exists as a layer when there is more than one routing option to coordinate.

When should an international ISV not hire orchestration?

When it has a single acquirer, a single geography, low volume, a reconciliation that closes without manual adjustment and no currency or receivable risk to absorb. In that case, the layer adds a system to integrate and a point of failure to monitor without improving approval, cost or reconciliation. The criterion is fragmentation, not the size of the company.

What does smart retry do that a common retry does not?

The common retry repeats the same call to the same acquirer and gets the same decline. Smart retry classifies the cause from the code, defines the retry window, chooses another acquirer when the decline is a risk case and stops retrying after a limit. The difference shows up in the approval rate of recurring subscriptions.

What does reconciliation solve in practice?

Reconciliation matches approvals, reversals and settlements with the corresponding invoice and produces a single statement per currency. Without it, the ISV closes the month adding up statements from different acquirers and from rails like PIX and boleto, and the sum does not match recognized revenue. It is what makes the multi-country operation auditable.

References and Further Reading

• Payment orchestration: what it is and how to choose platforms
• Merchant of Record vs own operation in LatAm
• Local payments: the cost of selling SaaS in Latin America
• PIX, SPEI and boleto: local payment for the SaaS vendor
• Chargeback prevention in cross-border SaaS

Next step

The question this guide answers is not "is orchestration good", but "does the fragmentation of my business already justify the layer above the gateway". For the international ISV that sells in Latin America, the honest answer is usually that the problem is not the lack of an orchestration layer. It is the need to build the local operation that fragmentation exposes. Nexforce Marketplace solves that root: the local operation contracts in each market, charges the buyer in local currency and method and pays the ISV in its own currency, without the vendor opening a fiscal entity in each country or reconciling acquirers on its own. The ISV's gain is operating in LatAm with another company's local structure, not its own. The decision comes before that.