Kiedy migrować
Sygnały alarmowe:
• >20% klientów z Polski, ale BLIK generuje <30% obrotu (Stripe słabo obsługuje BLIK)
• Effective rate >3% (w PL typowe 1,4–2,2%)
• Dispute/chargeback proces po angielsku wydłuża się >14 dni
• Faktury w USD = ryzyko FX + problem VAT (odwrotne obciążenie)
Fazy migracji
Faza 1 (tydzień 1–2): dual-running. Payment Gateway obok Stripe. Nowi klienci → Payment Gateway, istniejące subskrypcje → zostają na Stripe.
Faza 2 (tydzień 3–6): migracja subskrypcji. Network Token Portability — karty VTS/MDES przenosimy bez re-authentication. PAN-only → re-enrollment przy najbliższej transakcji.
Faza 3 (tydzień 7): cutover. Stripe w trybie read-only (historyczne raporty), Payment Gateway 100% nowego obrotu.
Mapowanie API
Większość endpointów Stripe → Payment Gateway ma 1:1 odpowiednik:
• /v1/charges → /v1/payments
• /v1/payment_intents → /v1/payments (z capture_method=manual)
• /v1/customers → /v1/customers
• /v1/subscriptions → /v1/subscriptions
• /v1/refunds → /v1/refunds
Payment Gateway publikuje migration adapter — drop-in replacement dla Stripe SDK (Node/Python), który pod spodem wywołuje nasze API. Zero zmian w kodzie dla 80% use caseów.
Dane historyczne
Stripe nie daje bulk export PAN-ów (słusznie). Co możesz zrobić:
• Dla tokenized cards (VTS/MDES): bulk token migration przez network. 2–5 dni.
• Dla PAN-only: użyj Stripe Card Data Export (wymaga PCI Level 1 po obu stronach + NDA) lub re-enrollment przy pierwszej transakcji.
Historyczne transakcje (do celów księgowych) eksportujesz CSV-em ze Stripe Dashboard — Payment Gateway pozwala je zaimportować do swojego data warehouse przez POST /v1/historical_imports.
Webhooks
Zmień URL subscription endpointu w panelach obu gatewayów stopniowo.
Wzorzec: jeden unified webhook handler w Twojej aplikacji, który rozpoznaje źródło po nagłówku (Stripe-Signature vs. X-PaymentOrchestrator-Signature) i normalizuje do wspólnego formatu.
Przykład implementacji — na naszym GitHubie: payment-orchestrator/migration-examples.
Realny timeline klienta (case)
SaaS B2B, 40k PLN MRR, ~2 500 aktywnych subskrypcji:
• Dzień 0–7: setup + testy w sandbox
• Dzień 8–14: dual-running, 10% ruchu
• Dzień 15–28: scaling do 100% nowych + migracja VTS tokenów
• Dzień 29: cutover
• Involuntary churn: 0,3% (vs. 1,2% średnia w Stripe → PG migracjach gdzie merchant nie użył VTS)