Before an agent can pay for an API, prove the spend path is bounded.

launch checklist

Use this before a public x402 or Pay.sh demo.

A payment-agent demo should not be judged only by whether it completes a paid request. The useful proof is whether a stranger can see the maximum possible loss, who approved the spend, what was purchased, and how the system behaves when something goes wrong.

1. Default to sandbox or zero-value mode

First-run examples should avoid real funds unless a human intentionally switches modes.

• Demo command uses sandbox, testnet, dry-run, or zero-value mode.
• Real-payment mode is visually and programmatically separate.
• Docs explain exactly when real value can move.
• Automated tests never require a funded wallet.

2. Cap the spend in more than one place

One cap is a useful start. Two independent caps are safer.

• Per-call max spend.
• Per-session or per-day max spend.
• Service allowlist for paid endpoints.
• Wallet or contract-level limits where supported.
• Clear error when a cap is exhausted.

3. Require human approval before real payment

An agent can choose an API, but a user should know the price and purpose before money moves.

• Approval screen shows provider, endpoint, price, reason, and max total.
• Multi-call exploration requires a second approval.
• Ambiguous pricing pauses instead of guessing.
• The user can cancel without leaving partial state behind.

4. Write receipts and audit events

Every payment attempt should leave evidence.

• Request id or trace id.
• Provider and endpoint.
• Price and currency.
• Approval source.
• Payment proof or transaction reference when safe to store.
• Result state: paid, denied, capped, failed, retried, or refunded.

5. Treat payment metadata as sensitive

Resource URLs, reason strings, prompts, and descriptions can leak user intent or private context.

• Filter PII from payment descriptions and reason strings.
• Do not place private prompts in public payment metadata.
• Separate internal logs from public receipts.
• Document which metadata reaches facilitators, providers, or chains.

6. Block replay and duplicate purchase paths

Retries are normal. Paying twice for one action should not be.

• Idempotency key for payment attempts.
• Nonce or expiry on payment proofs.
• Duplicate detection before retrying after network failure.
• Receipt reconciliation if the provider succeeds but the client times out.

7. Validate the recipient and endpoint

The agent should not be able to pay a lookalike service because a page or tool response suggested it.

• Provider registry URL is pinned or verified.
• Payment destination is checked against the expected service.
• External provider docs and returned headers are treated as untrusted input.
• Endpoint category matches the user's approved task.

8. Show failure and refund behavior

Launch demos often show the happy path. Buyers care about the unhappy path.

• Payment declined.
• Cap exhausted.
• Provider returns paid-but-failed.
• Provider succeeds but the callback is delayed.
• Dispute, refund, or support path is documented.

9. Keep private keys and funded wallets out of public demos

Do not let a screenshot, video, env file, or public repo become the payment credential leak.

• .env and local wallet files are ignored.
• Examples use placeholders or sandbox wallets.
• No funded wallet seed, private key, or bearer token appears in docs, logs, or screenshots.
• CI uses mocked or sandbox payment flows.

10. Export a launch-readiness report

The report is what makes the demo reviewable by a teammate, judge, buyer, or sponsor.

• Verdict and score.
• Spend map.
• Control gaps.
• Evidence from files, routes, or docs.
• Safe launch path.
• Known unchecked areas.

For a browser-only first pass, run the Agent Commerce Gate. It reads local files in the browser and returns a ranked fix queue.

https://tateprograms.com/agent-commerce-gate.html