From demo to payment infrastructure

Included

Merchant payment sections and the original player widget share local browser storage on the same origin. Deposits create one credit and a separate sweep record. Sweeps move funds to merchant hot wallets without crediting the player again. The Gaming demo forwards withdrawal requests to a simulated merchant adapter. Only a simulated merchant authorization produces a gateway payout; no player game-balance copy is used. Each network has two merchant wallet roles: hot and gas funding. The demonstrated four-address arrangement is not a mandatory production policy. Demo references are unique per seeded player and network, but are not real blockchain addresses.

Demo wallet roles

Configure one gas-funding address and one merchant hot-wallet address for TRON, and the same two roles for Solana. Deposits sweep directly to the corresponding hot wallet; withdrawals use its balance. The Players section shows payment activity by opaque merchant Player ID, without player profiles. Existing demo collection and hot balances are merged during migration. Editing an address changes future demo routing only and does not transfer real balances or verify ownership.

Sweep timing

Sweep schedules are set per network, from every 10 seconds up to every 7 days, with Sweep now always available. Sweep now runs queued sweeps immediately. Credit never waits for a sweep. A sweep threshold is a separate setting; threshold units and timer interaction remain to be defined. A scheduled interval is not a settlement guarantee. The browser demo catches up one batch when reopened; production requires durable scheduled jobs, per-wallet concurrency locks, confirmed deposit idempotency and fee/signing checks.

Wallet change requests

Merchants submit a network, wallet role, proposed address and reason after simulated re-verification. No address changes on submission. A separate Provider (demo) role can approve and apply or reject a pending request, with a review note and audit event. Provider review is an inherited demo workflow, not an agreed production policy. Merchant keys, address ownership and recovery remain merchant controlled. Production address-change authorization must be defined. The demo role selector is not an access control.

Demo access

The dashboard uses username demo and password demo (admin is also accepted as a username). This is a frontend demonstration screen with a tab-local session, not real authentication. The hosted demo is accessible without a ChatGPT account. Never use this access mechanism for live merchant funds.

Try the connected workflow

Open Checkout Widget and choose a color design. Slide to record a 100-token demo deposit, then view Deposits, Players and Sweep History. In the Gaming withdrawal tab, enter an amount and use Demo address. The request is automatically forwarded to the simulated merchant adapter. After simulated merchant authorization, the gateway automatically pays if its hot wallet and fee funding are sufficient. Funding holds retry while a page is open; there is no manual Gaming payout approval button.

What needs a secure backend

Use authenticated player and merchant accounts, server-side merchant ownership and role checks, and password re-verification or real two-factor challenges before changing policy. Enforce rate limits and session expiry. Store no private keys, real passwords, or 2FA secrets in the frontend. The demo role selector and verification phrase provide no security.

Use a transactional, append-only financial ledger with integer token precision, balance reservations, idempotency keys, database constraints, and concurrency control. Browser local storage is editable, can be cleared, and is not safe for financial accounting or concurrent writers. Transactions do not synchronize between browsers or devices.

Deposit and sweep services

Generate controlled, chain-specific addresses or token accounts with a custody provider or secure signer. Map each to a merchant and player. Monitor approved token identifiers, confirmation/finality policy and reorganization behavior. Deduplicate by chain transaction and transfer/event identity. A confirmed deposit records one payment event; the merchant integration applies any player-account credit in the merchant system. A separate retryable sweep job coordinates fees and signing, then moves tokens to the merchant merchant hot wallet. Failed sweeps never reverse a valid deposit or duplicate a merchant payment notification.

Design Solana and TRON fee handling separately. This demo uses illustrative per-operation fee debits; it does not implement a gas-paying contract, on-chain fee sponsorship, resource delegation, or address creation. The native fee/resource owner stays separate from token collection and payout wallets. Validate the desired gas contract model against each chain before implementation.

Automatic TRX funding for TRON deposit addresses

Receiving USDT does not activate a TRON address. The gateway tops up each unique TRON deposit address with TRX from the merchant’s funding wallet; receiving TRX activates the address, and a reserve stays there for later outgoing transfers, which consume Bandwidth and Energy. Activation and having enough resources are separate states, and both are separate from deposit confirmation. Top-ups are operational funding: never a player deposit, bonus or service-fee event. Production needs bounded amounts and daily limits, top-ups only to gateway-generated addresses of that merchant, one pending top-up per address with idempotency keys, and merchant authorization of the funding policy. TRX is sent only after an address receives its first deposit, at most $10 worth per top-up; the console uses a demo TRX price.

Payment pairs and BSC

USDT on TRON (minimum 10 USDT) and USDC on Solana (minimum 1 USDC) are configured for deposits and payouts. USDT and USDC on BSC are the Binance-Peg BEP-20 tokens (18 decimals) with deposits by address/QR or connected wallet and withdrawals. Deposit minimums are 10 USDT on TRON and 1 on every other chain; each merchant sets its own withdrawal minimums above the platform floor. Every token and network keeps its own wallet balance, service credit and gas funding (TRX, SOL or BNB). Token decimals belong to each contract.

Prepaid service fee

XpayZ charges the merchant 1% on deposits only, from prepaid service credit. A 100-unit deposit credits the player 100 units and charges 1 unit to service credit. There is no on-chain split; network costs, sweeps and payouts carry no second 1% fee. The console shows simulated charges; real billing is planned for production.

Automatic merchant-authorized player payouts

The merchant owns player profiles, game balances and withdrawal eligibility. The gateway records the opaque Player ID and payment details: request ID, amount, asset/network, destination required for the transfer, status, timestamps, authorization reference and transaction hash. Payment records require durable storage; a merchant player database is not imported.

On a player withdrawal request, deliver an authenticated notification to the merchant backend. The merchant verifies the player and its own balance and rules, then returns an authenticated payout instruction linked to the exact request. Only that instruction authorizes gateway processing. Verify signatures or equivalent server authentication, merchant ownership, amount, destination, asset/network, authorization freshness and payload-bound idempotency. Never trust a browser or a player-provided approval flag.

Process accepted instructions automatically, subject to gateway liquidity, fee funding, destination/network checks, signing policy and confirmed chain results. Deduplicate both player requests and merchant instructions. Funding holds may retry automatically without creating another payout. Reconcile ambiguous broadcasts before retrying. Merchant declines never create a transfer. The Gaming merchant adapter in this package simulates this handoff; no real endpoint, authorization signature, blockchain signer or live payment is connected. Other industry prototypes retain their existing demo-only threshold screens.

Audit and synchronization

Write tamper-resistant audit events containing merchant, administrator, old/new limit, policy version, UTC time, verification method and result, and request/session metadata. Never log credentials or codes. Use server events or authenticated polling to update both interfaces. Reconcile chain balances against ledger and custody records, monitor low fee/hot-wallet balances, and alert on failed jobs.

Hosting this demo

Upload this folder’s contents to public_html/XYX/ and open index.html. Keep player.html, ledger.js, dashboard files, and xz-pay-widget/ together on the same origin. HTTPS is recommended. The unchanged original widget remains accessible at original-widget/index.html. Nothing in this package needs real wallet keys or RPC credentials.