Switching Payment Provider With Active Subscriptions Without Losing Revenue

Switching payment provider in a business with no subscriptions is a configuration change. In a business with live subscribers it is a project, because the tokens holding your customers' cards were created at the old provider and are usually not portable. The plan is written around that question, not around the target date.

The three migration routes, by what is possible

The third route is the forgotten one, and usually the cheapest. If your subscriptions renew annually, a gradual transition spreads the pain across a year instead of concentrating it into a week.

What to do, in what order

1. Establish what the agreement says - commitment period, notice, exit cost. Before anything else.
2. Ask the new provider whether token migration from your current provider exists, and who performs it.
3. Export everything while still active: subscriber list, amounts, frequency, charge dates, last four digits and expiry, charge history, and reports going back years.
4. Open the new account and run small real transactions - a charge, a refund, and an instalment charge - before touching subscriptions.
5. Move new traffic first. Every new customer goes to the new provider; existing ones do not move yet.
6. Reconcile a full month with both providers running and confirm reports and invoices are correct.
7. Only then begin the existing-subscriber route - migration, re-enrolment or gradual transition.
8. Close the old account after confirming there are no open charges, refunds in flight or disputes in progress.

The order matters more than the speed. A business that starts at step 7 discovers at step 4 that something does not work, with nothing left to fall back on.

What exactly to export, and why it must happen before you give notice?

The export is your insurance, and it is only possible while you are an active customer. These are the fields you need, not just "a customer list":

• The provider's customer identifier and your internal one, so you can cross-reference.
• Name, phone and email - at least one must be correct, because that is how you will ask for an update.
• Amount, frequency, currency and next charge date.
• Last four digits and card expiry. Without those you cannot write an update request the customer will recognise - as explained in what a payment token is.
• Subscription state: active, paused, cancelled, failing.
• Full charge history, including failures and refunds.
• Monthly reconciliation reports for the whole period you are required to retain.

The reason this precedes giving notice is simple: an export request from an active customer is a service request, and the same request from a customer who has announced they are leaving is one nobody is obliged to rush. The full list of what to require in the agreement up front is in Israeli payment gateways compared.

What actually goes wrong

• Double charging. Both providers run the same subscription in the same month. Prevented by explicitly switching off the old side before enabling the new one - and not on the same day.
• A month with no collection. The old one is off and the new one is not running yet. That is the result of a single-date cutover with no parallel run.
• Invoices from two sources. If both providers issue documents, numbering splits and reconciliation breaks.
• Disputes arriving after closure. A transaction from two months ago can reverse after you closed the account, leaving nothing to offset against.
• Quiet churn during re-enrolment. Customers who do not update never announce they left. They simply disappear from the report.

The fourth item is why you do not close the old account immediately. Leave it open and funded until the window in which transactions can still reverse has passed.

How to run a re-enrolment campaign

If there is no token migration, you are asking customers to take an action - which is the definition of a campaign:

• State what happens if they do not update, and when. Without a date there is no urgency.
• Send a direct link to the update page, not instructions. Every extra step lowers response.
• Mention the last four digits of the existing card so the customer recognises what this is about.
• Track daily who has updated, and follow up only with those who have not.
• Some customers will need a phone call. Plan for it rather than being surprised by it.
• Make sure the update attaches the new token to the same subscription rather than opening a second one.

And importantly: do not contact everyone on the same day. A small first group exposes faults in the update page before your whole customer base hits them.

Who needs to be in the room

Provider migrations usually fail not because of technology but because somebody was not told. Four roles need to know from day one:

• Whoever reconciles the money. During the parallel month there will be two reports, and they need to know that is deliberate rather than a fault.
• Whoever answers customers. If a customer calls about a card-update message, the answer must be ready - otherwise the team says "I do not know", and the customer does not update.
• Whoever maintains the site or store. Swapping a payment plugin is a production change, and the checkout page usually needs testing on mobile too.
• The accountant. They will receive documents from two sources in the same month, and should know in advance.

The second item is what sinks re-enrolment campaigns: a good message sent to an unprepared team produces calls that end without an update.

Sources

• PayPlus - standing order management system
• Cardcom - payment solutions
• Shva - the Israeli card clearing infrastructure