AP2 vs MPP
Do you need purchase authority, service payments, or both?
AP2 deals with authorization evidence within commerce. MPP deals with machine payment interactions for services. They are not equivalent retail checkout systems. If you need to prove a shopper authorized a purchase, investigate the mandate and verifier roles. If you are selling metered API access, examine payment methods, intents and service access instead.
What this establishes
A practical way to inspect evidence and make the next merchant decision.
What it cannot establish
Live merchant deployment, private account eligibility, purchase completion or guaranteed AI selection.
The overlap
AP2 deals with authorization evidence within commerce. MPP deals with machine payment interactions for services. They are not equivalent retail checkout systems.
The merchant decision
If you need to prove a shopper authorized a purchase, investigate the mandate and verifier roles. If you are selling metered API access, examine payment methods, intents and service access instead.
Where they overlap.
Where they complement.
Compare roles and implementation work. A shared capability does not make two systems interchangeable.
| Decision dimension | AP2 | MPP |
|---|---|---|
| Layer | Identity & trust | Payments |
| Role | Uses linked checkout/payment mandates and receipts to bind authorization. | Lets agents negotiate and pay for service access across supported payment methods. |
| Status | released | active individual Internet-Draft |
| Version | 0.2.0 | draft-httpauth-payment-01 · normative core; broader SDK/method versions separate |
| Discovery | Outside scope | Payment offers for services |
| Checkout | Authorizes checkout; does not define commerce API | Not a retail checkout model |
| Payment | Mandates and receipts; not a settlement rail | Core role: service access |
| Authorization | Core role | Payment method and intent dependent |
| Transport | Integration with commerce protocols | HTTP-oriented; SDK integration |
| Adoption | Public specification; individual deployments Unknown | Team documents service integrations; not independently transacted |
| What it does not solve | Does not define the catalog API or replace a commerce protocol. | Does not supply retail catalogs, fulfillment or a complete store checkout. |
| Evidence | 3 source record(s) Checked 2026-09-28 public-preview; scope-dependent | 3 source record(s) Checked 2026-09-28 draft; scope-dependent |
Unknown ≠ unsupported. Announcements and product documentation are not proof of your live integration.
Overlap and replacement risk
These entries occupy different layers. They can work together; replacing one with another may leave a commerce, communication or authorization gap. Keep your source of product truth, fulfillment responsibility and payment obligations explicit.
Go to the source.
Primary documentation records what is publicly stated. It does not independently prove outcomes or your account’s eligibility.
Claim scope: Authorization mandates and receipts
Payment authorization within a commerce protocol; catalog API details are out of scope.
Claim scope: Stewardship and integrations
Site states continued standardization within FIDO working groups.
Claim scope: Version metadata and documented changes only; not merchant adoption.
SHA-256 of retrieved source response: 43572d4defa8d53e8ab8dbfe90cc2d6734892aa93fcce009015d73cf21336ad6
Claim scope: Agent payments for web services
Open payment-method-extensible protocol; no retail-wide adoption inferred.
Claim scope: SDK interoperability
MPP team documents x402 exact flows in mppx.
Claim scope: Version metadata and documented changes only; not merchant adoption.
SHA-256 of retrieved source response: fcb287fd83f5a74d9ebf5b06ade3849cbad9ca4581a88fc075554afc28956b69