Delivery (/issue Endpoint)
The Delivery component of the Experience Middleware defines the formats and channels through which receipts and invoices generated at the point of sale are transmitted to consumers and business customers.
While fiscalization ensures that every transaction is securely recorded and legally compliant, delivery governs how the resulting document is transferred to its recipient — whether on paper, on a screen, in a digital wallet, or directly into an accounting system.
Supported Delivery Formats
fiskaltrust supports a range of delivery formats that can be combined depending on merchant configuration, market requirements, and customer preference.
Printed Receipt
The traditional paper receipt issued at the point of sale.
- Generated by the POS system and printed on a connected receipt printer.
- Still required or expected in many markets and use cases.
- Fully compatible with the fiskaltrust fiscalization flow: the printed document carries the fiscal data (signatures, QR codes, sequence numbers) required by local regulation.
Digital Receipt
An electronic version of the receipt delivered to the consumer through a digital channel after the transaction has been fiscalized.
- Delivered via QR code, HTTPS link, SMS, email, or the InStore App.
- Linked to the underlying fiscal receipt so that the digital and fiscal documents always correspond.
- Reduces paper consumption and enables downstream interactions such as loyalty, returns, or feedback collection.
Digital receipts are generated by the fiskaltrust.Middleware after the receipt has been signed and journaled. They are stored in fiskaltrust's backend infrastructure and optionally exposed to the customer through the following mechanisms:
- A secure QR code or URL embedded in the physical or on-screen receipt.
- API access using a receipt ID or transaction hash, enabling frontend applications, digital wallets, and loyalty programmes to retrieve and display receipts programmatically.
For implementation details, see the Digital Receipt section.
Structured Invoice & E-invoicing
A machine-readable invoice containing standardized data fields in addition to the human-readable representation.
A structured invoice (also known as e-invoice) describes data available in a structured form rather than just as a visual representation (e.g. PDF). All subsequent processing is simply a conversion of that data — the fiskaltrust.Middleware already outputs data in a structured format.
E-invoicing is the electronic exchange of invoices across B2B, B2G, and B2C transactions, and increasingly between businesses and tax authorities. It is built into the fiskaltrust.Middleware's core process — any merchant already integrated with /sign is ready to use it, with support available directly through the POS system API.
- Used for business-to-business (B2B), business-to-government (B2G), and — in some countries — business-to-consumer (B2C) transactions where the recipient needs to import the invoice into an accounting or ERP system.
- Carries the same fiscal guarantees as a regular receipt while including structured data (item lines, tax breakdowns, buyer information) in a defined format.
- Can be issued alongside or instead of a printed or digital receipt, depending on the customer's request at checkout.
Simplified Invoice / POS Receipt Example
The following example shows a structured invoice request for a simplified invoice or POS receipt transaction.
{
"ftCashBoxID": "00000000-0000-0000-0000-000000000000",
"ftPosSystemId": "00000000-0000-0000-0000-000000000000",
"cbTerminalID": "1",
"cbReceiptReference": "SIMP-0001",
"cbReceiptMoment": "2024-01-01T10:00:00.000Z",
"cbChargeItems": [
{
"Quantity": 1.0,
"Description": "Product A",
"Amount": 12.50,
"VATRate": 20.0,
"ftChargeItemCase": "0x0000000000000001"
}
],
"cbPayItems": [
{
"Quantity": 1.0,
"Description": "Cash",
"Amount": 12.50,
"ftPayItemCase": "0x0000000000000001"
}
],
"ftReceiptCase": "0x0000000000000001"
}
E-invoice Payload Examples
The following examples show e-invoice requests for different transaction types.
B2B E-invoice
{
"ftReceiptCase": 35184372088836,
"cbReceiptReference": "Ecomm-B2B-IC-001-866afb78-b77c-46d2-b77c-3d4756884409",
"cbReceiptMoment": "{{$isoTimestamp}}",
"cbCustomer": {
"CustomerVATId": "DE123456789",
"CustomerName": "EU Buyer GmbH",
"CustomerStreet": "Sample Street 1",
"CustomerZip": "12345",
"CustomerCity": "Berlin",
"CustomerCountry": "DE"
},
"cbChargeItems": [
{
"Quantity": 10,
"Description": "Electronic Gadgets",
"Amount": 500,
"VATRate": 0,
"ftChargeItemCase": 35184372093208,
"ftChargeItemCaseData": {
"GR": {
"exemptionReason": 2
}
}
}
],
"cbPayItems": [
{
"Quantity": 1,
"Description": "Non-cash Payment",
"Amount": 500,
"ftPayItemCase": 35184372088834
}
],
"ftReceiptCaseData": {
"GR": {
"mydataoverride": {
"invoice": {
"invoiceHeader": {
"deliveryMethod": 2,
"currencyCode": "EUR",
"otherInvoiceHeader": {
"thirdPartyVATId": "DE123456789"
},
"invoiceType": "1.1"
}
}
}
}
}
}
B2C E-invoice
{
"ftReceiptCase": 35184372088836,
"cbReceiptReference": "Ecomm-B2C-001-866afb78-b77c-46d2-b77c-3d4756884409",
"cbReceiptMoment": "{{$isoTimestamp}}",
"cbCustomer": {
"CustomerVATId": "",
"CustomerName": "John Doe",
"CustomerStreet": "",
"CustomerZip": "",
"CustomerCity": "",
"CustomerCountry": "GR",
"CustomerEmail": "john.doe@example.com"
},
"cbChargeItems": [
{
"Quantity": 1,
"Description": "Software License",
"Amount": 100,
"VATRate": 22,
"ftChargeItemCase": 35184372088851
}
],
"cbPayItems": [
{
"Quantity": 1,
"Description": "Non-cash Payment",
"Amount": 124,
"ftPayItemCase": 35184372088834
}
],
"ftReceiptCaseData": {
"GR": {
"mydataoverride": {
"invoice": {
"invoiceHeader": {
"deliveryMethod": 1,
"currencyCode": "EUR",
"invoiceType": "11.1"
}
}
}
}
}
}
Delivery from a Point-of-Sale Perspective
From the POS perspective, delivery is the final step of the checkout flow. After items have been entered, the receipt has been fiscalized, and payment has been processed, the POS triggers the appropriate delivery channel(s).
A typical flow:
- The POS sends the receipt to the fiskaltrust.Middleware for fiscalization.
- The Middleware returns a fiscalized receipt with all required fiscal data.
- Depending on the customer's selection and the merchant's configuration, the POS triggers one or more delivery options:
- Print the receipt on the connected printer.
- Generate a digital receipt and present it as a QR code, link, or message, or deliver it via the InStore App.
- Issue a structured invoice for a business customer.
- Submit an e-invoice through the relevant national or European channel (where supported).
- The POS records which delivery options were used so that the transaction is fully traceable.
The POS integrates once with fiskaltrust to access all supported delivery formats, and selects the format appropriate for each transaction.
Delivery from a General Perspective
From a broader perspective, the delivery layer provides consumers and business customers with a consistent, standards-based mechanism to receive proof of purchase, while keeping merchants compliant with local fiscal and invoicing rules.
- Consumers can select between paper and digital receipt formats, and interact with the digital receipt after the transaction (for example to access warranty information or initiate a return).
- Business customers can request a structured invoice or e-invoice for direct import into their accounting system.
- Merchants benefit from a single integration covering all delivery formats, eliminating the need for separate per-channel or per-market solutions.
- Tax authorities receive fiscally guaranteed documents regardless of the delivery channel used.
By consolidating these formats under a single delivery layer, the Experience Middleware supports both current paper and digital receipt scenarios and future structured invoice and e-invoicing requirements through one coherent integration.
e-Delivery
e-Delivery refers to having a defined digital channel for communicating and exchanging documents such as invoices and receipts. Common channels include email — a widely adopted digital protocol — or regulated networks such as Peppol, mandated in several countries for B2B and B2G document exchange.
It is important to distinguish between the format (the structured data representation), the delivery channel (how the document reaches the recipient), and the mandate (the local regulatory requirement defining which channel must be used). A market may require physical printing today, email tomorrow, or a specific network protocol in the future — delivery rules evolve with local regulation.
fiskaltrust supports the creation and conversion of structured document formats across markets. The actual delivery to the recipient, however, is handled outside the Middleware in line with the applicable local requirements.
Intended Audience for Delivery Integration
Delivery integration is primarily relevant for:
- PosCreators who want to offer merchants a complete set of receipt and invoice delivery options without implementing each format independently.
- PosDealers who configure delivery channels for merchants across different markets and customer segments.
- PosOperators who need to provide flexible, compliant checkout experiences across paper, digital, and structured document formats.