How to Connect SBP (Faster Payments) to Digiseller

SBP changes the economics of taking payment for digital goods far more than it looks like from the outside. It is not just another button at checkout — it is an account-to-account credit transfer instead of a card transaction. That single difference cascades into different pricing, different settlement behaviour, different refund mechanics and the near-absence of card chargebacks. Here is how a Digiseller seller connects it, what to prepare first, and where the process usually breaks.

Why SBP matters for Russian digital sales

The real bottleneck in a digital-goods store is rarely price. It is the payment funnel. The buyer has already chosen the key and already pressed buy — and then the payment fails: the card does not allow internet transactions, the issuer's anti-fraud engine kills it as suspicious, the 3-D Secure code never arrives, the card expired, the limit is used up.

SBP routes around almost all of that. The buyer scans a QR or taps a link, lands in their own banking app, and confirms the transfer the way they always do. No card details, no issuer limits in the way.

The second effect is the absence of card chargebacks. Because the payer initiates the transfer themselves, there is no card-scheme dispute mechanism to reverse it later. For digital goods, where the product cannot be put back on a shelf, that removes a genuine source of loss — see our breakdown of how to avoid chargebacks on digital goods.

This does not mean disputes vanish. A buyer can still file a fraud claim with their bank, open a dispute on the platform, or escalate to Digiseller support. What changes is the channel, not the existence of conflict.

What to prepare before connecting

C2B acceptance is commercial payment acceptance, which means legal status is not optional.

• Entity status. Sole trader, legal entity, or self-employed status where the bank supports it. Collecting revenue on a personal card is not SBP acquiring.
• A settlement account at a bank that participates in the system. Participation lists change — check before you pick a bank.
• Merchant registration. Your bank registers you as a merchant, declaring your site, activity type and product category.
• Bank onboarding checks. Digital goods are a scrutinised category. Expect to explain what you sell, where you buy it, and what documents back the purchase.
• A clear tax position. SBP does not change your tax rate, but it makes revenue fully visible. The mechanics are covered in our piece on VAT and tax for digital goods distributors.

Separately, handle fiscalisation. Paying by SBP does not remove cash-register obligations for sales to individuals. Decide in advance whether you issue the receipt through your own online cash register or a payment agent does it under contract.

The connection path on Digiseller

Digiseller has historically acted as more than a storefront — it also sits in the payment path. The buyer pays on the platform side, funds land on your internal balance, and you withdraw to your own details. That produces two distinct scenarios that sellers routinely confuse.

Scenario 1 — SBP as a buyer payment method

Here you connect nothing to a bank yourself. The method is provided platform-side and you simply enable it in your seller panel's payment settings. Your job is to confirm the method is genuinely active for your listings and renders correctly for the buyer at checkout.

Scenario 2 — SBP as your own acceptance and payout channel

If you also run your own storefront or a Telegram shop alongside the platform, SBP connects directly through an acquiring bank and the whole technical layer is yours. This is the scenario that requires a contract, merchant registration and real integration work.

Menu names and layout inside Digiseller change from time to time. Navigate by the payment-settings section and the platform's current help pages rather than screenshots from older guides.

The general platform workflow is covered in how to sell digital goods on Digiseller, and programmatic automation in Digiseller API automation.

Static vs dynamic QR — the decision that determines everything

If you accept SBP outside the platform, this is the single most important technical choice.

A static QR is fine for a physical counter. For digital goods it fails: buyers type the wrong amount, pay against the wrong order, or pay twice — and you untangle it by hand. Automated delivery requires a dynamic QR or payment link carrying a unique operation ID per order.

Settlement, reconciliation and reporting

SBP behaves as a series of individual transfers, not as card acquiring with batched clearing. Practical consequences:

• Each operation arrives as its own amount, not inside a daily settlement file. Bank fees may be debited separately — confirm the format in your agreement.
• Every operation carries a unique identifier, and that identifier is your reconciliation key. Store it next to your order number. Without it, refunds and disputes become archaeology.
• Settlement timing depends on the bank and your contract terms. Do not plan cashflow on hearsay; read the documents.

A robust technical flow looks like this: order created in your system → payment link generated with a unique ID → bank sends a payment notification → your backend verifies signature and amount → only then is the code released. Handle notifications idempotently: banks can resend the same callback, and without protection you will deliver two keys for one payment. The mechanics are detailed in webhooks for digital goods orders and idempotency keys.

Refunds over SBP

The seller initiates a refund by reference to the original operation, and the money goes back to the payer's account. The key rules:

• You cannot refund to a different account or by a different method within the mechanism. A buyer asking you to refund to another card is a classic fraud pattern.
• Partial refunds are generally available, but conditions and timing are set by the bank.
• A refund does not undo delivery. If the key is already activated, there is nothing to return — log the moment of issue and, where the supplier exposes it, activation status.

Write the policy down: when a refund is automatic, when it requires a code-status check, and who signs off.

Common pitfalls

1. Using a static QR for online sales. Guarantees manual reconciliation and duplicate deliveries.
2. Releasing the code when the QR is displayed rather than when payment is confirmed. The buyer closes the tab; the key is already gone.
3. Not storing the operation ID. Refunds and disputes become unresolvable.
4. Ignoring fiscalisation. A fully transparent payment with no receipt is the fastest way to attract questions.
5. Sudden volume spikes with no explanation to the bank. Anti-money-laundering procedures can restrict your account. Keep supplier contracts and purchase documents ready in advance.
6. Modelling margin on approximate rates. The C2B rate depends on your merchant category and bank terms — read your contract, not blog posts.

Where to source inventory for instant delivery

Fast payment is pointless if the code takes an hour to arrive. SBP only pays off with genuine instant fulfilment, and that needs a reliable stock source. FoxReload covers that layer: a wholesale catalogue of 900+ SKUs — game keys, gift cards, top-ups, eSIM and software licences — behind a single REST API, with auto-delivery and multi-region SKUs. Orders are created programmatically and codes come back immediately, so the payment-to-delivery loop closes in seconds with no human in the middle.

To compare platforms on acceptance and payout terms, see Plati vs GGSEL vs Digiseller.

In short

SBP is not cosmetic. It removes a whole class of checkout failures and takes card chargeback risk largely off the table. In exchange it demands registered status, a careful integration with a unique operation ID per order, and a written refund policy. Rates, limits and settlement timing move — verify them in your current bank agreement and the platform's own documentation before you model unit economics.