An online payment in Russia requires a fiscal receipt for the buyer. Here is who must issue it, what happens when it is missing, and how fiscalisation fits into payment acceptance without buying hardware.
deadline to issue a receipt after settlement
and cards in one acceptance setup
cash registers to purchase
54-FZ is not about bookkeeping but about the moment of settlement: the buyer must receive a receipt and the tax authority a copy of it.
An electronic receipt is sent to the buyer by email or phone at the moment of settlement, and the data goes to a fiscal data operator. This applies to card payments and to payments through the Faster Payments System alike.
Item name, quantity, price, VAT rate, and the payment and subject attributes. A poorly described item list is the most common reason a receipt fails validation.
Beyond the penalty, missing fiscalisation gives the acquirer grounds to end the relationship: it is no less accountable than you are for the lawfulness of acceptance.
Fiscalisation is a step in the payment lifecycle, not a separate system you have to reconcile by hand.
A successful payment, a refund or a partial refund each produce the corresponding fiscal document automatically. The operator does not maintain two pictures of settlement and reconcile them.
Receipt contents are assembled from the order lines; rates and settlement attributes are driven by rules. Advances and instalments have their own subject-of-settlement attributes.
The fiscal drive is rented from a cash-solution operator and the receipt goes through it. Owning hardware, servicing it and replacing the drive drop out of the job.
Responsibility for the receipt rests with whoever takes money from the buyer, and it cannot be handed over along with an integration. So the decisions that remain yours are worth settling before launch: whose register is used, how the item list is described, which VAT rate applies to each line, what counts as an advance. The platform makes sure every settlement produces a document; it does not decide for you what the document says.
Refunds and partial refunds deserve separate attention. They produce their own fiscal documents, and that is where the picture most often diverges: the money went back but the refund receipt was never issued. When fiscalisation is tied to the payment event rather than to an accountant's manual step, that gap closes by itself.
And about channels. The Russian market is not only cards: a substantial share of payments runs through the Faster Payments System, where confirmation is instant and the receipt must be just as fast. It makes sense to build the setup with both channels and one fiscalisation rule from the start, rather than revisiting it after the first quarter of operation.
Two setup wizards. The operator goes through them alone — no development needed.
Cash-solution operator, company details, tax regime, VAT rates, settlement attributes and the rules that build the receipt.
Terminals for cards and the Faster Payments System, limits and a test transaction — the acceptance setup fiscalisation attaches to.
Issue the first receipt on a test transaction and check it in the tax authority's portal: an error in the item list or the VAT rate is visible immediately, whereas after live acceptance begins, fixing it means issuing correction documents.
Register and go through the fiscalisation wizard yourself. Issue the first receipt on a test transaction — before live acceptance starts, while an item-list error can still be fixed without correction documents.
Get started