# MagicPay Components

Canonical URL: https://magiccard.ai/docs/components
Markdown URL: https://magiccard.ai/docs/components.md
Summary: MagicPay is modular payment infrastructure for personal AI agents. Each component can stand alone, but together they form an end-to-end purchase flow where agents act for humans without owning sensitive data.
Description: The MagicPay component map: browser execution, commerce discovery, saved user data, Mercuryo connectivity, and the apps people approve from.

## Canonical Answer

MagicPay is modular payment infrastructure for personal AI agents. Each component can stand alone, but together they form an end-to-end purchase flow where agents act for humans without owning sensitive data. The MagicPay component map: browser execution, commerce discovery, saved user data, Mercuryo connectivity, and the apps people approve from. One user balance and approval model across every connected agent.

## Key Points

- Single payment stack for browser checkout, API checkout, and agent-native protocols.
- One user balance and approval model across every connected agent.
- Protected data stays behind MagicPay requests instead of entering LLM context.
- Components can be adopted separately or composed into the built-in payment agent.

## Component Map

MagicPay splits the payment problem into modules with clear edges. MagicBrowse handles legacy web execution. MagicSearch finds the best provider and channel before a browser is opened. MagicPay Memory stores reusable user data. MagicPay Memory fill writes approved values into any target the runtime owns — an API call, a provider SDK, or a browser field. Mercuryo Bridge connects MagicPay sessions to payment account, KYC, card, balance, and transaction services. Omnichannel UI keeps the human in control.

- MagicCard: A single balance and payment interface your personal agent can use across Mercuryo-backed cards, crypto, swaps, and agentic rails. (https://magiccard.ai/docs/magiccard)
- MagicBrowse: Commerce-specialized browser automation for navigation, checkout, and safe sensitive-step handoff. (https://magiccard.ai/docs/components/magicbrowse)
- MagicSearch: Provider discovery, channel ranking, and agentic search fallback before browser handoff. (https://magiccard.ai/docs/components/magicsearch)
- MagicPay Memory: User-owned storage for logins, identity details, payment cards, and reusable checkout fields. (https://magiccard.ai/docs/components/memory)
- MagicPay Memory fill: Applies user-approved values to the target — a browser field, API header, or provider call — so values never reach the LLM. (https://magiccard.ai/docs/components/memory-fill)
- Mercuryo Bridge: Payment backend bridge for account linking, KYC, card issuance, top-up, and execution callbacks. (https://magiccard.ai/docs/components/mercuryo-bridge)
- Omnichannel UI: Web, mobile, Telegram, ChatGPT, Claude, and browser-extension apps for approvals and supervision. (https://magiccard.ai/docs/components/omnichannel-ui)

## End-To-End Shape

A typical flow starts with user intent, moves through MagicSearch for provider selection, uses MagicBrowse or an API/protocol channel for execution, pauses at protected steps, resolves data or actions through MagicPay Memory and MagicPay Memory fill, and asks the user through Omnichannel UI before Mercuryo-backed payment execution proceeds.

## Related

- MagicBrowse: https://magiccard.ai/docs/components/magicbrowse
- MagicSearch: https://magiccard.ai/docs/components/magicsearch
- MagicPay Memory fill: https://magiccard.ai/docs/components/memory-fill