O hábito de um a um
Alguns operadores pagam aos comerciantes criando cada payout individualmente: um operador abre um formulário, introduz o montante e o destino, e envia. Não existe uma etapa de validação em lote nem uma fase de aprovação separada antes de o dinheiro ser movimentado. Para volumes baixos, isto parece rápido. À medida que o número de comerciantes e a frequência dos payouts aumentam, cada payout continua a depender de uma pessoa a preencher corretamente um registo, sem nada estrutural a verificá-lo antes de os fundos saírem.
Um payout é uma transação, não um registo isolado
Na omwio, os payouts não são uma ação separada e mais leve do que os pagamentos. Estão integrados no mesmo modelo de transações que pagamentos, trocas (exchanges), reembolsos e chargebacks: um modelo de estados partilhado, um token público e um mapeamento de estados único e consistente em toda a plataforma. Um payout criado hoje tem o mesmo ciclo de vida e a mesma visibilidade que qualquer outra transação que um gestor ou comerciante consulte — não desaparece num formulário que foi submetido e esquecido.
As carteiras mostram o que um payout afeta antes de ser movimentado
Cada comerciante tem carteiras multimoeda com histórico de saldo e visibilidade de reservas. Isto significa que um payout nunca é um número isolado introduzido numa caixa — está associado a uma carteira específica, numa moeda específica, com um histórico visível de como o saldo chegou até ali e do que está atualmente retido em reserva. Um gestor consegue sempre responder de onde veio um determinado montante e o que está retido, precisamente o contexto que um processo um a um não tem forma estrutural de evidenciar.
As permissões decidem quem pode agir, e tudo é registado
O modelo de acesso da omwio desce até às ações individuais em cada painel, com autenticação de dois fatores delimitada por tenant, controlos de sessão e um registo de toda a atividade administrativa. Isto permite separar quem pode criar uma transação de quem detém acesso mais amplo, e significa que qualquer ação realizada sobre um payout pode ser atribuída posteriormente a quem a executou. Um processo construído em torno de uma pessoa a criar diretamente cada payout não dispõe de um registo equivalente de quem fez o quê, a menos que esse registo seja construído e mantido em separado.
A reconciliação é onde as lacunas são detetadas
O módulo de contabilidade e reconciliação liga novamente os payouts à contabilidade. As liquidações (settlements) fazem corresponder os payouts aos comerciantes com um MID identificado, os extratos dos fornecedores são confrontados com as transações da plataforma por montantes, referências e janelas temporais, e a tesouraria mostra os fundos reservados, bloqueados e livres por moeda em qualquer momento. É nesta fase que um payout criado sem qualquer verificação estrutural acaba por ser confrontado com o que efetivamente foi liquidado — e é aqui que eventuais diferenças entre os dois são mais fáceis de detetar precocemente, em vez de numa investigação de fecho de mês.
O que isto muda na prática
A diferença não está na velocidade de um único payout — está no que passa a existir em torno desse payout depois: um histórico de estados, um registo na carteira que mostra o saldo de onde saiu, um registo de quem agiu sobre ele, e um processo de reconciliação que o confronta com os extratos dos fornecedores. Nada disto substitui o critério de um operador; apenas dá a esse critério um registo em que se apoiar.
