Sandbox testing
In sandbox you can ask Hubpay to pretend that something happened: the payer paid, the payer paid too little, or the time limit passed. Your integration receives the same statuses and webhooks as in production. No real money moves.
There are four journeys. Together they cover the statuses and webhooks of a full payment, a part payment, an expired request, and a payout to a beneficiary through to PAID or FAILED. A few outcomes cannot be simulated yet, such as a failed payment. See what you cannot simulate yet.
| Journey | You prove that | Payer options |
|---|---|---|
| 1. Complete a payment | A full payment reaches PAID and COMPLETE and your webhook receives every lifecycle event | Bank transfer, card, crypto without a wallet, crypto with a test wallet |
| 2. Part payment | A payer who sends too little produces PART_PAID, and you can either collect the rest or credit what arrived | Bank transfer, card, crypto without a wallet, crypto with a test wallet |
| 3. Expire a payment request | A hosted or embedded checkout that is not paid in time shows the payer it has expired, and your webhook receives payment_request.expired | Hosted page, embedded |
| 4. Pay out to a beneficiary | A paid request with payout details creates a payout, you approve it if your account needs it, and you send the bank's result | Card or crypto for the payment. A simulated bank transfer cannot be used here |
Do Before you start once, then pick a journey. Each journey has tabs for the payer options. Pick the tab that matches how your payers pay. Your choice is remembered across the journeys.
For what each simulation endpoint does, and what cannot be simulated yet, see Simulation endpoints. Partners who onboard accounts through the API also have onboarding decisions and RFI cases in sandbox.
One rule for every journey
Webhooks can arrive late, more than once, or in a different order. After each step, also read the status with Get payment request. Trust the API status, not only the webhook.
