--- title: "WooCommerce Redsys Gateway 32.1.x" description: "Nueva rama 32.1.x del plugin Redsys para WooCommerce. Una versión de mantenimiento que corrige cinco problemas de seguridad y una veintena de fallos, entre ellos un pago con tarjeta guardada en InSite que podía cobrarse dos veces." url: https://plugins.joseconti.com/2026/09/09/woocommerce-redsys-gateway-32-1-x/ date: 2026-09-09 modified: 2026-09-11 author: "jconti" image: https://plugins.joseconti.com/wp-content/uploads/2026/09/woocommerce-redsys-gateway-32-1-x-scaled.jpg categories: ["WooCommerce.com"] type: post lang: es --- # WooCommerce Redsys Gateway 32.1.x > El desarrollo de esta versión ha costado 2.300 euros. El coste acumulado para este año es de 37.430 euros. El coste acumulado desde la primera versión es de 236.160 euros, pero el coste para ti es [solo la licencia](https://plugins.joseconti.com/product/plugin-woocommerce-redsys-gateway/) de 79€. Nueva rama 32.1.x del plugin Redsys para WooCommerce de [WooCommerce.com](https://plugins.joseconti.com/product/plugin-woocommerce-redsys-gateway/). ## Versiones de la rama - [32.1.0](#3210) - [32.1.1](#3211) ## 32.1.0 ### Nuevo: - El informe de estado de WooCommerce (WooCommerce – Estado) lista ahora también lo que está activado en la pestaña “Ajustes avanzados” de Redsys: notificaciones push, facturas secuenciales, códigos QR, tarjetas guardadas, sobrescritura de estados de pedido, reglas condicionales, suscripciones, conciliación por correo electrónico, los protocolos de comercio agéntico y la API de la app de gestión. Las credenciales no se imprimen nunca: de cada una se indica únicamente si está configurada o no. Se incluye al copiar el informe para enviarlo a soporte, que es justo el objetivo: una petición de soporte llega ya con la configuración dentro. - Ya puedes decidir si a tus clientes se les ofrece “Añadir una tarjeta de crédito para Suscripciones” en Mi cuenta – Métodos de pago. Hasta ahora esa opción aparecía sola en cuanto había un plugin de suscripciones activo, sin manera de quitarla, y eso no es lo que quiere toda tienda: en una tienda donde la tarjeta de la suscripción se captura siempre durante la compra, lo único que hacía era invitar al cliente a guardar una tarjeta que nunca se iba a cobrar. El nuevo interruptor está en Redsys – Ajustes avanzados – Tarjetas guardadas, viene activado para que nada cambie en las tiendas que ya lo ofrecían, y al desactivarlo se queda sola la tarjeta de 1-click. También se informa de él en el informe de estado de WooCommerce. ### Seguridad: - El plugin escribía en su propio archivo de registro la dirección de la página de “pedido recibido” de cada compra, en todos los pagos, y esa dirección contiene la clave del pedido: el testigo privado que WooCommerce pone en el enlace de pago del comprador y que este plugin exige antes de mostrar un pedido. Cualquiera con acceso de lectura al archivo de registro podía, por tanto, abrir esos pedidos y ver el nombre, el correo, el teléfono y las direcciones que contienen. Ocurría estuviera o no activado el registro de depuración en la tienda, porque ese punto concreto escribía en el log sin comprobar ese ajuste. Ahora respeta el ajuste de depuración como el resto de registros que escribe el plugin, y la clave se sustituye por “[redacted]” antes de escribir nada, de modo que no queda registrada ni con el log activado. Esa sustitución se ha aplicado después a todas las líneas de registro del plugin, y no solo a la que se reportó: alrededor de noventa líneas más repartidas por las pasarelas imprimían esas mismas direcciones siempre que el registro de depuración estuviera activo, incluidas las que vuelcan el mensaje completo enviado al banco. Los archivos de registro ya escritos siguen conteniendo esas direcciones: si los tienes, bórralos. - La página que reenvía al comprador a Redsys (y a Bizum) aceptaba cualquier número de pedido escrito en su dirección, sin comprobar que quien lo pedía fuera quien hizo ese pedido. Como los números de pedido son correlativos, alguien podía recorrerlos y leer los datos que el plugin envía al banco de los pedidos de otros clientes: nombre, correo, teléfono y las direcciones de facturación y envío, junto con el importe y la descripción de lo comprado. En ningún momento se expuso un número de tarjeta, un código de seguridad ni una clave de firma, y por esta vía no se podía pagar ni modificar nada. Esa página exige ahora la clave del pedido que WooCommerce incluye en el enlace de pago del propio comprador, de modo que una petición que no corresponde al pedido se responde con una página “Forbidden” en lugar de atenderse. La misma comprobación se ha añadido a la ventana emergente de pago de la página de finalizar compra. Reportado por el equipo de seguridad de Tivify (TVUP Streaming Media), que describió el problema con claridad y nos dio tiempo para corregirlo antes de hacerlo público. Gracias. - Los tres botones de preautorización de la pantalla de pedido (autorizar, anular y cobrar una parte) y la búsqueda de clientes de PayGold aceptaban sus peticiones sin un testigo de seguridad. La comprobación de permisos ya estaba en su sitio, así que solo un gestor de tienda o un administrador podía usarlos y nadie más podría haberlos ejecutado, pero a un administrador con la sesión ya abierta se le podía engañar para dispararlos desde otra web sin que se diera cuenta. Los cuatro llevan y verifican ahora un testigo de seguridad de WordPress, lo que cierra esa vía. - El Protocolo de Comercio Agéntico podía acabar activado sin que nadie lo hubiera elegido, en tiendas que se actualizan automáticamente. Publica direcciones con las que pueden hablar máquinas, así que está pensado para estar desactivado salvo que lo actives tú, y ahora lo está. Si lo tenías activado, para ti no cambia nada. - Se ha actualizado la librería de Google incluida en el plugin, lo que corrige dos fallos en la parte que realiza peticiones de red. ### Actualizado: - Cuando falla la renovación de una suscripción, la nota que se añade al pedido dice ahora exactamente qué paso ha fallado y con qué código de comercio y terminal se hizo el intento. Hasta ahora los seis fallos posibles escribían la misma nota, poco informativa, lo que hacía casi imposible diagnosticar una renovación fallida sin acceso a la tienda, especialmente en tiendas donde no se está escribiendo el log de depuración. - Cuando Apple Pay no consigue validar la tienda con Apple, el registro recoge ahora la explicación de la propia Apple y si los archivos del certificado se pueden leer. Apple responde con un genérico “Expectation Failed” y pone el motivo real en el cuerpo de su respuesta, que no se estaba registrando nunca, así que esos fallos eran un callejón sin salida. - El plugin distribuido ya no contiene los scripts de desarrollo y compilación del proyecto, la configuración de su entorno de pruebas local, sus directorios de editor y de hooks de git, su README para desarrolladores ni un documento interno de revisión de seguridad. Nada de eso llegaba a cargarse cuando el plugin se ejecuta, pero tampoco pinta nada en el servidor de una tienda. Lo que contiene el paquete se comprueba ahora automáticamente, antes de cada publicación, contra una lista de lo que el plugin realmente distribuye, de modo que algo que se añada al proyecto en el futuro no pueda viajar dentro del zip sin que nadie se dé cuenta. - La tarea de conciliación por correo electrónico existe ahora solo mientras esa función está activada, y solo una vez. Antes se creaba en todas las tiendas y se despertaba cada cinco minutos sin hacer nada. - Todas las traducciones vuelven a estar completas. Sesenta y nueve textos añadidos por versiones recientes seguían apareciendo en inglés: etiquetas de ajustes, el informe de estado y algunos mensajes que puede ver un comprador. Español, catalán, euskera, gallego, francés y portugués vuelven a estar al cien por cien. - El testigo que protege el enlace de “añadir una tarjeta” se compara ahora en tiempo constante, como el resto de secretos que compara este plugin. Cronometrar esa comparación a través de internet no es un ataque practicable, así que no había nada explotable; el defecto era la inconsistencia, porque esta era la única comparación que se quedó atrás cuando se migraron las demás durante el trabajo de firmas. ### Arreglado: - Con InSite, pagar con una tarjeta que el comprador tenía guardada podía cobrar el dinero y aun así mostrar el pedido como fallido. Cuando el banco aprueba un pago así sin pedirle al comprador que confirme con la app de su banco, que es lo que ocurre con una tarjeta guardada, el plugin buscaba el resultado en el sitio equivocado, no encontraba nada y trataba ese “nada” como un rechazo. El cargo ya se había hecho, así que compradores a los que se les decía que el pago había fallado pagaban una segunda vez y se les cobraba dos veces. El resultado se lee ahora de la propia respuesta firmada del banco, la misma que ya usa el resto del pago. Afectaba por igual al checkout clásico y al de bloques, y también a las renovaciones de suscripciones. Reportado por dos tiendas con pocos días de diferencia, una de ellas rastreándolo hasta la línea exacta. Gracias. - En la pasarela de tarjeta, un pago hecho con una tarjeta guardada se daba por completado con solo el número de autorización, sin comprobar la respuesta real del banco que va a su lado. Un pago rechazado que aun así llevara algo en ese campo marcaba por tanto el pedido como pagado, y la tienda enviaba la mercancía sin haber cobrado. Ahora se exige que ambos coincidan antes de completar un pedido. Si la respuesta del banco falta por completo, el pago no se completa, porque no queda nada que diga que fue aprobado; una tienda cuyo banco omita realmente ese campo puede restaurar a propósito el comportamiento anterior con el filtro redsys_allow_payment_without_ds_response, que está documentado y que no se puede usar para aceptar un pago que el banco haya rechazado. - En tiendas que usan ciertos plugins de finalizar compra, Fluid Checkout entre ellos, todos los pagos eran rechazados por Redsys con el error SIS0574. El banco exige una breve descripción del navegador del comprador con cada pago (su idioma, el tamaño de su pantalla y similares), que el plugin recoge mediante campos ocultos que añade al checkout. Esos campos se añadían en el momento en que se construía la pasarela de tarjeta, lo que en esas tiendas ocurre después de que otro plugin haya pedido ya a WooCommerce la lista definitiva de campos del checkout, y WooCommerce construye esa lista una sola vez y nunca más. Los campos, por tanto, no se creaban, no se rellenaban y no se enviaban, y el banco rechazaba el pago. Ahora se añaden en cuanto carga el plugin, antes de que nadie pueda pedir la lista, lo que afecta a todas las pasarelas que los necesitan, la de tarjeta, Bizum y las wallets, y no solo a InSite. En InSite la descripción del navegador viaja además ahora con el resto de los datos del pago en lugar de depender solo del pedido, de modo que sobrevive a un checkout que se reconstruye a sí mismo. Reportado por un integrador que ya traía el diagnóstico demostrado. Gracias. - Si un pago se cancelaba o era rechazado, el comprador volvía a la tienda pero el pedido se quedaba pendiente y el carrito no se restauraba. La dirección que el plugin le daba al banco para devolver al comprador estaba escrita en la forma que se usa para los enlaces dentro de una página web, no en la que se usa para una dirección real, así que la tienda recibía el retorno sin la referencia del pedido, sin su número y sin su testigo de seguridad, y no tenía nada que cancelar. Afectaba a Bizum, Google Pay, Apple Pay, domiciliación bancaria, transferencia, InSite y a la pasarela de tarjeta siempre que el ajuste de “volver a” esté puesto en cancelar el pedido. En MasterPass esa misma dirección se enviaba directamente vacía, por un error de escritura de un solo carácter repetido en tres líneas. Todo pasa ahora por una única pieza de código compartida, de modo que una pasarela que se añada en el futuro no pueda volver a equivocarse. - En el modo de pago en ventana emergente (modal), cancelar un pago no hacía nada y el comprador se quedaba en el carrito con el pedido pendiente. La dirección a la que el plugin enviaba al navegador se escribía en la página de una forma que el navegador interpreta como un enlace dentro de un documento y no como una dirección web, así que todo lo que iba después del primer parámetro se descartaba: la referencia del pedido, su número y su testigo de seguridad desaparecían, y WooCommerce no tenía nada que cancelar. El mismo defecto afectaba a la dirección a la que se devuelve al comprador después de pagar, donde perdía en silencio un parámetro de seguimiento. Los dos están corregidos, en la pasarela de tarjeta y en la de InSite, y el comportamiento corregido se ha verificado en un navegador real. - El checkout podía morir con un error crítico, en lugar de enviar al comprador al banco, con un cliente registrado cuya ficha de cliente no se había modificado nunca desde que se creó. El plugin construye un conjunto de datos de seguridad para el banco en cada pago, y uno de los campos es la fecha en que se modificó por última vez la cuenta del cliente, que WooCommerce deja vacía en una cuenta que no se ha tocado nunca, normalmente una creada por una importación, una migración o automáticamente por otro plugin. El plugin leía esa fecha vacía como si fuera una fecha real y la página de pago se detenía ahí. Ahora recurre a la fecha de creación de la cuenta, que es lo que significa “nunca modificada”, y la misma protección se ha añadido al código equivalente que usan las suscripciones, donde esa misma fecha vacía se estaba reportando en silencio al banco como “modificada hoy”, que es información incorrecta para sus controles de fraude. - Redsys y las demás pasarelas podían desaparecer del checkout para todo el mundo, incluidos los compradores normales, en tiendas donde la lista de “mostrar solo a estos usuarios” del modo de pruebas no se había rellenado nunca. El plugin leía ese ajuste vacío como “mostrarlo a un usuario cuyo id es nada”, que no coincide con nadie, así que el método de pago quedaba oculto para todos los visitantes. Solo afectaba a tiendas cuyos ajustes hubieran sido escritos por algo distinto de la pantalla de ajustes, una importación, una migración o la propia API de gestión del plugin, porque guardar esa pantalla a mano almacena un valor vacío distinto que nunca lo provocaba. Corregido en las nueve pasarelas que compartían el mismo código. - Las suscripciones pagadas con Apple Pay o Google Pay por un cliente sin cuenta no obtenían nunca del banco el permiso de pago recurrente, así que la primera renovación fallaba con una nota diciendo que no había tarjeta. Ocurría en tiendas donde la opción general de “permitir a los clientes crear una cuenta durante el pago” está desactivada, algo habitual en tiendas que admiten la compra como invitado: los caminos de pago de las wallets no veían la sobrescritura que hace de esa opción el propio WooCommerce Subscriptions, así que no se creaba ninguna cuenta y, sin cuenta, el permiso del banco no se podía guardar. Corregido en los cuatro sitios que lo gestionan (Apple Pay y Google Pay, tanto en el checkout clásico como en el de bloques). - El script de pago del checkout de bloques estaba compilado contra una versión de React que el propio WordPress no acepta. Una dependencia solo de desarrollo arrastraba un React más nuevo a la compilación, y WordPress rechaza los elementos producidos por él, así que el método de pago podía no llegar a aparecer en el checkout de bloques. La compilación fija ahora la versión que usa WordPress y el script se ha vuelto a generar. - El carrito y el checkout podían volverse notablemente lentos, también para visitantes no identificados, en tiendas con tarjetas guardadas o suscripciones. El ayudante interno WCRed() del plugin construía una copia nueva de su objeto global cada vez que se le llamaba, y ese objeto registra tres hooks de WordPress en el momento de construirse. WordPress no sustituye esos hooks, los añade, así que en una tienda donde el ayudante se llama una vez por cada tarjeta guardada o suscripción las mismas tres comprobaciones acababan registradas cientos de veces y se volvían a ejecutar, todas, cada vez que WooCommerce montaba la lista de pasarelas de pago disponibles. En una tienda que reportó el problema esto llegaba a unos 438 registros duplicados por carga de página y a cerca de 1,7 segundos de trabajo de PHP en la página del carrito, de los cuales solo 56 milisegundos eran consultas a la base de datos. El ayudante construye ahora ese objeto una sola vez y lo reutiliza, de modo que los hooks se registran exactamente una vez por petición. El comportamiento del plugin no cambia en nada: el objeto no guarda datos propios de cada petición. El mismo tratamiento de un objeto por petición se ha aplicado al ayudante WCPSD2(), que tenía la forma idéntica. - En una pequeña parte de las tiendas, la clave de firma de mensajes de Comercio Agéntico (UCP) se guardaba en una forma que no podía usarse nunca, así que toda comprobación de firma contra ella fallaba y el documento de clave publicado no seguía el estándar. Cuando el plugin creaba esa clave, una de sus dos coordenadas volvía de vez en cuando de OpenSSL un byte más corta de lo que exige el estándar, alrededor de 1 tienda de cada 135, y el plugin la guardaba tal cual en lugar de rellenarla. Desde ese momento la tienda no podía verificar sus propias firmas, ni podía hacerlo ningún agente externo, hasta que se rotaba la clave. La clave se guarda ahora rellenada hasta la longitud exigida, y una clave ya guardada en la forma corta se repara automáticamente la primera vez que se lee, así que ningún comerciante tiene que rotar nada. - En tiendas con PHP 8.0 o anterior, activar la conciliación por correo electrónico rompía la página con un error del servidor en lugar de simplemente no funcionar. El plugin lo comprueba ahora antes y deja una nota clara en su registro. La función en sí sigue necesitando PHP 8.1. - Las tareas en segundo plano se acumulaban en decenas de copias de sí mismas en la lista de acciones programadas de WooCommerce. Corregido en todos los sitios donde el plugin programa algo, y las copias que ya estuvieran ahí se limpian automáticamente. - Una notificación a la app móvil podía perderse sin dar ningún error si se enviaba en el momento equivocado. - Aparecían avisos de PHP en el registro del servidor en cada visita a la página de “pagar pedido”, procedentes de las pasarelas de Apple Pay y Google Pay. Para los compradores no había nada roto, pero el log de depuración de esas pasarelas no estaba registrando nada de ese paso, así que quien intentara diagnosticar un problema ahí estaba mirando un fallo y no un silencio. Reportado por un comerciante, y encontrado en tres pasarelas en lugar de en la que se reportó. Gracias. - Activar el log de depuración para investigar un problema de pago con tarjeta producía avisos en lugar de la información para la que se había activado. - El botón “Conectar con Google” de los ajustes de conciliación por correo electrónico no se mostraba nunca. Conceder el acceso ya era posible rellenando los datos de Google y pulsando “Guardar cambios”, así que esto restaura un atajo, no desbloquea la función. - El plugin enviaba a la tienda un correo diciendo “Redsys no está enviando campos de tokenización” después de pagos en los que Redsys había enviado todos y cada uno de ellos. La comprobación que hay detrás de ese aviso probaba una variable que no existe en ninguna parte del plugin, y una prueba sobre algo que no existe siempre es cierta, así que el aviso salía en cada pago que guardaba una tarjeta. Los comerciantes se lo llevaban a su banco, que respondía con razón que el terminal estaba bien. El aviso informa ahora solo de ausencias reales, e indica en el registro qué campo faltaba, la fecha de caducidad, la marca de la tarjeta o el número, en lugar de decir únicamente que faltaba algo. También ha tenido que dejar de leer la marca después de que el plugin la haya convertido en un nombre para mostrar, porque esa conversión responde “Unknown” cuando no hay marca, lo que habría convertido el aviso en uno que no podría aparecer nunca. Ese mismo bloque escribía “unknown” como número de tarjeta en el log de depuración en cada pago, por un nombre de variable con una letra de más; ahora escribe el número enmascarado real. - Buscar en la pantalla de tokens de Redsys (WooCommerce – Redsys tokens) por correo electrónico o por nombre de usuario no encontraba ninguna tarjeta guardada a partir de la vigesimoquinta. La pantalla pedía a la base de datos una página de tokens y buscaba después dentro de esa página, y como los pedía sin ningún orden concreto, esa página eran siempre los veinticinco tokens más antiguos de la tienda, así que las tarjetas guardadas recientemente, que son las únicas que alguien busca, resultaban inalcanzables. La búsqueda se hace ahora en la base de datos, sobre todos los tokens, y el listado llega de más nuevo a más antiguo. El contador que hay encima de la tabla y la lista de debajo ya no pueden discrepar, ordenar por nombre de usuario o por correo ordena ahora toda la tabla en lugar de la página visible, y la pantalla ya no carga en memoria todos los tokens de la tienda solo para contarlos, cosa que en tiendas con miles de tarjetas guardadas hacía en cada carga de página. ## 32.1.1 ### Nuevo: - Al borrar el plugin se eliminan ahora sus ajustes: la configuración de cada método de pago, los Ajustes avanzados de Redsys, la licencia y las tareas programadas de mantenimiento, de modo que una tienda que lo desinstala queda limpia. No toca nunca clientes, pedidos ni suscripciones, ni nada ligado a ellos: las tarjetas guardadas, la numeración de pedidos y facturas y los pagos que aún están en curso se conservan, así que al reinstalar el plugin continúa donde lo dejó. ### Arreglado: - Con el “Pago con 1 clic” de la pasarela de tarjeta, un cliente sin tarjeta guardada que marcaba “Guardar la información de pago” pagaba con normalidad, pero la tarjeta no se guardaba nunca. El plugin pedía al banco una referencia de tarjeta nueva mientras le decía que esa referencia ya existía, y cuando el banco la devolvía, el plugin se creía su propio mensaje y descartaba la referencia. Ahora pide correctamente una tarjeta nueva, de modo que la tarjeta se guarda, y solo la pide cuando el cliente ha marcado de verdad la casilla. El mismo desajuste existía en las suscripciones con InSite y también queda corregido. Lo reportó una tienda que ya había encontrado la causa, gracias. - Con InSite, un solo pago de suscripción podía dejar al cliente con la misma tarjeta guardada dos veces en “Métodos de pago”. El banco llega a la tienda por dos vías para un mismo pago, la respuesta al propio pago y una notificación aparte, y cada vía guardaba la tarjeta. Todos los puntos que guardan una tarjeta comprueban ahora primero si ese cliente ya tiene esa tarjeta procedente de esa misma operación (la misma referencia de tarjeta, el mismo tipo y la misma transacción) y la reutilizan. Una tarjeta que se vuelve a guardar desde una operación distinta se sigue guardando, porque es un registro de tarjeta nuevo de verdad. Las tarjetas que ya están duplicadas no se eliminan: se pueden borrar desde “Métodos de pago”. Lo reportaron con una traza completa de producción, gracias. - La opción “Añadir una tarjeta para Suscripciones” añadida en la 32.1.0 (Ajustes avanzados de Redsys – Tarjetas guardadas) funcionaba al revés: la oferta solo aparecía cuando había un plugin de suscripciones activo, y la opción únicamente podía ocultarla. Los productos pueden guardar una tarjeta de suscripción sin ningún plugin de suscripciones, y cuando esa tarjeta caducaba o era robada, el cliente no tenía forma de añadir una nueva. La oferta aparece ahora siempre que haya un plugin de suscripciones compatible activo, y también siempre que la opción esté marcada, con o sin plugin. La opción viene ahora desactivada por defecto, así que una tienda que no la toque se comporta como antes de la 32.1.0. - Con InSite, guardar una tarjeta nueva durante una compra normal con 1 clic pedía al banco una tarjeta recurrente (de suscripción) en lugar de una tarjeta de 1 clic. El valor que debía decidirlo no se rellenaba nunca, así que cada tarjeta nueva se trataba como recurrente. Los pedidos que contienen una suscripción de cualquier plugin de suscripciones compatible, o un producto configurado para guardar una tarjeta de suscripción, siguen pidiendo una tarjeta recurrente; las compras normales con 1 clic piden ahora una tarjeta de 1 clic. - Con InSite, una tarjeta guardada para una suscripción podía almacenarse con un tipo no válido, lo que la hacía invisible para todo lo que buscara tarjetas de 1 clic o de suscripción. Ahora se almacena siempre como una u otra. - Al cobrar el resto de un depósito, el plugin cargaba la primera tarjeta guardada que encontraba, de cualquier tipo. Ahora cobra la tarjeta de suscripción más reciente del cliente, que es el tipo de tarjeta pensado para cargos que inicia la propia tienda y que además recoge la tarjeta que el cliente haya sustituido desde Mi cuenta. A un cliente sin tarjeta de suscripción se le cobra exactamente igual que antes. - Después de introducir la clave de licencia y pulsar “Activar licencia”, WordPress mostraba “Lo siento, no tienes permisos para acceder a esta página”, aunque la licencia se había activado correctamente. El plugin volvía a una dirección en la que esa página no existe; ahora vuelve a la página de la licencia. Lo reportó una tienda que señaló la línea exacta, gracias. - Los pedidos pagados por transferencia bancaria o con Google Pay (redirección) se comunicaban a los agentes de compra de IA como pagos con tarjeta, porque el plugin buscaba esos dos métodos de pago con nombres equivocados. Ahora se comunican como lo que son. ### Eliminado: - Se ha eliminado la pasarela MasterPass, porque Mastercard ha cerrado el servicio MasterPass y ya no puede cobrar pagos. Desaparecen su pantalla de ajustes, su opción en el checkout, los colores de su botón exprés y su integración con el checkout de bloques. Los pedidos que se pagaron con MasterPass en el pasado no se ven afectados: conservan sus datos y se siguen mostrando como pedidos de Redsys. Sus dos ajustes sobrantes se dejan intactos en la base de datos.