Cuando un pago falla: registros, alertas y recuperación
Los pagos fallan por motivos comunes (una tarjeta rechazada, una cuenta bancaria vacía, un número mal escrito) y, de vez en cuando, por motivos técnicos. REDA Pay registra cada fallo en un lugar concreto y avisa a alguien concreto. Este artículo relaciona cada fallo con el lugar donde se registra, la alerta que genera y la forma de resolverlo.
Dónde se registran los fallos
| Fallo | Se registra como | A quién se avisa |
|---|---|---|
| Se rechaza o se deniega un pago en pantalla | Una Pay Transaction con Status failed y el motivo en Error Message, bajo la orden; la orden sigue Not Processed | A la persona que está en la pantalla, de inmediato |
| Falla un enlace de pago cuando el cliente paga | Lo mismo, y además la orden sigue en Link - Active | Al propietario de la orden: notificación en la aplicación "Payment Link [P-000000] failed." |
| Falla una ejecución programada | Una transacción fallida bajo la orden hija generada | Al propietario de la programación: "Scheduled Payment [P-000000] failed."; además, un REDA Pay Log de la ejecución |
| Se cortó la conexión con Payload en medio del pago | Una transacción fallida con Process Callout Exception marcado; el pagador ve el mensaje de "unexpected exception" con un código | El trabajo de recuperación de pagos fallidos la repara; consulta Activar la recuperación de pagos fallidos |
| Un trabajo en segundo plano tuvo errores (programaciones, sincronizaciones, extractos, actualizaciones de clientes) | Un REDA Pay Log con Attention Needed marcado y los fallos adjuntos en un archivo CSV | A todos los usuarios activos que reciben los correos de administración de Salesforce, y al propietario del trabajo, por correo |
| Un pago bancario se devuelve días después | El Status de la transacción pasa a rejected con una Rejected Date | A nadie de forma predeterminada; consulta Disputas y pagos devueltos |
| No se pudo enviar a Payload el nombre, el correo o el teléfono de un cliente | Sync Error Message en el Pay Customer | A nadie; se ve en el registro |
Leer una transacción fallida
Abre la Pay Order y mira sus Pay Transactions. Un intento fallido tiene:
| Campo | Qué leer |
|---|---|
| Status | failed |
| Error Message | El motivo de Payload, con la forma "tipo de error : descripción"; por ejemplo, una tarjeta rechazada, un número de ruta no válido o una regla de cliente como "Payments are not allowed at this time for this customer." |
| Process Callout Exception | Marcado cuando se cortó la conexión: el resultado se desconoce hasta que se ejecute el trabajo de recuperación |
| Created Date | Cuándo se hizo el intento |
La orden en sí no cambia y se puede volver a pagar desde el registro con otro método.
Un intento fallido junto al reintento correcto. El registro fallido se conserva para la auditoría.
REDA Pay Logs
Cada trabajo en segundo plano que encuentra un error escribe un REDA Pay Log (RPL-000000):
| Campo | Significado |
|---|---|
| Process | Qué trabajo: órdenes programadas, sincronización de transacciones, procesamiento de extractos, transacciones faltantes, actualización de clientes |
| Start / End Datetime, Total Records, Success Records, Failed Records | Las cifras de la ejecución |
| Exception | El texto del error cuando falló el propio trabajo |
| Attention Needed | Marcado mientras haya fallos que nadie resolvió |
| Resolved Date Time | Complétalo cuando hayas atendido el registro; el registro sale de la vista Attention Needed |
| Notes & Attachments | Un archivo CSV con cada registro fallido y su error; descárgalo para ver qué órdenes o transacciones se vieron afectadas |
Cuando se crea un registro con fallos, REDA Pay envía un correo a todos los usuarios activos que reciben los correos de administración y al propietario del trabajo. El asunto es "RPL-000000 - proceso - System Asynchronous Automation Exception" y el cuerpo empieza con "ATTENTION NEEDED" y un vínculo al registro.
La app REDA Pay tiene una pestaña REDA Pay Logs con las vistas Attention Needed, Created Today y All; el tablero de REDA Pay Admin muestra la cantidad de registros que necesitan atención.
La vista Attention Needed es la revisión diaria de quien se encarga de las operaciones de pagos.
Recuperación, según la situación
| Situación | Haz esto |
|---|---|
| Pago con tarjeta o bancario rechazado | Vuelve a cobrar con otro método. La transacción fallida se conserva como historial |
| Una regla de cliente lo impidió ("not allowed for this customer", "pay method type is not allowed…") | Corrige los métodos permitidos o el tipo de transferencia del Pay Customer (consulta Reglas por cliente) y vuelve a pagar |
| Se debitó al pagador pero Salesforce muestra un intento fallido con Process Callout Exception | Espera al trabajo de recuperación (cada 15 minutos), o abre la orden y pulsa Sync Transaction para traer ya el registro de Payload. No vuelvas a procesar la orden |
| El estado de una transacción parece desactualizado | Sync Transaction en la transacción (o en la orden, para todas) la vuelve a leer en Payload |
| Falló una ejecución programada | Cobra el importe pendiente con un pago único; la programación continúa en su fecha siguiente. Si el método ya no sirve, reemplázalo; consulta Configurar un pago recurrente |
| Un registro informa muchos fallos de un mismo trabajo | Abre el CSV, corrige la causa común (una cuenta inactiva, un método eliminado, un permiso que falta) y luego completa Resolved Date Time |
| Una Statement Activity atascada en In Process | Usa Reprocess; consulta Conciliar depósitos y pagos salientes |
Sync Transaction
En una Pay Transaction: haz clic en Sync Transaction y luego en Sync. REDA Pay vuelve a leer esa transacción en Payload y actualiza el estado, el código de estado, el estado de fondeo y las fechas. En una Pay Order: la misma acción le pide a Payload todas las transacciones etiquetadas con la orden, actualiza las que tiene Salesforce y crea las que le faltan; es la versión manual del trabajo de recuperación, sin el límite de una hora.
Mensajes de error con detalle técnico
De forma predeterminada, REDA Pay muestra el detalle técnico de un error (números de línea y un seguimiento de pila) después del mensaje, porque el interruptor de la organización ERROR_STACK_TRACE viene en TRUE. Ese detalle ayuda al soporte, pero no debe aparecer en la pantalla de ningún cliente. Antes de la puesta en marcha, defínelo en FALSE; consulta Interruptores de la organización y mensajes de error.
Errores que debes evitar
| Error | Qué ocurre | Solución |
|---|---|---|
| Volver a procesar una orden después del mensaje de "unexpected exception" | Un segundo cargo | Sincroniza primero; mira las transacciones |
| Ignorar los correos Attention Needed | Las ejecuciones programadas fallidas y los errores de sincronización se acumulan sin que nadie los vea | Asigna a una persona la revisión diaria |
| Eliminar transacciones fallidas para "ordenar" | Se pierde el registro de auditoría del intento; de todos modos, las transacciones con reembolsos no se pueden eliminar | Déjalas |
| Dejar pasar más de una hora los intentos con Process Callout Exception | El trabajo de recuperación ya no los toma | Usa Sync Transaction en la orden |
Preguntas frecuentes
No. REDA Pay no envía correos a los pagadores. El pagador ve el resultado en pantalla; tu propia automatización puede enviarle un correo a partir de la transacción fallida.
Todos los usuarios activos configurados para recibir los correos de administrador de Salesforce, y el propietario del trabajo que falló.
Crea un flujo sobre REDA Pay Log (cuando Attention Needed pasa a verdadero) que publique donde quieras.