What Fiscal402 is
Payment settlement proves that value moved. It does not produce a fiscal record. Fiscal402 sits after settlement and turns machine-payment evidence into an EU VAT determination, a UBL 2.1 invoice, a ledger row and a signed fiscal402.receipt.
The current production path is x402 v2 exact → EU VAT. Other payment protocols and jurisdictions are architecture, not live product.
What works now
| Layer | Current |
|---|---|
| Payment protocol | x402 v2 exact, post-settlement |
| Custody | None — observation only |
| Jurisdiction | EU VAT (eu-vat-oss-2026.09) |
| VIES | Recorded where a VAT ID is supplied |
| FX | USDC → EUR at settled_at |
| Invoice | UBL 2.1, SHA-256 of exact UTF-8 bytes |
| Receipt | fiscal402.receipt / 1.0.0 |
| Signature | Ed25519, JWKS |
What Fiscal402 does not do
- Hold merchant or buyer funds.
- Generate HTTP 402 payment requirements.
- Settle, route or split the payment.
- Act as an x402 facilitator.
- File a VAT return, give tax advice, or guarantee tax-authority acceptance.
- Treat a wallet address as a legal person or establishment.
Public HTTP
| Method | Path | Use |
|---|---|---|
| POST | /settlements | Ingest settlement evidence |
| GET | /settlements/:id | Read the fiscal record |
| GET | /settlements/:id/ubl | Fetch the bound UBL document |
| GET | /v1/receipts/:id | Fetch fiscal402.receipt |
| GET | /.well-known/jwks.json | Signing keys |
| POST | /v1/compliance/evaluate | Sandbox classification |
Where it is going
The long-term primitive is one verifiable fiscal event, independent of how value moved. Additional payment adapters and jurisdiction engines are planned. They are not current.