Two different questions: authentication and authorization
The most common failure in payment verification is collapsing two questions into one. Authentication asks who is this party? It is answered with cryptography and credentials: a signature that verifies against a known key, a device attestation, a session bound to a biometric unlock. Authorization asks a completely different question — is this authenticated party permitted to do this specific thing? That is answered by policy and by the scope of the authority the user actually granted.
An agent can be perfectly authenticated and still wholly unauthorized. Its key may be genuine, its request well-formed, its signature valid — and the purchase still outside anything the user ever approved: wrong merchant category, wrong amount, an authority that expired last week. A verifier that stops at ‘the signature checks out’ has answered only the first question. In agent payments the second one carries most of the risk, because the party presenting valid credentials is software that can be induced to act against its principal’s interest without its keys ever being stolen.
The authority chain back to the user
Every agent-initiated payment should be traceable, by verification rather than by assumption, to a human decision. The chain has links: a user authenticated to their wallet or account provider; that user granting a scoped authority to a named agent; the agent presenting a request that falls inside that scope; and the specific transaction being covered by the specific grant, not merely by some grant.
Verifying the chain means checking each link and each join. A grant issued to agent A does not authorize agent B, even if B is operated by the same vendor. A grant made under one user session does not survive that user revoking access. And critically, the chain must be checked toward the principal: start from the transaction and walk back to a human act, rather than starting from a credential and assuming a human stands behind it. Delegation adds depth — an orchestrating agent invoking a sub-agent creates another link, and unverified depth is where authority silently widens.
Validating credentials, chains, and trust anchors
Verifying a credential is more than a signature check. A signature tells you that the holder of some private key produced this data. Turning that into an identity requires anchoring: the key must chain, through certificates or an issuer registry or a resolvable identifier document, to a trust anchor the verifier independently decided to trust. Everything hangs on that anchor, and it must be configured, not discovered from the message being verified: a credential that supplies its own root of trust proves nothing.
The practical checklist is unglamorous and each item has caused real incidents: the signature algorithm is one you accept (never one the message names for you); the chain terminates at a configured anchor; every certificate in the path is within its validity window; the credential’s subject really is the party making the request; and the credential’s stated purpose covers payments. A correctly signed credential presented by someone other than its subject is a replayed credential, not an identity.
Freshness: expiry and revocation
Credentials are statements about the past. A certificate issued three months ago asserts what was true then; keys get compromised, employees leave, agents get decommissioned, and users revoke access. Verification therefore has a time dimension: is this credential still good right now?
Expiry is the cheap half — a date comparison, worth doing always, with attention to clock skew and to the fact that a short-lived credential is safer precisely because it limits how wrong a stale answer can be. Revocation is the expensive half. Status can be pulled from a published revocation list, queried from a status endpoint, or read from a compact status registry, and each option trades freshness against latency and availability. The design question that matters is what happens when the status source is unreachable inside your payment window. Failing open quietly converts a revoked agent into a spending one; failing closed converts a status outage into an outage of your own. Pick per risk tier and state the choice explicitly.
Verifying the merchant, not just the payer
Verification is usually described as the network checking the payer. In agent payments the arrow points both ways, and the neglected direction is more dangerous. A human shopper has weak but real defenses against an impostor storefront — the look of the page, an odd URL, a gut feeling. An agent has none of that. It will pay whatever endpoint its instructions and its search results led it to.
So the agent side needs its own verification: the merchant’s domain genuinely controlled by the entity it names, its payment endpoint presenting a valid certificate for that domain, its merchant identity signed by an acquirer or registry the wallet recognizes, and the party that will actually be credited matching the party the user intended to pay. Homograph domains and lookalike checkout endpoints are cheap to produce and invisible to a system that only verifies the payer. Where a merchant cannot be verified, that is itself a signal.
Step-up authentication and when to demand it
Step-up is deliberate friction: pausing the flow to obtain a fresh, human-present authentication — a biometric confirmation, a device prompt, a challenge from the issuer — before proceeding. It is powerful and it is expensive, because every step-up costs conversion and trains users toward reflexive approval when overused. The discipline is to trigger on risk, not on ritual.
Sensible triggers are all forms of ‘something about this transaction sits outside what the user already approved’: an amount above the granted ceiling, a merchant or category outside the authority’s scope, a first transaction with an unfamiliar counterparty, a new device or agent instance, an authentication that has gone stale, or a risk engine flagging anomalous velocity. Step-up should escalate to the human, not to the agent — a challenge an agent can answer on the user’s behalf verifies nothing about user presence. Regulated flows may separately require strong customer authentication with its own exemption rules; treat those as a floor, not as your whole policy.