Cash Server: 54-FZ receipts via API on your own cash register

Cash Server is fiscalization of online sales without renting a cash register in a data center. Your website, CRM or accounting system sends a receipt with an ordinary HTTP request, and the document is registered on your own cash register — the one already standing in your store, office or warehouse.

The protocol is deliberately compatible with ATOL Online v5 (FFD 1.2) and v4 (FFD 1.05): if your module or SDK already speaks to ATOL Online, the integration comes down to changing the base URL and the access credentials.

• Base URL: https://54fz.cenaly.ru/possystem/v5/
• API reference: Cash Server API
• Receipt contents and reference tables: Receipt fields
• Ready-made store scenarios: Scenarios
• Errors and diagnostics: Errors

1. How it works#

your server ──HTTP──► 54fz.cenaly.ru ──queue──► Cenaly Hardware Bridge ──► your KKT ──► OFD → FTS
     ▲                     │                    (the store's cash register PC)
     └───callback + report─┘

1. Your backend receives the payment and sends a JSON receipt to POST /possystem/v5/{group_code}/sell.
2. The service replies instantly: {"uuid": "...", "status": "wait"} — the document has been accepted into the queue.
3. The queue picks a free cash register in your group and sends the job to the bridge on the cash register PC.
4. The cash register registers the receipt, and the OFD sends the electronic receipt to the customer's e-mail or phone.
5. You get the result: a POST to your callback_url and/or GET .../report/{uuid} — with the fiscal document number, the fiscal sign, the fiscal drive number and the KKT registration number.

The typical time from request to done is a few seconds. The maximum waiting time for a free cash register is 300 seconds, after which the document gets the fail status with the timeout type.

2. How this differs from renting a cloud cash register#

One KKT is legal both for the sales floor and for the website: see Cloud cash register and Online store receipts. We provide the transport and the queue up to your cash register — we are not an operator of fiscal data; the receipt is generated by your KKT, in your name and under your TIN.

3. What you need to connect#

1. Your own fiscal cash register registered for online payments. Its registration record must have the “online payments” flag enabled, and the payment location (tag 1187) must contain your website address. If the register is only registered at a retail address, it must be re-registered — the bridge includes a registration wizard.

2. A POS computer with Cenaly Hardware Bridge installed. The bridge is a background Windows or Linux service that connects the register to the cloud. It uses a standard installer and configures automatic startup itself; see Cenaly Hardware Bridge.

3. A permanent internet connection and a POS computer that stays on. Receipts are issued on your equipment: if the computer is off, the document waits in the queue and returns an error after 300 seconds. Keep the POS computer on for overnight orders.

4. The “Cash Register API (Russia)” extension. Enable the section using the “Cash Register API (Russia)” card in the App Store. The extension costs ₽790 per month or ₽7,900 per year for each connected register and is available only to locations in Russia.

5. Your own cash register server. You create the credentials yourself: in the admin panel, open “Cash Register API” → “Create cash register server”. The two-step wizard asks you to select a register from your equipment registry (you can add a backup too), then enter company details (name, tax identification number (INN), default taxation system and protocol version). The final step provides a group_code, login and password. The password is shown only once and stored only as a hash: a lost password cannot be recovered, only replaced using “Change password” (tokens already issued remain valid for their 24-hour lifetime).

The wizard has a “Test mode” checkbox: documents are accepted and validated but not sent to the register — useful for debugging an integration before the first real receipt. You can change the mode later: “Settings” in the server row lets you edit its name and test mode, so a tested server can go live without being recreated or having its credentials changed. There is also a shared test group with a mock register — support can provide its credentials.

Cash register compatibility#

ATOL registers (DTO-10 driver) currently provide reliable support for electronic receipts without printing. For other families (SHTRIKH-M, Pirit, Mercury), the bridge is used for offline scenarios — they either do not support online receipts without printing or do not declare this capability in their protocol. Check your model with support before connecting: incompatibility is identified during setup, rather than on your first real receipt.

4. Connection Procedure#

Integration readiness is simple to determine: the first report with done status and a populated fiscal_document_number.

5. What the Service Can and Cannot Do Today#

What it can do:

• 8 protocol operations: sell, sell_refund, buy, buy_refund, and four types of correction receipts;
• full FFD 1.2 receipt structure: buyer (including extended details), taxation system, settlement method and subject flags, units of measurement, VAT rates (including 5%, 7%, 22%), agent details, industry-specific and operational attributes;
• idempotency via external_id — a repeated request never prints a duplicate document;
• queue with balancing across multiple POS devices in a group, including backup devices;
• result delivery via callback with retries and polling.

What it cannot do yet (transparently):

• Marking code verification in Chestny ZNAK / TS PIoT — the marking code is passed to the POS as is; permit-based mode is not implemented on our side;
• Link to the receipt in the OFD (ofd_receipt_url) — the field is returned empty: POS drivers do not supply it; the receipt can be found in your OFD personal account by the FD number;
• Dedicated public API for POS monitoring (FN status, pending unsent documents) — in development. The status of POS devices itself is visible in the "POS API" section: connectivity of each POS (online / offline / removed from equipment), queue (how many documents are pending and in progress), receipts printed and rejections in 24 hours, last receipt and last rejection, alongside a receipt log with fiscal details.

The service is available only within the Russian boundary of the cenaly.ru brand: the entire receipt path and customers' personal data remain within Russian infrastructure.

6. What's next#

• Cash Server API reference — authentication, endpoints, response formats, limits.
• Receipt fields — the contents of receipt and all value reference tables.
• Online store scenarios — payment on the website, prepayment, refund, correction, courier, agent scheme.
• Errors and diagnostics — error codes, behaviour when the cash register is offline, integration checklist.