Integration & Exit
- 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
| Method | PCI Scope | Control | Speed to Market | Best For |
|---|---|---|---|---|
| Hosted checkout | Lowest | Limited | Fast | Most SMBs |
| Plugin | Low | Limited | Fast | Platform users (Shopify, WooCommerce) |
| API | Higher | Full | Slow | Custom 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
- "If I leave, do you export my tokens to a new PCI-compliant vault?"
- "What is the process, cost, and timeline?"
- "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 Type | Typical Portability | Notes |
|---|---|---|
| Stripe | Supported (to PCI-compliant vault) | Well-documented process |
| Square | Limited | May require customer re-entry |
| PayPal/Braintree | Supported | Standard migration tools |
| Traditional ISOs | Varies widely | Get in writing |
| Legacy processors | Often not supported | Major 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
| Item | Question to Ask |
|---|---|
| Terminal ownership | Do I own the hardware? |
| Terminal portability | Can I use it with another processor? |
| CP vs CNP rates | What's my interchange for in-person? |
| Unified reporting | One dashboard for all channels? |
| Token sharing | Can I charge a card saved in-store online? |
Related: Card-Present Terminal Decisions
Commercial-Card Data: Check Before You Build
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
| Phase | Actions |
|---|---|
| Pre-migration | Token export confirmed, new processor approved, integration tested |
| Cutover | Update payment endpoints, test live transactions, monitor errors |
| Post-migration | Verify settlement, confirm token migration, cancel old account |
Common Migration Failures
- Tokens didn't migrate → Customers forced to re-enter cards
- Webhook endpoints not updated → Missing payment notifications
- Old processor still charging fees → Forgot to cancel
- 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
-
Legacy integration debt. If your checkout is deeply integrated with a specific processor's API, migration is a major project.
-
Stored cards without portability. Subscription businesses can lose significant revenue from forced card updates.
-
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
| Metric | What It Tells You | Target |
|---|---|---|
| Auth rate by processor | Processor performance | Compare the same card, country and transaction mix before and after migration |
| Payout timing | Cash flow predictability | Check arrival against your account schedule, including weekends and holds |
| Token migration success rate | Migration health | Reconcile exported, imported and failed records; resolve failures before the affected renewals |
| Commercial-data qualification | Track eligible sales by network and program | Agree account-specific targets with your processor |
Next Steps
- Decide on integration method → Match to your resources and PCI appetite
- Confirm token portability → Get it in the contract
- Plan for omnichannel → If you have or plan in-person sales
- Ask about commercial-card data → Check each network and your current integration
See Also
- Processor Selection - Choosing the right processor
- Contracts & Underwriting - What to negotiate
- Card-Present Terminal Decisions - Terminal selection
- Subscriptions and Recurring - Recurring billing setup
- PCI DSS - Security requirements
- Processor Management - Ongoing relationship