Ellipse Gradient for Header

Mollie Integration Guide

Integrate Mollie with enterprise systems through its REST API, payment webhooks, bearer authentication, and scheduled reconciliation workflows.

Mollie integration options at a glance

Mollie’s primary integration model is a versioned REST API over HTTPS for Payments, Customers, Mandates, Subscriptions, Orders, Refunds, Profiles, Settlements, Balances, and related resources. Mollie also supports webhook-style callbacks, particularly for Payment status changes. Martini can consume these APIs, receive callbacks through a Martini API or workflow trigger, and map Mollie JSON into commerce, ERP, CRM, billing, or internal database schemas. API keys support account-level integrations, while OAuth 2.0 supports delegated access to Mollie organizations. Scheduled workflows can paginate through resources and reconcile missed notifications; a general Mollie bulk API, file exchange interface, GraphQL API, or SOAP API was not confirmed.

Integration pointSupported by Mollie?Common use casesHow Martini supports it
REST APIsYesMollie’s primary interface supports Payments, Customers, Mandates, Subscriptions, Orders, Refunds, Profiles, Settlements, Balances, and related resources. It is used for payment creation, status retrieval, refunds, recurring-payment management, and reconciliation.Martini can consume Mollie REST endpoints from workflows, map JSON responses, apply business rules, and expose APIs that abstract Mollie operations for other applications.
Webhooks / outbound callbacksLimitedMollie supports webhook-style notifications, especially when Payment status changes. Coverage is resource- and event-dependent rather than a universal event stream.Martini can expose an API endpoint or use a webhook-triggered workflow, retrieve the current Mollie resource, and process notifications idempotently.
AuthenticationYesMollie supports bearer authentication with test and live API keys. OAuth 2.0 is available for applications accessing Mollie organizations on behalf of users or merchants.Martini can store keys, OAuth client credentials, access tokens, and refresh tokens in secure environment configuration and use separate test and live settings.
Scheduled synchronizationYesPeriodic reconciliation is appropriate for missed or delayed webhook notifications, settlement retrieval, resource synchronization, and recovery of failed processing.Martini can schedule workflows, paginate through collections, persist checkpoints, and route exceptions for retry or operational review.
Pagination and incremental retrievalYesMollie collection endpoints use pagination parameters and response links. Incremental synchronization can use available timestamps, status filters, pagination, and periodic reconciliation.Martini workflows can follow next-page links, checkpoint successful progress, throttle requests, and resume after an interruption.
Bulk / async / batch APIsNot confirmedMollie payments may complete asynchronously, but a general-purpose bulk or batch API was not confirmed. Large transfers should use paginated REST requests.Martini can orchestrate controlled concurrency, retries, checkpointing, and scheduled batches without representing this as a Mollie bulk API.
File / attachment APIsNot confirmedMollie’s documented integration model is JSON over REST. A general file-import, file-export, or attachment API was not confirmed.Martini should exchange transaction data through Mollie REST resources; file workflows should only be used for other systems in the surrounding architecture.
GraphQL APIsNot confirmedNo official Mollie GraphQL API was confirmed in the reviewed material.Martini integrations should use Mollie REST APIs rather than assume GraphQL support.
SOAP APIsNot confirmedNo official Mollie SOAP API was confirmed in the reviewed material.Martini integrations should use Mollie REST APIs and documented webhook callbacks instead of SOAP.

How Mollie exposes data and business events

Mollie REST APIs

Mollie’s versioned REST API is the principal integration mechanism for Payments, Customers, Mandates, Subscriptions, Orders, Refunds, Profiles, Settlements, Balances, and related resources. It supports both transactional operations and retrieval for reconciliation.

Martini implementation pattern

Martini implementation pattern: a workflow or API receives an application request, authenticates to Mollie with an API key or OAuth bearer token, calls the relevant REST resource, validates the response, maps Mollie JSON into a canonical or target schema, and records correlation identifiers for later updates.

Implementation sequence

Receive an API request or scheduled synchronization trigger
Authenticate to Mollie with the configured bearer credential
Call the relevant Mollie REST resource
Follow pagination links when processing collections
Validate the response and apply business rules
Map Mollie JSON to the target application schema','Write the result and store the Mollie,-

Mollie Payment webhooks

Mollie supports webhook-style callbacks, most notably when a Payment changes status. The callback should be treated as a notification that the resource may have changed, not necessarily as the complete payment record.

Martini implementation pattern

Martini implementation pattern: expose a Martini API or webhook-triggered workflow, accept the Payment identifier, retrieve the current Payment from Mollie, evaluate its status, and update the downstream order or invoice exactly once. Scheduled reconciliation complements webhook processing.

Implementation sequence

Receive the Mollie webhook notification
Extract the referenced Payment identifier
Retrieve the current Payment from Mollie
Check the idempotency key and prior processing state
Evaluate the current Mollie payment status
Map the status to the downstream order or invoice state','Persist the result and return a-

Mollie scheduled reconciliation

Mollie does not appear to provide a general change-data-capture stream for all resources. Scheduled retrieval is therefore useful for missed notifications, unsettled activity, refunds, subscriptions, settlements, and balance comparisons.

Martini implementation pattern

Martini implementation pattern: schedule a workflow that retrieves resource collections using pagination, filters or timestamps where available, compares Mollie data with the target system, and records a checkpoint after successful processing. Failures are retried without discarding the last confirmed checkpoint.

Implementation sequence

Start the scheduled reconciliation workflow
Load the last successful checkpoint
Retrieve the next Mollie collection page
Transform and compare the returned resources
Apply only new or changed business records
Write updates to the target system','Store the new checkpoint and report exceptions-

Common Mollie integration patterns

Pattern 1: Synchronize Mollie payment statuses

When to use this pattern

Use this pattern when an order, invoice, or commerce platform must reflect payment progress quickly while remaining resilient to duplicate or incomplete notifications. Mollie sends a webhook-style notification, and the authoritative Payment is then retrieved from Mollie.

Integration direction
Mollie
Martini
Shopify
Example Mapping
Mollie FieldCanonical FieldTarget Field
idpayment.externalIdtransactionId
statuspayment.statusfinancialStatus
amount.valuepayment.amounttotalAmount
amount.currencypayment.currencycurrency
Martini implementation pattern

Martini receives the notification, retrieves the current Payment, maps Mollie statuses to the target order state, and applies rules such as allowing fulfillment only for an approved paid state. A stored payment identifier and business key make the workflow idempotent; transient failures are retried and unresolved cases are reconciled later.

Martini capabilities used
  • webhook-triggered workflows
  • API consumption
  • data mapping
  • business rules
  • idempotency
  • error handling

Pattern 2: Create Mollie payments for orders

When to use this pattern

Use this pattern when a commerce or order-management application needs to initiate Mollie checkout and receive a stable payment reference and checkout URL. The originating system remains responsible for the order while Mollie manages payment processing.

Integration direction
WooCommerce
Martini
Mollie
Example Mapping
Mollie FieldCanonical FieldTarget Field
orderNumberorder.idmetadata.orderNumber
totalorder.amount.valueamount.value
currencyorder.amount.currencyamount.currency
returnUrlpayment.returnUrlredirectUrl
Martini implementation pattern

A Martini API accepts the order request, validates amount and currency, maps the payload to a Mollie Payment or Order request, and returns the Mollie identifier and checkout URL. The workflow stores the correlation key before responding and prevents duplicate creation when the same order request is retried.

Martini capabilities used
  • API exposure
  • API consumption
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 3: Orchestrate Mollie refunds

When to use this pattern

Use this pattern when customer service, commerce, or finance users request full or partial refunds and the result must be reflected consistently across Mollie and downstream accounting or order systems.

Integration direction
NetSuite
Martini
Mollie
Example Mapping
Mollie FieldCanonical FieldTarget Field
paymentIdrefund.paymentIdoriginalTransactionId
amount.valuerefund.amountrefundAmount
amount.currencyrefund.currencycurrency
descriptionrefund.reasonmemo
Martini implementation pattern

Martini validates the original Payment or Order, checks that the requested amount is within the refundable balance, creates the Mollie Refund, and maps the returned identifier to the target system. A refund request key and Mollie resource identifier prevent duplicate reversals; rejected requests are routed to an operational error path.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • validation
  • data transformation
  • business rules
  • retry handling

Pattern 4: Reconcile recurring payments and settlements

When to use this pattern

Use this pattern when an organization needs periodic alignment of Customers, Mandates, Subscriptions, Payments, Refunds, Settlements, or Balances with a billing, ERP, or internal database. It is particularly useful when webhook coverage does not include every required resource.

Integration direction
Mollie
Martini
NetSuite
Example Mapping
Mollie FieldCanonical FieldTarget Field
customerIdcustomer.externalIdcustomerId
subscription.statussubscription.statusrecurringBillingStatus
settlement.periodssettlement.periodaccountingPeriod
amount.valuetransaction.amountamount
Martini implementation pattern

A scheduled Martini workflow loads its checkpoint, retrieves paginated Mollie resources, maps and compares them with the ERP, and writes only new or changed records. It preserves currency and decimal values, throttles requests, retries transient failures, and reports mismatches for review.

Martini capabilities used
  • scheduled workflows
  • pagination
  • checkpointing
  • data mapping
  • database or API writes
  • monitoring
  • error handling

Applications commonly integrated with Mollie

Mollie can be integrated with commerce, finance, customer, and operational applications to coordinate payment initiation, status updates, refunds, reconciliation, and customer communications. The following are practical enterprise architecture targets; specific application capabilities and payment flows should be validated for each deployment.

Application Scenario Direction Martini Pattern
Shopify Synchronize Mollie payment outcomes with Shopify orders and checkout processes. Shopify → Martini → Mollie Martini receives payment requests from the commerce flow, maps order and amount data to Mollie, returns the Mollie identifier and checkout URL, and later processes Mollie payment notifications to update Shopify order status. Duplicate callbacks are handled using payment and order keys.
WooCommerce Process WooCommerce checkout payments through Mollie and return payment status to orders. WooCommerce → Martini → Mollie A Martini API or workflow accepts checkout data, creates the Mollie Payment, and persists the relationship between the WooCommerce order and Mollie payment. A webhook workflow retrieves the current Payment before applying the resulting status to the order.
Adobe Commerce Coordinate payment creation, order status, refunds, and reconciliation for commerce transactions. Adobe Commerce → Martini → Mollie Martini transforms Adobe Commerce order and customer data into Mollie requests, orchestrates refund validation and creation, and routes payment status updates back to the commerce platform. Retry and idempotency controls protect against duplicate writes.
Salesforce Make payment outcomes, refunds, and customer payment activity available to sales and service processes. Mollie → Martini → Salesforce Martini retrieves Mollie Payments, Refunds, Customers, or Subscriptions, maps them to Salesforce objects, and applies business rules for status updates and exception cases. Salesforce-originated refund requests can be validated and sent to Mollie through a Martini API.
NetSuite Reconcile Mollie Payments, Refunds, Settlements, and fees with invoices, customers, and accounting records. Mollie → Martini → NetSuite Scheduled Martini workflows retrieve paginated Mollie resources, convert monetary values without floating-point loss, and map them to NetSuite accounting structures. Checkpoints, reconciliation keys, and bounded retries support recoverable financial processing.
Microsoft Dynamics 365 Synchronize orders, customers, payment statuses, refunds, and settlement-related information. Mollie → Martini → Microsoft Dynamics 365 Martini consumes Mollie REST resources, transforms JSON into Dynamics 365 contracts, and routes payment and refund changes to the appropriate business process. An inbound API can accept payment or refund requests from Dynamics 365.
ServiceNow Create or update operational cases for failed payments, refunds, disputes, and integration exceptions. Mollie → Martini → ServiceNow A Martini webhook and reconciliation workflow identifies failed or delayed Mollie activity, enriches it with the current resource representation, and creates or updates ServiceNow cases. Idempotency keys prevent repeated notifications from creating duplicate cases.
Klaviyo Trigger customer communications based on payment, refund, customer, or subscription activity. Mollie → Martini → Klaviyo Martini retrieves or receives relevant Mollie changes, filters them through business rules, and maps approved customer and transaction attributes to Klaviyo events or profiles where the target implementation supports them. Sensitive payment details are excluded from outbound payloads.

How to build a Mollie integration in Martini

Objective

Configure Mollie access and the target application without mixing test and live environments.

Instructions in Martini

  • Store Mollie test or live API keys in Martini secrets and environment configuration.
  • Use OAuth 2.0 credentials and refresh-token handling when delegated organization access is required.
  • Configure target endpoints, merchant context, and webhook URLs separately for each environment.

Objective

Select the event-driven or scheduled entry point that matches the Mollie resource and business requirement.

Instructions in Martini

  • Use a Mollie webhook callback for selected Payment status changes.
  • Use an API-triggered workflow for payment, order, or refund requests from another application.
  • Use a scheduler for reconciliation, settlement retrieval, and recovery from missed notifications.

Objective

Obtain the authoritative Mollie resource and process collections safely.

Instructions in Martini

  • Treat webhook payloads as change notifications and retrieve the current Payment or referenced resource.
  • Follow Mollie pagination links until the collection is exhausted.
  • Persist a checkpoint or correlation key after successful processing.

Objective

Coordinate calls, validations, target writes, and exception paths in a Martini workflow.

Instructions in Martini

  • Sequence Mollie API calls and downstream operations in a workflow.
  • Branch on payment, refund, mandate, or subscription status.
  • Route transient failures to bounded retries and permanent failures to an operational error path.

Objective

Transform Mollie JSON and monetary values into stable target-system contracts.

Instructions in Martini

  • Map Mollie identifiers, statuses, amounts, currencies, customer data, and metadata to canonical fields.
  • Use decimal-safe handling for financial amounts.
  • Tolerate additive fields and validate required fields explicitly.

Objective

Protect business processes from invalid transitions, duplicate notifications, and duplicate writes.

Instructions in Martini

  • Store processed resource identifiers and business keys for idempotency.
  • Allow fulfillment, accounting, or communication actions only for approved status transitions.
  • Validate refund amounts against the original Payment or Order.

Common Mollie data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
PaymentsCreate, retrieve, and monitor payment transactions, including status, amount, currency, method, checkout URL, metadata, refunds, and settlement-related information.Shopify, WooCommerce, Adobe Commerce, NetSuite, Salesforce, Microsoft Dynamics 365, internal order databasesMartini retrieves the current Payment after notifications, maps monetary values and statuses, applies idempotency rules, and routes updates to downstream systems.
CustomersRepresent customers used for recurring payments, mandates, and customer-specific payment activity.Salesforce, Shopify, WooCommerce, NetSuite, Microsoft Dynamics 365, customer databasesMartini maps customer identity and contact fields to canonical customer models, validates required data, and preserves Mollie identifiers for correlation.
MandatesRepresent authorizations that permit recurring or subsequent payments for a Customer.Billing platforms, CRM systems, NetSuite, Microsoft Dynamics 365, internal subscription databasesMartini validates mandate status and customer relationships before creating or synchronizing recurring-payment data.
SubscriptionsDefine recurring payment schedules associated with Customers and Mandates.Billing platforms, Salesforce, NetSuite, Microsoft Dynamics 365, customer databasesMartini retrieves subscription state, maps schedule and status data, and runs reconciliation workflows for missed changes.
OrdersRepresent commerce orders with line items, shipping or billing details, payments, and refunds.Shopify, WooCommerce, Adobe Commerce, NetSuite, Microsoft Dynamics 365Martini transforms order totals, currencies, line items, and customer data into Mollie requests and synchronizes downstream order status.
RefundsRepresent full or partial reversals of Payments or Orders.NetSuite, Salesforce, Shopify, WooCommerce, Adobe Commerce, Microsoft Dynamics 365Martini validates the requested amount against the original Payment or Order, creates the Refund, stores its identifier, and prevents duplicate refund processing.

Authentication and security considerations

Bearer authentication

Mollie supports bearer authentication with test and live API keys. Martini should store these credentials in secrets and keep test and live configuration isolated.

OAuth 2.0

OAuth 2.0 is available when an application accesses Mollie organizations on behalf of users or merchants. Martini should protect client credentials, access tokens, and refresh tokens and request only the scopes required by the integration.

Webhook protection

A Mollie callback indicates that a resource may have changed; it does not by itself prove payment success. The receiving workflow should retrieve the current Mollie resource and evaluate its status before making business decisions.

Sensitive data

Payment identifiers, customer information, metadata, credentials, and webhook payloads should be protected and excluded from unnecessary workflow logs or error messages.

Operational considerations for Mollie integrations

Pagination and checkpoints

Collection workflows should follow Mollie pagination links and persist progress so an interruption does not require a full restart.

Rate limits and retries

Throttle requests according to Mollie responses and documented limits. Use timeouts, bounded retries, and backoff for transient failures and rate-limit responses.

Idempotency

Webhook processing and payment, order, or refund writes should use Mollie identifiers and internal business keys to prevent duplicate business actions.

Payment states

Model payment states explicitly rather than reducing them to a simple success or failure flag. Apply the status rules required by the downstream order, fulfillment, or accounting process.

Financial values

Preserve amount and currency as structured values and use decimal-safe processing when mapping to financial systems.

Testing and change management

Keep test and live credentials, webhook URLs, downstream endpoints, and monitoring configuration separate. Mappings should tolerate additive fields, validate required fields, and be reviewed when Mollie resource representations evolve.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrated workflows

Martini coordinates Mollie API calls, webhook receipt, downstream writes, scheduled reconciliation, validation, and exception paths in a maintainable workflow rather than scattering logic across scripts.

Reusable APIs

Martini can expose controlled APIs for payment creation, refund requests, or other Mollie operations so multiple applications use consistent authentication, validation, and business rules.

Consistent transformation

Mappings and transformations convert Mollie JSON, payment statuses, and monetary values into stable canonical and target-system contracts.

Operational resilience

Retries, checkpoints, idempotency, monitoring, and reconciliation help address duplicate callbacks, asynchronous payment completion, rate limits, and missed notifications.

Environment control

Secrets and environment configuration keep Mollie test and live credentials, webhook endpoints, and downstream connections isolated without embedding sensitive values in application code.

Frequently asked questions

How can Mollie be integrated with enterprise systems?

Mollie can be integrated through its versioned REST API over HTTPS, bearer authentication with API keys or OAuth 2.0, and webhook-style callbacks for selected resources, especially Payment status changes. Scheduled REST synchronization supports pagination, reconciliation, settlements, refunds, subscriptions, and recovery from missed notifications.

Can Martini integrate with Mollie?

Yes. Martini can consume Mollie REST APIs, receive Mollie webhook callbacks through a Martini API or workflow trigger, transform Mollie JSON, and synchronize Payments, Customers, Mandates, Subscriptions, Orders, Refunds, and related resources with enterprise applications.

Do I need a connector to integrate Mollie with Martini?

No. A dedicated Mollie connector is not required. Martini can integrate using Mollie’s native REST APIs, documented webhook callbacks, API-key or OAuth authentication, and scheduled workflows.

Is there any extra Lonti cost to integrate Mollie with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Mollie. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Mollie, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.

Which Mollie integration methods should an enterprise use?

The Mollie REST API should be the primary method for creating and retrieving Payments, Customers, Mandates, Subscriptions, Orders, Refunds, Profiles, Settlements, and Balances. Webhook-style callbacks are useful for selected Payment status changes, while scheduled, paginated reconciliation provides recovery and broader synchronization. No official Mollie GraphQL or SOAP API was confirmed.

Are Mollie webhooks available for payment events?

Mollie supports webhook-style notifications, particularly for Payment status changes, but coverage is not a universal event stream for every resource. Martini should receive the callback, retrieve the current Mollie resource, evaluate its status, and process it idempotently; scheduled reconciliation should cover missed or delayed notifications.

How can Mollie data be synchronized and transformed?

Martini can retrieve Mollie JSON through REST workflows, follow pagination links, maintain timestamps or checkpoints where available, and map Payments, Orders, Refunds, Customers, Mandates, or Subscriptions to canonical and target schemas. Scheduled reconciliation is recommended because Mollie does not appear to provide general change-data capture for all resources.

How are Mollie errors, retries, and duplicate notifications handled?

Martini can apply bounded retries and backoff for transient HTTP failures or rate limits, validate responses, and route permanent errors to an operational path. Webhook and write workflows should store Mollie identifiers and internal business keys so duplicate callbacks or retried requests do not repeat downstream transitions or refunds.

Related Martini documentation

APIs

Webhooks

Workflows

Security

Operations

Integrate Mollie with Martini

Use Martini to connect Mollie payments and recurring-payment resources with the applications, APIs, and data stores that support your enterprise processes.

EXPLORE MARTINI
BOOK A DEMO