Reconciliar encomendas e banco: como detetar pagamentos que a sua loja julga ter e você não tem

O back office diz «Pagamento aceite» e a encomenda segue para o armazém. É o normal, e quase sempre é verdade. Mas esse estado é escrito pela sua loja, não pelo seu banco: é o que a loja julga que aconteceu. O dinheiro é confirmado por outros dois sítios, o painel do gateway e o extrato bancário, e se ninguém os comparar com as encomendas, uma discrepância pode durar meses.

Não se trata de uma raridade teórica. Já vimos lojas com encomendas «pagas» cujo dinheiro tinha ido para a conta de outra pessoa, lojas com duas encomendas por cada pagamento e lojas com pagamentos que nunca chegaram a dar origem a uma encomenda. Em todos os casos, uma reconciliação semanal tê-lo-ia detetado em poucos dias.

Porque é que encomendas, gateway e banco deixam de bater certo

Desvio de pagamentos

É o caso mais grave. Alguém com acesso aos ficheiros da loja —através de uma palavra-passe de FTP roubada ou de um módulo vulnerável— altera o módulo de pagamento para que o cliente pague num gateway do atacante. A encomenda é criada com o nome do módulo legítimo, o estado é o de sempre e no back office tudo parece normal. Há apenas uma diferença: no painel do seu gateway essa operação não existe.

A variante simples é alterar o IBAN da transferência bancária na configuração. O cliente paga, a encomenda fica pendente, o cliente insiste que pagou e você não encontra o crédito.

Notificações duplicadas ou perdidas

O gateway avisa a sua loja de que o pagamento foi concluído através de uma notificação (IPN, webhook ou o regresso do cliente à loja). Se chegarem duas ao mesmo tempo, pode acabar com duas encomendas para um só pagamento, cada uma com a sua fatura e o seu stock descontado. Se não chegar nenhuma, tem o caso contrário: um pagamento sem encomenda, e um cliente que pagou e não recebe nada.

Alterações manuais e reembolsos fora da loja

• Um funcionário marca como paga uma encomenda por transferência antes de ver o crédito.
• É feito um reembolso a partir do painel do gateway e a encomenda continua paga.
• Chega um estorno (chargeback) e a encomenda não fica a saber.

Liquidações que não são encomendas

Os gateways não transferem encomenda a encomenda: liquidam em lotes e descontam comissões, reembolsos e estornos. Por isso não é possível reconciliar o banco diretamente com as encomendas; é necessário o passo intermédio do gateway.

As duas reconciliações a fazer

Reconciliar é cruzar três fontes em dois passos:

1. Encomendas ↔ operações do gateway. Cada encomenda paga com cartão, Bizum ou PayPal tem de ter a sua operação no painel, com o mesmo montante. E cada operação cobrada tem de ter a sua encomenda.
2. Operações ↔ créditos no banco. A soma das operações de um período, menos comissões, reembolsos e estornos, tem de ser o que o gateway lhe transferiu.

O primeiro passo é o que encontra desvios e duplicados. O segundo encontra comissões inesperadas, retenções e liquidações que não chegam.

A reconciliação semanal, passo a passo

1. Exporte as encomendas pagas da semana com referência, montante total, módulo de pagamento e número de operação. No PrestaShop esse número costuma estar no pagamento da encomenda (a tabela ps_order_payment, campo transaction_id), embora alguns módulos o guardem em tabelas próprias.
2. Exporte as operações do painel de cada gateway do mesmo período, com o seu número, montante e estado.
3. Cruze pelo número de operação, não pelo montante. Duas encomendas de 49,90 € cruzadas pelo montante são dadas como certas, mesmo que uma seja falsa.
4. Tire três listas: encomendas sem operação, operações sem encomenda e montantes que não coincidem.
5. Bata as liquidações do gateway com os créditos do extrato.
6. Anote o que fez com cada diferença. Uma diferença por explicar, na semana seguinte já ninguém se lembra dela.

Transferências, pagamento contra entrega e Bizum manual

Nos métodos sem notificação automática, a encomenda passa a paga porque uma pessoa o decide. A regra é simples: só se marca como paga com o extrato à frente, nunca porque o cliente envia uma captura de ecrã do comprovativo, que se falsifica num minuto. E verifique de vez em quando se o IBAN que a sua loja mostra na confirmação da encomenda e nos emails é o seu.

Sinais de que algo está a ser desviado

• Números de operação com um formato diferente do habitual nesse gateway.
• Um gateway que nas liquidações recebe menos do que dizem as encomendas.
• Clientes que dizem ter pago e cujo pagamento não aparece em nenhum painel.
• Ficheiros do módulo de pagamento com uma data de modificação que não coincide com nenhuma atualização.
• Alterações na configuração dos gateways que ninguém da equipa se lembra de ter feito.

Porque é que isto também passa por manter a loja atualizada

O desvio de pagamentos precisa de escrever no seu servidor. As vias mais habituais são credenciais de FTP ou do painel de alojamento roubadas e módulos com vulnerabilidades conhecidas que ninguém atualizou. Uma loja com PrestaShop, PHP e módulos atualizados, e com as contas de acesso revistas, dificulta muito a vida ao atacante. A reconciliação deteta o problema; a atualização reduz as vezes em que chega a acontecer.

Checklist

• Reconciliação encomendas ↔ gateway todas as semanas, pelo número de operação.
• Reconciliação gateway ↔ banco em cada liquidação.
• Transferências marcadas como pagas só com o extrato.
• Revisão periódica do IBAN e das chaves dos gateways na configuração.
• Aviso quando os ficheiros dos módulos de pagamento mudarem.
• Registo de cada diferença e da sua resolução.

Como resolver isto no PrestaShop

O RKR Order Guard evita as encomendas duplicadas quando duas notificações do gateway chegam ao mesmo tempo e revê o histórico para encontrar as que já tem, classificando-as consoante haja um ou dois pagamentos: a que sobra passa a Cancelado e o seu stock é reposto, e os reembolsos são decididos por uma pessoa. Além disso, vigia os pagamentos desviados em duas camadas: verifica o número de operação de cada encomenda (por assinatura no Redsys, pelo formato do identificador no PayPal, PayPlug e Stripe) e guarda a impressão digital dos ficheiros dos seus módulos de pagamento para o avisar se mudarem sem uma atualização. O aviso aparece na ficha da encomenda, onde está quem a vai enviar. O RKR Security Alert completa a vigilância: guarda uma fotografia da configuração, dos módulos e dos funcionários, marca como críticas as alterações nos gateways de pagamento mesmo que sejam feitas por SQL direto e avisa-o por Telegram.