BLIK, iDEAL, Bancontact: métodos de pago locales que abren mercados locales

La cobertura de pasarelas de pago (Mollie, Stripe, Przelewy24, Adyen) refleja los métodos que estos módulos ofrecían en el momento de redactar este artículo; la disponibilidad depende de tu cuenta de comerciante, así que confirma la lista actual en el panel del proveedor antes de comprometerte.

Esta es la verdad incómoda sobre vender a otros países desde una tienda PrestaShop: en los mercados donde más pagos estás perdiendo, a menudo el cliente no puede pagarte con los métodos que ofreces. Un comprador belga con una tarjeta de débito solo Bancontact no puede introducirla en un campo de Visa. Un comprador neerlandés que lleva quince años usando iDEAL ve un formulario de tarjeta y cierra la pestaña sin hacer ruido. Un comprador polaco menor de cuarenta años busca BLIK en su móvil, no lo encuentra y asume que tu tienda es extranjera y arriesgada. No es un problema de precio ni de sellos de confianza. Es un problema de infraestructura de pago y, en PrestaShop, tiene una solución concreta y configurable.

Esta guía trata específicamente de poner BLIK, iDEAL y Bancontact, las tres vías de pago locales dominantes de Polonia, los Países Bajos y Bélgica, en marcha en un proceso de pago de PrestaShop: qué módulo de pasarela ofrece realmente cada una, dónde están los ajustes en el panel de administración y cómo mostrar cada método solo a los clientes que lo utilizan. Para el caso más amplio de por qué una combinación de pagos más amplia aumenta las ventas, consulta por qué ofrecer más opciones de pago significa más ventas; para ver un mapa país por país de lo que esperan los compradores europeos, consulta métodos de pago para el comercio electrónico europeo.

Las tres vías de pago y por qué cada una es un requisito imprescindible, no un extra

BLIK, iDEAL y Bancontact no son métodos de pago "alternativos" en sus mercados de origen: son la opción por defecto, y la tarjeta es el respaldo. La diferencia importa porque cambia la pregunta de "¿debería añadir esto?" a "¿pueden mis clientes de aquí pagarme siquiera?"

Entonces, ¿qué significa esto para tu tienda? Si vendes a estos países y no ofreces la vía de pago correspondiente, la venta perdida no aparece como una queja: aparece como un abandono del proceso de pago que no puedes explicar. El cliente que no puede pagar como paga siempre no te escribe un correo. Se va. Por eso este es el cambio de pago que merece la pena hacer antes de ajustar cualquier otra cosa en el proceso de pago.

La realidad en PrestaShop: no integras tres vías de pago, eliges una pasarela

El primer impulso es buscar "un módulo BLIK", "un módulo iDEAL" y "un módulo Bancontact". No lo hagas. En PrestaShop, cada una de estas vías se ofrece a través del módulo de pasarela de un proveedor de servicios de pago, y una sola pasarela bien elegida cubre las tres, además de las tarjetas, con una única integración, una única cuenta de liquidación y un único sistema de informes. Tres módulos separados significan tres lugares donde mantener alineados los ajustes de PCI/SCA, tres conjuntos de actualizaciones que perseguir entre versiones de PrestaShop y tres oportunidades de conflicto de hooks en el paso de pago.

La pregunta práctica, entonces, es qué módulo de pasarela ofrece cada vía de pago, porque la cobertura realmente varía, y eso es lo que debe guiar la elección según tu combinación concreta de mercados.

La cobertura y la disponibilidad cambian con el tiempo y dependen de los métodos activados en tu cuenta de comerciante, así que confirma la lista actual en el panel del proveedor antes de comprometerte; pero el patrón es estable: una tienda orientada al Benelux tiende a Mollie, una tienda orientada a Polonia tiende a Przelewy24, y una tienda que quiere tarjetas más estas vías bajo un mismo techo tiende a Stripe. Cada una tiene su propia profundidad de configuración, explicada donde corresponde: Mollie como pasarela multimétodo, configurar Przelewy24 y los pagos polacos, y la guía de integración de Stripe. Si todavía estás eligiendo un procesador principal, Stripe frente a PayPal y la comparativa completa de módulos de pago son el punto de partida correcto.

Activar las vías de pago: dónde están realmente los ajustes

Sea cual sea la pasarela que elijas, la parte de PrestaShop sigue la misma lógica. Después de instalar el módulo (Módulos → Gestor de módulos, sube el ZIP o instálalo desde el catálogo), los métodos se activan en dos lugares que los comerciantes suelen confundir:

• En el panel de la pasarela (lado Mollie/Stripe/P24): primero hay que activar la vía de pago en tu cuenta de comerciante. iDEAL y Bancontact quizá ya estén disponibles, pero deben activarse o aprobarse en el panel del PSP según tu cuenta y tu país; BLIK a menudo debe activarse explícitamente, a veces tras una breve revisión. Si un método no aparece nunca en el proceso de pago por mucho que hagas en PrestaShop, casi siempre es por esto: la vía de pago no está activada a nivel de cuenta.
• En la configuración del módulo (lado PrestaShop): abre el módulo y encontrarás una lista de métodos de pago con interruptores por método, ordenación y (en los módulos de Mollie y Adyen) reglas por país y moneda para cada método. Aquí decides qué vías se muestran y en qué orden en el paso de pago del controlador order.

Dos ajustes específicos de PrestaShop determinan el resultado. Primero, la moneda. iDEAL, Bancontact y BLIK son vías en euros/PLN: BLIK liquida en PLN, las otras en EUR. En Internacional → Localización → Monedas, asegúrate de que PLN exista y esté activado si te diriges a Polonia; un método BLIK se negará silenciosamente a mostrarse en un carrito con una moneda que no puede procesar. Segundo, SCA/3-D Secure: son vías europeas sujetas a PSD2, así que deja activa la autenticación reforzada de cliente en la pasarela: el paso de redirección al banco es la autenticación, y desactivarla no acelera nada, solo rompe el flujo.

Muestra la vía de pago correcta al cliente correcto

Este es el paso que la mayoría de las tiendas se saltan, y cuesta conversiones en silencio. Mostrar todas las vías de pago a todos los clientes convierte el paso de pago en un muro de logotipos: que un comprador francés tenga que pasar por iDEAL, Bancontact y BLIK para encontrar un campo de tarjeta es fricción, y en la pantalla final antes de la conversión la fricción sale cara. El objetivo es justo el contrario: cada cliente ve los tres o cuatro métodos que son suyos, con la tarjeta incluida como respaldo universal.

PrestaShop te da ese filtrado, y hay tres niveles de control:

• Reglas de país del módulo de pasarela. Los módulos de Mollie y Adyen permiten vincular un método a países de facturación directamente en su configuración: asigna Bancontact a Bélgica, iDEAL a los Países Bajos y BLIK a Polonia. Es la vía más limpia porque la lógica vive junto al método.
• Restricciones de pago del núcleo. La propia página Pago → Preferencias de PrestaShop permite restringir módulos por moneda, país, grupo y transportista: una matriz de restricciones donde puedes activar o desactivar un módulo de pago por dimensión. Es menos granular que las reglas por método, pero funciona con cualquier pasarela.
• Orden de hooks del módulo. El paso de pago muestra las opciones devueltas por cada módulo en el hook paymentOptions (llamado displayPayment en 1.6); aparecen en el orden que configures en el módulo o en la posición del hook. Pon primero la vía local dominante para ese mercado y la tarjeta en segundo lugar: el cliente debe ver su opción por defecto antes que el respaldo.

Si quieres que esta segmentación se perciba como algo intencionado y no como desorden, encaja de forma natural con un paso de pago limpio en un proceso de pago en una sola página, donde los métodos relevantes aparecen junto al total del pedido en lugar de quedar enterrados bajo una puerta de paso.

Pruébalo antes de fiarte: la parte que muerde en producción

Las vías de pago locales fallan de formas distintas a las tarjetas, y fallan después de que el cliente salga de tu sitio, así que una comprobación rápida de "carga" no basta. Recorre cada vía de principio a fin en el entorno de pruebas de la pasarela antes de pasar a producción:

• El viaje de vuelta. iDEAL y Bancontact usan redirecciones al banco; BLIK puede permitir introducir un código en el proceso de pago y confirmar la operación en la app bancaria. El pedido solo se confirma cuando la pasarela llama al webhook/IPN de tu tienda, no cuando el cliente vuelve. Si tu servidor bloquea la URL de callback, o una capa de caché/CDN o un módulo de seguridad se coloca delante del controlador de webhook del módulo, aparece el clásico fantasma: dinero cobrado, pedido atascado en estado pendiente/incompleto. Confirma que el webhook llega y cambia el pedido a un estado pagado.
• La redirección abandonada. Prueba qué ocurre cuando el cliente llega a la pantalla del banco y la cierra. El carrito debe seguir siendo recuperable y el pedido no debe marcarse como pagado. Aquí también es donde un seguimiento de carrito abandonado demuestra su valor, porque el abandono durante la redirección forma parte normal de estos flujos.
• Coincidencia de moneda. Haz un pedido de prueba real en PLN para confirmar que BLIK aparece y liquida, y en EUR para iDEAL/Bancontact. Que falte un método en el proceso de pago casi siempre es un desajuste de moneda o de regla de país, no un error.

Qué hace realmente el controlador de webhook

Merece la pena entender el "pedido fantasma" anterior, no solo probar que no ocurra, porque es el modo de fallo que te cuesta ventas conciliadas sin hacer ruido. En una vía con redirección, el pedido se crea en estado pendiente cuando el cliente sale hacia su banco; es la llamada servidor a servidor de la pasarela, no la vuelta del navegador, la que confirma el pago. En un módulo de PrestaShop, esa llamada llega a un front controller dedicado, y su trabajo es muy concreto: verificar que la notificación procede realmente de la pasarela y después mover el pedido a estado pagado. La forma siempre es esta:

// 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;
    }
}

Dos puntos de ese flujo son donde se rompen las tiendas reales. El paso de verificación (1) es la razón por la que nunca marcas un pedido como pagado solo porque el navegador del cliente haya vuelto a la URL de éxito: a esa URL se puede llegar sin haber pagado; la señal autorizada es el webhook verificado. Y el 200 rápido (3) es la razón por la que una CDN pesada o una capa de seguridad delante de ese controlador es peligrosa: si el POST de la pasarela recibe un desafío, se reescribe o agota el tiempo de espera, nunca obtiene su 200, el pedido nunca cambia de estado y aparece el fantasma de pagado pero pendiente. Tú no escribes este controlador, lo trae el módulo de la pasarela, pero conocer sus tres tareas te dice exactamente qué revisar cuando un pedido se queda colgado: si la URL de callback es accesible, si devuelve 200 y si hay algo delante de ella.

Cómo saber si ha funcionado

No lo juzgues por sensaciones ni por tres días de datos. Antes de añadir estas vías de pago, registra dos cifras segmentadas por país en tus analíticas: tasa de abandono del proceso de pago y conversión de carrito a pedido para los Países Bajos, Bélgica y Polonia en concreto. Cuando las vías estén activas, compara las mismas cifras por país durante al menos 30 días y con un volumen de pedidos significativo: suficiente para ver una tendencia, no ruido de una semana a otra. La mejora aquí rara vez es un aumento uniforme en todo el sitio; suele ser una recuperación clara en los mercados concretos que antes no podían pagarte, precisamente por eso los mides por separado. Sea cual sea el aumento que hayas visto citado al añadir una vía local dominante, tómalo como una orientación y deja que tus propios datos segmentados den el veredicto.

Hay otra vía de pago que merece mencionarse mientras estás en los ajustes de pago: en estos mismos mercados, el pago aplazado o "compra ahora, paga después" (Klarna en particular) aparece junto a BLIK e iDEAL en las expectativas de los compradores, y la mayoría de las pasarelas anteriores pueden activarlo de la misma manera. Si merece la pena ofrecerlo es una decisión aparte; la analizamos en compra ahora, paga después y qué significa para tu conversión.

El principio que hay debajo de todo esto es sencillo: cada cliente que llega a tu paso de pago ya ha decidido comprar, y tu única tarea es no interponerte entre esa persona y el método en el que confía. En PrestaShop, eso significa elegir una pasarela que incluya iDEAL, Bancontact y BLIK, activar cada vía tanto en la cuenta como en el módulo, dirigirla al país que la utiliza y comprobar que el webhook del viaje de vuelta se ejecuta antes de celebrarlo. Haz bien esas cuatro cosas y los mercados que perdían pedidos en silencio empezarán a convertir como lo hace tu mercado principal.

Preguntas frecuentes

¿Necesito un módulo separado para BLIK, iDEAL y Bancontact?

No, y no deberías. Cada vía se ofrece a través del módulo de pasarela de un proveedor de servicios de pago, y una sola pasarela bien elegida incluye las tres, además de tarjetas, bajo una única integración y cuenta de liquidación. Mollie cubre las tres como métodos de primera categoría; Stripe las ofrece junto a las tarjetas; Przelewy24 es la ruta centrada en Polonia, con BLIK nativo. Tres módulos separados solo significan tres conjuntos de actualizaciones, tres lugares donde alinear los ajustes de SCA y tres oportunidades de conflicto de hooks en el paso de pago.

¿Por qué BLIK no aparece en mi proceso de pago aunque haya activado el módulo?

Hay dos causas habituales. Primero, el nivel de cuenta: BLIK a menudo debe activarse explícitamente en el panel de la pasarela (a veces tras una breve revisión) antes de que pueda aparecer; activar el módulo de PrestaShop no basta. Segundo, la moneda: BLIK liquida en PLN, así que se niega silenciosamente a mostrarse en un carrito con una moneda que no puede procesar. Confirma que PLN existe y está activado en Internacional → Localización → Monedas, y que BLIK está activado en el panel del proveedor.

El cliente pagó con iDEAL pero el pedido se quedó pendiente: ¿qué ha pasado?

El viaje de vuelta se completó en el navegador, pero el webhook servidor a servidor de la pasarela no llegó a tu tienda, así que el pedido nunca cambió a pagado. El pedido lo confirma el webhook, no el hecho de que el cliente aterrice de nuevo en tu página de éxito. Comprueba que la URL de webhook/callback del módulo sea accesible públicamente, que devuelva un 200 rápido y que no haya ninguna CDN, capa de caché o módulo de seguridad delante de ella desafiando o reescribiendo el POST de la pasarela.

¿Qué pasarela debería elegir si Polonia es mi mercado principal?

Inclínate por Przelewy24: BLIK es nativo ahí y está centrado en transferencias bancarias polacas, así que es el encaje más profundo cuando Polonia es tu centro de gravedad. Si también necesitas una cobertura sólida de tarjetas y alcance global en la misma tienda, Stripe ofrece BLIK (en PLN, sujeto a activación en la cuenta) junto a las tarjetas, lo que puede ser la opción más sencilla bajo un mismo techo. La guía específica de configuración de Przelewy24 recorre de principio a fin la ruta centrada en Polonia.

¿Estas vías con redirección siguen necesitando 3-D Secure / SCA?

Ya están construidas alrededor de ello. iDEAL, Bancontact y BLIK son vías europeas sujetas a PSD2, y el paso de redirección al banco (o la confirmación en la app) es la autenticación reforzada. Deja SCA activo en la pasarela: desactivarlo no acelera nada, rompe el flujo. Para la tarjeta de respaldo junto a estas vías, la misma pasarela gestiona 3-D Secure por ti; no tienes que programar nada de eso a mano.