Changing payment gateway is one of the riskiest changes a product team can make, because every mistake is measured in money. A broken page is an annoyance. A broken payment is a customer who could not top up, a subscription that silently stopped, or a wallet balance that no longer adds up. This is a case study of moving a UK telecom brand’s three products, a mobile service, a VOIP calling app with its own digital wallet, and calling cards, from Pay360 to Adyen in one month, with no payment downtime and no lost payments or balances.
The migration at a glance
| Company | A UK telecom brand selling across the UK, Europe and the United States |
| Scope | Three products: a mobile service, a calling app with a digital wallet, and calling cards |
| Move | Pay360 to Adyen |
| Approach | Gradual traffic split: a share of payments on Adyen first, increased step by step |
| Timeline | One month, against a 2 to 4 week figure quoted for a typical integration |
| Hardest parts | Saved cards, auto top-ups and recurring payments, 3-D Secure and fraud rules |
| My role | Product manager: owned the plan, the rollout, the risk and the customer experience |
| Result | Higher payment success rate, new payment methods live, no payment downtime, no lost payments or balances |
Why move from Pay360 to Adyen
There were three reasons, and they were all about growth rather than fixing something broken.
- Payment success rates. Every declined payment is a customer who wanted to pay and could not. Even a small lift in the share of payments that go through is revenue the business has already earned.
- More payment methods. Customers expect to pay the way they pay everywhere else. A gateway with a wider range of methods removes friction at the moment of purchase.
- Selling beyond the UK. The brand was serving customers across Europe and the United States. A gateway built for global payments (multiple currencies) fitted where the business was going, not just where it had been.
What was at stake
A payment gateway processes every sale a telecom product makes. For these three products that meant one-off top-ups, auto top-ups that customers rely on to keep their service running, calling card purchases, and a digital wallet holding customers’ own money inside the app.
Each carried a different kind of risk. A failed one-off payment loses a sale. A failed auto top-up can cut a customer off without them knowing why. A wallet that records a payment differently from the gateway leaves a balance that is wrong, and customers notice a wrong balance faster than almost anything else. And every new checkout step, such as an extra authentication screen, costs some customers who simply give up.
The “2 to 4 weeks” question
Near the end of an early meeting with our stakeholders and Adyen’s representatives, my boss asked a simple question: how long does it usually take a team to migrate to Adyen? Adyen’s technical representative was careful to say there is no hard and fast rule, but that it is usually 2 to 4 weeks.
The caveat did not stay in the room. The number did. From then on, 2 to 4 weeks was the figure my boss used, and the expectation was that we should be moving that fast too. As the product manager who owned the plan, that put the pressure on me.
The figure was not wrong. It just measured something smaller than our project. A typical estimate like that describes getting payments working on the new gateway for a typical merchant. We had three products, saved cards to move, auto top-ups that could not miss a payment, a digital wallet whose balances had to match the gateway exactly, and a rollout we wanted to take one step at a time. None of that is in a general number given at the end of a meeting.
We finished in one month: just past the top of that range, across three products, with nothing lost. The lesson I took from it is about how estimates travel. A vendor’s typical figure, said once with a caveat, becomes a deadline as soon as someone senior repeats it. The fix is to answer it early and plainly: say what the number covers, list what your project adds on top, and give your own estimate before the borrowed one sets the expectation for you.
Rolling out with a gradual traffic split
The most important decision was not to switch in one go. Instead, a small share of payments went through Adyen first while the rest stayed on Pay360. The team compared the two side by side: success rates, failures, declines and what customers experienced at checkout. Only when the numbers on Adyen were healthy did the share increase, step by step, until all payments ran through the new gateway.
This turned a single high-stakes cutover into a series of small, reversible steps. If a problem appeared, it appeared in a small share of payments, with the old gateway still running as the fallback. It is the same principle as phasing a domain migration, applied to money: limit how many customers a problem can reach, measure, then move on.
The three hard parts
Saved cards
Customers who had saved a card expected it to keep working. Where the stored card details could be migrated from Pay360 to Adyen behind the scenes, customers noticed nothing. Where they could not, customers had to add their card again the next time they paid. Because it was a mix of both, the product had to handle both paths well: no confusing errors, and a clear, quick way to re-add a card when it was needed.
Auto top-ups and recurring payments
Customers set up recurring payments once and stop checking them, which is the point. That makes them the easiest to break without anyone noticing. Each auto top-up needed to keep running on schedule through the switch, charged to the right card, so that no customer lost service because a payment they never check had failed.
3-D Secure and fraud rules
Every gateway authenticates payments and screens for fraud in its own way. Moving gateways means moving to a new set of rules, and those rules decide which customers are asked to verify a payment and which payments are blocked. Get them too loose and fraud gets through. Get them too strict and genuine customers are challenged or declined. For a telecom brand selling top-ups and calling credit, both matter: digital goods attract card fraud, and friction at checkout loses real customers.
The one thing that nearly went wrong
The friction showed up at 3-D Secure. Early in the rollout, more customers paying through Adyen were being asked to authenticate their payments than before, and some of them dropped off at that step instead of completing the payment. Each one was a customer who wanted to pay and did not.
The traffic split is what kept this small. It surfaced in a limited share of payments, where it was visible in the side-by-side numbers, rather than across every customer at once. That gave the team time to adjust the authentication and fraud settings and confirm the drop-off had recovered before moving more traffic over. In a single cutover, the same problem would have hit all three products on day one.
The result
All three products moved to Adyen in one month with no payment downtime: customers could pay throughout. No payments and no wallet balances were lost. The payment success rate went up, which was the main reason for the move, and customers gained new payment methods. The business also ended up with a gateway that fitted its customers across Europe and the United States, not just the UK.
A payment gateway migration checklist from this project
- Be clear on why you are moving, and pick the numbers that will prove it, such as success rate. These numbers will help you decide when each step of the rollout is safe.
- Give your own estimate early. A vendor’s typical timeline describes a typical integration, not your project. Say what it leaves out before it becomes your deadline.
- List every way money moves: one-off payments, recurring payments, wallets, refunds. Each one breaks differently.
- Split traffic, don’t cut over. Start with a small share on the new gateway, keep the old one live as the fallback, and increase step by step.
- Compare old and new side by side on success rate, declines and checkout drop-off, not just on whether payments technically work.
- Plan for saved cards both ways: migrate stored cards where you can, and make re-adding a card painless where you can’t.
- Protect recurring payments first. They fail silently and the customer finds out when their service stops.
- Treat 3-D Secure and fraud rules as product decisions. Watch how many customers are challenged and how many give up, and tune before you scale.
- Reconcile wallet balances against the gateway throughout, so every customer’s balance always matches what they paid. You must have audit logs of each transaction.
When a gradual traffic split is the wrong choice
A traffic split worked here because there was enough payment volume to compare the two gateways within days, and both could run side by side. It is not always the right call.
- Low payment volume. If a small share of traffic means a handful of payments a day, the comparison tells you very little. A planned cutover at a quiet time, with a tested rollback, may be simpler and just as safe.
- The old gateway cannot stay live. If the contract is ending or the provider is shutting down, there is no fallback to split against. Put the time into testing and saved card migration instead.
- Running two gateways costs more than the risk. Two sets of reconciliation, two reports and two support paths are real work. For a single simple product with no wallet or recurring payments, that overhead may not be worth it.
- No one is watching the numbers. A split only helps if someone compares success rates and drop-off at every step. Without that, it is a slow cutover with the same blind spots.
What this means if you are changing payment providers
A payment migration is not an integration task with a deadline. It is a product change that touches every paying customer, and it deserves the same care as any feature that affects revenue. The teams that get it right move gradually, measure the customer experience as closely as the technical one, and keep the old gateway available until the new one has proven itself.
The same products went through another high-stakes move, from .uk domains to a .com, which I wrote up as a website migration case study. For the fraud side of digital goods, see When Fraud Looks Like Growth: Chargebacks in Digital Goods. And for how moving into payments from telecom worked as a career step, see Transfer Learning: What Past Roles Teach Future PMs.
If you have a migration like this on your roadmap and want someone to own the plan, this is the kind of work I do as a technical product manager. Get in touch to talk it through.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
