Journey cart ile değil account ile başlar
Dealer'ın birden fazla invoice borcu, account credit'i, limit'i veya negotiated term'i olabilir ve hangi obligation'ı settle edeceğini seçmesi gerekebilir. Payment experience payment method göstermeden önce commercial context'i anlamalıdır.
Partial ve split settlement normaldir
B2B payment sıklıkla balance'ın bir kısmını ödeme, birden fazla invoice birleştirme, tek payment'ı obligations arasında allocate etme veya installment seçme davranışlarını içerir. Bunlar edge case değil core account behavior'dır ve finance operations sonrası düzeltilecek workaround olmamalıdır.
Authorization organizational olabilir
Payment'ı başlatan kişi yüksek tutarı approve etmeye yetkili olmayabilir. Dealer portal bu nedenle payment authentication yanında user role, account permission ve approval workflow'a ihtiyaç duyabilir.
Reconciliation account loop'u kapatmalı
Successful payment doğru invoice'ları ve account balance'ı güncellemeli, clear evidence üretmeli ve settlement'a trace edilebilmelidir. Allocation manuel kalırsa para geldiği halde customer-facing portal stale balance gösterebilir.
Obligation'ları payment attempt'lerden ayrı modelleyin
Dealer account invoice, credit, past-due item, disputed amount ve payment term içerebilir. Bu obligation'lar payment attempt olsun veya olmasın vardır. Obligation state'i payment execution'dan ayırmak portal'ın doğru account view sunmasını ve finance'ın successful payment'ın neyi settle etmesi gerektiğini anlamasını sağlar.
Mapping one-to-many ve many-to-one pattern'i de destekler: tek payment birden fazla invoice'ı kapatabilir, bir invoice birden fazla partial payment alabilir, credit payment olmadan obligation'ı azaltabilir. Order veya invoice ID'yi payment identity olarak kullanmak bu ilişkileri temiz temsil edemez.
Allocation rule'larını explicit yapın
System dealer'ın invoice allocation seçip seçmediğini, business'ın oldest-due-first rule kullanıp kullanmadığını, partial amount'a izin verilip verilmediğini ve credit'in nasıl consume edildiğini bilmelidir. Allocation policy customer experience ve accounting'i etkiler; funds geldikten sonra manual olarak yeniden kurulacak bilgi olmamalıdır.
Exception olduğunda finance daha sonra değiştirse bile intended allocation'ı evidence olarak koruyun. Böylece account balance'ın neden değiştiği ve customer intent ile internal correction arasındaki fark açıklanabilir.
Approval'ı yalnız user değil organization etrafında tasarlayın
B2B user account ve legal entity adına hareket eder. Permission dealer branch, role, amount threshold, payment method veya second approver gereksinimine bağlı olabilir. Authentication user'ın kim olduğunu kanıtlar; authorization bu user'ın bu account için bu financial action'ı yapıp yapamayacağını belirler.
Approval flow payment intent'i approval pending iken korumalıdır; final payer transaction'ı yeniden kurmak zorunda kalmamalıdır. Audit evidence initiator, approver, policy ve execution result'ı bağlamalıdır.
Self-service'i finance operations'a bağlayın
Portal ancak successful action finance'ın kullandığı system'ları güncelliyorsa gerçek operational leverage yaratır. Payment status, invoice allocation, balance, receipt, settlement reference ve exception ERP veya ilgili account source of truth'a dönmelidir. Aksi halde portal support işini azaltırken reconciliation işini büyütür.
Self-service'i portal visit ile değil completed financial outcome ile ölçün. Eligible balance'ın manual assistance olmadan ödenme yüzdesi, due date'ten collection'a süre, allocation exception ve payment journey başına support contact faydalı metric'lerdir.
Dealer payment'ı account state ve obligations etrafında modelle.
Partial ve multi-invoice payment'ı core flow kabul et.
Organizational approval ile payment authentication'ı ayır.
Payment'tan invoice allocation ve account balance'a loop'u kapat.