Static and Dynamic Payments
Static and Dynamic Payments
PayCools acquiring payment methods can be divided into static and dynamic payments based on when the payment information is generated and whether the amount is fixed when the order is created. These forms are not limited to QR codes: static bills (virtual accounts / payment references) and fixed payment links are also static payments, while dynamic QR codes, dynamic bills, and payment information returned in real time when an order is created are dynamic payments. The right form depends on your business scenario, reconciliation requirements, and how users pay.
What Is a Static Payment?
A static payment is a set of payment information that a merchant creates in advance and can reuse for a long time (a collection QR code, virtual account, payment reference, or fixed link). This information is not tied to a specific order.
- Generation: Generated once in advance and reusable for a long time.
- Amount: Usually not fixed in the payment information; the user enters it when paying, or confirms it based on a bill.
- Order association: Not bound one-to-one to an order; it must be matched using identifiers such as remarks, store, table, room number, or payment reference.
- Reconciliation: Received funds must be matched to your order system using identifiers, which requires more reconciliation effort.
Common static payment forms include:
- Static QR code: Store collection codes, table / room codes, donation codes, and similar codes that are displayed for a long time and can be scanned repeatedly.
- Static bill / virtual account: A virtual account or payment reference assigned to the same user or a fixed purpose, which the user pays through bank transfer, convenience stores, or other offline channels (see Bill Payment).
- Fixed payment link: A long-term payment link with a variable amount or an amount entered by the user.
Static payments are suitable for physical stores, long-term fixed collection, donations, and utility bill payments, especially when users need to pay repeatedly at different times and through different channels.
What Is a Dynamic Payment?
A dynamic payment is payment information that the system generates in real time for each order and binds one-to-one to that order.
- Generation: Generated in real time for each order and usually time-limited; it expires if not paid on time.
- Amount: Determined when the order is created and written into the payment information, so the user does not need to enter the amount.
- Order association: Bound one-to-one to the order number (such as
mchOrderId), so payment results can be mapped precisely to the order. - Reconciliation: Payment result notifications correspond one-to-one to orders, making reconciliation clear.
Common dynamic payment forms include:
- Dynamic QR code: A unique QR code is generated for each order; the user scans it, confirms the amount, and pays.
- Dynamic bill: A dedicated virtual account or payment reference is generated for each order.
- Dynamic payment link: A direct channel payment link that opens a web page for login and payment; some links can open an app for payment.
Dynamic payments are suitable for e-commerce checkout, self-service ordering and kiosks, bill collection, and PC QR payments, especially when each order has a different amount and must be reconciled strictly by order.
Comparison
| Dimension | Static Payment | Dynamic Payment |
|---|---|---|
| Payment information generation | Generated once in advance and reused long-term | Generated in real time for each order |
| Bound to an order | No; must be matched using identifiers | Yes; one-to-one with the order |
| How the amount is determined | Entered by the user or confirmed from a bill | Determined when the order is created and written into the payment information |
| Reusability | Reusable | One-time; usually expires after a timeout |
| Reconciliation | Match by remarks / store / reference; more difficult | Match precisely by order number; clear |
| Payment result notification | Must be matched to an order using identifiers | The order number is returned directly in the notification |
| Validity | Long-term | Time-limited; expires after a timeout |
| Typical forms | Static QR code, static bill / virtual account, fixed payment link | Dynamic QR code, dynamic bill, dynamic payment link |
| Typical scenarios | Stores, donations, offline bill payments, long-term fixed collection | E-commerce checkout, kiosks, bill collection, PC QR payment |
| Common integration | Static QR payment, bill payment | Direct API, checkout mode, dynamic QR payment |
Static Payment Flow
Create a reusable static code, VA, payment reference, or link in advance.
Post it in-store, or send the link or account details to the user.
The user scans the code or follows the payment instructions.
The user enters or confirms the amount to pay.
The user chooses a payment method and completes the payment.
PayCools sends the payment result to the merchant asynchronously.
The merchant matches the payment by remark, reference, or store ID.
Dynamic Payment Flow
Order Number and Transaction ID (Reconciliation and Callbacks)
Payment creation and callbacks involve two identifiers: the merchant order number (mchOrderId) and the transaction ID (transactionId). They serve different purposes and must be used separately during reconciliation.
| Identifier | Meaning | Description |
|---|---|---|
mchOrderId | Merchant order number | Passed by the merchant when creating a payment (including static payments); the payment result callback returns it unchanged so the merchant can link it to its own order / bill. |
transactionId | Transaction ID | A unique serial number generated by PayCools for each transaction; each transaction under the same merchant order has a different ID. |
Static Payments: One Order Number May Map to Multiple Transactions
Static payment information can be paid multiple times (for example, the same virtual account / payment reference receives multiple payments at different times). The mchOrderId passed by the merchant when creating the static payment is included in each payment callback, but each payment has its own transactionId, and they are all different.
- Callback granularity: Callbacks are sent per transaction and include both the merchant's
mchOrderIdand the transaction'stransactionId. - Reconciliation advice: Use
transactionIdto distinguish each received payment and avoid treating multiple payments under the same order number as one. - Business linkage: Then use
mchOrderIdto link the payment to your bill / user.
Dynamic Payments: One Order Usually Maps to One Transaction
Dynamic payments are generated in real time for each order, so usually one order maps to one transaction. mchOrderId and transactionId correspond one-to-one, making reconciliation clear.
Callback delivery and retries follow the unified rules. See General Payment Rules · Callback Notification Rules.
How to Choose
| Business Characteristic | Recommended Form |
|---|---|
| Physical stores, long-term fixed collection | Static payment |
| Users need to pay repeatedly at different times and through different channels | Static payment |
| Bill / utility payments where the user determines the amount | Static payment |
| Each order has a different amount and must be reconciled strictly by order | Dynamic payment |
| E-commerce checkout, self-service ordering, kiosks | Dynamic payment |
| Need to collect or push payments for a specific order | Dynamic payment |
| Want a shorter payment path and less user input | Dynamic payment |