Analyserapport: Checkout-Flow Brekz Webshop¶
Document metadata
| Auteur | Boaz Bakhuijzen |
| Datum | 12 januari 2026 |
| Bedrijf | Flooris |
| Klant | Brekz |
| Semester | Semester 3 - Leerjaar 2 |
1. Inleiding¶
1.1 Doel¶
Dit rapport beschrijft de bevindingen uit de analyse van de checkout-flow van de Brekz webshop. Het rapport richt zich op architecturele knelpunten, risico's en concrete aanbevelingen voor verbetering.
Volledige technische documentatie
1.2 Scope¶
- Analyse van happy path en een selectie van unhappy paths in de checkout-flow
- Identificatie van architecturele knelpunten en technische schuld
- Beoordeling van de metrics-implementatie
- Geprioriteerde aanbevelingen voor verbetering
1.3 Methodiek¶
De analyse is uitgevoerd over een periode van ongeveer 15 weken en omvatte de volgende activiteiten:
- Handmatige testing van alle betaalmethoden in de testomgeving (iDEAL, PayPal, Creditcard, Bancontact, Klarna, Bank Transfer)
- Doorlopen van happy paths en een selectie van unhappy paths
- Handmatige extractie van de Copernica calls in een aparte repository
- Ontwikkeling van een geautomatiseerd PHP script voor extractie van InfluxDB calls
- Identificatie en categorisatie van 100+ metrics per checkout-stap
- Code-analyse over meerdere technische lagen (Smarty templates, Vue componenten, PHP controllers, JavaScript)
- Ontwikkeling van sequence diagrams voor interacties tussen frontend, backend en CM.com
- Evaluatie van CM.com integratie en API-afhankelijkheden
- Identificatie van verouderde API's zonder actuele CM.com documentatie
2. Analyse van de Checkout-Flow¶
2.1 Overzicht¶
De checkout bestaat uit 6 hoofdstappen:
flowchart LR
A[Cart] --> B[Authenticatie]
B --> C[Betaalmethode]
C --> D[Betaling]
D --> E[Validatie]
E --> F[Bevestiging]
Ondersteunde betaalmethoden: iDEAL | PayPal | Creditcard | Bancontact | Klarna | Bank Transfer
Maestro niet gevalideerd
Maestro kon niet worden gevalideerd in de testomgeving en wordt daarom niet als volledig werkend beschouwd.
2.2 Bevindingen: Happy Path¶
De happy path werkt, maar de analyse identificeerde belangrijke architecturele problemen:
1. Beperkte traceerbaarheid
De checkout draait voornamelijk op één URL (/checkout?isPaymentStep=true) en één controller (OrderOpcController) zonder duidelijke en/of zichtbare state-tracking. Bij klantproblemen is het daarom moeilijk om te achterhalen waar precies iets misging.
2. Onvoldoende scheiding van verantwoordelijkheden
Cart, order en betaling zijn 1-op-1 gekoppeld. Dit werkt in de happy path, maar veroorzaakt grote problemen bij mislukte betalingen (zie sectie 2.3).
3. DOM-afhankelijke implementatie en template complexiteit
De checkout JavaScript werkt voornamelijk met DOM queries. Om de dataflow te begrijpen moet je de HTML-structuur grotendeels kennen. Daarnaast zijn de Smarty templates veel genest (template in template in template), met JavaScript files en sporadisch een Vue component ertussen. DOM-elementen worden soms hergebruikt als form containers, wat de semantische structuur onduidelijk maakt.
4. Monolithische controller
De OrderOpcController bevat alle checkout-logica (authenticatie, validatie, payment initiatie) zonder separation of concerns.
2.3 Bevindingen: Unhappy Paths¶
De analyse van unhappy paths identificeerde kritische architecturele problemen.
Kritisch knelpunt: cart-order-betaling koppeling
De 1-op-1 koppeling zorgt ervoor dat bij elke mislukte betaling een nieuwe cart en order in de database wordt aangemaakt:
- Database vervuiling: Tientallen incomplete orders per klant bij betalingsproblemen
- Onduidelijke order-status: Klanten zien meerdere orders, maar het is onduidelijk welke de echte is
- Geen betaalgeschiedenis: Er is geen zichtbaarheid van herhaalde betaalpogingen
- Debugging problemen: Bij support-incidents is het onduidelijk welke order relevant is
Architecturele keuze
De architectuur maakt geen onderscheid tussen order-status en betaalstatus. Dit is een implementatiekeuze, geen technische beperking van CM.com.
3. Technische Context¶
3.1 Systemen¶
| Laag | Technologie |
|---|---|
| Frontend | Vue.js componenten, Smarty templates |
| Backend | PrestaShop/PHP, docdatapayments module |
| Payments | CM.com (REST + SOAP) |
| Metrics | InfluxDB, Copernica, GA4 |
3.2 CM.com API Situatie¶
| API | Gebruik | Status |
|---|---|---|
| SOAP | Klarna, Bank Transfer, Creditcard tokens | Niet meer gedocumenteerd |
| REST (oud) | iDEAL, PayPal | Legacy volgens CM.com |
| REST (nieuw) | - | Niet geïmplementeerd |
Risicoanalyse SOAP-afhankelijkheid
Ook REST-gebaseerde betalingsmethoden (iDEAL, PayPal) gebruiken SOAP endpoints voor betaling validatie. De totale SOAP-afhankelijkheid is daarom hoger dan de tabel suggereert.
De SOAP endpoints zijn nog wel operationeel, maar CM.com heeft deze verwijderd uit hun officiële documentatie en biedt er geen officiële ondersteuning meer voor. Dit vormt een risico voor toekomstige stabiliteit en onderhoud.
4. Metrics Analyse¶
De checkout heeft 100+ InfluxDB metrics.
Bevinding
De metrics zijn nuttig maar zonder duidelijke strategie geplaatst. Sommige flows hebben 10 metrics, andere helemaal geen. Dit maakt het lastig om:
- Te bepalen waar nieuwe metrics moeten komen
- Goede conversie-funnels te bouwen
- Te begrijpen wat er gemeten wordt zonder de code te lezen
Belangrijkste checkout metrics¶
| ID | Event | Locatie |
|---|---|---|
MT-9 |
Cart add | Product toegevoegd aan winkelwagen |
MT-31 |
Checkout view | Checkout pagina geladen |
MT-32 |
Payment failed | Betaling mislukt (met reden) |
MT-35 |
Submit payment | "Nu Betalen" geklikt |
MT-30 |
Order confirmation | Bevestigingspagina bereikt |
5. Knelpunten en Risico's¶
Kritiek¶
Legacy SOAP API
SOAP endpoints zijn operationeel maar niet meer gedocumenteerd door CM.com. Dit verhoogt het risico op onoplosbare toekomstige problemen en potentiële beveiligingsissues.
1-op-1 cart/order/betaling
Database vervuiling door duplicate orders, onduidelijke transactiestatus voor klanten, en grote debugging uitdagingen bij support-incidents.
Hoge prioriteit¶
Geen separation of concerns
Monolithische controller en JavaScript verhogen het risico op regressies bij aanpassingen en maken bugs moeilijk te isoleren.
Incomplete error logging
Geen gestructureerde logging van betaalfouten maakt het moeilijk om klantproblemen te diagnosticeren.
Gemiddelde prioriteit¶
Metrics zonder strategie
Inconsistente metrics maken het moeilijk om goede conversie-funnels te bouwen.
Acceptabele risico's¶
Geaccepteerd
- CM.com als single point of failure: Gewenste situatie - directe integratie met alle payment providers is niet wenselijk
- 3D Secure timeouts: Afhankelijk van banksystemen, buiten onze controle
6. Aanbevelingen¶
Prioriteit 1 - Kritiek¶
1. Migreer naar nieuwste CM.com REST API
De SOAP API vormt een risico. Hoewel de endpoints nog operationeel zijn, documenteert en ondersteunt CM.com deze niet meer officieel, waardoor toekomstige problemen moeilijk op te lossen zijn. Ook de huidige REST implementatie is verouderd volgens CM.com.
Migratie naar de nieuwste REST API is belangrijk voor:
- Systeemstabiliteit en onderhoudbaarheid
- Toegang tot actuele documentatie en support
- Beperking van beveiligingsrisico's
2. Ontkoppel order en betaling
De 1-op-1 koppeling tussen orders en betalingen moet worden vervangen door een architectuur die meerdere betaalpogingen per order ondersteunt:
| Entiteit | Statussen |
|---|---|
| Order | pending → confirmed → shipped |
| Betaling | initiated → failed / success |
Mislukte betalingen leiden tot nieuwe betaalpoging, niet tot nieuwe order.
Deze wijziging voorkomt:
- Database vervuiling door duplicate incomplete orders
- Onduidelijkheid voor klanten over welke order de echte is
- Debugging problemen bij support-incidents
Prioriteit 2 - Hoog¶
3. Refactor checkout architectuur
Split de monolithische checkout over meerdere controllers met duidelijke verantwoordelijkheden. Vervang DOM-gebaseerde querySelector logica door state-driven Vue componenten met duidelijke data flows.
4. Gestructureerde error logging
Implementeer systematische logging van alle betaalfouten met context:
- In welke stap de fout optrad
- Welke betaalmethode werd gebruikt
- CM.com foutcodes en responses
- Duidelijke foutmeldingen voor gebruikers met vervolgacties
5. Metrics strategie
Definieer een duidelijke metrics-strategie:
- Documenteer elke metric met doel en interpretatie
- Implementeer complete conversie-funnel coverage
- Standaardiseer waar metrics worden geplaatst
7. Conclusie¶
Samenvatting
De checkout-flow werkt voor de happy path, maar de analyse identificeerde belangrijke architecturele problemen:
- Legacy API-afhankelijkheden zonder actuele provider-ondersteuning
- Architecturele koppeling die robuuste unhappy path afhandeling belemmert
- Monolithische code-organisatie die onderhoud en debugging bemoeilijkt
Belangrijkste aanbeveling
Ontkoppeling van orders en betalingen. Deze wijziging lost het merendeel van de unhappy path problemen op en maakt de checkout robuuster.
Bijlagen¶
Documentatie¶
Termen¶
| Term | Uitleg |
|---|---|
| PDP/PLP | Product Detail Page / Product Listing Page |
| CM.com | Payment provider (voorheen Docdata) |
| 3DS | 3D Secure authenticatie |
| MT-X | Metric ID in InfluxDB |