Compare the payment journey, not only the fee
| Method | Customer journey | Operational question |
|---|---|---|
| QRIS | Customer scans payment instructions using a supported payment app. | Can the customer complete the journey on the device they use? |
| Virtual account | Customer follows bank payment instructions using a provided reference or account number. | Is the reference unique, reusable or order-specific in your approved setup? |
| Wallet checkout | Customer follows the selected wallet’s supported authorization flow. | Are this wallet and transaction direction approved for your business? |
The exact journey depends on your provider and merchant configuration. Do not assume a virtual account is permanent or that a QR instruction is reusable. Confirm how the amount, payer and order reference are matched.
Use your actual orders to choose the first method
Review typical order amounts, mobile versus desktop use and the payment questions your customers already ask. If you have no existing data, test the approved checkout with a small set of realistic customer scenarios rather than guessing national preferences.
For a multi-method launch, label each option clearly. Keep payment states consistent across methods, while preserving the actual instructions and expiry rules of each route. An expired QR order and a delayed bank payment may require different support handling.
Check virtual account matching rules
- Which banks and references are available to this merchant?
- How are incorrect amounts and missing references handled?
- Can a customer pay after an order expires, and what happens next?
- Which records let finance reconcile an order to a confirmed payment?
PAYJN’s Indonesia page currently lists BNI, Mandiri, Permata, BRI and CIMB routes, with indicative ranges. Request the actual approved bank list and current limits before making customer-facing promises.
When evaluating the exception workflow, use the virtual account amount mismatch checklist to review underpayments, overpayments and separate payments for one invoice.
Keep wallet collection and payout coverage separate
A wallet can be a payout destination without being available for customer collection. In PAYJN’s published Indonesia coverage, DANA pay-in is not currently open for merchant onboarding, while DANA payouts are described separately. Check both directions before integrating or advertising a method.
Likewise, a customer’s ability to use a wallet to scan an approved QRIS instruction should not be described as a separate direct-wallet API integration. Explain the actual route your business offers.
Prepare a comparison brief for your provider
Send your company website, registration jurisdiction, business model, expected monthly IDR volume and average order amount. List the customer methods you want and whether you need payouts. Ask for separate fees, limits, settlement terms and exception responsibilities for each approved flow.
Then use the QRIS integration guide to prepare testing. Compare the full operating cost, including payment investigation and reconciliation work, rather than choosing on the headline rate alone.
Get a merchant-specific integration review
Share your website, target market, required methods and expected volume. Our team will review merchant fit and the proposed payment flow. Do not send API secrets or customer banking data in a first enquiry.
Discuss Indonesia integrationRelated integration guides
Method availability, transaction limits, fees and production access depend on the approved merchant setup. Operator references describe the payment ecosystem and do not imply a direct partnership.