Deposit and withdrawal in a broker script

Deposit and withdrawal in a broker script are the operating flow next to the terminal: payment methods, requests, fees, statuses, and connection with KYC. Without this, a white-label account area can trade on demo but cannot handle money. An empty "Deposit" button without a gateway is worse than honestly hiding the method.

Technically, this means database request entities, payment provider callbacks, manual processing where auto-withdrawal is not enabled, and strict user-status checks before payout.

Deposit flow

• Method list in the account area with currency and minimum amount.
• Invoice or session creation at the provider and return to the brand domain.
• Idempotent callback: repeated notification does not credit the balance twice.
• Statuses: created, pending, successful, error/canceled.
• Credit to the real account and record in operation history.

Account area: trader account. Demo is separate: virtual balance without payment provider: demo account. Brand: white label.

Withdrawal flow

A request contains amount, method, details, and fee. Before payout, check KYC approved and no holds. Statuses are visible to the user. Admin confirms or rejects with a reason. Enable auto-withdrawal only with limits and the client's anti-fraud rules.

1. Sandbox deposit -> balance increased once.
2. Withdrawal request without KYC -> rejection with a message to pass verification.
3. After KYC -> request enters the admin queue.
4. Rejection with a reason is visible in the account area.

KYC: KYC platform.

Connection with trading

Do not subtract a withdrawal from an amount locked as Forex margin without rules. For BO, check whether there are open options according to the operator policy. Products: BO, Forex, BO script, Forex script, terminal: terminal.

After deposit, lead the user to the real terminal, but do not hide payment history; people want to see where the money is.

Security

Callback only with signature verification and IP checks where possible. Reconcile amounts with the provider; do not trust only redirect query string. Admin balance operations go to the audit log. Detail or receipt files should not be publicly served.

HTTPS across the whole account area. Mixed content on the payment page breaks trust and sometimes the gateway widget itself.

Support and statuses

The client card should show recent deposits/withdrawals, provider transaction ids, and KYC. A "payment is being processed" reply template must use the real database status, not an excuse. Define manual-withdrawal SLA inside the team.

Local tests

Use sandbox keys and provider test cards or crypto addresses. On .loc, external callbacks often cannot reach you; use a tunnel or manual callback emulation in the admin panel for staging. Method template edits: MicroEditor, files: MicroDrive, server: MicroPanel.

Acceptance checklist

Success/fail deposit scenarios, duplicate callback, withdrawal with KYC gate, UI fee, mobile details form, status emails. Runbook: what to do with a stuck "pending" request.

Deposit and withdrawal create stronger brand trust than the color of a Call button. Close statuses, KYC gate, and callback idempotency before advertising real funding.

Methods and geography

The method set depends on audience geography: cards, local payment systems, crypto, bank wire. Show only methods available to the user; otherwise a click goes nowhere. Store method minimums and maximums in config and show them before creating a request.

Crypto deposits: a separate address/memo per request or per user depending on the provider model; credit only after the required number of network confirmations. Wrong network is a typical ticket; add a warning to the UI.

Manual and automatic modes

Automatic deposit crediting by callback is normal. Auto-withdrawal should use limits, trusted details, and anti-fraud scoring. Anything above the threshold goes to a manual queue. "Urgent withdrawal" escalation must not bypass KYC.

Daily reconciliation with the provider registry catches differences before accounting does. A callback success without money at the provider means stopping payouts and investigating, not trusting the user.

Accounting and reporting

Every operation has id, type, amount, fee, currency, and external id. Exports for client accounting require a separate role. Do not give a marketing manager mass PII export without need.

Refunds and chargebacks should be statuses tied to the original deposit. Otherwise the balance will diverge from the payment provider forever.

Operations compliance

Large withdrawals require extra checks by operator policy: details matching KYC, delay, manual call. Include hold and request_info statuses. The user sees what must be provided, not an eternal "processing" with no text.

Account blocking should stop payouts and new deposits by rule while keeping access to history. Log who initiated the block.

Mark test deposits on production and exclude them from marketing reports. Confusing sandbox and prod keys is a separate go-live checklist item.

Payment acceptance criteria

Sandbox deposit, idempotent callback, fee in UI, withdrawal with KYC gate, statuses and emails, admin audit, external id reconciliation. Without this, real methods are premature. See KYC, account area, white label.

Money operations rhythm

Registry reconciliation, withdrawal queue, stuck "pending" requests older than threshold, callback errors. Payments need a separate alert channel, not the same place as "chart stale". The night responder knows where to enable deposit maintenance without deployment. Method documentation with provider contacts belongs in the secret store next to keys.

After fee changes, update UI and offer terms at the same time. A mismatch is grounds for dispute even if the debit is technically correct.

Localize provider error messages. Raw code=51 in the UI does not help. Keep the code-to-message table in config, not hardcoded in the template.

User messages about money

Every request status needs short text: what is happening and what to do. "Processing" without a time frame is irritating; "usually up to N hours" is better if true. For an additional-document request, provide a list and KYC link. For withdrawal rejection, give the reason and next step, not only "rejected".

Send push/email about deposit credit only after the balance actually increases, not after redirect success. Otherwise the user sees the email before the money and writes to chat.

Check repeated withdrawal form submission with the browser back button: a second request must not be created without new confirmation. Idempotency is needed not only for deposit callbacks, but also for withdrawal UI.