Skip to main content
Sandbox testing proves that your route can issue 402 requirements, verify guarantees, settle, serve paid work, and produce useful logs. Use Base Sepolia (eip155:84532) and small prices while you are validating behavior.
Keep sandbox wallets, keys, and prices separate from production. A test route should never rely on a production seller key or real production pricing.

​
What to test first

1

Unpaid request

Call the protected route without a payment header. Confirm your API returns HTTP 402 with the expected scheme, price, network, asset, and payTo.
2

Paid retry

Use a 4Mica-capable buyer client to sign a guarantee with a unique request ID, retry the request, and receive the protected response.
3

Invalid payment

Retry with a missing, expired, malformed, or mismatched payment header. Confirm the paid handler does not run.
4

Delivery evidence

Confirm logs connect request ID, guarantee ID, payer, route, price, settlement result, and response hash or delivery marker.
5

Default path

Exercise the default path in a controlled environment so your team understands how an unpaid net position is covered from locked collateral.
Watch the sandbox run in 4mica dashboard so guarantee issuance, settlement, and delivery evidence are visible together.

​
Sandbox checklist

Before adding tiers, metering, or complex workflows, prove the smallest paid route end to end.
CheckWhat to confirm
Test walletsYou use separate seller and buyer wallets for sandbox.
Small priceThe first route uses a low amount, such as $0.01.
One protected routeA simple route works before you add pricing complexity.
Server-side facilitator callYour server, not browser code, talks to the facilitator.
Invalid attemptsRepeated bad payments trigger rate limits or alerts.
Support lookupYou can find a paid request from a guarantee ID or request ID.

​
Abuse scenarios to simulate

  • A buyer without enough collateral tries to pay.
  • A buyer pays for a cheap route and reuses the header on an expensive route.
  • A buyer changes request parameters after receiving a quote.
  • A buyer sends many unpaid requests to force expensive pre-work.
  • A buyer claims the agent failed after receiving a response.
  • Another client tries to impersonate a known payer or agent.
The expected result is simple: unpaid or invalid requests do not trigger paid work, and every accepted request has a payment record tied to the delivered result.
If an unpaid, expired, malformed, or mismatched payment reaches paid execution, stop the rollout. Fix that path before testing more pricing models.
If an invalid or suspicious request still reaches paid execution, send the reproduction steps to support.

​
When sandbox is done

Move toward production only after the payment flow is boring. You should be able to answer the same questions from logs, dashboard records, and application behavior.
QuestionWhere the answer should appear
What did the buyer pay for?Route configuration, quote metadata, and request logs.
Which wallet paid?Payment record and request logs.
Which seller address received the obligation?Payment requirements and settlement records.
Which route and price were used?HTTP 402 response, logs, and dashboard activity.
Did verification and settlement succeed?Middleware result and facilitator records.
What did the agent return?Response hash, delivery marker, or stored result metadata.
What happens if a net debtor does not settle?Default-path test notes and clearing records.