Para probar Redsys, empieza por el entorno sandbox y los escenarios de autorización, 3DS y rechazo. Si buscas una tarjeta de prueba Redsys con caducidad y CVV, consulta la tabla de tarjetas y la configuración del sandbox. Esta guía desarrolla el plan completo de pruebas para WooCommerce o una integración API, incluidas las renovaciones de suscripciones.
Probar una integración de pagos significa comprobar que el comprador, el sistema de cobro y tu negocio terminan con el mismo resultado. Ver una pantalla de «pago realizado» es solo una parte. También debes verificar qué ocurre si el banco rechaza la operación, el cliente cierra la pestaña o una confirmación llega dos veces.
Para una empresa de Andorra que conecta su TPV con AndorPay, el objetivo es concreto: cobrar cuando corresponde, entregar una sola vez y poder explicar cualquier operación desde sus referencias. Esta guía organiza las pruebas por escenarios y resultados verificables, tanto para una aplicación propia como para WooCommerce.
Qué debe demostrar una prueba de pago
Cada prueba necesita un resultado esperado en tres lugares: la pantalla del comprador, el estado del pago y el estado del pedido o servicio. Si el pago está confirmado pero el pedido continúa pendiente, la integración todavía tiene un problema que resolver.
Añade una cuarta comprobación: el efecto de negocio. Preparar un envío, activar un acceso o enviar la confirmación debe ocurrir según la regla definida y sin duplicarse. Un estado correcto en la base de datos no basta si el almacén recibe dos órdenes de preparación.
Por ejemplo, en una compra de un recurso digital, puedes esperar un pago confirmado, un pedido pagado y un único acceso activo. Si se repite la notificación, el acceso debe seguir siendo el mismo. Este escenario convierte una idea general de «funciona» en una comprobación precisa.
Prepara un entorno que no mezcle pruebas y ventas
Utiliza las credenciales de sandbox correspondientes. En AndorPay, una clave que empieza por ap_test_ selecciona el entorno de prueba de la sesión; las claves de producción empiezan por ap_live_. El entorno de una sesión no cambia después de crearla.
Comprueba también el comercio, terminal y credenciales de Redsys utilizados para pruebas. Una clave de aplicación correcta no arregla una configuración bancaria equivocada. Si utilizas tarjeta con inSite, el origen HTTPS exacto donde se carga el formulario debe estar permitido.
Prepara un pedido de prueba reconocible, un comprador ficticio y una dirección de retorno válida. Evita que esta operación desencadene un envío real o un correo confuso a un cliente. Mantén accesible la recepción de notificaciones mediante HTTPS y utiliza el secreto de firma del entorno correspondiente.
La guía de pruebas de AndorPay reúne los datos y condiciones vigentes. Para tarjetas, consulta también los entornos oficiales de Redsys. Los datos de prueba no sirven para pagar en producción.
Herramientas: elige una para cada pregunta
No necesitas una colección de programas para empezar. Necesitas observar la petición, la respuesta, la interacción del comprador y el resultado en tu negocio.
| Herramienta | Qué permite comprobar | Qué no demuestra por sí sola |
|---|---|---|
| Cliente HTTP o cURL | Autenticación, datos enviados y respuesta de la API | Que el comprador haya pagado |
| Navegador y herramientas de desarrollo | Redirección, mensajes, errores y comportamiento móvil | El estado bancario definitivo |
| Registro del servidor | Recepción de eventos y aplicación de reglas | Lo que vio el comprador |
| Consulta de pedido y pago | Correspondencia entre referencias y estados | Que todas las incidencias estén cubiertas |
| Prueba automatizada | Repetición de escenarios controlados | Funcionamiento real de todos los dispositivos y bancos |
Empieza por una petición mínima que funcione y después intégrala en la aplicación. Así podrás distinguir un error de credenciales de un error introducido por tu código. Guarda referencias útiles para seguir la operación entre sistemas.
Crear una sesión no equivale a cobrar
En la integración REST, una respuesta de creación correcta proporciona la dirección del checkout alojado. Abre esa dirección tal como la devuelve la API. No construyas una URL aproximada ni interpretes la creación de la sesión como una venta pagada.
Verifica tres casos antes de probar tarjetas: credencial incorrecta, datos inválidos y creación válida. Los dos primeros deben producir un error comprensible y mantener el pedido sin pagar. El tercero debe conservar la relación entre pedido y sesión antes de enviar al cliente al checkout.
Respeta el contrato concreto de cada operación. Por ejemplo, POST /v1/checkouts no admite la cabecera Idempotency-Key. Añadirla como receta general para todas las peticiones provoca un error. La documentación REST explica el comportamiento de este endpoint.
Si la aplicación pierde la respuesta o recibe una situación pendiente, investiga la sesión y la operación existentes antes de crear otro cobro. Un reintento de comunicación y una nueva autorización de pago son acciones diferentes.
La matriz mínima de escenarios con tarjeta
Prueba los casos disponibles en tu entorno bancario, con sus datos de prueba específicos. El resultado esperado debe escribirse antes de ejecutar cada caso.
| Escenario | Qué debe ver el comprador | Qué debe comprobar el negocio |
|---|---|---|
| Pago autorizado | Confirmación y siguiente paso claros | Pago confirmado y entrega única |
| Autenticación adicional | Instrucciones para completar la validación | Pedido pendiente hasta conocer el resultado |
| Pago rechazado | Mensaje útil y posibilidad adecuada de continuar | Sin entrega ni marca de pagado |
| Cliente cancela | Regreso comprensible a la compra | Estado coherente con el resultado real |
| Cliente cierra la pestaña | Puede consultar posteriormente su compra | La confirmación no depende de su regreso |
| Respuesta pendiente | Mensaje de espera sin impulsar otro cobro | Consulta y resolución de la operación existente |
En el caso con autenticación adicional, prueba completarla y abandonarla. Si solo ensayas el recorrido rápido, no sabrás si la tienda recupera correctamente el control cuando el banco exige un paso más.
Después repite una compra desde móvil. Revisa teclado, desplazamiento, cambio a la aplicación bancaria y regreso al navegador. El comprador debe reconocer el producto y el total durante todo el recorrido.
El retorno del navegador no confirma el pago
Una dirección de éxito sirve para continuar la experiencia del comprador. No debe ser la única condición para entregar un pedido. La persona puede cerrar la pestaña después de autorizar; también puede volver a una dirección guardada sin haber realizado otra compra.
Comprueba que el servidor decide a partir de una confirmación verificada o de la consulta autorizada del estado. Prueba abrir de nuevo la página de retorno: no debe crear otra entrega ni cambiar arbitrariamente el resultado.
En sentido contrario, cierra el navegador después de la autorización y comprueba qué ocurre con el pedido. Si termina correctamente a través de la notificación, habrás verificado que el negocio no depende de ese último clic del cliente.
Prueba las notificaciones, incluidas las que fallan
Un webhook es una notificación enviada a tu servidor. En AndorPay debe verificarse su firma antes de aplicar efectos. La guía de webhooks detalla la validación sobre el cuerpo original y la ventana temporal admitida.
Prepara estos casos en un entorno controlado:
- Firma válida: la recepción acepta el evento y actualiza la operación correcta.
- Firma alterada: se rechaza sin modificar pedidos ni accesos.
- Marca temporal fuera de la ventana: se rechaza conforme al contrato.
- Fallo temporal del receptor: la posterior entrega puede completar el trabajo pendiente.
- Mismo evento repetido: se reconoce por su identificador y no repite la entrega.
- Eventos recibidos en distinto orden: el sistema conserva un estado coherente y no decide únicamente por el orden de llegada.
La deduplicación debe proteger también los efectos secundarios. Comprueba el correo, el acceso y la tarea de preparación, además de la fila del pedido. Un evento repetido no debería producir varias acciones comerciales equivalentes.
Para simular un receptor que falla, utiliza una instalación de pruebas. Registra qué evento quedó pendiente, cuándo volvió a recibirse y qué efecto produjo. No interrumpas deliberadamente la recepción de ventas reales para realizar este ensayo.
Si tu tienda funciona con WooCommerce
Haz la prueba desde una ventana privada y con un producto reconocible. Comprueba la configuración de pruebas del plugin, la moneda y el recorrido que utiliza realmente tu tienda. Incluye tu tipo de checkout y las extensiones que modifican campos, envíos o descuentos.
Después de pagar, revisa el estado del pedido, sus notas y la referencia de transacción. El texto de la pantalla debe coincidir con esos datos. Comprueba también que la operación pertenece al pedido correcto si tienes varias pestañas abiertas.
El plugin utiliza notificaciones y mecanismos de recuperación. Si una confirmación no llega a tiempo, revisa la conectividad del endpoint y las tareas programadas antes de concluir que el banco ha rechazado el pago. En el diagnóstico técnico, los registros andorpay-card-gateway y el grupo andorpay-card de Action Scheduler ayudan a seguir el recorrido.
La acción de sincronización del pago consulta la operación existente. Es útil para recuperar el estado; no sustituye una autorización nueva ni justifica marcar manualmente como pagado un pedido sin comprobarlo. Sigue la guía de WooCommerce para la configuración vigente.
Apple Pay, Google Pay y Bizum requieren pruebas propias
Que aparezca un botón no significa que hayas validado una autorización completa. Primero comprueba la elegibilidad del dispositivo y navegador; después, la presentación del método y finalmente el resultado del pago, cuando el entorno lo permita.
En Apple Pay, una prueba puede validar la hoja de pago y la sesión del comercio sin completar una autorización en el sandbox ordinario de Redsys. El ensayo completo depende del entorno de certificación acordado y de las capacidades habilitadas.
En Google Pay, abrir la hoja en modo de pruebas tampoco demuestra por sí solo una autorización con Redsys. Deben cumplirse las condiciones del terminal, X-PAY y el tipo de credencial de prueba descritos en la documentación.
Para Bizum, nuestra integración utiliza RTP. Verifica su disponibilidad y los escenarios del entorno correspondiente. No supongas que, ante un fallo, existe un cambio automático al flujo clásico de redirección. Anota por separado qué parte has probado y qué validación queda pendiente.
Suscripciones: ensaya también lo que sucede después del alta
Si tu negocio cobra suscripciones, una primera compra correcta no valida la renovación. Añade un ciclo de renovación, un resultado fallido y las acciones posteriores que realmente utiliza tu aplicación.
Comprueba a qué periodo corresponde el pago y cómo afecta al acceso. Por ejemplo, un intento fallido no debería crear una segunda suscripción para el mismo servicio. Define qué mensaje recibirá el cliente y qué verá la persona que atiende la incidencia.
Las operaciones disponibles dependen de la configuración de la cuenta y del contrato documentado. Una capacidad no habilitada debe devolver un resultado controlado. No conviertas ese error en una confirmación ficticia para que el recorrido parezca completo.
También separa las devoluciones de los cobros. La API de reembolsos sobre Redsys no está habilitada en el recorrido documentado de AndorPay. Una prueba debe comprobar que una operación no soportada no marca falsamente el pago como reembolsado; la gestión aplicable debe acordarse por el canal correspondiente.
Qué guardar para investigar un resultado inesperado
Prepara una ficha breve por prueba. Permite que otra persona reconstruya lo sucedido sin repetir un cobro para «ver qué pasa».
| Campo | Ejemplo de contenido útil |
|---|---|
| Escenario | Autenticación completada con navegador cerrado después |
| Entorno | Sandbox y versión de la integración |
| Referencias | Pedido, sesión, request_id y event.id, cuando existan |
| Resultado esperado | Pedido pagado y un único acceso |
| Resultado observado | Estado de pago, pedido y acción ejecutada |
| Evidencia | Hora, respuesta relevante y registro sin secretos |
| Seguimiento | Error corregido o limitación pendiente de verificar |
No incluyas claves de API, secretos, número completo de tarjeta ni código de seguridad. Conserva identificadores y mensajes necesarios para el diagnóstico. La evidencia debe explicar una operación sin convertirse en una copia de datos de pago.
Cuándo puedes dar las pruebas por terminadas
Puedes cerrar un escenario cuando el resultado esperado coincide con lo observado y los efectos se ejecutan una sola vez. Si has visto únicamente la apertura de una wallet, registra ese alcance concreto. No lo conviertas en una aprobación del método completo.
Antes de pasar a producción, revisa credenciales, dominios permitidos y recepción de eventos de ese entorno. La validación real debe tener un alcance acordado y autorización para la operación. Sandbox y producción son comprobaciones distintas.
Conserva una pequeña selección de pruebas para repetir después de actualizar el plugin, cambiar el checkout o modificar la lógica de entrega. Prioriza autorización, rechazo, confirmación duplicada y recuperación: son recorridos que afectan directamente a cobrar y atender correctamente.
Del resultado de las pruebas a una integración lista para trabajar
Si todavía estás decidiendo cómo conectar tu negocio, empieza por la diferencia entre checkout alojado y API. Si ya tienes desarrollo propio, la guía de SDKs para integrar pagos ayuda a delimitar qué resuelve la herramienta y qué sigue en tu aplicación.
En AndorPay podemos revisar contigo el recorrido que necesita tu negocio en Andorra y las comprobaciones de su conexión. Cuéntanos qué plataforma utilizas y cómo cobras para plantear una integración con resultados claros desde la primera prueba.