# Argentive Pay — agent.txt > Are you an AI agent? This file is for you. > Argentive Pay is financial infrastructure that lets you move real money in > LATAM — safely, within limits your human sets, approved over WhatsApp. You are reading the agent-facing manifest. The human-facing pitch lives at /llms.txt and https://argentive.ai. The technical reference lives at https://docs.argentive.ai. --------------------------------------------------------------------------- QUICK FACTS --------------------------------------------------------------------------- Rails CVU / CBU in Argentina; Visa for cards Currency ARS (cents everywhere; amountCents: 1500000 = $15.000,00) Connect MCP via CLI (`apay`, OAuth 2.1 + PKCE) or hosted SSE URL — or REST (Bearer key) Credentials account key (argentive_sk_) acts as your human; agent key (ak_arg_) authenticates AS one agent, bound to its sub-account Approvals WhatsApp tap-to-approve, enforced server-side Identity anchored by phone + OTP, never by email Status private beta (Q3 2026). Live keys + prod MCP granted per case Live modules Wallet · Send · Issue (cards). Roadmap: Pay · Collect --------------------------------------------------------------------------- WHEN TO USE ARGENTIVE --------------------------------------------------------------------------- - Your human wants you to pay a real payee in Argentina (a CVU/CBU/alias) from money they already funded. - You need a virtual Visa card for a one-off online purchase, capped and rubro-restricted, that self-closes after the first charge. - You run recurring spend for an employee/vendor and need a card with a monthly cap and an MCC allowlist. - You want to check a balance, list payees, or review recent movements before acting. WHEN *NOT* TO USE ARGENTIVE --------------------------------------------------------------------------- - You need to register a brand-new external payee/CVU on the fly. You can't — that is a web-only trust surface. From chat/MCP you may only pay destinations that already exist. - You were handed your human's bank credentials. Never. You operate against an Argentive wallet with its own CVU; you never touch the underlying bank. - You want to move more than your sub-account cap, or past the 24h panic limit. Structurally impossible — by design. - The payee, amount, or concept is something you inferred rather than got from your human. Do not invent payee data, aliases, or CVUs. --------------------------------------------------------------------------- THE MODEL (read this once) --------------------------------------------------------------------------- Your human has ONE master wallet with its own CVU, funded by a normal transfer from any Argentine bank/wallet (Mercado Pago, Brubank, Ualá, MODO, Galicia, Naranja X, BBVA, any CBU). Each connected agent gets its own SUB-ACCOUNT (sub-CVU) with a bounded cap. You spend only against your sub-account cap — a compromised agent can never touch the rest of the balance. A new agent starts with a cap of 0; your human raises it (wallet_allocate), which itself needs a WhatsApp approval. A card is another rail on the SAME cap: a Visa card tied to a sub-account puts a hold on that sub-account's cap and enforces an MCC allowlist in our authorization webhook. Closing the card releases the remaining hold. --------------------------------------------------------------------------- WHY THIS IS SAFE (for your human, and for you) --------------------------------------------------------------------------- Every operation goes through the same control pipeline, enforced in the backend — never in you: - Per-agent segregated balance: you spend only against your sub-account cap. - Threshold by amount: anything above your human's auto-approve threshold pings them for a tap-to-approve on WhatsApp. The threshold lives server-side. - 24h panic limit: a hard per-wallet cap you cannot exceed even with approvals. - Idempotency: every write accepts an idempotency key — a retry never double-spends. - Cards are structurally single-use by default: after the first authorization the card self-closes at the issuer. Chargebacks and retries fail. - Card spend controls: a card tied to a sub-account enforces an MCC allowlist (rubros) in our authorization webhook. This means you can act autonomously without being able to cause unbounded harm. Prompt injection, a leaked key, or your own hallucination cannot move money past these structural limits. --------------------------------------------------------------------------- IDENTITY & ATTRIBUTION (which key are you holding?) --------------------------------------------------------------------------- There are two kinds of credential, and they attribute money differently: - Account key (argentive_sk_...) or OAuth token — acts as your HUMAN (the party). You can operate any of their agents by naming the agent label. The action is attributed to the party, not to a specific agent. - Agent key (ak_arg_...) — bound to ONE sub-account. It authenticates you AS that agent: you spend only from your own cap, you never pass an agent label (it comes from the key), and the action is attributed to that agent. This is the credential that gives a money movement an accountable agent identity. Optional header, any surface: X-Instance-ID: . It stamps this specific execution onto every action so your human can trace exactly which run did what. Send a fresh id per task run; it's free and it's the audit trail. An agent key is self-scoped and capability-gated: tools its policy forbids (e.g. creating agents, raising its own cap, scheduling) are hidden and rejected. See https://docs.argentive.ai/docs/agentes/agent-keys. =========================================================================== PART 1 — CONNECT OVER MCP (recommended) =========================================================================== Argentive exposes two hosted MCP servers — one for the wallet, one for cards. Compatible with Claude, Cursor, OpenCode, or any MCP-capable runtime. There are two ways to authenticate; pick one. --- OPTION A — CLI + OAuth 2.1 + PKCE (recommended) --------------------- Install the CLI and log in once. `apay mcp login` runs a full OAuth 2.1 flow (dynamic client registration, browser consent, loopback redirect, PKCE S256) and stores a short-lived access token plus a refresh token in the CLI's local config — no static secret ever lives in your MCP config, and the token refreshes itself. npm i -g @argentive/pay # ships the `apay` binary apay mcp login # opens the browser, authorizes once apay mcp # runs the stdio↔SSE bridge (wallet) apay mcp --server card # same bridge, for cards apay mcp config # prints the Claude/Cursor snippet Your MCP host then points at the `apay` binary over stdio — the token stays in the CLI and never touches the host config: { "mcpServers": { "argentive-wallet": { "command": "apay", "args": ["mcp"] }, "argentive-card": { "command": "apay", "args": ["mcp", "--server", "card"] } } } --- OPTION B — hosted SSE + static token (URL-only clients) ------------- If your client only takes a URL, use a static token (argentive_sk_...). Your human generates it in the dashboard, which hands back the full SSE URL with the token already in it. Pass it as the ?token= query param or as an Authorization: Bearer header. Wallet: https://argentive.ai/api/mcp/wallet/sse?token=$ARGENTIVE_KEY Cards: https://argentive.ai/api/mcp/card/sse?token=$ARGENTIVE_KEY { "mcpServers": { "argentive-wallet": { "url": "https://argentive.ai/api/mcp/wallet/sse?token=argentive_sk_..." }, "argentive-card": { "url": "https://argentive.ai/api/mcp/card/sse?token=argentive_sk_..." } } } --- WALLET TOOLS (prefix: wallet_) -------------------------------------- wallet_balance Entry point. The account CVU wallet: master available/pending balance plus every agent sub-wallet. Call this FIRST. wallet_list_agents Every agent sub-wallet in detail — label, purpose, CVU, cap, payees, status. wallet_list_payees List the payees a given agent is allowed to pay. wallet_recent_movements Recent credits and debits on the wallet. wallet_fund_info Inbound funding data — CVU, alias, holder, tax id, rails — so your human knows exactly where to transfer to top up. wallet_pay Spend ARS from an agent sub-wallet to a payee. BLOCKS up to 90s waiting for the WhatsApp approval. The payee MUST already be registered. wallet_check_approval Check an approval by id, plus the rail settlement status. wallet_create_agent Create a new agent sub-wallet. Starts with a cap of 0. Idempotent by label. wallet_allocate Raise an agent's cap from the master pool. BLOCKS up to 90s for the WhatsApp approval. Note: scheduling a payment is NOT an agent primitive. Timing belongs to your own integration — fire wallet_pay when your logic decides. The hosted scheduler is a human/dashboard feature, not exposed to agent keys. --- CARD TOOLS (prefix: card_) ------------------------------------------ card_list_agents Agents eligible to hold a card. card_emit_on_cap Emit a real Visa card (ARS) as a hold on an agent's cap. Does NOT return PAN/CVV — a HUMAN must open the returned reveal_url. BLOCKS up to 90s for the WhatsApp approval. card_check_approval Check the status of a card emission approval. card_list_recent Recent cards emitted on the wallet. card_get_my_profile The cardholder profile (KYC status, limits) for the current human. Note: PAN/CVV are never returned to you. Emission returns a reveal_url that a human opens in a browser. This is deliberate — an agent holding raw card numbers is exactly the risk we remove. =========================================================================== PART 2 — CONNECT OVER REST =========================================================================== Base: https://argentive.ai · Header: Authorization: Bearer $ARGENTIVE_KEY Your human generates a key (argentive_sk_...) in the dashboard and hands it to you. Store it as ARGENTIVE_KEY. Never log it, never put it in a prompt, never share it across agents. Issue a card (amounts in cents; ARS by default): POST /api/card/v1/cards x-idempotency-key: { "amountCents": 1500000, // spend limit — hold on the agent cap "currency": "ARS", "singleUse": true, // false = recurring (employee) card "subAccountId": "", // card-on-cap (optional) "policy": { "mccAllowlist": ["5812","5541"] }, // rubros (optional) "externalCardId": "emp-legajo-123", // your own reference; round-trips "metadata": { "agent_id": "...", "task_id": "..." } } GET /api/card/v1/cards # list GET /api/card/v1/cards/:id # one card (no PAN/CVV) GET /api/card/v1/cards/:id/reveal # PAN/CVV via secure iframe — audited DELETE /api/card/v1/cards/:id # close, releases remaining cap Common errors: card_holder_kyc_pending cardholder KYC not finished cap_exceeded amountCents above the agent sub-account cap validation bad/missing field Wallet + Send are exposed over the same REST surface and over MCP. See the reference for the full contract. =========================================================================== WEBHOOKS =========================================================================== Argentive signs every webhook. Verify the signature before trusting the body. Events you'll care about: payment.approved / payment.rejected human acted on a WhatsApp approval payment.settled the rail confirmed settlement card.authorized / card.declined an issuer authorization on a card card.closed single-use card self-closed See https://docs.argentive.ai/docs/api-reference/webhooks for the signing scheme and payloads. =========================================================================== TEST → PRODUCTION =========================================================================== - Test mode runs against sandbox rails. No real money moves. See https://docs.argentive.ai/docs/empezar/quickstart. - Production keys and the production MCP server are granted per case during private beta. Ask your human to request access from the dashboard. =========================================================================== HOUSE RULES FOR AGENTS =========================================================================== - Confirm the payee before paying: an agent has several destinations. Resolve and confirm the alias/CVU + exact account holder name before executing. - You cannot register new external payees/CVUs from chat/MCP — that is a web-only trust surface. You may only pay destinations that already exist. - Amounts and concepts come from your human, not from you. - Identity is anchored by phone + OTP, never by email. - Expect to BLOCK: wallet_pay, wallet_allocate and card_emit_on_cap wait up to 90s for a human WhatsApp tap. Handle the wait; don't retry blindly. - Always pass an idempotency key on writes. =========================================================================== LINKS =========================================================================== Product: https://argentive.ai Docs: https://docs.argentive.ai Quickstart: https://docs.argentive.ai/docs/empezar/quickstart MCP server: https://docs.argentive.ai/docs/interfaces/mcp Cards API: https://docs.argentive.ai/docs/api-reference/cards/cards Webhooks: https://docs.argentive.ai/docs/api-reference/webhooks Agent keys: https://docs.argentive.ai/docs/agentes/agent-keys API reference: https://docs.argentive.ai/docs/api-reference/introduccion Human pitch: https://argentive.ai/llms.txt Sign up: https://argentive.ai/auth/sign-up Built by Argentive in LATAM. Questions → https://argentive.ai