WHMCS Payment Mandates: Check Before You Migrate

A WHMCS customer export is not a transferable payment mandate. Before migrating recurring billing, identify the provider account, saved payment reference and authorization used by each service. Then confirm whether the destination can use that arrangement or the customer needs a new authorization. Invoice data and permission to collect are different records.

This guide helps hosting providers plan that decision. It does not provide a token-copy script or promise automatic payment-method portability. The original readiness worksheet below can be completed without collecting raw card details. For the wider move, start with the WHMCS migration checklist.

What does a WHMCS saved payment method represent?

A saved payment reference identifies a relationship in a particular gateway and provider account. Its meaning depends on the module. It might refer to a customer, a stored payment method or an external recurring agreement. The label alone does not tell you whether the new platform may collect.

The official WHMCS Stripe module documentation describes tokenized storage and module-specific references. Review the module your installation actually uses. A Stripe customer identifier is not a full subscription schedule, and a schedule does not by itself identify a usable card.

Some gateways create recurring agreements outside WHMCS. The separate WHMCS subscription management documentation describes gateway cancellation hooks for those arrangements. That is a different mechanism from an application deciding when to generate an invoice and request payment.

Write down the actual gateway name and version, provider account and collection owner. Ask who initiates each renewal: WHMCS, the provider's subscription system or another integration. Without that answer, it is easy to disable one schedule while an independent agreement keeps charging.

Treat the initial inventory as evidence gathering. Do not change live references while identifying them. A stable snapshot lets the billing team compare the old arrangement with the intended destination and identify accounts that need special handling before the next renewal.

Separate customer data, authorization and renewal schedules

Customer details help you match identity. Authorization establishes an eligible way to collect. The schedule determines when and how much to bill. Keep these as three separate checks, even when the old interface displays them on one page.

Download the payment readiness CSV. The English template records verification outcomes and fictional references. It is a planning worksheet, not a provider mandate import file. Do not put card numbers, security codes, passwords or API secrets in it.

For a fictional Customer A, all contact details may transfer correctly while the payment mapping remains unconfirmed. That customer is not ready for automatic collection. Marking the record “imported” should not collapse all three checks into a single green status.

For Customer B, the payment arrangement might be confirmed but the next period already paid. Correct authorization does not justify charging again. Combine this worksheet with the renewal handover record before activation.

Check whether you are changing the payment provider

Moving to a new billing interface and moving to a new payment provider are different projects. Staying with the same provider may reduce some work, but it does not establish that two integrations can use the same customer and payment references.

If the provider account stays the same, ask the destination integration which reference types it accepts, how ownership is verified and what setup is required. Confirm this with a small authorized test group. Do not substitute a familiar account name for actual support of the collection route.

If the provider changes, ask both providers about the supported migration process. Mollie's card mandate import guidance describes a coordinated provider transfer and mapping to new references. It explicitly separates card information migration from subscription logic. That distinction is central to planning the billing move.

Mollie's card process is not a universal method for every payment type. Its documentation distinguishes card migration from SEPA and PayPal mandate routes. Plan around your actual method, account and integration, rather than treating every saved payment row as interchangeable.

Keep provider coordination separate from a promise about the customer experience. Until the destination mapping and first collection route are verified, the honest status is “being checked.” A migration date should reflect readiness, not a blanket assumption that all saved methods transfer.

Decide when customer reauthorization is the clearer route

When an existing arrangement cannot be confirmed as usable, plan a new customer authorization rather than attempting an unsupported reference copy. Tell the customer what action is needed, what service it covers and when future collection will begin.

Reauthorization should not ask the customer to email card details. Direct them through the configured secure payment method flow. Staff should not gather a card number or security code in a support ticket to work around an incomplete integration.

Use different messages for confirmed and unconfirmed accounts. A customer whose payment mapping is ready should not receive an unnecessary request to add another card. A customer whose mapping is not ready should not receive a reassuring “no action required” message merely because their email address imported successfully.

A reusable message is: “Billing for [service] will move to [portal] from [period]. We need you to authorize the payment method through [verified setup link] before [date]. Your existing paid coverage ends on [date]. We will confirm the next scheduled amount before starting the new collection.”

Replace every field with the actual record and use the verified destination URL. Review who can answer customer questions and how incomplete authorization is handled. Repeated reminder emails cannot make an unsupported payment arrangement eligible.

Understand PayRequest automatic and manual subscription billing

PayRequest's subscription payment documentation describes automatic collection using an assigned valid mandate and manual recurring invoicing. The documented mandate workflow uses Mollie. Do not read the presence of a Stripe connection elsewhere as proof that any WHMCS Stripe reference can be assigned to this flow.

Review the payment method shown on the actual subscription. Confirm customer ownership and eligible mandate status through the supported interface. A familiar reference copied into an unrelated field does not prove a collection route works or that the customer authorized it.

Manual recurring invoicing can serve customers who pay by bank transfer, when the product and setup permit it. It gives the customer a payable invoice rather than automatically collecting. This changes the operational work: someone must monitor the invoice and payment result before treating the balance as settled.

Choose the method deliberately. Manual billing should not be an invisible fallback after a promised automatic collection fails. Tell customers whether money will be collected or they need to pay the invoice, and keep that instruction consistent with the portal state.

The customer portal is part of the experience, but the portal alone is not payment authorization. Use the portal demo to evaluate customer tasks while the payment mapping is reviewed separately.

Test the reference mapping before the first live renewal

Prepare a short verification record for each pilot account. It should name the old service reference, destination customer, next period, payment mode and person who checked it. Record observations and outcomes without collecting sensitive payment details.

For an automatic route, confirm the eligible payment arrangement and the amount due before an authorized collection check. Observe the actual provider result and the invoice state. A subscription displayed as active is not a substitute for verifying the relevant payment.

For a manual route, check the invoice instructions and how payment is reconciled. The absence of a mandate may be intentional. The question is whether the selected workflow matches the product configuration and the promise made to the customer.

Also verify that the old collection owner cannot bill the same period. A correct destination payment method can make duplicate collection easier if the old gateway still acts independently. Read the double-billing migration guide before reactivating any old job after a failed check.

Use a go-live condition based on evidence: supported reference, correct customer, correct amount and date, one collection owner and a reviewed result. “All rows imported” is a data milestone. It is not the complete payment acceptance test.

Handle incomplete payment readiness without losing control

Keep unconfirmed accounts in a separate group. Assign each an action: provider confirmation, customer reauthorization, an explicitly agreed manual invoice route or a postponed handover. Avoid activating the whole group and hoping failed payments identify the exceptions later.

For time-sensitive renewals, keep the old arrangement responsible only while it is still the agreed billing owner. Document the revised handover date. If the new system has already made an attempt, check the result before letting the old system collect again.

Preserve historical payment records and support notes. A provider mapping is useful for matching references, but customers may still ask about an old refund, invoice or statement description. Give staff a way to trace those questions without keeping unnecessary credential copies.

Bring the completed readiness worksheet to the WHMCS migration assessment. Describe your provider, methods and service automation. This gives the team a concrete setup to review rather than a request to “move all subscriptions” without defining what that includes.

PayRequest Business costs €20/month and includes the customer portal and recurring billing. Standard platform payment fees are 0% while the paid plan is active. Provider processing fees apply separately; commission payments retain their separate fee. Complete account setup and activate Business at checkout. Selecting Business during signup does not itself grant paid access. Check current pricing before choosing your setup.

Editorial note: AI assisted with this article and its illustrative cover. Official documentation was reviewed on 7 October 2026. Worksheets and customer messages are original planning templates. All examples are fictional; no live charge, customer migration or hosting termination was performed for this article.