Payment Methods
MagicPay hides payment method details from users while routing agent sessions through the best available rail.
Channel Ranking
MagicPay ranks payment channels by fit for the purchase and by how much browser work can be avoided. Ranking is the routing preference, not a list of shipped rails: agent-native protocols rank first because they are the least fragile, and they are used once a provider actually supports them. x402 is live today; ACP and AP2 are planned. Card payments and API paths still carry most purchases — see the status column on the MagicCard page.
| Rank | Channel | Use when |
|---|---|---|
| 1 | Agent-native protocols (x402, ACP, AP2) | The provider supports a native agent payment protocol |
| 2 | Public MCP/API | The provider exposes an official callable interface |
| 3 | Reverse MCP/API | MagicPay can adapt to a provider flow without browser checkout |
| 4 | Browser checkout | The purchase must happen through an ordinary website checkout |
Purchase Operation Types
The same MagicCard interface supports one-time purchases, marketplace-attached cards, and recurring subscriptions.
- One-time purchase: pay for goods such as tickets or website checkout items.
- Marketplace purchase: attach a card to a marketplace account such as Amazon or Uber Eats.
- Recurring payment: create a dedicated subscription card and manage renewals from MagicPay.
Protocol Philosophy
x402 and other agentic protocols are payment infrastructure, not user-facing complexity. The user should not need to think about the payment protocol, just as they do not think about payment rails when tapping a card.