Skip to main content

Architecture

System Architecture​

  1. Merchant Management System (MMS) - frontend for CSC and TAX office where new merchants/devices can be registered and approved. Additionally, the system generates Keys and Clients Certificates during onboarding of the merchants.
  2. Merchant Portal (MP) - a tool for merchants to apply for new cash register activation and the reporting module for displaying tax obligations in real-time.
  3. Web browser—Any consumer can scan the QR code with a common camera and be immediately redirected to the FDO Consumer Microservice,where FDO check hash and if it's valid one generates digital copy of the receipt. No specific software or hardware is needed for such validation.
  4. Online ECR—any hardware/software that can generate receipts in a specific format signed by clients using certificates generated by TaxAuthoritie in the MMS system. There is no certification for such ECRs and no way to issue receipts without an online connection to FDO.
  5. ECR with Off-line functionality - certified by Gov hardware solution with Fiscal Memory WORM (Write Once Read Many) type, which can work without an Internet connection for not more than 72 hours and issue receipts in a specific format signed by clients certificates.
  6. E-invoicing - separate complex wich enables digitalisation of the invoicing flow and fiscalise it by events like creation, payment execution, items despatching etc.

Advantages of FDO S1​

  1. 72-hour offline support—S1 enables ECR to work in offline mode in rural regions with pure internet coverage. You need to connect ECR to the internet once every three days and upload all the receipts to the FDO. Utilisation of secured WORM Fiscal Memory excludes fraud offline, as all the documents printed on the device should be stored in FM.
  2. Easy Certification process enables easy access to the offline ECR for 3rd party vendors.
  3. High-security S1 standards enable the storage of BigData and protect it from modification at all interaction levels, such as ECR and FDO.Fiscal document database from each ECR is built on the principles of blockchain, where hash of each block calculated by HSM.
  4. The flexibility of the system architecture enables high-velocity performance, swift scalability, and easy deployment of new services queried by the government. For case of high performance we utilise a horizontal chain of servers with Mongo noSQL DB.
  5. High performance architecture allows to operate with 50 000 TPS + and more.
  6. Merchant portal (MP) for B2G communication—S1 enables remote communication between merchants and the government through the MP. Each merchant can register a new ECR, request sales data reports, and see all fiscal data in real-time. The system's high scalability allows for the addition of any type of functionality requested from the government.
  7. S1's wide range of hardware and software products for Merchants enables easy transition to the new regulations for both new and existing merchants.
  8. 3 levels of participants of FDO interactions enable the utilisation of private Customer Service Centers in onboarding new merchants. System integration support and hardware/software sales by CSC decrease government unit involvement in the onboarding and supporting fiscalisation process. Communication and registration of merchants in the system goes through certified CSC.

Security and cryptography​

  1. All documents are signed by the clients certificate, and the FDO service verifies each signature before saving it to the database.
  2. All documents are saved to the database in a strict sequence in the order in which the fiscal operation was performed. With the help of HSM the hash of each document is calculated. This calculation is made on the basis of all data of the document and hash of the previous document and thus measures protects data from illegal operations, such as document data substitution, as well as adding a third-party document to the chain.
  3. With regular hash checks of all documents process, the integrity of the database is monitored. This check can also be run manually for a certain period of dates, by selected merchant or by other customisable parameters.
  4. When requesting to receive a cheque by qr code, the hash check of this document is performed, which guarantees correct display of all data on the selected fiscal transaction.

Off-line ECR requirements​

  1. Off-line mode for not more than 72 hours (configurable).​
  2. If the device is used for more than 72 hours in off-line, it should be automatically blocked until all the offline receipts are uploaded to the FDO server.
  3. One shift duration is not more than 24 hours.
  4. All issued fiscal receipts (inc. Z-reports, service documents etc.) should be saved in FM (Fiscal Memory) WORM (Write Once Read Many) type.
  5. WORM functionality needs to be confirmed by the vendor's declaration.
  6. Should support sending receipts via email, sms.
  7. Capacity of FM - minimum 2000 z-reports (with minimum calcualtion 100 receipts per shift, approximate 5 years FM usage).
  8. All-in-One devices should accept various types of payments like bank cards, A2A payments, QR code payments, etc
  9. Forbidden changing the time on the ECR during the open shift. All events of time changes should be stored in FM.

Key parts of FDO security perimeter​

  1. Security storage + HSM - storage of the client's certificates generated for each merchant and HSM to validation receipts chain by calculating hash.
  2. SQL DB (PostgreSQL)- database for dashboards and reports for Mercahnts and Goverment.
  3. NoSQL DB - BIG Data storage for fiscal documents for each ECR with hash of each block of fiscal documents calculated by HSM.

[!NOTE] As we grow, we're transitioning much of our traditional PDF-based documentation to this interactive online portal. If at any time you require legacy documentation, please Contact Us for more information.