Module and release scope
This guide covers Mollie Hosted Payments 1.0.0, Extension API 1, from the reviewed product source. Its declared core range is 1.3.6–1.3.99. Use the matching released core and signed provider package; a version label alone does not install the required contracts. Source availability does not mean the module is bundled in every currently downloadable product, installed on your server, enabled or certified for your merchant/server account. Nothing in this guide enables a provider or changes your existing connections.
Open System → Payment gateways (newer source may group these as Payments, Domain services or Hosting services). Install the reviewed signed package through Modules & addons or the integration workspace's Install tab, enable the module separately, add an account/connection, save its own credentials, run its stated Test and explicitly enable the connection. Saving or retesting disables the connection until you enable it again. Start with the provider's test environment where supported; otherwise use an isolated account or server.
Exact connection fields
These are the fields declared by this module. Secret values are entered privately and encrypted by the application. Defaults are configuration hints, not approved live merchant settings. Internal fields are populated by the module and are not operator-editable.
| Key / label | Type | Required | Default / guidance |
|---|---|---|---|
mode — Environment |
select | Yes | Default: "sandbox" Choices: sandbox = Sandbox, live = Live |
api_key — Profile API key |
secret | Yes | Use a test_ or live_ profile API key; organization/OAuth tokens are not used by this module. |
profile_id — Website profile ID |
text | Yes | The pfl_ ID belonging to this API key in Mollie Dashboard → Developers. |
accepted_currencies — Enabled invoice currencies |
text | Yes | Default: "EUR" Comma-separated currencies approved for this profile. No invoice currency conversion is performed. |
One-off invoice payments through Mollie Payments API v2. Requires EmailaBiller 1.3.6 or later. Installed disabled; no account, credential or business defaults are supplied.
Configure
- Complete Mollie onboarding and create a website profile. Activate the payment methods and currencies your business is approved to accept.
- From Mollie Dashboard → Developers, copy the website profile ID (
pfl_…) and its test API key (test_…). Select Sandbox. Organization tokens and OAuth access tokens are intentionally unsupported here; a profile key fixes account ownership. - Set enabled invoice currencies to the currencies approved for this profile. The module handles supported two-decimal payment currencies and sends the invoice amount unchanged. JPY and ISK are excluded; no currency conversion is performed.
- Save and Test. Testing reads
GET /v2/profiles/me; it never creates a payment. Enable the connection only after a successful test and sandbox checkout. - For production, change to Live and the matching
live_…profile API key; verify and enable explicitly.
Webhook and return
The application passes the exact connection webhook URL to Mollie when creating each payment. Keep that HTTPS URL publicly reachable; a separate signing secret is unnecessary for this v2 payment notification flow. A notification contains a payment ID and is only a prompt for an authenticated API read. Browser returns use the stored checkout ID from the signed application return, then perform the same read.
Payment is recorded only for paid, with a valid payment date, matching profile/environment, complete original invoice metadata and exact amount/currency. Authorizations, pending payments, refunds and chargebacks cannot create new paid evidence. Stable payment IDs prevent repeat credits in the core ledger. Scheduled collection, subscriptions and automatic refunds are outside this one-off module.
Provider documentation
- Create payment and profile-key authentication
- Retrieve payment and status evidence
- Read-only current profile
- Payment currencies and decimal places
- Payment notifications
HTTP failures show a safe status and setup guidance; raw provider response bodies and credentials are never displayed. No provider request is retried automatically after an uncertain checkout creation.