Ontwerp een WooCommerce-betaalmethode als één server-side betaalproces met twee passende presentatielagen voor Classic Checkout en Checkout Blocks. Kopieer de zakelijke logica niet naar twee frontends. Beide varianten moeten dezelfde beschikbaarheid, validatie, orderstatus en foutafhandeling gebruiken.
WooCommerce-webshops bestaan vaak uit een mix van oudere shortcodes, nieuwe blocks en aangepaste checkouttemplates. Een methode die alleen in het beheerscherm registreert, verschijnt niet vanzelf correct in iedere checkout. Test daarom expliciet welke integratielaag de actieve winkel gebruikt en wat er tijdens een thema- of WooCommerce-update verandert.
Scheid betaalregels van checkoutweergave
De server beslist of de methode beschikbaar is, valideert invoer en start de betaling. Classic Checkout rendert velden en meldingen via PHP-hooks; Blocks gebruikt een geregistreerde frontendcomponent en data uit de WooCommerce Store API. Beide sturen uiteindelijk naar hetzelfde gecontroleerde serverproces.
Zet geen essentiële locatie-, bedrag- of rechtencontrole uitsluitend in JavaScript. Een verborgen knop kan alsnog handmatig worden aangeroepen en frontendcode kan verouderd in een cache staan. JavaScript verbetert de ervaring; de server bewaakt de regel.
Maak de gegevenscontracten klein en expliciet. De frontend heeft bijvoorbeeld titel, beschrijving, beschikbaarheidsreden en een paar veilige configuratiewaarden nodig, niet het volledige providerobject. Versieer veranderingen die de vorm van die data wijzigen. Daarmee voorkom je dat Classic en Blocks toevallig verschillende interpretaties van dezelfde instelling krijgen.
| Onderdeel | Gedeelde kern | Presentatieverschil |
|---|---|---|
| Beschikbaarheid | Serverregel voor ordercontext | Classic hook of Blocks-storedata |
| Titel en uitleg | Beheerinstellingen | Markup passend bij component |
| Start betaling | Zelfde service en controles | Andere frontendaanroep |
| Foutstatus | Gestandaardiseerde foutcode | Notice of blockmelding |
| Betaalovergang | Één idempotente serverroute | Alleen statusweergave verschilt |
Voorkom stille degradatie
Wanneer de Blocks-integratie ontbreekt, kan de betaalmethode geheel verdwijnen zonder zichtbare beheerfout. Voeg daarom een compatibiliteitscontrole toe in beheer en een releasecheck die de actieve cart- en checkoutpagina opent. Andersom kan een onvolledige frontendregistratie wel een titel tonen maar geen correcte afhandeling hebben.
Houd versies van JavaScript en PHP bij elkaar. Een nieuwe serverrespons met oude frontendcode kan een betaling onbegrijpelijk blokkeren. Gebruik bestandsversies voor cacheverversing en test na deployment vanaf een schone browsersessie. Voor maatwerk dat met een veranderend platform meebeweegt is een onderhoudsafspraak minstens zo belangrijk als de eerste bouw. Lees meer bij maatwerksoftware voor bedrijfsprocessen.
Controleer daarnaast de editorervaring. Een beheerder die een nieuwe Checkout Block-pagina publiceert, moet vóór livegang kunnen zien dat de methode ondersteund wordt. Geef in pluginbeheer een gerichte waarschuwing als benodigde blocks of afhankelijkheden ontbreken. Laat die waarschuwing niet als algemene banner op iedere beheerpagina verschijnen; koppel hem aan de plek waar iemand hem kan oplossen.
Fictief voorbeeld: gefaseerde migratie naar Blocks
Speciaalzaak Atelier gebruikt jarenlang Classic Checkout. Het team bouwt een terminalmethode voor showroomorders en wil later naar Blocks. In plaats van een tweede plugin te maken, wordt de betaalservice los van de checkoutmarkup gehouden. De Blocks-component leest dezelfde titel, beschrijving en beschikbaarheidsuitkomst.
Tijdens de test blijkt dat de locatiekeuze in Classic als formulierwaarde komt, terwijl Blocks hem via de checkoutstate bijwerkt. Beide paden normaliseren die context op de server. Wanneer de locatie niet geldig is, geven zij dezelfde foutcode terug maar tonen ieder een passende melding. De orderstatus en providerverificatie blijven identiek.
Atelier bouwt ook een tijdelijk parallel testpad. Een kopie van de checkout wordt alleen voor medewerkers zichtbaar, zodat echte combinaties van coupons, verzending en klantrollen kunnen worden geprobeerd. Pas nadat de matrix klopt, vervangt Blocks de oude pagina. De oude presentatie wordt daarna verwijderd om te voorkomen dat twee checkouts ongemerkt blijven bestaan.
Compatibiliteitsmatrix voor acceptatie
- Test Classic Cart plus Classic Checkout.
- Test Cart Block plus Checkout Block.
- Test een gemengde migratiesituatie die de webshop werkelijk gebruikt.
- Controleer gast, ingelogde klant en bevoegde medewerker.
- Wissel verzendmethode en locatie tijdens de checkout.
- Test succes, weigering, time-out en herladen.
- Controleer toetsenbord, foutfocus en schermlezermeldingen.
- Herhaal na updates van WooCommerce, thema en checkoutplugins.
Neem alleen combinaties op die je werkelijk ondersteunt. Een lange lijst theoretische compatibiliteit zonder end-to-endtest geeft schijnzekerheid. Leg in beheer vast welke checkout actief is en laat een ontbrekende integratie opvallen vóór klanten hem ontdekken. Voor orderdata die daarna naar andere systemen gaat, kan Yindle Connect de overdracht en uitzonderingen organiseren.
Leg regressietests vast rond de zakelijke uitkomst, niet alleen rond zichtbare knoppen. In beide checkouts moet één correcte order ontstaan, met dezelfde betaalmetadata en herstelmogelijkheid. Zo kan de presentatie later veranderen zonder dat de betaalregels stil meeveranderen.
Verwar daarbij “betaling verwerkt” niet met “order vervuld”. WooCommerce kan een betaalde order op “Processing” zetten wanneer levering nog volgt en op “Completed” wanneer geen verdere uitvoering nodig is. Classic en Blocks moeten ook in dat onderscheid dezelfde serverlogica gebruiken.
Bespreek met Yindle een betaalmethode die in jouw WooCommerce-checkout blijft werken.
Wanneer de betaalmethode onderdeel is van een fysieke Mollie-terminalflow, lees dan Yindle Terminal Payments. Voor de laatste klassieke bestelstappen blijft Yindle Checkout een afzonderlijke presentatielaag.