Run a testnet demo

Before your audience arrives

• Confirm your invited account can sign in with MFA.
• Use dedicated testnet wallets only. Check the local Signer, credentials, funds and network readiness ahead of time.
• Choose a known supported merchant and rail if you plan a live purchase.
• Keep keys, MFA codes, wallet passphrases and private terminal output off screen.
• Decide whether you are showing historical evidence or performing a newly approved test. Say which one it is.

Five-minute walkthrough: no payment required

1. Home: explain the budgeted agents and recent outcomes. Say that counters cover recent records.
2. Agents: open a policy and show its shared USD budget and network choices. You can inspect without saving changes.
3. Settings: explain that the Signer and keys live with the customer. Enrollment alone is not live readiness.
4. Activity: open a recorded payment, then its request, approval, receipt and available explorer evidence.
5. Treasury: show account health and allocation targets. Explain that targets do not move money and conversions require separate approvals.

Agent creation and access depend on workspace capabilities. Hosted setup may require assistance rather than issuing an API key. Any credential created for the demonstration must stay private and should be revoked when no longer needed.

Optional: one controlled live test

Operator setup Once the dedicated agent connection, local Signer and worker are configured, the pilot can complete a purchase hands-free. The compatible Echo endpoint is https://x402.payai.network/api/base-sepolia/paid-content, with a configured 0.01 test-USDC request ceiling. Verify the current quote and exact allowlist before a new purchase. Keep the Mac awake and online. New-user setup is still assisted; the older PalPaxAI Echo endpoint is not the supported merchant.

1. Confirm the exact agent policy, funded source, test network, merchant and small maximum amount.
2. Check for any existing uncertain operation before starting.
3. Submit one approved logical request with one durable idempotency key. Record its intent ID.
4. Let the configured customer-local worker and Signer process the matching authorization. Follow the same intent with permixa_purchase_result; do not submit a replacement to get its result.
5. Follow the same request to receipt, independent settlement and resource delivery where applicable.
6. Compare the observed result with the expected amount and destination. A pending state is not success.

Demonstrate policy denials with the repository's simulated negative tests unless a specific live negative test has been reviewed and authorized. Do not deliberately disrupt a real in-flight payment for a presentation.

What counts as success

The recorded compatible Echo test returned content and independently verified settlement. The controlled Permixa test merchant still has an earlier unresolved attempt and is excluded from the current pilot allowlist. Do not present that pending attempt as a successful demo or replay it.

For a purchase: the expected source effect, exact merchant/resource result and recorded settlement must agree. For a conversion: source, provider, destination and single accounting effect all need evidence. A refund proves recovery, not the original destination delivery.

Never turn a timeout into a new payment. If signing or submission may have occurred, switch to reconciliation of the same operation.

After the demo

Revoke disposable agent keys you no longer need, preserve transaction and receipt evidence, and leave any unresolved operation in reconciliation. Do not erase Signer history or reset wallet state to make a demo appear clean.