Choose a button or QR code for the device
NSPK describes online store payments using QR codes, buttons and links. A button or link lets the customer choose a bank and proceed to confirmation. On a desktop, a QR code is convenient to scan with a phone. On the phone itself, provide a clear route to the available banking flow rather than leaving the customer with only an image of a code.
The payment page should show the order reference, total amount, selected method and a clear action. A label such as “Continue to SBP payment” explains the next step. Do not display methods that have not been enabled for that merchant.
If the chosen bank's application does not open, the customer needs a useful message and an available next action. Do not promise an automatic handover on every device: test the browsers and environments that the approved integration actually supports.
Save the order before opening the bank
The merchant's server should record the order and amount before opening an external payment flow. A separate payment attempt is linked to that order. If the customer closes the browser or returns several minutes later, the store should find the original order instead of losing the basket.
Keep at least two references for support and reconciliation: the order identifier and the payment attempt identifier. They serve different purposes. The order describes the purchase; the attempt describes a specific payment process. A further attempt must retain its relationship to the same order.
Validate the price and purchase details on the server. Data supplied only by the browser should not determine the order amount on its own. Follow the applicable documentation for creating another attempt and setting its expiry.
Returning to the store does not confirm payment
A customer can return from the banking application before a server-side status arrives. A customer can also complete payment and close the tab without returning to the result page. Order updates must therefore follow a verified server-side outcome under the integration's rules.
The result page can communicate three understandable states:
| State | What the customer sees | What the store does |
|---|---|---|
| The outcome is still being checked | An order reference and a waiting message | Checks the current status and preserves the order |
| Payment is confirmed | Confirmation and the next fulfilment step | Starts delivery or fulfilment once |
| The attempt ended without payment | An explanation and an available next action | Preserves the attempt history and checks whether a new attempt is appropriate |
Take technical status names and permitted transitions from the connected payment system's documentation. Customer-facing messages should explain the outcome rather than expose internal status codes.
Handle an uncertain result carefully
If a customer reports a debit while the store has not received confirmation, check the original attempt first. Immediately asking for another payment can result in two successful transactions for one order.
A status refresh action can help on the result page, while support should be able to search by order reference. Technical records should retain when the attempt was created and when its state changed. Payment secrets and full payment credentials do not belong in those records.
Checking an existing attempt and creating a new one are different operations. Customers do not need internal API method names, but the merchant's team needs to distinguish these actions when designing the interface.
Test the full journey on real devices
One successful test is not enough. Build a small test set for the relevant devices and browsers:
- a normal payment followed by a return to the store;
- cancellation by the customer;
- closing the tab after the handover;
- returning before the server notification arrives;
- reopening the result page;
- expiry of the payment attempt;
- a temporary loss of connectivity;
- repeated delivery of the same notification.
Each test needs an expected result: what the customer sees, what state the order reaches and how many times the product or access is delivered. Test embedded messenger browsers separately when customers start the flow there. The payment launch testing checklist provides a practical matrix.
Find where customers leave the flow
Separate the journey into events: checkout started, payment created, SBP selected, payment handover and confirmed success. Count orders separately from attempts so that repeated clicks do not artificially increase the customer count.
Compare results by device, browser and period. Many created payments without a handover may indicate an interface issue; handovers without confirmation require investigation of available error and status data. These are diagnostic hypotheses to verify with evidence. Changing a button label alone does not establish that conversion improved.
Connecting with WhiteCapital Tech
WhiteCapital Tech helps businesses evaluate website and application payment acceptance through SBP, payment links and APIs. Available methods, integration parameters, fees and limits are determined after project review. Describe the customers' devices, order journey and fulfilment process when discussing a connection.
Engineering teams can continue with the API integration guide and payment webhook and status guide. The merchant infrastructure page explains how a specific business is assessed.
Questions and answers
Is a QR code enough on a mobile payment page?
Check how a customer can complete payment on the same device. A button or link to the approved payment flow usually makes the next step clearer.
Does a return from the bank mean payment succeeded?
A verified server-side status confirms the outcome. The customer's return is used for the interface and a fresh status check.
What happens if the customer closes the tab after payment?
The order should update through the server-side channel independently of the open page. The customer should be able to find the order and its current state.
Should the store immediately suggest paying again?
Check the original attempt first. When the result is uncertain, another payment can lead to two successful transactions.
Sources and scope
- NSPK: SBP payment questions and answers, in Russian.
- NSPK: ways to pay for purchases, in Russian.
- WhiteCapital Tech: payment API.
The general payment methods are described using NSPK's official materials. The state table, test set and measurement approach are editorial operating recommendations. They do not replace the documentation for an individual connection or promise support for every bank, device or feature.
This is practical guidance. Available methods, equipment integration, limits, fees and settlement terms depend on project approval and the agreed documentation.