The Payment Route Was Still Working. We Had to Build Its Replacement Anyway.

Payoneer already worked with a licensed Chinese payment provider that had proved reliable in prior work, and the local business team had an established relationship with them. That gave us a credible payment rail and reduced one source of uncertainty.

The surrounding product was much broader. A customer first had to qualify for the new route. Their information had to be current enough, additional consent and terms had to be handled correctly, and the provider needed the right identity and document data. Individuals and companies also had different onboarding requirements.

Legal had implications to resolve around the provider relationship and customer terms. Operations needed new ways to handle onboarding blockers, KYC-related issues, payment tracking and investigation. Teams responsible for regulatory information requests had to learn how to deal with incoming spot checks and supporting-document requests. Across the program, dependent teams owned capabilities around identity and qualification, customer and bank-account data, documents, registration and consent, communications, payment visibility, and other platform services.

One of the more consequential problems appeared in qualification. Eligibility depended partly on customer bank-account information, and during discovery we found gaps between the information the new flow required, the existing qualification model, and the integrations connecting them. Until that gap was resolved, we could not reliably determine which customers were eligible for the new route.

The owning team already had significant commitments of its own. Executive backing gave us an escalation path, though it did not create roadmap capacity. There was additional integration work that would help that team reach one of its own objectives, so we expanded the scope slightly and designed the dependency to serve both roadmaps.

It took some negotiation. Once the same work was useful to both teams, the priority conflict became easier to solve.

Several other dependencies were simpler, and some did require escalation. This one stayed with me because changing the shape of the dependency gave both teams a reason to move.

We chose individuals first. They gave us a more controlled population for proving the complete journey, with less risk that an unexpected failure would disrupt a complex business operation.

Companies brought more variation: different entity structures, document requirements, legal-representative information, document expiry, and potentially larger gaps between the information Payoneer already held and what the provider required. We therefore tested the route with a limited individual population, widened availability as confidence grew, and brought company customers into the next phase.

That choice reduced initial rollout risk and gave us a cleaner first test. The cost was time: full company coverage came later.

Operations learned alongside the product. An onboarding failure could reflect missing information, a document problem, a KYC issue, or a customer who needed assistance. Payments could require investigation, and regulatory spot checks created another operational flow around supporting information.

By Q3, staged production rollout began on schedule. We had proved enough of the route to start widening access, while the company journey and operational model continued to mature.

The old route was still available, and customers had little reason to complete additional onboarding for an alternative they did not yet urgently need. Early adoption was slow.

The China GTM organization took much of the lead on customer awareness and engagement. My focus stayed closer to the product and operating system underneath it: expanding eligibility safely, making sure each intended customer type could complete the journey, identifying where the flow was breaking down, and coordinating removal of the blockers behind those failures.

As rollout widened, I worked with the data team to build a daily view of the migration. We followed the funnel from eligibility and exposure through onboarding and completion, looking for populations that were lagging and for technical or operational bottlenecks.

The dashboard gave the program a shared view of progress. When something slowed down, we could see where it was happening and involve the people who could change it. It became part of the way we ran the rollout rather than an end-of-month report.

Availability expanded progressively over roughly six months. The plan held up well, helped by strong management support and broad cooperation. Execution still depended on the provider, the dependent teams, Legal and Compliance, Operations, and eventually real customers all doing their part.

By the end of the program, we had established the new route end to end for the customer types we had committed to support and met the delivery targets we had set.

The China business team had been living with this risk for a long time. By 2024, another roadmap or optimistic date carried limited weight. They needed to see the alternative work end to end when we said it would.

Delivering that commitment and satisfying a senior stakeholder who had entered the program with understandable skepticism was one of the most rewarding parts of the project for me.

I wrote separately about the relationship around this delivery in You Don’t Reduce Oversight by Asking for Trust. That companion piece focuses on how visible commitments, misses and recovery changed the way we worked together.

Stakeholder management is an accurate label for part of the work, though it understates the product problem. Every team had legitimate goals of its own. My job was to keep one company-level risk coherent while translating it into decisions and bounded pieces of work that made sense to the people responsible for each part of the system.

That is what I remember most strongly about the project, much more than the provider integration itself.