Simulating money flows
Drive payments, refunds, disputes and payouts by hand.
Every state change a real merchant can experience is triggerable from the environment's ledger tools — and each one emits the same webhook a live account would.
| Action | Effect | Events emitted |
|---|---|---|
| Create payment | Adds a succeeded charge and a balance transaction | payment.created, payment.succeeded |
| Refund payment | Full or partial refund against a charge | refund.created, refund.succeeded |
| Open dispute | Moves the amount into dispute, holds the funds | dispute.created |
| Submit evidence | Attaches evidence, dispute goes under review | dispute.updated |
| Close dispute | Won (funds returned) or lost (funds deducted) | dispute.closed |
| Run payout | Sweeps the available balance into a pending payout | payout.created |
| Settle payout | Marks the payout paid | payout.paid |
Funds maturity
Sandbox funds follow a T+2 availability model, like production: a payment lands in pending, becomes available after two simulated days, and only available funds can be paid out. Advance the clock from the ledger view instead of waiting.
Raw event simulation
Any event from the event catalog can also be fired directly with a synthetic payload — useful to test handlers for cases that are awkward to reach, such as invoice.payment_failed.
Test cards
| Number | Behaviour |
|---|---|
| 4242 4242 4242 4242 | Succeeds |
| 4000 0000 0000 9995 | Declined — insufficient funds |
| 4000 0000 0000 0259 | Succeeds, then disputed as fraudulent |