Cómo se mantienen al día los estados de los pagos
Cobrar un pago es el comienzo de su vida, no el final. Un pago bancario aceptado hoy puede ser devuelto en tres días; un pago con tarjeta puede reembolsarse desde el panel de Payload; el dinero llega a tu cuenta bancaria en un lote. REDA Pay se entera de todo esto mediante webhooks (mensajes que Payload envía a tu organización cuando ocurre algo) y actualiza los registros sin que nadie pulse un botón. Este artículo explica qué llega, qué cambia y qué hacer cuando no llega.
Los diez eventos
| Evento de Payload | Qué significa | Qué hace REDA Pay |
|---|---|---|
| payment | Se creó una transacción de pago | Vuelve a leer la transacción y actualiza la Pay Transaction |
| processed | Se procesó una transacción | Lo mismo |
| authorized | Se autorizó un importe en una tarjeta | Lo mismo |
| credit | Se creó una transacción de pago saliente (desembolso) | Lo mismo |
| refund | Se hizo un reembolso, en pantalla o en el panel de Payload | Lo mismo; un reembolso hecho fuera de Salesforce aparece como una actualización de la transacción |
| void | Se anuló una transacción | Lo mismo |
| decline | Se rechazó una transacción | Lo mismo |
| reject | Un pago bancario fue devuelto después de aceptarse | Lo mismo: la Pay Transaction pasa a rejected con una Rejected Date |
| deposit | Payload depositó fondos en tu cuenta bancaria | Crea o actualiza una Statement Activity de tipo Deposit y enumera los pagos que incluye |
| reversal | Payload retiró fondos de tu cuenta bancaria (pagos salientes, reembolsos) | Crea o actualiza una Statement Activity de tipo Payout |
Para todos los eventos salvo deposit y reversal, REDA Pay hace una sola cosa: toma el identificador de la transacción del mensaje, vuelve a leer la transacción completa en Payload y guarda lo que devuelve Payload: estado, código de estado, estado de fondeo, importes y fechas. El contenido del mensaje nunca se escribe directamente en un registro, así que un estado en Salesforce siempre refleja lo que tiene Payload. Un mensaje sobre una transacción que Salesforce nunca vio se ignora.
Diez eventos, uno por fila. Si la pestaña muestra menos, vuelve a ejecutar Setup Webhooks.
Qué cambia en los registros
| Registro | Campos que cambian | Lo provoca |
|---|---|---|
| Pay Transaction | Status, Status Code, Status Message, Funding Status, Processed Date, Rejected Date, Voided Date, importes | payment, processed, authorized, credit, refund, void, decline, reject |
| Statement Activity y sus Transaction Activities | Se crea con Statement Amount, Type, Reference Number, Logged Datetime; líneas vinculadas a Pay Transactions | deposit, reversal |
| Pay Order | Nada. El estado propio de la orden refleja el procesamiento hecho en pantalla o por el trabajo; los cambios posteriores están en la transacción | — |
El procesamiento de los webhooks se ejecuta en segundo plano, en lotes pequeños, a los pocos minutos del evento. Los errores se escriben en un REDA Pay Log.
Ejemplo práctico: la vida de un pago bancario
| Día | Evento | Qué cambia en Salesforce |
|---|---|---|
| Lun 10:00 | Un residente paga $1,251.75 en el portal | Pay Order P-052010 Immediate - Processed; T-0014610 processed, Funding Status pending |
| Lun 10:01 | Payload envía payment y processed | REDA Pay vuelve a leer T-0014610: no hay cambios visibles, ya estaba al día |
| Mar 02:00 | Payload agrupa en un lote los pagos bancarios del día para el fondeo | En el siguiente evento o sincronización, Funding Status indica batched |
| Mié 09:00 | Payload envía deposit para el lote del martes | Se crea la Statement Activity S-0000931:2026-11, de tipo Deposit, con una línea Transaction Activity vinculada a T-0014610; Status Completed, Good To Reconcile |
| Jue 15:00 | El banco del residente devuelve el pago: Payload envía reject | T-0014610 pasa a rejected, Rejected Date el jueves; P-052010 no cambia |
| Vie 09:00 | Payload envía reversal por los fondos devueltos | Una Statement Activity de tipo Payout registra el dinero que sale de tu cuenta |
Sin webhooks, Salesforce seguiría mostrando el pago como procesado y el depósito nunca aparecería.
Lo que un webhook nunca hace
| Nunca… | Porque |
|---|---|
| Cambia una Pay Order | Las órdenes registran tu instrucción; los resultados están en las transacciones y los extractos |
| Crea un pago para una orden que Salesforce no conoce | Las transacciones desconocidas se ignoran; la conciliación puede crear deliberadamente las que faltan |
| Escribe en un registro los datos del propio mensaje | REDA Pay siempre vuelve a leer en Payload, así que un mensaje mal formado o desactualizado no puede dañar un registro |
| Envía algo a tus clientes | Las notificaciones son internas, para los propietarios de las órdenes |
Cómo ver que funciona
| Comprobación | Dónde |
|---|---|
| Las transacciones cambian de estado sin sincronizaciones manuales | Abre un pago bancario reciente unos días después: Funding Status batched y, más tarde, una Statement Activity que lo nombra |
| Llegan los depósitos | Statement Activities → In Process / Pending Reconciliation se llenan después de cada depósito de Payload |
| Errores | REDA Pay Logs → Attention Needed |
| El registro de webhooks sigue existiendo | Pay Profile → pestaña Webhook Setup, diez filas; Webhook Setup Datetime [Payload] en el perfil |
El recurso manual: Sync Transaction
Cualquier transacción se puede actualizar a demanda:
- En una Pay Transaction: Sync Transaction → Sync vuelve a leer esa transacción.
- En una Pay Order: Sync Transaction → Sync le pide a Payload todas las transacciones etiquetadas con la orden, actualiza las que tiene Salesforce y crea las que le faltan.
Úsalo cuando un estado parece desactualizado, cuando un cliente dice que pagó pero no aparece ninguna transacción, o durante los primeros días, antes de verificar los webhooks. Hace exactamente lo que habría hecho un webhook.
Errores que debes evitar
| Error | Qué ocurre | Solución |
|---|---|---|
| Trabajar sin webhooks en producción | Las devoluciones, los reembolsos hechos en Payload y los depósitos nunca llegan a Salesforce | Configúralos antes de la puesta en marcha |
| Reemplazar la clave de API sin volver a registrar | Los webhooks siguen registrados con la clave anterior y dejan de llegar | Vuelve a ejecutar Setup Webhooks |
| Esperar que el estado de la orden cambie con una devolución | Cambia la transacción; la orden sigue en Processed | Usa el estado de la transacción en los informes de cobranza |
| Editar a mano el estado de una transacción | El siguiente webhook o sincronización lo sobrescribe con la verdad de Payload | Deja los estados a REDA Pay; usa Internal Comments para las notas |
Preguntas frecuentes
Payload envía el mensaje cuando ocurre el evento; REDA Pay lo procesa en minutos.
Crea un flujo sobre Pay Transaction que se active cuando Status cambie a rejected; consulta Automatizar pagos con flujos.
Sí, mediante el evento refund: se vuelve a leer la transacción original y se crea o actualiza una transacción de reembolso bajo la orden.