Integration Checklist

Integrating the fiskaltrust.Middleware takes several steps: calling the API correctly, registering in the production fiskaltrust.Portal, and connecting to Dealers. This checklist gives POS Creators a quick way to confirm that every required step is complete.

Market	Check item	Description	Reference
	Sandbox fiskaltrust.Account created	An account and a POS system (ftPosSystemId) are created in the sandbox fiskaltrust.Portal, so that test Middleware instances can be set up.	Sandbox setup
	Production fiskaltrust.Account is created and partner contract is signed	An account is created in the production fiskaltrust.Portal to manage POS systems, and the PosCreator role is activated.	Portal Registration
	Certification or Attestation is started	One of two confirmations is required for legal compliance: certification (mandatory if the POS system is developed for your own use) or attestation. The corresponding process is started.	Contact our experts
	API methods are implemented	The POS system can call the Middleware API via the protocol of your choice.	Function structures & Communication protocols
	Business sequences are implemented	The required business cases (ftReceiptCases, ftChargeItemCases and ftPayItemCases) are implemented. Not every case applies to every POS-System — implement only those relevant to your use case.	Receipt cases & the relevant country-specific appendix
	Receipt headers are included	The correct values are passed for ftCashBoxID, ftPosSystemId, cbTerminalID, cbReceiptReference and cbReceiptMoment.	Data structures & the relevant country-specific appendix
	Special receipts are implemented	The required special receipts are implemented via the respective ftReceiptCases: initial operation, zero, daily closing, monthly closing, yearly closing, out of operation, and others. Which of these are mandatory depends on the market.	Receipt cases & the relevant country-specific appendix
	Error handling is implemented	The POS software handles both error types: the Middleware is not reachable, and the signing device or service is not reachable.	Cash register integration & the relevant country-specific appendix
	Signatures are printed on the physical receipts	The ftSignatures returned by the Middleware are printed on the physical receipts. All items must be printed, with a few exceptions in Germany — see the linked reference.	Reference tables & the relevant country-specific appendix
	POS systems are created in the production Portal	One POS system per model (not per device) is created in the Portal, and its ID is used as ftPosSystemId in sign requests.	Creating a PosSystem
	PosDealers are invited and connected to POS systems	The PosDealers distributing the device are either invited by their PosCreator or created their accounts themselves, and are connected to the previously created POS system.	PosDealers - Getting Started Guide
	Certification or Attestation is complete	The certification (mandatory if the POS-System is developed for your own use) or the attestation is successfully finished.	Contact our experts
	(Optional): Use of business cases is approved by a tax consultant	A tax expert familiar with your Middleware implementation approves the correct use of receipt, charge item and pay item cases.	Reference tables
	(Optional): DSFinV-K export is approved by a tax consultant	A tax expert familiar with the business sequences implemented via the Middleware approves the content of a sample or live-data DSFinV-K export created via the Middleware or in the fiskaltrust.Portal. Note that structural integrity is already certified, and a marketing package is available from Audicon — see the certification announcement for details.	DSFinV-K Generation
	(Recommended): Open TSE transactions are properly handled	During daily operation, some transactions can stay open in the TSE — most often because the finish transaction does not reach the TSE, due to network errors, an unplugged TSE, or a power outage. If such transactions are still open at the daily closing, the Middleware cannot delete the exported TSE logs (the content of the TAR file), so the TAR grows in size with every export. Because the TAR is stored in the local Middleware database, that database can grow to several gigabytes. By law, the maximum number of open transactions is 500; once that limit is reached, the TSE will not sign any new transactions. To prevent this, we strongly recommend implementing the following process before sending a daily closing receipt: (1) send a Zero-Receipt with TSE info to the queue — the ftState property of the response then contains the CurrentStartedTransactionNumbers; (2) close this array of open transactions using a Failed-Receipt (for multiple transactions).	Single Receipt Creation

Table 1. Integration checklist for POS Creators, listing the steps required to integrate the fiskaltrust.Middleware, their applicable markets, and reference documentation.