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 is needed for connection#

1. Your own fiscal cash register (CRE) registered for online settlements. The registration card must have the "online settlements" flag enabled, and the place of settlement (tag 1187) must contain your website address. If the cash register is registered only for a retail address, re-registration is required — a registration wizard is available directly in the bridge.

2. A POS PC with Cenaly Hardware Bridge installed. The bridge is a Windows or Linux background service that maintains communication between the cash register and the cloud. Installation uses a standard installer, autostart is configured automatically; see Cenaly Hardware Bridge.

3. A stable Internet connection and a powered-on POS PC. The receipt is printed on your equipment: if the PC is turned off, the document waits in a queue and returns an error after 300 seconds. For nighttime orders, keep the POS PC turned on.

4. "Cash Register API (Russia)" extension. The section is enabled via the "Cash Register API (Russia)" card in the "App Store". The extension is paid: 790 ₽ per month or 7,900 ₽ per year for each connected cash register, and is available only for locations in Russia.

5. Your own cash register server. You generate access credentials yourself: admin section "Cash Register API" → "Create Cash Register Server" button. A two-step wizard — select a cash register from your hardware registry (you can also add a backup one) and company details (name, Tax ID (INN), default tax system, protocol version). The final step issues a group_code, login, and password. The password is shown only once and is stored only as a hash: a lost password cannot be recovered, it can only be reset using the "Change password" button (already issued tokens will remain valid for their remaining 24 hours).

The wizard includes a "Test mode" checkbox: documents are accepted and validated but not sent to the cash register — convenient for debugging the integration before the first live receipt. The mode can be switched later too: the "Settings" button in the server row opens editing of the name and the test mode, so a debugged server goes live without being re-created and without new credentials. There is also a shared test group on a mock cash register — its credentials can be provided by support.

Cash register compatibility#

Electronic receipts without printing are reliably supported today by ATOL cash registers (DTO-10 driver). For other families (SHTRIH-M, Pirit, Mercury), the bridge is used in offline scenarios — they either do not support online receipts without printing or do not declare support in their protocol. Check your model with support before connecting: incompatibility will be visible at the configuration stage, not on the first live 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.