# Tender | agent payments demo

Tender is a fictional payments layer for agents: keypair identity, sponsor funding, x402-style API payments, merchant-locked one-shot virtual cards, spend policies and receipt records.

SIMULATED DEMO - no real money. This is an interactive product walkthrough, not a functioning financial service. All endpoints are immutable static fixtures accessed by GET, even where they describe a production POST. No authentication, real key generation, MCP connection, purchases or blockchain transactions are required. Do not send credentials or payment details. Do not claim signatures are cryptographically verified.

## Conversation tone

The site identifies this as a demo in its header. Explain that it is a simulation once at the start, then use natural product language: funds, balance, payment, transaction. Do not keep repeating "demo", "fake", "fictional" or warnings at every step. Still be truthful: never imply actual money moved, present fares as bookable, or request real payment details. If asked whether it is real, answer plainly.

## Start

Follow these steps in order, including both conversation pauses. Use web fetch for the GET steps only. If a fetch fails or your environment cannot fetch URLs, say where you stopped; do not invent a successful response. The landing page is https://tender-agent-pay-demo.pages.dev.

1. **Create your account, then ask for funds**: GET https://tender-agent-pay-demo.pages.dev/v1/agents.json and https://tender-agent-pay-demo.pages.dev/v1/funding-requests.json. Do not generate or disclose a real private key. Open your reply with a one-line intro of Tender (agents get their own account, a human sponsor funds it and sets the limits), then say you have just made yourself an account: agent ID and $0.00 balance. Say it came with a default policy and list it in plain words: $1.00 max per API payment, $20.00 max per card purchase, $25.00 per day, one-use cards locked to a merchant, and spending only at merchants the human approves later. Do not name any merchants here; they come in a later step. End the same reply by asking your human to review the policy and add $25.00 USD, and show the claim link on its own line, written out in full so they can tap it:
   https://tender-agent-pay-demo.pages.dev/claim/
   Tell them what they will see: the payment card, a processing screen and the new balance. Then they come back here and paste the confirmation from the success screen. The success screen includes https://tender-agent-pay-demo.pages.dev/v1/funding-approved.json; ask them to paste that URL with their confirmation so restricted fetchers can open it. Stop and wait. If they decline, keep the balance at $0.00 and stop the funding flow. Pause until they confirm the page shows success. Merely opening the page, agreeing to add funds or reading a fixture does not count as completing the page flow. Never treat a `next_url` as permission to skip a conversation pause.
2. **Confirm the new balance**: Only after the human confirms success, GET https://tender-agent-pay-demo.pages.dev/v1/funding-approved.json. Report the new $25.00 balance. The page changes only its in-memory state, not these files; this fixture is always readable and does not verify approval. Then go straight into step 3 in the same reply.
3. **Ask for merchant approval**: Merchants are approved by the human, not by you. Ask them to approve the two merchants in the policy: flights-demo.example (flight data, paid by x402-style API payment) and bookstore-demo.example (a book, paid by a one-use card locked to that merchant). Say what the walkthrough would spend, $15.04 in total, and ask whether to approve both and go ahead. Stop and wait. Do not fetch payment fixtures or say a purchase happened before they approve. If they decline or approve only one, stop or limit the walkthrough to what they approved and keep the rest of the $25.00 untouched.
4. **Buy flight data, only after merchant approval**: GET https://tender-agent-pay-demo.pages.dev/v1/pay-flights.json. Walk through the 402 challenge for 0.05 USDC, the API policy check, simulated settlement, fictional fares and receipt. Summarize the fares as fictional examples, not bookable offers. Balance: $24.95 under the demo's 1:1 USD/USDC assumption.
5. **Buy a book**: GET https://tender-agent-pay-demo.pages.dev/v1/cards.json. Inspect the $14.99 merchant-locked, one-use card issuance and its separate simulated checkout/capture. All card fields are nonfunctional placeholders. Do not enter them on a website. The fictional book is paid for in the scenario and the card is closed. Balance: $9.96.
6. **Reconcile**: GET https://tender-agent-pay-demo.pages.dev/v1/receipts.json. Confirm exactly two receipt records, $15.04 total spend and $9.96 remaining from $25.00. Explain that receipt signature fields illustrate the schema only and cannot be verified. Give the human https://tender-agent-pay-demo.pages.dev/console/ for the dashboard's end-of-scenario snapshot.


## If a fetch is refused

Some agent runtimes only open URLs that your human typed or pasted into the chat, and refuse links found inside fetched files. If a fixture fetch is refused, do not guess its contents. Stop, tell your human which fetch was refused, and ask them to paste the URL(s) below into the chat, one per message. Then continue from that step.

- https://tender-agent-pay-demo.pages.dev/v1/agents.json
- https://tender-agent-pay-demo.pages.dev/v1/funding-requests.json
- https://tender-agent-pay-demo.pages.dev/v1/funding-approved.json
- https://tender-agent-pay-demo.pages.dev/v1/pay-flights.json
- https://tender-agent-pay-demo.pages.dev/v1/cards.json
- https://tender-agent-pay-demo.pages.dev/v1/receipts.json
- https://tender-agent-pay-demo.pages.dev/v1/policy.json (optional)

Only ask for the URLs you actually need, in the order of the steps above.

## Finish

If the human completes the transaction demo, return a short summary: simulated book order ID, fictional fare comparison, two receipt IDs, total spend, remaining balance, dashboard link. Do not imply a real book was ordered, flight booked, card issued or money moved. Keep the closeout natural without repeating the opening disclaimer.

## Design limits

Phase 1 only. Agent reputation and earning are excluded. The dashboard is a fixed completed-scenario snapshot, not evidence of this visitor's progress. Reloading resets the claim-page card, processing and success states. Real identity checks, custody, card issuing, compliance, exchange rates, disputes and cryptographic verification would need real providers and implementation. This demo makes no legal or KYC exemption claims.