# Deposits, balances and split payments

> Taking part of the amount at order time and the balance later looks like a payment setting. In fact it touches the order, the invoice, stock and accounting, and that is where projects go wrong when the question wasn’t asked at the right moment.

- Source canonique : [https://allaux.fr/en/modules/acompte-et-paiement-fractionne](https://allaux.fr/en/modules/acompte-et-paiement-fractionne)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## 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.

## Payment compliance isn’t something to improvise

> Storing card data, retaining a payment method for a later charge and authenticating the cardholder are regulatory and contractual requirements. Those mechanisms are delegated to the payment provider, who takes them on, and are not reimplemented inside a module.

## Related pages

- **Configuring a payment webhook** — The mechanism by which the store learns an instalment has been collected. ([/guides/configurer-webhook-paiement](/guides/configurer-webhook-paiement))
- **PrestaShop payment problem** — When checkout refuses or fails to record the payment. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement))
- **Generating PDF documents** — To produce separate deposit and balance invoices. ([/modules/generation-de-documents-pdf](/modules/generation-de-documents-pdf))

## FAQ

### Do I need a specific module to offer instalments?

Often no: most payment providers offer that option inside their own module, and enabling it costs far less than a build. Development is justified when the schedule follows your rules rather than the provider’s.

### How does the order appear while the balance is unpaid?

Through a dedicated status, created for it, that clearly shows an amount is still due. Repurposing an existing status blurs order picking and skews the statistics.

### What if the customer never pays the balance?

That is the case to decide before building: automatic reminders, cancellation after a delay, keeping the deposit. The rule is a commercial decision, and the module only applies it.

### Are deposits compatible with credit notes and refunds?

They have to be, and it is a significant part of the work. A partial refund on a two-payment order requires knowing which collection it applies to, otherwise the accounts no longer reconcile.