A tokenized payment method stores a provider reference that WHMCS can use for authorised future payments. The exact data flow depends on the gateway, so confirm how the selected integration collects, updates and removes payment details.
IN THIS ARTICLE
01 Plan the payment-method change
- Inventory the active gateways and determine which store data locally, which use provider tokens and which redirect customers to the provider.
- Choose a supported tokenized gateway and configure it using its documented authentication and customer-input flow.
- Test adding a payment method, paying an invoice, setting a default and updating details through the client area.
- Review existing unpaid invoices and their assigned gateway. Changing a customer's default payment method does not automatically change those invoice gateway assignments.
- Explain to customers how to update their payment method securely through Billing and Payment Methods.
Does activating a tokenised gateway migrate existing payment data?
Enabling a tokenization gateway does not automatically delete existing locally stored payment data. Some gateways support conversion during a later payment, while others require customers to add details again. Follow the documented migration procedure for the specific source and destination gateways.
If the business intends to prevent new local storage, review the visibility of non-tokenized gateways and administrative workflows as well. Existing tokens may remain tied to the old gateway or merchant account, so do not delete that integration before resolving its active customers.
02 Verify recurring collection
Use a controlled test customer to confirm which saved method is selected for a recurring invoice. If the default payment method is not valid for the invoice's gateway, WHMCS uses the client's first applicable payment method instead. Inspect the invoice gateway and its compatible saved methods before a capture attempt, and verify which method the controlled test actually uses.
Keep card numbers, security codes and bank details out of tickets, notes and diagnostic attachments. Any deliberate removal of stored data requires an approved migration and retention decision, because deleting it can break future collection. Retain only the operational evidence needed to confirm that the replacement flow works.