Three Ways into Latin American Acquiring: Local Acquirers, Cross-Border Aggregators and Ecosystem Platforms
"Latin America is not one market" has been repeated so often that it has stopped functioning as a warning. What actually costs teams a quarter is not the general truth that methods differ by country, but a far more specific question: in this transaction, who holds the local acquiring status?
Acquiring status determines three things — who authorises to the card networks, which path the cleared funds travel, and who carries and handles chargeback disputes. In Latin America, whether those three close locally determines local approval rates, whether disputes are winnable, and how much settlement you eventually receive. Around that question there are only three ways in: appoint a local acquirer, appoint a cross-border aggregator, or borrow the traffic of an ecosystem platform.
The general explanation of methods and culture — what Pix, Boleto, cash networks and instalment culture each mean — is in the Latin America payment guide; the positioning and boundaries of a single ecosystem platform are covered separately in the Mercado Pago guide. This article is the horizontal comparison: what each route costs you, how four local acquirers differ, and five blockers you cannot route around.
1. What really separates the three routes
1.1 Local acquirers: credentials and closure both sit locally
A local acquirer holds acquiring credentials in the country, completes authorisation, clearing and chargeback handling locally, and settles in local currency to a local account. What that status buys is controllability: the issuing bank and the acquirer operate inside the same rulebook and clearing network, so approval rates and dispute handling have the widest room for manoeuvre, and when something goes wrong the contact, the dispute process and the documentary requirements are all local.
The price is equally clear: eligibility lands on the entity. Local acquirers serve local merchants, and contracting normally requires a locally registered entity, a local tax ID and a local bank account. For an overseas seller this is not "one more document" but "do we incorporate here at all". Incorporation and maintenance costs belong in the market-entry model from the start; the wider judgement is in entity structures and collection accounts for cross-border sellers.
1.2 Cross-border aggregators: one API for many countries, uneven depth per market
Cross-border aggregators hold no acquiring credentials themselves. They package local acquirers, local methods and local accounts across several markets into a single API. You integrate once, collect in many countries, and receive settlement to an offshore or regional account under the contract.
What this solves is entry speed and entity friction; what it costs is uneven depth per market. The same aggregator may connect most major methods in Brazil and only cards plus one or two transfers in another country, with refunds, chargebacks and settlement cadence varying by market. It suits "validate the market first, then decide whether to go deep", and it does not suit replacing local acquiring status in a core market over the long run.
1.3 Ecosystem platforms: traffic is the upside, the account relationship is the price
The third route is the ecosystem platform, typically a payment provider grown inside an e-commerce ecosystem such as Mercado Pago. It arrives with consumers and habits already attached, conversion moves immediately, and eligibility tends to sit close to what a local merchant actually has.
But the upside and the dependency are the same object: the wallet lives on the consumer's phone, and the balance, the enrolled card and the entry point for the next purchase live on the platform side. Irrelevant for one-off purchases, decisive as a ceiling for subscriptions and high-frequency repeat business. It is better understood as "a payment source you must connect, plus an optional acquiring channel" than as "your collection infrastructure".
1.4 The right order: ask about status before features
The practical sequence is: decide whether you can and will hold a local entity in that market, choose the route accordingly, and only then compare feature lists and pricing.
Doing it the other way round — features first, entity later — usually ends with integration finished and launch stuck in underwriting, followed by an architecture rewrite of routing, callbacks and reconciliation. The three routes are not options that can be scored on one sheet; they are three different liability structures.
2. Four local acquirers
2.1 Cielo: infrastructure position in Brazilian card acquiring
Cielo is a traditional Brazilian card acquirer with two lines for merchants: in-store card acceptance and online e-commerce acquiring, sharing one merchant relationship.
Its capability most worth isolating is instalments (parcelamento). In Brazil, instalments are not a marketing tactic but the default settlement pattern: consumers expect an order to be split into several payments, and whether you offer it, and into how many, directly moves average order value and conversion. When evaluating a Brazilian acquirer, instalments are therefore a functional threshold rather than a bonus — a solution without them is effectively unusable in Brazil.
The second point is its position as a local acquirer: authorisation, clearing and chargebacks close locally, so local card processing and disputes sit in one system. That delivers not "a lower rate" but "a more predictable outcome". The eligibility bar sits in the same place: assessment runs on local entity, CNPJ tax ID and local bank account, so overseas sellers usually incorporate locally first or come in indirectly through an aggregator.
2.2 Getnet: a bank-owned acquirer, strongest on cash flow and credit
Getnet was founded in 2018 in Sao Paulo, Brazil, and is Santander's acquiring arm, providing card acquiring, POS terminals, online payments and payment processing as one integrated service. On official figures it serves more than three million merchants in Latin America, covers Brazil plus more than ten countries in the region, and supports more than ten card networks.
The value of bank ownership is not on the feature list but in cash flow and credit: settlement stability rests on the bank's clearing capability, and merchant credit and financial services can be arranged inside the same relationship. For a smaller merchant with a tight cash cycle that needs acquiring volume to fund working capital, this layer often weighs more than a rate difference.
The cost is the other side: product and pricing transparency is usually weaker than at independent acquirers, and negotiating room depends on merchant volume. Online payment interfaces and developer ecosystem are comparatively limited, so a technical team expecting complete documentation, a smooth sandbox and a rich plugin ecosystem will notice the gap.
2.3 PagSeguro: acquiring plus account, two legs
PagSeguro belongs to the UOL group and is structured on two legs: acquiring (an online gateway plus offline POS hardware) on one side, and the PagBank digital account on the other.
The key implication of that combination is the money path: online collections land in the PagBank account first, then fund withdrawals, transfers or supplier payments, so money circulates inside one system. For local micro-merchants that removes a layer of inter-institution reconciliation; for cross-border merchants it moves the barrier to the account layer — whether an account can be opened, what type it is, and which documents outbound funds require become the real gate.
On the product side, credit cards (including instalments), Pix and Boleto sit in one checkout. Those three cover three kinds of people: those with a card, those with a bank account, and those with only cash. For a local business with a mixed customer base, that coverage is conversion.
2.4 Kushki: the kind that grew from gateway into regional acquirer
Kushki started in Ecuador, and its evolution is worth noting: first a payment gateway, then a regional acquirer, and now it processes transactions end to end and connects directly to Visa and Mastercard rather than passing transactions to somebody else's acquiring system. Operating entities include Kushki Operadora S.A. in Chile and other local companies.
Its coverage is regional: offices in Mexico City, Guadalajara, Santiago, Bogota, Lima and Quito, plus a Miami office serving cross-border business. The product splits into four blocks — PayIns for collection, PayOuts for disbursement, Card-Present for offline acceptance, and Security for risk and security. Integration ranges from API to JS Library, payment button, e-commerce plugins, form components, payment links and offline acceptance, so teams with thin technical capacity can still launch.
Its value to cross-border teams is being neither a pure gateway nor a pure aggregator: because it holds regional acquiring capability itself, local approval rates and chargeback handling are more controllable than in setups that hand the transaction to another party. The limits are concrete — it operates in a handful of countries and the business must sit in those countries, and it solves "can we sell" while leaving local tax and invoicing compliance to the merchant.
3. Using cross-border aggregators correctly
EBANX and dLocal represent the other route: one API across several emerging markets, packaging local methods, local acquiring and local settlement. The value is speed and entity flexibility — you can test a market without incorporating in it.
To judge an aggregator, do not read the coverage list; ask three things: which methods are actually supported in each country, where settlement lands, and how refunds and chargebacks flow. The contract is usually vaguer on these than the website, so get specific per country, per method, per account.
There are two correct uses. The first is validation: use an aggregator to test three markets cheaply, see which one produces order volume and conversion worth pursuing, then decide where to incorporate and switch to a local acquirer. The second is the long tail: run local acquirers in core markets and let an aggregator hold the remaining countries, instead of building an entity and account for every small market.
The wrong use is treating it as the long-term backbone of a core market: the moment local depth requirements arrive — instalments, cash networks, local disputes, invoice coordination — the aggregator's boundary shows, and by then your architecture has been designed around "one API".
4. Tax IDs, invoicing and contractual liability
4.1 Tax IDs are a hard threshold, not supplementary material
Brazil uses CPF for individuals and CNPJ for companies; Mexico uses RFC with the CFDI electronic invoice system. These numbers are not accessories to collection but preconditions for opening an account and for a transaction to be legitimate: without a local tax ID a local acquirer generally cannot open an account for you, and with a tax ID but no way to issue a compliant invoice, transactions stall later at fulfilment and after-sales.
This is also why "a local acquirer lets overseas sellers without a local tax ID sell" needs careful reading — it usually means an aggregation or collection-on-behalf structure lets you receive money first, not that it obtains a tax ID for you. The compliance framework and country differences are in VAT and sales tax compliance; this article draws no tax conclusion.
4.2 Who invoices and who files has to be in the contract
The vaguest sentence in cross-border payments is "the platform handles tax". It may mean three entirely different arrangements: the platform only collects on your behalf, the platform issues invoices for you, or the platform sells to the consumer in its own name — the last being a genuine MoR structure.
Under those three arrangements the seller of record, the invoice header and the party liable for after-sales all differ. Before signing, confirm three points item by item: who issues the invoice, in whose name, and which entity carries the filing obligation; and who supplies the documentation when a refund or chargeback occurs. These are not legal niceties; they decide whether you can operate in the market beyond the first quarter.
4.3 How this differs from MoR: different problems being solved
A merchant-of-record model has the platform complete the sale and the invoicing in its own name, with the merchant stepping back on both compliance and customer relationship. It is an effective tool for testing a market quickly and a step in the opposite direction when the goal is your own brand and customer relationship. The boundaries of the model are in merchant-of-record platform models.
Local acquiring and MoR are not the same thing: the former gives you acquiring status and a local clearing channel while the seller remains you; the latter replaces you as the seller. Confusing the two produces contradictory decisions in entity planning.
5. Five blockers in execution
5.1 Entity: can your current entity collect
The first blocker is always the entity. Local acquirers require a local entity, tax ID and account; cross-border aggregators accept an offshore entity but with a discount on depth; ecosystem platforms essentially serve locally registered merchants. Confirm whether your existing entity can collect in that country before discussing anything else.
5.2 Instalments: funding burden and chargeback liability
In Brazil, instalments must be offered, and they redistribute both money and risk: who funds the deferred amount, when funds actually arrive, and who absorbs consumer default or a chargeback. Those clauses matter far more than the rate card. Treat the funding burden of instalments as a standalone cost inside the cash-flow model.
5.3 Refund paths: vouchers and cash are not card refunds
Boleto is a voucher, OXXO is a cash network and Pix is an instant transfer. Their refund paths, documentary requirements and arrival times differ completely from card refunds. Building one "refund" button surfaces the gap on the first ticket. The four cancellation and refund cases need separate states and actions.
5.4 Reconciliation basis: three bases running in parallel
With several methods live, reconciliation faces card network reports, acquirer statements and offline or cash channel receipts at once, with different fields and different time bases. Decide which document is the basis, treat the others as verification, then classify the differences and handle each class; the method is in reconciliation and statement download operations.
5.5 FX and currency controls: does the money get out
The last blocker is the easiest to overlook: once local currency settles into a local account, how it converts into usable funds, which documents are needed and which channel it can take vary widely, and in some markets the currency regime turns moving money out into a project of its own. When ranking markets, put FX and the currency path in the decision table next to payment methods.
6. Go-live order
- Set the entity and market priority first. Rank two or three markets and decide which one justifies an entity.
- Then choose the route. Consider local acquirers for core markets; use cross-border aggregators for validation and the long tail.
- Then fix the method mix and instalments. Rank methods by target customer base, and design funding and risk for instalments separately as a Brazilian requirement.
- Then build the asynchronous and refund chains. Pending states, timeout closure, settlement confirmation, idempotency and refund documentation, validated item by item.
- Then reconciliation and difference handling. Fix the basis, the classification and the owner of each difference type.
- Optimise last. Retries, routing between channels and fee auditing are ongoing work after launch.
7. Four common misjudgments
- Reading a coverage list as a capability list. "Supported in 13 countries" does not mean usable in all of them; validate methods, settlement and refunds per country.
- Assuming the rate is the main cost. In Latin America, entity maintenance, instalment funding, FX and currency paths, and chargeback and refund operations often matter more than a rate difference.
- Replacing local acquiring status with an aggregator in a core market. It runs in the short term, and the architecture has to be rebuilt once local depth requirements arrive.
- Confusing MoR with local acquiring. The first replaces the seller; the second provides an acquiring channel, and the contractual liabilities are entirely different.
Source: 16IDC original. Supported methods, eligibility requirements, settlement and dispute terms for each acquirer and aggregator follow official documentation and commercial contract terms.