Split Payment

Overview

A split payment divides one customer obligation or checkout amount across multiple payment methods, payers, destinations, or funding sources. Each component must be tracked while preserving the status of the overall order. Each leg needs its own amount, currency or asset, method, authorization, fees, reference, and status.

If one leg fails, the system may retry, request another method, cancel remaining legs, or refund successful components according to policy. The operating record should preserve the original obligation, participants, amount, currency or asset, authoritative identifiers, timestamps, state history, exceptions, and final financial effect. Important failure modes include duplicate or delayed events, wrong destinations or currencies, stale instructions, unavailable providers, unsupported retries, and customer-facing status that differs from authoritative records.

Split Payment should remain distinct from Split Payout and Split Settlement, because each can represent a different stage, record, control, or financial outcome.

The aggregate must handle rounding, conversion, partial failure, timeout, refund, and overpayment without creating an unexplained balance. Teams should design for wrong amounts, duplicate attempts, invalid routing, inconsistent states, delayed completion, and reconciliation gaps.

The business should define whether components can complete independently and when the order becomes sufficiently paid. Fulfillment should follow the approved order-level rule, not the first successful component. Reconciliation should connect every component to the single commercial obligation and any later reversal. Controls should validate inputs server-side, authenticate external events, make irreversible actions idempotent, and reconcile provider, network, settlement, and ledger evidence. For Split Payment, the authoritative record and completion rule should be documented before any irreversible operational, customer, or accounting action is released.