VENDOR SPECIFICATION · V1.0.0

Bind the provider payee—not just a merchant label.

Canonical payee identity places the exact rail-specific recipient and an explicit verification-evidence reference inside the signed purchase envelope.

NORMATIVE PROFILE

One strict shape, four narrow provider bindings

Every identity uses MANDATESHIELD_PAYEE_IDENTITY_V1, a logical merchant_id, an exact provider binding and a declared verification-evidence reference. Unknown and extra fields are rejected.

{
  "profile": "MANDATESHIELD_PAYEE_IDENTITY_V1",
  "provider": "X402",
  "merchant_id": "merchant_data_api",
  "binding": {
    "network": "eip155:8453",
    "pay_to": "0x1111111111111111111111111111111111111111"
  },
  "verification": {
    "method": "TRUSTED_MERCHANT_MAPPING",
    "verifier": "merchant-registry-production",
    "evidence_ref": "https://registry.example/merchants/merchant_data_api"
  }
}

Download the JSON Schema · Inspect the machine-readable assurance boundary

EXACT BINDINGS

Each rail contributes the identity facts it can actually know

  • x402: selected CAIP-2 network plus exact payTo, tied to a trusted merchant-mapping reference.
  • MPP: canonical HTTPS service origin plus the lowercase Payment method from the challenge.
  • Stripe: configured connected account and merchant account, echoed into the PaymentIntent binding.
  • Custom: configured provider ID and HTTPS service origin with exact same-origin /.well-known/mandateshield-payee.json evidence.

ASSURANCE BOUNDARY

A bound evidence reference is not independent verification

The normalizer validates canonical shape and exact source-field equality. It does not fetch a registry, authenticate a TLS session, verify an x402 or MPP payment credential, certify a Stripe account, or prove settlement. Raw protocol projections remain non-executable. Strict authority and a fresh trusted-gateway consume permit are still mandatory.