> ## Documentation Index > Fetch the complete documentation index at: https://docs.crossmint.com/llms.txt > Use this file to discover all available pages before exploring further. # How Agents Pay > Why giving an agent a payment method used to mean handing over the user's real card, and how scoped cards and wallets fix it An agent that can only recommend is a search engine. An agent that can act needs to spend money, and the web gave developers no safe way to let it. ## Problems The only payment credential most of your users have is a card, and nothing about a card was designed to be handed to software that acts on its own: * **The real card number ends up in the agent's context.** It travels through prompts, logs, tool calls, and model providers. Once leaked, it can be charged again and again. There is no limit the agent cannot exceed, no expiry, and no way to revoke without cancelling the card. It also drags the developer into PCI scope. * **Keeping a human in the loop defeats the purpose.** Approving every payment is safe, but the user is interrupted at the exact moment the agent was supposed to save them time. * **Prepaid or virtual cards from a fintech give up the user's card.** The user funds a new balance instead of using the card they already have, loses their rewards, refunds, and chargeback protections, and the developer often becomes the account holder for money that is not theirs. * **Custodial agent wallets create custody and trust problems.** Someone other than the user controls the funds, which raises licensing questions and still gives the agent unlimited access to whatever is in the wallet. * **Limits enforced only in application code do not hold.** They stop honest mistakes, not a compromised agent, a manipulated model, or a leaked credential. Agents amplify every one of these risks. An agent with unlimited access to money is a liability. What is missing is spending power that is **scoped, enforced outside the agent, and revocable by the user**, while the user keeps their own card. ## Solutions Crossmint gives agents two payment instruments. Both follow the same principle: the user delegates a bounded allowance, the bound is enforced outside the agent, and the user can revoke it at any time. ### Agent Cards Verify a card once, set spending rules, and the agent pays with a one-time card number that only works within those rules Verify a card once, set spending rules, and the agent pays with a one-time card number that only works within those rules The user saves their real card once, in a Crossmint-hosted PCI-compliant iframe. From that saved card, your app creates as many **scoped authorizations** as it needs. Crossmint calls these **order intents**: each one is an allowance with an amount, a description, an expiration, and optionally a merchant. The user approves each one, and can cancel it at any time. From an active order intent, the agent **mints credentials on the rail the purchase needs**: | Rail | What the agent receives | Enforced by | | - | - | - | | Visa Intelligent Commerce | A one-time card number or network token bounded by the allowance | Visa | | Mastercard Agent Pay | A one-time card number or network token bounded by the allowance | Mastercard | | Encrypted card | The saved card encrypted to a key only the agent holds, for cards outside the network programs; minted for an amount the order intent consumes | The order intent, for the amount; the card network does not bound the card | | Protocol credentials (SPT) | A protocol-specific token for merchants and services that accept it | The protocol | Depending on the rail, the credential is delivered as a one-time card number, a network token, or a protocol-specific format such as MPP. The real card number never leaves the vault. A leaked network credential is worthless: it is bounded to an amount, expires, and is revoked with the order intent. The encrypted card is the exception: it decrypts to the saved card, so the allowance is yours to enforce and you should cancel the order intent as soon as it is no longer needed. And because the purchase runs on the user's own card, rewards, refunds, and chargebacks keep working. Read the [Agent Cards overview](/agents/cards/overview) for the product. ### Agent Wallets For machine-to-machine payments, cards do not fit. Paying an API per call or settling with another agent involves amounts too small and too frequent for card fees and chargeback rules. These payments run on stablecoins. The user owns a non-custodial wallet and adds the agent as a **signer with a scoped permission set**: a spend cap, allowed counterparties, and a time window. The permissions are enforced onchain, so a transaction outside them is rejected at the wallet level, and the user can revoke the signer at any time. Neither you nor Crossmint takes custody. Read the [Agent Wallets overview](/agents/wallets/overview) for the product. Every delegation is explicit, scoped, enforced outside the agent, and revocable. The agent gets exactly the spending power the user granted, and nothing that survives a leak. ## See Also Why a secure card was not enough, and how one API buys from any merchant Save once, authorize many, pay on the right rail Scoped, non-custodial stablecoin wallets