Switching payment providers? What to check before you move

Last updated 23 October 2026. Copy page as text

TL;DR

• Check the leaving cost before you sign anything new
• Ask both providers whether your saved cards can move
• Export customers, items and sales before your access ends
• Keep both accounts open for a short overlap
• Close the old account last, after refunds, chargebacks and held money are settled

Switching payment providers (processors) for your shop, salon or online store? Check leaving costs and saved cards, export your records, then overlap accounts and close the old one last. The short path covers readers, store settings and payment links, without code. Subscribers need billing checks. Money held or account closed? Start here. Your own integration? Use this plan.

The short switch path

1. Check what it costs to leave. Find your agreement and any separate equipment lease before contacting either company. Ask: "What's my termination fee? What's the auto-renewal notice deadline? Does my lease continue separately?" Read the contract checks and quote comparison before signing.

2. Ask about saved cards before you commit. Send both providers: "Can my saved cards move from [old provider] to [new provider]? Who handles the transfer? What won't move?" Get both answers in writing before you sign with the new provider. Subscribers need a separate billing plan, alongside the recurring-payments guide.

3. Export your records before access ends. Save customers, items and sales history somewhere you control before access ends. Open the files to check they're readable. Ask: "Where do I export each list? What won't the export include?" Square's closure guide names all three.

4. Check each reader and till. Ask the new provider: "Will this exact model work with you? If it won't, what must I replace?" Check your lease separately before returning equipment, even if you're replacing everything.

Here's what each provider publishes about leaving, from its own pages. "Not published" means its public pages don't answer that point. On a phone, scroll the table sideways.

Provider	Saved cards	Export your data	Hardware	When you close
Square VENDOR	Call support for an encrypted export to a PCI DSS Level 1 processor. One-time imports also start with support.	Square Dashboard has exports for customers, items and transactions.	Use with another processor: Not published.	Chargeback duties and reserves survive; payouts follow your schedule, subject to holds. Refund steps after closure: Not published. Ask: who handles later refunds, and can my reader move?
Clover VENDOR	Import and export to another processor: Not published.	Dashboard: customers and sales reports. Item spreadsheet export is offered; its click path: Not published.	Use elsewhere or reprogramming: Not published.	Clover's service terms end on 30 days' notice and give you time to extract your account data. Your processing agreement may set its own terms. Refunds, disputes, reserves and final payout after closure: Not published. Ask support for card moves, item-export steps, device reuse and an old-sales settlement plan.
Shopify Payments VENDOR	Ask support about imports; full card numbers need Plus or Enterprise. Export to another platform: Not published.	Shopify admin: Customers > Export, Products > Export, Orders > Export.	Shopify-supported readers require Shopify Payments. Reuse elsewhere: Not published.	Pending payouts continue; reactivate to contest chargebacks. Funds may stay held for unresolved obligations. Refund steps after closure: Not published. Ask about refunds, reserve release, card export and reader reuse.
Stripe VENDOR	Request a secure export or import through the migrations team. Exports need a PCI DSS Level 1 processor; Link credentials are excluded.	Dashboard: Customers > export, Transactions > Export. Product catalog > Export products: choose a date range, then Export for CSV.	Terminal software needs a Stripe account. Use elsewhere or reprogramming: Not published.	Pay out balances before closing; refunds and dispute responses stop. Liability remains. Reserve-release timing: Not published. Ask about held funds and device reuse.
PayPal VENDOR	Credit Card Vault imports and exports need sales vetting and a secure transfer. Coverage of POS-reader cards: Not published.	PayPal history; POS online Products > Export and Reports > Export. Customer-list export: Not published.	The Card Reader's permitted use is through the POS app.	Withdraw the business balance first; obligations remain. Holds, reserves or open disputes can block closure. Post-close refund steps and reserve-release date: Not published. Ask about old sales, held funds, customer exports and POS-card moves.
Toast VENDOR	Import and export of saved payment cards: Not published.	Toast Web: Guests > Guestbook > Download list; Reports > Sales > Sales summary. Ask Customer Care for menu data-export access.	Card processing must use Toast. Device reuse elsewhere: Not published.	Later chargebacks and refunds can require a reserve; remaining reserve funds return after obligations and requested paperwork are settled. Post-close refund steps and final-payout date: Not published. Ask about those, card moves and device reuse.
Helcim VENDOR	Start imports or exports with a support ticket. Exports go to a verified PCI-DSS Level 1 provider through an encrypted transfer.	All Tools: Customers > Import / Export, Products & Services > Import/Export; Payments > Export.	Hardware may only be used with Helcim's services.	Old obligations remain; closure may bring a reserve with a six-month minimum and release conditions. Any reserve remainder pays out after that period. Post-close refund steps: Not published. Ask support how later refunds and disputes will be handled.

Policies change. Check your own account before you rely on a row.

5. Keep a short overlap. Keep the old account open while you set up and check the new one. Don't assume both can run in one checkout. Shopify allows only one active card provider. Use its switching instructions, keeping old credentials for returns.

6. Move every place customers pay. Check the counter, online store, invoices, booking tool and recurring charges. Ask each app: "Where do I change the provider or payment link? What's your supported test flow?" Check each route before sending customers there, using the test flow that app supports.

7. Check the new money and fees. Match your first payout to its sales and bank deposit. Compare the first statement with your written quote, then ask about anything that doesn't match. Use Reading Statements.

8. Close the old account last. Refund old sales through the provider that took them. Chargebacks can arrive months later. Read the dispute timeline and held-money guide. Wait until old refunds, disputes and held money are settled before you request closure. Ask: "What's still outstanding? How will I receive the final payout and handle later claims?"

When this needs a different path

They closed your account or held your money? Start with holds and reserves and the MATCH guide, using the notice you've received. A routine switch won't settle that recovery problem.

Still looking for someone who'll take your business? Check acceptance before planning the migration.

You've built an integration, gateway or payment router? Follow the integration plan for testing, parallel running and a way back. You'll need more than the short path.

Subscribers rely on saved cards? That's the riskiest part of this switch. Read the recurring-billing step, then confirm your providers' supported move before changing charges.

If you have your own integration

Built your own payment integration, gateway or router? This part's for you. Switching processors is high-stakes: mess up the migration and you'll lose recurring revenue, break checkout, or spend a quarter on reconciliation. This one's about not doing that.

• Processor migrations take 4-8 weeks minimum; complex token migrations with large card-on-file databases take 12+ weeks - don't underestimate the timeline
• Token portability is the make-or-break factor. Confirm your current processor will export tokens and the new one can import them before you sign anything, because you can't fix it after
• Run both processors in parallel for 2-4 weeks instead of a hard cutover. Route a percentage of traffic to the new one first, so integration issues don't land on all your revenue at once
• Recurring billing is the highest-risk part. Test every subscription scenario (new charges, retries, cancellations) before you touch your existing subscriber base, and don't migrate it in one go

Workflow Overview

Phase	Key Tasks
Discovery	Inventory current processor, map features to new, define token strategy
Integration	Build parallel integration, test matrix (auth, capture, refund, void), all flows
Token Migration	Export strategy, import tokens, validate mapping, cutover planning
Execution	Ramp 10% → 25% → 50% → 100%, monitor auth rate, migrate recurring billing
Cleanup	Sunset old processor, update docs, post-migration review

Line up four things before Phase 1: the signed contract with the new processor, a live account and test credentials, your current processor's policy on exporting token and card data, and engineering time booked. The third one decides the other three. If your current processor won't put its token export policy in writing before you sign, you aren't planning a migration, you're planning a re-collection project. Find that out now, not in week three.

Trigger Criteria

Use this playbook when:

• You're migrating to a new payment processor
• You're adding a backup processor
• You're consolidating from multiple processors to one
• Current processor relationship is ending

The real cost here is 4-8 weeks of engineering time that isn't going into your product. Weigh the reason against that before Phase 1. Abandon it in week five and you're running two half-built integrations. That's worse than the processor you were unhappy with.

---

Phase 1: Discovery (Week 1-2)

Step 1: Inventory Current State

Document everything about current processor:

Item	Document
Transaction types	One-time, recurring, auth+capture, etc.
Payment methods	Cards, ACH, wallets, local methods
Token format	Vault structure, token format
Recurring billing	Subscription count, billing frequency
Stored credentials	How many cards on file
MIDs	All merchant IDs, per-MID config
Reporting	Settlement, reconciliation, disputes
Integrations	APIs, webhooks, SDKs in use

Step 2: Map to New Processor

Feature	Current	New Processor	Gap?
Card vault	Yes/No	Yes/No
Network tokens	Yes/No	Yes/No
3DS	Version	Version
ACH	Yes/No	Yes/No
Apple/Google Pay	Yes/No	Yes/No
Reporting format	Format	Format

Checkpoint: Feature parity confirmed or gaps documented with workarounds.

Step 3: Token Migration Strategy

Scenario	Approach
Processor supports token migration	Export tokens, import to new processor
No direct migration	Use network tokens (Visa/MC token services)
Neither works	Re-collect cards at next transaction
Account updater available	May help with expired cards during transition

Critical question: Can you export raw PANs or tokens that the new processor accepts?

---

Phase 2: Integration (Week 2-4)

Step 1: Build New Integration

Parallel integration approach:

Step 2: Integration Checklist

• Auth request/response handling
• Capture flow
• Refund flow
• Void flow
• Partial capture (if used)
• 3DS integration
• AVS/CVV handling
• Error handling and retries
• Webhook receivers
• Tokenization flow
• Recurring billing integration

Step 3: Test Matrix

Test Case	Status
Successful card auth
Declined card (various codes)
3DS challenge flow
3DS frictionless flow
Auth + capture
Auth + void
Auth + partial capture
Refund (full)
Refund (partial)
Recurring billing (create)
Recurring billing (charge)
Recurring billing (update)
Apple Pay
Google Pay

Checkpoint: All test cases passing in sandbox.

---

Phase 3: Token Migration (Week 3-5)

Option A: Processor-to-Processor Migration

If new processor accepts imported tokens:

1. Request token export from current processor
2. Transform token format if needed
3. Import tokens to new processor vault
4. Map old token IDs to new token IDs
5. Update your database with new token references
6. Validate sample of migrated tokens

Option B: Network Token Migration

Using Visa/Mastercard network tokenization:

1. Ensure both processors support network tokens
2. Export network tokens (DPAN + cryptograms) from old processor
3. Register network tokens with new processor
4. Network tokens work across processors

Option C: Gradual Re-collection

If migration not possible:

1. Keep old processor active for existing tokens
2. New customers go to new processor
3. At next transaction, existing customers re-enter card
4. Migrate stored credential to new processor
5. Eventually sunset old processor

Rank these A, then B, then C. Option C isn't a strategy, it's attrition on a delay. Every re-entry is a chance for the customer to cancel.

Checkpoint: Migration approach chosen and tested with sample data.

---

Phase 4: Cutover Planning (Week 4-6)

Step 1: Define Cutover Strategy

Strategy	Pros	Cons
Big bang	Clean cutover	High risk
Percentage ramp	Lower risk	Longer timeline
New customers only	Lowest risk	Two systems forever
By segment	Targeted migration	Complexity

Recommendation: Percentage ramp (10% → 25% → 50% → 100%)

A percentage ramp limits the sales exposed to a broken integration. The 10/25/50/100 sequence above is an example. Choose the starting share and each increase from your loss cap, attempt counts and ability to roll back. Monthly volume under $100K alone doesn't justify a hard cutover. A new-customers-only route needs a plan for the old subscriptions and the cost of running both systems.

Step 2: Create Rollback Plan

Define criteria and process. These are example starting triggers; agree the denominator, normal variation and rollback owner before launch:

Trigger	Action
Auth rate drops 5%+ vs baseline	Pause ramp, investigate
Error rate over 1%	Route back to old processor
New processor outage	Automatic failover to old
Dispute rate spikes	Investigate before proceeding

Step 3: Communication Plan

Stakeholder	What to Communicate	When
Customer support	New error codes, escalation path	1 week before
Finance	New settlement schedule, reconciliation changes	2 weeks before
Engineering	On-call schedule, rollback procedures	1 week before
Customers	Only if checkout UX changes significantly	Optional

---

Phase 5: Migration Execution (Week 5-8)

Step 1: Initial Ramp (10%)

1. Route 10% of new transactions to new processor
2. Monitor for 3-5 days minimum
3. Check:
   • Auth rate vs baseline
   • Error rate
   • Customer complaints
   • Settlement accuracy

Step 2: Expand Ramp (25% → 50% → 75%)

At each stage:

1. Increase traffic percentage
2. Monitor for 2-3 days
3. Verify metrics stable
4. Proceed or troubleshoot

Step 3: Full Cutover (100%)

1. Route 100% to new processor
2. Keep old processor available for fallback
3. Monitor closely for 1 week
4. Begin old processor sunset planning

Step 4: Recurring Billing Migration

Handle separately from one-time payments, and only after one-time traffic has held at 100% for a full week:

1. Identify all active subscriptions
2. Migrate tokens (per Phase 3 approach)
3. Update subscription records with new tokens
4. Test billing on subset of subscriptions
5. Run first full billing cycle with monitoring
6. Validate all charges succeeded

This is the highest-risk step in the whole migration. Give it its own week and its own rollback. If a billing cycle goes wrong you want exactly one variable to look at, and you want the old processor still standing. Don't batch it.

Checkpoint: All traffic on new processor, metrics stable.

---

Phase 6: Cleanup (Week 6-10)

Step 1: Sunset Old Processor

1. Confirm no active traffic to old processor
2. Resolve any pending transactions/settlements
3. Download historical data for records
4. Cancel old processor contract (if applicable)
5. Remove old processor code paths (after stabilization)

Step 2: Update Documentation

• Internal runbooks updated
• Dispute handling procedures updated
• Reconciliation processes updated
• Alert thresholds calibrated for new processor

Step 3: Post-Migration Review

Question	Answer
Auth rate vs pre-migration?
Any lost recurring customers?
Settlement timing acceptable?
Support ticket volume?
Lessons for next migration?

---

Success Criteria

You're done when:

• 100% of traffic on new processor
• Auth rate within 0.5% of pre-migration baseline
• All recurring billing functioning
• Reconciliation process working
• Old processor dependencies removed

The auth rate line is the one that gets waved through. A migration that settles outside that 0.5% band isn't finished, it's a revenue cut you agreed to on a call and then stopped measuring. Compare declines at BIN level and close the gap, or route back.

---

Critical Metrics to Track

Metric	Pre-Migration	During Ramp	Post-Migration
Auth rate	Baseline	Daily	Weekly
Error rate	Baseline	Hourly	Daily
Decline codes	Distribution	Daily	Weekly
Settlement lag	Baseline	Daily	Weekly
Dispute rate	Baseline	Weekly	Monthly

---

Scale Callout

Volume	Considerations
Under $100k/mo	Can often do big-bang cutover; simpler token migration
$100k-$1M/mo	Percentage ramp recommended; test recurring billing carefully
Over $1M/mo	Dedicated migration team; extended parallel running; fallback essential

---

Where This Breaks

• Swapping readers or payment links? Use the short path before closing anything.
• Token migration fails. Test migration on small sample first. Have re-collection fallback.
• Auth rate tanks. The new processor doesn't have the same issuer relationships. Compare at BIN level before you commit.
• Recurring billing broken. Test billing flow end-to-end before migrating subscriptions.
• Settlement reconciliation off. Different settlement timing/format. Update finance processes.
• Old processor shuts down early. Get the timeline in writing, and keep them live longer than you think you'll need.
• No rollback tested. Test failover before you need it. Don't assume it works.

---

Next Steps

After migration is complete:

1. Optimize on new processor: Run auth optimization experiments now that you have fresh baseline
2. Clean up old code: Remove old processor integration after 30-day stability period
3. Update documentation: Runbooks, escalation contacts, API references
4. Renegotiate terms: At 6-month mark, review volume and negotiate better rates
5. Plan redundancy: Consider keeping a backup processor relationship for failover

---

Related

• Auth Optimization - Improving approval rates
• Processor Reporting Checklist - Data requirements
• Settlement & Reconciliation - Post-capture operations
• Benchmarks - Auth rate targets
• Processor Management - Working with processors
• Subscriptions & Recurring - Migrating recurring billing
• 3D Secure - Authentication integration
• Decline Codes - Understanding declines
• Money Held or Frozen - Processor reserves
• Payment Change Checklist - Testing changes
• Reading Statements - Understanding processor costs
• Buying Payments - Processor selection criteria

Sources

Source	Supports	Opened
VENDOR Toast merchant agreement	Contract-specific termination fees and renewal terms, section 8	21 October 2026
VENDOR Toast POS renewal FAQ	Check the order, agreement and written non-renewal notice	21 October 2026
VENDOR Toast financing contacts	Separate finance contract and contacting its provider	21 October 2026
FTC equipment-lease warning	Read the full lease and get cancellation promises in writing	21 October 2026
VENDOR Stripe payment-data export	Provider-to-provider card transfer and Link exclusions	21 October 2026
VENDOR Square account closure	Export customers, items and payment history before access ends	21 October 2026
VENDOR Shopify provider settings	One active card provider, switching and retaining credentials for old returns	21 October 2026
VENDOR Stripe refunds	Refund the original payment through its account	21 October 2026
VENDOR Stripe dispute lifecycle	Disputes can follow old sales months later; timing varies	21 October 2026
VENDOR Square payment terms	Sections 14, 19-22 and 37-39: reserves and chargeback duties survive closure; final payout conditions	21 October 2026
VENDOR Provider pages for Square, Clover, Shopify Payments, Stripe, PayPal, Toast and Helcim, linked in the provider table	Each provider row	21 October 2026
VENDOR Stripe payout reconciliation	Match an automatic payout to its included transactions	21 October 2026