El journey empieza por una cuenta, no por un carrito
Un dealer puede tener múltiples invoices, credits, limits y negotiated terms. La experiencia debe cargar ese contexto antes de ofrecer payment methods.
Partial y split settlement son normales
Pagar parte del balance, agrupar invoices o repartir un payment entre obligaciones son core flows, no edge cases.
Authorization puede ser organizacional
Quien inicia el pago puede no tener authority para aprobar un importe alto. Roles, account permissions y approval workflows complementan payment authentication.
Reconciliation debe cerrar el account loop
El pago successful debe actualizar invoices y balance correctos y seguir traceable hasta settlement. Allocation manual produce balances stale aunque el dinero haya llegado.
Modela obligaciones separadas de payment attempts
Una cuenta de dealer puede incluir invoices, credits, past-due items, disputed amounts y payment terms. Esas obligaciones existen haya o no intento de pago. Separar obligation state de payment execution permite al portal mostrar una cuenta correcta y a finance entender qué debe liquidar cada pago.
La relación también soporta one-to-many y many-to-one: un payment cubre varias invoices, una invoice recibe varios partial payments y un credit reduce obligación sin payment. Usar order o invoice ID como payment identity no representa bien estas relaciones.
Haz explícitas las allocation rules
El sistema debe saber si dealer elige allocation, si negocio aplica oldest-due-first, si admite partial amounts y cómo se consumen credits. Allocation policy afecta customer experience y accounting, por lo que no debería reconstruirse manualmente después de recibir funds.
Cuando haya excepciones preserva intended allocation como evidencia aunque finance la cambie después. Así se explica por qué cambió balance y se distingue customer intent de internal correction.
Diseña approvals alrededor de la organización, no solo del user
Usuarios B2B actúan por cuentas y entidades legales. Permissions pueden depender de branch, role, amount threshold, payment method o second approver. Authentication demuestra identidad; authorization determina si ese usuario puede hacer esa acción financiera para esa cuenta.
Approval flows deben preservar payment intent mientras está pendiente para que final payer no reconstruya la transaction. Audit evidence debe unir initiator, approver, policy y execution result.
Conecta self-service con finance operations
Un portal crea leverage real cuando sus acciones actualizan los sistemas de finance. Payment status, invoice allocation, balance, receipt, settlement references y excepciones deben volver a ERP o source of truth. Si no, el portal mueve trabajo de soporte a reconciliación.
Mide self-service por outcomes financieros completados, no visitas. Porcentaje de balances pagados sin ayuda, time from due date to collection, allocation exceptions y support contacts por journey son métricas más útiles.
Modela pagos dealer alrededor de account state.
Trata partial y multi-invoice como core flows.
Separa organizational approval y payment authentication.
Cierra el loop hasta invoice allocation.