BLIK, iDEAL, Bancontact : les moyens de paiement locaux qui ouvrent les marchés locaux

La couverture des rails de paiement par les passerelles (Mollie, Stripe, Przelewy24, Adyen) reflète les moyens pris en charge par ces modules au moment de la rédaction ; la disponibilité dépend de votre compte marchand, vérifiez donc la liste actuelle dans le tableau de bord du prestataire avant de vous engager.

Voici la réalité inconfortable de la vente transfrontalière avec une boutique PrestaShop : sur les marchés où vous perdez le plus de commandes au paiement, le client ne peut souvent tout simplement pas vous payer avec les moyens que vous proposez. Un acheteur belge qui possède une carte de débit uniquement Bancontact ne peut pas la saisir dans un champ Visa. Un acheteur néerlandais qui utilise iDEAL depuis quinze ans voit un formulaire de carte bancaire et ferme discrètement l'onglet. Un acheteur polonais de moins de quarante ans cherche BLIK sur son téléphone, ne le trouve pas, et en conclut que votre boutique est étrangère et risquée. Ce n'est pas un problème de prix ni de badge de confiance. C'est un problème de rail de paiement, et sur PrestaShop il existe une solution concrète et configurable.

Ce guide explique précisément comment rendre BLIK, iDEAL et Bancontact, les trois rails locaux dominants en Pologne, aux Pays-Bas et en Belgique, disponibles dans un tunnel de commande PrestaShop : quel module de passerelle fournit réellement chaque moyen, où se trouvent les réglages dans le back-office, et comment afficher chaque option uniquement aux clients qui l'utilisent. Pour comprendre plus largement pourquoi un mix de paiement plus riche augmente les ventes, consultez pourquoi proposer plus de moyens de paiement génère plus de ventes ; pour une cartographie pays par pays des attentes des acheteurs européens, consultez les moyens de paiement pour l'e-commerce européen.

Les trois rails, et pourquoi chacun est indispensable, pas simplement utile

BLIK, iDEAL et Bancontact ne sont pas des moyens de paiement « alternatifs » sur leurs marchés d'origine : ce sont les options par défaut, la carte bancaire servant de solution de repli. Cette nuance compte, car elle transforme la question « devrais-je l'ajouter ? » en « mes clients ici peuvent-ils seulement me payer ? »

Qu'est-ce que cela implique pour votre boutique ? Si vous livrez ces pays sans proposer le rail correspondant, la vente perdue ne se manifeste pas par une réclamation : elle apparaît comme un abandon de commande que vous ne savez pas expliquer. Le client qui ne peut pas payer comme il a l'habitude de le faire ne vous envoie pas un e-mail. Il part. Voilà pourquoi c'est le changement de paiement à traiter avant d'optimiser quoi que ce soit d'autre dans le tunnel de commande.

La réalité PrestaShop : vous n'intégrez pas trois rails, vous choisissez une passerelle

Le premier réflexe consiste à chercher « un module BLIK », « un module iDEAL » et « un module Bancontact ». Ne le faites pas. Sur PrestaShop, chacun de ces rails est fourni via le module de passerelle d'un prestataire de services de paiement, et une passerelle bien choisie couvre les trois, plus les cartes bancaires, avec une seule intégration, un seul compte de règlement et un seul ensemble de rapports. Trois modules séparés, c'est trois endroits où maintenir la cohérence des réglages PCI/SCA, trois séries de mises à jour à suivre selon les versions de PrestaShop, et trois risques de conflit de hook à l'étape de paiement.

La question pratique est donc : quel module de passerelle fournit quel rail ? La couverture varie réellement, et c'est elle qui doit guider votre choix selon votre mix de marchés.

La couverture et la disponibilité évoluent dans le temps et dépendent des moyens activés sur votre compte marchand ; confirmez donc la liste actuelle dans le tableau de bord du prestataire avant de vous engager. Mais la logique reste stable : une boutique centrée sur le Benelux penche vers Mollie, une boutique centrée sur la Pologne penche vers Przelewy24, et une boutique qui veut regrouper cartes et rails locaux sous un même toit penche vers Stripe. Chacun de ces choix a sa propre profondeur de configuration, traitée dans les guides dédiés : Mollie comme passerelle multi-moyens, configuration de Przelewy24 et des paiements polonais, et le guide d'intégration Stripe. Si vous êtes encore en train de choisir votre processeur principal, Stripe vs PayPal et le comparatif complet des modules de paiement sont les bons points de départ.

Activer les rails : où se trouvent réellement les réglages

Quelle que soit la passerelle choisie, le côté PrestaShop suit la même logique. Après avoir installé le module (Modules → Gestionnaire de modules, téléversement du ZIP ou installation depuis le catalogue), les moyens se configurent à deux endroits que les marchands confondent souvent :

• Dans le tableau de bord de la passerelle (côté Mollie/Stripe/P24) : le rail doit d'abord être activé sur votre compte marchand. iDEAL et Bancontact peuvent déjà être disponibles, mais doivent être activés ou approuvés dans le tableau de bord du PSP selon votre compte et votre pays ; BLIK doit fréquemment être activé explicitement, parfois après un court examen. Si un moyen n'apparaît jamais au paiement quoi que vous fassiez dans PrestaShop, la cause est presque toujours là : le rail n'est pas activé au niveau du compte.
• Dans la configuration du module (côté PrestaShop) : ouvrez le module et vous trouverez une liste de moyens de paiement avec des commutateurs par moyen, l'ordre d'affichage et, dans les modules Mollie et Adyen, des règles par pays et par devise. C'est ici que vous décidez quels rails s'affichent, et dans quel ordre, à l'étape de paiement du contrôleur order.

Deux réglages propres à PrestaShop déterminent le résultat. D'abord, la devise. iDEAL, Bancontact et BLIK sont des rails en euro/PLN : BLIK est réglé en PLN, les autres en EUR. Dans International → Localisation → Devises, assurez-vous que le PLN existe et est activé si vous ciblez la Pologne ; un moyen BLIK refusera silencieusement de s'afficher sur un panier libellé dans une devise qu'il ne peut pas traiter. Ensuite, SCA/3-D Secure : ces rails européens relèvent de PSD2, laissez donc l'authentification forte du client active dans la passerelle : l'étape de redirection vers la banque est l'authentification, et la désactiver n'accélère rien, elle casse simplement le parcours.

Afficher le bon rail au bon client

C'est l'étape que la plupart des boutiques sautent, et elle coûte discrètement des conversions. Afficher tous les rails à tous les clients transforme l'étape de paiement en mur de logos : pour un acheteur français qui doit faire défiler iDEAL, Bancontact et BLIK avant de trouver le champ carte bancaire, c'est de la friction, et sur le dernier écran avant la conversion, la friction coûte cher. L'objectif est l'inverse : chaque client voit les trois ou quatre moyens qui sont les siens, avec la carte bancaire comme solution universelle de repli.

PrestaShop vous donne ce filtrage, avec trois niveaux de contrôle :

• Règles par pays du module de passerelle. Les modules Mollie et Adyen permettent d'associer directement un moyen à des pays de facturation dans leur configuration : Bancontact pour la Belgique, iDEAL pour les Pays-Bas, BLIK pour la Pologne. C'est l'approche la plus propre, car la logique reste attachée au moyen.
• Restrictions de paiement natives. La page Paiement → Préférences de PrestaShop permet de restreindre les modules par devise, pays, groupe et transporteur : une matrice de restrictions dans laquelle vous pouvez activer ou désactiver un module de paiement selon chaque dimension. C'est moins fin que des règles par moyen, mais cela fonctionne avec n'importe quelle passerelle.
• Ordre des hooks du module. L'étape de paiement affiche les options renvoyées par chaque module sur le hook paymentOptions (appelé displayPayment en 1.6) ; l'ordre d'apparition correspond à l'ordre défini dans la configuration du module ou à la position du hook. Placez le rail local dominant en premier pour ce marché, la carte en second : le client doit voir son moyen par défaut avant la solution de repli.

Si vous voulez que ce ciblage paraisse intentionnel plutôt qu'encombré, il s'associe naturellement à une étape de paiement bien rangée dans un tunnel de commande en une page, où les moyens pertinents restent visibles avec le total de la commande au lieu d'être enfouis derrière une étape.

Testez avant de faire confiance : la partie qui fait mal en production

Les rails locaux échouent d'une manière différente des cartes bancaires, et ils échouent après que le client a quitté votre site ; un simple test « ça s'affiche » ne suffit donc pas. Parcourez chaque rail de bout en bout dans le mode test/bac à sable de la passerelle avant de passer en production :

• Le trajet de retour. iDEAL et Bancontact utilisent des redirections vers la banque ; BLIK peut proposer la saisie d'un code au paiement avec confirmation dans l'application bancaire. La commande n'est confirmée que lorsque la passerelle appelle le webhook/IPN de votre boutique, pas lorsque le client revient. Si votre serveur bloque l'URL de rappel, ou si une couche de cache/CDN ou un module de sécurité se trouve devant le contrôleur de webhook du module, vous obtenez le cas classique : argent encaissé, commande bloquée dans un état en attente/incomplet. Vérifiez que le webhook arrive bien et fait passer la commande à un état payé.
• La redirection abandonnée. Testez ce qui se passe lorsque le client arrive sur l'écran de la banque et le ferme. Le panier doit rester récupérable et la commande ne doit pas être marquée comme payée. C'est aussi là qu'une relance de panier abandonné prend toute sa valeur, car l'abandon pendant une redirection fait partie du fonctionnement normal de ces parcours.
• La correspondance de devise. Passez une vraie commande de test en PLN pour confirmer que BLIK apparaît et règle correctement la transaction, puis en EUR pour iDEAL/Bancontact. Un moyen absent au paiement est presque toujours lié à une incompatibilité de devise ou de règle pays, pas à un bug.

Ce que fait réellement le contrôleur de webhook

Le « cas fantôme » ci-dessus mérite d'être compris, pas seulement testé, car c'est le mode de panne qui vous coûte discrètement des ventes pourtant payées. Avec un rail à redirection, la commande est créée dans un état en attente lorsque le client part vers sa banque ; c'est le rappel serveur à serveur de la passerelle, et non le retour du navigateur, qui confirme le paiement. Dans un module PrestaShop, ce rappel atteint un front controller dédié, dont le rôle est précis : vérifier que la notification vient bien de la passerelle, puis faire passer la commande à l'état payé. La structure est toujours la suivante :

// controllers/front/webhook.php – reached at
// index.php?fc=module&module=yourmodule&controller=webhook
class YourModuleWebhookModuleFrontController extends ModuleFrontController
{
    public function postProcess()
    {
        // 1. Read + verify the notification really came from the gateway
        //    (signature / API re-fetch – never trust the raw POST alone).
        $paymentId = Tools::getValue('id');
        $status    = $this->module->api->getPaymentStatus($paymentId);

        // 2. Only on a confirmed-paid status, flip the order forward.
        if ($status === 'paid') {
            $this->module->validateOrder(
                (int) $cartId,
                (int) Configuration::get('PS_OS_PAYMENT'), // "Payment accepted"
                $amountPaid,
                $this->module->displayName
            );
        }

        // 3. Answer 200 fast – the gateway retries on timeout/non-200.
        http_response_code(200);
        exit;
    }
}

Deux points dans ce flux sont précisément ceux où de vraies boutiques cassent. L'étape de vérification (1) explique pourquoi vous ne marquez jamais une commande comme payée simplement parce que le navigateur du client est revenu sur l'URL de succès : cette URL peut être atteinte sans paiement ; le signal qui fait foi est le webhook vérifié. Et la réponse rapide en 200 (3) explique pourquoi une couche CDN lourde ou une couche de sécurité devant ce contrôleur est dangereuse : si le POST de la passerelle est soumis à une vérification, réécrit ou arrive en délai dépassé, elle ne reçoit jamais son 200, la commande ne change jamais d'état, et vous obtenez le cas payé-mais-en-attente. Vous n'écrivez pas ce contrôleur : le module de passerelle le fournit. Mais connaître ses trois tâches vous dit exactement quoi vérifier lorsqu'une commande reste bloquée : l'URL de rappel est-elle joignable, renvoie-t-elle 200, et quelque chose se trouve-t-il devant elle ?

Comment savoir si cela a fonctionné

Ne jugez pas le résultat au ressenti ni sur trois jours de données. Avant d'ajouter ces rails, relevez deux chiffres segmentés par pays dans vos analytics : le taux d'abandon au paiement et la conversion panier-commande pour les Pays-Bas, la Belgique et la Pologne en particulier. Une fois les rails en ligne, comparez les mêmes chiffres par pays sur au moins 30 jours et un volume de commandes significatif, suffisant pour voir une tendance plutôt qu'un bruit d'une semaine à l'autre. Le gain est rarement une hausse uniforme sur tout le site ; c'est plutôt une reprise nette sur les marchés précis qui ne pouvaient pas vous payer auparavant, exactement la raison pour laquelle il faut les mesurer séparément. Quel que soit le niveau de hausse que vous avez vu cité pour l'ajout d'un rail local dominant, considérez-le comme une indication et laissez vos propres chiffres segmentés trancher.

Un autre rail mérite d'être mentionné pendant que vous êtes dans les réglages de paiement : sur ces mêmes marchés, le paiement fractionné ou différé (Klarna en particulier) fait partie des attentes des acheteurs juste à côté de BLIK et d'iDEAL, et la plupart des passerelles ci-dessus peuvent l'activer de la même manière. Décider s'il vaut la peine de le proposer est un sujet à part ; nous l'examinons dans le paiement différé et son impact sur votre conversion.

Le principe qui sous-tend tout cela est simple : chaque client qui arrive à votre étape de paiement a déjà décidé d'acheter, et votre seul travail consiste à ne pas vous interposer entre lui et le moyen de paiement auquel il fait confiance. Sur PrestaShop, cela signifie choisir une passerelle qui porte iDEAL, Bancontact et BLIK, activer chaque rail à la fois côté compte et côté module, le cibler sur le pays qui l'utilise, et prouver que le webhook du trajet de retour se déclenche avant de célébrer. Faites correctement ces quatre choses, et les marchés qui perdaient silencieusement des commandes commencent à convertir comme votre marché domestique.

Questions fréquentes

Ai-je besoin d'un module séparé pour BLIK, iDEAL et Bancontact ?

Non, et vous ne devriez pas. Chaque rail est fourni par le module de passerelle d'un prestataire de services de paiement, et une passerelle bien choisie regroupe les trois, plus les cartes, sous une seule intégration et un seul compte de règlement. Mollie couvre les trois comme des moyens de premier plan ; Stripe les propose aux côtés des cartes ; Przelewy24 est la voie centrée sur la Pologne, avec BLIK en natif. Trois modules séparés, c'est simplement trois séries de mises à jour, trois endroits où aligner les réglages SCA, et trois risques de conflit de hook à l'étape de paiement.

Pourquoi BLIK ne s'affiche-t-il pas dans mon paiement alors que j'ai activé le module ?

Deux causes habituelles. D'abord, le niveau du compte : BLIK doit fréquemment être activé explicitement dans le tableau de bord de la passerelle (parfois après un court examen) avant de pouvoir apparaître ; activer le module PrestaShop ne suffit pas. Ensuite, la devise : BLIK est réglé en PLN, il refuse donc silencieusement de s'afficher sur un panier libellé dans une devise qu'il ne peut pas traiter. Vérifiez que le PLN existe et est activé dans International → Localisation → Devises, et que BLIK est bien activé dans le tableau de bord du prestataire.

Le client a payé avec iDEAL, mais la commande reste en attente : que s'est-il passé ?

Le trajet de retour s'est terminé dans le navigateur, mais le webhook serveur à serveur de la passerelle n'a pas atteint votre boutique ; la commande n'est donc jamais passée à l'état payé. La commande est confirmée par le webhook, pas par l'arrivée du client sur votre page de succès. Vérifiez que l'URL de webhook/rappel du module est accessible publiquement, qu'elle renvoie rapidement un 200, et qu'aucun CDN, aucune couche de cache ni aucun module de sécurité ne se trouve devant elle pour soumettre le POST de la passerelle à une vérification ou le réécrire.

Quelle passerelle choisir si la Pologne est mon marché principal ?

Privilégiez Przelewy24 : il est natif BLIK et centré sur les virements bancaires polonais, ce qui en fait l'option la plus adaptée lorsque la Pologne est votre centre de gravité. Si vous avez aussi besoin d'une forte couverture cartes et internationale dans la même boutique, Stripe prend en charge BLIK (en PLN, sous réserve d'activation du compte) aux côtés des cartes, ce qui peut être le choix le plus simple sous un seul toit. Le guide de configuration Przelewy24 détaille le parcours centré sur la Pologne de bout en bout.

Ces rails à redirection ont-ils encore besoin de 3-D Secure / SCA ?

Ils sont déjà construits autour de ce principe. iDEAL, Bancontact et BLIK sont des rails européens relevant de PSD2, et l'étape de redirection vers la banque (ou de confirmation dans l'application) est l'authentification forte. Laissez SCA active dans la passerelle : la désactiver n'accélère rien, elle casse le parcours. Pour la carte bancaire de repli proposée avec ces rails, la même passerelle gère 3-D Secure pour vous ; vous n'avez rien à coder à la main.