Process
In the main-scan mode, the user scans the merchant's static/dynamic code; in the scanned-by mode, the merchant scans the user's payment code. Order numbers, merchant identifiers, and amounts are routed to wallets like WeChat/Alipay through the acquiring system. IoT vending machines, EV charging stations, etc., use dynamic codes to prevent replay attacks, and 4G modules are responsible for fetching orders and querying payment results.
Risks
Code replacement, screenshot theft, and man-in-the-middle attacks require terminal firmware and physical tamper-proof measures; signature and timestamp verification are essential.
Reconciliation
Platform-side orders and payment channel transactions need end-of-day reconciliation, and any exceptions require manual handling.
Module and Terminal Engineering Details
In dynamic code scenarios, screen refresh rate, backlight, and QR code error correction level affect scanning success rates; in outdoor strong light or low-temperature conditions, the LCD response slows, reducing user scanning experience. When 4G modules fetch orders and poll payment results, appropriate backoff and timeout should be set to avoid frequent retries that trigger channel rate limits under weak network conditions. Firmware must verify QR code content domain names and signatures to prevent local cache tampering; devices should comply with physical tamper-proof measures and startup integrity checks. For offline codes or dual-offline pilot businesses, risk levels and single transaction limits should be distinguished, and terminal status should be uploaded promptly once the network is restored.
Risk Control, Customer Complaints, and Operational Data
For the same terminal, a large number of failed payments in a short time, abnormal amounts, or sudden changes in geographic location should be connected to the risk control list and real-time interception. Customer complaint handling requires traceable order numbers, code generation time, payment channel return codes, and module-side network indicators. From an operational perspective, peak periods, failure code distribution, and device model distribution can be statistically analyzed to drive firmware optimization and code strategy adjustments. If revenue sharing and invoicing rely on successful payment callbacks, it is necessary to ensure callback arrival rates and order completion mechanisms, otherwise account mismatches and degraded user experience may occur.
Engineering Practice Supplement
Combining "QR Code Payment" with the module's full lifecycle: During the EVT stage, verify reference design and antenna solutions; during the DVT stage, conduct conduction/radiation preliminary tests and thermal imaging; during the PVT stage, finalize calibration and test scripts. Before certification, verify the target country's regulations and carrier registration requirements to avoid missing frequency band or SAR items. The production line retains golden samples for comparison and sampling rules; after-sales can trace software versions, calibration parameters, and key component batches according to the serial number. If the customer requires remote operation and maintenance, security upgrades, rollback, and emergency shutdown strategies must be designed simultaneously.
Dynamic-Code Payload and the Payment State Machine
In a payment, the QR code is only a slip that carries the order into the wallet. In merchant-presented mode the customer scans the merchant code. In consumer-presented mode the merchant scans the customer's payment code. The payload of a dynamic code should contain a one-time order id, an amount, a merchant id, and an expiry. The wallet or the acquirer creates a pending payment from that. There are only three terminal states: payment succeeded, definite failure, and result unknown. Unknown must be queried again. It cannot be judged from whether the code is still on the screen. The cellular module fetches the code from the acquirer, submits the consumer-presented result, and polls the terminal state. It does not decide whether the customer's balance is sufficient. Error-correction level, contrast, and refresh timing affect whether the code can be scanned. They do not decide whether the books are settled.
The condition of use is that the order id is created and stored before the code is issued, that the domain and signature on the code can be checked by firmware, and that an expired code is not polled further. In strong outdoor light, or when the display slows in the cold, extend the time the code is shown instead of pulling a new order continuously. If offline or dual-offline operation is allowed by the business, there must be a per-transaction limit and an obligation to upload the terminal state later. An offline success is not the same as cleared funds. A burst of failures or a jump in amount on one terminal must be able to stop the machine, not only appear later in a cloud report.
Poll Backoff and Callback Recovery
On a weak network the usual move is to shrink the poll interval to the minimum. The channel returns a rate limit, the terminal treats the limit as a payment failure and issues a new code, and one purchase becomes several pending payments. If goods are dispensed when the callback is lost, goods go out without a successful payment. If the device waits for the callback forever, the customer has been debited and the goods do not come out. Recovery must query the original order id. It must not create a new order and ask again. If a static code stuck on the cabinet is replaced, and firmware does not check the content, the money arrives in someone else's merchant id.
A wrong local clock marks an unexpired code as expired, or keeps showing a code that has expired. If a split waits for the payment callback before it starts, a missing callback becomes a missing receivable for one party. The rules are in payment split. Do not share one "payment succeeded" bit between a contactless card read and a QR scan. A failed card read should not be written as a wallet decline; see NFC payment.
Issuing the code, payment, and dispensing should be three local states, not one success flag. Code issued only means the screen holds a pending payment. Payment succeeded only means the channel accepted the debit. Dispense succeeded is when the goods leave the chute. A failure in any segment has to keep its reason. In particular, payment succeeded and dispense failed must enter a refund or restock queue. It must not be overwritten when the next code is generated. When a poll returns a rate limit, lengthen the interval and keep the original order. Do not switch to a new code immediately. A failed signature check should stop the display and raise an alarm, so static content stuck on the cabinet cannot cover the later dynamic code. If the local clock is too far off, refuse to issue a code rather than show one the cloud already considers expired. Keep the three states together with the channel transaction id through the end of the day. Recovery and complaints then will not merge two purchases into one.