# A payment module for when nothing off-the-shelf fits

> Virtual wallet, store credit system, in-house split payment: this is the kind of payment module I build when off-the-shelf modules don't quite cover the need.

- Source canonique : [https://allaux.fr/en/expertises/module-paiement-sur-mesure-prestashop](https://allaux.fr/en/expertises/module-paiement-sur-mesure-prestashop)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

Off-the-shelf payment modules cover the standard cases well: card, PayPal, bank transfer. The need for a custom module appears when the payment logic falls outside these classic cases: a virtual wallet system funded by the client company, a store-credit mechanism that can be used partially across several orders, split payment with rules specific to the business, or a payment method reserved for certain business accounts under their negotiated terms. These are specific needs that no generic module can anticipate.

## How I approach this kind of work

A payment module deals with money and order validation: it's an area where a mistake can be costly, in unfulfilled orders or misrecorded payments. I always start by precisely framing the full lifecycle of the payment involved: at what point the amount is reserved, charged, refundable, and what order statuses should follow from each stage.

Development builds on PrestaShop's native payment system rather than working around it, so the module stays compatible with the rest of the ecosystem (invoicing, returns handling, statistics). Particular attention goes to edge cases: what happens if payment is interrupted mid-process, if a wallet balance becomes insufficient after the cart is validated, or if two orders try to use the same store credit almost simultaneously. These rare cases are statistically the most costly to leave poorly handled.

## Factors that affect the estimate

- **Complexity of the business logic** — A simple balance to debit has nothing in common with a system of caps, linked accounts, or automatic attribution rules.
- **Link to an external system** — A wallet topped up manually in the back office is simpler than a balance synchronised with an external management system.
- **Traceability requirements** — A detailed transaction history, required for accounting reasons, adds design and back-office reporting work.
- **Expected transaction volume** — A rarely used mechanism is handled differently from a payment method meant to become the main settlement channel.

## Questions to ask before starting

> Is the expected behaviour in case of partial failure defined? Who should be able to view or modify a balance, and with what traceability? Does the module need to stay compatible with an existing accounting system?

## FAQ

### Is a custom payment module compatible with regulatory obligations?

The module fits within the framework set by the payment methods already in place (card, transfer); it never replaces a licensed banking gateway, but orchestrates business logic around it.

### Can a virtual wallet be combined with standard payment methods?

Yes, that's actually the most common usage: a wallet balance used first, topped up with a card payment for the difference.

### How does the module handle refunds?

The refund cycle is framed at the design stage, with a consistent mechanism depending on whether the amount returns to the wallet, as store credit, or via the original payment method.

### Does this kind of module hold up through PrestaShop updates?

By relying on native hooks and the payment system rather than core modifications, the module stays compatible from one update to the next, provided a check is run on major version upgrades.