payment controls · synthetic reference

Policy control, not payment processing.

Run a bounded policy check over a canned payment fixture and inspect the signed decision evidence it returns. The useful infrastructure is the control boundary: a decision can be checked and recorded without pretending that Aadya moved money.

Run the policy fixture Read the boundary first
01 · run the control

Inspect the decision, not a checkout.

The evaluator checks the synthetic fixture's declared payee and account binding, exact-decimal amount ceiling, Verification of Payee status, risk decision, freshness, validity window, and transaction-binding digest.

A pass produces an Ed25519-signed, minimised policy-decision receipt. The demo also checks that a field flip and a re-sign under an untrusted key are rejected against the pinned public anchor.

public fixture

Synthetic €50 policy check

No form data is collected. The button requests the fixed server-side fixture and displays only selected decision and integrity fields.

Ready.

02 · exact scope

What a green result means—and what it does not.

It demonstrates

A reproducible policy evaluation over synthetic claims, a minimised signed decision receipt, and anchored integrity checks that detect tampering and wrong-key re-signing.

It does not demonstrate

A wallet presentation, issuer trust, holder consent or binding, transaction-data-bound OID4VP, SCA, bank authorisation, processor connectivity, clearing, or settlement.

  • The fixture is canned. Its amount, payee, risk decision, and evidence timestamps are synthetic inputs maintained for repeatable testing.
  • The clock is pinned. Evaluation occurs at the fixture's validity start so the sample remains reproducible; it says nothing about today's payment conditions.
  • The receipt is a backend policy record. It is not a wallet, bank, PSP, SCA, payment-authorisation, or settlement record.