MagicCard
MagicCard turns agentic payments, crypto, APIs, browser checkout, and new payment protocols into one simple top-up balance.
- One card-like interface for personal AI agent payments.
- As simple for the user as topping up a single card balance.
- Supports one-time purchases, marketplace cards, and subscription-specific payment methods.
- Card data and final confirmations stay behind MagicPay approval requests.
Supported Payment Methods
MagicCard is not one physical rail. It is the user-facing abstraction over the payment methods MagicPay can orchestrate for each agent session.
| Method | Status | Use when |
|---|---|---|
| Card payments | Live | The merchant supports ordinary online checkout and no merchant integration is required. |
| API access | Live | A developer or agent can complete the payment through a programmatic MagicPay or provider API path. |
| x402 | Live | The provider supports HTTP-native stablecoin micropayments. |
| ACP | Planned | The provider supports Agentic Commerce Protocol checkout. |
| AP2 | Planned | The flow needs secure delegation of payment authority from human to agent. |
| Future protocols | Planned | New agent payment standards become available behind the same MagicCard interface as they ship. |
How MagicPay Chooses A Method
MagicPay ranks the safest and most direct route first. Agent-native protocols and official APIs are preferred when available; reverse APIs and browser checkout are fallback paths when the merchant only supports legacy flows.
- The user does not need to choose rails for every purchase.
- The agent should request the purchase intent, not a specific card number or secret.
- MagicSearch and provider metadata can influence routing before MagicBrowse opens a page.
- User approval and policy still decide whether money can move.
Card Types
Different payment relationships need different persistence. MagicCard keeps the user-facing model simple while MagicPay scopes the payment method to the job.
| Type | Best for | Persistence |
|---|---|---|
| One-time purchase | Tickets, bookings, goods, and single checkout sessions. | Card details are isolated to the payment and not reused by the agent. |
| Marketplace purchase | Amazon, delivery, travel, and other accounts that may need a saved method. | A provider-scoped relationship can remain available for future approved sessions. |
| Recurring subscription | SaaS, memberships, renewals, and scheduled charges. | A dedicated subscription payment method persists with next-charge and cancellation context. |
No Data In LLM Context
MagicCard does not mean the model gets card data. Card numbers, credentials, OTPs, identity fields, and final payment confirmations stay inside MagicPay protected flows and never enter LLM context. The agent receives only safe state such as request status, approval outcome, selected provider, and whether the workflow can continue.
Smart Internal Top-Up
MagicPay presents one simple MagicCard balance while agents spend only through approved sessions, policy-controlled limits, and available balance checks. Internal top-up and routing logic can prepare the right payment path for the session while keeping wallet, swap, card, and protocol complexity out of the user-facing flow.