MagicCard
MagicCard makes the complex world of agentic payments, new protocols, crypto, APIs, browser checkout, and Mercuryo-backed cards feel as simple as topping up one card balance.
- One card-like interface for personal AI agent payments.
- As simple for the user as topping up a single card balance.
- Backed by Mercuryo account state, card issuing, payment operations, crypto, swaps, and checkout rails.
- Supports one-time purchases, marketplace cards, and subscription-specific payment methods.
- Memory-managed card data and final confirmations stay behind MagicPay 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, with Mercuryo providing the backend card and payment capabilities where those rails are needed.
| 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 | Planned | 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. When a card or payment operation is needed, MagicPay routes the session through Mercuryo-backed backend capabilities rather than acting as the card issuer itself.
- 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 underlying Mercuryo-backed card behavior 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 in MagicPay Memory-managed flows and do not enter LLM context. The agent receives only safe state such as request status, approval outcome, selected provider, and whether the workflow can continue.
Card Reissuing
Mercuryo backend provides the card issuing and payment infrastructure. MagicPay can request or coordinate frequent card rotation and reissuing through that backend so a single leaked or stale card value does not become a durable payment credential. Payment artifacts are scoped to the task, card details are isolated from the agent, and long-lived merchant relationships can use provider- or subscription-scoped cards instead of exposing a universal reusable number.
Smart Internal Top-Up
MagicPay presents one simple MagicCard balance while Mercuryo backend handles the underlying account, card, and payment operations. 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.