Mollie's webhook sends
the payment ID. Nothing else.
You fetch the rest.

It is a deliberate design choice. Mollie sends a minimal webhook — just the payment ID — to prevent sensitive payment data from being exposed in webhook payloads that might be logged or intercepted. You are expected to fetch the full payment object from the API after receiving the webhook. This also means the webhook body is always correct: Mollie can't accidentally send stale data because it sends no data at all.

When you create a Mollie payment, the response includes _links.checkout.href. This is the URL you redirect the customer to. For iDEAL, it shows a bank selector. For cards, it shows a card form. For other methods, it shows the appropriate payment UI. After the customer completes or abandons the payment, Mollie redirects them to your redirectUrl. Then Mollie sends a webhook to your webhookUrl. Always redirect to _links.checkout.href — never build your own checkout UI for Mollie methods.

Yes. iDEAL is only available for Dutch locale (nl_NL) and Dutch customers. Bancontact requires Belgian locale. Giropay and EPS are German and Austrian respectively. Mollie uses locale to determine which methods to show in the checkout and whether the method is applicable. If you want to offer specific regional methods, set locale to match the customer's country. The mock accepts any locale string.

Mollie uses decimal strings, not integers. Pass amount as an object with a string value: { value: '49.99', currency: 'EUR' }. This is different from Stripe and Square, which use integer cents. The value must have exactly the number of decimal places for the currency — EUR needs two, JPY needs zero. Passing '49.9' instead of '49.90' will cause a validation error in the real API.

Mollie retries. It will attempt delivery multiple times over several hours with increasing delays. If all retries fail, the webhook is dropped. Your integration should always respond with HTTP 200 within a few seconds — if your handler is slow, respond immediately and process asynchronously. To catch missed webhooks, also call GET /payments/{id} when the customer returns to your redirectUrl, as a fallback status check.