MBI Up2pay ETransactions

🎯 Module Overview

MBI Up2pay ETransactions collects card payments online for your invoices and sales orders through Crédit Agricole's Up2Pay E-Transactions payment solution. The module adds an "Internet card" payment method to Dolibarr, generates a payment link for each document, emails it to your customer, then records the settlement and marks the invoice as paid as soon as the bank confirms the transaction. It complies with the PSD2 regulation and supports 3-D Secure v2.

An Up2Pay E-Transactions contract with Crédit Agricole is required, together with the shop credentials provided by the bank (site number, rank, identifier and secret key), a bank account configured in Dolibarr on which settlements will be recorded, and return pages reachable from the Internet, as the bank calls them directly to notify transaction results.

🌐 Demo: https://demo.mbicloud.fr 🛒 Discover our other modules on Dolistore.

💡 Benefits

• Your customers pay online, immediately, with no data re-entry on your side.
• The settlement, the bank entry and the paid status of the invoice are handled automatically.
• The payment link is sent along with the invoice or the order, in an email you write once and for all.
• Your customer settles the sales order itself, from a link that really points to it, without waiting for the invoice.
• You can request a deposit, or offer payment in two or three instalments, without leaving Dolibarr.
• A test mode lets you validate the whole chain before collecting a single euro.

⚙️ Key Features

💳 Online card collection

• "Internet card" payment method: added to Dolibarr and available on customer invoices and sales orders.
• Secure payment link: generated per document, based on a single-use hash.
• Choice of payment page: a page in your own company's colours, or Dolibarr's native online payment page.
• Test mode: validate the integration without any real movement.

🧾 Payment from a sales order

• Payment from the order itself: your customer settles the sales order from a link that really points to it, without waiting for the invoice.
• Link ready as soon as the document is validated: on orders as well as on invoices, and sent automatically when the document is sent to the customer by email.
• Invoice creation from the order: when the payment relates to a sales order.

💶 Deposit and instalments

• Deposit: an extra field lets you collect only part of the amount, capped at the outstanding balance.
• Payment in two or three instalments: the amount is split into equal parts, each instalment being charged one month after the previous one.
• Full schedule announced before the card is entered: the amount due today and the date of every upcoming debit are shown to the customer.
• Card expiry checked at checkout: a card expiring before the last instalment is refused, while the customer can still present another one.

✉️ Customer emails

• Automatic email delivery of the link: sent when the invoice or the order is sent to the customer, with a customisable subject and message template, and optional copies to addresses of your choice.
• Trust image: displayed in the email, showing the customer's phone number.
• Paid invoice email: sent after collection, with the PDF attached, customisable subject and template.

🔒 Link validity control

• A link that no longer has a purpose is refused: an invoice that is settled, abandoned or still a draft, and an order that is already invoiced, cancelled or still a draft, can no longer be paid.
• A running instalment plan blocks any reopening of the link: a customer is never charged a second time for amounts the bank has already committed to collect.
• Collected amount recomputed on the server: the amount charged never depends on a field of the payment form.

🛡️ Security and architecture

• Multi-entity: payments made on a secondary entity are correctly attached.
• Signature verification: the bank's returns are verified using a 2048-bit key.
• Automatic settlement recording: on the bank's return, payment creation, entry on the configured bank account, invoice switched to paid.
• Reliable handling of bank notifications: a duplicate notification does not create a second settlement, and a failure while recording is retried cleanly instead of leaving a partial entry.
• Permissions: three separate permissions, read, create or update, delete.

🆕 Recent updates (2.2.0 / 2.1.0 / 2.0.1)

• Payment from a sales order now really works: the link is built when the order is validated, points to that order, and is sent to the customer when the order is sent by email, just like invoices.
• The payment page announces the whole schedule before the card is entered, the amount due today and the date of every upcoming debit, and a card expiring before the last instalment is refused at checkout while the customer can still present another one.
• A link that no longer has a purpose is refused: a settled, abandoned or draft invoice, and an already invoiced, cancelled or draft order, can no longer be paid; a running instalment plan blocks any reopening of the link.
• The collected amount is now recomputed on the server, and a bank notification carrying more than the invoice balance is no longer recorded as is.
• The module is available in six complete languages: English, French, German, Spanish, Italian and Portuguese.
• The payment result pages no longer load a stylesheet from Google, and the online payment stylesheet configured in Dolibarr is applied to them.
• An optional branded payment page is available, or redirection to Dolibarr's native online payment page, the default behaviour being unchanged; deposit and 2x/3x split payment are available on orders as well as on invoices.
• Security was strengthened on the public payment page and signature verification uses a 2048-bit key; duplicate gateway notifications and payments made on a secondary entity are handled correctly.

✅ Compatibility

• Dolibarr: 12.0+ (tested up to Dolibarr 23)
• PHP: 7.2+
• Available languages: English, French, German, Spanish, Italian, Portuguese.
• Up2Pay E-Transactions contract: required, with the shop credentials provided by Crédit Agricole (site number, rank, identifier and secret key).
• Dolibarr bank account: required, settlements are recorded on it.
• Internet-reachable return pages: required, the bank calls them directly to notify transaction results.
• PHP openssl extension: optional, used to verify the signature of the bank's returns.
• No other Dolibarr module is required, and no incompatibility is declared. The module fits into the standard Dolibarr interface, without overriding the core.

Module version: auto
Publisher/Licence: MB Informatique / GPL-v3
User interface language: English, French, German, Spanish, Italian, Portuguese
Help/Support: MB Informatique
Prerequisites:

• Dolibarr min version: auto
• Dolibarr max version: auto

🔧 Installation

1. Download the module's ZIP archive without extracting it.
2. In Dolibarr, go to Home > Setup > Modules/Applications.
3. Open the Deploy/Install external module tab.
4. Upload the module's ZIP archive.
5. Find and enable MBI Up2pay ETransactions.
6. Configure the module options from its administration page: the shop credentials provided by Crédit Agricole (site number, rank, identifier and secret key), the bank account on which settlements will be recorded, and the subjects and templates of both emails.
7. Grant the required permissions to the relevant users.
8. When updating from an earlier version, disable then re-enable the module so that the "Payment link" field is added on orders.
9. (Optional) For a manual installation, drop the mbietransactions folder into /htdocs/custom/.

ℹ️ Usage notes

• An Up2Pay E-Transactions contract with Crédit Agricole is required, together with the shop credentials provided by the bank: site number, rank, identifier and secret key.
• A bank account must be configured in Dolibarr, as settlements are recorded on it.
• The module's return pages must be reachable from the Internet, as the bank calls them directly to notify transaction results.
• The PHP openssl extension is optional and is used to verify the signature of the bank's returns.
• Enable test mode first, pay an invoice end to end to check that the bank's return is properly processed, then disable test mode once the whole chain has been validated.
• Payment in two or three instalments is an option of your Up2pay contract, not a module setting: without it the bank refuses the payment and your customer only reads "payment refused", with no reason given.
• A deposit is capped at the outstanding balance, and split payment charges each instalment one month after the previous one.
• The bank does not accept amounts below one euro, and an amount too small to be split is collected in one go.
• Back up the database and the Dolibarr files before any update, and read the ChangeLog: some versions require disabling and re-enabling the module to take effect, which is stated explicitly at the top of the version concerned.
• Disabling the module releases the licence activation and removes the module's constants, permissions and declarations. Data created by the module is kept: the payment hash table and the extra fields added to invoices and orders are not deleted, so that the transaction history is preserved.

🎓 Services

• Training on the module is available at €80 excl. VAT.
• Support and updates included for the duration of your license.

📄 Licence and terms of use

The module is distributed under the GNU General Public License v3 or later (GPL v3+), the full text of which is provided in the COPYING file delivered with the module.

The complete Terms of Use are delivered with the module and can be read from its “About” tab in Dolibarr. Our Terms and Conditions of Sale are available at https://www.mb-informatique.fr/cgv.html.

👨 💻 Publisher

MBI Up2pay ETransactions is a custom Dolibarr module developed by MB Informatique.

It is aimed at companies holding a Crédit Agricole Up2Pay E-Transactions contract who want to collect card payments for their invoices and sales orders directly from Dolibarr, without re-entering data and without an intermediate tool.

Publisher: MB Informatique
Contact: info@mb-informatique.fr
Website: https://www.mb-informatique.fr

🛠 CHANGELOG

UPDATE 2.2.0 (2026-08-06)

• Fixed: the cardholder name sent to the bank for 3-D Secure authentication is filled again. One of the two name fields was left empty on nearly every company record, which lowers the authentication score and can have the payment refused.
• Fixed: the mobile number sent for 3-D Secure authentication is no longer malformed. The dialling code and the number were combined into a number that does not exist, a foreign mobile was declared as French, and a landline could be sent as a mobile. A phone number the module cannot read no longer breaks the payment page either.
• Improved: a customer record whose name cannot be transmitted to the payment service now stops the payment page with a clear message, instead of letting the bank refuse the authentication without explanation. The reason and the customer record concerned are written to the log, so the record can be corrected.
• Fixed: the second address line announced in 2.1.0 is not sent for the time being, following an authentication incident in production.

UPDATE 2.1.0 (2026-08-02)

• ⚠️ Action required: disable then re-enable the module after updating, so the "Payment link" field is added on orders.
• New: the module payment link now works on orders. It used to open an invoice unrelated to the order, or report an expired link.
• New: the payment link of an order is built when the order is validated, and sent to the customer when the order is sent by mail, just like invoices.
• Security: the collected amount is now recomputed on the server. It came from a field of the payment form, which a customer could edit to pay less than the amount due.
• Security: a partly settled balance is no longer split again in two or three instalments. A customer reopening their payment link could open a second schedule on top of the one the bank already held, and be charged more than the amount due. Past the first settlement, the balance is collected in one go.
• Fixed: an invoice created from an order no longer inherits the order's two or three instalment split, whose schedule belongs to the order.
• Fixed: instalment dates no longer overflow into the following month. A date computed from the 31st fell three days late; it now lands on the last day of the target month.
• Fixed: on a two or three instalment payment, a card expiring before the last instalment is now refused at checkout, while the customer can still present another one. It used to be accepted, and the later instalments failed weeks after the sale.
• Security: an invoice that is fully settled, abandoned or still a draft can no longer be paid through the module link. The link, built at validation, never expired and kept accepting payments on an invoice that owed nothing.
• Security: the link is refused while an instalment plan is running. The remaining instalments are held by the bank, which collects them on its own: reopening the link charged the customer a second time for money already committed. A payment recorded by hand still leaves the link usable for the balance.
• Improved: the payment page now announces the whole schedule — the amount due today and the date of every upcoming debit — before the customer enters their card. It used to show the first instalment alone, under a "total payment amount" label.
• Improved: the setup page points out that payment in two or three instalments is an option of your Up2pay contract, not a module setting. Without it the bank refuses the payment and your customer only reads "payment refused", with no reason given.
• Fixed: an amount too small to be split — under 2 EUR in two instalments, under 3 EUR in three — is now collected in one go. The payment used to be blocked, with a message wrongly claiming the amount was below 1 EUR when only the instalment was.
• Security: a bank notification carrying more than the invoice balance is no longer recorded as is. The balance is collected and the excess is reported in the log: an invoice cannot owe more than its balance, and booking past it would break the bank reconciliation.
• Improved: compliance with the official Up2pay e-Transactions integration kit — the cardholder name is always filled, the second address line is sent, and both the returned-data list and the signature verification match the example provided by the bank.
• Improved: an amount below the one-euro minimum accepted by the bank is now reported clearly to the customer instead of ending on a payment page error.
• Improved: the bank notification is acknowledged as soon as the settlement is recorded, before the PDF is generated and the mail is sent. The "Warning e-Transactions" alerts caused by the timeout disappear.
• Fixed: an order that is already invoiced, cancelled or still a draft can no longer be paid through the module link.

UPDATE 2.0.1 (2026-07-30)

• Security: the payment result pages no longer load a stylesheet from Google, so your customer's browser is not contacted by a third party while paying.
• Fixed: the online payment stylesheet configured in Dolibarr is now applied to the payment result pages; it was built and then discarded.
• Improved: the module documentation is shown in the user's language on the About tab, in English, French, German, Italian and Spanish.

UPDATE 2.0 (2026-06-18)

• ⚠️ Action required: disable then re-enable the module after updating to apply the changes introduced by this version.
• New: optional branded payment page, or redirection to Dolibarr's native online payment page (default behaviour unchanged).
• New: deposit and 2x/3x split payment are now available on orders as well, not only on invoices.
• Security: fixed a vulnerability on the public payment page and hardened signature verification, now using a 2048-bit key.
• Improved: a duplicate gateway notification no longer creates a second settlement, and a failure while recording is retried cleanly instead of leaving a partial settlement.
• Fixed: the deposit and split payment options had been ignored since 1.6 and were not editable on the record; both are restored.
• Fixed: an amount with a fractional cent could be charged up to one hundred times too high.
• Fixed: a deposit larger than the outstanding balance can no longer collect more than what is due.
• Fixed: payments made on a secondary entity were lost and are now recorded.
• Compatibility: PHP 8.5 support, minimum Dolibarr version raised to 12.0.

UPDATE 1.6.0 (2025-08-08)

• New: payment can be started from a sales order, with the invoice created automatically.
• Improved: the payment link can be generated when a payment is validated through the Dolibarr API.
• Fixed: minor phone number validation issue.

UPDATE 1.5.0 (2024-09-25)

• New: phone number settings added to the module configuration.

UPDATE 1.4.0 (2024-08-20)

• New: setting to control when an invoice is marked as paid.
• Compatibility: support for the latest Dolibarr version and for multi-company.

UPDATE 1.3.0 (2023-11-15)

• Fixed: payment mode check against the Dolibarr core.
• Improved: code cleaned up and optimised.

UPDATE 1.2.0 (2023-10-06)

• Security: public key added and signature verification enabled.
• Security: overall protection strengthened.
• Fixed: various minor issues.

UPDATE 1.1.0 (2023-07-26)

• New: email subjects can be set from the module configuration.
• New: English translations added.
• Improved: display style updated.
• Fixed: various issues.

UPDATE 1.0

• Initial version.