The PAP Verifier Is Live: Merchant-Side Verification for Agentic Commerce

Last week, Sierra and Meta published draft 0.1 of the Personal Agent Protocol. This week, BBVA became the first European bank to join the effort. Thirty-five design partners are at the table, including OpenAI, Visa, Mastercard, and PayPal. The protocol is moving fast.

PAP answers a real question: how does a person's AI agent work with a business on their behalf? The business publishes a discovery document at /.well-known/poppy.json. The agent reads it, opens a session, and the customer signs in through OAuth. One session spans the business's APIs, website, and agent.

But there is a gap the spec does not fill. When the agent shows up with a session token, who verifies it on the merchant's side?

That is what we built.

Two levels of verification

Agentic commerce needs verification at two levels, and they are not the same.

Network level (TAP). When the payment runs on Visa's card network, the network is in the loop. Visa's Trusted Agent Protocol defines how the agent's credentials get checked. Our TAP verifier, live since October 7, independently validates the agent's signature and screens the counterparty against our threat corpus.

Merchant level (PAP). When the business runs its own checkout through Stripe, Shopify, or Meta, there is no card network in the loop. The merchant is on its own. The agent presents a PAP session token, and the business has to decide whether to trust it.

Most agent transactions will live at this second level. The card network verifies the payment. The merchant verifies the business relationship. Both need an independent check.

What the PAP verifier does

Our PAP verifier is live now at POST /v1/pap/verify. One API call, and it checks:

• Session token validity. The PAP session token is a JWT signed by the business's OAuth issuer. We fetch the issuer's keys and verify the signature, expiry, and audience.
• DPoP proof. PAP binds tokens to a key the agent holds, using DPoP. We validate the proof: signature, method and URL binding, and freshness. A stolen token alone does not pass.
• poppy.json discovery. We fetch the business's published /.well-known/poppy.json and validate it against draft 0.1: protocol version, organization identity, OAuth issuer, and scope declarations. If the discovery document does not match the token's claims, that is a finding.
• Replay protection. Every token carries a unique ID. We record it, so a replayed token gets rejected.
• Counterparty screening. The agent's identity and the business's domain are screened against 700K+ threat indicators from 125 monitored marketplaces and 9M+ corpus citations.

The response is a verdict: verified or not, with reasons. No ambiguous middle.

Why this matters now

The early adopters are already publishing. Tilopay, Emora Health, and Rent Our Bins have live poppy.json files. None of the big launch partners publish one yet, which means the window is open: the businesses moving first are the ones defining what "good" looks like.

A merchant that accepts agent traffic without verifying it is trusting the agent to describe itself honestly. That is not a posture. Verification is the posture.

RelayShield is now the verification layer for agentic commerce at both levels: TAP for the network, PAP for the merchant. Flat monthly pricing, pay per verification if you prefer. The endpoint is live today.

---

Originally published at blog.relayshield.net on October 16, 2026.