Separate the layers of a purchase
Consider an agent buying a research report for an illustrative $2. The buyer must know which report is offered, whether the user approved it and how the seller accepts payment. After payment, the seller must provide the report. A successful response at one stage does not establish that the whole purchase succeeded.
The first layer is commerce: discovery, pricing, checkout updates and fulfillment. The second is authorization: evidence that the agent may purchase this item using this payment credential. The third is the payment exchange: how the buyer receives requirements and submits proof or a credential. The underlying rail then processes or settles the transfer.
AP2 v0.2 explicitly operates within a commerce protocol and defines checkout and payment mandates. MPP describes payment for web services with an extensible approach to methods. x402 addresses paying for resources in an HTTP request flow. Those scopes explain why comparing only the word payment produces misleading results. [1] [2]
Where the standards fit
Scroll the table to compare all columns.
| Layer | Question | Starting point |
|---|---|---|
| Commerce | What can be bought and how is checkout updated? | A documented merchant commerce interface |
| Authority | Who approved this checkout and payment? | AP2 v0.2 mandates |
| Web payment exchange | What payment does this service require? | x402 or MPP for its supported method |
| Underlying rail | How is value processed or settled? | The selected card or blockchain implementation |
| Delivery | Did the buyer receive the result? | Seller fulfillment and application receipts |
Compare documented roles using one purchase
Ask what each participant receives and verifies. In the report purchase, a merchant needs evidence that the agent can buy the offered report. A credential provider needs evidence that the payment credential can be used for that checkout. The service accepting the request needs the correct payment information for its supported method.
The table is a scope comparison, not a ranking. AP2 is identified by its published v0.2 specification. For MPP and x402, record the exact specification and SDK versions in your implementation. The protocol name alone is insufficient evidence that buyer and seller interpret the same messages.
MPP also abbreviates Merchant Payment Processor in the AP2 specification. That role is separate from the Machine Payments Protocol. In a system diagram, use the full name wherever context could be ambiguous. A payment processor can participate in AP2 without implementing the Machine Payments Protocol. [1]
Compare scope before features
Scroll the table to compare all columns.
| Standard | Purpose | Participants | Evidence to pin |
|---|---|---|---|
| AP2 v0.2 ↗ | Linked checkout and payment authorization | Shopping agent, credential provider, merchant, processor, trusted surface | Mandate types, versions, signatures and verifiers |
| x402 ↗ | Payment for API or digital resources | Buyer, seller, any facilitator | Protocol revision, scheme and network |
| Machine Payments Protocol ↗ | Extensible web-service payment exchange | Client, service, method-specific components | Supported method and client/server revisions |
| Commerce interface ↗ | Product, checkout and fulfillment coordination | Buyer channel and merchant backend | Checkout capability and state transitions |
Keep checkout interfaces distinct from authority
A commerce interface can expose product selection, checkout state and fulfillment details. An authorization standard can bind permission to a checkout. The interfaces need a shared understanding of the transaction, but they need not own the same responsibilities.
For the report, a catalog response may establish the edition and advertised price. A later checkout may add tax or change availability. Approving a catalog description is therefore different from approving the final purchase. Record which object the approval covers and recheck it when the checkout changes. This is implementation advice, not a claim that all protocols share an approval structure.
Do not substitute ACP, AP2 and UCP for one another in requirements. Name the commerce integration and authorization mechanism separately. AP2 names compatibility with UCP while leaving catalog and communication APIs outside its scope. That boundary helps assign ownership of checkout updates. [1]
Place card networks in the system
Visa and Mastercard initiatives belong in a discussion of credentials, network participation and agent-enabled purchasing. Their names do not establish merchant support for a particular HTTP payment challenge. Nor do they establish identical eligibility across issuers or countries. Check the dedicated network guides before choosing a card route.
If the report seller accepts cards through checkout, investigate the credential and processor path. If it accepts a paid HTTP request, investigate that method's client and server support. A provider advertising several standards still needs to show which path covers your purchase. Ask for a documented flow rather than assuming a partnership badge supplies it.
Choose the next technical guide
Start with the observable obstacle. If the buyer cannot prove authority, read the AP2 guide and map the verifying parties. If the API needs a payment exchange, read the x402 or MPP guide for its supported method. If the seller needs checkout, review the commerce integration before selecting a wallet.
Write a compatibility record containing buyer role, seller role, protocol revision, payment method, network where relevant, authorization evidence and delivery outcome. Add the source and review date for each external claim. The record makes a decision reviewable without pretending that standards with different jobs are substitutes.
For the report, acceptance means an authorized purchase, a confirmed payment outcome and an accessible report. A failure at any point should have an owner and a recovery action. This gives you a practical test for a proposed stack and a reason to question an integration demonstrating only its easiest stage.