Skip to main content

Integration & Exit

TL;DR
  • How you integrate determines your PCI scope: a fully hosted checkout (Stripe Checkout, Shopify) usually qualifies for SAQ A, the lightest, but you still validate it each year; card data touching your servers means SAQ D, the heaviest. Confirm which applies with your acquirer
  • Token portability is your exit strategy - before you integrate, confirm you can export your stored payment methods in a format your next processor can import
  • Embedded/redirect checkout is the fastest path to launch but the hardest to customize; API integration takes 2-4x longer but gives full control over UX and fraud flow
  • Commercial-card data support depends on your processor. Stripe supports CEDP through Checkout, Billing and Invoicing as well as PaymentIntents; a custom API checkout isn't always needed

Your exit strategy is part of the purchase decision. How you integrate affects PCI scope, conversion, flexibility, and whether you can leave.


Choosing Integration Method​

How you connect to your processor affects PCI scope, conversion, and flexibility.

API vs. Hosted Checkout vs. Plugin​

MethodPCI ScopeControlSpeed to MarketBest For
Hosted checkoutLowestLimitedFastMost SMBs
PluginLowLimitedFastPlatform users (Shopify, WooCommerce)
APIHigherFullSlowCustom flows, omnichannel

You Probably Don't Need an API​

If you're asking "should I use the API?", the answer is probably no.

Use hosted checkout if:

  • You're under $1M/mo
  • Standard checkout flow works for you
  • You don't have dedicated dev resources
  • PCI compliance scares you (it should)

Use API if:

  • You need custom checkout flows
  • You're building omnichannel (online + in-person unified)
  • You're a marketplace or platform
  • You have dev resources to maintain it

Integration Method Decision Tree​

Do you need custom checkout UI?
├── No → Use hosted checkout or plugin
└── Yes → Do you have dedicated dev resources?
├── No → Reconsider. Hosted checkout is fine.
└── Yes → Are you prepared for SAQ D (PCI)?
├── No → Use tokenization (SAQ A-EP)
└── Yes → Full API integration

Ask Your Dev​

"What's our PCI scope with our current integration? What would change if we switched methods?"


Token Portability: The Golden Handcuffs​

Your exit strategy is part of the purchase decision.

Why This Matters​

If you have stored cards (subscriptions, repeat customers), those cards are tokenized by your processor. If you leave, you need those tokens. If your processor won't export them, your customers have to re-enter cards. That means churn.

Operator Questions to Ask Before Signing​

  1. "If I leave, do you export my tokens to a new PCI-compliant vault?"
  2. "What is the process, cost, and timeline?"
  3. "Is this supported for network tokens and processor tokens?"

Network Tokens vs. Processor Tokens​

  • Processor tokens: Tied to that processor. Portability depends on their policy.
  • Network tokens: Visa/Mastercard tokens. More portable, but still need processor cooperation.

Contract Language to Look For​

  • "Token export" or "data portability" clauses
  • Fee structure for token export (some charge per-token)
  • Timeline for export (30 days? 90 days?)

If it's not in the contract, assume you can't do it.

Token Portability Comparison​

Processor TypeTypical PortabilityNotes
StripeSupported (to PCI-compliant vault)Well-documented process
SquareLimitedMay require customer re-entry
PayPal/BraintreeSupportedStandard migration tools
Traditional ISOsVaries widelyGet in writing
Legacy processorsOften not supportedMajor migration risk

Related: Subscriptions and Recurring


Card-Present Considerations​

If you have in-person sales, processor selection gets more complex.

Terminal Bundling vs. Separate Purchase​

  • Bundled terminals: Often "free" but locked to processor. Leave, and the terminal is a paperweight.
  • Separate purchase: More upfront cost, but you own the hardware.

Ask: "If I switch processors, can I use my terminals with the new processor?"

In-Person Transaction Pricing Differences​

  • CP (card-present) transactions typically have lower interchange than CNP
  • Some processors quote blended rates that hide the CP advantage
  • Ask for separate CP and CNP rate breakdowns

Omnichannel Processor Requirements​

If you sell online and in-person, you want one processor for both. Why:

  • Unified reporting
  • Single reconciliation
  • Token sharing between channels

Not all processors do omnichannel well. Ask for a demo of the unified dashboard.

Card-Present Checklist​

ItemQuestion to Ask
Terminal ownershipDo I own the hardware?
Terminal portabilityCan I use it with another processor?
CP vs CNP ratesWhat's my interchange for in-person?
Unified reportingOne dashboard for all channels?
Token sharingCan I charge a card saved in-store online?

Related: Card-Present Terminal Decisions


Commercial-Card Data: Check Before You Build​

B2B Sellers

Ask about Visa CEDP, Mastercard Level 2/3 and Amex enhanced data separately. Extra fields don't guarantee lower fees.

Tax, order references and product detail may be needed. Get your processor's field list before changing checkout.

Stripe supports CEDP through PaymentIntents, Checkout, Billing and Invoicing. Don't rebuild a hosted checkout just to send commercial data. Stripe CEDP integration guidance.

Operator Questions​

  • "Which cards and sales qualify on each network?"
  • "Can our current integration send the required fields?"
  • "What verification, program fees and later adjustments apply?"
  • "What's the net saving on our eligible card mix?"

See commercial-card guidance before budgeting savings.


Migration Planning​

When switching processors, plan carefully to minimize disruption.

Migration Checklist​

PhaseActions
Pre-migrationToken export confirmed, new processor approved, integration tested
CutoverUpdate payment endpoints, test live transactions, monitor errors
Post-migrationVerify settlement, confirm token migration, cancel old account

Common Migration Failures​

  1. Tokens didn't migrate → Customers forced to re-enter cards
  2. Webhook endpoints not updated → Missing payment notifications
  3. Old processor still charging fees → Forgot to cancel
  4. Settlement timing changed → Cash flow surprise

The 90-Day Rule​

Run both processors in parallel for 90 days if possible:

  • New transactions on new processor
  • Recurring/subscriptions migrated in batches
  • Old processor for remaining refunds and disputes

Where This Breaks​

  1. Legacy integration debt. If your checkout is deeply integrated with a specific processor's API, migration is a major project.

  2. Stored cards without portability. Subscription businesses can lose significant revenue from forced card updates.

  3. International expansion with cross-border complexity. US processors with "international support" often means cross-border (expensive), not local acquiring (cheaper).


Analyst Layer: Metrics to Track​

MetricWhat It Tells YouTarget
Auth rate by processorProcessor performanceCompare the same card, country and transaction mix before and after migration
Payout timingCash flow predictabilityCheck arrival against your account schedule, including weekends and holds
Token migration success rateMigration healthReconcile exported, imported and failed records; resolve failures before the affected renewals
Commercial-data qualificationTrack eligible sales by network and programAgree account-specific targets with your processor

Next Steps​

  1. Decide on integration method → Match to your resources and PCI appetite
  2. Confirm token portability → Get it in the contract
  3. Plan for omnichannel → If you have or plan in-person sales
  4. Ask about commercial-card data → Check each network and your current integration

See Also​

Something wrong on this page? Email matt at paymentsandrisk.com and say what needs fixing.