When a customer disputes a card payment, the bank often sides with them first. The shop then gathers logs and receipts. That material is easy to argue over because it is rarely a single, checkable fact tied to the exact payment.

This demo shows a technical path: a proof that binds a customer key to a fixed set of fields (amount, currency, parties, time window) so a verifier can run math instead of debating paperwork.

The browser form talks to a small server. The server asks the Affix API to build or check proofs and to store the record. The circuit here is a teaching build: do not paste this into production without your own security review and keys.

Proof generation runs through the API and stores a durable proof record for dispute handling.

Verification can run repeatedly with stable performance because the proof payload is fixed and cacheable.

1. Card details and amount are known at checkout.
2. A proof is generated that commits to hashes of IDs and to amount, currency, and times.
3. The proof is kept (here, via the API) until a dispute.
4. Anyone with the verification key can check the proof. Tampering any committed field breaks the check.

Real deployments still need issuer buy-in, key custody rules, and your own ceremony for trusted setup if you stay on Groth16.

The verifier sees the public inputs inside the proof, not the private key. Typical fields include amount, numeric currency code, timestamps, hashes of merchant and acquirer strings, and a domain tag so one proof cannot be replayed for another bank or scheme.

Acquirer

Bank or processor that settles card money for the shop.

Groth16

A compact proof system. You need a one-off trusted setup per circuit revision.

Issuer

Bank that issued the card to the customer.

Public inputs

Values baked into the proof that the checker sees.

Witness

Secret values used only while building the proof.