Sandbox Test Data

The sandbox gives you three endpoints to manage test data for your merchant:

POST /v1/merchant/sandbox/reset — wipe and optionally reseed
POST /v1/merchant/sandbox/seed-beneficiaries — generate sample beneficiaries across multiple countries and methods
POST /v1/merchant/sandbox/seed-payouts — generate sample payouts in mixed states for UI and webhook testing

All three are sandbox-only — calling them against production returns 403 sandbox_only. They’re scoped to your merchant — you can’t affect another merchant’s data.

Reset

Four reset scopes:

`?scope=`	What it does
`balances` (default)	Wipe `merchant_accounts` + sandbox transactions, re-seed fresh balances. Beneficiaries, instruments, and payouts stay.
`all`	Wipe payouts, instruments, beneficiaries, and sandbox transactions. Re-seed currency balances only.
`delete-all`	Wipe everything. No reseed. You land at zero state.
`full-reset`	Wipe everything. Re-seed balances + sample beneficiaries + sample payouts. Equivalent to a fresh merchant with demo data.

# Clean balances, keep your beneficiaries and payouts
curl "https://api.antonpayments.dev/v1/merchant/sandbox/reset?scope=balances" \
  -X POST \
  -H "Authorization: DPoP $ANTON_ACCESS_TOKEN"

# Nuclear option — fresh merchant state with demo data
curl "https://api.antonpayments.dev/v1/merchant/sandbox/reset?scope=full-reset" \
  -X POST \
  -H "Authorization: DPoP $ANTON_ACCESS_TOKEN"

Rate-limited to 10 resets per merchant per hour — enough for active development, tight enough to catch a runaway test suite. Response:

{
  "status": "reset",
  "scope": "balances",
  "merchant_id": "mer_01HX..."
}

status varies by scope:

balances → "status": "reset"
all → "status": "cleaned"
delete-all → "status": "deleted"
full-reset → "status": "reset" with extra counts for the sample data that was re-seeded

full-reset adds beneficiaries, instruments, and payouts counts so the dashboard can render a confirmation toast without a second call:

{
  "status": "reset",
  "scope": "full-reset",
  "merchant_id": "mer_01HX...",
  "beneficiaries": 4,
  "instruments": 4,
  "payouts": 4
}

Seed sample beneficiaries

Creates a curated set of realistic beneficiaries across multiple countries and payment methods — useful for populating your UI or testing country-specific edge cases:

curl https://api.antonpayments.dev/v1/merchant/sandbox/seed-beneficiaries \
  -X POST \
  -H "Authorization: DPoP $ANTON_ACCESS_TOKEN"

Response:

{
  "status": "seeded",
  "merchant_id": "mer_01HX...",
  "beneficiaries": 4,
  "instruments": 4
}

beneficiaries is the number of beneficiary records created; instruments is the number of payment instruments attached across those beneficiaries (usually one per beneficiary, but kept separate so the response shape stays honest if the seeder later creates multi-instrument beneficiaries). The beneficiaries created include a mix of individual and business types, spanning several corridors — enough variety to exercise most payout flows without you having to construct PII by hand.

Seed sample payouts

Creates payouts in a mix of states — completed, failed, cancelled, manual_review, and in-flight — so you can validate your UI and webhook handling against every outcome:

curl https://api.antonpayments.dev/v1/merchant/sandbox/seed-payouts \
  -X POST \
  -H "Authorization: DPoP $ANTON_ACCESS_TOKEN"

{
  "status": "seeded",
  "merchant_id": "mer_01HX...",
  "created": 4
}

created is the number of sample payouts created — one per seeded beneficiary, cycling through the four outcome triggers (happy path, slow, return, failure). Requires seeded beneficiaries first. Running seed-payouts with no beneficiaries returns 422 no_beneficiaries. Call seed-beneficiaries first, or use ?scope=full-reset on the reset endpoint which seeds both.

Using these in CI

A recommended CI pattern:

Before each test run, reset

POST /v1/merchant/sandbox/reset?scope=delete-all to guarantee a clean slate.

Seed any baseline data your tests assume

If your tests need a starting population (e.g., dashboard snapshot tests), call seed-beneficiaries and seed-payouts.

Run your tests

Exercise your real integration against the seeded state.

Between test suites, reset scoped to balances

?scope=balances is faster than a full reset — keeps your seeded data, resets funding state.

Rate limits apply across the hour: 10 resets per merchant per hour. In a heavy-test CI setup, either share a merchant across workers carefully, or provision multiple sandbox merchants.

Triggering specific scenarios (future)

Sandbox seeders produce a curated distribution — payouts in mixed states, beneficiaries across corridors. For deterministic triggering of specific engine verdicts, screening hits, or rail failures, that’s forthcoming functionality — when it lands it’ll use the ?simulate= query parameter on POST /v1/payouts (sandbox-only). Watch the changelog for when it ships.

What’s different from production

See Sandbox Overview for the full list. Key points:

Rail submission is mocked — no real banks are contacted
Timing is compressed — sandbox payouts transition to completed in seconds
Real OFAC screening runs, but you can trigger deterministic outcomes using specific test beneficiaries
All authentication, authorization, webhook signing, and state-machine behavior is identical to production

Reset

Seed sample beneficiaries

Seed sample payouts

Using these in CI

Triggering specific scenarios (future)

What’s different from production

Next steps

Sandbox overview

Going live

​Reset

​Seed sample beneficiaries

​Seed sample payouts

​Using these in CI

​Triggering specific scenarios (future)

​What’s different from production

​Next steps

Sandbox overview

Going live

Reset

Seed sample beneficiaries

Seed sample payouts

Using these in CI

Triggering specific scenarios (future)

What’s different from production

Next steps