Conditional payment methods and verification¶
Payment methods depend on the saved checkout, its currency, current administrator authority, configuration and provider support. A method being listed, a payment request being acknowledged, a bank result being verified and subscription coverage being applied are separate milestones.
Draft availability: the current App and Tenant Admin checkout views present hosted payment. The codebase also contains native method-selection and verification services, but their complete in-app forms and matching design journeys have not been verified. This page explains those conditional backend capabilities; use the Billing task guide for the inspected screen journey.
Which methods may be available¶
For an eligible saved subscription checkout, the payment service can offer the following manual methods. They require explicit configuration and current provider support; this table is not a promise that a particular environment offers them.
| Method | Supported currency | Additional condition |
|---|---|---|
| Bank transfer | NGN or GHS | The currency is explicitly enabled and the provider can prepare the matching temporary account |
| Pay with bank account | NGN | The bank-account integration and currency are enabled |
| OPay | NGN | Its separate integration and currency are enabled |
| USSD | NGN | The service can retrieve a current, supported bank list; the request retains the selected bank |
| Mobile money | GHS | The implemented selection is Ghana MTN, with the matching country, network and payment phone details |
These are currency and integration conditions, not a statement that every bank, wallet or customer in a country can participate. The final saved amount, tax and currency remain authoritative. Do not calculate a different amount from a sample price or change the checkout's currency to make a method appear.
Card verification has a separate implemented path for an existing owned card attempt. The native manual-method list does not offer a new card-start channel. A backend card service or an available verification contract does not establish a delivered card-entry form. Current subscription card acceptance and renewal consent are explained in saved payment methods.
What an available-method list means¶
Availability is a current observation for one checkout. A later submission checks ownership, configuration and saved payment state again. An earlier list cannot authorize a changed method or a new charge.
An empty native list can accompany a hosted checkout, disabled native configuration, missing checkout prerequisites or an already unresolved payment. It does not prove that no payment exists or that every payment option is unavailable. Retain the original reference and check its current result before creating another request.
Initial workspace payment and ordinary workspace Billing have different entry boundaries. An initial checkout must belong to an eligible current administrator; an ordinary Billing action uses the selected workspace and its current authority. A workspace name, finance title or copied payment reference does not grant either form of access. See billing access and workspace creation.
Starting a request does not confirm payment¶
The backend retains the original workspace, checkout, operation, method and saved commercial terms. Repeating an operation cannot silently replace its method or selected details. A different operation cannot bypass an earlier unresolved payment.
A successful start acknowledgement means that the request has reached its checking stage. The provider may still need to prepare a method, confirm a transfer, request bank verification or report its final result. A lost response can leave work in progress. Preserve the existing operation and ask support to reconcile it instead of using a new request as a test.
Disabling a method can stop new requests while an already dispatched operation still requires investigation. Recovery of that original operation is different from permission to start another one. It is not a promise that every disabled integration can still supply all the evidence needed for recovery.
Read the current payment state¶
| State | Meaning and recovery boundary |
|---|---|
| Not started | The current view has no corresponding native payment record; an old page is insufficient evidence that a recent submission did nothing |
| Checking | Processing, provider observation or fulfillment is unfinished; keep the original reference |
| Payment required | Current verified instructions may be available for the original payment; inspect their amount, currency, reference and expiry |
| Verification required | The existing charge needs its current bank action, such as a code, PIN, address confirmation or provider redirect; this is not a new purchase |
| Succeeded | Current records show matching completed checkout, payment and invoice evidence; workspace readiness, coverage and personal access still have their own checks |
| Failed | A failed or voided attempt is recorded; controlled replacement still needs its own reconciliation and authority |
| Expired | Payment instructions can have expired without proving that no money moved or that a replacement is safe |
| Review required | Saved or provider evidence does not establish a usable next action; ask authorized support to reconcile the original payment |
| Unavailable | Current status could not be established; do not interpret this as a confirmed decline |
A provider reporting success does not by itself complete the platform’s payment records. Independent verification, fulfillment and application can arrive separately. Refreshing status is not an instruction to collect payment again. See payment acceptance and coverage.
Temporary bank instructions and bank verification¶
Bank-transfer instructions belong to a particular saved operation and include a bank, account, reference, amount, currency and expiry. Use current verified information rather than an old copy. The requested lifetime and the provider's recorded expiry must be checked; this page does not promise a universal payment window.
An expired instruction, a locally expired checkout and confirmed payment failure describe different conditions. A transfer can still require reconciliation after an instruction expires. Automatic recovery receives an hourly signal. This does not promise an exact refresh or completion time.
Bank verification also belongs to an existing charge. A different prompt, changed charge or stale response must be checked against current status. A rejected code or PIN does not authorize an unrelated second charge. Provider redirects and payment instructions have different meanings from verification fields and may be unavailable in the current frontend.
Keep PINs, one-time codes, full card credentials and private address/payment instructions out of support messages. Support normally needs the workspace, original checkout and operation references, observed state and approximate time through the approved channel.
Manual payment and automatic renewal remain separate¶
A manual payment does not create a newly saved automatic-debit method. It also is not a request to revoke any earlier saved consent. Check current renewal consent and removal separately when deciding whether automatic charging should continue.
Payment acceptance does not remove an administrative or support pause, grant missing product permissions or certify that initial workspace provisioning has finished. Use subscription access, the Billing guide and the original saved request to establish the outcome that matters.