Cómo se crean los Pay Customers a partir de cuentas, contactos y prospectos
Un Pay Customer es la persona o la empresa a la que REDA Pay le cobra o le paga, tal como la conoce un Pay Profile. Tu equipo nunca completa un formulario de Pay Customer antes de cobrar: la primera vez que la pantalla de pago se abre desde una cuenta, un contacto o un prospecto (el registro principal), REDA Pay crea el Pay Customer a partir de él de forma automática, con una asignación de campos que puedes leer y cambiar. Este artículo explica esa asignación, qué ocurre en los pagos siguientes y cómo se mantiene el cliente sincronizado con Payload.
Qué ocurre la primera vez
- Un miembro del personal pulsa el botón de pago en un contacto, o un cliente abre la página de pago en tu portal.
- REDA Pay busca un Pay Customer para ese registro principal en el Pay Profile elegido.
- Si no existe, lee el registro REDA Pay Process Config del objeto principal (cuenta, contacto o prospecto), arma el Pay Customer con los campos que ese registro asigna y lo guarda.
- A partir de entonces, todos los pagos desde ese registro usan el mismo Pay Customer. Cuando el cliente paga por primera vez, REDA Pay también lo registra en Payload y guarda en el registro el identificador de cliente de Payload (cifrado).
Un Pay Customer conserva un vínculo con su cuenta, contacto o prospecto, y Parent Record Id guarda el Id del registro del que proviene.
Un Pay Customer creado a partir de un prospecto. Allowed Transfer Type y Allowed Payment Methods provienen de la asignación.
Los registros de asignación
Abre Configuración → Tipos de metadatos personalizados → REDA Pay Process Config → Gestionar registros (Manage Records). El paquete incluye tres registros, uno por objeto principal:
| Registro | Source Object API Name | Asignación |
|---|---|---|
| Account - Config - Payload | Account | El nombre a partir del nombre de la cuenta; Allowed Transfer Type Receipt and Disbursement; Allowed Payment Methods Card y Bank Account; el vínculo a la cuenta |
| Contact - Config - Payload | Contact | Nombre, Email y Phone (a partir del teléfono móvil del contacto); el mismo tipo de transferencia y los mismos métodos; el vínculo al contacto |
| Lead - Config - Payload | Lead | Nombre, Email y Phone (a partir del teléfono móvil del prospecto); lo mismo; el vínculo al prospecto |
Cada registro tiene estos campos:
| Campo | Significado |
|---|---|
| Source Object API Name | El objeto principal al que se aplica el registro, por ejemplo Contact |
| Is Active | Solo se usan los registros activos. Si no hay un registro activo para un objeto, los pagos desde ese objeto se detienen con "Transaction not allowed for SObject: …" |
| Applicable To User Profiles | Opcional: nombres de perfiles de Salesforce separados por comas. Si está completo, el registro se aplica solo a los usuarios con esos perfiles y tiene preferencia sobre un registro con el campo vacío. Permite que un perfil del portal tenga una asignación distinta de la del personal |
| Customer Record Mapping | Una línea por campo de Pay Customer, con la forma FieldApiName=valor. Un valor escrito como {{FieldName}} se copia del registro principal (se admite una ruta como {{Account.Name}}); cualquier otro valor se usa tal como está escrito |
| Pay Profiles | El texto de ayuda lo indica como obligatorio, pero las pantallas de pago no lo usan: déjalo como viene en el paquete |
| Description | Notas internas |
La asignación de Contact que incluye el paquete es:
Name={{Name}}
rpay__Email__c={{Email}}
rpay__Phone__c={{MobilePhone}}
rpay__Allowed_Transfer_Type__c=two-way
rpay__Allowed_Payment_Methods__c=card;bank_account
rpay__Contact__c={{Id}}two-way es el valor guardado para Receipt and Disbursement; send-only es Receipt y receive-only es Disbursement. card y bank_account son los valores guardados para los dos métodos de pago.
Cambiar la asignación
Cambios habituales, cada uno se hace editando el registro y sus líneas de Customer Record Mapping:
| Objetivo | Cambio |
|---|---|
| Los clientes creados a partir de contactos solo pueden pagar, nunca recibir pagos | rpay__Allowed_Transfer_Type__c=send-only en el registro de Contact |
| Los residentes del portal solo pueden pagar con cuenta bancaria | Crea un segundo registro de Contact, define Applicable To User Profiles con el nombre del perfil del portal y asigna rpay__Allowed_Payment_Methods__c=bank_account |
| Usar el teléfono del trabajo del contacto en lugar del móvil | rpay__Phone__c={{Phone}} |
| Llevar tu propia referencia al cliente | rpay__Attribute_1__c={{Your_Field__c}} |
Guarda y prueba cobrando un pago desde un registro que todavía no tenga Pay Customer. Una asignación a un campo que no existe en el Pay Customer, o un valor que el campo no admite, falla en ese paso con el error que se muestra en pantalla.
Los tres registros de asignación del paquete. Edítalos directamente; agrega un segundo registro para un objeto solo cuando un perfil necesite reglas distintas.
Un cliente por registro, perfil y correo
REDA Pay incluye una regla de duplicados en Pay Customer que impide un segundo registro con el mismo Parent Record Id, el mismo Pay Profile y el mismo Email. Así, un contacto tiene un Pay Customer por Pay Profile. Dos contactos distintos con el mismo correo son clientes distintos, porque sus registros principales son distintos. Si necesitas combinar dos contactos, hazlo antes de cobrar pagos, o cuenta con dos Pay Customers.
Conversión de prospectos
Cuando se convierte un prospecto que tiene Pay Customers, REDA Pay mueve sus Pay Customers a la nueva cuenta y al nuevo contacto, y sus Pay Orders a la nueva oportunidad, para que el historial de pagos siga a la persona. El vínculo al prospecto del Pay Customer se reemplaza por los vínculos al contacto y a la cuenta.
Mantener el cliente sincronizado con Payload
Payload guarda su propia copia del nombre, el correo y el teléfono del cliente. REDA Pay envía los cambios:
- En el primer pago: el cliente se registra en Payload automáticamente.
- Desde el registro: el botón Create Payload Customer de un Pay Customer lo registra (o vuelve a enviar sus datos) sin cobrar un pago.
- Al editar: cambiar el nombre, el correo o el teléfono del Pay Customer envía el cambio a Payload en segundo plano. Si falla, el motivo aparece en Sync Error Message en el registro; corrige los datos y pulsa Create Payload Customer.
Un cliente sin Email igual puede pagar: la pantalla de pago le pide una dirección de correo y la guarda en la orden.
Errores que debes evitar
| Error | Qué ocurre | Solución |
|---|---|---|
| Desactivar el registro de Lead porque los prospectos no deberían pagar | Todo pago desde un prospecto se detiene con "Transaction not allowed for SObject: Lead" | Desactívalo deliberadamente solo si ninguna página de prospecto tiene un botón de pago |
| Asignar un campo que no existe | La creación del cliente falla con un error "Invalid field" en pantalla | Revisa el nombre de API del campo en el objeto Pay Customer |
| Asignar Allowed Payment Methods vacío | El cliente no puede pagar ni recibir pagos | Asigna al menos un método |
| Cambiar el correo del Pay Customer por uno que ya se usa para el mismo registro y perfil | La regla de duplicados impide guardar | Corrige el correo en uno de los registros |
| Esperar que la dirección del registro principal aparezca en el cliente | Solo se copian los campos asignados | Agrega las líneas de dirección a la asignación si las necesitas |
Preguntas frecuentes
Las pantallas los crean de uno en uno. Para una migración, tu administrador de Salesforce o REDA pueden crearlos con una carga de datos o un script que siga la misma asignación, y luego registrarlos en Payload.
Se usaron dos Pay Profiles activos. Cada perfil mantiene sus propios clientes.
No. La asignación se usa solo cuando se crea el Pay Customer. Actualiza también el correo del Pay Customer; ese cambio se envía a Payload.