Demo account in a trading script

A demo account in a trading script provides a virtual balance and the same screens as a real account: terminal, history, and sometimes even a training "deposit" without a payment provider. The user learns to press buttons without risk; the operator reduces support questions such as "how do I open a trade".

A launch mistake is mixing demo and real into one balance number or resetting both together. In the database these are different accounts or separate ledgers; in the UI, every screen that shows money must have a clear label.

Rules to fix immediately

• Separate demo and real balance.
• Demo reset button to the starting amount.
• Clear transition to the real account: CTA, not a hidden substitution.
• Demo history is not disguised as real in statements.
• Withdrawing money from demo is impossible by definition.

Account area: trader. BO: options, platform. Forex: script, platform.

Feed on demo

Demo prices are usually the same market prices as real; the account money changes, not the market. A one-second delay for demo is acceptable. A separate "drawn" price is dangerous: the user moves to real and sees different movement behavior. Quotes: quotes, API, chart: TradingView.

1. Open the demo terminal: last price moves.
2. Make a trade: balance and history update.
3. Reset demo: history and balance return according to product policy.
4. Check that real did not change.

Transition to real

The transition screen explains: demo is virtual; next comes funding and possibly verification. The deposit button leads to the payment flow: deposit and withdrawal. After the first deposit, open the real terminal by default, but keep the account switcher; many users continue practicing.

White label: white label. Terminal: terminal. Web instead of desktop: MT4 alternative.

Demo restrictions

Sometimes you limit maximum trade amount, asset list, or reset frequency to prevent abuse such as endless resets for profit screenshots. Keep limits in the admin panel. Do not show demo profit in public rankings next to real without a label; it creates fake marketing and complaints.

Support

A common ticket is "where did the money go" after an accidental account switch. Highlight the active account with a color or badge in the terminal and account header. In support, the client card should show both balances immediately.

Acceptance checklist

Scenario: registration -> demo trade -> history -> reset -> CTA to real -> test deposit in sandbox. The mobile account label is readable. Infrastructure: MicroPanel, MicroDrive.

A demo account works when virtual money is honestly separated, the market is the same, and the path to real is clear. Do this before advertising, and onboarding stops burning in chat.

Starting balance and demo economics

The starting amount should allow a dozen training trades but should not look like a million-dollar screenshot for fraudulent marketing. If reset is allowed, limit frequency: once per day or N times per week. Log resets so abuse is visible.

Demo payout percentage and leverage should stay close to real. An inflated demo "wow" effect leads to shock on the real account and chargebacks or review scandals.

Demo in team support

Support should be able to view demo history "as the user". A frequent case: the user thinks they were trading real. A badge and a "you are on demo" email after registration reduce confusion. Add a chat macro explaining how to switch accounts and where to reset.

Do not mix demo leaderboards with real promotions. If you need a contest, use a separate participation flag.

Technical debt: two ledgers

Demo and real entries in one table with an account_type field are easier to maintain than two almost identical schemas. Operation ids are globally unique. Admin reports always filter by type. Run accrual tests on both account types.

During script version migration, check that demo reset does not touch real promo flags, and vice versa.

Demo and marketing

Mark demo-profit screenshots in ads as demo if channel policy requires it. Inside the product, a "DEMO" watermark on the chart is optional, but a header badge is mandatory. A landing page can promise a "training account"; the account area should repeat that wording.

Referral bonuses for demo registration without deposit are easy to abuse, so track conversion to real separately. Support gets a macro for distinguishing demo from real.

Technically block the withdrawal API method for demo account_type on the backend, not only by hiding the button. Another client can call the API directly.

Demo acceptance criteria

Separate balance, reset, badge, backend withdrawal ban, live feed, training trade in history, CTA to real, and KYC not blocking demo. Attach a walkthrough video to delivery. Related manuals: account area, terminal, deposit.

Operational rhythm for demo

Watch resets per user and abnormal frequency: contest abuse is possible. Conversion to real after N demo trades is a product metric, not only a marketing metric. If conversion is zero with real traffic, check CTA and payment sandbox/prod flags, not only creative.

Once per release, run an automated test: create user, trade, reset, attempt withdraw API -> 403. It is cheaper than manual testing once every six months when the pain is already visible.

When demo balance reaches zero after a series of trades, show a clear empty state with a reset button, not just disabled direction buttons. This reduces the feeling that the terminal is broken.

Demo in a multi-product setup

If one account area has both BO and Forex, demo accounts are product-specific: demo options must not spend demo Forex margin and vice versa. Put the product switcher near the demo/real switcher. Confusing two axes is a source of the angriest tickets. At the start of one product, hide the second axis; do not draw gray placeholders.

Limit demo assets to those actually covered by the feed. An empty chart during demo onboarding kills conversion more than strict KYC for withdrawal. Before promotion, run the top five demo assets as a new user.

Do not forget the post-registration email: where demo is, where reset is, and where the path to real starts. One email reduces the first wave of repeated chat questions. The email text belongs to the white-label brand and should not contain default template logos.