A single “processing time” mixes decisions controlled by Bizzo with delays controlled by a bank, card scheme, e-wallet or blockchain. The reliable record gives each stage its own timestamp and evidence.
Open the verified play routeConfirm account details, payment ownership, limits and verification status. Save the applicable terms and do not assume that prior deposits completed every identity check.
Record amount, currency, method, reference and submission time. Note any reversal window and avoid cancelling a withdrawal merely to resume play.
Save status changes and support case numbers. If documents are requested, record the exact request and the secure upload receipt without exposing the documents publicly.
For bank or e-wallet payments, retain the processor reference; for crypto, capture the transaction ID. An approved status without dispatch evidence remains an operator-side stage.
Finish the timeline when the receiving account can use the funds. Record weekends, bank cut-offs, confirmations and receiving-provider holds separately.
| Record | Capture | Decision use |
|---|---|---|
| Request | Cashier reference and time | User initiates |
| Review | Pending/KYC/support events | Operator controls |
| Dispatch | Payment or chain reference | Rail begins |
| Receipt | Usable receiving balance | Journey ends |
A fair comparison holds method, currency, verification state, amount band and day type constant. Publish the sample count and range instead of converting the fastest case into a promise. Large balances can also be constrained by rolling limits even when one transaction is fast.
At cashier submission; show verification and reversal periods as separate stages inside the total.
No. Look for a bank/processor reference or blockchain transaction ID.
Method, account review, amount, weekends and receiving-provider rules can all change elapsed time.