BryanNetPayment status and gateway callbacks
Prerequisites and authority
Use the official organization interface. Customer procedures need account ownership; provider configuration and manual grants need authorized operator access.
Interpret payment status and callbacks
Follow the complete chain: provider transaction → stored payment → linked subscription → provisioning → usable router access. Each stage has its own result.
| Observation | Interpretation/action |
|---|---|
| Checkout opened | Payment initiated, not paid |
| Browser says success | Confirm server/provider verification |
| Stored payment successful | Inspect linked subscription |
| Subscription queued | Existing active plan may take precedence |
| Subscription active, provisioning failed | Repair access without losing payment |
| Telegram message missing | Inspect notification delivery separately |
Provider callbacks can arrive after the browser return and can be retried. BryanNet must reconcile the same transaction without creating duplicate paid access. The inspected payment model has unique reference/transaction fields, but uniqueness alone is not proof of full idempotency under concurrent events.
Bachs payment details and crypto
Provider identifies Bachs, Paystack or Flutterwave; Origin identifies the BryanNet client (web, mobile or Telegram). Channel describes the payment rail, such as Bank Transfer, Card or Crypto. Method preserves the provider's method name, such as NGN_BANK_TRANSFER or CRYPTO. A checkout that expires or is cancelled before collection can legitimately have no channel/method.
Bachs reports the collection method on the linked charge. Its channel: api describes the provider-side origin, not the bank/card/crypto rail. Checkout and charge identifiers are separate; a provider transaction ID identifies the collected charge, not another BryanNet payment reference.
A crypto charge's amount/currency describes the asset and network, for example USDT_TRC20. The checkout price remains the plan's naira amount. BryanNet verifies the checkout price/reference and full linked crypto payment separately; it does not derive a naira price from a settlement balance. Underpayment, missing payment evidence, unsupported assets and mismatched links do not establish success.
Gateway events and recovery
All three online providers use a durable webhook inbox. A verified delivery can be acknowledged before payment processing completes; acknowledgement is not proof that the subscription is already active. Payment-worker recovery processes recorded events and retries recoverable failures. Inspect linked gateway events and worker operations alongside the charge result.
Historical failure notifications remain after recovery. Check recent worker runs and the current payment before treating an old alert as an active outage. A successful payment with a router timeout is an access/provisioning problem, not permission to charge the customer again.
When reporting a problem, provide the reference, approximate time and visible state. Do not send card details, provider secret keys or one-time codes.
Operators should compare the provider's actual payment result with the stored transaction before any manual adjustment. Keep economic history intact and record the corrective action. Two distinct successful provider references may represent two payments; one reference repeated in callbacks represents a delivery/reconciliation problem.
Use Payment succeeded but internet did not activate for success without activation and Payment duplicated, stale or webhook never processed for duplicate/stale records.
Related guides
Related guides: Purchase a plan and understand activation, Credentials, devices and concurrent logins, Telegram customer onboarding and commands, Website registration account linking and recovery, Payment succeeded but internet did not activate.