Copy page

QR Code

QRIS / QR Code

QRIS (Quick Response Code Indonesian Standard), also documented here as QR Code, is Indonesia's standardized QR payment system. Brick QRIS / QR Code is a Receive Money payment flow for businesses that need to accept QR-based customer payments through static or dynamic QR codes.

Use Brick QRIS / QR Code when your business needs QR payment collection for checkout, point-of-sale, invoices, counters, marketplaces, platforms, or other payment aggregation workflows. Brick sends status updates through callbacks and provides status APIs so your system can reconcile customer payments.

What You Can Do With QRIS / QR Code

• Create dynamic QR codes with predefined payment amounts.
• Use static QR codes for reusable merchant payment acceptance.
• Track QRIS payment status across processing, paid, completed, expired, and cancelled states.
• Receive callback notifications when transaction status changes.
• Add optional customer information to QR Code request payloads when the feature is enabled for your account.

Transaction Limits & Settlement Time

QRIS / QR Code supports payments ranging from IDR 1,000 to IDR 10,000,000 per transaction.

Settlement Time: Refers to the time it takes for funds to appear in your Brick account balance after the customer completes a QR Code payment.

QR Code Types

Brick supports two types of QR Code:

1. Dynamic QR Code

• Contains a predefined amount set at the time of generation.
• Used for point-of-sale systems, e-commerce checkout, and time-sensitive billing.
• Can only be used once—QR code expires after payment or timeout.
• Requires API integration to generate in real time.

Common reasons to use Dynamic QR Code:

• Reduces manual errors
• Enables order-based payment tracking

🚧 Dynamic QR Code is generated via API only.

2. Static QR Codes

• A reusable QR code that allows multiple payments with variable amounts.
• Users scan the same code and enter their desired payment amount.
• Generated once via the Brick dashboard.
• Static QR codes never expire.

Use cases:

• Donations
• Physical store counters
• General-purpose or open-ended payments

QR Code Transaction Statuses

QR Code transactions go through several statuses throughout their lifecycle:

---

Customer Information Parameter

Brick now supports an optional customerInformation object in the QR Code request payload. This parameter allows clients to attach payer identification details to a QR Code transaction, making it easier to trace and verify who made a specific payment.

Parameter Structure

Code
"customerInformation": {
  "customerName": "Customer QR Code",
  "issuerName": "OTTOCASH"
}

Field Descriptions

Use Case

This feature is useful for clients who need to match and verify which payer a QR Code transaction originated from. By including customerInformation in the request, you can:

• Cross-reference incoming QR Code payments with your own customer database.
• Identify the issuer/wallet provider used during payment.
• Improve reconciliation accuracy in multi-customer or high-volume environments.

Example Scenario

A platform processes QR Code payments on behalf of multiple end-users. By passing customerInformation, the platform can link each incoming payment to the specific customer who initiated it — even before the callback is received — and reconcile records more reliably.

How to Enable This Feature

🔔 This is an optional add-on feature and is not enabled by default.

If you are interested in using the customerInformation parameter, please contact the Brick Business Team for further information and activation.