Deposits, balances and split payments

Three needs that are often confused

A deposit followed by a balance: the customer pays part at order time, the rest is collected later, often at dispatch or delivery. The order exists from the first payment but isn’t fully paid, and that intermediate state must be represented somewhere in the store.

Payment in instalments: the full amount is authorised at order time and taken across several dates. Here the order counts as paid, and the schedule belongs to the payment provider, not to the store.

Deferred payment granted by the merchant: typical of B2B, the order ships and the invoice is settled later, on negotiated terms. That is not a payment module matter but customer account management.

These three sound alike in the request and have almost nothing in common in the build. Telling them apart at the start avoids building the wrong thing.

How I approach this kind of work

The first question is what your payment provider already offers. Many natively support instalments and deferred capture, and in that case the best answer isn’t a build but correct configuration of the provider’s own module, with its status callbacks properly received by the store.

When it really is a deposit, the work sits elsewhere than payment: representing the «partly paid» state, triggering the balance request, handling a balance that is never paid, and above all producing correct accounting documents. A deposit invoice isn’t a partial invoice of the total, and the store must distinguish what has been collected from what remains due.

I explicitly handle stock, which is often forgotten: does a deposit reserve the goods, and for how long. Without an answer to that, the feature creates an operational problem in place of the payment problem it solves.