Paybyrd Paybyrd
Gratis aanmelden
Het migratie-playbook · editie 2026

Hoe je je huidige processor verlaat zonder betalingen te breken.

Een 47-puntenrunbook van de engineers die TAP Air Portugal, Vila Galé, Prozis en KuantoKusta migreerden. Gefaseerd framework, technische en commerciële checklists, eerlijke red flags. Geschreven zoals we ons eigen team zouden briefen — geen salesdeck.

Het volledige runbook in je inbox? Eén e-mail met elke sectie hierboven, plus links die je team zo in Confluence / Notion kan plakken.

Geen marketinglijst. Eén mail met het runbook + een follow-up 14 dagen later om te checken hoe het ging.

Wat erin zit
  1. 01Waarom de meeste migraties mislukken
  2. 02Het 5-fasen-framework
  3. 03Technische migratie-checklist
  4. 04Commerciële checklist
  5. 05Vragen vóór je zegt dat je weggaat
  6. 06Wanneer NIET overstappen
  7. 0722 dagen tot live traffic · Vila Galé
  8. 0830-60-90 post-migratie
01 · Waarom de meeste migraties mislukken

Het is bijna nooit de integratie.

We hebben de diff gedraaid op tientallen migraties — onze eigen en die van concurrenten. Als er eentje uit de rails loopt, zit de oorzaak meestal op dezelfde vijf plekken. Ze vooraf kennen maakt van een risky 60-daags project een saai 22-daags project.

  1. 01

    De alles-of-niets-cutover

    Team zet op maandagochtend 100% van het verkeer om. Dinsdag 11 uur blijkt uit de diff dat subscription-re-auth in sandbox niet was gedekt. Terug rollen betekent nu opnieuw verkeer omklappen, dezelfde failure modes in reverse. Migreer altijd via parallel verwerken met een gefaseerde ramp — 5% → 20% → 50% → 100% over 2–4 weken.

  2. 02

    Kaart-token re-auth op schaal

    Je hebt 80.000 klanten met opgeslagen kaarten. De nieuwe processor ondersteunt geen network-token import van je huidige vendor. Gevolg: 80.000 re-auth-mails in twee weken, honderden verloren klanten door verwarde oudere shoppers, en een CS-team dat verzuipt in tickets. Check network-token portability altijd voor je tekent.

  3. 03

    Reconciliation-drift tijdens de overdracht

    Huidige processor betaalt T+2. Nieuwe T+1. Tijdens parallel verwerken reconcilieert finance twee cadansen tegen één ERP. Eén uitbetaling valt in de verkeerde maand, één refund verschijnt dubbel, en de CFO verliest een kwartaal lang vertrouwen in de cijfers. Lijn de ledger-mapping af VOOR je verkeer omklapt.

  4. 04

    Webhook endpoint mismatches

    Oude processor vuurt payment.captured. Nieuwe vuurt transaction.succeeded. Elk op zich ziet er goed uit. Samen omzeilen ze je fulfilment-logica — betalingen verwerken prima, maar niks wordt verzonden. Zet nieuwe webhook-handlers naast de bestaande voor je één enkele transactie omklapt, en replay historische events er een week tegenaan.

  5. 05

    Ontbrekende PCI-papierwerk

    Nieuwe processor gebruikt een ander embedded component pattern. Je auditor vraagt een bijgewerkte SAQ. Acht weken verder. Intussen kun je niks aan de checkout-pagina doen zonder opnieuw te scopen. Haal de Attestation of Compliance (AoC) + SAQ-type schriftelijk bij de nieuwe processor tijdens evaluatie — niet na go-live.

Wil je dit als bewerkbaar runbook-doc?

Laat je e-mail achter — we sturen het volledige playbook als één e-mail die je team kan archiveren, plus een check-in na 14 dagen om te zien hoe de migratieplanning loopt.

↓ Of blijf scrollen — het volledige playbook staat hieronder, opgedeeld per sectie.

02 · Het 5-fasen-framework

Van contract tot 100% live traffic, in vijf fasen.

We publiceren deze tijdlijnen als default. Voor de meeste merchants onder €500M jaaromzet levert dit framework schoon op in 20–28 werkdagen zonder zichtbare disruptie voor klanten. Enterprise-accounts met complexe reconciliation-stacks kunnen er 2–4 weken bij optellen.

  1. Fase 0 · Pre-work
    Week 0
    Stakeholder-afstemming

    Benoem de eigenaar aan beide kanten. Bevestig dat de CFO de parallel-processing-kosten heeft afgetekend. Bevries de feature-backlog voor de migratieperiode.

  2. Fase 1 · Onboard
    Week 1–2
    Sandbox + integratie

    Certificeer sandbox. Zet parallelle webhook-endpoints op. Exporteer historische data. Test 10 echte tokens end-to-end.

  3. Fase 2 · Parallel
    Week 3–4
    5–20% live traffic

    Getagde transacties lopen door beide kanten. Dagelijkse diff-rapporten. Finance valideert één uitbetalingscyclus voor verder uitbreiden.

  4. Fase 3 · Ramp
    Week 5–6
    Gefaseerde cutover

    20% → 50% → 80% → 100%. Jij houdt de rollback-schakelaar. Paybyrd's SRE's zitten op je Slack tijdens elke bump.

  5. Fase 4 · Validatie
    Week 7–8
    Sunset + stabiliseren

    Oude processor sluiten voor nieuw volume. Reserve-release gepland. Chargeback-tail ownership gemapped. 30-60-90-validatieplan scherpgesteld.

03 · Technische migratie-checklist

De technische 36-puntenpass.

Werk elk item af voor Fase 2. Streep door wat niet op jouw stack van toepassing is (bijv. geen subscriptions = sla de tokenisatie-groep over). De rest is non-negotiable.

Integratiefoot­print

4 items
  • Inventariseer elk codepath dat de huidige processor aanroept (checkout, subscriptions, refunds, admin-tools, reporting-exports, customer-service-panels).
  • Identificeer SDK-versies in productie — sommige endpoints zijn versie-pinned; de nieuwe processor heeft mogelijk matchende versies of een parallelle lib nodig.
  • Documenteer de bestaande webhook-handlers en hun idempotency-garanties voor je ook maar iets aanraakt.
  • Catalogiseer elke hardcoded testkaart / testaccount. Die werken aan de nieuwe kant niet meer.

Dataoverdracht

5 items
  • Exporteer de volledige transactiehistorie (minstens 18 maanden) in CSV én in het native processor-formaat. Heb je nodig voor refunds, chargebacks en tax audits lang na de cutover.
  • Exporteer alle opgeslagen kaart-tokens met hun vervaldata — refereer je naar bij import in de vault van de nieuwe processor.
  • Exporteer klantrecords, subscription-schemas, betaalplannen en opgeslagen betaalmethoden.
  • Snapshot de chargeback-historie (inclusief arbitrage-stadia) — de nieuwe processor erft disputeverplichtingen voor lopende zaken.
  • Bewaar alle PCI-attestation-documenten. Auditors vragen erom.

Tokenisatie en subscriptions

4 items
  • Bevestig dat de nieuwe processor network-token import ondersteunt van je huidige vendor (Visa/Mastercard network tokens zijn draagbaar; merk-specifieke proprietary tokens vaak niet).
  • Voor subscriptions: kies een re-auth-strategie. Network-token porting vermijdt klant-zichtbare re-auth. Proprietary tokens betekenen opnieuw invoeren bij de volgende factuur — plan de communicatie.
  • Test de migratie op een sample van 10 echte tokens end-to-end voor je in bulk migreert.
  • Verifieer 3DS2 step-up flows aan de nieuwe kant voor recurring en merchant-initiated transacties.

Webhooks en async

4 items
  • Zet nieuwe webhook-endpoints naast de bestaande; vervang pas als parallel verwerken pariteit bevestigt.
  • Replay-tests: kan het nieuwe endpoint een oude payload-shape aan? (Je backfill- / reconciliatie-tools sturen soms weken later nog legacy events.)
  • Verifieer dat idempotency-keys identiek werken aan de nieuwe kant. Double-capture / double-refund zijn de klassieke migratie-bugs.
  • Bevestig dat webhook-retry-policies compatibel zijn met je bestaande at-least-once-tolerantie.

Fraude en risico

4 items
  • Exporteer huidige fraude-regels (block lists, velocity-regels, geo-restricties) en vertaal ze naar de grammatica van de nieuwe engine — niet kopiëren.
  • Draai shadow mode op de nieuwe fraud-stack 2–3 weken voor je decisioning aanzet.
  • Verifieer dat de 3DS2-challenge-flow aan de nieuwe kant overeenkomt met klantverwachting (zelfde UI-transitie, zelfde success/failure UX).
  • Synchroniseer BIN-lijsten, issuer-regels en merk-specifieke logica.

Reconciliation en finance

4 items
  • Map de nieuwe uitbetalings-cadans naar je bestaande ledger / ERP. T+0 / T+1 / T+2 verschillen breken geautomatiseerde reconciliation stilletjes.
  • Bevestig dat de per-outlet / per-SKU / per-kanaal breakdown aan de nieuwe kant matched (of overtreft) wat je operationele rapporten nu bieden.
  • Lijn de eerste maand-einddata aan beide kanten op zodat finance boeken kan sluiten zonder dubbel te tellen.
  • Tag parallel-verwerkte transacties aan beide kanten met een gedeelde identifier (je order-ref is ideaal) voor automatische diff-rapportage.
04 · Commerciële checklist

Voordat je legal-team het nieuwe contract aanraakt.

Engineering krijgt de headlines; procurement bepaalt of de migratie zich écht terugverdient. Deze drie groepen zijn wat je CFO beantwoord wil zien voor hij tekent.

Exit-voorwaarden bij je huidige processor

3 items
  • Lees het contract. Opzegtermijn, exit fees, dataexport-verplichtingen, chargeback-tail, reserve-release-schema.
  • Bevestig dat de datum van je laatste nieuwe-volume-transactie GEEN vroege-beëindigingsboete triggert.
  • Als je huidige processor een stay-incentive aanbiedt: op papier eisen en afwegen tegen de totale migratiewaarde.

Acquirer / scheme-afspraken

3 items
  • Heb je directe acquirer-contracten los, dan hoef je die niet te verhuizen — de meeste orchestrators (Paybyrd incluis) zitten erboven.
  • Onderhandel met de nieuwe processor of je acquiring consolideert of je huidige afspraken behoudt.
  • Lees interchange++-termen zorgvuldig; blended pricing en IC++ hebben op schaal totaal andere cashflow-implicaties.

Reserves en holds

3 items
  • Krijg schriftelijke commitments over wanneer reserves na migratie worden vrijgegeven (standaard: 180 dagen na laatste nieuwe-volume-transactie).
  • Bevestig chargeback-tail ownership: je huidige processor blijft aansprakelijk voor disputes op pre-migratie-transacties.
  • Surcharge- en DCC-revenue-shares — begrijp beide kanten voor je omklapt.
05 · Vragen vóór je zegt dat je weggaat

Support-prioriteit kelderen op het moment dat je aankondigt.

Doe het export- en reserve-release-werk voor het gesprek. Zodra je opzegt, is de incentive van je huidige processor om je soepel te laten exporteren nul. Volgorde is alles.

  1. 01 Kan ik 24 maanden transactiehistorie vandaag onbeheerd exporteren in hun native formaat ÉN standaard CSV?
  2. 02 Werkt network-token porting voor onze Visa + Mastercard on-file base? (Antwoord: ja, altijd — maar bevestig het op papier.)
  3. 03 Wanneer worden reserves vrijgegeven en wat is het schema? (Standaard: 180 dagen na laatste nieuwe-volume-transactie.)
  4. 04 Wie is verantwoordelijk voor chargebacks en disputes na migratie tegen pre-migratie-transacties? (Antwoord: de oude processor, maar documenteer het.)
  5. 05 Wat is de cadans van dispute-notificaties nadat ons account is gesloten voor nieuw volume? (Sommigen vallen terug op maandelijkse batches — ramp voor response SLA's.)
  6. 06 Verliezen we direct toegang tot het admin-dashboard bij migratie, of is er een read-only gracieperiode? (Vraag om 180 dagen; velen geven 90.)
  7. 07 Zijn er minimum-volumeclausules die penalisaties triggeren als we afbouwen tijdens parallel verwerken?
  8. 08 Voor subscription-bedrijven: verhuist onze recurring-overeenkomst automatisch mee met network-token porting, of moeten we klant-zichtbare re-auth-meldingen sturen?
06 · Wanneer NIET overstappen

We zeggen het als het een slecht idee is.

Niet elk kwartaal is een goed migratie-kwartaal. Vijf situaties waarin het eerlijke antwoord is "wacht" — zelfs als je zeker weet dat de nieuwe cijfers beter zijn.

Je gaat binnen < 8 weken piek-seizoen in.

Zelfs een schone 22-daagse migratie heeft operationele staarten. Migreer niet in Black Friday / Kerst / zomerreispiek. Plan de cutover in je rustigste zes-weken-venster.

Je techteam is één of twee engineers.

Parallel verwerken vereist tegelijk monitoren aan beide kanten. Heb je geen bandbreedte, onderhandel extra migratie-support bij de nieuwe processor of fase het project over 3+ maanden uit.

Je hebt nog niet alles geëxporteerd.

De dag dat je de overstap aankondigt, valt de support-prioriteit van je huidige processor. Eerst exporteren, dan tekenen.

Je checkout is diep custom zonder testdekking.

Parallel verwerken is hoe je mismatches vindt. Kun je beide kanten niet instrumenteren met diff-rapporten, dan vlieg je blind.

Je contract heeft een variabele surcharge die triggert bij volume-drops.

Parallel verwerken splitst je volume tijdelijk. Lees de kleine lettertjes — sommige contracten straffen dat af.

07 · De 22-daagse migratie · Vila Galé

Contract op maandag. Live traffic drie weken later.

Vila Galé runt 40+ hotels door Portugal en Brazilië met een unified booking engine, on-property POS en een groeiend mobile-kanaal. Hun migratie van hun vorige processor naar Paybyrd was de snelste enterprise-scale hospitality-migratie die we hebben gedaan — dit was de échte tijdlijn.

Hotels gemigreerd
40+
Kanalen verenigd
Web + POS + Kiosk
Contract tot live
22 dagen
Klantdisruptie
Nul
  1. Dag 1 · Contract getekend

    Integratieteam gekoppeld. Sandbox-credentials binnen 4 uur geleverd. 18 maanden transactiehistorie van de oude kant geëxporteerd tegen Dag 3.

  2. Dag 4–9 · Parallelle endpoints up

    Nieuwe webhook-listeners deployed naast de oude. Network-token porting voor 200K card-on-file records gevalideerd op een sample van 50 records. Sandbox gecertificeerd tegen echte staging booking-flow.

  3. Dag 10–14 · 5% live traffic

    Paybyrd verwerkte 1 op 20 echte transacties gedurende 5 dagen. Diff-rapport elke ochtend. Enige anomalie: een afrondingsdrift op toeristenbelasting, binnen 24 uur opgepakt. Fixed op Dag 11.

  4. Dag 15–19 · 20% → 50% → 80%

    Gefaseerde bumps. Finance-team draaide hun maandeinde-close op parallel-verwerkt volume — reconciliation klopte tot op 4 cent op €3,2M aan geboekte omzet.

  5. Dag 20–22 · 100% cutover

    Oude processor gesloten voor nieuw volume op Dag 20. 30-daagse reserve-release ingepland. Paybyrd's SRE on-call zat de eerste week post-cutover in hun Slack. Nul klant-zichtbare incidents.

"Finance sluit de dag in uren af, niet op maandagen. De migratie zelf was minder verstorend dan een normale release-week."

— Vila Galé, post-migratie retrospective
08 · 30-60-90 post-migratie

De drie vensters waar het nog uitmaakt.

Cutover is niet de finish. De meeste migraties die "schoon live gingen" lekken daarna nog waarde om twee redenen: chargeback-tail drijft af, en approval-rate pariteit wordt niet gevalideerd tegen de nieuwe baseline.

Dag 0 – 30

Stabiliseren

  • • Dagelijkse approval-rate diff tegen de oude baseline.
  • • Wekelijkse reconciliation-audit (eerste uitbetalingscyclus).
  • • Drift van CS-ticketvolume gemonitord. (Spike = iets is door de diff-rapporten geglipt.)
  • • Notificatiekanaal voor chargeback-tail van oude processor bevestigd werkend.
Dag 30 – 60

Optimaliseren

  • • Fine-tune multi-acquiring routing tegen je daadwerkelijke decline-patronen.
  • • Activeer fraud decisioning na 3 weken shadow-mode-observatie.
  • • Eerste volle kalendermaand rapportage — CFO-review.
  • • Reserve-release ingepland, 180 dagen na laatste transactie.
Dag 60 – 90

Valideer de business case

  • • Blended kosten-per-transactie vs de oude baseline — matched de echte besparing de projectie?
  • • Approval-rate lift gematerialiseerd?
  • • Support-ticketvolume op pariteit of beter?
  • • Nieuwe capabilities geactiveerd (DCC revenue share, InstaTax, customer intelligence, etc.) — al omzet gegenereerd?

Nog hier? Zet er cijfers tegenover.

30 minuten met een senior payment engineer. Neem je meest recente processor-afschrift mee. We lopen dit framework langs je echte stack, en je gaat weg met een schriftelijk 22-daags migratieplan — of je nu voor Paybyrd kiest of niet.

Boek 30 min met een engineer