Mollie Integration Penetration Testing

Mollie’s advanced access tokens are scoped to specific permissions across payments, refunds and webhooks, and only an account Admin can create one. We test which tokens exist, what permissions each one actually holds, and whether that still matches what the integration does.

Why Mollie findings sit in your tokens and your webhook handler, not the API

Mollie offers four ways to authenticate: a standard API key tied to a single payment profile, an advanced access token that can be scoped to specific permissions and, optionally, a specific profile or mode, an OAuth app access token for acting on behalf of a connected merchant, and Basic Auth using the OAuth client ID and secret to generate or revoke tokens. Only a user with the Admin role can create an advanced access token, so we test whether that restriction is enforced consistently and whether any token in use holds more permission than the integration needs.

Mollie’s webhook design deliberately sends only the ID of the updated object, for example a payment ID, never its new status, precisely so a forged call to your webhook URL cannot mark an order as paid on its own. That means the security of the flow depends entirely on your endpoint actually calling back into the Mollie API to fetch the real status before it acts. We test whether it does that every time, and how it behaves when Mollie retries the same call, which it does up to ten times over 26 hours if your endpoint does not return a 200.

Where a business is itself a platform using Mollie Connect, an OAuth app access token lets it act on behalf of connected merchant accounts once they have granted consent. We test what scope was actually granted against what the integration uses, how a connected account’s tokens are stored, and whether a revoked or expired authorisation is still honoured anywhere in the code.