# Aftercard Components

Canonical URL: https://aftercard.ai/docs/components
Markdown URL: https://aftercard.ai/docs/components.md
Summary: Aftercard 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 Aftercard component map: browser execution, commerce discovery, saved user data, payment provider connectivity, and the apps people approve from.

## Canonical Answer

Aftercard 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 Aftercard component map: browser execution, commerce discovery, saved user data, payment provider 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 Aftercard requests instead of entering LLM context.
- Components can be adopted separately or composed into the built-in payment agent.

## Component Map

Aftercard splits the payment problem into modules with clear edges. built-in browser handles web execution. MagicSearch finds relevant provider-method instructions without executing them. Aftercard Memory stores reusable user data. Aftercard Memory fill writes approved values into any target the runtime owns — an API call, a provider SDK, or a browser field. Payment Bridge connects Aftercard sessions to payment account, KYC, card, balance, and transaction services. Omnichannel UI keeps the human in control.

- Aftercard Card: A single balance and payment interface your personal agent can use across provider-backed cards, crypto, swaps, and agentic rails. (https://aftercard.ai/docs/magiccard)
- MagicFill: Exact protected-field materialization and clicks behind the host browser bridge. (https://aftercard.ai/docs/components/magicfill)
- MagicSearch: Semantic provider-method lookup with URLs, official docs, and agent guidance. (https://aftercard.ai/docs/components/magicsearch)
- Aftercard Memory: User-owned storage for logins, identity details, payment cards, and reusable checkout fields. (https://aftercard.ai/docs/components/memory)
- Aftercard Memory fill: Applies user-approved values to the target — a browser field, API header, or provider call — so values never reach the LLM. (https://aftercard.ai/docs/components/memory-fill)
- Payment Bridge: Payment backend bridge for account linking, KYC, card issuance, top-up, and execution callbacks. (https://aftercard.ai/docs/components/payment-bridge)
- Omnichannel UI: Web, mobile, Telegram, ChatGPT, Claude, and browser-extension apps for approvals and supervision. (https://aftercard.ai/docs/components/omnichannel-ui)

## End-To-End Shape

A typical flow starts with user intent, optionally uses MagicSearch to find provider-method guidance, then lets the agent execute through built-in browser or an API/protocol channel. Protected steps use Aftercard Memory and Aftercard Memory fill, and Omnichannel UI asks the user before payment execution proceeds.

## Related

- MagicFill: https://aftercard.ai/docs/components/magicfill
- MagicSearch: https://aftercard.ai/docs/components/magicsearch
- Aftercard Memory fill: https://aftercard.ai/docs/components/memory-fill