Worldline Direct / CAWL

This plugin lets your customers pay through Worldline Direct, also sold as PAYONE Global Online Pay in Germany and Austria, CAWL by Crédit Agricole in France and ANZ Worldline Solutions in Australia. At the end of the checkout the customer pays on the secure payment page of your provider, and the order is confirmed in your shop once the payment is accepted.

Features

• Sends the customer to the hosted payment page of your Worldline, PAYONE, CAWL or ANZ account, which shows the payment methods your contract offers: cards, Google Pay, Apple Pay, PayPal, iDEAL, Bancontact and more (the whole list). No card number is ever typed on your website.
• 3-D Secure on card payments, with a setting to ask the bank to challenge the customer or not.
• Confirms the order when the payment is accepted, from the customer's return and from the provider's notification, even when the customer closes the browser before coming back to your shop.
• Never takes the status of a payment from the browser or the notification: it is read back from your provider first. The same payment confirms the order once.
• A payment cancelled on the payment page brings the customer back to your shop with the cart kept.
• Shows the payment page in the customer's language, and with your own template (variant) when you set one up in your account.
• Works with the test environment of your provider, to try the whole flow with test cards before going live.
• Compatible with the UCP (Universal Commerce Protocol) plugin for headless commerce: UCP clients can send Google Pay tokens, paid server to server with 3-D Secure.

How it works

• 1. The customer chooses the payment method at the end of the checkout and is sent to your provider's payment page.
• 2. They pay with the method of their choice, with 3-D Secure when their bank asks for it.
• 3. They come back to the thank you page of your shop and the order is confirmed; your provider's notification confirms it too if they do not come back.
• 4. HikaShop sends the customer its confirmation email.

Installation

• 1) Have an account with your provider. PAYONE opens a free test account at signup.preprod.payone.com; with Worldline, CAWL or ANZ, ask your provider for one. The live account comes with your contract and has its own keys.
• 2) Log in to your merchant portal (for PAYONE, portal.preprod.payone.com for the test account and portal.payone.com for the live one) and note your PSPID, shown at the top of the portal.
• 3) Open Developer, Payment API, and generate an API key: copy the API Key ID and the Secret API Key, the secret is shown only once.
• 4) Download the plugin from our website and install it on your website (the Joomla extension manager, or HikaShop's plugin installer on WordPress).
• 5) In HikaShop, go to System > Payment methods, click "New" and choose Worldline Direct. Fill in the PSPID and the two keys, choose the environment (Pre-Production for a test account, Production for a live one) and the endpoint of your provider (PAYONE for a PAYONE account), and save.
• 6) In your portal, turn on the payment methods you want to offer. No webhook has to be set up: the plugin gives its notification address with each payment.
• 7) If your website uses Akeeba Admin Tools' .htaccess Maker (or any other server-level hardening that restricts which PHP files can be reached at the website root, often called "entry point filtering" or "allowed front-end files"), whitelist worldlinedirect_*.php in the list of allowed files and regenerate your .htaccess. When the payment method is saved, the plugin writes a small return file named worldlinedirect_<payment_id>.php at the root of your website, so that the return address stays within the 200 characters the payment page accepts. If your hardening blocks it, customers see a "403 Forbidden" page when they come back although they paid, and the order waits for the notification. When the website root is not writable, the plugin uses a longer return address through index.php instead, which is not affected.

Configuration

• PSPID: the PSPID of your merchant account (step 2). A test account and a live account have different PSPIDs.
• API Key ID and Secret API Key: the keys of step 3, from the same account and environment as the PSPID.
• Environment: Pre-Production (test) takes no real payment and uses the keys of your test account; Production takes real payments with the keys of your live account.
• Endpoint: your provider: Worldline Direct, CAWL (Crédit Agricole), PAYONE (Global Online Pay), ANZ Worldline Solutions (Australia), GlobalCollect or WL Online Payment Acceptance. Choose the one your contract is with; the payment page then carries its name and look.
• Variant name: the template of the payment page made in your portal (Branding), to show your colours and logo. Empty, the default page is shown.
• 3D Secure Challenge Indicator: whether you want the customer's bank to ask them to authenticate on card payments. Leave the default "no preference" unless your provider tells you otherwise.
• Debug: writes the requests and answers of your provider in the payment log file of the HikaShop configuration page, to look into a problem.
• Return URL: not used, the plugin makes the return address itself; leave it empty.
• Invalid status: not used by this version; a payment cancelled on the payment page cancels the order.
• Verified status: the status of an order once its payment is accepted, usually "confirmed".

Troubleshooting

• "You have to configure a PSPID", "the API Key" or "the Secret API Key": one of these settings is empty.
• "MISSING_OR_INVALID_AUTHORIZATION" in the payment log: the keys do not belong to the PSPID, or a test account's keys are used in Production (or the reverse).
• "The endpoint Ogone (EU) (or TechProcess (India)) of this payment method no longer exists": those servers were shut down. Payments now go to Worldline Direct; choose the endpoint of your contract and save the payment method.
• The customer sees "403 Forbidden" on coming back from the payment page: see step 7 of the installation.
• "INVALID_VALUE" on returnUrl in the payment log: the return address is too long; check that the return file of step 7 can be written at the root of your website, and save the payment method again.

Use

• This plugin is compatible with all the editions of HikaShop
• Compatible with Joomla and WordPress
• Requires a Worldline Direct, PAYONE Global Online Pay, CAWL or ANZ Worldline account (a free test account to try it)
• Compatible with PHP 8.3 minimum
• No limit of time
• No limit of use
• 30-day money-back guarantee

Changelog

2.2.2 on the 24th of October 2026

• Updated the bundled Worldline Direct PHP SDK to its 12.0.0 release. This plugin now requires PHP 8.3 or higher, as the SDK does.

2.2.1 on the 22nd of October 2026

• Updated the bundled Worldline Direct PHP SDK to its latest 11.3.0 release, keeping up with Worldline's payment method and API additions. None of the classes or properties the plugin relies on were affected by this release.

2.2.0 on the 19th of October 2026

• Improvement: PAYONE Global Online Pay can be chosen as the endpoint, for the PAYONE merchants of Germany and Austria.
• Ogone and TechProcess are no longer in the endpoint list, their servers having been shut down: a payment method saved on one of them now takes its payments through Worldline Direct and its settings say so, where it could not take any payment before.

2.1.6 on the 13th of October 2026

• Updated the bundled Worldline Direct PHP SDK to its 11.2.1 patch release. None of the classes or properties the plugin relies on were affected.

2.1.5 on the 7th of October 2026

• Updated the bundled Worldline Direct PHP SDK to its latest 11.2.0 release, keeping up with Worldline's payment method and API additions. None of the classes or properties the plugin relies on were affected by this release.

2.1.4 on the 4th of October 2026

• Updated the bundled Worldline Direct PHP SDK to its latest 11.1.0 release, keeping up with Worldline's payment method and API additions. None of the classes or properties the plugin relies on were affected by the SDK's intervening major versions.

2.1.3 on the 22nd of September 2026

• Payments made through the Worldline payment page now send Worldline the webhook address again, so orders are confirmed by the gateway notification. Since 2.1.2, websites showing PHP warnings displayed "Undefined variable $feedbackUrl" at the end of the checkout, and Worldline received no webhook address for these payments.

2.1.2 on the 4th of May 2026

• The customer return URL the plugin sends to Worldline is now short enough to stay under the gateway's 200-character limit on every HikaShop install. The previous URL pattern (the full HikaShop notify endpoint with all its routing query parameters) routinely landed at 200 to 230 characters depending on how long the site host name and the order token were, and Worldline rejected such requests with the generic "incorrect request error response" message and an INVALID_VALUE error on every returnUrl property. Customers paying on those installs were unable to reach the Worldline payment page at all. The plugin now writes a small return file at the website root when the payment method is saved (the same approach used by several other HikaShop payment plugins), and points Worldline at that short URL. Sites where the website root is not writable transparently fall back to a stripped-down version of the previous URL, with only the routing keys actually consumed by the notify handler.
• When Worldline rejects a payment request, the HikaShop log now contains the full request that was sent to the gateway (with the return URLs, payment-method-specific inputs and the complete order data) alongside the gateway's structured response. Previously only the order data was logged, which made it hard to diagnose problems caused by the rest of the request, such as a return URL the merchant account hadn't whitelisted or a malformed site URL.

2.1.1 on the 1st of May 2026

• Worldline can now process orders whose order number contains slashes, dates or other special characters. The plugin now sanitises the value sent to Worldline as the bank-statement descriptor and as the merchant reference, keeping only letters, digits, spaces, hyphens and underscores. Customers were previously seeing the same generic "incorrect request" error from the gateway when their order number happened to include a date pattern like "B1A2/04/26".
• French, Belgian, Italian and Spanish addresses where the house number sits at the start of the street (e.g. "14, rue de la Tour" or "14 Avenida de Mayo") are now correctly split into a street name and a house number when sent to Worldline. The previous logic only recognised the German / English / Dutch convention where the number sits at the end of the street, leaving the house number empty for everything else.
• When Worldline rejects a request, the HikaShop log now also contains the gateway's structured per-field response (the JSON breakdown returned alongside the validation error), instead of only the generic "the payment platform returned an error response" line. Makes diagnosing rejected orders much faster.

2.1.0 on the 30th of April 2026

• Updated the bundled Worldline Direct PHP SDK to its latest 8.4.0 release. The previous SDK was several major versions behind and used class names that the latest payment gateway no longer accepted on every request.
• The plugin now ships its own SSL certificate bundle and points the SDK at it, so the connection to the payment gateway works on hosts where the system curl certificate bundle is missing or out of date (typical on shared hosting and on Windows servers). Customers who were previously seeing a generic "the payment platform returned an incorrect request error response" or a cURL SSL error when clicking the payment button should now be redirected to the Worldline payment page as expected.
• The country code (and the state code, where applicable) of the customer's billing and shipping address is now always sent to Worldline. Until now, depending on the way the address had been loaded, those fields could end up empty in the request, which Worldline rejects with the same generic "incorrect request" error. The plugin now falls back to the resolved country and state objects when the flat code fields are not populated, and uses FR as a last resort if no country information at all is available, so the request still goes through and can be corrected from the Worldline backend.
• Fixed the additional address line not being passed to Worldline (it was sent only when empty, and never when actually filled in).
• Fixed a typo in the SDK class name used for discount, payment fee and additional cart lines that caused a PHP error on any order containing a discount, a coupon, or a payment fee.

2.0.1 on the 11th of March 2026

• Added getUcpGooglePayConfig() method for automatic Google Pay gateway detection by the UCP plugin, removing the need to manually configure the gateway name and merchant ID in UCP settings.

2.0.0 on the 10th of March 2026

• Added UCP (Universal Commerce Protocol) support for headless commerce integration via the getPaymentURL method which generates hosted checkout URLs for UCP checkout sessions.
• Added server-to-server Google Pay token processing via the new onUcpPaymentProcess event handler using Worldline's CreatePayment API with mobile payment method input (product 320).
• Added 3D Secure redirect handling for PAN_ONLY Google Pay tokens that require additional authentication.
• The payment notification handler now supports both hosted checkout callbacks and direct payment callbacks.
• Refactored the SDK client creation and order building logic into shared private methods for better maintainability.

1.0.3 on the 16th of June 2025

• The update server was missing from the XML of the plugin preventing the auto update via the Joomla update manager from taking the plugin into account.

1.0.2 on the 14th of June 2025

• The plugin now provides the current local to the payment gateway, making sure that it only provides locales supported by it, and otherwise defaults to English.

1.0.1 on the 13th of June 2025

• We've added a new option "Variant name" to the Worldline Direct / CAWL payment plugin. This will allow you to use the customized template options configured in your merchant account.
• The merchant reference of transactions on the merchant account now use the order number instead of the order id for easier order matching.

1.0.0 on the 12th of June 2025

• Initial release of the plugin