Eine API.
Fiskal-Compliance in allen EU-Märkten.
Die fiskaltrust.Middleware ist Open Source. Sie signiert, verkettet, protokolliert und exportiert nach dem Recht des jeweiligen Landes. Sie rufen die POS System API auf. Wir halten die Länderlogik aktuell.
POST /v2/sign{ "cbReceiptReference": "S-2026-04417", "cbChargeItems": [ ... ], "cbPayItems": [ ... ]}200 OK signed · chained · journaled{ "ftSignatures": [ ... ], "ftReceiptIdentification": "ft2A#8841"}- Änderungen am Kassencode bei Gesetzesänderungen
- 0
- Endpunkte in der POS System API
- 5
- Live-Märkte in der EU, eine Schnittstelle
- 7
- POS-Integrationen im Live-Betrieb
- 800+
Fünf Endpunkte. Der ganze Kassiervorgang.
Eine Integration deckt Signaturerstellung, Belegverkettung, Journalisierung, Export und Compliance-Logik in allen EU-Märkten ab. Sie senden die Transaktion. Die Middleware wendet die lokalen Regeln an und liefert die Signaturelemente zurück, die Ihr Beleg drucken muss.
- /echo
- Verbindungs- und Funktionsprüfung, verifiziert Middleware-Version und Funktionsumfang.
- /pay
- Zahlungsabwicklung ausführen und überwachen, Timeouts und Zahlungsartenzuordnung.
- /sign
- Den Beleg über die SCU nach nationalem Recht fiskalisieren.
- /issue
- Belegausgabe erzeugen und den Zustellstatus verfolgen.
- /journal
- Journale und Prüfdaten im nationalen Format exportieren.
Eine Anfrage. Ein signierter Beleg.
Die Sandbox akzeptiert die POS-System-ID aus lauter Nullen, Sie testen also ohne Registrierung. Fallback-Tagging befüllt die Receipt-Case-Werte für Sie. Kopieren, senden, Signatur lesen.
Sandbox-Zugangsdaten holen
Legen Sie im Portal eine Sandbox-CashBox an und kopieren Sie die Werte x-cashbox-id und x-cashbox-accesstoken.
Minimale Anfrage senden
Authentifizieren Sie sich über Header und ergänzen Sie eine neue x-operation-id.
Signatur lesen
Die Antwort liefert die Signaturelemente, die Ihr Beleg drucken muss.
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.Die signierte Antwort enthält alles, was ein konformer Beleg braucht: die Identifikation, den Signaturblock und den Status. Im Produktivbetrieb ersetzen Sie die Null-ID durch eine registrierte ftPosSystemId und einen marktspezifischen Receipt Case.
Was eine Anfrage alles auslöst.
Sie senden die Transaktion einmal. Die Middleware durchläuft hinter der Antwort den gesamten Compliance-Lebenszyklus.
Erfassen
Das Kassensystem sendet die Transaktion per REST oder gRPC.Signieren
Die SCU wendet die nationalen Fiskalregeln an.Speichern
Revisionssicheres Archiv nach den lokalen Aufbewahrungsfristen, 10+ Jahre.Zustellen
Beleg auf Papier, per QR-Code, E-Mail, SMS oder Wallet.Exportieren
Prüffertige Journale im nationalen Format, auf Abruf.
Die RKSV steckt in der Konfiguration, nicht in Ihrem Code.
Die ftQueueAT und die österreichische Signaturerstellungseinheit übernehmen die gesamte RKSV-Regelung. Die Tabelle zeigt die Aufteilung zwischen der Middleware und Ihrer Integration.
| Lokale Pflicht | Was die Middleware übernimmt | Was Ihr Code tut |
|---|---|---|
| RKSV-Signatur und Verkettung | Signiert jeden Beleg über eine zertifizierte Signatureinheit und verkettet das DEP | Ruft dieselben fünf Endpunkte auf |
| Belegerteilungspflicht | Liefert den signierten Beleg für Druck oder digitale Zustellung zurück, inklusive QR-Code-Inhalt | Stellt die Antwort dar oder leitet sie weiter |
| FinanzOnline-Meldungen | Registrierungs- und Lebenszyklus-Ereignisse der Signatureinheit werden mit dem Produkt Notifications automatisch gemeldet | Nichts, die Konfiguration deckt das ab |
| DEP-Export | Erstellt das Datenerfassungsprotokoll für Prüfungen über /journal und das Portal | Ruft /journal bei Bedarf auf |
Stabile API. Open Source. Revisionssichere Belege. Keine Anbieterbindung.
Läuft dort, wo Ihre Kasse läuft.
Die Middleware ist modular: Queue, SCU und Helper. Wählen Sie die Bereitstellung, die zu Ihrer Architektur passt, und wechseln Sie später, ohne Ihre Integration anzufassen.
Lokal
Windows, Linux, macOS und Android, als Vordergrunddienst oder im Kiosk-Modus. Das Signieren funktioniert offline.
Cloud
In nationalen Azure-Rechenzentren gehostet, erfüllt die Anforderungen an den Datenstandort je Markt und wächst mit Ihrem Rollout.
Hybrid
Kassenlogik auf dem Gerät, Signieren und Meldungen in der Cloud. Die übliche Wahl für gemischte Umgebungen.
Open Source
Der vollständige Middleware-Code liegt auf GitHub, versioniert und dokumentiert. Sie prüfen selbst, was Ihre Belege signiert.
Integrieren Sie uns, erben Sie die Zertifizierung.
Jeder Markt prüft fiskaltrust einmal. Ihr Kassensystem baut auf diesen Zertifizierungen auf, ohne pro Land ein eigenes Audit zu durchlaufen.
| Markt | Regelung | Von der Middleware übernommen |
|---|---|---|
| Österreich | RKSV | Signaturerstellung, DEP-Journal, FinanzOnline-Abläufe |
| Deutschland | KassenSichV | TSE-Anbindung (Hardware und Cloud), DSFinV-K-Export |
| Italien | Registratore Telematico | Telematische Übermittlung der corrispettivi an die AdE |
| Frankreich | NF525 | Zertifizierte Verkettung und kumulierte Zähler, von LNE geprüft |
| Spanien | Verifactu · TicketBAI | Signieren und Melden von Datensätzen, nationale und baskische Regelung |
| Portugal | SAF-T PT | AT-zertifizierte Verarbeitung, ATCUD und QR-Codes auf Belegen |
| Griechenland | myDATA | Länderspezifische Fiskalisierung und Meldung |
| *Belgien | GKS 2.0, FDM v2 | Aufbauend auf der FDM-Blackbox und einer MwSt-Signaturkarte. GKS 2.0 als aktuelle Generation |
| *Polen | CRK, KSeF | Meldung an die CRK. KSeF deckt die E-Rechnung ab |
| *Dänemark | SAF-T DK | Prüffertiger SAF-T-Export auf Abruf. |
*In der Roadmap: drei Regelungen, die wir für den Ausbau beobachten. Keine aktuelle Abdeckung durch die Middleware.
Alles, was Sie vor einem Gespräch brauchen.
Beurteilen Sie Machbarkeit und Eignung nach Ihren eigenen Maßstäben. Der Stack ist dokumentiert, öffentlich und schon heute testbar.
Dokumentation
Dokumentation lesenVollständige API-Referenz, Integrationsleitfäden und Fehlersemantik auf Englisch unter docs.fiskaltrust.eu.
GitHub
Repositories ansehenDer Middleware-Quellcode, Launcher, Devkit und Demo-Implementierungen, offen einsehbar.
Sandbox
Zugang erhaltenEine nahezu vollständige Kopie des Live-Systems. Testbelege signieren, ohne rechtliche Verpflichtung.
Academy
Programm ansehenStrukturiertes Onboarding für Ihr Team, von der ersten Anfrage bis zum zertifizierten Rollout.
Was Entwickler zuerst fragen.
Klare Antworten, bevor Sie Entwicklungszeit investieren.
Wo liegt die RKSV-Logik?
In der österreichischen Queue und der Signaturerstellungseinheit innerhalb der Middleware. Ihre Kasse sendet dieselben Anfragen wie in jedem anderen Markt, die Konfiguration erzeugt RKSV-konforme Ausgaben.
Wie lange dauert eine Integration?
Den ersten signierten Beleg in der Sandbox haben Sie in wenigen Minuten, über den Quickstart oben. Die Produktionsreife hängt von Ihrer Kassenarchitektur ab. Die meisten Partner gehen innerhalb von Wochen live, nicht Monaten.
Brauche ich die Academy, um zu starten?
Nein. Sandbox, Dokumentation und Quellcode sind offen und kostenlos. Die Academy ist das Zertifizierungsprogramm für den Partnerstatus, sinnvoll nach Ihrer fertigen Integration, nicht davor.
Was passiert, wenn sich eine Vorschrift ändert?
Wir aktualisieren die Middleware zentral. Updates sind versioniert und abwärtskompatibel. Ihr Kassencode bleibt unberührt.
Wie ergänze ich ein neues Land?
Konfigurieren Sie einen neuen SCU-Typ für den Zielmarkt. Die API bleibt identisch, die Expansion ist also Konfiguration und kein Neuaufbau.
Ist die kostenlose Stufe das volle Produkt?
Die Open-Source-Middleware ist kostenlos und enthält die gesamte Compliance-Logik. Kostenpflichtige Produkte ergänzen Cloud-Hosting, Archivierung, digitale Belege und Support.
Deckt dieselbe API auch die E-Rechnung ab?
Ja. Strukturierte E-Rechnungen laufen über Peppol durch dieselbe Integration, abgestimmt auf den ViDA-Rollout in der EU.
Welche Protokolle unterstützen Sie?
REST und gRPC für neue Integrationen. SOAP bleibt für Altsysteme verfügbar.
Starten Sie heute in der Sandbox.
Signieren Sie Ihren ersten Testbeleg noch vor dem Mittagessen. Wenn Sie eine zweite Meinung zu Ihrer Architektur wünschen, sprechen unsere Entwickler mit Ihren.