TAP · IMPLEMENTATION GUIDE

TAP-shaped evidence adapter checklist

Evaluate normalized TAP-shaped RFC 9421-style evidence with transaction policy, freshness and replay controls.

What the protocol establishes

MandateShield accepts a normalized component projection; it does not parse raw Visa structured fields or implement the full Visa trust-store profile. Keep that processing external and treat recognized-agent evidence as one input, not the complete authorization decision.

Official Visa TAP specification

Five checks before execution

  1. Normalize upstream TAP fields, then verify the projected signature against an account-pinned key.
  2. Check created, expiry, nonce, authority and path binding.
  3. Confirm the signature tag matches browsing or payment intent.
  4. Evaluate amount, currency, merchant and user-approved limits.
  5. Store and atomically reject replayed transaction identifiers.

The gap MandateShield closes

A recognized agent can still submit a transaction outside the specific amount, merchant or time window the user approved.

MandateShield normalizes execution facts and returns a deterministic decision with exact findings. Strict v2 verifies supported evidence and returns an ES256-signed receipt with public transparency; it complements the protocol's wider trust and settlement chain.

Test the normalized payment boundary

No account and no payment credentials required. Change the amount, merchant or consent and inspect the machine-readable result.

Open free validator →