Flirexa / Guides / Payment providers

Commercial operations

Choose a payment provider that accepts your actual VPN business

A provider appearing in a settings screen does not guarantee that it will approve every business, country, currency, or payment method. Start with eligibility, then build checkout around verified settlement.

Before integration

Provider approval is part of the product design

Describe the business accurately

Give the provider your real website, terms, support channel, billing model, expected countries, currencies, and refund or dispute process. Do not hide the VPN use case to obtain methods the account is not permitted to use.

Confirm methods by account

Card, wallet, bank, Alipay, WeChat Pay, and local methods depend on provider, account country, customer location, currency, and activation status. Enable only methods the API confirms are available.

Keep a second path

A second eligible provider or cryptocurrency option can reduce lost orders during an outage or regional restriction, but it also adds reconciliation and support work.

Payment authority

A browser success page is not proof of payment

A customer can close a tab, reload a return URL, lose connectivity, or arrive at a success path without settlement. The server must treat the payment provider as the authority.

CreateCreate an order with a unique internal reference, exact amount, currency, selected plan, and customer identity
RedirectSend the customer to the provider or present the approved method without granting access
VerifyAuthenticate the webhook or query the provider API and confirm settled state, amount, currency, and order mapping
Apply onceUse idempotency so repeated callbacks cannot add the subscription or balance twice
ReconcileRetry pending orders in the background and alert the operator only when intervention is meaningful

Checkout experience

Reduce decisions without hiding important state

Use the preferred method directly

If an operator configures one active payment path for a plan, the customer can move directly into it. Show a chooser only when multiple working options are available.

Remove unavailable methods

Do not send a method that the provider account has disabled. Fall back to a normal card checkout or another configured provider instead of exposing the provider's raw API error.

Keep errors actionable

Tell the customer whether to retry, choose another method, wait for confirmation, or contact support. Keep internal request identifiers in operator logs rather than turning them into the main message.

Test the return domain

Success and cancellation URLs must point to the operator's real HTTPS portal, not an example domain. Test them from a clean browser and a mobile device.

Production checklist

Test more than the happy path

  • a successful payment activates the exact purchased plan once
  • a rejected, cancelled, underpaid, expired, or pending order does not activate access
  • a duplicate webhook produces no duplicate credit or subscription time
  • a temporary provider outage leaves an order recoverable
  • currency and decimal prices remain exact from plan table to checkout and receipt
  • support can identify the order without asking for payment credentials
SecretsStore provider credentials outside Git and never expose secret keys in frontend code
LogsRecord provider status and internal references without copying full sensitive payloads
AccessLimit payment configuration and manual adjustments to authorized administrators
RecoveryBack up order and entitlement state so restoration does not lose paid access

Common questions

Payment integration decisions

Does Flirexa guarantee approval by a listed provider?

No. Flirexa provides integrations and operational controls. The provider independently decides business eligibility, countries, currencies, methods, reserves, and account status.

Should every available method appear to every customer?

No. Present methods that are active for the operator account and valid for the current transaction. A shorter working list converts better than a long list that fails after selection.

Can cryptocurrency be the fallback?

It can be one fallback where lawful and appropriate for the operator. The same rules still apply: unique order references, provider-confirmed settlement, amount checks, idempotency, and supportable reconciliation.