Commerce Checkout en Facturen Setup¶

Datum: 3 november 2025
Doel: Checkout flow configureren en facturatiesysteem opzetten met PDF generatie

Uitgangspunt¶

We hebben één testproduct (Los nummer "Voedingsgeneeskunde 4 - 2025") en moesten beslissen: eerst alle productsoorten opbouwen of beginnen met checkout?

Strategische Beslissingen¶

Vraag 1: Eerst alle producten opbouwen of nu al checkout configureren?¶

Beslissing: Begin nu met checkout.

Redenen: - Validatie van architectuur: Checkout moet werken voor alle producttypes. Door nu op te zetten valideer je of tax resolver, cart en payment flow correct functioneren - Iteratief werken: Als er problemen zijn in checkout (BTW-berekening, address handling, payment provider), ontdek je dat vroeg - Minder complexiteit: Checkout opzetten met één product is overzichtelijker dan met tientallen producten - Hergebruik: Eenmaal geconfigureerd werkt checkout automatisch voor alle nieuwe producttypes

Vraag 2: WeFact integratie voor facturen of Drupal-native oplossing?¶

Eerste overweging: WeFact koppelen voor facturatie en boekhouding.

Probleem: - WeFact stuurt facturen → dubbele emails mogelijk (Drupal + WeFact) - Onduidelijk hoe gebruikers facturen downloaden via hun account

Uiteindelijke beslissing: Drupal-native facturen met Commerce Invoice.

Voordelen: - Klanten downloaden facturen via hun account (/user/orders) - Automatische koppeling order ↔ factuur ↔ gebruiker - Volledige controle over vormgeving en branding - Privacy: alle data blijft binnen eigen systeem - WeFact sync later mogelijk toevoegen voor accountant-integratie

Geïnstalleerde modules: - drupal/commerce_invoice - Factuur entities gekoppeld aan orders - drupal/entity_print - PDF generatie via dompdf - drupal/symfony_mailer - Moderne email handling voor Drupal 10+

Checkout Flow Configuratie¶

Locatie: /admin/commerce/config/checkout-flows

Bestellingstype: Standaard¶

Locatie: /admin/commerce/config/order-types/default/edit

Configuratie: - Label: Standaard - Workflow: Standaard (draft → completed) - Generate special ordernummer: Aangevinkt - Geeft klanten herkenbaar ordernummer (bijv. #2025-001) in plaats van node ID - Bestelling verversen: Alleen verversen bij laden - Order herberekenen alleen bij cart/checkout pagina's, niet bij elke pageview (betere performance) - Receipt BCC: Test email adres ingevuld (later aan te passen naar definitief adres)

Checkout Stappen¶

Gekozen flow: Standaard checkout flow bewerkt (niet nieuwe flow aangemaakt)

Reden: Standaard flow bevat al logische stappen, aanpassen is makkelijker dan vanaf nul. Voor één webwinkel volstaat één flow.

Stap 1: Inloggen¶

Configuratie: - Allow guest checkout: UIT - Verplicht inloggen - Allow registration: AAN - Nieuwe klanten kunnen registreren tijdens checkout

Reden voor verplicht inloggen: - Medische content vereist authenticatie (juridische redenen) - Consistent: gebruikers zijn al gewend in te loggen voor artikelen - Betere klantrelatie: je weet wie je klanten zijn - Order history: klanten zien hun eerdere aankopen - Herhaalaankopen makkelijker (opgeslagen gegevens)

Overige instellingen: - Override display label: Leeg gelaten (standaard "Inloggen") - Wrapper element: Container (standaard)

Stap 2: Orderinformatie¶

Contactinformatie: - Veldengroep: AAN - Vereis dubbele e-mailinvoer: AAN (als email wordt gevraagd, dubbel checken is goed) - Always display email fields: UIT

Reden voor UIT: - Gebruikers zijn al ingelogd (verplicht via stap 1) - Email is al bekend in systeem - Onnodig om opnieuw te vragen - Betere gebruikerservaring (minder velden)

Resultaat: Alleen factuuradres wordt gevraagd, niet opnieuw email adres.

Stap 3: Overzicht¶

Functie: Laatste check voor betaling - Toont volledige order samenvatting - Producten, prijzen, BTW, totaal - Factuuradres ter verificatie - Laatste kans om terug te gaan en aan te passen

Configuratie: Standaard instellingen behouden (geen opties beschikbaar behalve label)

Reden: Wettelijk vaak verplicht (transparantie voor online verkoop), voorkomt fouten.

Stap 4: Betaling¶

Betaalinformatie configuratie: - Always display payment methods: AAN - Klanten moeten kunnen kiezen betaalmethode - Collect payment methods on orders with zero balance: UIT

Reden voor UIT bij zero balance: - Bij €0,00 orders (bijv. 100% kortingscode) geen betaalmethode nodig - AAN zetten alleen zinvol voor recurring payments (abonnementen auto-verlengen) - Voor losse nummers niet relevant

Payment capture mode: - Gekozen: Autoriseren en vastleggen (Authorize and capture) - Geld wordt direct afgeschreven bij succesvolle betaling

Reden: - Meest gebruikelijk voor digitale producten en losse nummers - Geen fysieke verzending die annulering voor verzending vereist - Order completion = betaling direct binnen

Alternatief (Alleen autoriseren): Geld reserveren maar niet direct afschrijven - gebruikt voor fysieke producten waar annulering voor verzending mogelijk moet zijn.

Overige stappen¶

Voltooid: Standaard behouden - automatische "Bedankt voor je bestelling" pagina

Zijbalk: Standaard behouden - toont order samenvatting tijdens checkout

Uitgeschakeld: Niet-actieve stappen (bijv. Verzending) blijven uitgeschakeld

Payment Gateway: Mollie¶

Locatie: /admin/commerce/config/payment-gateways

Installatie¶

Module geïnstalleerd: drupal/commerce_mollie

composer require drupal/commerce_mollie
ddrush en commerce_mollie -y

Probleem na installatie: Mollie verscheen niet in Plugin dropdown bij nieuwe gateway aanmaken.

Oplossing: Cache geleegd via ddrush cr - daarna wel beschikbaar.

Configuratie Gateway¶

Instellingen: - Naam (machine name): betaling_via_mollie - Naam voor weergave: Betaling via Mollie - Plugin: Mollie

Alternatieve naamgeving overwogen: "iDEAL, Creditcard & meer" - duidelijker voor klanten omdat Mollie als merknaam weinig zegt, maar uiteindelijke keuze was "Betaling via Mollie".

Betaalinstructies: Leeg gelaten

Reden: Mollie redirect is vanzelfsprekend, te veel tekst veroorzaakt verwarring en hogere drop-off. Mollie toont zelf al instructies.

Voorwaarden (Current Request, Klant, Bestelling, Producten): Alle leeg gelaten

Reden: Mollie is enige betaalmethode en moet altijd beschikbaar zijn. Voorwaarden alleen nodig bij meerdere payment gateways of geografische restricties.

API Keys¶

Status: Nog niet ingevuld (wacht op Mollie account holder)

Configuratie voor morgen: - Mode: Test - Test API key: Invullen (begint met test_...) - Live API key: Later invullen

Verkrijgen: Mollie.com → Developers → API keys

Email Configuratie¶

Symfony Mailer¶

Module: drupal/symfony_mailer (geïnstalleerd)

Reden voor installatie: - Drupal 10+ standaard (vervangt oude swiftmailer/phpmailer) - Betere deliverability - Commerce integratie: Order confirmatie emails out-of-the-box - Toekomstbestendig

Configuratie: Nog uit te voeren

Plan: - SMTP settings configureren (mailserver gegevens) - From address instellen (bijv. winkel@voedingsgeneeskunde.nl) - Order confirmation email templates aanpassen - Eerst testen met lokale mail (PHP mail), SMTP pas als alles werkt

Facturatie Setup¶

Commerce Invoice¶

Module: drupal/commerce_invoice v2.2.0

Functie: - Maakt invoice entities gekoppeld aan orders - Automatische factuur generatie bij order completion - Klanten kunnen facturen downloaden via account

Entity Print¶

Module: drupal/entity_print v2.18.0
PDF Engine: dompdf v3.1.4

Configuratie: /admin/config/content/entity-print

PDF Engine keuze: Dompdf geselecteerd

Waarschuwing op configuratie pagina:

TCPDF (v1) is not available
Php Wkhtmltopdf is not available

Beslissing: Negeren - dit zijn alternatieve PDF engines die optioneel zijn.

Beschikbare engines: - Dompdf - geïnstalleerd, werkt prima voor facturen - TCPDF - optioneel alternatief - Wkhtmltopdf - optioneel, complexer (vereist binary installatie)

Reden voor Dompdf: - Voldoende voor professionele factuur layouts - Ondersteunt custom CSS styling - Embedded lettertypen mogelijk - Logo's en afbeeldingen - Wkhtmltopdf is overkill voor facturen (alleen beter bij complexe CSS3/HTML5)

Vormgeving (nog uit te voeren): - Custom CSS voor PDF (lettertype, kleuren, spacing) - Twig template override (structuur, logo positionering) - Bedrijfslogo toevoegen - Bedrijfsgegevens (KvK, BTW-nummer) - Factuurnummering (bijv. VG-2025-001)

Note: Gebruiker is grafisch ontwerper, dus nadruk op mooie vormgeving.

Problemen en Oplossingen¶

Probleem 1: Mollie plugin niet zichtbaar¶

Symptoom: Bij nieuwe payment gateway aanmaken was Mollie niet beschikbaar in Plugin dropdown, ondanks dat commerce_mollie enabled was.

Oorzaak: Plugin cache niet vernieuwd na module installatie.

Oplossing: ddrush cr uitgevoerd - daarna verscheen Mollie in dropdown.

Probleem 2: Eerste gateway verkeerd aangemaakt¶

Situatie: Gebruiker had eerst gateway aangemaakt zonder Plugin te selecteren (velden invullen zonder plugin keuze).

Oplossing: Eerste gateway verwijderd, nieuwe aangemaakt met correcte volgorde: 1. Eerst Plugin selecteren (Mollie) 2. Dan naam en configuratie invullen

Nog Te Doen¶

Hoge prioriteit (morgen):¶

Mollie API keys toevoegen (Test mode)
Test checkout uitvoeren: product → cart → checkout → betaling (test transactie)
Entity Print configureren (PDF engine bevestigen)
Commerce Invoice instellingen: /admin/commerce/config/invoices
Factuurnummering instellen
Bedrijfsgegevens configureren
Logo uploaden
Factuur template vormgeven (CSS + Twig)
Test factuur genereren en downloaden via user account

Toekomstige taken:¶

SMTP configureren voor productie emails
Email templates aanpassen (order confirmation, factuur email)
Live Mollie API keys toevoegen
Test volledige flow van product aankoop tot factuur ontvangst
WeFact sync overwegen voor boekhoud-integratie (optioneel)

Status¶

Checkout flow: Volledig geconfigureerd (tot aan betaling)
Payment gateway: Aangemaakt, wacht op API keys
Facturatie: Modules geïnstalleerd, configuratie volgende stap
Email: Symfony Mailer geïnstalleerd, configuratie volgende stap

Klaar voor: API keys toevoegen en eerste test checkout uitvoeren

Technische Details¶

Modules geïnstalleerd (vandaag):¶

commerce_invoice 2.2.0
entity_print 2.18.0
symfony_mailer 1.6.2
mailer_transport 1.6.2 (dependency)
commerce_mollie 8.x-1.12

Dependencies geïnstalleerd:¶

dompdf/dompdf 3.1.4
dompdf/php-font-lib 1.0.1
dompdf/php-svg-lib 1.0.0
sabberworm/php-css-parser v8.9.0
symfony/css-selector v7.3.0
tijsverkoyen/css-to-inline-styles v2.3.0
html2text/html2text 4.3.2

Configuratie paden:¶

Order types: /admin/commerce/config/order-types
Checkout flows: /admin/commerce/config/checkout-flows
Payment gateways: /admin/commerce/config/payment-gateways
Entity Print: /admin/config/content/entity-print
Commerce Invoice: /admin/commerce/config/invoices
Symfony Mailer: /admin/config/system/mailer

Drush commands gebruikt:¶

# Module installatie
composer require drupal/commerce_invoice drupal/entity_print drupal/symfony_mailer
ddrush en commerce_invoice entity_print symfony_mailer -y

# Mollie installatie
composer require drupal/commerce_mollie
ddrush en commerce_mollie -y

# Cache clear (voor plugin detection)
ddrush cr

Belangrijke Overwegingen¶

Checkout filosofie:¶

Verplicht inloggen past bij medische uitgeverij (juridisch + consistent)
Simpele flow: minder velden = hogere conversie
Alleen vragen wat nodig is (email niet dubbel vragen)

Betaling:¶

Direct capture voor digitale content (geen reden om uit te stellen)
Mollie als enige provider voorlopig (meeste Nederlandse betaalmethoden)
Test mode eerst, live pas na grondige testing

Facturatie:¶

Drupal-native = betere UX (download via account)
dompdf voldoende voor mooie facturen
Vormgeving belangrijk (gebruiker is designer)
WeFact sync mogelijk later toevoegen zonder systeem aan te passen

Email strategie:¶

Symfony Mailer = moderne standaard
Order confirmation + factuur beide via Drupal
SMTP configuratie pas na succesvolle test flow

Volgende sessie: API keys toevoegen, checkout testen, facturen vormgeven