Describe how the location operates first
Record three things before connecting: where an order is entered, which device the employee uses and which system records the sale. A store with a queue, a pickup point and a service desk can have different operational needs.
Agree who owns unresolved transactions and where staff escalate a discrepancy. When several locations are involved, the payment record should identify the relevant location and order. Equal payment amounts otherwise make matching difficult.
Support for a particular cash register, device or accounting system must be agreed separately. The ability to accept a QR payment does not establish that a ready-made integration exists for every device.
Link the payment to a specific sale
A dynamic flow creates a payment for an individual purchase with a specified amount. A static QR can be reused, while the amount and sales matching require an appropriate control process. The choice depends on the approved connection and record-keeping arrangements. The dynamic and static QR guide explains the distinction in more detail.
A practical dynamic QR process is:
- The employee records the order contents and final total.
- The system creates a linked payment attempt.
- The customer is shown a QR code on the agreed display or other medium.
- The customer checks the details and confirms the transaction with the bank.
- The employee receives confirmation in the designated interface.
- The sale proceeds to fulfilment and becomes part of reconciliation.
Retain the order reference, payment identifier, amount, time and location in the transaction record. Field names and the available data depend on the integration.
Staff verify the outcome on the merchant's side
NSPK states that the merchant's bank communicates the transaction status and credited amount by SMS or another supported method. In an automated setup, employees need an equivalent confirmed result in their working interface.
A screenshot on the customer's phone should not be the sole basis for releasing goods: it could relate to another purchase or an earlier transaction. The employee checks the payment, amount and relationship to the current order using the available confirmed source.
Clear states help a busy location: waiting for payment, payment confirmed, attempt ended without success and investigation required. Staff should not need to interpret technical error codes while serving a customer.
Prepare instructions for exceptions
| Situation | Employee action |
|---|---|
| The customer shows a debit but confirmation has not arrived | Check the original transaction and escalate using the order reference |
| Two customers pay the same amount | Match payments by order identifiers rather than the amount alone |
| The code is no longer valid | Check the previous attempt and follow the approved replacement rules |
| The same notification arrives again | Ensure the sale is not fulfilled a second time |
| Connectivity is lost | Follow the agreed process without labelling an unknown outcome as successful |
The instructions should identify the responsible person and the information needed by support: order reference, payment identifier, time and a description of the issue. Do not include integration secrets. When the outcome is unknown, distinguish checking the existing result from creating another payment.
Run the instructions through a practice case. An employee should be able to find the order and explain the next step to the customer without reading the developer's technical documentation.
Refunds and the end of a shift
Link a refund to the original successful transaction. Keep the refund amount, identifier and outcome separately from the original sale. The connected payment system determines the procedure and whether partial refunds are available. The online payment refund guide covers the operating model.
At the end of a shift, compare successful payments with sales and account separately for refunds and unknown outcomes. Start with each location when several are involved. The sales total and the amount due for settlement may differ because of agreed fees or other contractual terms; do not treat them as interchangeable figures.
Create a separate discrepancy record that states what was expected, what was confirmed, which identifiers were checked and who owns the investigation. “Escalated to support” is a workflow state, not a financial payment status. The payment reconciliation guide provides a baseline set of fields.
Check receipt generation and delivery separately under the rules applicable to the business and jurisdiction. A payment QR image does not describe all of a seller's obligations.
What to discuss with WhiteCapital Tech
Prepare a description of the physical location, a sample order, the accounting system, employee devices and reporting requirements. WhiteCapital Tech assesses QR payment flows for physical businesses within an individually approved project.
Equipment, cash-register integration, methods, fees and limits require separate confirmation. The SBP for business page explains the general payment scenario. Before launch, complete the acceptance testing matrix with an employee from the location, a developer and the person responsible for reconciliation.
Questions and answers
Does every purchase need a separate QR code?
It depends on the flow. A dynamic QR is linked to an individual payment; a static QR is reused and requires an appropriate method of matching sales.
Can staff release goods based on the customer's screenshot?
The working process should use confirmation on the merchant's side and a link to the current order.
Will QR payments work with any cash register?
Compatibility with a particular cash register, device and accounting system must be checked separately.
What if one order has two successful payments?
Preserve both transactions, investigate the circumstances and handle the extra payment through the agreed refund process. Do not remove a payment from the records.
Sources and scope
- NSPK: QR questions and answers, in Russian.
- NSPK: paying for purchases through SBP, in Russian.
- WhiteCapital Tech: merchant payment infrastructure.
General information about QR and payment confirmation is based on NSPK's official materials. The location workflow and exception table are editorial operating recommendations. Specific obligations, interfaces and transaction rules depend on applicable requirements, the agreement and the connection documentation.
This is practical guidance. Available methods, equipment integration, limits, fees and settlement terms depend on project approval and the agreed documentation.