Fiscal receipts and recurring charges: how to fiscalise a product subscription in Ukraine

When a store sells one-off, fiscalisation is part of checkout: the customer pays, the software fiscal registrar (PRRO) issues a receipt, the customer gets it by email. With a subscription everything is the same, except the customer is not there at the moment of payment. The charge runs overnight against a token, and the receipt has to appear without their involvement — and without yours.

This is not legal advice: PRRO rules change, and the current requirements are worth checking with your accountant before launch. But the technical mechanics are stable, and that is what this is about.

Why subscriptions complicate fiscalisation

Three things that go unnoticed in one-off sales:

1. There are many operations. A thousand subscribers charged weekly is over four thousand receipts a month, all without a cashier.
2. Payment and shipment are decoupled. The charge runs two or three days before shipping, so a failed payment does not disrupt delivery. The receipt is issued at the moment of payment, and the goods travel later.
3. There are pauses, skips and refunds. A skipped delivery before the charge is simply no operation. A refund after the charge is a “return” operation in the same PRRO, and it has to happen automatically too.

Who issues the receipt

There are two working options, and the choice depends on which acquirer you use.

The payment provider’s PRRO. LiqPay has a built-in software fiscal registrar: pass the cart contents in the payment request and a receipt is issued for every operation, token-based recurring charges included. For a store this is the simplest option — no separate service, set up once in the LiqPay dashboard.

Plata by Mono has no built-in PRRO. The receipt is issued by a separate service that receives the successful-payment event.

A separate fiscalisation service. Checkbox, Vchasno.Kasa and similar. The scheme is always the same: the payment goes through, your system or the subscription platform sends the operation data to the service — amount, line items, payment method — the service issues the receipt and returns its link, which goes to the customer. All of it is a webhook and one API call, no people.

The advantage of a separate service: it does not depend on the acquirer. You can take some payments through mono, some through LiqPay, and issue receipts in one place.

How this looks with Neocarts

Neocarts is not a PRRO and does not issue receipts. It does what a receipt needs: on every successful charge it sends a webhook with the amount, line items, payment method and customer identifier. Your developer or integrator passes that event to Checkbox or Vchasno.Kasa — or, if the acquirer is LiqPay with its PRRO switched on, the receipt is issued on LiqPay’s side with no extra steps.

So fiscalising subscriptions looks the same as fiscalising one-off payments; only the trigger is not the “Pay” button but the charge event. If you already have a PRRO for the website, no new register needs to be opened.

Refunds and partial operations

The customer cancelled after the charge but before shipping — a refund and a refund receipt are needed. In LiqPay with PRRO, a refund through the API issues the corresponding receipt automatically. Through Checkbox a refund is a separate call referencing the original receipt.

Partial refunds hardly ever happen in subscriptions: a charge for one period either exists or does not. If you do allow changing the order after the charge, it is better to handle it as a top-up or a refund, each as its own operation with its own receipt, rather than editing an already fiscalised one.

Test mode

Before launch, run the full cycle in test mode: first payment, token charge, failed charge, refund. All four scenarios must leave a correct trail in the PRRO. LiqPay has sandbox keys for this, Checkbox has a test register. Launching subscriptions on a live PRRO without this check means correcting receipts by hand a month later.

In short

• Every charge is a separate operation and a separate receipt. There is no person at the moment of payment, so the receipt has to be issued on an event.
• LiqPay acquiring with the built-in PRRO covers this without extra services. Plata by Mono — through Checkbox or Vchasno.Kasa on a webhook.
• Neocarts sends an event for every charge and refund; issuing the receipt is on your PRRO’s side, and it works with whatever fiscal solution you already have.

The comparison of the acquirers themselves for subscriptions is in LiqPay or Plata by Mono. How recurring payments work in Neocarts and what it costs are on their own pages.