The journey begins with an account, not a cart
A dealer may owe several invoices, have credits on account, operate under limits or negotiated terms, and need to choose which obligations to settle. The payment experience therefore needs commercial context before it presents payment methods.
Partial and split settlement are normal
B2B payments frequently involve paying part of a balance, combining several invoices, allocating one payment across obligations or selecting installments. These are not edge cases. They are core account behaviors that should exist in the domain model rather than being repaired after payment in finance operations.
Authorization and approval can be organizational
The person initiating payment may not be the person authorized to approve a large amount. Dealer portals may therefore need user roles, account permissions and approval workflows in addition to payment authentication.
Reconciliation should close the account loop
A successful payment must update the correct invoices and account balance, generate clear evidence, and remain traceable through settlement. If allocation is manual, the customer-facing portal may show stale balances even after money has arrived.
Model obligations separately from payment attempts
A dealer account can contain invoices, credits, past-due items, disputed amounts and payment terms. Those obligations exist whether or not a payment has been attempted. Keeping obligation state separate from payment execution allows the portal to present an accurate account view and lets finance understand what a successful payment is intended to settle.
The mapping also supports one-to-many and many-to-one patterns: one payment can cover several invoices, one invoice can receive several partial payments, and a credit can reduce an obligation without any payment. Treating order or invoice ID as the payment identity cannot represent these relationships cleanly.
Make allocation rules explicit
The system should know whether the dealer chooses invoice allocation, whether the business applies oldest-due-first rules, whether partial amounts are allowed and how credits are consumed. Allocation policy affects both customer experience and accounting, so it should not be reconstructed manually after funds arrive.
When exceptions occur, preserve the intended allocation as evidence even if finance later changes it. That makes it possible to explain why an account balance changed and to distinguish customer intent from an internal correction.
Design approvals around the organization, not just the user
B2B users act on behalf of accounts and legal entities. Permissions may depend on dealer branch, role, amount threshold, payment method or whether a second approver is required. Authentication proves who the user is; authorization determines whether that user may perform this financial action for this account.
Approval flows should preserve the payment intent while approval is pending so the final payer does not need to reconstruct the transaction. Audit evidence should connect initiator, approver, policy and execution result.
Connect self-service to finance operations
A portal creates real operational leverage only when successful actions update the systems that finance uses. Payment status, invoice allocation, balance, receipt, settlement references and exceptions should flow back to ERP or the relevant source of account truth. Otherwise the portal moves work from customer support into reconciliation rather than removing it.
Measure self-service by completed financial outcomes, not portal visits. Useful metrics include percentage of eligible balances paid without manual assistance, time from due date to collection, allocation exceptions and support contacts per payment journey.
Model dealer payments around account state and obligations.
Treat partial and multi-invoice payments as core flows.
Separate organizational approval from payment authentication.
Close the loop from payment to invoice allocation and account balance.