Midtrans Guide: Local Acquiring for Indonesian Payment Methods

Midtrans Guide: Local Acquiring for Indonesian Payment Methods

The first move most teams make when entering Indonesia is connecting an international card channel and then waiting for orders. That move is not wrong, but it covers only part of the local payment structure. Indonesian checkout runs three parallel rails: bank virtual accounts, e-wallets and the national QR standard, with cards forming only part of one rail. Card-only integration rarely means receiving no money at all. What it usually means is a large share of buyers stopping on the checkout page, because local buyers do not habitually pay by card.

This guide follows the order in which you would actually integrate Midtrans and other Indonesian local acquirers: positioning and boundaries, onboarding and entity requirements, the two integration paths and what each costs you, how money moves on each local method, fee composition, how it divides work with other options, who it fits, and the misreadings that recur.

1. Positioning: A Local Indonesian Acquirer, Not a Global Platform

1.1 Three Parallel Rails Are the Real Structure

Reducing Indonesian payment structure to a single card penetration number is the most common error at selection time. The first rail is the bank virtual account: the buyer receives a dedicated account number at checkout, opens a banking app or an ATM, transfers the money, and the transaction only becomes real once funds arrive. The second rail is the e-wallet: the buyer confirms inside a wallet app, funded by wallet balance or a linked account. The third rail is QRIS, Indonesia national QR standard, which unifies the QR codes of different wallets and different banks into one format that can be scanned across apps, collapsing a fragmented scanning landscape into a single experience.

Cards certainly exist in Indonesia, but they sit alongside these three rails rather than replacing them. The same buyer may pay rent with a virtual account, order food with a wallet, scan QRIS at a convenience store and book a flight with a card. What you need to accept is the method that is most natural for local buyers, not the method your own team knows best.

What the three rails share is a confirmation mechanism that differs from cards. Cards run a two-stage authorisation and capture flow, and the authorisation result comes back inside the request. Virtual accounts, wallet redirects and QR payments carry an asynchronous component: the buyer pays after leaving your page, and your system has to wait for a back-end state change. That difference drives the integration choice, as section three explains.

1.2 What It Is Not

First, it is not a local entity. Midtrans is an Indonesian local acquiring platform offering two integration paths, hosted checkout and a core API, covering virtual accounts, e-wallets, the national QR standard, cards and convenience store payments. But the local entity, tax registration and invoicing obligations that apply when you operate in Indonesia do not disappear because you use it. For the wider structure see the Cross-Border Seller Entity and Account Structure Guide.

Second, it is not a multi-market aggregator. It solves the payment structure of one market. If you also sell into Thailand, Malaysia or the Philippines, you need either a different layer of solution or several local acquirers in parallel. For the regional picture read the Southeast Asia Payment Guide.

Third, it cannot decide for you which methods to enable. A method list is commercial material. What actually moves conversion is your buyer profile and order value mix. However complete the list is, conversion will not improve if the checkout page buries the most used method below the third screen.

2. Onboarding and Entity Requirements

2.1 What Onboarding Actually Looks At

Onboarding variables for local acquiring match 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. Indonesian local acquiring is more sensitive to cross-border money movement and category risk for two reasons. Local regulators watch cross-border flows more closely, and dispute handling on non-card methods differs from cards, often placing more of the evidence burden on the merchant.

The most underestimated item when preparing material is business explainability. The reviewer has to decide what you sell, to whom, whether the refund policy is clear and whether a support channel actually works, all from a page a third party can open. If the site is product images plus an order form, the number of back-and-forth rounds rises noticeably. This is not unique to Indonesia, but local review leans more on manual judgement, so structured material makes a large difference.

Another point is that category and delivery model must line up. Virtual goods, physical goods, subscription services and marketplace matching have different transaction structures and accept different evidence. If the page says physical goods while the order flow has no shipment trail and no return path, review tends to stall. Organising material as what you sell, how it is delivered and how it is refunded usually improves the pass rate.

2.2 Local Entities and Tax Registration Do Not Disappear

This is the point the guide most wants to make. Using a local acquiring platform changes which interface you collect through. It does not change which jurisdiction you owe tax and compliance obligations in. Many teams read onboarding a local acquirer as outsourcing compliance, then 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 answers local regulatory enquiries. Left unanswered, these seem harmless for a while and then surface all at once at the busiest moment. For the overall tax framework see the VAT and Sales Tax Compliance Guide, but the conclusion has to land on Indonesian rules specifically.

One related concept is often confused with this: the merchant of record model is a completely different responsibility structure that takes over the counterparty position toward buyers, and it is not the service an acquirer provides by default. When you see the two used interchangeably, do not follow that usage.

3. Integration Options and Account Structure

3.1 Hosted Checkout versus Core API

Midtrans offers two integration paths, and this is the second most important judgement in the whole guide.

Hosted checkout gives you a payment page. You pass order parameters, the buyer pays inside that page, and you receive the result. The advantages are speed to launch, method maintenance on the provider side and compliance detail handled for you. The cost is that page styling, method ordering and post-failure guidance are under provider control, leaving little room to tune things for your specific business.

The core API lets you render method selection in your own front end, call the provider to create a transaction, and then handle redirects, webhooks, timeouts, retries and state synchronisation yourself. The advantages are a controllable experience, method ordering driven by buyer profile, and failure reasons you can translate into plain language. The cost is far more work: you design the state machine, and you handle orders that hang in asynchronous states.

Neither path is good or bad in itself. Running on hosted checkout during validation is reasonable. Moving to the core API makes sense when conversion becomes a core metric and method ordering produces a measurable difference. Note that switching has its own cost, so if you plan to switch later, reserve an abstraction layer in the front end instead of scattering hosted checkout parameter assembly across business code.

3.2 Account Structure and Three Server-Side Basics

On account structure, the common shape is a main account with several merchant configurations underneath, each bound to a business line, currency and set of payment methods. 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. A clean account structure is not the same as a clean settlement path. Before integrating, draw the flow: where money enters from the buyer, which currencies it passes through, which account it lands in, how it settles, and whether refunds return the same way or take another route.

The server has to get three things right: idempotency, the state machine and reconciliation. Idempotency means the same creation request arriving twice must not create two payments, a scenario produced by duplicate webhooks and network retries. The state machine means created, awaiting payment, in progress, succeeded, failed, expired, refunding and refunded states must close properly. Asynchronous methods such as virtual accounts and QR payments routinely sit in intermediate states, so guessing from front-end polling does not work. Reconciliation means your order records must match the provider settlement report line by line, with rules fixed before integration starts.

For the operational detail of both, see the Payment Reconciliation and Bill Operations Guide and the Payment Refund and Settlement Operations Guide.

4. Core Capabilities and Method Coverage

4.1 Method List and Money Characteristics

For Indonesia, the useful evaluation is not counting methods but marking the money characteristics of each one. Those characteristics decide three things: how the state machine is designed, how support scripts are written, and how reconciliation rules are set.

Real-time methods return an authorisation result inside the request, so failures can be retried immediately, though disputes can still follow. Asynchronous methods return results late: the buyer may abandon midway, may pay much later, so orders need a long enough validity window and must match incoming funds by amount and account number. Methods that need an offline voucher require the buyer to pay at a physical location and receive proof, which means a separate verification or query flow rather than waiting on a webhook.

4.2 Methods and Integration Notes

The way to use the table is to mark the lead methods for your buyer profile first, then confirm the states and reconciliation rules for each. Do not select on how many methods are supported, since that is only a commercial number. For general success rate work see the Payment Success Rate Optimization Guide, and for regional differences see the Local Payment Methods by Region Guide.

5. Fee Structure and Real Cost

5.1 Fee Components

Local acquiring fees are not one number but a set of components. Asking what the rate is usually yields an answer you cannot budget with.

Current rates and conditions belong to the official quote and the signed contract. Any percentage appearing in an article goes stale, and budgeting from old numbers is the easiest error to make.

5.2 Judging the Real Cost

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

One easily missed dimension is that method coverage feeds back into conversion. Adding one local method may lift conversion noticeably, or it may only add another state and reconciliation path to maintain. Comparing fees without conversion tends to produce a biased conclusion.

A final reminder: settlement currency choice noticeably affects cash flow. If the business spans several Southeast Asian markets, settle the currency path before negotiating price, which is worth more than arguing over a few basis points.

6. How It Divides Work With Other Options

6.1 Against Regional Aggregators

The competitor to a regional aggregator is not another aggregator but the option of using one local acquirer for one market. A local acquirer is often deeper in a single market: it understands local risk preferences better, covers methods more completely, responds faster and settles more flexibly. The cost is that every new market repeats selection, contracting, integration and reconciliation.

So this is a cost structure question. If target markets concentrate in one or two and volume is large, a local acquirer usually wins. If they are dispersed with modest volume each, the aggregator marginal cost advantage appears. For the aggregator view read the 2C2P Guide, and compare market focus and account structure across 2C2P, Xendit and dLocal.

6.2 Against Global Acquiring Platforms

The other common option is a global acquiring platform, whose strengths are mature interfaces, complete documentation, full tooling and standardised multi-currency support. It 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 a market like Indonesia: the method list may be sufficient, but success rate and localised experience may not match an acquirer that works the ground there. When evaluating, compare the local method list and settlement structure of Adyen and Stripe side by side.

A pragmatic combination is to run main card volume and mature-market business on a global platform while filling Indonesian local methods with a local acquirer. The cost 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 Indonesian business in the overall picture.

7. Who It Fits and Who It Does Not

7.1 Good Fit

First: teams where Indonesia is a primary or important market and order volume already justifies a dedicated local acquirer. The conversion difference from local method coverage usually dwarfs the integration and maintenance cost.

Second: teams whose buyers are mostly local consumers with modest order values and high order frequency. Checkout failure hurts these businesses most directly, so local coverage is close to revenue.

Third: teams willing to invest engineering in the state machine and reconciliation. Local acquiring hands you the asynchronous logic, and without the capacity to handle hanging orders and reconciliation gaps, operations get dragged down.

7.2 Weak Fit

First: teams treating Indonesia as a test market with very low volume and most buyers abroad. Integration cost cannot be amortised, so a general solution that already covers you is more sensible for a while.

Second: teams hoping one interface solves all of Southeast Asia. A local acquirer is a single-market solution, and multi-market needs an aggregator or several acquirers in parallel.

Third: teams treating full compliance outsourcing as the goal. An acquiring platform changes the interface, not the obligations, as noted earlier.

Fourth: teams with no server-side engineering capacity that expect to go live by editing a few settings. Hosted checkout can carry you for a while, but the core API work cannot be avoided once conversion becomes the target.

8. Rollout Notes and Common Misreadings

8.1 Rollout Notes

8.2 Common Misreadings

The first misreading is assuming that integrating cards means integrating Indonesia. Cards are only one method there, and virtual accounts, e-wallets and QR payments carry a large share of local volume. Card-only integration will not stop money entirely, but it will lose a large number of orders that could have completed.

The second misreading is treating a virtual account as an ordinary bank transfer. A virtual account is asynchronous: the buyer may pay immediately, may pay hours later, or may never pay. The system needs a long enough validity window, must match funds by amount and account number, and must auto-close expired orders. Treating it as a synchronous submit-and-succeed flow produces a mass of shipped orders with no money received.

The third misreading is treating the number of methods as capability. A method list is commercial material. What matters is which few methods your buyers actually use and whether those methods close the loop on experience and reconciliation in your system.

If you are working on Indonesian payment selection, use this guide as a checklist: first confirm how your buyers actually pay, then check whether the local acquirer can hand you the money result, the refund path and the reconciliation rules for those methods completely. For the wider regional judgement, continue from the Payment category page.

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