Payment Networks — VI, Agent Pay, TAP

Mastercard and Visa payment-network protocols — persistent declarations plus session-based attestation tokens.

These protocols have two lives: a persistent declaration at registration (public keys, merchant domains, execution modes — what the agent can do) and session-based attestation tokens at runtime (SD-JWT chains, RFC 9421 signatures — proof that a specific transaction is authorised). Both halves go through the same Verification Gateway SDK.

VI — Verifiable Intent

Mastercard & Google's 3-layer SD-JWT credential chain proving human authorisation for commerce transactions. Two modes: Immediate (user confirms each action, 2-layer chain) and Autonomous (agent delegated, 3-layer chain with constraint enforcement). VI's 8 constraint types (merchant allowlists, payment amounts, budgets, recurrence, line items) map directly to PDLSS boundaries.

You declare: execution mode, agent public key (JWK/PEM), key ID, credential provider, supported mandate types, payment amount constraints, budget limits.

PDLSS pre-fill: Autonomous/Both mode enables self-instantiation; payment amount max flows to autonomous and hard limits; allowed merchants become counterparties; currency mirrored.

{
  "protocols": ["a2a", "vi", "agentpay"],
  "vi": {
    "executionMode": "Autonomous",
    "kid": "key-1",
    "supportedMandateTypes": ["checkout", "payment"],
    "defaultConstraints": {
      "paymentAmount": { "currency": "USD", "max": 10000 }
    }
  }
}

Agent Pay — Mastercard

Mastercard's payment execution protocol using RFC 9421 HTTP Message Signatures. Agents sign every request (browse and purchase tags) using ECDSA P-256 or RSA-PSS; the Mastercard Agent Registry holds the public key for verification. Agent Pay handles the payment rail; VI handles the authorisation chain — they are complementary.

You declare: agent public key, Mastercard Agent ID, signature algorithm, allowed merchant domains, DTVC formats, consumer ID&V method, token binding scope.

PDLSS pre-fill: allowed merchant domains become counterparties; always financial_transaction purpose.

{
  "protocols": ["a2a", "vi", "agentpay"],
  "agentpay": {
    "mastercardAgentId": "mc-agent-12345",
    "signatureAlgorithm": "ecdsa-p256-sha256",
    "allowedMerchantDomains": ["store.example.com"],
    "tokenBindingScope": "per-transaction"
  }
}

TAP — Visa Trusted Agent Protocol

Visa's equivalent of Agent Pay, also using RFC 9421 HTTP Message Signatures. ~85% of the infrastructure is shared with Agent Pay — the only differences are the registry endpoint (Visa's JWKS at mcp.visa.com/.well-known/jwks) and the payment credential format (Intelligent Commerce tokens vs Agentic Tokens). Shares verifier infrastructure with Agent Pay and Web Bot Auth.

You declare: agent public key, Visa Agent ID, signature algorithm, allowed merchant domains, token type (agent-specific or PAR), passkey enrollment.

PDLSS pre-fill: allowed merchant domains become counterparties.

{
  "protocols": ["a2a", "tap"],
  "tap": {
    "visaAgentId": "visa-agent-12345",
    "signatureAlgorithm": "rsa-pss-sha512",
    "allowedMerchantDomains": ["shop.example.com"],
    "tokenType": "agent-specific-token",
    "passkeyEnrolled": true
  }
}

Third-Party Credentials

Agents may arrive with existing credentials from external providers — a Mastercard L1 credential via VI, a DID from an AP2 Credential Provider, or a Visa agent token. AstraSync assigns an ASTRA-ID as the primary identity anchor but accepts and stores third-party credentials alongside it.

Supported formats: DID (Decentralized Identifier), Verifiable Credential (VC), SD-JWT, X.509 certificate. When an agent presents a third-party credential at runtime, the gateway resolves it to the ASTRA-ID and proceeds with normal verification.

Third-party credentials appear as an optional section in the registration form when any Payment Network protocol (VI, Agent Pay, TAP) is selected.

Session-based attestation tokens (runtime)

While agents declare their Payment Network capabilities at registration, the actual attestation tokens are short-lived and flow through the request pipeline during each transaction. They never get stored — the Verification Gateway SDK parses and validates them on every request against the agent's registered persistent metadata.

• VI SD-JWT chains — 3-layer credential chain (Credential Provider → User → Agent) with selective disclosure. Verified against the agent's registered public key and constraint templates.
• Agent Pay / TAP RFC 9421 signatures — HTTP Message Signatures on browse and purchase requests. Verified against Mastercard or Visa agent registries using the declared key ID and algorithm.
• ACP HMAC webhooks — signed webhook payloads from Stripe-backed checkout sessions.
• UCP checkout sessions — short-lived session tokens issued by a UCP merchant to authorise a single checkout flow.

Full cryptographic verification of these tokens (SD-JWT chain validation, RFC 9421 signature checking, constraint enforcement against PDLSS) ships with the Commerce Shield Lambda@Edge adapter. Today the SDK extracts and surfaces the tokens; verification is on the roadmap.