Waarom ASD Tunnel echte Mollie payment testing mogelijk maakt in CI

Als je ooit een end-to-end test hebt geschreven voor een payment provider zoals Mollie, dan ben je waarschijnlijk tegen hetzelfde probleem aangelopen als wij: de webhook. Je test kan een betaling aanmaken, je test kan door de Mollie checkout klikken in een headless browser, maar daarna moet Mollie jouw backend kunnen bereiken om te zeggen: “de betaling is gelukt.”

En Mollie kan simpelweg geen http://localhost bereiken.

Dit is geen specifiek Mollie-probleem — elke payment provider werkt zo. Zonder een publiek bereikbare endpoint kun je de volledige flow niet testen.

Wat de meeste teams doen

De meeste projecten kiezen één van deze oplossingen:

• Webhooks mocken door zelf een POST te doen naar hun handler

• Werken met een staging omgeving

• Externe tunnel tools gebruiken tijdens development

Mocking is snel, maar je test alleen je eigen code. Niet of:

• Mollie je endpoint écht kan bereiken

• Je proxy / routing correct staat

• De volledige pipeline werkt

Je test componenten, niet het systeem.

Onze drie-lagen teststrategie

Wij wilden snelheid én realisme. Daarom hebben we onze tests opgesplitst:

1. One-time payment (local)
   API-only: create-payment call, DB check, en een gesimuleerde webhook.

2. Subscription (local)
   Zelfde aanpak voor subscriptions, inclusief gekoppelde data.

3. Volledige Mollie checkout (CI + tunnel)
   De echte flow. Playwright doorloopt de Mollie checkout, en daarna wacht de test tot Mollie zelf de webhook terugstuurt.

De test pollt de database tot orders.status = 'paid'.

Waarom een tunnel nodig is in CI

GitHub runners zijn:

• Niet publiek bereikbaar

• Hebben geen open poorten

• Zijn volledig ephemeral

Dus zonder publieke endpoint kan Mollie geen webhook sturen.

Een tunnel lost dat op door tijdelijk een publieke HTTPS endpoint te maken die naar je CI omgeving routed.

Wat ASD Tunnel doet

Met vier regels:

asd init --yes
asd caddy start
asd net apply --seed --caddy --tunnel

krijg je een tijdelijke publieke URL die:

• via Caddy (TLS + auth) loopt

• naar je lokale Supabase functies routed

• direct bruikbaar is als webhookUrl

Voor Mollie ziet dit eruit als een normale productie endpoint.

De volledige flow

Playwright → Mollie checkout → Mollie servers → ASD tunnel
→ Caddy → Supabase → database update → test assertion

Alles is echt:

• echte browser

• echte Mollie API

• echte webhook delivery

• echte database mutatie

Geen mocks. Geen staging.

Waarom dit belangrijk is

Dit geeft je:

• Echte end-to-end verificatie

• Detectie van integratie changes

• Inzicht in test-mode edge cases

• Exact dezelfde setup lokaal en in CI

• Geen staging omgeving nodig

Wat hier écht anders is

Tunnels bestaan al (ngrok, Cloudflare, etc.).

Het verschil zit in hoe dit gebruikt wordt:

• Draait binnen GitHub runners

• Volledig ephemeral

• Geen extra accounts of setup

• Geïntegreerd in dezelfde CLI als je dev stack

Daardoor kun je dit op elke PR draaien.

Boilerplate (Angular + Supabase)

Alles wat hierboven beschreven is zit direct in de ASD boilerplate:

https://github.com/asd-engineering/asd-angular-supabase

Speciaal voor Angular developers, met:

• Playwright E2E setup

• Supabase edge functions

• ASD CLI integratie

• Veilige defaults

Andere frameworks volgen binnenkort.

Conclusie

Het probleem is niet “payments testen”.

Het probleem is systemen testen die afhankelijk zijn van inbound webhooks in omgevingen die niet publiek bereikbaar zijn.

ASD Tunnel maakt dat probleem niet nieuw — maar wél praktisch oplosbaar in CI.