One API.
Fiscal compliance across EU markets.
The open-source fiskaltrust.Middleware signs, chains, journals and exports under each country's law. You call the POS System API. We keep the country logic current.
POST /v2/sign{ "cbReceiptReference": "S-2026-04417", "cbChargeItems": [ ... ], "cbPayItems": [ ... ]}200 OK signed · chained · journaled{ "ftSignatures": [ ... ], "ftReceiptIdentification": "ft2A#8841"}- POS code changes when laws move
- 0
- Endpoints in the POS System API
- 5
- Live EU markets, one interface
- 7
- POS integrations in production
- 800+
Five endpoints. The whole checkout.
One integration covers signature creation, receipt chaining, journaling, export and compliance logic across EU markets. You send the transaction. The Middleware applies the local rules and returns the signature elements your receipt must print.
- /echo
- Connectivity and health check, verifies Middleware version and capabilities.
- /pay
- Execute and monitor payment processing, timeouts and method allocation.
- /sign
- Fiscalise the receipt via the SCU under national rules.
- /issue
- Generate receipt output and track its delivery state.
- /journal
- Export journals and audit data in the national format.
One request. One signed receipt.
The sandbox accepts the all-zero POS System ID, so you test without registration. Fallback tagging fills the receipt case values for you. Copy, send, read the signature.
Get sandbox credentials
Create a sandbox CashBox in the Portal and copy the x-cashbox-id and x-cashbox-accesstoken values.
Send the minimal request
Authenticate through headers and add a fresh x-operation-id.
Read the signature
The response returns the signature elements your receipt must print.
POST /v2/sign
x-cashbox-id: <from the Portal>
x-cashbox-accesstoken: <from the Portal>
x-operation-id: <fresh UUID>
{
"cbReceiptReference": "my-first-receipt",
"ftPosSystemId": "00000000-0000-0000-0000-000000000000",
"cbChargeItems": [{
"Amount": 21.00,
"Description": "Coffee beans",
"VATRate": 20
}],
"cbPayItems": [{
"Amount": 21.00,
"Description": "Cash"
}]
}# Press "Send request" and read the
# signed response here.200 OK signed · chained · journaled
{
"ftSignatures": [ ... ],
"ftReceiptIdentification": "ft2A#8841"
}The signed response carries everything a compliant receipt needs: the identification, the signature block and the state. Your production setup swaps the all-zero ID for a registered ftPosSystemId and a market-specific receipt case.
What one request sets in motion.
You send the transaction once. The Middleware runs the full compliance lifecycle behind the response.
Capture
POS sends the transaction over REST or gRPC.Sign
The SCU applies the national fiscal rules.Store
Revision-safe archive per local retention rules, 10+ years.Deliver
Receipt on paper, by QR, email, SMS or wallet.Export
Audit-ready journals in the national format, on demand.
Verifactu and TicketBAI live in the configuration, not in your code.
Two regimes govern Spanish tills. Verifactu covers the common territory with 2027 deadlines, TicketBAI runs live in the Basque provinces. The table shows the split between the Middleware and your integration.
| Local duty | What the Middleware handles | What your code does |
|---|---|---|
| Verifactu signing and chaining | Signs and hash-chains each billing record per the SIF requirements, QR included | Calls the same five endpoints |
| The 2027 calendar | Compliance ships before the deadlines: 1 January 2027 for corporate taxpayers, 1 July 2027 for the rest | Ships integrations now, ahead of the rush |
| TicketBAI | Handles the signed, chained invoicing the Basque provinces demand today | Calls the same five endpoints |
| AEAT reporting | Carries the record submission the Verifactu mode defines | Nothing, configuration covers this |
Stable API. Open source. Audit-proof receipts. No vendor lock-in.
Runs where your POS runs.
The Middleware is modular: Queue, SCU and helpers. Pick the deployment matching your architecture and switch later without touching your integration.
Local
Windows, Linux, macOS and Android, as a foreground service or in kiosk mode. Signing works offline.
Cloud
Hosted in national Azure data centres, meeting residency requirements per market and scaling with your rollout.
Hybrid
POS logic on the device, signing and reporting in the cloud. The common choice for mixed estates.
Open source
Full Middleware code on GitHub, version-controlled and documented. You audit what signs your receipts.
Integrate us, inherit the certification.
Each market audits fiskaltrust once. Your POS system builds on those certifications without running its own audit per country.
| Market | Regulation | Handled by the Middleware |
|---|---|---|
| Austria | RKSV | Signature creation, DEP journal, FinanzOnline flows |
| Germany | KassenSichV | TSE connection (hardware and cloud), DSFinV-K export |
| Italy | Registratore Telematico | Telematic transmission of corrispettivi to the AdE |
| France | NF525 | Certified chaining and cumulative counters, LNE-audited |
| Spain | Verifactu · TicketBAI | Record signing and reporting, national and Basque regimes |
| Portugal | SAF-T PT | AT-certified processing, ATCUD and QR codes on receipts |
| Greece | myDATA | Country-specific fiscalisation and reporting |
| *Belgium | GKS 2.0, FDM v2 | Built on the FDM black box and a VAT signing card. GKS 2.0 current generation |
| *Poland | CRK, KSeF | Report to the CRK. KSeF covers e-invoicing |
| *Denmark | SAF-T DK | Audit-ready SAF-T export on demand. |
*On the roadmap: three regimes we track for expansion. Not current Middleware coverage.
Everything you need before a call.
Judge feasibility and fit on your own terms. The stack is documented, public and testable today.
Documentation
Read the docsFull API reference, integration guides and error semantics in English at docs.fiskaltrust.eu.
GitHub
Browse the reposThe Middleware source, launcher, devkit and demo implementations, in the open.
Sandbox
Get accessA near-full copy of the live system. Sign test receipts without legal obligation.
Academy
See the programStructured onboarding for your team, from first request to certified rollout.
What developers ask first.
Straight answers before you commit engineering time.
Verifactu moved to 2027. Should I wait?
No. The vendor duty runs ahead of the merchant deadline, and merchants pick their software before the waves. Integrations built now sell through 2026 and 2027.
How long does an integration take?
First signed receipt in the sandbox in minutes, through the quickstart above. Production readiness depends on your POS architecture. Most partners ship within weeks, not months.
Do I need the Academy to start?
No. The sandbox, the docs and the source are open and free. The Academy is the certification program for partner status, useful after your integration stands, not before.
What happens when a regulation changes?
We update the Middleware centrally. Updates are version-controlled and backward compatible. Your POS code stays untouched.
How do I add a new country?
Configure a new SCU type for the target market. The API stays identical, so expansion is configuration, not re-engineering.
Is the free tier the full product?
The open-source Middleware is free and carries the full compliance logic. Paid products add cloud hosting, archiving, digital receipts and support.
Does the same API cover e-invoicing?
Yes. Structured e-invoices travel over Peppol through the same integration, aligned with the ViDA rollout across the EU.
Which protocols do you support?
REST and gRPC for new integrations. SOAP remains available for legacy systems.
Start in the sandbox today.
Sign your first test receipt before lunch. When you want a second pair of eyes on your architecture, our developers talk to yours.