Por qué un pago rechazado rara vez explica el motivo

Un pago rechazado rara vez explica el motivo porque cada PSP reporta los rechazos en su propio formato, y porque "rechazado" suele agrupar tres problemas distintos: rechazos del banco, datos incorrectos del cliente y errores técnicos. Relaciona cada respuesta original con una lista corta de motivos, guarda el mensaje original al lado y sabrás qué problema estás resolviendo.

¿Por qué cada PSP reporta los motivos de rechazo de forma distinta?

Abres tu panel, encuentras un pago rechazado y el motivo dice "Do not honor". O "Error 05". O una frase en portugués. O nada.

Un proveedor devuelve códigos numéricos. Otro devuelve texto libre. Un tercero transmite el mensaje original del banco emisor, en el idioma del país donde está el banco. "Insufficient funds", "Fondos insuficientes" y "Saldo insuficiente" pueden describir el mismo rechazo.

Cada PSP traduce las respuestas de los emisores, sus propias decisiones de riesgo y sus propios errores técnicos a su propio formato. Con un PSP, tu equipo aprende el vocabulario. Con varios, el reporte de principales motivos de rechazo se convierte en cientos de textos con los que nadie puede actuar.

¿Qué hay realmente detrás de un pago rechazado?

Cuando revisamos listas de rechazos, casi todo cae en uno de tres grupos:

1. Rechazos del banco. Fondos insuficientes, rechazo del emisor, límite alcanzado, sospecha de fraude. El emisor o el motor de riesgo del proveedor revisó el pago y dijo que no.
2. Problemas de datos. La solicitud estaba mal. Nadie rechazó el pago.
3. Errores técnicos. Un tiempo de espera agotado, un proveedor no disponible, un problema de configuración en la integración. Tampoco nadie rechazó nada.

Los problemas de datos son el grupo que más se confunde con rechazos del banco. Casos que vemos a menudo:

• El país no coincide con la ciudad o el código postal.
• El documento de identidad tiene un formato incorrecto para el país.
• Al número de teléfono le falta el código de país, o lo tiene dos veces.
• El campo del nombre contiene un correo, un número o una sola letra.

La mayoría de los paneles muestran los tres grupos como "rechazado".

¿Por qué importa la diferencia?

Si un tercio de tus rechazos son en realidad errores de datos o técnicos, tu tasa de aprobación te está contando una historia equivocada. Podrías cambiar de PSP cuando la solución es un campo de tu formulario de pago. O culpar a tu integración cuando el banco simplemente dijo que no.

También cambia quién tiene que actuar. Un rechazo del banco significa que el cliente reintenta más tarde o paga con otro método. Un problema de datos significa que tu equipo de producto corrige el formulario. Un error técnico significa que tus ingenieros o tu proveedor corrigen la conexión. Tres equipos, tres acciones, una sola etiqueta.

Las redes de tarjetas hacen una separación parecida. Visa agrupa sus códigos de rechazo en cuatro categorías, una de ellas para la calidad de los datos, y no permite a los comercios reintentar un rechazo cuando el emisor nunca lo va a aprobar.

¿Cómo convertir las respuestas originales en motivos de rechazo accionables?

Relaciona cada respuesta original, de cada PSP, con una sola lista corta de motivos. Una lista como esta cubre la mayoría de los rechazos con tarjeta:

Fondos insuficientes o límite alcanzado

• Grupo: rechazo del banco, del lado del cliente.
• Quién actúa: el cliente. Un reintento más tarde u otro método pueden funcionar.

Rechazo del emisor sin detalle ("Do not honor")

• Grupo: rechazo del banco, del lado del emisor.
• Quién actúa: el cliente, con su banco. Ofrece otro método en lugar de reintentar la misma tarjeta una y otra vez.

Sospecha de fraude, tarjeta perdida o robada

• Grupo: rechazo del banco, definitivo.
• Quién actúa: nadie de tu lado. No reintentes.

Autenticación rechazada por el emisor

• Grupo: rechazo del banco.
• Quién actúa: el cliente, con su banco. Si el cliente salió de la página de autenticación, es un abandono, no un rechazo.

Datos del cliente inválidos

• Grupo: problema de datos.
• Quién actúa: tu equipo de producto, con validación en el checkout.

Número de tarjeta o de cuenta inválido

• Grupo: problema de datos, definitivo para ese número. Las reglas de Visa prohíben reintentar con el mismo número de cuenta después de este rechazo.
• Quién actúa: el cliente, que necesita ingresar un número válido.

Método de pago o país no habilitado

• Grupo: error técnico.
• Quién actúa: tus ingenieros, o el equipo de alta de comercios de tu proveedor.

Proveedor o red no disponible, tiempo de espera agotado

• Grupo: error técnico.
• Quién actúa: tus ingenieros y tu proveedor. Consulta el estado final antes de reintentar, para no cobrar dos veces al cliente.

Tres reglas mantienen útil esta lista:

• Guarda el mensaje original del PSP junto al motivo asignado. Los equipos de soporte necesitan los dos.
• Nunca dejes que un error de configuración aparezca como un rechazo del cliente.
• Revisa cada semana las respuestas sin motivo asignado. Aparecen textos nuevos cuando agregas un proveedor o cuando un proveedor cambia sus mensajes.

¿Y las transferencias bancarias, Pix y los cupones en efectivo?

Los métodos locales rara vez devuelven un rechazo clásico. Fallan de otras formas:

• El cliente nunca paga la referencia y esta expira. Eso es una expiración, no un rechazo. Explicamos las reglas de expiración por método en Pagos pendientes en LATAM.
• El dinero llega pero no se puede relacionar con la orden: monto incorrecto, referencia incorrecta, número de cuenta reutilizado.
• La solicitud se rechaza antes de que el cliente la vea, a menudo por un número de documento faltante o inválido, como el CPF del pagador en Brasil.
• El cliente cancela en su banco, por ejemplo durante un pago con PSE en Colombia.

Dale a cada caso su propio motivo ("expirado", "sin identificar", "solicitud rechazada", "cancelado por el cliente") y mantenlos separados de los rechazos con tarjeta.

¿Qué guardar con cada pago rechazado?

• El código y el mensaje originales, tal como los envió el PSP.
• El PSP, el método de pago y el país.
• El motivo asignado y su grupo.
• Una línea de tiempo: creado, enviado al PSP, respuesta del PSP, estado final.
• El ID de orden del comercio, para poder vincular los reintentos de una misma orden.

Con estos campos, alguien de tu equipo de soporte puede responder "¿por qué se rechazó este pago?" sin abrir un ticket con el PSP.

¿Qué debe ver el cliente después de un rechazo?

El cliente no necesita el código original. Necesita saber qué hacer a continuación.

• Para un rechazo del banco, sugiere otro método de pago o que contacte a su banco.
• Para un problema de datos, señala el campo a corregir y conserva el resto del formulario lleno.
• Para un error técnico, indica que el problema está de tu lado y pide que lo intente de nuevo en unos minutos.
• Para una sospecha de fraude, muestra un mensaje genérico. Explicar el motivo ayuda a quien no debe.

¿Cómo revisar tus propios rechazos esta semana?

Exporta tus últimos cientos de transacciones rechazadas. Agrúpalas por motivo y clasifica cada motivo en los tres grupos de arriba. No tiene que ser perfecto.

Ejemplo: de 400 rechazos, 180 son rechazos del banco, 140 son problemas de datos y 80 son errores técnicos. Los rechazos del banco no llegan a la mitad. Tu mejora más rápida está en el formulario de pago y en la integración, y probablemente no tiene nada que ver con el PSP que usas.