How to Switch QRIS Providers With Pending Payments

Keep each issued QRIS attempt tied to its original route

When switching QRIS payment providers, send eligible new payment attempts to the new route while continuing to verify, reconcile and resolve attempts already created on the old route. Save the originating provider and account with every attempt. Keep the old notification handler, authorised status lookup and operational support available for the outstanding cohort until you can account for its payment outcomes and subsequent obligations.

This runbook is for an operating business moving an order-specific QRIS checkout between providers or merchant accounts. Game and digital-goods teams can use it to review a migration before allowing it to affect live purchases. Begin with an approved business, product and collection flow on the proposed route. Have engineering, support and finance agree the transition together, including the handling of purchases already in progress.

A routing change applies to the creation of new instructions. A QR instruction already issued to a customer belongs to a particular payment attempt. Keep its original references intact throughout the migration. If a customer returns to that order after the switch, load the existing attempt from your records and determine its current status before offering another instruction. Give support visibility into which route owns the payment so it can investigate with the correct account.

The stages below are proposed merchant operating controls. Supplier documentation provides concrete examples of transaction identifiers, status enquiries, notifications and expiry. Your approved integration determines the actual fields, allowed actions and final-state rules.

Build an inventory before changing routing

Take a snapshot of the old route’s open attempts immediately before the switch, then keep updating that inventory as results arrive. Record a cutover time with its time zone and a routing configuration version. The snapshot gives the team an initial list to investigate. A continuing query catches a payment creation request that was already in flight when the snapshot was taken.

For each attempt, preserve the merchant order ID, an immutable internal attempt ID, provider transaction ID, provider account, environment, expected IDR amount, instruction expiry if available, creation time, last verified result and fulfilment state. Record which provider reference a status enquiry requires. Associate the payment result with that attempt even if the checkout, product session or routing configuration has since changed.

Also identify the operational dependencies outside the order database. List the callback endpoint and verification configuration, access to provider reports, the staff responsible for investigations, refund or adjustment procedures where approved, and how long each access remains available. Review the contract and technical permissions with the provider before a planned account closure. Give finance enough information to connect each receipt to its later report entry.

Midtrans’s QRIS reference illustrates a transaction record with an order ID, transaction ID, merchant ID, amount, currency and payment status. Its status API retrieves a particular transaction, using identifiers specified for that integration. Use those documents to frame questions for your provider, then build the inventory from your own approved schema. See the supplier references.

Agree how both routes will operate during the transition

Set separate controls for creating new attempts and processing existing ones. This lets you stop exposing a troubled route to new customers while retaining its recovery functions. Include these controls in the deployment review. Ask the on-call engineer to show how they can find an old attempt, verify a result and reach the support owner after the routing switch.

Run the switch in controlled stages

1. Complete acceptance testing on the new route

Confirm eligibility, credentials, amount handling, QR presentation and the documented verification procedure before live use. Test a successful payment and each supported failure or expiry path. Agree the source of truth for final status and who handles unresolved attempts. Use the QRIS integration checklist to review the underlying checkout requirements.

2. Make route selection a durable decision

Store the route with the attempt when allocating it. If concurrent requests can open the same order, protect the allocation so both requests find the same active attempt or follow an explicitly approved replacement policy. For a creation timeout, leave the route assignment available to the recovery worker. The worker needs to know where the request went even when it has no provider transaction ID yet.

3. Keep callback verification route-specific

Use a dedicated callback address or another documented, trustworthy way to select the appropriate verification configuration. Validate the message using that configuration before applying its contents. If several accounts share an endpoint, make their identifier mapping unambiguous. Keep credentials in the approved secret store and restrict operational access. Midtrans documents notification verification and handling for delayed or out-of-order events. Build your route mapping and tests around the contract of each actual integration.

4. Protect the shared order and fulfilment ledger

Old and new routes should feed a common order decision. Record each confirmed receipt against its own attempt, then apply the order’s payment-allocation and delivery controls. Two different providers can generate different valid payment events for the same customer purchase. A provider-specific event key alone leaves that purchase exposed to a second grant. Protect the order allocation and fulfilment operation against concurrent processing, and send an additional confirmed receipt to finance review.

5. Monitor the outstanding old-route cohort

Track unresolved attempt count, oldest unresolved age, failed verification, enquiry errors, confirmed-but-unfulfilled orders and unmatched report entries. Assign an owner and next action to each exception. Inspect the cohort independently of the new route’s checkout results so a quiet old route remains visible to the on-call team. Give support a customer-facing order status and a clear escalation path while investigation continues.

Hypothetical case with purchases spanning the switch

A digital-goods business schedules a switch at 15:00 WIB. At 14:58 it creates attempt A on the old route for an IDR 90,000 purchase. At 15:01 another customer opens a new purchase and receives attempt B on the new route. These times, references and amounts are illustrative. They establish a test sequence for the merchant’s team.

At 15:02 the old-route callback confirms A. The merchant verifies it under the original configuration, matches the amount and order, records the receipt and grants the purchased item once. At 15:03 the customer refreshes the earlier order page. The page reads the saved paid state and delivery result. The routing switch has left enough information for support to locate A and for finance to match its original report.

Now vary the test. Suppose A remains unresolved when the customer requests a new checkout. The merchant keeps the investigation linked to A and follows its agreed replacement policy. If the old provider confirms expiry and a replacement is allowed, create a separately referenced attempt on the current route. If both attempts later appear paid, preserve both receipts, check the authoritative evidence with each provider and open a finance exception. Keep the purchase-level delivery guard in force while the team resolves the extra receipt.

For an entitlement that cannot be delivered after payment confirmation, follow the business’s approved exception policy and the original provider’s available resolution process. The game checkout timeout guide explains the order-to-delivery review in more detail.

Test recovery and rollback before the release

• Old callback after deployment. Replay an authorised test notification for an old attempt through the new application release. It should still select the original verification configuration and reach the correct order.
• Two events at once. Run the old callback and a reconciliation worker concurrently. Confirm one receipt allocation and one delivery. Then test two distinct successful attempts against one purchase and verify the extra-receipt exception.
• Request still in flight. Switch the routing configuration while the old route’s creation request is awaiting a response. The recovery worker should retain the old route and the original request reference.
• New-route rollback. Disable new attempt creation on the new route after test attempts exist. Verify that its issued attempts remain queryable and its callbacks still work while future eligible checkouts use the chosen recovery route.
• Changed credentials or permissions. Test the agreed credential transition and account access expiry in the sandbox or another approved test process. Record the investigation and report-retrieval procedures your team will use during the transition.

Write rollback instructions in terms of new creation, outstanding attempts and operational access. A rollback adds another cohort to monitor because the new route may already own issued instructions. Keep both cohorts visible until their results and subsequent obligations are accounted for. Use the duplicate webhook guide when reviewing repeated delivery controls.

Use an explicit sign-off before retiring the old integration

Agree exit criteria before the switch. Engineering should reconcile the open-attempt inventory with the provider’s authoritative records, explain every unresolved item and confirm that delayed results have an owner and recovery path. Finance should account for receipts, relevant report entries, outstanding settlements and approved adjustments or refunds. Support should retain a way to trace a historic order and escalate it after normal checkout traffic has moved.

Confirm the provider’s access and data-retention arrangements against these obligations. Record who approved the retirement and the evidence they reviewed. An empty pending queue is one input to that decision. Receipt reporting and later customer or finance investigations can create continuing access needs, so give those needs their own sign-off.

If the old route offers an expire or cancel operation, establish the supported methods, valid states and response semantics before using it. Midtrans documents an expiry API and illustrates a response where the merchant cannot change the transaction state. After an uncertain expiry request, verify the original attempt through the agreed process. Keep the result and any later conflicting evidence available for investigation.

For a migration assessment, prepare the outstanding-attempt inventory, your test results, account-access requirements and the responsibilities you need each provider to accept. Review these alongside the Indonesia collection requirements. This gives your team a concrete operational basis for evaluating a proposed route.

Sources and verification date

Primary supplier documentation checked on 13 November 2026. The inventory, cohort monitoring, migration tests and sign-off plan are proposed merchant controls. Confirm actual capabilities and permissions for the approved provider and account.

• Midtrans. QRIS charge records and statuses.
• Midtrans. Transaction status enquiry.
• Midtrans. Notification authentication, delivery and ordering.
• Midtrans. Expiry operation and response examples.