Skip to content

Analyserapport: Checkout-Flow Brekz Webshop

Terug naar klant: Brekz

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

User flow flowchart

  • 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

PHP extraction script

  • 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

Technical flow documentatie

  • 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]

Flowchart Sequence diagrams

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.

Technische flows

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.

Volledige metrics tabel

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 pendingconfirmedshipped
Betaling initiatedfailed / 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:

  1. Legacy API-afhankelijkheden zonder actuele provider-ondersteuning
  2. Architecturele koppeling die robuuste unhappy path afhandeling belemmert
  3. 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

  • Checkout Process


    Current Situation documentatie

    Bekijken

  • Metrics Extraction


    Tooling voor metrics extractie

    Bekijken

  • CM.com Payments API


    Officiële API documentatie

    Bekijken

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