Payment gateway sandbox verification

Prerequisites and authority

Local installation authority, a complete approved release package, working Docker and access to the deployment record are required. Preserve existing data before installation/update/removal.

Test payments before live sales

Use the provider's test credentials and designated sandbox methods. Confirm that the selected organization enables plan sales and payments, and that the customer interface is entitled.

1. Configure one supported provider in test mode using Configure supported payment providers and webhooks.
2. Check the stable public callback address from outside the LAN.
3. Register a dedicated test customer and choose a published test plan.
4. Initiate checkout once and record its reference.
5. Complete the provider test payment and return to BryanNet.
6. Verify provider success, stored payment, linked subscription and provisioning independently.
7. Confirm actual hotspot access and notification behavior.
8. Test cancellation, failure and a delayed/duplicate provider event in the test environment.

The customer's browser return is not sufficient proof of payment. Server-side verification and callback processing must establish the economic result. A successful callback must not grant two subscriptions when it is retried.

Bachs acceptance checks

Use Sandbox credentials and the matching merchant organization ID and signing secret. Run the saved-credential test, then test an actual checkout separately. Record the BryanNet reference, Bachs checkout/charge identifiers, provider outcome and stored payment channel/method without recording secret keys or payer account details.

• Test enabled bank transfer and card methods separately. Verify a completed charge, stored successful payment, linked subscription and router provisioning.
• For crypto, record the plan's naira checkout amount and the charge's asset/network amount separately. Confirm the original checkout amount/currency/reference match, the charge belongs to that checkout and the charge is fully paid with zero remaining. Confirm Crypto / CRYPTO appears in payment details.
• Test cancellation, expiry, delayed webhook delivery and duplicate delivery. A duplicate event or repeated verification must not grant another subscription.
• Check website overlay return and reopening a pending checkout. Test Telegram purchase/check-payment and mobile external-browser return independently; website results do not certify these channels.
• Verify payment-worker inbox recovery after a restart and distinguish financial completion from a router connection failure. Preserve a successful payment while recovering access.

Observed locally on 10 October 2026: sandbox bank-transfer verification and a completed USDT_TRC20 charge against a NGN-priced checkout. Automated verification tests passed. This does not certify live settlement, all supported crypto assets, real webhook delivery or physical-device return behavior; complete and retain those acceptance records before release approval.

When the test customer already has an active subscription, the purchase should queue. That is different from a provisioning failure. Confirm validity begins when the ordinary queued purchase activates.

Record results before enabling live credentials. Then verify the live configuration and required callback settings without publishing secrets. Keep payment records even when provisioning needs repair. Use Payment succeeded but internet did not activate and Payment duplicated, stale or webhook never processed for failure investigation.

Related guides

Related guides: First-deployment walkthrough and success checklist, Deployment verification and first login, Back up BryanNet and validate backups, Restore BryanNet safely, Product updates, compatibility and rollback.