Documentation v1.24
Last updated 2026-08-20 Give feedback

MagicPay Components

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.

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. MagicBrowse Commerce-specialized browser automation for navigation, checkout, and safe sensitive-step handoff. MagicSearch Provider discovery, channel ranking, and agentic search fallback before browser handoff. MagicPay Memory User-owned storage for logins, identity details, payment cards, and reusable checkout fields. MagicPay Memory fill Applies user-approved values to the target — a browser field, API header, or provider call — so values never reach the LLM. Mercuryo Bridge Payment backend bridge for account linking, KYC, card issuance, top-up, and execution callbacks. Omnichannel UI Web, mobile, Telegram, ChatGPT, Claude, and browser-extension apps for approvals and supervision.

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.

MagicPay public documentation.