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.

Read the API docs Get sandbox access

POS System API

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.

Explore reference

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.

request

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"
  }]
}

signed response

# Press "Send request" and read the
# signed response here.

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.

Create your sandbox CashBox Explore all endpoints

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.

Article 286 CGI lives in the configuration, not in your code.

The ftQueueFR delivers inalterability, security, retention and archiving, the four legal criteria. The table shows the split between the Middleware and your integration.

Local duty	What the Middleware handles	What your code does
Inalterability and security	Signs and chains each transaction, records stay tamper-evident	Calls the same five endpoints
Proof of conformity	Accredited certification backs the compliance components your POS inherits	Presents the certificate at inspections
Retention and archiving	Stores records revision-safe over the legal period with the POS Archive	Nothing, configuration covers this
Period closings	Produces the grand total and period records the law demands	Calls /journal at closing time

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.

REST
gRPC
SOAP (legacy)

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.

What developers ask first.

Straight answers before you commit engineering time.

Does my POS need its own NF525 or LNE certificate?

No. The NF525 certification sits with the fiskaltrust Middleware, audited by the LNE. Your POS sends the same requests as in every market, and merchants receive the certificate as a document.

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.

Read the API docs Request a developer talk

One API.

Five endpoints. The whole checkout.

One request. One signed receipt.

Get sandbox credentials

Send the minimal request

Read the signature

What one request sets in motion.

Capture

Sign

Store

Deliver

Export

Article 286 CGI lives in the configuration, not in your code.

Stable API. Open source. Audit-proof receipts. No vendor lock-in.

Runs where your POS runs.

Local

Cloud

Hybrid

Open source

Integrate us, inherit the certification.

Everything you need before a call.

Documentation

GitHub

Sandbox

Academy

What developers ask first.

Start in the sandbox today.