Mollie
Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.
Capabilities
| Error decoding | limited |
| API response parsing | supported |
| Webhook / notification parsing | limited |
| Timeline | limited |
| Event correlation | supported |
| Diagnostic rules | limited |
Supported input
| Format | Description | Status |
|---|---|---|
mollie.payment | Payments API v2 payment objects (resource: payment), as returned by GET /v2/payments/{id} | supported |
mollie.refund | Refund objects (resource: refund) | supported |
mollie.chargeback | Chargeback objects (resource: chargeback) | supported |
mollie.capture | Capture objects (resource: capture) | supported |
mollie.error | Payments API v2 error responses (status, title, detail, field, _links.documentation) | limited |
mollie.event | Next-gen webhook events with the full payload (resource: event, _embedded.entity) | experimental |
mollie.event.simple | Next-gen webhook events with the simple payload (no embedded entity) | unsupported |
mollie.webhook.classic | Classic webhooks (form-encoded id=<resource id>, nothing else) | unsupported |
mollie.orders | Orders API v2 objects (no longer recommended by Mollie) | unsupported |
Notification delivery
- Repeated deliveries are recognized by event id (next-gen webhooks).
- Delivery order: not documented by the provider.
- Mollie retries a webhook until it receives 200 OK within 15 seconds (up to 10 attempts over 26 hours), so a slow handler can receive the same event again. Record processed event ids and always fetch the current object before acting.
Known limitations
- Classic webhooks (form-encoded id=tr_...) carry only an identifier: no status, amount, time or signature. They are recognized but not analyzed; paste the GET /v2/payments/{id} response for that id instead.
- Next-gen simple payloads carry no entity and are recognized but not analyzed. Full payloads are experimental: Mollie publishes no complete payment event envelope example, many event types are beta, and Mollie still recommends classic webhooks for payments.
- Mollie API errors have no machine-readable error code. They are classified by HTTP status and field only; detail is free text and not used for classification, so 422 account suspension and 400 idempotency-key misuse cannot be told apart from other 422 and 400 errors.
- details.failureReason is card-only and optional (the documented failed-payment example has none). Its 15 values are documented without descriptions, so explanations are derived from the code names.
- statusReason (point-of-sale), SEPA bankReasonCode and chargeback reason codes are not decoded.
- A payment object is a snapshot, not an event log. Timeline points come only from timestamps present on it (createdAt, authorizedAt, paidAt, canceledAt, expiredAt, failedAt) and are labeled as derived from the snapshot. A pending status is never timestamped; expiresAt and captureBefore are deadlines, not events.
- Lifecycle points derived from snapshots are not deliveries. When several snapshots are supplied, the generic out-of-order rule can still report them as arriving out of order (with possible confidence only).
- Refunds and captures only have createdAt, so the time of their status changes is not available. Chargebacks have no status; received and reversed are taken from createdAt and reversedAt.
- Embedded refunds, chargebacks and captures (?embed=...) are read defensively because the shape of _embedded is not documented in the payment response schema.
- Mollie does not state explicitly that a retried next-gen delivery reuses the event id; PandaPayLens uses the event id as the delivery key. Snapshots have no delivery key.
- Signature headers (X-Mollie-Signature) cannot be verified without the signing secret; only their presence is reported.
- Orders API objects, API v1 payloads and HAL list responses are not analyzed.
- Provider-specific diagnostic rules (state inconsistency, retry risk) do not cover Mollie yet; only the generic rules apply.
Examples
- Mollie: failed payment: A payment snapshot with status failed and a failureReason.
- Mollie: authorized, captured and refunded: Payment, capture and refund objects linked by their ids.
- Mollie: classic webhook (id only): A classic webhook carries only the payment id. PandaPayLens explains what else is needed.
Provider documentation
- Handling errors
- Extra payment parameters (details.failureReason)
- Handling payment status
- Get payment
- Webhooks
- Next-gen webhooks
- Refunds
- API idempotency
PandaPayLens is not affiliated with Mollie. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.