{"id":841314,"date":"2026-09-10T12:18:52","date_gmt":"2026-09-10T12:18:52","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=841317\/"},"modified":"2026-09-30T08:35:29","modified_gmt":"2026-09-30T08:35:29","slug":"prestashop-payment-gateway-integration","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/es\/prestashop-blog-es\/prestashop-payment-gateway-integration\/","title":{"rendered":"Integraci\u00f3n de una pasarela de pago personalizada en PrestaShop: requisitos t\u00e9cnicos, flujo de la API y desaf\u00edos reales de OPC"},"content":{"rendered":"

Integrar una pasarela de pago en PrestaShop puede parecer sencillo sobre el papel.<\/span><\/p>\n

La pasarela de pago proporciona documentaci\u00f3n de la API, credenciales de entorno de pruebas, claves de autenticaci\u00f3n, URL de devoluci\u00f3n de llamada y algunos puntos finales. El m\u00f3dulo de PrestaShop env\u00eda la solicitud de pago, recibe la respuesta, crea el pedido y redirige al cliente a la p\u00e1gina de confirmaci\u00f3n.<\/span><\/p>\n

Sin embargo, en una tienda PrestaShop real, la pasarela de pago rara vez funciona de forma aislada.<\/span><\/p>\n

En el momento en que una tienda utiliza un m\u00f3dulo de pago en una sola p\u00e1gina (OPC, por sus siglas en ingl\u00e9s), como SuperCheckout, m\u00faltiples m\u00f3dulos de pago, flujos de pago personalizados, iframes, m\u00e9todos de pago basados \u200b\u200ben JavaScript y personalizaciones adicionales del proceso de pago pueden interactuar entre s\u00ed.<\/span><\/p>\n

Aqu\u00ed es donde muchas integraciones de pago se complican.<\/span><\/p>\n

Durante el proceso de compatibilidad de la pasarela de pago, nos hemos encontrado con casos en los que un m\u00e9todo de pago funcionaba perfectamente con el proceso de pago predeterminado de PrestaShop, pero se comportaba de forma diferente dentro de OPC. Por ejemplo, un proveedor de pago pod\u00eda mostrarse correctamente en el proceso de pago est\u00e1ndar, mientras que opciones como BLIK, selecci\u00f3n bancaria o BNPL desaparec\u00edan en SuperCheckout.<\/span><\/p>\n

La lecci\u00f3n importante fue que integrar una pasarela de pago no se trata solo de hacer que la llamada a la API funcione, sino de lograr que todo el ciclo de pago funcione correctamente dentro del proceso de pago de PrestaShop.<\/span><\/p>\n

1.0 \u00bfQu\u00e9 necesita realmente una pasarela de pago personalizada?<\/strong><\/h2>\n

\"\u00bfQu\u00e9<\/a><\/p>\n

A grandes rasgos, una integraci\u00f3n de pago para PrestaShop debe gestionar cinco aspectos:<\/span><\/p>\n

    \n
  1. Mostrar el m\u00e9todo de pago al finalizar la compra.<\/span><\/li>\n
  2. Env\u00ede los datos del cliente o del pago a la pasarela de pago.<\/span><\/li>\n
  3. Recibir y validar la respuesta de la puerta de enlace.<\/span><\/li>\n
  4. Crea o actualiza correctamente el pedido de PrestaShop.<\/span><\/li>\n
  5. Redirija al cliente a la p\u00e1gina de confirmaci\u00f3n o de error correspondiente.<\/span><\/li>\n<\/ol>\n

    Un m\u00f3dulo de pago t\u00edpico extiende la clase base en lugar de hacerlo.<\/p>\n

    El m\u00f3dulo de pago normalmente funciona con ganchos como:<\/p>\n

    El hook es responsable de que el m\u00e9todo de pago est\u00e9 disponible en la p\u00e1gina de pago.<\/p>\n

    El gancho gestiona lo que el cliente ve despu\u00e9s de regresar del proceso de pago.<\/p>\n

    Por ejemplo: <\/span><\/p>\n

    public function hookPaymentOptions($params) { if (!$this->active || !$this->checkCurrency($params['cart'])) { return []; } $paymentOption = new PaymentOption(); $paymentOption ->setCallToActionText($this->l('Pagar con tarjeta')) ->setAction( $this->context->link->getModuleLink( $this->name, 'redirect', [], true ) ); return [$paymentOption]; }<\/pre>\n
    Lo importante es que este gancho no debe simplemente asumir que el m\u00e9todo de pago siempre se puede mostrar.<\/span><\/p>\n
    La moneda, el pa\u00eds, el operador, el estado del cliente, el importe del carrito, la configuraci\u00f3n del m\u00f3dulo y la disponibilidad de la pasarela de pago pueden influir en si se debe mostrar o no el m\u00e9todo de pago.<\/span><\/p>\n
    2.0 La pieza que lo cambia todo: OPC<\/strong><\/h2>\n
    El proceso de pago predeterminado de PrestaShop y un m\u00f3dulo OPC no necesariamente procesan los m\u00e9todos de pago exactamente de la misma manera.<\/span><\/p>\n
    Esta fue una de las lecciones m\u00e1s importantes que aprend\u00ed al trabajar con m\u00faltiples m\u00f3dulos de pago.<\/span>
    \n<\/span><\/p>\n
    Con el proceso de pago predeterminado, un m\u00f3dulo de pago generalmente controla la representaci\u00f3n de sus opciones de pago y el flujo de pago.<\/span><\/p>\n
    Con un OPC, el m\u00f3dulo de pago se convierte en otra capa entre el m\u00f3dulo de pago y el cliente. Esto significa que pueden interactuar los siguientes elementos:<\/span><\/p>\n
    El cliente<\/b>\r\n\u2193<\/span>\r\nOPC \/ SuperCheckout<\/b>\r\n\u2193<\/span>\r\nOpciones de pago<\/b>\r\n\u2193<\/span>\r\nM\u00f3dulo de pago<\/b>\r\n\u2193<\/span>\r\nAPI de puerta de enlace<\/b>\r\n\u2193<\/span>\r\nRespuesta de puerta de enlace<\/b>\r\n\u2193<\/span>\r\nM\u00f3dulo de pago<\/b>\r\n\u2193<\/span>\r\nOPC \/ PrestaShop<\/b>\r\n\u2193<\/span>\r\nConfirmaci\u00f3n del pedido<\/b><\/pre>\n
    Por lo tanto, un m\u00f3dulo de pago puede ser completamente correcto desde la perspectiva de la API y aun as\u00ed no comportarse correctamente dentro de un OPC.<\/span><\/p>\n
    Por eso, las pruebas de compatibilidad de pagos siempre deben incluir ambos:<\/span><\/p>\n