Evidence and verification
A payment record says what happened. Evidence shows who authorized it. Evidence is the network’s own proof, attached to the event exactly as the rail produced it, so anyone can verify it later without trusting you or HalvorAI.
Kinds of evidence
Section titled “Kinds of evidence”| Kind | What it is | Format |
|---|---|---|
ap2.payment_mandate, ap2.checkout_mandate | An AP2 mandate | sd-jwt or kb-sd-jwt |
vi.chain | A Mastercard Verifiable Intent chain | kb-sd-jwt |
tap.signature | A Visa Trusted Agent Protocol request signature | http-signature |
x402.payment_payload, x402.settlement | The x402 payment payload and settlement response | json |
mpp.receipt | A Machine Payments Protocol receipt | json |
stripe.object | A Stripe object snapshot | json |
agentic_token.metadata | Issuer metadata for an agent token | json |
kya.attestation | A know-your-agent provider attestation | jws or sd-jwt |
Each item carries its value and a sha256 digest of the exact bytes. Values larger than 64 KB are stored in object
storage and the event keeps a reference. The evidence helpers package these items for you.
What gets checked
Section titled “What gets checked”Verification runs in the background after ingest and writes one result per evidence item.
| Evidence | Checks include |
|---|---|
| AP2 mandates | The SD-JWT parses, the issuer signature and disclosure hashes are valid, the key-binding token is signed by the holder, the credential is within its lifetime, and for closed mandates the payee, amount and instrument equal the event’s. |
| Verifiable Intent | Each layer is signed by the key the layer above delegated to, both mandates bind the same agent key, and the payment and checkout hashes agree. |
| Visa TAP | The signature input parses, covers the authority and path, was created within the allowed window (eight minutes), has a tag Visa defines, has a nonce not seen before, and verifies against the key directory. |
| x402 payload | It matches the event’s amount, payee and network, has not expired, and for EVM exact payments the typed-data signature recovers the payer. |
| x402 settlement | success matches the event type and a transaction hash is present when settled. |
| Stripe, MPP, agent tokens | Structure only. These are marked producer-asserted, because there is no signature to check. |
Result values
Section titled “Result values”| Result | Meaning |
|---|---|
valid | Every cryptographic and binding check passed. |
invalid | A cryptographic or binding check failed. This raises a high-severity evidence_invalid alert. |
expired | The credential was outside its lifetime when the payment happened. |
unverifiable | No key was available, or the kind has no signature to check. This is not a failure. |
An unknown issuer gives unverifiable, never invalid, so a missing trust anchor does not raise false alarms.
Verification coverage
Section titled “Verification coverage”The dashboard reports verification coverage: the share of events with at least one valid cryptographic result.
It is one of the five numbers your sponsor bank usually asks for. See cases and evidence packs.
Reading evidence
Section titled “Reading evidence”GET /v1/events/{id} returns an event with its evidence and results. Evidence values may contain personal data,
so they are shown only to the analyst, admin and owner roles and to API keys with the events:read scope. Every view
of evidence values is written to the audit log. See roles.