Turn machine payments into verifiable fiscal events.

At a glance

Five facts, in prose.

Fiscal402 is non-custodial and does not move customer funds. Free during beta at 0 bps. Standard rate after beta is 10 bps (0.1%) of fiscalized volume. High-throughput platforms may use custom contracted rates.

What is Fiscal402?

Fiscal402 is post-settlement fiscal infrastructure for autonomous commerce. It turns machine payments into durable, verifiable fiscal events.

Who is it for?

x402 merchants, agent platforms, marketplaces, ERP systems, and accounting workflows that need EU fiscal evidence after a machine payment has already settled.

What problem does it solve?

Settlement proves that value moved. It does not produce a fiscal record. Fiscal402 sits after payment, persists the event, emits a determination, a UBL 2.1 artifact, and a signed fiscal402.receipt.

What does it support today?

x402 v2 exact on USDC (Base and Ethereum), EU VAT determination, USDC→EUR historical FX, UBL 2.1, Ed25519-signed fiscal402.receipt/1.0.0, and durable fiscal event history. MPP is supported as mpp.settlement/1 evidence. AP2 is supported authorization evidence. US, UK, and Canada tax engines are not production determination.

How can I integrate or verify it?

Start with the integration guide, POST settled x402 evidence to the Fiscal402 API, then retrieve and independently verify the receipt. Protocol specification and verifier source are public.

Read the about page, the facts table, or the verification model.

Settlement ≠ fiscal record

x402 moves the money.Fiscal402 makes the transaction fiscally usable.

The gap

Payment is not the end of the transaction.

Machine payment systems can prove that money moved. Enterprises still need to know what the transaction represented, which jurisdiction applied, which ruleset was used, and whether the evidence can be verified later.

1. PAYMENT SETTLED
2. ↓economic event still unresolved
3. ↓Fiscal402
4. ↓fiscal record

How it works

Settlement first. Fiscal evidence after.

x402 moves value. Fiscal402 observes the settled transfer and makes the event fiscally usable. It does not generate HTTP 402, authorize payment, settle funds, or act as a facilitator.

1. 01

   Settled

   x402 transfer already exists

2. 02

   Observe

   PaymentEvidence, post-settlement

3. 03

   FiscalEvent

   Persist event, parties, provenance

4. 04

   Determine

   EU VAT + engine / ruleset versions

5. 05

   Artifacts

   Exact UBL 2.1 bytes + ledger

6. 06

   Receipt

   fiscal402.receipt/1.0.0

7. 07

   Record

   Query, reconcile, independently verify

System of record

A settlement is temporary. A fiscal record has to survive.

Fiscal402 does not only return a response and forget it. It preserves enough structured evidence to reconstruct how the event was processed.

Reconstructable

Know not just the answer. Know why it was the answer.

Every determination is tied to the event context, evidence sources, engine version and ruleset version used at processing time.

Append-only history

Corrections should create history, not erase it.

Material corrections create new history instead of silently mutating the original record. This is an append-only correction model — not a claim of legal immutability or a blockchain-backed audit log.

EVENT
  │
  ├── determination v1
  │      └── receipt A
  │
  └── correction
         └── determination v2
                └── receipt B

Protocol object

Don't trust the claim. Verify the event.

A Fiscal402 receipt binds the normalized event, fiscal determination and artifacts to a signed payload that can be independently verified. Verification proves cryptographic and structural integrity. It is not a guarantee of tax-authority acceptance.

Trust layer

Verification is local.

Verification uses the receipt, JWKS, and optional bound UBL. No Fiscal402 API call is required. VERIFIED denotes cryptographic integrity, not tax-authority approval.

Integrity

Nothing should disappear between settlement and accounting.

Fiscal402 can identify incomplete or inconsistent fiscal records instead of silently treating them as finished. This is a system capability, not an operator dashboard.

Jurisdiction engine

Global transactions. Explicit fiscal coverage.

Fiscal402 accepts parties anywhere. EU VAT is determined for EU corridors and for non-EU sellers of electronic services into the EU. US, UK, and Canadian tax stay explicit: experimental or manual review. Representation is not a tax claim.

• EU VAT
• B2B / B2C
• Reverse charge
• OSS
• Global sellers
• Historical FX
• UBL 2.1

Fiscal402 produces technical fiscal classification and evidence. This is not tax advice and not a guarantee of tax-authority acceptance.

Coverage

Explicit jurisdiction coverage.

The event model is worldwide. Tax determination is jurisdiction-specific. EU VAT is production. Everything else is labelled as it actually is.

Production remains x402 v2 exact and EU VAT, including qualifying non-EU sellers of electronic services into Europe. Full coverage notes.

Architecture

Worldwide by architecture.Conservative by determination.

Fiscal402 can represent machine-commerce events between parties anywhere. Tax determination runs only where verified jurisdiction rules exist. Today that engine is EU VAT. UK is experimental. US and Canada are provider/review boundaries, not live rate engines.

Payment evidence becomes a fiscal event. The router evaluates the corridor. Receipts issue only when the path is production-eligible. Determination is output, not input.

Current production: x402 ingest + EU VAT + receipt v1 + durable fiscal history.

Fail closed

No verified rule.No invented tax.

Fiscal402 does not turn architectural coverage into fabricated tax output. Manual review is a first-class result.

The FiscalEvent persists. US is a jurisdiction candidate. Determination waits for a verified engine. That is the product working.

Receipt eligibility

A receipt is earned by evidence.

A global FiscalEvent does not automatically produce fiscal402.receipt/1.0.0. Production v1 is issued only on the verified EU VAT path.

1. event normalized

2. ↓

   jurisdiction supported?

3. ↓

   settlement verified?

4. ↓

   valuation available?

5. ↓

   artifacts valid?

6. ↓

   receipt eligible

Only then: fiscal402.receipt/1.0.0

Capabilities

Know coverage before you process.

Platforms can query Fiscal402 without executing a payment. Coverage is returned per layer — event, payment, jurisdiction, receipt — never as a single misleading supported flag.

{
  "seller_country": "US",
  "buyer_country": "NL",
  "supply_type": "digital_service"
}

Platforms

One fiscal hook.Global event model.

Platforms keep payment verification and settlement. Fiscal402 receives the settled economic event, evaluates fiscal coverage, and returns a verifiable fiscal artifact when supported.

Developers

Record a settled x402 payment.

After x402 has settled, POST settlement evidence to Fiscal402. You get a signed fiscal402.receipt. Typed packages are not published on npm — HTTP is the supported path.

const origin = process.env.FISCAL402_ORIGIN ?? "https://api.fiscal402.com";

const response = await fetch(`${origin}/settlements`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "X-Fiscal402-Key": process.env.FISCAL402_MERCHANT_KEY!,
    "Idempotency-Key": "acme-nl-de-1",
  },
  body: JSON.stringify({
    amountUsdc: "1.00",
    txHash: "0xYOUR_SETTLED_TX",
    timestamp: "2026-09-10T12:00:00.000Z",
    payerWallet: "0xPAYER",
    receiverWallet: "0xPAY_TO",
    network: "eip155:1",
    asset: "USDC",
    scheme: "exact",
    consumerCountry: "DE",
    consumerName: "Buyer GmbH",
  }),
});

if (!response.ok) {
  const body = await response.json();
  throw body.error ?? new Error(`Fiscal402 ${response.status}`);
}

const event = await response.json();
// event.id → GET /v1/receipts/:id

Authenticate ingest with X-Fiscal402-Key. Full walkthrough: Quickstart.

x402 · fiscal evidence

Machine payments, then a fiscal record.

x402, EU VAT, UBL 2.1, fiscal receipts, and independent verification are documented as themselves — not as a worldwide tax engine.

• x402 VAT

  EU VAT after machine payments.

• Fiscal receipts

  Payment receipt vs fiscal402.receipt.

• x402 accounting

  Settlement is not a ledger row.

• UBL 2.1

  EN 16931 artifact bound by SHA-256.

• Cross-border

  Global events, explicit tax coverage.

• Embed Fiscal402

  One fiscal hook after settlement.

• Verification

  Independent Ed25519 / JWKS checks.

Independent dimensions

Protocol is not network. Network is not asset. Asset is not jurisdiction.

Fiscal402 keeps these axes separate so a new payment rail does not rewrite tax, and a new jurisdiction does not rewrite payment ingest.

1. PROTOCOL

   x402

2. ≠ NETWORK

   eip155:1

3. ≠ ASSET

   USDC

4. ≠ JURISDICTION

   NL → DE B2C

Pricing

10 bps. Custom at platform scale.

Free during beta at 0 bps — not permanently free. Pricing policy does not imply settlement-integrated fee collection. Fiscal402 currently operates post-settlement. Native x402 exact splits are not supported. Not tax advice. Not a guarantee of tax-authority acceptance.

Production

Run Fiscal402 on a real x402 settlement.

If you operate a machine-commerce service anywhere in the world, Fiscal402 can normalize the settled event and determine tax only where verified rules exist — today, EU VAT including non-EU sellers into Europe.

Your agents can already pay.Make the transactionfiscally usable.