Como os Pay Customers são criados a partir de contas, contatos e leads
Um Pay Customer é a pessoa ou empresa de quem o REDA Pay recebe dinheiro ou a quem paga, tal como é conhecida por um Pay Profile. A sua equipe nunca preenche um formulário de Pay Customer antes de receber um pagamento: na primeira vez que a tela de pagamento abre a partir de uma conta, um contato ou um lead (o registro pai), o REDA Pay cria o Pay Customer a partir dele automaticamente, usando um mapeamento que você pode ler e alterar. Este artigo explica esse mapeamento, o que acontece nos pagamentos seguintes e como o cliente se mantém sincronizado com a Payload.
O que acontece na primeira vez
- Um membro da equipe pressiona o botão Pay em um contato, ou um cliente abre a página de pagamento no portal.
- O REDA Pay procura um Pay Customer para esse registro pai no Pay Profile escolhido.
- Se não existe nenhum, ele lê o registro REDA Pay Process Config do objeto pai (Account, Contact ou Lead), monta o Pay Customer com os campos que esse registro mapeia e o salva.
- Daí em diante, todo pagamento desse registro usa o mesmo Pay Customer. Quando o cliente paga pela primeira vez, o REDA Pay também o registra na Payload e guarda o identificador de cliente da Payload (criptografado) no registro.
Um Pay Customer tem um vínculo de volta com a sua conta, contato ou lead, e o Parent Record Id guarda o Id do registro de origem.
Um Pay Customer criado a partir de um lead. O Allowed Transfer Type e o Allowed Payment Methods vieram do mapeamento.
Os registros de mapeamento
Abra Configuração → Tipos de metadados personalizados → REDA Pay Process Config → Gerenciar registros (Manage Records). Três registros vêm com o pacote, um por objeto pai:
| Registro | Source Object API Name | Mapeamento |
|---|---|---|
| Account - Config - Payload | Account | Nome a partir do nome da conta; Allowed Transfer Type Receipt and Disbursement; Allowed Payment Methods Card e Bank Account; o vínculo com a conta |
| Contact - Config - Payload | Contact | Nome, e-mail e telefone (do telefone celular do contato); o mesmo tipo de transferência e os mesmos métodos; o vínculo com o contato |
| Lead - Config - Payload | Lead | Nome, e-mail e telefone (do telefone celular do lead); o mesmo; o vínculo com o lead |
Cada registro tem estes campos:
| Campo | Significado |
|---|---|
| Source Object API Name | O objeto pai ao qual o registro se aplica, por exemplo Contact |
| Is Active | Só os registros ativos são usados. Se não houver registro ativo para um objeto, os pagamentos a partir dele param com "Transaction not allowed for SObject: …" |
| Applicable To User Profiles | Opcional: nomes de perfis do Salesforce separados por vírgula. Quando preenchido, o registro vale só para usuários com esses perfis e tem preferência sobre um registro com o campo em branco. Permite que um perfil de portal tenha um mapeamento diferente do da equipe |
| Customer Record Mapping | Uma linha por campo do Pay Customer, no formato FieldApiName=valor. Um valor escrito como {{FieldName}} é copiado do registro pai (um caminho como {{Account.Name}} é permitido); qualquer outro valor é usado como está |
| Pay Profiles | Aparece como obrigatório no texto de ajuda, mas as telas de pagamento não o usam; deixe-o como veio |
| Description | Observações internas |
O mapeamento de contato que vem no pacote é este:
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 é o valor gravado para Receipt and Disbursement; send-only é Receipt e receive-only é Disbursement. card e bank_account são os valores gravados para os dois métodos de pagamento.
Alterar o mapeamento
Alterações comuns, cada uma feita editando o registro e as suas linhas de Customer Record Mapping:
| Objetivo | Alteração |
|---|---|
| Clientes criados a partir de contatos só podem pagar, nunca receber | rpay__Allowed_Transfer_Type__c=send-only no registro de Contact |
| Moradores no portal só podem pagar por conta bancária | Crie um segundo registro de Contact, defina Applicable To User Profiles com o nome do perfil do portal e mapeie rpay__Allowed_Payment_Methods__c=bank_account |
| Usar o telefone comercial do contato em vez do celular | rpay__Phone__c={{Phone}} |
| Levar a sua própria referência para o cliente | rpay__Attribute_1__c={{Your_Field__c}} |
Salve e depois teste recebendo um pagamento de um registro que ainda não tem Pay Customer. Um mapeamento para um campo que não existe no Pay Customer, ou um valor que o campo não aceita, falha nessa etapa com o erro exibido na tela.
Os três registros de mapeamento do pacote. Edite-os no lugar; acrescente um segundo registro para um objeto só quando um perfil precisar de regras diferentes.
Um cliente por registro, perfil e e-mail
O REDA Pay inclui uma regra de duplicidade no Pay Customer que bloqueia um segundo registro com o mesmo Parent Record Id, o mesmo Pay Profile e o mesmo Email. Assim, um contato tem um Pay Customer por Pay Profile. Dois contatos diferentes com o mesmo e-mail são clientes diferentes, porque os seus registros pai são diferentes. Se você precisa mesclar dois contatos, faça isso antes de receber pagamentos, ou conte com dois Pay Customers.
Conversão de leads
Quando um lead com Pay Customers é convertido, o REDA Pay move os seus Pay Customers para a nova conta e o novo contato, e as suas Pay Orders para a nova oportunidade, para que o histórico de pagamentos acompanhe a pessoa. O vínculo do Pay Customer com o lead é substituído pelos vínculos com o contato e a conta.
Manter o cliente sincronizado com a Payload
A Payload mantém a sua própria cópia do nome, do e-mail e do telefone do cliente. O REDA Pay envia as alterações:
- No primeiro pagamento: o cliente é registrado na Payload automaticamente.
- No registro: o botão Create Payload Customer em um Pay Customer o registra (ou reenvia os seus dados) sem receber um pagamento.
- Na edição: alterar o nome, o e-mail ou o telefone do Pay Customer envia a alteração à Payload em segundo plano. Se isso falhar, o motivo aparece em Sync Error Message no registro; corrija os dados e pressione Create Payload Customer.
Um cliente sem Email ainda pode pagar: a tela de pagamento pede um endereço de e-mail e o grava na ordem.
Erros comuns a evitar
| Erro | O que acontece | Solução |
|---|---|---|
| Desativar o registro de Lead porque leads não devem pagar | Todo pagamento a partir de um lead para com "Transaction not allowed for SObject: Lead" | Desative de propósito só se nenhuma página de lead tiver um botão Pay |
| Mapear um campo que não existe | A criação do cliente falha com um erro "Invalid field" na tela | Confira o nome de API do campo no objeto Pay Customer |
| Mapear Allowed Payment Methods para nada | O cliente não consegue pagar nem receber | Mapeie pelo menos um método |
| Editar o e-mail do Pay Customer para um já usado no mesmo registro e perfil | A regra de duplicidade bloqueia o salvamento | Corrija o e-mail em um dos registros |
| Esperar que o endereço do registro pai apareça no cliente | Só os campos mapeados são copiados | Acrescente as linhas de endereço ao mapeamento se precisar delas |
Perguntas frequentes
As telas os criam um de cada vez. Para uma migração, o administrador do Salesforce ou a REDA podem criá-los com uma carga de dados ou um script que siga o mesmo mapeamento e depois registrá-los na Payload.
Foram usados dois Pay Profiles ativos. Cada perfil mantém os seus próprios clientes.
Não. O mapeamento só é usado quando o Pay Customer é criado. Atualize também o e-mail do Pay Customer; essa alteração é enviada à Payload.