Skip to main content

Testing Payments Safely

Before going to production, you need confidence that your agent integration handles every scenario safely. This guide covers the testing environments (agent sandbox and Tempo Testnet), counterparty and time-window scenarios, and the migration to production. For policy semantics and the amount-threshold trio (APPROVED / REQUIRES_APPROVAL / DENIED), run the three-tier threshold test in Testing Spending Policies.

Prerequisites

An agent with an SDK key (Quickstart), or an agent sandbox (below)
For testnet scenarios: a funded Tempo Testnet wallet linked to your agent

Choose Your Environment

Fastest Lane: Agent Sandbox

The quickest way to test the payment lifecycle is the agent sandbox: POST /api/agents/sandbox creates a test-mode organization, agent, Tempo Testnet wallet, and SDK keys in one call, with no email verification or human approval. Sandbox payments execute in simulated mode: policy evaluation, spend tracking, receipts, and audit logs are real, but no onchain transfer happens, so you don’t need a signer or a funded wallet. See the Agent Sandbox Quickstart for the full flow, including claiming the sandbox later.

Tempo Testnet

When you want real onchain transactions, use Tempo Testnet:
Tempo TestnetProduction (Tempo / Base / Solana)
TokenpathUSD (free)USDC.e on Tempo or USDC on Base / Solana
Gas feesNoneCovered by Conto
OnchainYes, real blockchain transactionsYes
PoliciesFully enforcedFully enforced
Best forIntegration testing, policy validationLive agent operations
Tempo Testnet gives you real onchain transactions with real policy enforcement, using free test tokens. Your code stays the same when you switch to production. Only the wallet and chain change. The Quickstart covers creating and funding a testnet wallet.

Test Plan

This guide walks through two scenarios beyond the amount thresholds:
#ScenarioExpected Result
1Payment to blocked counterpartyDENIED
2Payment outside time windowDENIED
For amount-based outcomes: a REQUIRES_APPROVAL payment appears in Pending Approvals in the dashboard, where a human can approve or reject it; after approval, the agent can execute it (poll for the status change, or use webhooks to get notified). For handling DENIED and REQUIRES_APPROVAL statuses in code, see Error Handling.

Scenario 1: Blocked Counterparty

First create and assign the policy:
1

Create the policy

Go to PoliciesNew Policy.
FieldValue
NameTest: Blocked Address
Policy TypeCOUNTERPARTY
2

Add rule

FieldValue
Rule TypeBLOCKED_COUNTERPARTIES
Value0xBLOCKED0000000000000000000000000000dead
ActionDENY
3

Assign it to your agent

Add it in the Permissions tab.
Then send a $5 payment to the blocked address:
curl -X POST https://conto.finance/api/sdk/payments/request \
  -H "Authorization: Bearer $CONTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 5,
    "recipientAddress": "0xBLOCKED0000000000000000000000000000dead",
    "purpose": "Test: blocked recipient"
  }'
Verify:
  • Response status is "DENIED"
  • violations reference the blocked counterparty policy
  • Amount doesn’t matter. The address itself is blocked

Scenario 2: Time Window Restriction

To test time-based restrictions, temporarily add a time window policy:
1

Create a time window policy

FieldValue
NameTest: Business Hours Only
Policy TypeTIME_WINDOW
Rule TypeTIME_WINDOW
Start Time09:00
End Time17:00
ActionALLOW
2

Assign it to your agent

Add it in the Permissions tab.
3

Test outside the window

If it’s currently outside 9am-5pm in your timezone, any payment request will be denied with a time window violation.If it’s during business hours, you can temporarily set the window to a past range (e.g., 02:00-03:00) to trigger the denial.
4

Clean up

Remove the time window policy after testing to avoid blocking your other tests.
Policy-rule time windows use the server’s local time. If you need to test a specific IANA timezone, configure a wallet-level time window instead.

Checking Results in Bulk

After running your scenarios, review everything in one place:

Transactions Page

Go to Transactions in the dashboard. You should see:
  • Confirmed transactions from approved-and-executed payments
  • Denied/rejected entries from the blocked-counterparty and time-window scenarios
  • A pending-approval entry for any payment that required approval

Audit Logs

Go to Audit Logs to see the policy evaluation trail for every request. Each entry shows:
  • Which policies were evaluated
  • Which rules matched
  • The final decision and reasoning

Via API

# List recent transactions
curl https://conto.finance/api/sdk/transactions \
  -H "Authorization: Bearer $CONTO_API_KEY"

Testing x402 Micropayments

If your agent uses x402 protocol payments (paying for APIs), test the pre-authorize → record flow the same way. The request and response shapes are documented in the x402 SDK reference; the x402 guide covers the end-to-end flow.

Moving to Production

Once your scenarios pass:
  1. Create a production wallet on Base (USDC) or Solana (USDC)
  2. Fund it with real stablecoins
  3. Link it to your agent with production-appropriate limits
  4. Adjust policies for production thresholds (the test policies can remain as-is)
  5. Your integration code stays the same, no code changes needed
You can keep your testnet wallet and policies active alongside production. Many teams run test agents permanently for regression testing.

Troubleshooting

For unexpected policy outcomes (DENIED when you expected REQUIRES_APPROVAL, the wrong policy triggering, org policies overriding agent policies), see the policy troubleshooting accordions.
Check the Permissions tab on the agent detail page. Policies must be explicitly assigned to the agent. Creating a policy doesn’t automatically apply it.
Double-check the timezone setting on the policy. If your local timezone doesn’t match the policy timezone, the enforcement window may be offset.
The wallet balance was sufficient at request time but dropped before execution. This can happen if other transactions executed between request and execute. Re-fund the testnet wallet.

Next Steps

Secure Your Agent

Production-ready policy configurations

Recipes

Copy-paste solutions for specific tasks

Error Handling

Handle every error code gracefully

Policy Reference

All policy types and rule operators