So damn scary or how we implemented online cashier

This article was written in the form of a post for Habr, mostly due to the fact that a real informational vacuum has arisen around the issue of online cash registers for Internet sites. On the one hand, the network is full of articles on the topic of online cash registers, on the other hand, there is not very much information about solutions for websites, especially technical ones. Only the words that "urgently need to" and "will be fined." We found this quest quite interesting and confusing, if you help someone, we will be happy.

What is an online cashier, how it interacts with the tax authorities and a general description of the technology can be found on specialized sites. It also contains all the technical information on the products that we managed to find, in essence, this is the processing of our internal Wiki article on this topic.

Perhaps the article will lose its relevance very soon, so that it is written as of mid-June 2017. And yes, it seems like exactly for Internet sites selling services online, the deadline for implementation is not this year, but I don’t want to experiment with the tax authorities, and it’s better to prepare a sleigh in summer ...

So, we sell online services on our sites (subscriptions). We accept payments through Yandex.Cash and PayPal. We work in white, all things. Now, it turns out, we need a cash desk for settlements with individuals (except for paying them from our own bank account). Somewhere in the payment chain on the website between the “approved” answer from the payment gateway and the service, you need to insert another operation “to knock out a check”. “Well, what problems, we rent an online cash desk service and that's it,” we decided. And then the harsh reality showed: all beautiful ATOL -online landing pages , Starrus and others are nothing more than advertising landings. Today there are no SaaS solutions ready for operation; in any case, we could not find them. As well as the vaunted integration of Yandex.Cash with ATOL-online . The same request for technical documentation in ATOL stalled right at the entrance, and Starrus advised to put stand alone instead of their unprepared SaaS. Then it turned out juicy details about the situation with fiscal drives and it was quite fun.

As a result, after analyzing the market, including on the adequacy of communication with manufacturers' support, we stopped on a solution from Starrus: CCT RP RPF System. We decided to purchase the complex, install it at our facilities and add our billing to interact with all of this.

But at the beginning of some terminology:

• KKT - cash register equipment. In the context of the article - the cash register.
• FR - fiscal registrar. In essence, the same as CCP.
• FN - fiscal drive. A cryptographic tool in the FR.
• FD - fiscal document. Check, PD number - check number.
• OP is a fiscal feature. The reference value of PD.
• OFD - the operator of fiscal data. An external service that receives and accumulates fiscal data.

Fiscal registrar RP System 1FS (FA) - the online cash register ( CCT ) of the new generation with automatic sending of fiscal data to the CRF . Allows the network to accept commands in JSON format and "knock out checks." All external interaction with the OFD is blackbox, it works independently and does not require any additional gestures.

Hardware

Officially, in the “registry” there is only the RP model of the 1FA System. It is designed for vending machines and has a receipt printer included. The model for Internet sites is called RP System 1FS, it is distinguished by the absence of a printer. But since the RP model, the 1FS System is not in the registry, the RP model of the 1FA System, but without a printer in the kit, is being sold under its guise. This information will avoid confusion when choosing and ordering CCP .

The CCP itself is a small metal box painted with black paint. Markings are marked on the case and all interface connectors are present in the end planes.

On the case there is a flap on the screw mount, followed by a compartment for the fiscal drive ( FN ), which works through the internal interface of the UART. It will not allow the key to be inserted in the wrong way (muffled by pin), but considering the design features of the hatch, it is not easy to insert and especially remove the drive. When registering and re-registering an FN , a corresponding entry is made in the CCP passport.

The generalized state of the CCP is displayed on the case by means of four LED indicators. Status, data exchange, error status.

Power is supplied from any stabilized DC source from 7.5 to 24 volts. "Round" plug, "plus" inside. The power supply unit is not included in the package, as a rule, they are not available from the supplier / manufacturer, they are advised to purchase third-party compatible.

The Ethernet controller has a predefined address, or it receives settings via DHCP (DHCP priority over static settings).

RS232 (DB-9 in / out) operates in 115200 mode and is used for local connection to a control computer and for connecting a receipt printer, if necessary. At all stages of the standard interaction with CCP , starting with registration of the FN and ending with the “punching” of checks, it can be performed exclusively over a local network via Ethernet, without interacting with RS232.

On the case there is a USB, but it has not been tested.

Fiscal drive

This module is a cryptographic tool, it stores fiscal data (checks), it also generates the result of cryptographic functions with input data (fiscal sign). Structurally made of gray plastic with a holographic protective tape. The interface connector provides power to the FN in the working mode and data exchange via the UART, I2C and RS232 protocols. Inside there is a lithium battery that supports the internal clock (RTC). FN has an artificially limited period of validity and must be replaced every 13 months.

Software

It is possible to interact with CCT through the RS232 interface, or over a local network using the JSON protocol, which communicates via an HTTP connection to port 4444, as well as a "binary" connection to TCP port 3333.

TestFR, RS232, . Windows, «» . , , , , . , .

/ , . .

. ( ) . «» . «» , , . , . . «» , « », -. «» . .

. , , . ( ) , . , .

( ) . , . 3000 .

, . .

. , 3-way handshake. ( ).

. : ( ), , «-» . , .

, , !

TestFR. , . « » , 11 . , , , , . . () 1 — « ». (), . , .

- ( ) - , «8. », « », 1. , , TestFR, . CTRL+A .

, . , .

, . . .

, . , . , .

.

. . , . .

. — . :

• 1: ,
• 1: ,

, . . .

«», , - Complex. , , . , - .

Complex :

{
    "Group": "%personal_uuid%",
    "Device": "auto",
    "RequestId": "%unique_request%",
    "QueueLen": 100,
    "Password": 1,
    "Lines": [{
            "Qty": 2500,
            "Price": 10000,
            "PayAttribute": 4,
            "TaxId": 1,
            "Description": "  "
        }, {
            "Qty": 500,
            "Price": 200000,
            "PayAttribute": 4,
            "TaxId": 2,
            "Description": " , "
        }
    ],
    "Cash": 200000,
    "NonCash": [2000, 3000, 4000],
    "TaxMode": 1,
    "PhoneOrEmail": "%customer_contact%",
    "FullResponse": false
}

RequestId , . , , , .

, . «» n . , : , , . .

FullResponse true , , .

100, .

, Qty = 1000.

Cash ( - )

NonCash , . .

TaxMode — ( ).

, «» . 1 1- API, .

, API. , , . , . , . , . . , , , .

, « , ». «»:

• . «» . - , — .
• , «». «» «», .
• , . «» TestFR.exe, — . «» . , , , .
• , -, . « », , , . , ( ).