Payment requests: billing another agent with a link An agent finishes a job for another agent. Say it summarized a stack of filings, and the price was 5 USDT. Now it wants to get paid. Between people, the old tool for this is the invoice: how much, to whom, what for, by when. The payer decides when to pay, not the amount or the destination. Between agents, the risks get sharper. If the payer retypes the address and amount, a bad parse or a prompt injection can send the money elsewhere. What I want is an invoice an agent can read, check, and settle without retyping anything. Q402 calls this a payment request. The Wallets page describes it in one line: "Bill anyone with a shareable link. Track them in Activity → Requests." How a request moves Step 1. The biller creates it. The billing agent calls q402_request_create with an amount, a token (USDC, USDT, or USDG on Robinhood Chain), a chain, an optional memo of up to 200 characters, and an optional expiry in days (default 7, max 90). The recipient defaults to the biller's own Agent Wallet, so an agent can bill itself with just an amount. Creating a request moves no funds, so there is no confirmation step and a Trial key is enough. The tool returns a req_ id and a shareable /pay/req_… link. A human can open the link in a browser; another agent can take the id. Step 2. The payer looks before paying. q402_request_status takes the req_ id and returns the amount, token, chain, recipient, and status: open, paid, expired, or cancelled. It changes nothing and needs no API key. Step 3. The payer settles it. q402_request_pay takes the req_ id and confirm: true. Amount and recipient come from the stored request, so the payer cannot redirect the funds or change the sum. Paying moves real money, so the tool has the same guards as q402_pay. The opening call moves nothing: it returns a preview and a single-use consentToken that expires in about 120 seconds. The agent shows the preview to the user, waits for their next message, and calls again with the token. It also needs a live API key and Q402_ENABLE_REAL_PAYMENTS=1, and it respects Q402_MAX_AMOUNT_PER_CALL and Q402_ALLOWED_RECIPIENTS. A request above the cap, or to an address outside the allowlist, stops in the MCP server before anything is signed. It never reaches the chain. When it passes, the server signs from the payer's Agent Wallet (Mode C, a Q402-managed encrypted key) and relays the transfer gaslessly. The payer's agent holds no native gas token; gas is billed to the payer's own Q402 account. When a person pays through the link from their own wallet, the biller's account covers the gas instead. Step 4. Both sides reconcile. A successful pay returns a txHash and a receiptId. On the server, the request flips to paid and stores the transaction hash and the Trust Receipt id next to the original memo. In the dashboard, the row in Activity → Requests links to the explorer and to the receipt. That receipt is the same one every Q402 settlement gets: payer, recipient, amount, chain, tx hash, and block, signed by the relayer EOA. q402_receipt fetches it by rct_ id and verifies the signature locally. So reconciliation is a join on ids: the request carries the memo ("Invoice 1024 / API usage"), the receipt carries the proof, and the request record points from one to the other. If the job falls through, the biller can cancel an open request. Requests are not escrow Q402 also has escrow, and the two answer different questions. Escrow holds money before the work is done. The buyer locks funds in a non-custodial vault, then releases them on delivery or reclaims them after a timeout. It protects the buyer. A request holds nothing. It is a bill issued after (or alongside) the work, and the money moves straight from the payer's wallet to the recipient at the moment the payer settles. Until then, nothing is locked anywhere. The biller is extending trust, the way any invoice does. So the choice is about who carries the risk: a new counterparty and a large job lean toward escrow, a repeat customer and a small bill toward a request. Wiring it up Add the MCP server to Claude Code: claude mcp add q402 -- npx -y @quackai/q402-mcp The biller needs an API key in Mode C. The payer needs a live key and real payments switched on, in ~/.q402/mcp.env: Q402_MULTICHAIN_API_KEY=q402_live_... Q402_ENABLE_REAL_PAYMENTS=1 Q402_MAX_AMOUNT_PER_CALL=200 Q402_AGENT_WALLET_ADDRESS=0x... # pin one wallet if you have several On a new setup, q402_doctor walks through keys and signing mode. Then, on the biller side: You: Bill 5 USDT on BNB Chain, memo "Filing summaries, batch 12". Claude → q402_request_create → req_… + /pay/req_… link And on the payer side: You: Pay request req_… Claude → q402_request_status → 5 USDT to 0x… on bnb, open Claude → q402_request_pay → needs_consent preview You: yes Claude → q402_request_pay → paid, txHash + rct_… A request created with a sandbox key settles in mock mode, a reasonable way to rehearse the loop before money moves. The old part and the new part None of this is new as an idea. An invoice has always separated the right to set the terms from the act of paying. What changes with agents is that the separation has to be enforced in code, because the payer is a program that can be talked into things. Fixing the terms at creation, asking a human before settlement, and leaving a signed receipt afterward covers most of what I would want from a bill I did not write myself.