1. Separate a local method from a service promise
QRIS is Indonesia's national QR payment standard. A virtual account gives a customer bank payment instructions associated with a reference or account identifier. These are different payment journeys, not interchangeable labels for the same integration.
The market's payment options are not a list of methods automatically available through PAYJN. Confirm the specific method, merchant eligibility, limits and customer experience for your proposed setup.
For the QRIS standard itself, see Bank Indonesia's QRIS overview. This reference describes the national standard, not PAYJN's authorization or coverage.
2. Design the mobile payment journey first
- Document where the customer sees payment instructions, the amount, the currency and any expiry time.
- Test the supported same-device journey. A QR image alone may not explain what a customer should do when their banking application is on the same phone.
- Make pending, expired and completed states understandable. A return to your website is not by itself proof of a successful payment.
- Keep the merchant order reference available to customer support without exposing credentials or private customer banking details.
3. Make IDR order handling explicit
Agree the amount format and currency fields in the current API documentation. Do not infer decimal handling from a marketing example. Store your own order reference alongside the reference returned by the payment service.
During testing, cover repeated submissions, expired instructions, interrupted requests and delayed status notifications. Agree which source determines the final order state before your application credits a customer or fulfils an order.
4. Review collections and payouts separately
If you need both pay-in and payouts, confirm both explicitly. Collection availability does not guarantee that the same bank, wallet or customer type is supported as a payout destination.
- For pay-in: payment instructions, confirmation, expiry and reconciliation.
- For payouts: beneficiary requirements, submission rules, funding needs and rejected-payment handling.
- For both: approved business model, transaction limits, fees, settlement arrangements and the escalation path for exceptions.
5. Agree the operating terms before launch
Request a written, merchant-specific coverage summary rather than relying on a headline about speed or stability. Ask who owns each investigation, which references support will need and how you will receive updates during an incident.
Use a launch checklist with your technical, finance and support teams. Decide which tests must pass and who signs off on the transition to production. Do not substitute a general uptime claim for a documented operating process.
Your first Indonesia enquiry
Send your company website and jurisdiction, business model, expected monthly IDR volume, average transaction size, preferred methods and pay-in or payout requirements. This gives the team enough context for an initial assessment without sending confidential customer data.
Explore PAYJN's Indonesia payment page or prepare an Indonesia merchant enquiry.