Métodos de pago
Accede desde Tiendas preparadoras > Parámetros de pago > Configuración de métodos de pago.
Permite crear, editar, habilitar/deshabilitar y eliminar métodos de pago por tienda preparadora.

Listado
Filtros disponibles
| Filtro | Descripción |
|---|---|
| Métodos de pago | Desplegable para filtrar por pasarela. |
| Tienda(s) preparadora(s) | Multiselect para filtrar por tienda preparadora. |
Columnas
| Columna | Descripción |
|---|---|
| Métodos de pago | Nombre e identificador de la pasarela configurada. |
| Tienda preparadora | Tienda preparadora a la que aplica la configuración. |
| Última modificación | Fecha, hora y usuario de la última modificación. |
| Habilitar | Toggle para activar o desactivar el método de pago en esa tienda de forma inmediata, sin entrar al detalle. |
| Acciones | Tres acciones por fila: Duplicar, Ver detalle y Eliminar. |
Recomendación
Una vez configurado un método de pago para una tienda, usa Duplicar para extenderlo al resto de tiendas en lugar de configurarlo desde cero. Solo tendrás que ajustar los campos que son únicos por tienda (ver Duplicar una configuración).
Crear una configuración
Pulsa el botón Crear configuración (esquina superior derecha). El formulario se divide en dos partes: primero se selecciona el método de pago y la tienda preparadora, y en función del método seleccionado aparecen los campos de configuración específicos.
En el desplegable de Tienda preparadora solo aparecen las tiendas que aún no tienen configurado ese método de pago.
Los métodos de pago disponibles son:
- Redsys
- AddOnPayments
- Simulado
- Directo
- Finaro
- BBVA Mexico
- EvoPayments
- Openpay
Campos comunes a todos los métodos
Los siguientes campos están presentes en todos o la mayoría de los métodos. Se agrupan en dos bloques según su naturaleza.
Configuración operativa
Controlan el comportamiento del método de pago en la tienda:
| Campo | Descripción |
|---|---|
| Quiero activar el método de pago | Habilita o deshabilita el método de pago en esa tienda. Equivalente al toggle Habilitar del listado. |
| Quiero ver el método de pago en la tienda | Controla si el método de pago es visible para los usuarios en la tienda online. Se puede desactivar para métodos de uso interno o que solo se ofrecen bajo petición (p.ej. pago contra entrega). |
| Quiero que el personal de atención al cliente pueda ver el método de pago | Permite a los agentes utilizar la funcionalidad "conectar en nombre de", y que puedan ver y seleccionar este método de pago aunque no sea visible en tienda. |
Configuración técnica
Parámetros técnicos requeridos por la pasarela:
| Campo | Descripción |
|---|---|
| Clave para cifrar las comunicaciones | Clave de cifrado proporcionada por la pasarela. Es única por tienda preparadora y debe actualizarse al duplicar una configuración. |
| Días máximos pago | Número máximo de días desde hoy en que el cliente puede seleccionar una franja de entrega al usar ese método. Por ejemplo, si se configura a 5, el cliente solo podrá escoger franjas dentro de los próximos 5 días. Si se deja vacío, no se aplica ninguna restricción. Solo tiene efecto en métodos de pago con tarjeta (Redsys, AddOnPayments, Finaro, BBVA, EvoPayments, Openpay). |
| Url de notificación de pago | URL interna de TOL a la que la pasarela notifica el resultado del pago. Proporcionada por Aktios; suele ser la misma para todas las tiendas del mismo cliente. |
La mayoría de los métodos requieren configurar URLs de retorno de la pasarela, que indican a dónde redirigir al usuario tras un pago exitoso o fallido, y en algunos casos también una URL del servicio de pago. Los campos concretos varían según el método y se detallan en la sección de cada pasarela.
Campos de tokenización
Disponibles en los métodos que soportan guardado de tarjetas (Redsys, AddOnPayments, Finaro y Openpay):
| Campo | Descripción |
|---|---|
| Quiero guardar las tarjetas que utiliza el cliente | Activa la tokenización de tarjetas, permitiendo que el usuario guarde sus datos de pago y no tenga que introducirlos en cada compra. |
| Quiero activar el incremento automático en el identificador del pedido | Solo disponible en Redsys. Para pedidos con productos a peso, permite retener un importe adicional que cubre posibles variaciones entre el peso pedido y el servido. El importe final se ajusta en la confirmación del pedido. |
Campos específicos por método
Cada método de pago muestra campos adicionales según sus requisitos técnicos. A continuación se detallan los campos propios de cada uno, sin repetir los campos comunes descritos anteriormente.
Redsys
Pasarela de pago española más habitual en comercios online españoles.
| Campo | Obligatorio | Descripción |
|---|---|---|
| Identificador (Merchant Group) | Sí | Identificador del grupo de comercios. Permite que un usuario que ha guardado su tarjeta en una tienda pueda usarla en otras del mismo grupo. Mismo valor para todas las tiendas del grupo. |
| Código de comercio para la zona | Sí | Código asignado por Redsys a esa tienda preparadora. Único por tienda; debe cambiarse al duplicar. |
| Nombre que se registrará en la página del gestor de pago | Sí | Nombre que verá el usuario en la pantalla de pago de Redsys. |
| Tipo de transaccion | Sí | Define cómo se procesa el cobro: 1 = preautorización, 0 = autorización, 7 = preautenticación. |
| Tipo clave y versión merchant | Sí | Algoritmo de firma utilizado en las comunicaciones con Redsys (ejemplo: HMAC_SHA256_V1). Suele ser el mismo para todos los centros. |
| ID de terminal | Sí | Identificador del terminal en Redsys. Habitualmente 001 o 100 según configuración del banco. |
| Url de vuelta de la pasarela para un pago incorrecto | No | URL a la que redirige Redsys si el pago falla. |
| Url de vuelta de la pasarela para un pago correcto | No | URL a la que redirige Redsys tras un pago exitoso. |
| Url de vuelta de la pasarela para un pago correcto con tarjeta guardada | No | URL de retorno tras un pago exitoso usando tarjeta tokenizada. |
| Url de la página web donde se redirigirá al usuario para realizar el pago | No | URL del entorno de Redsys donde el usuario completa el pago. |
| Url del servicio de pago que se llamará para realizar el pago | No | Endpoint del servicio de Redsys que procesa el pago. |
| Url de vuelta de la pasarela para un pago incorrecto con tarjeta guardada | No | URL de retorno si el pago falla usando tarjeta tokenizada. |
| Url de vuelta de la pasarela para un pago correcto (alternativa) | No | Segunda URL de retorno para pago correcto según configuración interna. |
| Url de vuelta de la pasarela para un pago correcto con tarjeta guardada (alternativa) | No | Segunda URL de retorno para pago correcto con tarjeta tokenizada. |
| Id de suscripción proporcionado por Redsys | No | ID para el servicio de reconciliación de pedidos. |
| Secret de suscripción proporcionado por Redsys | No | Clave secreta para el servicio de reconciliación de pedidos. |
| Url del servicio para obtener información del pedido | No | Endpoint de Redsys para consultar el estado de pedidos pendientes de confirmación. |
Reconciliación de pedidos
TOL dispone de un servicio que se ejecuta cada hora para detectar pedidos pagados en Redsys cuya confirmación no llegó correctamente (por problemas de conectividad). Los tres últimos campos habilitan este mecanismo. Se configuran una sola vez y deben mantenerse idénticos en todas las tiendas. Aktios gestiona la solicitud de estas credenciales a Redsys.
AddOnPayments
Pasarela de pago que soporta múltiples métodos de cobro. Utilizada principalmente en mercados latinoamericanos.
| Campo | Obligatorio | Descripción |
|---|---|---|
| Cuenta asignada por el gestor de pago | Sí | Identificador de cuenta proporcionado por AddOnPayments. |
| Modo autorización | Sí | Define el tipo de cargo: true para cargos directos, false para el resto. |
| Código de comercio para la zona | Sí | Código asignado por AddOnPayments a esa tienda. |
| ID de terminal | Sí | Identificador del terminal en AddOnPayments. |
| Url de vuelta de la pasarela para un pago correcto | No | URL de retorno tras un pago exitoso. |
| Url de vuelta de la pasarela para un pago incorrecto | No | URL de retorno si el pago falla. |
Finaro
Pasarela de pago internacional (anteriormente conocida como Credorax). Orientada a comercios con operativa en múltiples países.
| Campo | Obligatorio | Descripción |
|---|---|---|
| Código de comercio para la zona | Sí | ID de cliente asignado por Finaro a esa tienda. |
| Tipo de transaccion | Sí | Código de operación: 10 = creación de tarjeta, otros valores = pago normal. |
| Url de vuelta de la pasarela para un pago correcto | Sí | URL de retorno tras un pago exitoso. |
| Url de vuelta de la pasarela para un pago incorrecto | Sí | URL de retorno si el pago falla. |
| Protocolo de autenticación | No | Versión del protocolo de seguridad: 01 con 3D-Secure, 02 sin 3D-Secure. |
| Tipo clave y versión merchant | No | Versión o skin de la pantalla de pago proporcionada por Finaro. |
BBVA Mexico
Pasarela de pago de BBVA México. Orientada a comercios con operativa en México a través de la plataforma mExpress.
| Campo | Obligatorio | Descripción |
|---|---|---|
| Código de comercio para la zona | Sí | BBVA Express ID del comercio asignado por BBVA. |
| Tipo de transaccion | No | Código del medio de pago según configuración de BBVA. |
| Tipo clave y versión merchant | No | Opción de financiamiento: 0 = desactivado, 1 = activado. |
| Url de vuelta de la pasarela para un pago correcto | No | URL de retorno tras un pago exitoso. |
| Url de la página web donde se redirigirá al usuario para realizar el pago | No | URL del entorno de BBVA donde el usuario completa el pago. |
EvoPayments
Pasarela de pago de Mastercard Payment Gateway Services, orientada a mercados latinoamericanos.
| Campo | Obligatorio | Descripción |
|---|---|---|
| Código de comercio para la zona | Sí | Identificador de comercio asignado por EvoPayments. |
| Nombre que se registrará en la página del gestor de pago | Sí | Nombre del comercio mostrado en el checkout de EvoPayments. |
| Versión del API REST utilizada | Sí | Versión de la API de EvoPayments a utilizar (ejemplo: 100). |
| Url de vuelta de la pasarela para un pago correcto | No | URL de retorno tras un pago exitoso. |
| Url de la página web donde se redirigirá al usuario para realizar el pago | No | URL del gateway de EvoPayments donde el usuario completa el pago. |
Openpay
Pasarela de pago de BBVA para México y otros países.
| Campo | Obligatorio | Descripción |
|---|---|---|
| Código de comercio para la zona | Sí | ID de comercio asignado por Openpay. |
| Tipo de transaccion | Sí | Define cómo se procesa el cobro: 1 = preautorización, 0 = autorización, 7 = preautenticación. |
| Url de vuelta de la pasarela para un pago correcto | No | Primera URL de retorno tras un pago exitoso. |
| Url de vuelta de la pasarela para un pago incorrecto | No | URL de retorno si el pago falla. |
| Url de vuelta de la pasarela para un pago correcto (alternativa) | No | Segunda URL de retorno para pago correcto según configuración interna. |
| Url del servicio de pago que se llamará para realizar el pago | No | Endpoint del servicio de Openpay que procesa el pago. |
| Indica si es necesario solicitar el código CVV en la operación | No | Toggle que activa la solicitud del CVV al usuario durante el pago, incluso si tiene tarjeta guardada. |
| Activa o desactiva la autenticación 3D Secure para pagos con tarjeta | No | Toggle que habilita la autenticación 3D Secure para mayor seguridad en el pago. |
| Número máximo de tarjetas posibles a tokenizar | No | Número máximo de tarjetas que el usuario puede guardar en su cuenta. |
Simulado
Método de prueba que simula el flujo de pago de forma local, sin realizar llamadas a APIs externas ni procesar cobros reales. Se utiliza exclusivamente en entornos de desarrollo y preproducción para validar la integración.
Entornos de producción
Este método no debe activarse en entornos de producción.
Directo
Método para pagos contra entrega. No realiza llamadas a pasarelas externas; el procesamiento es local e inmediato en TOL. El operador confirma el pago manualmente una vez recibida la transferencia o entregado el pedido.
Duplicar una configuración
La acción Duplicar copia todos los parámetros de una configuración existente a una nueva tienda preparadora. Es el método recomendado para extender una pasarela ya configurada a nuevas tiendas.
Al duplicar, los campos comunes a todas las tiendas se trasladan automáticamente. Solo es necesario ajustar los campos que son únicos por tienda:
- Código de comercio para la zona (
merchantId): asignado individualmente por la pasarela a cada tienda. - Clave para cifrar las comunicaciones (
key): única por tienda. - Identificador (Merchant Group) (
merchantGroup): si se quiere que la tienda comparta tokenización de tarjetas con otras, debe mantenerse el mismo valor. Si no, ajustar según corresponda. - Nombre que se registrará en la página del gestor de pago (
merchantName): si se desea un nombre específico por tienda.
Permisos
| Perfil | Roles | Qué puede hacer |
|---|---|---|
| Gestión | payment_parameters:read, :create, :write, :delete y payment_inquiry:read |
Buscar configuraciones, Crear configuración, duplicarlas, ver y editar su detalle, habilitarlas o deshabilitarlas y eliminarlas. |
| Solo consulta | payment_parameters:read y payment_inquiry:read |
Ver el listado. El icono de duplicar aparece, pero la copia no se puede guardar. No aparecen el interruptor de habilitar, el acceso al detalle, el botón de crear ni el de eliminar. |
| Sin acceso | — | La entrada de menú no aparece. Si se accede con la dirección de la pantalla, se muestra el aviso «No tiene permisos para acceder a esta sección» y se vuelve a la página de inicio. |
Detalles a tener en cuenta:
- El botón Crear configuración aparece con
payment_parameters:write, pero para guardar una configuración nueva o duplicada hace falta ademáspayment_parameters:create. - Los campos del detalle de una configuración solo se muestran con
payment_inquiry:read(Consulta de parámetros de pago). Sin ese rol, el detalle aparece vacío aunque se tengan los roles de gestión. - El rol
payment_parameters:adminincluye todos los rolespayment_parameters:*, pero nopayment_inquiry:read.