---
title: "Payments and payouts"
weight: 30
description: "Management of payment transactions and payouts (transfers from Mollie to your bank account)."
source_hash: "a0884654"
---

# Payments and payouts

## Payments

Access: **Bank > Mollie > Payments**

Payments represent the transactions made by your customers via Mollie (credit card, iDEAL, Bancontact, SEPA bank transfer, etc.).

### Payment list

The list page displays all payments synchronized from Mollie with:

- **Mollie ID** (`tr_xxxx`) - Clickable link to the detail card
- **Amount** and **currency**
- **Fees** charged by Mollie on the transaction
- **Method** used
- Payment **status**
- **Creation date**

![Mollie payment list with ID, amount, method and status columns](screenshots/paiements-liste.webp)

**Available actions:**

- **Synchronize** - Fetches recent payments from the Mollie API
- **New** - Creates a new payment (if rights allow)
- Filtering by status, method, date, amount

### Mollie fees

Mollie does not communicate the fees at payment time: they are only known once the transaction has been settled on your Mollie balance, which can take from a few minutes to several days depending on the payment method. The **Fees** column therefore remains at zero as long as Mollie has not settled the transaction.

Fees are fetched from the Mollie balance transactions:

- on each **Synchronize** from the payment list,
- on each **Refresh from Mollie** from a payment card,
- automatically by the scheduled task **MollieCheckPay**, which catches up settled payments since the previous run.

Two limits to know:

- in **test mode**, the balances API returns nothing: fees always remain at zero;
- the API key used must have access to balances, otherwise fees cannot be read (the detail is logged in the Dolibarr logs).

If the `MOLLIE_ADD_FEES` constant is set to `PAYMENT` (addition of a debit line for each fee related to a collection), the corresponding fee entry is added to the bank account. It is only created when the fee amount is actually known, never with a zero amount.

### When a payment is refused

The module refuses to start a payment in the following cases. The customer sees an on-screen message and the reason is logged in the Dolibarr logs.

| Situation | Reason |
|-----------|--------|
| Invoice already settled | Nothing is owed anymore, credit notes and down payments included |
| Draft, canceled or abandoned invoice | Only a validated invoice can receive a payment |
| Order already invoiced | It is the invoice that must be paid |
| Order not validated or canceled | The object is not ready to be paid |
| Dolibarr not accessible over HTTPS | Mollie could not notify the payment |
| Zero amount | There is nothing to collect |

The collected amount is always computed from the paid object (invoice remaining amount, order total, configured down payment). It is never read from the browser request.

### Resuming an abandoned payment

If a customer leaves the Mollie payment page without completing it, they can come back and pay later from the same link:

- if the Mollie payment session is **still open**, the customer is redirected to that same payment page;
- if it is **expired, failed or canceled**, a new payment is created and replaces the previous attempt;
- if it is **already paid** or **being processed**, no second payment is started and a message invites the customer to contact you.

### Payment pending confirmation

Some methods are not confirmed immediately: a bank transfer remains pending until the money arrives, an installment payment remains authorized until its capture.

In these cases, the customer sees a **"Payment being confirmed"** page, neither success nor failure, and no error message is sent. The payment is recorded in Dolibarr as soon as Mollie confirms it, by webhook or by the scheduled task.

### Payment results in the invoice agenda

Each Mollie payment result leaves an automatic event in the **Events** tab of the invoice, with the same codes Dolibarr uses for Stripe. Other modules (reminders, subscription management) can thus read these traces without knowing Mollie.

| Code | When | Detail recorded |
|------|-------|-------------------|
| `AC_PAYMENT_MOLLIE_OK` | The payment is collected and recorded on the invoice | Date of collection at Mollie |
| `AC_PAYMENT_MOLLIE_KO` | The payment is refused, or a chargeback takes the money back | Mollie status, refusal code and message, refusal date |
| `AC_MOLLIE_BANK_RECORD_FAILED` | The payment succeeded at Mollie but its payment and bank line could not be written in Dolibarr | Error returned by Dolibarr |

**What counts as a refusal:**

- a payment with **failed** status at Mollie, always: the card or the bank refused;
- for an **automatic direct debit** (recurring payment on a mandate, without the customer), an **expired** or **canceled** payment also counts: nothing else will make it succeed;
- a customer who **leaves** the payment page or clicks **Cancel** refused nothing: no event is set, they can come back and pay from the same link.

The refusal detail is readable in the event, in the form `failed - insufficient_funds - The card has insufficient funds` for a card or `failed - AM04 - Insufficient funds` for a SEPA direct debit.

**One event per payment:** Mollie sometimes sends the same notification several times, and the module also learns the result from the customer's return page, the scheduled task or the refresh button. The module only sets the event once per Mollie payment. A new attempt refused the next day is a new payment: it leaves its own event.

**Orders:** the `AC_PAYMENT_MOLLIE_*` codes are only set on invoices. The successful payment of an order creates its invoice, which receives the event. The refusal of an order payment sets nothing, the order not having an invoice yet.

**Bank line cannot be written:** if the Mollie bank account in the configuration is missing or invalid, the `AC_MOLLIE_BANK_RECORD_FAILED` event signals the money collected at Mollie but absent from Dolibarr. Fix the configuration: the payment is recorded at the next Mollie notification, which resends it for 26 hours, or by the scheduled task which replays failed notifications.

The old `AC_MOLLIE_PAYMENT_OK` code remains visible on invoices paid previously. It is now only set on donations.

### Invoices in foreign currency

If the multi-currency module is active and the invoice is denominated in a currency other than your company's, the customer is debited the **amount in the invoice currency**, in that currency. The payment is recorded in Dolibarr with the invoice's exchange rate.

A payment received in a currency that does not match the object, or for an amount different from the one announced at the start, is refused and logged.

### Payment statuses

| Status | Description |
|--------|-------------|
| Draft | Payment created, awaiting action |
| Authorized | Payment authorized by the bank, awaiting capture |
| Paid | Payment received and confirmed |
| In progress | Capture sent, processing underway |
| Disputed | The customer disputed the payment |
| Expired | The payment has expired (deadline exceeded) |
| Failed | The payment failed |
| Refused | The payment was refused by the bank |
| Pending capture | Awaiting capture by the bank |
| Canceled | The payment was canceled |

### Payment card

The payment detail card displays:

- General information: amount, currency, method, description
- Dates: creation, expiry, payment
- Link to the associated Dolibarr third party
- Link to the related Dolibarr invoice (if applicable)

![Mollie payment detail card with general information and available actions](screenshots/paiement-fiche.webp)

**Actions available on the card:**

- **Refresh from Mollie** - Updates the information from the API
- **Cancel** - Cancels a pending payment (if the API allows it)
- **Capture** - Starts the capture of an authorized payment
- **Release authorization** - Releases an uncaptured payment authorization
- **Refund** - Refunds all or part of the payment
- **Delete** - Deletes the local record (draft only)

### Bank transfer details

When a payment uses the **bank transfer** method (`banktransfer`), the card displays additional information:

- **Transfer reference** - Unique reference the customer must indicate when making the transfer
- **Recipient account IBAN** - IBAN of the Mollie account the customer must transfer to
- **BIC code** - BIC code of the recipient bank
- **Recipient bank** - Name of the bank

The flow is as follows:

1. The customer chooses "bank transfer" during payment
2. Mollie provides an IBAN and a unique transfer reference
3. The customer makes the transfer from their bank indicating the reference
4. Mollie automatically matches the transfer using the reference
5. A webhook is sent and the status changes to **Paid**

> The default delay to receive the transfer is 12 business days + 2 processing days. Past this delay, the payment automatically expires. The payment is mapped to the Dolibarr payment method **VIR** (bank transfer).

### Tabs of the payment card

- **Card** - Payment details
- **Refunds** - List of associated refunds (see [Refunds](/mollie/remboursements))
- **Chargebacks** - Chargebacks linked to this payment (see [Chargebacks](/mollie/remboursements))
- **Captures** - Captures made (see [Captures](/mollie/remboursements))

## Event registrations and booths

The module supports online payment of **event registrations** and **booth reservations** from the Dolibarr *Event organization* module.

The flow is the Dolibarr core one: from the public registration page, the participant arrives on the payment page, where the Mollie button appears just like for an invoice.

Once the payment is confirmed:

1. The payment is recorded on the **registration invoice**, on the Mollie bank account, like any other payment of the module
2. The **participant** moves to *Validated* status, with the amount paid and the registration date
3. For a booth, the **reservation** moves to *Suggested* status
4. The confirmation email of the Event organization module is sent, if configured

> Replaying the notification or reloading the return page does not validate twice: an already validated participant and an already suggested booth are left as they are.

## Member dues

The module supports online payment of **dues** from the Dolibarr *Members* module. From a member's payment link, they arrive on the payment page where the Mollie button appears, with the choice of payment method (card, iDEAL, Bancontact, etc.) depending on what is enabled on your Mollie account.

### Dues amount

A dues entry does not carry an amount like an invoice would: it is determined server-side, in this order:

1. the amount of the **member type**
2. failing that, the **MEMBER_NEWFORM_AMOUNT** constant
3. failing that, the amount of the member's **last dues**

If the member type allows the member to choose their amount (*Editable amount*), the entered amount is accepted, provided it respects **MEMBER_MIN_AMOUNT**. Otherwise, the type's amount applies: a different value sent by the browser is ignored, and a collection that does not match the authorized amount is refused and logged.

If **MEMBER_ALLOW_CHANGE_OF_TYPE** is enabled, the type chosen on the payment page is applied: the amount and the recorded dues follow this type. An unknown or disabled type is never kept.

### What is recorded after payment

1. The member still in **draft** is validated
2. The **dues** entry is created, for the period following the current one in case of renewal
3. The complementary entries follow the **ADHERENT_BANK_USE** setting of the Members module:
   * *Direct bank entry*: bank line on the **Mollie account**
   * *Invoice and bank entry*: third party created if needed, invoice, payment and bank line
   * *Invoice only*: invoice, without bank entry
   * *None*: the dues entry only
4. The **membership confirmation email** is sent if configured (ADHERENT_EMAIL_TEMPLATE_SUBSCRIPTION or the member type text), and the **external user** is created if ADHERENT_CREATE_EXTERNAL_USER_LOGIN is enabled

> The bank account used is the Mollie module's one. The Dolibarr core only knows the PayBox, PayPal and Stripe accounts here: without this handling, the collection would fail with "bank account not configured".

> Replaying the notification or reloading the return page never creates two dues entries for the same Mollie payment.

## Payouts

Access: **Bank > Mollie > Payouts**

Payouts represent the transfers Mollie makes to your bank account. Mollie groups the payments received and transfers them periodically (usually daily or weekly depending on your Mollie configuration).

### Payout list

The list page displays:

- **Mollie ID** of the payout
- **Amount** transferred
- **Date** of the transfer
- **Status**

![Mollie payout list with transferred amounts and dates](screenshots/reversements-liste.webp)

### Synchronization

Payouts are automatically synchronized via:

- The **Synchronize** button on the list page
- The daily scheduled task **MollieCheckPay** (see [Scheduled tasks](/mollie/webhooks))
- Mollie webhooks (automatic notifications)