Map the spending instrument to the purchase
Crossmint's agent documentation separates Agent Cards, Agent Wallets and Agent Checkouts. The first two provide spending power; the third handles the process of buying. The products can be composed, but they are not a single interchangeable payment API. A wallet transfer can succeed without an order being placed, while a checkout can stop because the buyer still needs to answer a question. [2]
Suppose a procurement agent needs an $18 software export. This is an illustrative purchase, not a Crossmint price or an observed test. Before choosing a component, identify whether the seller offers a paid API endpoint, a conventional web checkout or both. An x402 endpoint suggests a machine-payment route. A product page with a license selection and checkout suggests an order workflow. The price alone does not decide.
The diagram marks the points your application needs to connect. The owner defines authority, the instrument enforces its applicable limits, and the seller supplies the purchased output. Keep a record at each boundary. That makes it possible to explain whether a failed task was blocked before payment, paid but not delivered, or completed successfully.
From owner approval to purchased output
- Owner authority
Approve the software export, maximum total, seller and time window.
- Spending instrument
Choose a scoped agent card or delegated stablecoin wallet; identify its enforcement point.
- Purchase route
Use the supported paid endpoint or merchant checkout. Surface required buyer inputs.
- Payment evidence
Preserve the selected credential route and final payment reference without raw secrets.
- Seller delivery
Match the receipt and export to the task, then resolve any discrepancy before retrying.
Check custody and the actual credential rail
Agent Wallets are documented as non-custodial smart wallets. For a consumer deployment, the user owns the wallet and grants an agent a delegated signer. A server agent wallet is owned by the application's backend. The documented controls include spending caps, allowed counterparties and a time window, with permissions enforced onchain. This is a different ownership arrangement from handing an unrestricted root signer to an agent. [3]
Agent Cards start from a saved user card and an approved order intent. Crossmint documents several credential rails, including Visa Intelligent Commerce, Mastercard Agent Pay, encrypted cards and protocol credentials. Read the selected rail rather than assuming every credential inherits the same enforcement. Network-issued credentials are bounded by the allowance; the encrypted-card fallback requires your allowance handling and is enabled only for eligible production projects. [4]
For an integration review, ask who holds the root key or original card, what the agent receives, where the cap is enforced, and how revocation reaches that credential. These are four separate questions. A claim that card data is protected does not establish that a checkout can never exceed a task budget. Conversely, a budget check does not establish that sensitive credentials are absent from application logs.
Separate documented integration from general compatibility
The capability matrix names a source for each path and keeps its unresolved question visible. Crossmint's current wallet documentation includes x402 and MPP. The specific x402 guide uses a funded EVM wallet on Base with USDC and an agent authorized as a signer. That concrete example provides a better starting point than inferring support for every network from a broad multi-chain description. [5]
The public agentic-payments page also describes AP2 and Visa support. Treat that as a provider statement about supported flows, then confirm the exact protocol version, credential route and account access needed for your application. A partnership logo is not a complete integration guide. Request the relevant technical contract when a compatibility claim is central to your decision. [1]
For the illustrative software export, write down the seller endpoint and accepted payment offer before picking a wallet. If the required asset or network differs from the documented example, that is an investigation item. Do not silently substitute another chain, convert funds without permission, or assume that the same ticker means the same token contract.
Capabilities and verification questions
Scroll the table to compare all columns.
| Buyer task | Documented component | Integration evidence | Reach question |
|---|---|---|---|
| Pay a machine endpoint | Agent Wallets, x402 | [5]: Base wallet with USDC and delegated signer | Does this endpoint offer that asset, network and scheme? |
| Use a user card | Agent Cards | [4]: approved order intent and selectable credential rail | Which rail does the saved card support, and who enforces its cap? |
| Complete an online order | Agent Checkouts | [6]: URL, cap, run status and payment input | Can this seller fulfill this specific buyer order? |
| Evaluate AP2 compatibility | Provider-supported AP2 flow | [1]: public compatibility statement | Which AP2 version and integration contract apply? |
| Assess regional access | Selected agent product and funding path | No complete agent-product country matrix established here | Confirm buyer, business, asset and merchant eligibility separately. |
Merchant reach and geography need a purchase-level answer
Agent Checkouts starts from a URL and a spending cap. Its documented execution can use an agentic commerce protocol or a browser path, and a run can request additional buyer information or authorization. The result can be a receipt, a blocked outcome or a failure. A broad merchant-reach claim therefore describes the intended access route; it does not guarantee that any particular order will complete. [6]
For the $18 software export, confirm the license permits the intended business use, the buyer can purchase from the seller, and the payment method is accepted. Shipping restrictions may be irrelevant to this digital item, but tax details, account ownership or seller authentication may still matter. Keep merchant acceptance, provider eligibility and buyer location as separate fields in the purchase specification.
Do not borrow geographic rules from a neighboring Crossmint product. Its general token Checkout documentation includes asset-specific regional exclusions and business-verification requirements. Those rules describe that product, not a universal country list for Agent Cards or Agent Checkouts. This review has not established a complete eligibility matrix for every agent product; obtain the applicable terms for the selected route. [7]
The marketing page describes a commerce offering in which Crossmint acts as merchant of record and handles returns and chargebacks. Do not apply that statement automatically to a direct wallet payment or a purchase using a saved card. Identify the contracting seller and support route in the actual order documents. [1]
Preserve authorization and delivery evidence
A useful purchase record links the task, the approved allowance, the instrument, the checkout run and the final seller reference. Store identifiers rather than raw credentials in the agent's conversation. Record the approved total and currency, including any taxes or extras, so a later change in the amount is visible. These are application design recommendations, not a claim about a Crossmint certification.
For Agent Checkouts, the current guide says payment input uses an order-intent identifier instead of raw card details. It also documents an awaiting-input state for missing information or authorization. Your interface should surface the actual requested action and resume the same run after it is answered. Starting a second checkout because the first appears slow creates an avoidable duplicate-purchase risk. [6]
With an x402 purchase, keep the payment result and the delivered software export together. The payment receipt establishes a payment event; the application still needs to inspect whether the returned file matches the requested format and license. If a response is lost, resolve the original purchase before authorizing another charge. A network timeout is an uncertain state, not evidence of a free retry.
Compare alternatives with the same $18 task
A fair comparison gives every provider the same seller, buyer location, approved amount and delivery requirement. Compare the documented agent interface and credential route, the handling of a request for human input, and the evidence returned after a failed or successful purchase. Leave unsupported fields unknown instead of awarding a score for broad marketing language.
Use the Coinbase and Circle provider guides when the task is specifically a machine payment from an agent wallet. Use the stack selector when the task also requires merchant checkout or card credentials. The useful output is a purchase path with named responsibilities and unresolved access checks. This page is a documentation-based review; it does not claim a live Crossmint transaction or measured success rate.