Describe the task before selecting a provider
Choose whether you are building the buying or selling side, then identify an API purchase or a retail checkout. A buyer needs controlled spending authority and a compatible purchase interface. A seller needs payment acceptance connected to delivery. The same company may need both, but each has a different integration boundary.
Record the buyer, business and merchant countries in your implementation notes. A location alone cannot establish availability: the selected product, account approval and purchase may impose different conditions. Even when you have checked current documentation, the selector keeps provider eligibility open for confirmation.
Describe your payment boundary
Keep asset, custody and approval separate
Specify a card or the exact stablecoin and network when the seller requires one. If acceptance is undecided, leave the asset open. x402 provides paid-resource negotiation, while Stripe documents particular card and stablecoin machine-payment routes. Neither statement establishes universal merchant acceptance. [1] [6]
Custody describes who controls the funds or reusable credential. Approval describes what the agent may do with that control. An owner-controlled wallet with a delegated signer and a managed service both need explicit limits and recovery procedures. Coinbase and Circle describe agent wallet products; inspect the chosen product rather than assuming all wallets share the same authority model. [3] [4]
For customer-present purchases, design the approval and resume step. For unattended tasks, verify a bounded policy with enforced amount, counterparty, purpose and expiry. AP2 supplies mandate evidence within commerce flows; it does not create the wallet or seller integration for you. [2]
Read the result as a category with conditions
The open rules below show how role and task determine the first guide path. Asset, custody and approval choices add requirements to that path. An unknown answer stays visible rather than becoming a positive match. No provider is ranked first because of affiliation or a commercial relationship.
A useful next step is concrete: open the guide, identify the official integration, and resolve its listed access or compatibility question. If a provider cannot document the required route, retain that gap in the decision record. The tool does not infer missing support from a partnership announcement.
Open selection rules and export contents
Scroll the table to compare all columns.
| Condition | Suggested category | Reason and unresolved check |
|---|---|---|
| Buyer + API | Controlled wallet or credential plus machine-payment client | Match the endpoint offer; confirm asset, network and provider access. |
| Seller + API | Paid-resource server plus settlement integration | Connect payment verification to delivery; confirm merchant eligibility. |
| Buyer + retail | Purchase workflow plus scoped payment credential | Handle order details and approval; confirm seller acceptance. |
| Seller + retail | Commerce checkout plus payment acceptance | Expose final order terms; confirm channel and account access. |
| Any unknown input | Keep the corresponding requirement open | Do not fabricate compatibility, custody control or consent. |
| Export | Markdown or JSON decision record | Include role, task, geography, asset, custody, approval, guide links and verification questions. |
Export the decision for an implementation review
Export Markdown for a discussion or JSON for a structured planning record. Preserve the selected inputs, suggested categories, reasons, linked guides and unresolved checks. Update the record when you obtain provider-specific evidence, particularly for geography and payment-method access.
The controls run locally in this page and do not create an account, connect a wallet or initiate a purchase. Download the record if you need to retain it. Avoid entering secrets or payment credentials: the selector needs requirements, not access to your funds. A completed form is not a security, compliance or availability certification.