Testing Payments Safely

Before going to production, you need confidence that your agent integration handles every scenario — approved, denied, requires approval, insufficient balance, and more. This guide covers how to test each one safely on Tempo Testnet.

Prerequisites

Why Tempo Testnet

	Tempo Testnet	Production (Base / Solana)
Token	pathUSD (free)	USDC (real money)
Gas fees	None	Covered by Conto
On-chain	Yes — real blockchain transactions	Yes
Policies	Fully enforced	Fully enforced
Best for	Integration testing, policy validation	Live agent operations

Tempo Testnet gives you real on-chain 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.

Test Plan

This guide walks through 5 scenarios that cover the core payment lifecycle:

#	Scenario	Expected Result
1	Simple payment under limits	APPROVED → execute → confirmed
2	Payment exceeding spend limit	DENIED
3	Payment requiring approval	REQUIRES_APPROVAL
4	Payment to blocked counterparty	DENIED
5	Payment outside time window	DENIED

Setup: Create Test Policies

Create these policies to test against. If you already have policies from the quickstart, you can reuse or modify them.

Policy: Spend Cap

Create the policy

Go to Policies → New Policy.

Field	Value
Name	Test: Spend Cap
Policy Type	SPEND_LIMIT

Add rule

Field	Value
Rule Type	MAX_AMOUNT
Operator	LTE
Value	25
Action	ALLOW

Transactions above $25 are denied.

Policy: Approval Threshold

Create the policy

Field	Value
Name	Test: Approval Threshold
Policy Type	APPROVAL_THRESHOLD

Add rule

Field	Value
Rule Type	REQUIRE_APPROVAL_ABOVE
Operator	GREATER_THAN
Value	15
Action	REQUIRE_APPROVAL

Policy: Blocked Counterparty

Create the policy

Field	Value
Name	Test: Blocked Address
Policy Type	COUNTERPARTY

Add rule

Field	Value
Rule Type	BLOCKED_COUNTERPARTIES
Value	`0xBLOCKED0000000000000000000000000000dead`
Action	DENY

Assign all three policies to your test agent in the Permissions tab.

Scenario 1: Approved Payment

A $5 payment — under all thresholds.

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": "0x1234567890abcdef1234567890abcdef12345678",
    "purpose": "Test: approved payment",
    "category": "TESTING"
  }'

Verify:

Response status is "APPROVED"
Execute it and confirm txHash is returned
Check Transactions in the dashboard — status should be “Confirmed”
Check Audit Logs — you should see the policy evaluation trail

# Execute the approved payment
curl -X POST https://conto.finance/api/sdk/payments/REQUEST_ID/execute \
  -H "Authorization: Bearer $CONTO_API_KEY"

Scenario 2: Denied by Spend Limit

30 payment — exceeds the

25 cap.

curl -X POST https://conto.finance/api/sdk/payments/request \
  -H "Authorization: Bearer $CONTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 30,
    "recipientAddress": "0x1234567890abcdef1234567890abcdef12345678",
    "purpose": "Test: over spend cap"
  }'

Verify:

Response status is "DENIED"
violations array contains a message referencing the spend cap
The requestId exists but cannot be executed

Handle it in code:

const result = await conto.payments.request({
  amount: 30,
  recipientAddress: '0x1234567890abcdef1234567890abcdef12345678',
  purpose: 'Test: over spend cap',
});

if (result.status === 'DENIED') {
  console.log('Blocked by policy:', result.violations[0].message);
  // Your agent should log this and try a smaller amount or escalate
}

Scenario 3: Requires Approval

20 payment — under the

25 cap but over the $15 approval threshold.

curl -X POST https://conto.finance/api/sdk/payments/request \
  -H "Authorization: Bearer $CONTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 20,
    "recipientAddress": "0x1234567890abcdef1234567890abcdef12345678",
    "purpose": "Test: needs approval"
  }'

Verify:

Response status is "REQUIRES_APPROVAL"
The payment appears in Pending Approvals in the dashboard
A human can approve or reject it from the dashboard
After approval, the agent can execute it

Handle it in code:

const result = await conto.payments.request({
  amount: 20,
  recipientAddress: '0x1234567890abcdef1234567890abcdef12345678',
  purpose: 'Test: needs approval',
});

if (result.status === 'REQUIRES_APPROVAL') {
  console.log('Waiting for human approval:', result.requestId);
  // Poll for status change, or use webhooks to get notified
}

Scenario 4: Blocked Counterparty

A $5 payment to a 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 5: Time Window Restriction

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

Create a time window policy

Field	Value
Name	Test: Business Hours Only
Policy Type	TIME_RESTRICTION
Rule Type	TIME_WINDOW
Start Time	09:00
End Time	17:00
Timezone	Your timezone
Action	ALLOW

Assign it to your agent

Add it in the Permissions tab.

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.

Clean up

Remove the time window policy after testing to avoid blocking your other tests.

Checking Results in Bulk

After running all scenarios, review everything in one place:

Transactions Page

Go to Transactions in the dashboard. You should see:

Confirmed transactions from Scenario 1
Denied/rejected entries from Scenarios 2, 4, 5
A pending-approval entry from Scenario 3

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:

# Pre-authorize an x402 payment
curl -X POST https://conto.finance/api/sdk/x402/pre-authorize \
  -H "Authorization: Bearer $CONTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 0.05,
    "recipientAddress": "0x1234567890abcdef1234567890abcdef12345678",
    "resourceUrl": "https://api.example.com/data",
    "serviceDomain": "api.example.com"
  }'

If authorized, the response includes "authorized": true and the selected wallet.

Moving to Production

Once all 5 scenarios pass:

Create a production wallet on Base (USDC) or Solana (USDC)
Fund it with real stablecoins
Link it to your agent with production-appropriate limits
Adjust policies for production thresholds (the test policies can remain as-is)
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

All scenarios return APPROVED (policies not enforcing)

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.

DENIED but expected REQUIRES_APPROVAL

Policies use AND logic — the most restrictive outcome wins. If one policy denies and another requires approval, denial takes priority. Check which policies are assigned and their rule values.

Time window tests pass when they shouldn't

Double-check the timezone setting on the policy. If your local timezone doesn’t match the policy timezone, the enforcement window may be offset.

Execute returns INSUFFICIENT_BALANCE after approval

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

Get Started

Quick Start

CLI

SDK

MCP Server

Policies

Integrations

Guides

Testing Payments Safely

Testing Payments Safely

Prerequisites

Why Tempo Testnet

Test Plan

Setup: Create Test Policies

Policy: Spend Cap

Policy: Approval Threshold

Policy: Blocked Counterparty

Scenario 1: Approved Payment

Scenario 2: Denied by Spend Limit

Scenario 3: Requires Approval

Scenario 4: Blocked Counterparty

Scenario 5: Time Window Restriction

Checking Results in Bulk

Transactions Page

Audit Logs

Via API

Testing x402 Micropayments

Moving to Production

Troubleshooting

Next Steps

Secure Your Agent

Recipes

Error Handling

Policy Reference

Get Started

Quick Start

CLI

SDK

MCP Server

Policies

Integrations

Guides

​Testing Payments Safely

​Prerequisites

​Why Tempo Testnet

​Test Plan

​Setup: Create Test Policies

​Policy: Spend Cap

​Policy: Approval Threshold

​Policy: Blocked Counterparty

​Scenario 1: Approved Payment

​Scenario 2: Denied by Spend Limit

​Scenario 3: Requires Approval

​Scenario 4: Blocked Counterparty

​Scenario 5: Time Window Restriction

​Checking Results in Bulk

​Transactions Page

​Audit Logs

​Via API

​Testing x402 Micropayments

​Moving to Production

​Troubleshooting

​Next Steps

Secure Your Agent

Recipes

Error Handling

Policy Reference

Testing Payments Safely

Prerequisites

Why Tempo Testnet

Test Plan

Setup: Create Test Policies

Policy: Spend Cap

Policy: Approval Threshold

Policy: Blocked Counterparty

Scenario 1: Approved Payment

Scenario 2: Denied by Spend Limit

Scenario 3: Requires Approval

Scenario 4: Blocked Counterparty

Scenario 5: Time Window Restriction

Checking Results in Bulk

Transactions Page

Audit Logs

Via API

Testing x402 Micropayments

Moving to Production

Troubleshooting

Next Steps