Payment Gateway in Indonesia: How QRIS, Virtual Accounts and E-Wallets Fit Together

If you sell online in Indonesia, “add a payment gateway” sounds like one task. In practice it means choosing between several payment methods, each with its own rules, fees and ways of failing. This guide explains how QRIS, virtual accounts and e-wallets differ, what changed in QRIS fees on 1 October 2026, and what to check before you integrate.

It also uses a research project as a lens. Komodoplex Labs, the technical partner we work with on Systems & Technology projects, is prototyping U-APAC PG, a unified Asia-Pacific payment gateway that starts with Indonesian payment rails. Its page labels it a prototype and “Coming Soon”, so read it as a way to understand the problem, not as a product you can sign up for.

The three payment methods: QRIS, virtual account and e-wallet

QRIS is Bank Indonesia’s national standard for payment QR codes. According to Bank Indonesia (BI), it was developed by the payment industry together with the central bank. Its main point is interoperability: the payment app of any licensed provider can pay at any QRIS merchant, and a merchant only needs an account with one QRIS provider. BI’s page also states a cap of Rp10,000,000 per QRIS transaction. For Bali businesses, BI adds that foreign visitors can scan QRIS with their home-country payment apps while the merchant receives rupiah.

A virtual account (VA) is a bank account number generated for a specific customer or order. The customer pays by bank transfer to that number, and the bank or gateway matches the payment to the order automatically. In our view VAs suit larger, invoice-style payments and customers who prefer bank transfers. BI has also published a national open API payment standard, SNAP, developed with payment-industry representatives and being implemented gradually. Komodoplex describes a VA flow on its Stories page for an admissions system at ITH: multi-bank VAs through Bank BTN and Bank Mandiri, where a settled payment triggers webhook validation and then account provisioning. That page describes capabilities and publishes no measured results.

An e-wallet is the app a customer pays from, such as GoPay, OVO, DANA or ShopeePay. This overlaps with QRIS, which confuses many owners: a wallet app can pay a QRIS code, but gateways also offer wallets as separate checkout options on a website. So “QRIS or e-wallet?” is often the wrong question. A better one is which methods your customers actually use at checkout.

What changed in QRIS fees on 1 October 2026

QRIS has a merchant discount rate (MDR), the fee the merchant pays. BI says the MDR is set by BI according to merchant category and transaction value, is borne by the merchant and may not be charged to consumers.

On 17 August 2026 BI announced an expansion that took effect on 1 October 2026: the 0% MDR now covers all merchant categories for transactions up to Rp100,000. The existing 0% for micro businesses on transactions up to Rp500,000 continues. Above those thresholds, BI’s MDR page lists 0.3% for micro businesses above Rp500,000 and 0.7% for small, medium and large businesses. That table says it applies from 15 March 2025 and predates the expansion, so check BI’s current figures before you budget.

MDR may not be your whole cost, because a gateway or bank can charge its own fees, so ask for the full cost per payment method in writing.

Why one integration is rarely the whole story

Look at how a single gateway documents its channels. Midtrans’s integration documentation, which we read on 11 October 2026, has separate pages for BCA, Permata, BNI, BRI and CIMB virtual accounts, Mandiri Bill Payment, GoPay and QRIS, ShopeePay and QRIS, Indomaret, Alfamart, Kredivo, DANA and OVO, among others. That is fragmentation inside one provider.

It is also the problem the U-APAC PG page describes: each country runs its own clearing networks and regulations, and engineering teams struggle to maintain many gateway SDKs and reconciliation formats. Komodoplex’s research direction is a unified API layer over several settlement rails, starting with Indonesia and moving across borders only once that foundation is verified. BI’s QRIS Antarnegara page shows why the direction is plausible: it lists QRIS use in Thailand, Malaysia, Singapore, Japan, South Korea and China, and names local QR standards such as PromptPay in Thailand and DuitNow QR in Malaysia.

A payment is a state machine, not a yes or no

U-APAC PG says its prototype is validating transaction state machines. The phrase describes the most common integration mistake: treating a payment as either paid or not paid. Midtrans’s documentation lists statuses including pending, settlement, capture, deny, cancel, expire, failure, refund and partial refund. Its guidance for merchants is a good pattern for any gateway:

• Verify every notification. Midtrans signs each one with a signature key made by hashing the order ID, status code, gross amount and your server key with SHA512, and says to ignore a notification that does not match.
• Do not trust the browser. Its docs note that front-end callback data can be modified by the user, so confirm the status through the API.
• Expect duplicates. In rare cases it may send several notifications for one event, so handle them idempotently, using the order ID as the key.
• Expect delay. If a notification does not arrive, check the status through the API.
• Check more than one field before delivering. Look for status code 200, a transaction status of settlement (or capture for cards) and, where present, a fraud status of accept.

Komodoplex’s engineering post on admission spikes treats duplicate payment webhooks as expected too.

Should you build your own payment gateway?

Almost certainly not, and that is not what the lab project asks you to do. BI licenses payment service providers (PJP) by category. Its licensing page lists activities including administering sources of funds, payment initiation and acquiring services, and remittance, and licence categories I and II include payment initiation and acquiring. BI’s e-licensing page for non-bank institutions also lists payment gateway, e-wallet and e-money operators among its licensed categories. Whether a given design counts as a regulated activity is a legal question, so ask a lawyer, and use a provider that can tell you which licence it holds.

U-APAC PG is architecture research. Nothing on its page says it is a live or licensed payment service, and we are not presenting it as one.

A checklist before you choose or integrate

• Licence: which BI licence does the provider hold, and for what activity?
• Methods: QRIS, the VAs from the banks your customers use and, for consumer sales, the main wallets.
• Total cost: MDR plus provider fees for each method, in writing.
• Settlement: when money reaches your account, and how expired or failed payments are handled.
• Notifications: signed, retried and safe to receive twice.
• Refunds and reconciliation: can you refund part of a payment, and can finance export a report that matches your orders?
• Data: what customer data you store, and how it fits Indonesia’s PDP Law.
• Tracking: whether you can measure payments as events, as in our guide to tracking enquiries in GA4.

How we can help

SodraTech scopes websites, web applications and internal systems, and works with Komodoplex where engineering is needed, as our post on the SodraTech and Komodoplex partnership explains. Labs is Komodoplex’s independent R&D space with no client commitments, so U-APAC PG is not something we offer. If you are adding online payments to a website or system, tell us how your customers pay today and where it breaks, and we will write that into requirements before anyone builds. Two related guides cover choosing a booking system and building trust on a task platform. When you are ready, tell us about your business.