Everything an AI agent can do with the Mollie API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints34
API versionv2
Last updated23 June 2026
Orientation

How the Mollie API works.

The Mollie API is how an app or AI agent works with a Mollie account: taking a payment, refunding a charge, creating a customer, or running recurring billing through mandates and subscriptions. Access is granted through a Bearer credential, an API key, an organization access token, or an OAuth grant, and OAuth carries per-area scopes that set which resources a call can read or write. When something changes, Mollie posts only the object's id to a registered address, so the receiver fetches the current state rather than trusting the message.

34Endpoints
10Capability groups
18Read
16Write
15Permissions
Authentication
Mollie authenticates a call with a Bearer credential, in one of three forms. A profile API key (test_ or live_) gives full access to one profile; an organization access token (access_) reaches organization-level resources and is what the MCP server uses; and OAuth grants a connected organization's consent scoped to specific permissions. Every credential belongs to one mode, either test or live.
Permissions
OAuth access is scoped per area, with read and write split, like payments.read, payments.write, refunds.write, and customers.read. An app requests only the scopes it needs, and a token reaches nothing else; a 403 means the scope is missing. When no scopes are requested, the grant defaults to organizations.read alone. An API key, by contrast, carries full access for its profile.
Versioning
Mollie runs a single current API version, v2, and ships dated changes through release notes rather than minting a new version string each time. The older v1 is legacy, and the Orders API is no longer recommended, with the Payments API the path for new work, though some pay-later methods like Klarna and Billie still require Orders.
Data model
Mollie is a REST API with JSON requests and HAL+JSON responses, where _links carry related resources and the next page. A payment is the core object and returns a checkout URL to send the customer to. Recurring billing combines customers, mandates, and subscriptions. A POST can carry an Idempotency-Key so a retried write is not processed twice, and lists are cursor-paginated.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Mollie determines what it can reach. There is a route for making calls, a route for receiving events, and a hosted server that exposes Mollie tools to agents, and each is governed by the credential behind it and the permissions that credential carries.

Ways to connect

REST API

The REST API takes JSON request bodies, returns HAL+JSON, and pages through lists with a cursor, at https://api.mollie.com/v2. A call authenticates with a Bearer credential: a profile API key, an organization access token, or an OAuth access token. The older v1 is legacy, and the Orders API is no longer recommended for new work.

Best forConnecting an app or AI agent to Mollie.
Governed byThe credential and the permissions it carries.
Docs ↗

MCP server

A first-party hosted Model Context Protocol server at https://mcp.mollie.com/mcp acts as a proxy for the public API, exposing Mollie tools to AI clients like Claude and Cursor. It authenticates with an organization access token passed as the MOLLIE_API_OAUTH_ORG_TOKEN environment variable, where profiles.read is required and the token's other scopes decide which tools work. It covers the Payments, Payment Links, Refunds, Captures, Customers, Mandates, Subscriptions, Methods, Settlements, Invoices, Balances, Terminals, and Webhooks APIs.

Best forConnecting an AI agent to Mollie through MCP.
Governed byThe organization access token and the scopes it carries.
Docs ↗

Webhooks

Mollie POSTs to a webhookUrl set on a payment, subscription, or payment link when its status changes. The body is form-encoded and carries only the object's id, like id=tr_..., so the receiver fetches the current state and never trusts the request itself. The endpoint must return HTTP 200, or Mollie retries up to 10 times over about 26 hours.

Best forReceiving Mollie status changes at an app or AI agent.
Governed byThe credential used to fetch the object the webhook names.
Docs ↗
Authentication

API key

An API key authenticates a single profile and is sent as a Bearer token. A test key (test_...) operates on simulated data where no money moves, and a live key (live_...) processes real payments. A key carries full access for its profile, so it is not scoped per resource the way OAuth is.

TokenBearer API key (test_... / live_...)
Best forServer-side calls for a single account's own profile.
Docs ↗

Organization access token

An organization (advanced) access token reaches organization-level resources across profiles, sent as a Bearer token. It is shown only once, at creation, and can be limited to specific profiles or to test or live mode. The Mollie MCP server uses this token type.

TokenBearer access token (access_...)
Best forOrganization-wide server access and the MCP server.
Docs ↗

OAuth 2.0

OAuth lets an app call Mollie on behalf of another organization that grants consent, through Mollie Connect. The app requests a subset of scopes, like payments.read, payments.write, refunds.write, or customers.read, and the access token reaches only what those scopes allow. When no scopes are requested, the grant defaults to organizations.read alone.

TokenOAuth access token tied to a connected organization
Best forPlatforms acting for organizations they don't own.
Docs ↗
Capability map

What an AI agent can do in Mollie.

The Mollie API is split into areas an agent can act on, like payments, refunds, customers, subscriptions, and settlements. Each area has its own methods, and writes in some areas move real money or change recurring billing.

Payments

5 endpoints

Methods for creating and managing payments, the core of the Mollie API.

A write here takes, changes, or cancels a real payment.
View endpoints

Refunds

4 endpoints

Methods for refunding payments, fully or in part.

A write here returns real money to a customer.
View endpoints

Customers

5 endpoints

Methods for working with customer records.

A write here changes or deletes a real customer record.
View endpoints

Subscriptions

4 endpoints

Methods for recurring billing on a customer.

A write here starts, changes, or stops recurring charges.
View endpoints

Mandates

3 endpoints

Methods for the recurring-payment authorizations behind subscriptions.

A write here creates or revokes permission to charge a customer.
View endpoints

Orders (legacy)

3 endpoints

Methods for the older Orders API, still required by some pay-later methods.

A write here changes a real order; Mollie now recommends the Payments API instead.
View endpoints

Methods

3 endpoints

Methods for listing and configuring the payment methods a profile offers.

A write here enables or disables a real payment method on a profile.
View endpoints

Settlements

2 endpoints

Methods for the payouts Mollie makes to a merchant's bank account.

Read-only; exposes settlement and payout figures.
View endpoints

Chargebacks

2 endpoints

Methods for reading chargebacks raised against payments.

Read-only; exposes disputed-payment data.
View endpoints

Balances

3 endpoints

Methods for reading account balances and their transactions.

Read-only; exposes current and historical balance figures.
View endpoints
Endpoint reference

Every Mollie API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Payments

Methods for creating and managing payments, the core of the Mollie API.5

A core write. The webhookUrl set here is where Mollie posts status changes.

Acts onpayment
Permission (capability)payments.write
VersionAvailable since the API’s base version
Webhook eventpayment.paid
Rate limitStandard limits apply

Read-only. This is the call a webhook receiver makes to learn the real status.

Acts onpayment
Permission (capability)payments.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onpayment
Permission (capability)payments.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Only certain fields can change, and only while the payment is open.

Acts onpayment
Permission (capability)payments.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Only works while the payment's isCancelable flag is true.

Acts onpayment
Permission (capability)payments.write
VersionAvailable since the API’s base version
Webhook eventpayment.canceled
Rate limitStandard limits apply

Refunds

Methods for refunding payments, fully or in part.4

Moves real money. Only payments with a positive amountRemaining can be refunded.

Acts onrefund
Permission (capability)refunds.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onrefund
Permission (capability)refunds.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onrefund
Permission (capability)refunds.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Only queued refunds can be canceled, before they are paid out.

Acts onrefund
Permission (capability)refunds.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Customers

Methods for working with customer records.5

A core write for recurring billing.

Acts oncustomer
Permission (capability)customers.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts oncustomer
Permission (capability)customers.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts oncustomer
Permission (capability)customers.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A core write.

Acts oncustomer
Permission (capability)customers.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Irreversible; the customer and its stored details are removed.

Acts oncustomer
Permission (capability)customers.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Subscriptions

Methods for recurring billing on a customer.4

Requires an existing mandate; each generated charge calls the subscription's webhookUrl.

Acts onsubscription
Permission (capability)subscriptions.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onsubscription
Permission (capability)subscriptions.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Changes future charges for an active subscription.

Acts onsubscription
Permission (capability)subscriptions.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Stops recurring charges; existing payments are unaffected.

Acts onsubscription
Permission (capability)subscriptions.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Mandates

Methods for the recurring-payment authorizations behind subscriptions.3

Records consent to charge; a subscription needs a valid mandate to run.

Acts onmandate
Permission (capability)mandates.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onmandate
Permission (capability)mandates.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Subscriptions relying on the mandate can no longer charge.

Acts onmandate
Permission (capability)mandates.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Orders (legacy)

Methods for the older Orders API, still required by some pay-later methods.3

Mollie no longer recommends the Orders API; use Payments unless a method like Klarna or Billie requires it.

Acts onorder
Permission (capability)orders.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onorder
Permission (capability)orders.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Only cancelable orders can be canceled.

Acts onorder
Permission (capability)orders.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Methods

Methods for listing and configuring the payment methods a profile offers.3

Read-only; used to render available methods at checkout.

Acts onmethod
Permission (capability)payments.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onmethod
Permission (capability)payments.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Configures which methods a profile offers; governed by the profiles scope.

Acts onmethod
Permission (capability)profiles.write
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Settlements

Methods for the payouts Mollie makes to a merchant's bank account.2

Read-only.

Acts onsettlement
Permission (capability)settlements.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onsettlement
Permission (capability)settlements.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Chargebacks

Methods for reading chargebacks raised against payments.2

Read-only; chargebacks are read through the payments scope.

Acts onchargeback
Permission (capability)payments.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onchargeback
Permission (capability)payments.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Balances

Methods for reading account balances and their transactions.3

Read-only.

Acts onbalance
Permission (capability)balances.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onbalance
Permission (capability)balances.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onbalance_transaction
Permission (capability)balances.read
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Mollie can notify an app when something changes, like a payment being paid or a subscription generating its next charge. It sends only the object's id, so the receiver fetches the current state rather than trusting the request, and learns about activity without polling.

EventWhat it signalsTriggered by
payment status change (paid)A payment reached a final state such as paid. Mollie posts the payment id to the webhookUrl set on the payment, and the receiver fetches the payment to read the real status./v2/payments
payment status change (canceled)A payment was canceled. Mollie posts the payment id to the payment's webhookUrl, and the receiver fetches the payment to confirm./v2/payments/{id}
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Mollie limits how fast an app can call to protect the API, and pages through long lists with a cursor rather than a page number.

Request rate

Mollie limits how fast the API can be called to protect it, and recommends exponential back-off when retrying so a client does not flood the API. Going over returns HTTP 429 with a Retry-After header that says how long to wait before trying again. Mollie does not publish a fixed request-per-second figure in its public reference.

Pagination

A v2 list endpoint uses cursor pagination, so objects in a page do not shift when new ones are created. The limit parameter sets the page size up to a maximum of 250, from takes the id of an object to start from, and sort is asc or desc with desc (newest first) the default. The response carries a _links.next href to fetch the following page until there are no more.

Request size

A list returns at most 250 objects per page, the maximum value of limit. An Idempotency-Key is cached for one hour, after which the same key counts as a new request.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
400Bad RequestThe request could not be understood, usually a syntax problem in the body or parameters.Read the title and detail in the response, fix the request, and resend.
401UnauthorizedAuthentication failed, for example a missing, malformed, or wrong-mode credential.Check the Bearer credential and that it matches the mode (test or live) being used.
403ForbiddenThe credential is valid but lacks access to the requested resource, for example an OAuth token missing the needed scope.Grant the required scope, or use a credential with access to the resource.
404Not FoundThe referenced object does not exist, or is not visible to this credential or mode.Verify the id and that it lives in the same account and mode.
422Unprocessable EntityThe request was well formed but could not be processed, like an invalid value. The response may include a field property naming the offending input.Read the field and detail, correct that input, and resend.
429Too Many RequestsThe rate limit was reached.Read the Retry-After header and back off with exponential delay before retrying.
503Service UnavailableThe service is temporarily unavailable on Mollie's side.Retry later with backoff; if it persists, contact Mollie support.
Versioning & freshness

Version history.

Mollie runs a single current version of its API, v2, and ships dated changes through release notes rather than minting a new version string for each one.

Version history

What changed, and when

Latest versionv2
v2Current version
Current API version

Mollie runs a single current API version, v2, with JSON requests and HAL+JSON responses. New capability ships through dated release notes rather than a new version string, and the older v1 is legacy.

What changed
  • Cursor pagination with a maximum page size of 250.
  • Idempotency-Key support on all POST endpoints, cached for one hour.
  • Orders API is no longer recommended; the Payments API is the path for new work.
2025-07-29Feature update
Mollie MCP server launched

Mollie released a first-party hosted Model Context Protocol server so merchants can drive their account from AI clients in natural language. It proxies the public API and authenticates with an organization access token.

What changed
  • Hosted MCP server at mcp.mollie.com/mcp.
  • Covers Payments, Payment Links, Refunds, Captures, Customers, Mandates, Subscriptions, Methods, Settlements, Invoices, Balances, Terminals, and Webhooks APIs.
  • Works with Claude Desktop, Cursor, and other MCP clients.
Earlier
Next-gen webhooks (beta) and ongoing additions

Mollie continues to extend v2, including a next-generation webhooks model in beta with new event types and flexible delivery, alongside the original per-object webhookUrl model.

What changed
  • Next-gen webhooks beta with new event types and Webhook Event pages.
  • Saving cards during checkout via the Payments API for one-click reuse.
  • Embedded payment components for an on-page checkout.

Build against v2; the older v1 is legacy and the Orders API is no longer recommended for new work.

Mollie changelog ↗
Questions

Mollie API, answered.

What is the difference between test and live API keys?+
A Mollie credential belongs to one mode. A test key (test_...) operates on simulated data where no real money moves, useful for development, while a live key (live_...) processes real payments. Objects do not cross modes, and an organization access token can likewise be limited to test or live.
How do webhooks work, and why does Mollie only send an id?+
When a payment, subscription, or payment link changes status, Mollie POSTs to the webhookUrl set on it with a form-encoded body containing only the object id, like id=tr_.... The status is deliberately not in the request, so the receiver fetches the object to read the real state and cannot be fooled by a spoofed payload. The endpoint should return HTTP 200, or Mollie retries up to 10 times over about 26 hours.
How do I make a request safe to retry (idempotency)?+
A POST can carry an Idempotency-Key header set to a unique value, such as a UUID. If the same key arrives again within one hour, Mollie returns the cached first response and marks it with Idempotent-Replayed: true, so a retry after a network blip will not create a duplicate. Keys older than an hour are discarded. GET, PATCH, and DELETE are repeatable by nature and do not need a key.
How does pagination work on list endpoints?+
Mollie v2 lists use cursor pagination, which keeps a page stable as new objects are created. The limit parameter sets the page size up to 250, from takes the id of an object to start from, and sort is asc or desc with desc as the default. Each response includes a _links.next href to follow for the next page until there are no more results.
Should I use the Orders API or the Payments API?+
The Payments API is the recommended path for new work. Mollie no longer recommends the Orders API, though some pay-later methods such as Klarna Pay later, Klarna Slice it, and Billie still require it. Existing Orders integrations can follow Mollie's migration guide to move to Payments.
What OAuth scopes does Mollie support?+
OAuth scopes are split by area and by read versus write, including payments.read and payments.write, refunds.read and refunds.write, customers.read and customers.write, mandates, subscriptions, orders, shipments, payment-links, terminals, profiles, organizations, plus read-only invoices.read, settlements.read, and balances.read. An app requests only the subset it needs; when none are requested, the grant defaults to organizations.read alone.
Does Mollie offer an MCP server for AI agents?+
Yes. Mollie runs a first-party hosted Model Context Protocol server at mcp.mollie.com/mcp that proxies the public API for AI clients like Claude and Cursor. It uses an organization access token passed as MOLLIE_API_OAUTH_ORG_TOKEN, where profiles.read is required and the token's other scopes decide which tools work, covering APIs from Payments and Refunds to Customers, Subscriptions, Settlements, and Balances.
Related

More finance API guides for agents

What is Bollard AI?

Control what every AI agent can do in Mollie.

Bollard AI sits between a team's AI agents and Mollie. Grant each agent exactly the access it needs, read or write, resource by resource, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Mollie key.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Mollie
Payments Agent
View payments ResourceOffReadFull use
Issue refunds ActionOffReadFull use
Customers ResourceOffReadFull use
Settlements ResourceOffReadFull use
Per-agent access, set in Bollard AI, not in Mollie