dLocal Guide: Where Emerging-Market Local Acquiring Fits

dLocal Guide: Where Emerging-Market Local Acquiring Fits

dLocal is often read as an aggregator that covers a great many countries, and selection then collapses into comparing whose coverage list is longer. That reading usually breaks down about six months after go-live. The real value is bringing local payment methods and local settlement paths from several emerging markets into one account structure behind one interface, which cuts the organisational and engineering cost of finding a local acquirer market by market. What it does not remove is the delivery difference in each market. This guide follows the order in which you would actually integrate it: positioning and boundaries, onboarding and entity requirements, account structure and integration, capability coverage, fee composition, how it divides work with other options, who it fits, and the misreadings that keep coming back.

1. Where It Fits: One Interface Across Several Emerging Markets

1.1 The problem it solves

Payment structure in emerging markets looks very different from mature ones. In Latin America, card penetration and instalment habits are intertwined, and bank slip methods and instant transfer methods have long carried a large share of volume. In Africa, mobile wallets and telecom operator schemes are the primary channel in many countries. In Southeast Asia and South Asia, local wallets, bank redirects and QR-based methods each form their own systems. A team that has only operated in mature markets has the same first reaction: every country needs its own local acquirer, its own contract, its own technical integration, and its own reconciliation and refund process.

With one or two target markets that cost is manageable. Once the list reaches five or six, the organisational cost grows fast: each local acquirer has a different interface style, different state definitions, different settlement currencies and cadence, and the team ends up maintaining an ever-growing integration matrix. This is where this class of provider earns its place: it brings local payment methods and local settlement paths from several emerging markets under one interface and one account structure, so the team maintains a single integration path. dLocal sits exactly there, focused on local acquiring and payouts in emerging markets, connecting local payment methods across markets through a unified interface.

1.2 What it is not

Stating the boundaries first saves a lot of rework later.

First, it is not a local entity. It is a provider of acquiring and payout services, but the local entity, tax registration and invoicing obligations that apply when you enter a market do not disappear because you use it. This is especially visible in Latin America, where CPF and CNPJ in Brazil and RFC in Mexico are unavoidable prerequisites. For the route itself see the Cross-Border Seller Entity and Account Structure Guide.

Second, it is not a leaderboard entry where more countries means more capability. A coverage list says the provider has a connection to a local channel. It does not say what success rate, settlement timing and support responsiveness your specific business will get in that market.

Third, it is not a global acquiring platform. Multi-currency acquiring for mature markets, unified online and offline management, enterprise organisational structures and multi-entity settlement belong to a different product category. For the wider picture of regional methods start with the Local Payment Methods by Region Guide.

2. Onboarding and Entity Requirements

2.1 What onboarding actually looks at

Onboarding for emerging-market acquiring rests on the same core variables as mature markets: entity location, how explainable the business model is, how verifiable the website and product are, expected volume and category risk. The difference is sensitivity. Emerging markets weigh these variables more heavily, for two reasons. Local regulators pay closer attention to cross-border money movement, and category risk plus dispute handling behave more extremely on local payment methods than on cards.

When preparing material, the most underestimated item is business explainability. The reviewer has to judge what you sell, to whom, whether the refund policy is clear and whether a usable support channel exists, all from a page a third party can reach. If the site is only product images and a form, the number of back-and-forth rounds rises noticeably. The same is true in mature markets, but reviews in emerging markets lean more on manual judgement, so structured material matters more.

Another point is that the same material is not accepted equally everywhere. Some markets allow a foreign entity to contract directly, while others prefer to see a local entity or a local contact. If there is more than one target market, list at selection time which markets can use the existing entity and which require a local entity first, then decide the order of integration.

2.2 Local entities and tax IDs do not disappear

This is the point the article most wants to make, and it is the first entry in the misreadings section.

Using an aggregating acquirer changes which interface you collect through. It does not change which jurisdiction you owe tax and compliance obligations in. Many teams read onboarding an aggregator as outsourcing compliance, and only discover at the first tax filing or the first invoice request that the responsibility boundary is not what they assumed.

That boundary has to be written into the contract: who files tax, who issues invoices to end buyers, who carries the burden of evidence in a dispute, who executes refunds, and who responds to local regulatory enquiries. Leaving these open tends to surface at the busiest possible moment. For the overall tax framework see the VAT and Sales Tax Compliance Guide.

One related note: the merchant of record model is a completely different responsibility structure and is not a service an acquirer provides by default.

3. Integration and Account Structure

3.1 One interface, layered accounts

Structurally, this class of provider usually offers two directions: collecting, meaning money coming in from buyers, and paying out, meaning money going to local recipients. They share one authentication and webhook mechanism, but the business semantics are entirely different. Documentation often presents them side by side, yet in operations they must be accounted for and reconciled separately.

On account structure, the common shape is a main account with several business entities or merchant configurations underneath, each bound to different markets, currencies and payment methods. This matters for multi-market teams: it lets them separate transactions by business line and market under one set of credentials without building a separate integration per market. With a scheme such as dLocal, what to confirm is not merely whether several configurations can be created, but whether each can set payment methods independently and produce its own settlement report.

Note, however, that a clean account structure and a clean settlement path are two different things. Before integrating, draw the flow: where money enters from the buyer, which currencies it passes through, which market it lands in, how it settles into which of your accounts, and whether refunds return the same way or take another route. If that diagram cannot be drawn, reconciliation will break later.

3.2 Three things the server must get right

Whichever acquirer you integrate, the server has to get three things right: idempotency, the state machine and reconciliation.

Idempotency means the same creation request arriving twice must not produce two payments. Webhooks can be delivered more than once and networks retry after timeouts, so a creation endpoint without an idempotency key can end up with one order, several payments and one refund too many. For patterns see the Payment Order Number and Idempotency Design Guide.

The state machine means created, redirected, in progress, succeeded, failed, expired, refunding, refunded and partially refunded states must close properly. Local payment methods in emerging markets confirm asynchronously at a high rate: bank slip and cash network methods often return a final result only after some time, while QR and transfer methods can sit in an intermediate state for a long stretch. A poorly designed state machine produces a mass of long-lived pending orders that tie up both support and finance.

Reconciliation means your order records must match the provider settlement report line by line. Once several markets, currencies and payment methods stack up, inconsistent reconciliation rules become the most common source of operational incidents.

4. Core Capabilities and Market Coverage

4.1 Collecting and paying out are two directions

Many teams only need collecting and therefore overlook payout capability. But for cross-border businesses money in and money out are often two sides of the same thing: you need to pay suppliers, service providers, marketing partners or creators locally, and international wires are expensive, slow and a poor experience for the recipient.

Offering both collecting and payouts to local recipients is a common trait of this direction, and both lines share the same account and compliance framework, which has real value for teams that need localised money movement. The question to ask is not whether payouts are possible but who you pay, in what capacity, whether the recipient needs a local account, and where funds return if a payout fails.

The acquiring side has to be evaluated against a concrete method list. Do not look at the total number of supported methods. List the few methods buyers in each target market actually use, then confirm each one.

4.2 Coverage list versus delivery quality

This is the central judgement of the whole article.

A coverage list answers whether something exists. Delivery quality answers whether it works well. The same aggregator can vary enormously between countries, and the reasons are not hard to see: local payment methods sit on local channels, local banks and local clearing institutions, and the aggregator's relationship with each differs in depth; local support capacity differs; and where volume in a market is large the product is polished, while where it is small problems linger.

That makes the table below more useful than any coverage list. It splits what you need from what the provider offers into four columns and forces a concrete verification in each target market.

The verification column is the key. A coverage list can only come from commercial discussions, while delivery quality only comes from running real transactions yourself. Before signing, ask for a test environment and run real categories, real amount bands and real failure scenarios rather than reading documentation alone. For method see the Payment Gateway Sandbox Testing Guide.

5. Fee Structure and Real Cost

5.1 Fee components

Fees for aggregating acquirers are not one number but a set of components. Asking what the rate is usually produces no answer you can budget with.

Current rates and conditions belong to the official quote and the signed contract. Any percentage appearing in an article will go stale, and budgeting from old numbers is the most common error of all.

5.2 How to judge the real cost

Comparing headline rates side by side is the easiest mistake at this stage. The right method is to build a transaction mix that matches your business, with the same payment method share, the same market distribution and the same amount bands, then compare total cost and final received amount.

One dimension that is easily missed is that method coverage feeds back into conversion. Adding one more local method may raise conversion, and it may also add operational complexity and disputes. Comparing fees without conversion usually produces a biased conclusion. For success rate work see the Payment Success Rate Optimization Guide, and for comparison method see the Payment Gateway Rate Comparison.

One more reminder: multi-currency pricing and the choice of settlement currency noticeably affect real cost and cash flow. If the business spans several emerging markets, read the Multi-Currency Payment Account Guide separately and settle the currency path before negotiating price.

6. How It Divides Work With Other Options

6.1 Against regional local acquirers

The biggest competitor to an aggregator is not another aggregator but the option of finding a local acquirer in each market yourself.

A local acquirer is often deeper in a single market: it understands local risk preferences better, is more likely to hold high-performing channels, responds faster and settles more flexibly. The cost is that every new market repeats the cycle of selection, contracting, integration and reconciliation. So this is purely a cost structure question: if target markets concentrate in one or two, a local acquirer usually pays off better; if they are dispersed and each carries modest volume, the aggregator's marginal cost advantage shows up.

Within the same category there are options with different regional focus, such as EBANX, which started in Brazil with Latin America as its main market, and 2C2P, which started in Thailand with Southeast Asia as its main market. For the wider regional picture see the Latin America Payment Guide, the Africa Payment Guide and the Southeast Asia Payment Guide, each of which lays out mainstream methods and onboarding traits for its region.

6.2 Against global acquiring platforms

The other common option is a global acquiring platform. Its strengths are mature interfaces, complete documentation, full tooling and standardised multi-currency and multi-market support, which suits teams with engineering capacity that want payment logic under their own control.

The difference is local depth. Global platforms usually depend more on partner channels for local methods in emerging markets. The method list may be sufficient, but success rate and localised experience in a specific market may not match an aggregator that works the ground there. When evaluating this class, compare the market focus and settlement structure of Adyen, Nuvei and Rapyd side by side.

A pragmatic combination is to run main card volume and mature-market business on a global platform while filling emerging-market local methods with a localised aggregator. The cost of that combination is two reconciliation flows, two state machines and two dispute processes, which takes extra engineering to abstract. Whether it is worth it depends on the weight of emerging-market business in the overall picture.

For a provider-level comparison see the Cross-Border Payment Platform Comparison, and for a framework that selects by market and method see the Cross-Border Payment Selection Matrix.

7. Who It Fits and Who It Does Not

7.1 Good fit

First: teams whose target markets are dispersed across emerging markets with volume in each too small to justify a separate local acquirer. The value of an aggregator is most direct here, covering several markets with one contract and one integration path.

Second: teams that need to handle both acquiring and local payouts. In cross-border business money in and money out are two ends of the same flow, and solving both in one account structure lowers operational complexity considerably.

Third: teams in the market validation stage that have not decided where to invest heavily. Building a separate integration per market is the last thing to do at this stage. An aggregator lets the business run at modest organisational cost, and a deeper local option can be considered once a market proves out.

7.2 Weak fit

First: teams with the vast majority of revenue concentrated in one emerging market and volume already large. At that point the local acquirer's depth advantage and negotiating room usually beat the convenience of an aggregator.

Second: teams selling mainly into mature markets. The incremental gain from emerging-market local method coverage is small, and the extra integration and reconciliation complexity is not worth carrying for it.

Third: teams with very strong requirements on success rate and settlement timing that are unwilling to do the market-by-market verification up front. No provider will do that work for you, and without the capability or the appetite for it, the selection conclusion is likely built on a coverage list that says the wrong thing.

Fourth: teams treating full compliance outsourcing as the goal. An aggregator changes the interface, not the obligations, as noted earlier.

8. Rollout Notes and Common Misreadings

8.1 Rollout notes

The last point matters most. If the acquiring arrangement may change later, keep the payment layer thin at integration time and reduce coupling to a specific provider. For process and acceptance checklists see the Payment Gateway Migration Guide. If the business involves subscriptions or recurring charges, automatic charging conditions in emerging markets differ from mature ones, so assess separately rather than assuming that the ability to accept a payment implies the ability to renew it.

8.2 Common misreadings

The first misreading is treating an aggregator as a local entity. Its role is to connect several local channels behind one interface, not to replace your local entity and tax registration. Assuming that onboarding it gives you a local identity is one of the most common misjudgements at selection time.

The second misreading is treating the number of countries as coverage quality. The number is commercial material; quality comes out of real transactions. The same aggregator can perform very differently in two countries, so selection requires market-by-market verification.

The third misreading is treating a unified interface as a unified experience. A unified interface lowers your engineering cost. It does not change differences in checkout flow, failure reasons, refund paths and reconciliation rules across local methods. Treating them as variants of card payments is where things break most often in the first quarter after go-live.

Read the three points and this table together and a simple conclusion follows: the value of this class of provider is saving organisational cost, not saving decision cost. Decision cost, meaning whether each market actually works and how well, still has to be paid by you.

More acquiring and local payment options are listed under Payment, organised by acquiring capability, local method and market region.

Note: this article is based on public information and general provider mechanics. Current rates and onboarding conditions are subject to the provider official pages and the signed contract.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.