KKI on QRIS: What Merchant Systems Must Handle

Bank Indonesia and ASPI launched Kartu Kredit Indonesia for the retail segment on 17 August 2026. In its first phase it is a digital card that acts as a funding source for QRIS. KKI uses existing QRIS acceptance. Confirm supported modes and any onboarding or contract requirements with your acquirer. For a business owner, start by asking the payment provider to confirm KKI support, fees, transaction limits, and refund procedures.

The checks below focus on those operational decisions.

What exactly launched on 17 August?

KKI is a deferred-payment instrument processed on domestic rails instead of an international card network. Bank Indonesia and the national payment-system association, ASPI introduced it on 17 August 2026 for the general retail segment.

The first phase is deliberately narrow:

• Digital card only. No plastic yet. Physical cards and online-payment support are planned for later phases.
• QRIS is the acceptance rail. It works across QRIS MPM (merchant-presented QR), QRIS CPM (customer-presented QR), and QRIS TAP (contactless payment).
• Eight issuers at launch. Seven first movers — BCA, Bank Mandiri, BNI, BRI, CIMB Niaga, Permata Bank, and Bank Mega — plus BSI as a next mover, with more payment service providers to follow.
• Rp10 million per transaction, with merchant fees quoted at 0% to 0.7% and an interest ceiling of 1.75% per month or 21% per year.

Scale matters here. QRIS reached 65.77 million users and 44.86 million merchants, 96.68% of them MSMEs, with 12.55 billion transactions worth Rp1.12 quadrillion in the first half of 2026 — up 93.92% year on year according to Bank Indonesia figures published on 17 August 2026. A change to what can fund a QRIS payment is a change that reaches almost every payment integration in the country.

KKI holders can also pay abroad through QRIS Cross Border in partner countries. That is an outbound story for travellers, not a new inbound scheme for Indonesian merchants — if you serve foreign guests, your existing cross-border QRIS arrangement with your acquirer is what governs that, and it is unchanged.

Why does a funding source matter to a merchant at all?

QRIS was designed to keep two things apart: how a customer funds a payment, and how a merchant accepts one. The merchant integration binds to the acceptance side only.

The acceptance interface does not require a new QR format. Confirm the QR payload, callback contract, and supported payment modes with your acquirer, the provider that handles merchant transactions. The team still needs to review amount limits, issuer mapping, and refunds in the existing system.

What is not the same is the distribution of what arrives. A payment method that used to be capped by whatever sat in someone's wallet balance is now capped by a credit line.

What breaks when tickets get bigger?

Systems built during the era of small QRIS payments carry assumptions nobody wrote down. Those assumptions are where this shows up.

The regulatory ceiling is Rp10,000,000 per transaction under PADG No. 3 of 2025, dated 19 February 2025, and KKI carries the same per-transaction figure. Issuers may set lower daily and monthly limits of their own. Rp10 million is the regulatory ceiling, not a duty to accept every payment at that amount. Provider limits and your own risk policy may be lower; make them explicit and reviewable.

Go looking for these:

• Amount caps below Rp10 million. Often a constant from a launch two years ago that nobody revisited. A hard rejection at Rp2 million now declines real money.
• QR expiry that is too short. Fifteen seconds is fine for a bakery. It is not fine for a Rp6 million purchase where the customer reads the amount twice before scanning.
• Velocity and fraud rules tuned for small tickets. A rule that flags anything above the 99th percentile of last year's amounts will start flagging ordinary sales.
• Invoice splitting workarounds. Some systems split a large bill into several QRIS payments because "QRIS is for small amounts." That workaround now produces multiple partial settlements to reconcile for no reason.
• Settlement float assumptions. A larger average ticket changes the cash-flow gap between sale and settlement, which matters more for a hotel or a contractor than for a warung.

Ask the team to inspect amount limits and related rules in code and configuration. Match each limit to provider requirements and the business's risk policy.

Will unknown issuer codes break your reconciliation?

This is the failure I would bet on. The issuer list is explicitly phased — seven first movers, then BSI, then other qualified providers over time. Any code that treats issuer identifiers as a closed set will eventually meet a value it has never seen.

The pattern to avoid:

// Brittle: a new issuer becomes an exception in production.
const ISSUERS = ["BCA", "MANDIRI", "BNI", "BRI"] as const;
if (!ISSUERS.includes(tx.issuer)) throw new Error("unknown issuer");

An unfamiliar issuer code does not itself invalidate a transaction confirmed by an authenticated provider message. Still verify signatures, amounts, order identity, and payment status. Store the raw string, record that it was unrecognised, and continue. The same applies to the funding-source field, where a value meaning credit is new in a field that previously only carried balance or debit.

// Tolerant: unknown values are data, not errors.
const known = ISSUER_LABELS[tx.issuer];
if (!known) logger.info({ issuer: tx.issuer }, "unmapped issuer code");
return { ...tx, issuerLabel: known ?? tx.issuer };

Rejecting an unrecognised value in a payment path converts a cosmetic gap in a lookup table into lost revenue. Same reasoning as idempotency keys in payment APIs: handle unfamiliar descriptive values without weakening signature, amount, order, or status validation, and prevent duplicate processing.

What about refunds and disputes?

Here I will describe questions rather than answers, because the honest position is that the operational detail differs by acquirer.

QRIS refunds have always been merchant-initiated and processed through the acquirer. Credit introduces a cardholder with a monthly statement, an issuing bank, and a consumer-protection relationship that a topped-up wallet does not have. Do not assume the two behave identically.

Put these to your acquirer in writing before your first large KKI-funded sale:

1. What is the refund window for a KKI-funded QRIS transaction, and does it differ from a wallet-funded one?
2. Are partial refunds supported, and do they settle on the same schedule?
3. Who bears the merchant fee on a refunded transaction?
4. If a cardholder disputes a charge with their issuer, what is the merchant's notification path and evidence requirement?
5. Which field in the settlement file identifies the funding source, and is it present in the real-time callback as well as the end-of-day file?

Question five is the one that decides whether you can even measure this. If the funding source only appears in the daily file, your live dashboards cannot separate KKI volume from wallet volume, and you will be reconciling blind.

How should you check merchant fees?

Not the logic, only the inputs. Merchant discount rate (MDR) is the transaction fee charged to a merchant. Fees for KKI-funded QRIS are quoted in the same 0%–0.7% band as the wider QRIS structure, and the tiering that takes effect on 1 October 2026 applies on top: MDR 0% for transactions up to Rp100,000 across all merchant categories, and up to Rp500,000 for micro merchants, as confirmed in BI’s official announcement. Zero MDR does not automatically remove gateway or other service fees; reconcile net amounts against provider reports.

If you already handle fees as a function of merchant category and transaction value rather than a fixed percentage, KKI adds nothing new. If you do not, the fee-logic work is the same work described in the October MDR changes, and it is now overdue rather than upcoming.

One rule survives every fee change: store gross amount, fee, and net amount as three separate fields, and reconcile on net. Recalculating historical fees with today’s rate table can produce mismatches; retain the applicable rate version.

A test matrix you can run this week

You cannot test KKI end to end without a KKI card. You can test everything on your side that a KKI transaction will touch.

These eight cases help check amount limits, issuer codes, and fees before transaction volume increases. Record the results and repeat affected cases whenever provider configuration changes.

What this actually asks of you

Start by confirming the provider's supported acceptance modes and the assumptions already built into your system.

But a payment method that was quietly bounded by wallet balances is now bounded by credit limits, and every assumption your code made about "QRIS means small" is now a defect waiting for the right customer. Find the constants. Loosen the enums. Ask your acquirer the refund questions and keep the answers.

Keep the provider's written refund answers and the test results with the integration records.