Un checklist de pruebas de formulario de pago es la diferencia entre lanzar una tienda y lanzar una incógnita. Un formulario de pago es una de las pocas pantallas donde un defecto se convierte directamente en dinero perdido o en una incidencia de seguridad, así que conviene recorrerlo con una lista en la mano en lugar de confiar en la memoria. La buena noticia es que la superficie que hay que probar es finita, conocida y bastante aburrida de recorrer. Lo que sigue es una matriz de casos para repasar de arriba abajo antes de dar por cerrada una integración.
Antes de escribir la primera prueba
Nada de lo que viene después funciona sin un entorno en condiciones. Confirma, antes de empezar, que estás usando claves de pruebas y no de producción, que tienes un conjunto de datos propio con números de estructura correcta y nunca emitidos guardado junto a los casos, y que puedes inspeccionar las respuestas de la pasarela sin adivinar.
Conviene además fijar por escrito qué significa terminado. Una definición razonable: el cargo se crea una sola vez, el estado del pedido queda correcto en la base de datos, el cliente recibe una confirmación coherente y existe un camino probado para devolver el dinero.
¿Qué estados hay que cubrir en la matriz?
Estos son los desenlaces que una integración real acaba encontrando. Si ninguno te resulta familiar, la prueba se ha quedado corta.
| Estado | Qué hay que comprobar |
|---|---|
| Éxito inmediato | Cargo creado una vez, pedido confirmado, aviso enviado |
| Rechazo del emisor | Mensaje comprensible, carrito intacto, sin cargo fantasma |
| Error de red o tiempo de espera | Reintento seguro, sin duplicados, estado reconciliado |
| Autenticación reforzada superada | Retorno correcto, pedido desbloqueado |
| Autenticación abandonada | El pedido no queda colgado y se puede reintentar |
| Cancelación por el usuario | Sin cargo y sin reserva de inventario |
| Doble envío | Una sola operación aunque se pulse el botón dos veces |
| Recarga a mitad del pago | El estado se recupera del servidor, no de la pantalla |
La última fila es la que más defectos descubre en aplicaciones de una sola página, porque el estado del pago suele vivir en memoria y desaparece con la pestaña.
¿Qué debe pasar cuando la tarjeta es rechazada?
Un rechazo no es un error del programa, es un desenlace normal. Lo que se prueba aquí es la traducción: del código que devuelve la pasarela al mensaje que lee la persona.
Separa los rechazos que el usuario puede resolver —un número mal tecleado, una fecha vencida, un código de seguridad incompleto— de los que no dependen de él, como los fondos insuficientes o una tarjeta bloqueada. Los primeros deben señalar el campo concreto; los segundos, ofrecer cambiar de tarjeta o de medio de pago. En ninguno de los dos casos conviene mostrar el código técnico en bruto, y en ninguno el formulario debe vaciarse: pedir otra vez la dirección de envío después de un rechazo es una forma segura de perder la venta.
Prueba también el rechazo repetido. Si alguien lo intenta tres veces con la misma tarjeta, la aplicación debe dejar de insistir o al menos no acumular cargos ni bloquear la cuenta por sospecha.
Idempotencia, reintentos y tiempos de espera
Aquí aparecen los cobros duplicados, que son el defecto más caro de todo el formulario. La regla es sencilla de enunciar: toda petición que crea un cargo debe llevar una clave de idempotencia, de modo que repetir la misma petición no cree una segunda operación.
En las pruebas, fuerza las situaciones que la producen: pulsar el botón dos veces seguidas, usar el botón Atrás y reenviar, abrir el pago en dos pestañas, cortar la conexión justo después de enviar. Después compara el número de cargos creados con el número de pedidos.
Sobre los reintentos, distingue dos casos. Un error de red es un no lo sé y merece un reintento con espera creciente. Un rechazo definitivo es un no y no debe reintentarse automáticamente: repetirlo no cambia el resultado y multiplica las comisiones y las alertas antifraude.
Devoluciones y capturas parciales
La devolución del dinero se prueba mucho menos de lo que se usa en producción. Cubre al menos estos escenarios: devolución total, devolución parcial única, varias devoluciones parciales que suman el importe original y una que intenta superarlo. Comprueba también qué ocurre al devolver una operación que nunca llegó a capturarse, y la devolución solicitada mucho después del cobro, cuando la tarjeta ya ha caducado.
Para cada caso conviene saber quién puede dispararlo desde la interfaz, qué queda escrito en el historial del pedido y qué documento recibe el cliente. Si el producto permite capturar un importe distinto del autorizado, prueba esa diferencia de forma explícita: es un punto donde los redondeos se equivocan con una facilidad sorprendente.
Autenticación reforzada y accesibilidad
La autenticación reforzada introduce a un tercero en mitad del flujo y, con él, todas las formas de volver mal. Prueba la ruta completa de ida y vuelta, no solo la pantalla del banco. Los cuatro desenlaces que hay que automatizar son: superada sin intervención, exigida y completada, rechazada por el titular y abandonada a medias. En los dos últimos, verifica que el pedido no queda bloqueado para siempre, que el inventario se libera y que un reintento posterior no genera un segundo cargo.
En accesibilidad, el formulario de pago es una de las pantallas donde tiene más impacto económico, porque un campo que no se puede rellenar es una venta perdida. Comprueba que cada campo tiene su etiqueta asociada, que los mensajes de error se anuncian a los lectores de pantalla y que todo el flujo se completa solo con el teclado.
Y no bloquees el pegado: la gente copia el número de su gestor de contraseñas, y bloquearlo solo consigue que abandone. Si el formulario valida la dirección de facturación, revisa antes cómo se comportan los datos de prueba de direcciones y códigos postales, porque el desajuste entre ambos es una fuente clásica de rechazos simulados: direcciones y códigos postales que no cuadran.
Para quien programa
Cerrar la lista es fácil; mantenerla útil requiere un poco de disciplina. Estas decisiones hacen que la batería siga sirviendo dentro de un año.
- Un caso por desenlace, no por número. Organiza las pruebas por el estado que quieres provocar y guarda junto a cada una los datos que lo producen.
- Estado del pago en el servidor. Si la pantalla es la única que recuerda en qué punto va la operación, una recarga la pierde. El servidor debería poder reconstruir el estado a partir del identificador del pedido.
- Clave de idempotencia en todas las peticiones que crean un cargo. Es la defensa más barata contra el duplicado y la única que funciona cuando la red falla justo después de enviar.
- Datos de prueba sintéticos y fijos. Números con estructura válida y nunca emitidos, guardados dentro del proyecto y etiquetados como falsos, para que la prueba sea reproducible y el repositorio no contenga nada sensible.
- Revisión de registros. Después de la batería, comprueba que ningún registro, traza ni aviso contiene el número completo ni el código de seguridad.
- Comprobación manual del camino corto. Una vez por release, recorre el pago a mano en un navegador real. Automatizar todo da confianza y a veces oculta un paso que solo falla con el ratón.
La combinación que mejor funciona es la de siempre: pruebas automáticas para lo repetitivo y una revisión humana breve para lo que cambia de forma.
Siguientes pasos
Con la matriz cubierta, el trabajo pendiente suele estar en los datos. El generador produce lotes de tarjetas con estructura válida y nunca emitidas para cada marca, y el artículo sobre tarjetas de prueba de la pasarela explica qué desenlaces se pueden provocar a propósito. Si el entorno que vas a usar contiene datos reales, empieza por las notas sobre datos de prueba y cumplimiento. Y si estás construyendo la validación, el artículo sobre validar un número de tarjeta reúne el orden de comprobaciones que evita los errores más comunes.