The Migration & Transition Playbook

How to plan, execute, and de-risk a payments migration — without blowing up your business, your merchants, or your quarterly numbers.

19 min read

When to migrate

Most platforms come to a migration decision reactively — they’ve outgrown their current setup and the pain finally becomes undeniable. The better approach is proactive: understand the trigger points before they hit, so you can plan rather than scramble. Six conditions signal it is time to act.

Trigger 1 — You’re on a referral model leaving >$500K/year on the table

Referral arrangements — where you route merchants to a payment processor in exchange for a flat fee or small revenue share — are a natural starting point. They also become a trap. As your merchant base and GMV grow, the delta between what you earn and what you could earn compounds rapidly. At $30M GMV the gap might be $150K annually. At $100M GMV it can easily exceed $500K–$1M. The math alone justifies a migration.

Trigger 2 — You’re on Stripe flat-rate and your GMV exceeds $50M

Stripe’s 2.9% + $0.30 pricing model is exceptional for companies in their first few years — the simplicity and reliability are genuinely valuable. But flat-rate pricing is a tax on success. At $50M GMV, an IC+ arrangement with a PFaaS provider can save $300K–$700K annually depending on your card mix. At $100M+ GMV the case is nearly always compelling. The question is not whether to move — it is when. (See Chapter 4 for the full Stripe-specific decision framework, and Chapter 5 for the underlying economics.)

Trigger 3 — Your vendor’s technology is limiting product development

Payment technology is no longer passive infrastructure. It generates the data that powers underwriting, informs risk models, and enables new financial products (see Chapter 8). If your current vendor’s API is limiting what you can build — real-time reporting, custom onboarding flows, the data infrastructure needed for working capital products — you are not just leaving money on the table, you are falling behind strategically. Technology limitations are the most underweighted migration trigger.

Trigger 4 — Your contract terms are unfavorable and up for renewal

Contract renewal moments are migration opportunities. If your current contract has unfavorable terms — opaque pricing, restrictive exclusivity clauses, punitive termination fees — a renewal is the natural moment to renegotiate or walk. Evaluate your contract 12–18 months before renewal, not 60 days before. Use the competitive landscape to create legitimate pressure, even if you ultimately stay.

Trigger 5 — You want interchange transparency

Flat-rate processors bundle interchange, assessment fees, and their own margin into a single number. You have no visibility into what you’re paying for each component. Interchange-plus (IC+) pricing separates the cost pass-through from the processor’s margin — you see the interchange category, the network fees, and the processor’s markup independently. This transparency is foundational to optimizing your economics (Chapter 6) and, eventually, to building underwriting models on payment data (Chapter 8).

Trigger 6 — You need capabilities your vendor doesn’t support

As platforms expand geographically or add new service lines, capability gaps become critical. Common examples:

• Card-present (in-person) payments — often unavailable or poorly supported by online-first processors.

• International processing — complex currency, compliance, and acquiring requirements across markets.

• ACH and bank-to-bank transfers — essential for B2B, marketplace, and high-value transaction contexts.

• Embedded card issuance — increasingly required for full-stack embedded finance strategies.

Charge Forward Insight

When building the migration business case, quantify both sides of the ledger. The revenue uplift from migrating is straightforward. Less obvious is the cost of staying: every quarter on an unfavorable structure is a quarter of forgone margin. Multiply the annual revenue gap by the number of years you delay. It compounds faster than most executives expect. Flagship Advisory Partners estimates that payment optimization alone — moving from non-strategic to strategic payment arrangements — can double the revenue a platform earns from payments. That is the cost of inaction.

Common migration paths

Not all migrations are equal. The right path depends on your current arrangement, your GMV, your technical capabilities, and your strategic objectives. The five most common migration patterns:

Reading the migration ladder

Think of these paths as a progression. Most platforms begin with a referral arrangement, then move to PFaaS as their first owned payments product, then optimize economics at scale with a managed PayFac or IC+ arrangement. Few platforms leap directly to full PayFac — the operational and regulatory requirements are substantial, and it only makes sense at $1B+ GMV. (The Charge Forward Maturity Framework maps platforms across these stages and identifies the right next move at each one.)

The most overlooked migration is PFaaS → PFaaS. As the market has matured, meaningful differences have emerged between PFaaS providers on economics, technology, and service quality. If you launched with the first PFaaS provider that called you, you may be significantly underperforming what a well-negotiated arrangement with a more competitive provider could deliver. (See Chapter 11 for take-rate comparisons between payment models, and the Vendor Database for current PFaaS comparisons.)

The migration process, step by step

A well-run migration follows five phases. Each phase has a defined purpose, a set of key activities, and a clear exit criterion that gates the next phase. The total timeline typically runs 3–9 months depending on the complexity of your integration and the size of your merchant base.

Phase 1 — Assessment (Weeks 1–4)

The assessment phase establishes your baseline and builds the business case. Too many platforms skip this phase and start directly with vendor conversations — a mistake that results in negotiating from a position of ignorance.

• Audit your current state: volumes, pricing, effective take rate, fee structure, contract terms, expiration dates.

• Map your technical integration: which APIs, which data flows, which internal systems depend on the current processor.

• Define your requirements: card-present, international, data access, onboarding flexibility, SLA requirements.

• Build the financial model: current economics vs. target economics vs. migration cost vs. payback period.

Phase 2 — Vendor Selection (Weeks 4–8)

Issue a structured RFP to 3–5 vendors. The RFP should cover pricing, technology architecture, onboarding and underwriting philosophy, risk and chargeback management, customer support, and contractual flexibility. Get competitive proposals before you negotiate with your preferred vendor.

• Evaluate on: economic model (IC+ vs. blended), technology (API quality, reporting, data access), service (dedicated support, implementation assistance), risk (their underwriting standards vs. your merchant risk profile).

• Run reference checks with other ISV/SaaS customers of similar size.

• Negotiate contractual protections: pricing floors, technology SLAs, data portability rights, reasonable termination clauses.

Phase 3 — Technical Integration (Weeks 8–20)

Technical integration is the longest phase and the one most frequently underestimated. Budget aggressively for engineering time — particularly if your current integration is deep and custom.

• API integration: payment capture, settlement, reporting, dispute management, onboarding flows.

• Sandbox testing: test every payment type, every edge case, every failure mode before touching production.

• Certification: most processors require formal certification testing; build this timeline into your plan.

• Parallel processing setup: configure the ability to run both processors simultaneously during the transition.

• Staff training: customer support, implementation engineers, and sales all need education on the new platform.

Phase 4 — Merchant Migration (Weeks 16–36)

Merchant migration is where most projects go wrong. The temptation is to migrate everyone at once — resist it. A phased approach is far safer.

• Start with new merchants: all new sign-ups go onto the new processor immediately; this builds confidence and catches issues without affecting existing relationships.

• Migrate in cohorts: segment your existing merchant base by volume, risk profile, or geography, and migrate one cohort at a time.

• Communication plan: merchant-facing communication should be proactive, clear, and focused on the benefits (faster onboarding, better support) — not the mechanics.

• Monitor closely: watch dispute rates, authorization rates, and merchant support tickets in real time during each cohort migration.

Phase 5 — Optimization (Ongoing)

A migration is not an optimization — it is the foundation for one. Once you are live on the new platform, the work of maximizing economics begins (Chapter 6 covers the full optimization playbook).

• Fine-tune pricing to merchants based on volume tiers, risk profile, and vertical.

• Monitor interchange categories — are you qualifying for the best possible rates?

• Track dispute and chargeback rates — do they reveal merchant risk patterns that require action?

• Assess data quality — are you capturing the transaction-level data needed for your next embedded finance product? (See Chapter 8.)

The token-vault challenge

The most common technical surprise in a payment migration is the token-vault problem. Understanding it early — ideally during Phase 1 — is the difference between a smooth migration and an expensive one.

What are payment tokens?

When a customer stores their card on file with your platform, the actual card number (the Primary Account Number, or PAN) is replaced by a processor-generated token. This token is meaningless outside of that processor’s system — it is a unique identifier that only that processor can map back to the real card number.

The implication: stored payment methods cannot be moved directly from one processor to another.

Your options

1. Re-collect card information from your customers. The most comprehensive solution — and the most friction-generating. Works well for platforms with low stored-card reliance or natural recollection moments (subscription renewals). Poorly suited to platforms where stored cards are core to the UX.

2. Use network tokenization (Visa / Mastercard). Visa and Mastercard each offer network-level tokenization programs that create a token managed by the card network rather than the processor. Network tokens are portable — they can be used across processors. If you are on network tokenization today, your migration is significantly simpler. If you are not, this is worth implementing before your next migration.

3. Use a token migration service. Several providers (including some PFaaS platforms and specialized services) can facilitate controlled token migrations in coordination with both the old and new processors. This process requires formal agreements with both processors and is subject to PCI requirements.

Practical mitigation in the wild

In practice, most migrations use a hybrid approach:

• Run dual processing: process new transactions on the new processor while legacy stored cards continue on the old processor for a defined period (typically 6–12 months).

• Migrate at natural re-collection points: when a stored card expires or is updated, collect it on the new processor rather than migrating the old token.

• Force re-collection for high-volume merchants: for your top merchants by volume, proactively communicate the change and prompt card update as part of a platform upgrade.

• Accept attrition on dormant stored cards: cards that haven’t transacted in 12+ months are unlikely to generate incremental revenue — accept the loss rather than investing in migration.

Charge Forward Insight

Most platforms underestimate their stored-card exposure until they are deep into Phase 3. Add a stored-card audit to Phase 1 — specifically, what percentage of your transaction volume comes from stored cards, and what percentage of those are subscription or recurring. That ratio determines how much attention the token-vault problem deserves in your planning. If 60%+ of your TPV runs through stored cards, the migration is fundamentally a token-strategy project with payments work attached, not the other way around.

Managing merchant experience during migration

The technical challenges of a migration are solvable with enough engineering time. The harder challenge is maintaining merchant trust and minimizing attrition during the transition. The operational playbook below is what high-quality migrations look like in practice.

Communication plan

Merchants hate surprises. The best migrations communicate early, clearly, and with a focus on merchant benefit.

• Announce 60–90 days before cutover for affected merchants.

• Frame the message around improvements: faster onboarding, better reporting, improved support — not internal infrastructure changes.

• Provide a clear timeline with specific dates, not vague windows.

• Designate a migration support contact (email or phone) for questions.

• Send reminder communication 30 days out, 14 days out, and 48 hours before cutover.

Parallel processing

Running old and new processors simultaneously during the transition period is the single most important risk-mitigation tactic. It allows you to catch integration issues without disrupting live merchants.

• Define a specific parallel processing window (typically 30–90 days per merchant cohort).

• Use the parallel window to validate authorization rates, settlement timing, and reporting accuracy.

• Only decommission the old processor after a clean parallel processing window with no material issues.

Phased rollout

• Start with new merchants — zero risk, builds confidence.

• Migrate low-volume existing merchants next — limited impact if issues arise.

• Migrate high-volume merchants last — maximum preparation, maximum monitoring.

• Reserve 10–15% of your most complex merchants (high volume, high stored-card use, complex integrations) for a final “white glove” migration with dedicated support.

Internal team training

• Customer support: must be trained on new platform workflows, dispute processes, and settlement timing before the first merchant migrates.

• Implementation/onboarding: must understand new API, new merchant portal, and new onboarding documentation.

• Sales: must understand what has changed, what is better, and how to position the migration positively in prospect and partner conversations.

Edge cases that bite

• Disputes in flight: maintain access to the old processor’s dispute management system for 120 days post-migration (standard dispute response window is 30–90 days, plus buffer).

• Pending settlements: ensure all pending settlements on the old processor clear before decommissioning.

• Chargeback rights: confirm your chargeback rights and processes are fully operational on the new processor before routing live volume.

• Funding timing: brief merchants on any changes to settlement timing or funding cadence.

Building the business case

Every migration requires internal buy-in, and every internal buy-in requires a business case. The structure of a compelling payment migration business case:

Revenue uplift formula

The simplest framing of migration economics:

Annual Revenue Uplift = (Target Take Rate − Current Take Rate) × Annual GMV

Illustrative: a $75M GMV platform moving from ~0.20% effective take rate to ~0.55% take rate → $75M × (0.55% − 0.20%) = ~$262,500 in additional annual revenue. At $150M GMV with the same improvement: ~$525,000. At $300M GMV: ~$1,050,000.

One-time migration cost estimate: $200K–$500K (engineering + setup + labor). Payback period at $75M GMV: 9–23 months. At $150M GMV: 5–12 months. The Charge Forward Payments Revenue Calculator runs this analysis against your specific volume and card mix.

Risk factors to model

• Merchant attrition: budget 2–5% churn during migration; most can be recovered with proactive communication and improved merchant experience on the new platform.

• Authorization rate changes: model a temporary 0.5–1% decline in authorization rates during the transition as merchants and processors calibrate; this typically normalizes within 30–60 days.

• Engineering delay: add a 25% buffer to engineering timeline estimates — payment integrations routinely take longer than expected.

• Parallel processing costs: running two processors adds incremental cost during the overlap period; budget explicitly for this.

Charge Forward Insight

In Charge Forward advisory work, a consistent pattern emerges: the platforms most successful at migrations treat it as a strategic project, not an IT project. That means executive sponsorship, dedicated project ownership, and a merchant communication plan developed before the technical work begins. The most common pitfall is underestimating the merchant-migration phase. Technical integration usually goes reasonably well. The surprises come in Phase 4: the merchant who has 8,000 stored cards and a custom integration, the dispute filed three days before cutover, the settlement timing change nobody told the finance team about. Plan Phase 4 with the same rigor you apply to Phase 3. Map your top 50 merchants by volume before the migration starts. Assign a dedicated migration contact to each of your top 20. The investment in that white-glove treatment pays for itself in attrition prevented.

What’s next

You now have the complete migration playbook. If you are facing a migration in the near term, the place to start is Phase 1: the assessment. Map your current state, build your business case, understand your token exposure — before you start talking to vendors. If you are not facing an imminent migration, use this chapter as a planning resource. Know your trigger points. Know your current effective take rate. Understand your contract terms and renewal dates. That preparation — done in advance — is what allows you to migrate on your terms rather than under pressure.

Chapter 10 — “The Embedded Finance Roadmap” — moves from optimizing your current payments to building the financial services ecosystem that sits on top of them. Payments is the wedge. Chapter 10 covers what you can build once you’ve driven it in.

To confirm your target end-state model before starting vendor conversations, use the Charge Forward Payment Model Fit Navigator. To short-list providers against your specific requirements, use the Vendor Database. To benchmark take rates and economics by model, see Chapter 11.

SOURCES & REFERENCES

Flagship Advisory Partners — Beyond Payments: The $1T Embedded Finance Opportunity (2025); Adyen/BCG Embedded Finance Report (2024); William Blair — How Embedded Finance Drives Enterprise Value and Increases Multiples for SaaS Platforms (September 2025).

Visa US Token Service documentation; Mastercard Digital Enablement Service (MDES) documentation; PCI DSS v4.0 requirements for stored payment credentials.

Charge Forward Embedded Payments Benchmark Report (April 2026); see Chapter 11 for take-rate comparisons by payment model. Note: FIS acquired Payrix in February 2022.

Public Charge Forward tools referenced in this chapter: Payment Model Fit Navigator, Vendor Database, Payments Revenue Calculator, Maturity Framework. All available at chargeforward.io/tools.

By Jane Podbelskaya · Updated June 20, 2026