Single operation number
It links the player, amount, currency, payment method, payment provider and the full processing history.
Documentation / Payment Flow
How the payment API works
Review the complete payment path: from creating a deposit and confirming payment through to crediting funds, withdrawals, refunds and financial reconciliation.
Deposit
creation and crediting
Payout
verification and sending
Statuses
operation confirmation
Reconciliation
financial control
Payment flow
From request to final outcome
01
Create the operation
Record the player, amount, currency, payment method and unique operation number.
02
Confirm payment
Redirect the player to the payment page, request bank confirmation or process the payment directly.
03
Receive the final status
Check the payment provider response and confirm the final outcome of the operation.
04
Update balance and accounting
Credit or debit funds once, account for the fee and record the operation for reconciliation.
Overview
Every payment follows controlled stages
The platform assigns its own operation number, links it to the payment provider response and changes financial state only after a confirmed outcome. A repeated request must not create a second debit or credit.
Clear statuses
The operation moves only through permitted stages and does not change a completed outcome without a separate adjustment.
Separate financial accounting
Payment status, balance change, fee and accounting entry are linked but checked separately.
Deposit flow
Typical deposit flow
A deposit starts with an internal operation and ends with a one-time credit after payment-provider confirmation.
01
Validate the request and create the operation
The platform checks the player, KYC, limits, currency, amount and payment method, then assigns an internal operation number.
02
Send the payment to the provider
The provider receives the amount, currency, player data, return URL, notification URL and required payment details.
03
Confirm payment
The player confirms the payment on an external page, through 3-D Secure or in a banking app.
04
Receive confirmation and credit funds
After validating the signature and final status, the platform increases the player's balance once and completes the operation.
Withdrawal and refund
Withdrawals, cancellation and refunds
Outgoing operations require verification of the player, available balance, risk, payment details and the payment provider's final response.
Player verification
KYC, age, account status, limits, self-exclusion and permitted withdrawal methods.
Risk checks
AML, fraud indicators, wagering conditions, source of funds and operator approval.
Reserve the amount
The amount is held on the balance until the final payout outcome is received.
Send to the payment provider
A separate payout request is created with a unique number and verified recipient details.
Wait for the outcome
The platform accepts intermediate statuses and does not debit the amount again.
Refund
A refund is created as a separate operation linked to the original payment and its own amount.
Cancellation
Cancellation is possible only before the irreversible stage and does not replace a refund for an already completed operation.
Final reconciliation
The provider report, payout data, fees and balance changes must show the same result.
Operation statuses
Recommended status model
Internal statuses normalize different payment-provider responses into one clear model for the platform.
Created
The operation has been created within the platform but has not yet been sent to or accepted by the provider.
Action required
The player needs to confirm payment, enter details or take an action with their bank.
Processing
The provider has accepted the operation, but the final outcome has not yet been confirmed.
Completed
The operation has completed successfully, after which the balance is changed once.
Rejected
The operation has ended in rejection with the reason retained and without another debit or credit.
Unconfirmed
The operation outcome is unknown because of a connection failure, response delay or conflicting data.
An unknown outcome cannot be treated as a rejection
The payment may have been accepted by the provider even without a timely response. First request the current status or wait for confirmation, and only then decide whether another operation is needed.
Reliability and reconciliation
Duplicate protection and financial reconciliation
Payment API reliability depends on safe behavior for repeated requests, delayed confirmations and partial failures.
Protection against repeated operations
Every deposit, withdrawal and refund receives a unique number.
A repeated request returns the existing result and does not create a new financial operation.
A repeated notification is checked against the event number and current payment state.
The balance change is linked to the payment number and applied only once.
Financial accounting and reconciliation
Store the amount, fee, net amount, currency and provider reference separately.
Do not rewrite a completed entry retrospectively; create a separate adjustment.
Reconcile API operations, provider reports, balance changes and payouts.
Record each discrepancy, its cause, owner and resolution result.
Testing
What to test before launch
Test successful payment, rejection, connection loss, repeated confirmation, unknown outcome, refund and financial reconciliation.
Successful deposit and withdrawal
All intermediate statuses, confirmation, balance change and final reporting.
Operation rejection
Insufficient funds, invalid details, limit exceeded, bank rejection, risk review and unavailable payment method.
Connection loss
The connection drops after the request is sent, and confirmation arrives later or is requested separately.
Repeated requests
The same operation or confirmation arrives again after processing is complete.
Refund and cancellation
Full and partial refund, cancellation before processing and prohibition on canceling a completed operation.
Reconciliation
The amount, fee, final status, balance and provider report match after all scenarios.
Pre-launch checklist
Production payments are enabled after statuses, confirmations, duplicate protection, balances and financial reporting have been verified.
Test and production environments use different credentials, notification endpoints and accounts.
The user's return to the website is not used as proof of successful payment.
The signature and event number are verified before changing the balance.
Deposits, withdrawals and refunds are protected against repeated execution.
An unknown status is clarified with the provider and checked during reconciliation.
Error alerts, PSP reports and a discrepancy-investigation process are configured.
Need to design a payment flow?
Send us the PSP list, payment methods, currencies, markets, balance rules and statuses. APIACE will help structure deposits, withdrawals, refunds, confirmation and financial reconciliation.