Por que dealer payment flows não são e-commerce checkouts

O journey começa com uma conta, não um carrinho

Um dealer pode ter vários invoices, credits, limits e negotiated terms. O payment experience precisa desse context antes de mostrar payment methods.

Partial e split settlement são normais

Pagar parte do balance, agrupar invoices ou alocar um payment entre obrigações são core flows, não edge cases.

Authorization pode ser organizacional

Quem inicia o pagamento pode não ter authority para aprovar valores altos. Roles, account permissions e approval workflows complementam payment authentication.

Reconciliation deve fechar o account loop

Successful payment deve atualizar invoices e balance corretos e permanecer traceable até settlement. Allocation manual cria balances stale mesmo após o dinheiro chegar.

Modele obrigações separadas de payment attempts

Uma conta de dealer pode ter invoices, credits, past-due items, disputed amounts e payment terms. Essas obrigações existem com ou sem payment attempt. Separar obligation state de payment execution permite ao portal mostrar a conta correta e a finance entender o que cada pagamento deve liquidar.

A relação também suporta one-to-many e many-to-one: um payment cobre várias invoices, uma invoice recebe vários partial payments e um credit reduz obrigação sem payment. Usar order ou invoice ID como payment identity não representa essas relações corretamente.

Torne allocation rules explícitas

O sistema deve saber se dealer escolhe allocation, se o negócio usa oldest-due-first, se aceita partial amounts e como credits são consumidos. Allocation policy afeta customer experience e accounting, então não deveria ser reconstruída manualmente depois do recebimento.

Quando houver exceção, preserve intended allocation como evidência mesmo que finance a mude depois. Assim fica possível explicar por que balance mudou e distinguir customer intent de internal correction.

Desenhe approvals ao redor da organização, não só do user

Usuários B2B agem por contas e entidades legais. Permissions podem depender de branch, role, amount threshold, payment method ou second approver. Authentication prova identidade; authorization define se aquela pessoa pode realizar a ação financeira para aquela conta.

Approval flows devem preservar payment intent enquanto aguarda approval para que o final payer não reconstrua a transaction. Audit evidence deve ligar initiator, approver, policy e execution result.

Conecte self-service a finance operations

Um portal cria leverage real quando ações atualizam os sistemas usados por finance. Payment status, invoice allocation, balance, receipt, settlement references e exceções devem voltar ao ERP ou source of truth. Caso contrário o portal tira trabalho do suporte e cria trabalho de reconciliation.

Meça self-service por outcomes financeiros concluídos, não por visitas. Percentual de balances pagos sem ajuda, time from due date to collection, allocation exceptions e support contacts por journey são métricas mais úteis.