Agent Money Matrix

Payment methods for automated spending, showing identity exposure, controls, and logging risk.

01One rail per job. Shared cards and shared wallets create shared graphs.

02Limit before execution. Dashboards are not controls if the charge already happened.

03Keep keys outside the agent runtime. Let the agent propose, not own the money.

Current options / reviewed 2026-08-10

Payment options an agent can use now

Records are scoped to the option, not the provider. Identity requirements and evidence confidence describe the provider; the controls available to an automated agent are shown separately.

virtual card

Privacy.com / API-issued virtual card

api · cli · mcp · card

Identity: A human Privacy account is required. Every end user must pass the Customer Identification Program before transacting; the terms list name, address, date of birth, and possible government ID requests.
Evidence: 94/100
Agent use: human kyc required

Available now: Available now through Privacy's API, CLI, and MCP paths; the agent uses a generated card at the merchant.Privacy for AI Agents · 2026-08-09 Privacy API: Cards · 2026-08-09

Review identity, controls, and failure paths

Identity setup: A human Privacy account is required. Every end user must pass the Customer Identification Program before transacting; the terms list name, address, date of birth, and possible government ID requests.Privacy API: Getting Started · 2026-08-09 Privacy Terms of Service · 2026-08-09
Ongoing verification: Privacy may request additional information at any time and may suspend or terminate an account that refuses it.Privacy Terms of Service · 2026-08-09
Counterparty data: The merchant receives card details and ordinary card-transaction data. Privacy records the merchant descriptor, location, category, amounts, events, and funding reference.Privacy for AI Agents · 2026-08-09 Privacy API: Transactions · 2026-08-09
Source and limits: Per-card spend limits can be configured by amount and duration; separate account transaction limits may change at Privacy's discretion.Privacy for AI Agents · 2026-08-09 Privacy API: Cards · 2026-08-09 Privacy Terms of Service · 2026-08-09
Approval / revocation: Merchant-locked, single-use, and multi-use cards are available; cards can be paused, unpaused, or closed. The reviewed flow does not require a human approval on every purchase.Privacy for AI Agents · 2026-08-09 Privacy API: Cards · 2026-08-09
Disputes / fraud: Transaction returns and voids are observable through the API. Product-specific notification and dispute deadlines come from the applicable card terms, not the card-control API.Privacy API: Transactions · 2026-08-09 Privacy Terms of Service · 2026-08-09
If the agent misbehaves: An agent can spend within the card's permissions without another approval. The account holder remains responsible for API, CLI, and MCP activity; Privacy may decline harmful or suspicious transactions.Privacy API: Getting Started · 2026-08-09 Privacy Terms of Service · 2026-08-09
Privacy / control boundary: Strong agent controls, weak identity privacy: the card hides the underlying funding credential from the merchant but does not make the verified Privacy account anonymous to Privacy or its bank partners.Privacy for AI Agents · 2026-08-09 Privacy API: Getting Started · 2026-08-09 Privacy Terms of Service · 2026-08-09

Record sourcesPrivacy for AI Agents · 2026-08-09 Privacy API: Cards · 2026-08-09 Privacy API: Getting Started · 2026-08-09 Privacy Terms of Service · 2026-08-09 Privacy API: Transactions · 2026-08-09

prepaid card

Laso Finance / U.S. prepaid card

x402 · api · card

Identity: The Laso docs describe KYC as optional and needed only for selected features such as Venmo or PayPal; this prepaid-card route is not listed as KYC-gated.
Evidence: 94/100
Agent use: api key only

Available now: Available now from the x402 get-card endpoint for U.S. merchants and U.S. shipping addresses, with JSON card details returned to the caller.

Review identity, controls, and failure paths

Identity setup: The Laso docs describe KYC as optional and needed only for selected features such as Venmo or PayPal; this prepaid-card route is not listed as KYC-gated.
Ongoing verification: No recurring verification step is documented for this route; provider compliance screening remains a service-level caveat.
Counterparty data: The merchant sees a Laso prepaid card and the documented Laso billing identity. Laso records card status and transactions.
Source and limits: $5-$1,000 USDC per card; U.S.-only use. The card is non-reloadable.
Approval / revocation: The x402 challenge fixes the purchase amount before settlement. No merchant lock, category lock, per-purchase human approval, or cancellation endpoint is documented for the issued U.S. card.
Disputes / fraud: Card status and transactions can be read, but the reviewed agent docs do not document a dispute or chargeback workflow for this route.
If the agent misbehaves: A wrong amount or unintended card order can settle as an irreversible x402 purchase. Failed settlement charges nothing; an issued non-reloadable card has no documented cancellation control.
Privacy / control boundary: Lower setup identity than a bank-linked card path, but weak post-issue agent controls. The merchant-facing card identity is not proof that Laso lacks wallet, payment, or transaction records.

Record sourcesLaso Finance documentation index · 2026-08-09

prepaid card

Laso Finance / International prepaid card

x402 · api · card

Identity: The route is not listed as KYC-gated in the reviewed Laso agent documentation.
Evidence: 94/100
Agent use: api key only

Available now: Available now as an x402 order, but fulfillment is queued for an administrator rather than immediate.

Review identity, controls, and failure paths

Identity setup: The route is not listed as KYC-gated in the reviewed Laso agent documentation.
Ongoing verification: No recurring verification step is documented for this route.
Counterparty data: Laso and its administrator receive the order and card records; the merchant receives the card credentials used at checkout.
Source and limits: $100 minimum and $1,000 maximum on-card value, with a 3.8% fee added and an indicated foreign-exchange markup for non-USD transactions.
Approval / revocation: A queued order can be cancelled and the charged amount returned to account balance. No cancellation is documented after administrative fulfillment.
Disputes / fraud: The reviewed agent docs document queue cancellation but no post-fulfillment card dispute or chargeback workflow.
If the agent misbehaves: An agent can submit the wrong amount or destination context; the practical stop control exists only while the order remains queued.
Privacy / control boundary: The route may avoid identity verification at setup, but the queued human fulfillment and card transaction trail remain visible to Laso and its card partners.

Record sourcesLaso Finance documentation index · 2026-08-09

View all 11 payment options

gift card

Laso Finance / Gift card

x402 · api · gift-card

Identity: The route is not listed as KYC-gated in the reviewed Laso agent documentation.
Evidence: 94/100
Agent use: api key only

Available now: Available now through catalog search and x402 ordering; the response returns a redemption URL, code, or PIN for the selected product.

Review identity, controls, and failure paths

Identity setup: The route is not listed as KYC-gated in the reviewed Laso agent documentation.
Ongoing verification: No recurring verification step is documented for this route.
Counterparty data: Laso sees the wallet, catalog selection, country, amount, and order. Redemption sends the gift-card credential into the chosen merchant's own flow.
Source and limits: $5-$9,000 converted USD value. Product currency, country, min/max, and fee vary by catalog item; fees can reach 4.8%.
Approval / revocation: The catalog selection and exact x402 price constrain the order. No account-wide budget, per-order human approval, or gift-card revocation endpoint is documented.
Disputes / fraud: The reviewed agent documentation does not publish a refund, dispute, or wrong-product recovery workflow for this route.
If the agent misbehaves: The amount is denominated in the product's currency, not always USD. An agent that ignores the currency or country fields can buy the wrong face value or an unusable regional product.
Privacy / control boundary: Gift-card credentials can reduce what the final merchant learns about the funding rail, but Laso still observes the funded order and the catalog choice.

Record sourcesLaso Finance documentation index · 2026-08-09

card payout

Laso Finance / Push to debit card

x402 · api · card

Identity: No calling-wallet KYC gate is documented, but redemption requires sender name, card number, and cardholder name.
Evidence: 94/100
Agent use: api key only

Available now: Available now for USD, EUR, and GBP; the API returns a redemption URL where card details are entered.

Review identity, controls, and failure paths

Identity setup: No calling-wallet KYC gate is documented, but redemption requires sender name, card number, and cardholder name.
Ongoing verification: Any downstream debit-card or bank verification is provider-scoped and not documented in the reviewed Laso agent material.
Counterparty data: The redemption flow receives sender name, card number, cardholder name, amount, and currency.
Source and limits: Face value 10-9,541.98 in USD, EUR, or GBP, with a 4.8% fee and a 1.50 minimum fee in the transfer currency.
Approval / revocation: The x402 challenge constrains the purchase amount, and a separate redemption step gates delivery. No post-redemption recall control is documented.
Disputes / fraud: The reviewed agent docs do not publish a dispute, fraud, or mistaken-card recovery workflow for this payout path.
If the agent misbehaves: An agent can fund the wrong currency or expose a redemption URL; incorrect cardholder data can make the transfer unfulfillable after payment.
Privacy / control boundary: The caller may avoid a full Laso KYC flow, but the payout itself is identity-bearing because cardholder and sender data enter the redemption path.

Record sourcesLaso Finance documentation index · 2026-08-09

account payout

Laso Finance / Venmo or PayPal payout

x402 · api · internal-ledger

Identity: The calling wallet must complete KYC; an unverified call returns kyc_required and a one-time verification URL.
Evidence: 94/100
Agent use: api key only

Available now: Available now through the x402 send-payment endpoint for Venmo and PayPal recipients.

Review identity, controls, and failure paths

Identity setup: The calling wallet must complete KYC; an unverified call returns kyc_required and a one-time verification URL.
Ongoing verification: The wallet exposes a current KYC review status. Additional provider checks beyond that status are not documented.
Counterparty data: The call submits recipient first and last name, email, and a Venmo phone number or PayPal email, linking the payout to both verified sender and identified recipient.
Source and limits: $5-$1,000 plus a 4.9% fee with a $1.50 minimum.
Approval / revocation: The x402 challenge constrains the amount. No per-payment human approval or payout recall endpoint is documented.
Disputes / fraud: If KYC is abandoned, deposited USDC remains in account balance and can be withdrawn. No completed-payout dispute workflow is documented.
If the agent misbehaves: An agent can send to the wrong phone number or email. The source documents balance recovery before fulfillment, not reversal of a completed payout.
Privacy / control boundary: This is the least private Laso agent route in the reviewed set: it requires caller KYC and named recipient identifiers even though the x402 funding leg is programmatic.

Record sourcesLaso Finance documentation index · 2026-08-09

bank payout

Laso Finance / ACH bank payout

x402 · api · bank

Identity: The account owner must complete identity verification in person. The application includes legal identity, address, employment, source-of-wealth, and SSN fields for U.S. persons.
Evidence: 94/100
Agent use: api key only

Available now: Available now to registered recipients on an approved banking profile; settlement is documented as one to two business days.

Review identity, controls, and failure paths

Identity setup: The account owner must complete identity verification in person. The application includes legal identity, address, employment, source-of-wealth, and SSN fields for U.S. persons.
Ongoing verification: The banking profile exposes approval status, missing fields, and per-rail capabilities; some work can be marked hosted-only for human completion.
Counterparty data: A recipient requires a postal address and registered U.S. or IBAN destination. Laso stores destination records; listing masks account numbers to the last four digits.
Source and limits: $10-$10,000 plus 0.25%, with a $1.50 minimum fee.
Approval / revocation: Only registered destinations can receive payment. Destinations can be deleted, but deleting a recipient is irreversible and may close connected off-ramp accounts; no per-payment human approval is documented.
Disputes / fraud: An unfulfillable payout leaves credited USDC recoverable through withdrawal. No recall or dispute flow for a completed ACH payout is documented.
If the agent misbehaves: An agent can send to the wrong registered destination or delete a recipient destructively. Laso explicitly says to confirm recipient deletion with the human first.
Privacy / control boundary: The destination allowlist is a useful agent-safety boundary, but this is an identity-rich bank rail rather than a private payment path.

Record sourcesLaso Finance documentation index · 2026-08-09

wallet payment

Laso Finance / Managed-wallet x402 payment

x402 · api · stablecoin

Identity: Authentication starts from a wallet signature. KYC is optional at account level and required only by selected downstream features.
Evidence: 94/100
Agent use: api key only

Available now: Available now: Laso can custody a wallet and settle x402 payments for an authenticated agent, or the caller can bring a supported self-custody wallet.

Review identity, controls, and failure paths

Identity setup: Authentication starts from a wallet signature. KYC is optional at account level and required only by selected downstream features.
Ongoing verification: Bearer credentials refresh over time; downstream endpoints can impose their own KYC or banking approval gates.
Counterparty data: Laso sees the managed wallet, balance, deposits, x402 challenge, settlement, and endpoint destination; signed webhooks can send activity to the caller's URL.
Source and limits: Limits are endpoint-specific. The reviewed docs publish route caps rather than one account-wide agent budget.
Approval / revocation: The x402 challenge fixes each endpoint price, while bearer credentials authorize calls. No general per-call human approval or account-wide merchant/category policy engine is documented.
Disputes / fraud: A failed settlement charges nothing and returns an error reason. Recovery after a successful external payment is defined by the downstream endpoint, not the managed wallet itself.
If the agent misbehaves: An agent with bearer access can spend available wallet funds on supported calls. Underfunded retries are safe, but an unintended successful x402 payment has no universal reversal path.
Privacy / control boundary: Wallet-signature setup can reduce conventional identity collection, but provider custody exposes balances and payment metadata to Laso and shifts key control away from the account owner.

Record sourcesLaso Finance documentation index · 2026-08-09

gift card

Bitrefill / Gift card or phone refill

merchant-api · gift-card · crypto

Identity: Basic purchasing can reach account limits before verification; verification uses government ID, liveness, and generally proof of address, with an exception for U.S. proof of address.
Evidence: 94/100
Agent use: api key only

Available now: Available now as a crypto-funded gift-card or phone-refill order. The public API page was blocked during this review, so API-level agent controls remain unverified.Bitrefill refund policy · 2026-08-09 Bitrefill wrong gift card or phone refill · 2026-08-09

Review identity, controls, and failure paths

Identity setup: Basic purchasing can reach account limits before verification; verification uses government ID, liveness, and generally proof of address, with an exception for U.S. proof of address.Bitrefill: How do I become a verified user? · 2026-08-09
Ongoing verification: Bitrefill reserves the right to request verification in certain cases and uses verification to raise purchase limits.Bitrefill: How do I become a verified user? · 2026-08-09
Counterparty data: Order support can require invoice ID, payment address, email, or the phone number being topped up. The final merchant receives the redeemed code or refill destination rather than the crypto funding credential.Bitrefill refund policy · 2026-08-09 Bitrefill wrong gift card or phone refill · 2026-08-09
Source and limits: Purchase limits are account-level and can trigger verification; exact current limit tiers were not present in the captured article.Bitrefill: How do I become a verified user? · 2026-08-09
Approval / revocation: A sealed gift card may remain refundable at Bitrefill's discretion. A revealed code or completed phone refill cannot be cancelled; no per-order agent approval control was verified.Bitrefill wrong gift card or phone refill · 2026-08-09
Disputes / fraud: Undelivered orders can be refunded after support review and a refund address; requests must be made within 30 days. Successfully delivered voucher codes are not refundable.Bitrefill refund policy · 2026-08-09
If the agent misbehaves: An agent can select the wrong region, card, email, or phone number. Once a code is revealed or a refill is delivered, Bitrefill documents no cancellation path.Bitrefill wrong gift card or phone refill · 2026-08-09 Bitrefill refund policy · 2026-08-09
Privacy / control boundary: The gift-card hop can reduce payment-data exposure to the final merchant, but Bitrefill still sees the funded order and can require identity verification as limits or risk checks apply.Bitrefill: How do I become a verified user? · 2026-08-09 Bitrefill refund policy · 2026-08-09

Record sourcesBitrefill refund policy · 2026-08-09 Bitrefill wrong gift card or phone refill · 2026-08-09 Bitrefill: How do I become a verified user? · 2026-08-09

wallet payment

BTCPay Server / Self-hosted wallet payment

merchant-api · bitcoin · lightning · psbt

Identity: BTCPay Server itself can be self-hosted without provider identity enrollment; the upstream acquisition of bitcoin and hosting account remain separate identity surfaces.
Evidence: 59/100
Agent use: no account

Available now: Available now from a self-hosted BTCPay wallet through send, payout, pull-payment, and refund workflows.BTCPay Server wallet · 2026-08-09 BTCPay Server refunds · 2026-08-09

Review identity, controls, and failure paths

Identity setup: BTCPay Server itself can be self-hosted without provider identity enrollment; the upstream acquisition of bitcoin and hosting account remain separate identity surfaces.BTCPay Server wallet · 2026-08-09
Ongoing verification: No BTCPay identity reverification is documented for the self-hosted wallet path.BTCPay Server wallet · 2026-08-09
Counterparty data: The operator's server sees wallet transactions, timestamps, balances, labels, payout or refund status, and destination data. The blockchain or Lightning peers retain their own network-level visibility.BTCPay Server wallet · 2026-08-09 BTCPay Server refunds · 2026-08-09
Source and limits: No provider-set universal spend cap is documented; available balance, wallet policy, and operator configuration bound the payment.BTCPay Server wallet · 2026-08-09
Approval / revocation: PSBT mode separates construction, inspection, signing, verification, and broadcast. A hot wallet can sign automatically with a seed stored on the server, removing that manual boundary.BTCPay Server wallet · 2026-08-09
Disputes / fraud: BTCPay can create and track refunds, but on-chain settlement does not create card-style chargebacks; refund authorization remains with the operator.BTCPay Server refunds · 2026-08-09
If the agent misbehaves: A hot-wallet agent can sign from server-held keys; compromise can spend the wallet. PSBT keeps an external signer in the loop but slows full autonomy.BTCPay Server wallet · 2026-08-09
Privacy / control boundary: Self-hosting avoids a central payment provider and supports strong signer separation, but transparent-chain history and server/network metadata are not removed by BTCPay.BTCPay Server wallet · 2026-08-09

Record sourcesBTCPay Server wallet · 2026-08-09 BTCPay Server refunds · 2026-08-09

human assisted

SHOPINBIT / Human concierge purchase

manual · bitcoin · monero · stablecoin · bank

Identity: ShopinBit advertises no KYC for concierge use. A purchase still requires the details needed to source, communicate, ship, or complete customs.
Evidence: 94/100
Agent use: no account

Available now: Available now through the app conversation or website form, but requests go to a real human concierge and offers arrive in 24-48 weekday hours.ShopinBit Concierge · 2026-08-09

Review identity, controls, and failure paths

Identity setup: ShopinBit advertises no KYC for concierge use. A purchase still requires the details needed to source, communicate, ship, or complete customs.ShopinBit Concierge · 2026-08-09 ShopinBit privacy policy · 2026-08-09
Ongoing verification: No recurring identity verification is advertised; order-specific delivery or customs data may still be required.ShopinBit Concierge · 2026-08-09 ShopinBit privacy policy · 2026-08-09
Counterparty data: A human concierge receives the request and necessary details, then communicates with suppliers and handles shipping and customs. ShopinBit says order data is deleted 30 days after shipment.ShopinBit Concierge · 2026-08-09
Source and limits: No universal order-value limit is published on the reviewed concierge page. Third-party sourcing adds 10% to the purchase price; supplier-network sourcing has no extra concierge fee.ShopinBit Concierge · 2026-08-09
Approval / revocation: The human sends an offer before payment, creating a strong per-order approval boundary. No autonomous agent API, account budget, or machine revocation control is documented.ShopinBit Concierge · 2026-08-09
Disputes / fraud: New products carry a stated two-year retailer warranty. The reviewed concierge page does not publish a general refund or dispute workflow.ShopinBit Concierge · 2026-08-09
If the agent misbehaves: An agent can submit an overbroad or incorrect request, but the human offer-and-payment step prevents autonomous completion. Shipping and customs still depend on accurate recipient data.ShopinBit Concierge · 2026-08-09
Privacy / control boundary: No-KYC positioning and Monero payment can reduce payment identity, but the human service and physical fulfillment collect order and delivery context. This is a privacy-oriented assisted path, not an autonomous agent rail.ShopinBit Concierge · 2026-08-09 ShopinBit privacy policy · 2026-08-09

Record sourcesShopinBit Concierge · 2026-08-09 ShopinBit privacy policy · 2026-08-09

Review protocols, method comparisons, examples, and cautions

Protocols

Protocol support does not change payment data collection

A payment record can include the request, approval, wallet, merchant event, provider log, and settlement receipt.

Protocol supportSettlement railLogging riskMinimum autonomy

Protocols shown

Open filtered API

Agent payment protocol comparison
Protocol	Role	Rails	Autonomy	Logging risk	Revocation	Metadata path	Sources
x402x402	HTTP 402 payment challenge and retry flow	stablecoin / crypto	4	high	weak	agent/client → paid endpoint → 402 challenge → wallet → facilitator → chain or settlement network → merchant access log	x402 protocol site Coinbase x402 docs Coinbase facilitator docs
AP2ap2 / mcp	Signed mandate and accountability layer for agent commerce	card / stablecoin / bank / deferred	3	medium	partial	user → agent → intent mandate → merchant → payment credential → wallet or payment rail → receipt	Google AP2 announcement AP2 protocol docs AP2 GitHub
MPPmpp / x402	Machine Payments Protocol for payment in the same HTTP request	card / stablecoin / lightning / deferred	4	high	partial	agent/client → paid service → MPP payment header → processor or wallet → settlement rail → service access log	Stripe MPP announcement MPP overview Cloudflare MPP docs
TAPtap	Trusted agent identity signal for agent commerce	card	3	high	partial	agent → agent-specific cryptographic signature → merchant → consumer recognition → optional payment information → Visa network or merchant records	Visa TAP announcement
MCPmcp	Tool protocol that can expose payment or card controls to an AI client	card / crypto / bank / gift-card / unknown	3	high	partial	AI host → MCP client → MCP server → provider API → payment rail → tool-call logs	Anthropic MCP announcement MCP specification Privacy.com MCP

x402x402HTTP 402 payment challenge and retry flowLogging risk: highDetails

Rails: stablecoin / crypto
Autonomy: 4
Revocation: weak
Metadata path: agent/client → paid endpoint → 402 challenge → wallet → facilitator → chain or settlement network → merchant access log
Sources: x402 protocol site Coinbase x402 docs Coinbase facilitator docs

ap2 / mcpAP2Signed mandate and accountability layer for agent commerceLogging risk: mediumDetails

Rails: card / stablecoin / bank / deferred
Autonomy: 3
Revocation: partial
Metadata path: user → agent → intent mandate → merchant → payment credential → wallet or payment rail → receipt
Sources: Google AP2 announcement AP2 protocol docs AP2 GitHub

mpp / x402MPPMachine Payments Protocol for payment in the same HTTP requestLogging risk: highDetails

Rails: card / stablecoin / lightning / deferred
Autonomy: 4
Revocation: partial
Metadata path: agent/client → paid service → MPP payment header → processor or wallet → settlement rail → service access log
Sources: Stripe MPP announcement MPP overview Cloudflare MPP docs

tapTAPTrusted agent identity signal for agent commerceLogging risk: highDetails

Rails: card
Autonomy: 3
Revocation: partial
Metadata path: agent → agent-specific cryptographic signature → merchant → consumer recognition → optional payment information → Visa network or merchant records
Sources: Visa TAP announcement

mcpMCPTool protocol that can expose payment or card controls to an AI clientLogging risk: highDetails

Rails: card / crypto / bank / gift-card / unknown
Autonomy: 3
Revocation: partial
Metadata path: AI host → MCP client → MCP server → provider API → payment rail → tool-call logs
Sources: Anthropic MCP announcement MCP specification Privacy.com MCP

AP2 vs x402 vs MPP Privacy.com MCP Agent wallet threat model Pay-per-crawl privacy Cards vs stablecoin wallets

Payment methods

Compare payment methods before enabling automated payments

Agent payment method comparison
Rail	Identity surface	Authority	Custody	Control quality	Funding trail	Automation risk	Appropriate uses	Limitations
Control layerBank-linked virtual cardsPrivacy.com	Full KYC, US bank account, issuing-bank records	API key plus merchant/category locks and spend caps; autonomy level 3 when scoped	Issuer/card rail with linked bank funding	High: merchant locks, spend limits, pause/close, API and webhooks	Checking account or card rails	Strong for capped SaaS tasks, weak for identity privacy	Mainstream subscriptions, API credits, short-lived research tools	Anonymous spend, sanctioned geography, or separating from bank identity
Prepaid merchant creditCrypto gift-card bridgesBitrefill CoinCards CryptoRefills	Email, order, coin, merchant and region dependent	API/MCP or account permission; safer when each order still gets human review	Merchant credit after purchase; provider/order records remain	Medium: fixed value, no open card reuse, limited reversibility	BTC, Lightning, XMR, stablecoins or other crypto by provider	Good when the agent only needs one merchant balance	Retail credits, eSIMs, vouchers, account top-ups, small recurring needs	Merchants that later demand card verification or durable billing
Low metadata spendMonero-first merchant creditXMR Cards Anon Shop	Low if OPSEC, delivery and merchant redemption are clean	Human-approved balance or order; autonomy should stay low	Merchant credit or order balance, not a general wallet	Medium: balance or order constrained, weak post-issuance recovery	Monero	Good for low-balance workflows with human receipt review	Private low-value online purchases and merchant-specific credit	High-value orders, fragile delivery, or refund-sensitive purchases
Card network bridgeCrypto or stablecoin virtual cardsSolvoCard Trocador Prepaid Cards Cake Pay	Issuer, program, country and activation dependent	Issuer card controls and balance caps; no general proof-of-intent layer	Issuer or provider custody until the card spends	Medium: card balance and issuer controls, weaker than true policy APIs	Crypto, stablecoins or prepaid card programs	Useful test rail, but issuer and chargeback risk stays unresolved	Disposable card-style spend where merchant only accepts Visa/Mastercard	Critical accounts, large balances, unclear issuer terms or blocked regions
Native settlementDirect crypto merchantBTCPay Server SHOPINBIT Directory search	Depends on coin, wallet hygiene, account identity and network layer	Agent can prepare an invoice; wallet or operator should sign outside the runtime	Self-custody until payment; merchant records after payment	Low by default: build policy, approvals and wallet separation yourself	Self-custodied crypto	Safe only when the agent proposes and a wallet/human signs	Crypto-native services, hosting, VPNs, wallets, private AI credits	Giving the agent wallet keys or exchange sessions
Human-in-loopSelf-hosted approval walletThreat model	Depends on funding source, wallet, logs, network and merchant account	Policy engine, human threshold, or scoped wallet grant	Self-custody or narrow hot wallet by design	High if policy engine approves, wallet signs, and balances stay tiny	Self-custodied crypto, internal credits, or scoped hot wallets	Best pattern for high-value or repeatable agent workflows	Agent drafts payment, human or policy service signs after checks	Untrusted browsing in the same runtime as keys or seed material
Do not defaultRaw bank card in agent runtime	Maximum: cardholder, bank, merchant, device and agent logs	Browser session or raw credentials; autonomy level can become broad by accident	Bank/cardholder account exposed through the agent workflow	Low unless wrapped by an external policy and issuer controls	Personal or business bank/card account	Poor default because compromise becomes direct money movement	Avoid except throwaway, low-risk personal automation	Anything sensitive, recurring, high-limit or hard to dispute

Control layerBank-linked virtual cardsIdentity: Full KYC, US bank account, issuing-bank recordsControl: High: merchant locks, spend limits, pause/close, API and webhooksDetails

Privacy.com

Authority: API key plus merchant/category locks and spend caps; autonomy level 3 when scoped
Custody: Issuer/card rail with linked bank funding
Funding: Checking account or card rails
Automation risk: Strong for capped SaaS tasks, weak for identity privacy
Appropriate uses: Mainstream subscriptions, API credits, short-lived research tools
Limitations: Anonymous spend, sanctioned geography, or separating from bank identity

Prepaid merchant creditCrypto gift-card bridgesIdentity: Email, order, coin, merchant and region dependentControl: Medium: fixed value, no open card reuse, limited reversibilityDetails

Bitrefill CoinCards CryptoRefills

Authority: API/MCP or account permission; safer when each order still gets human review
Custody: Merchant credit after purchase; provider/order records remain
Funding: BTC, Lightning, XMR, stablecoins or other crypto by provider
Automation risk: Good when the agent only needs one merchant balance
Appropriate uses: Retail credits, eSIMs, vouchers, account top-ups, small recurring needs
Limitations: Merchants that later demand card verification or durable billing

Low metadata spendMonero-first merchant creditIdentity: Low if OPSEC, delivery and merchant redemption are cleanControl: Medium: balance or order constrained, weak post-issuance recoveryDetails

XMR Cards Anon Shop

Authority: Human-approved balance or order; autonomy should stay low
Custody: Merchant credit or order balance, not a general wallet
Funding: Monero
Automation risk: Good for low-balance workflows with human receipt review
Appropriate uses: Private low-value online purchases and merchant-specific credit
Limitations: High-value orders, fragile delivery, or refund-sensitive purchases

Card network bridgeCrypto or stablecoin virtual cardsIdentity: Issuer, program, country and activation dependentControl: Medium: card balance and issuer controls, weaker than true policy APIsDetails

SolvoCard Trocador Prepaid Cards Cake Pay

Authority: Issuer card controls and balance caps; no general proof-of-intent layer
Custody: Issuer or provider custody until the card spends
Funding: Crypto, stablecoins or prepaid card programs
Automation risk: Useful test rail, but issuer and chargeback risk stays unresolved
Appropriate uses: Disposable card-style spend where merchant only accepts Visa/Mastercard
Limitations: Critical accounts, large balances, unclear issuer terms or blocked regions

Native settlementDirect crypto merchantIdentity: Depends on coin, wallet hygiene, account identity and network layerControl: Low by default: build policy, approvals and wallet separation yourselfDetails

BTCPay Server SHOPINBIT Directory search

Authority: Agent can prepare an invoice; wallet or operator should sign outside the runtime
Custody: Self-custody until payment; merchant records after payment
Funding: Self-custodied crypto
Automation risk: Safe only when the agent proposes and a wallet/human signs
Appropriate uses: Crypto-native services, hosting, VPNs, wallets, private AI credits
Limitations: Giving the agent wallet keys or exchange sessions

Human-in-loopSelf-hosted approval walletIdentity: Depends on funding source, wallet, logs, network and merchant accountControl: High if policy engine approves, wallet signs, and balances stay tinyDetails

Threat model

Authority: Policy engine, human threshold, or scoped wallet grant
Custody: Self-custody or narrow hot wallet by design
Funding: Self-custodied crypto, internal credits, or scoped hot wallets
Automation risk: Best pattern for high-value or repeatable agent workflows
Appropriate uses: Agent drafts payment, human or policy service signs after checks
Limitations: Untrusted browsing in the same runtime as keys or seed material

Do not defaultRaw bank card in agent runtimeIdentity: Maximum: cardholder, bank, merchant, device and agent logsControl: Low unless wrapped by an external policy and issuer controlsDetails

Authority: Browser session or raw credentials; autonomy level can become broad by accident
Custody: Bank/cardholder account exposed through the agent workflow
Funding: Personal or business bank/card account
Automation risk: Poor default because compromise becomes direct money movement
Appropriate uses: Avoid except throwaway, low-risk personal automation
Limitations: Anything sensitive, recurring, high-limit or hard to dispute

Examples

Example configurations

Low-risk SaaS subscription

Bank-linked virtual card

One merchant-locked card, one agent task name, hard monthly cap, receipt log.

Review transactions weekly; close the card when the task ends.

Sensitive research account

Gift-card bridge or Monero-funded credit

Alias email, isolated browser profile, VPN/Tor as appropriate, no reused card.

Assume the merchant still links behavior, timing and redemption metadata.

Crypto-native tool or host

Direct crypto merchant

Agent prepares invoice details; wallet signs outside the agent runtime.

Keep wallet logs separate from prompts, files and browser automation.

High-value workflow

Self-hosted approval wallet

Policy engine checks merchant, amount, category, frequency and purpose.

Human approval stays mandatory above a tiny threshold.

Caution

Privacy.com is not no-KYC

Privacy.com is useful for card-number isolation, merchant locks, spend caps, pausing, closing and API-driven controls. It is still a full-KYC, US bank-linked rail. Use it when the problem is agent spend control. Do not use it as financial anonymity.

One rail per job. Shared cards and shared wallets create shared graphs.
Limit before execution. Dashboards are not controls if the charge already happened.
Keep keys outside the agent runtime. Let the agent propose, not own the money.
Log merchant, amount, task and approval result. Do not dump secrets into receipts.