GALApay Test Environment Guide Updated: 2026-10-27 (Beijing time, UTC+08:00) Test portals Platform: https://test-admin.galapayglobal.com/ Merchant: https://test-merchant.galapayglobal.com/ Guide: /api/integration-doc?lang=en Isolation and accounts This environment shares the host with production but uses a separate process, database, accounts and encryption key. Never enter production passwords, authenticators, API secrets or real customer/payment information. Platform username: admin. Merchant primary username: testmerchant. Their initial passwords are different and delivered privately. Change the password and enroll a NEW test authenticator at first sign-in. Repeated failures can lock the test login IP; stop retrying and ask maintenance to inspect the test lock. Synthetic data and checks Initial fixtures contain one TEST-MERCHANT, site TEST-001 (internal ID TEST-SITE), 225 collection orders, 225 payout orders and 225 ledger entries. Counts can change through test operations. Verify menus, navigation, dialogs, filtering, pagination, page sizes, horizontal scrolling and 11 supported interface languages. Viewing and exporting are separate permissions. Subaccounts must remain scoped to their own synthetic merchant. New requests and historical downloads must enforce current permissions after revocation. Sensitive export fields must be masked without the corresponding permission, while order numbers remain exportable. Never upload real customer data. API and notification restrictions There is NO enabled test payment gateway. /open/v1/ is closed to both real and simulated payment API submissions. Do not configure these test domains in production integrations. Real payment workers, upstream collection, callback delivery, Telegram bots and group notifications are disabled. The test process cannot access the external network; application settings cannot override this OS restriction. GET /api/health is a public read-only check returning environment=staging, payments=disabled and notifications=disabled. Other console endpoints retain authentication, role checks and CSRF protection. Use separately supplied production documentation for the production protocol; this guide provides no live API credentials. Suggested acceptance flow 1. Confirm the test- domain and TEST ONLY banner. 2. Complete first-login security setup with the appropriate test account. 3. Check menu expansion, navigation, language switching and dialogs. 4. Verify order filters, multiple pages, page sizes and exports using synthetic data. 5. Use isolated subaccounts to verify view/export/sensitive permissions and immediate revocation. 6. Record reproducible issues, complete acceptance and arrange production deployment separately. Boundaries All writes affect only the synthetic database. Never restore it into production. Do not attempt real deposits, transfers, payouts, callback replays or group test messages. Testing UI behavior does not verify real upstream payments or notification delivery. Test code is not automatically synchronized to production.