Appearance
How recurring mandates work
A mandate is your customer's standing authorisation to charge them again. The first time a customer pays you through PayGlocal Recurring, they don't just settle that one invoice — they authorise a Standing Instruction (SI) that lets WHMCS charge their future invoices without asking for card details again. This page explains what that mandate is, how it behaves, and the two settings you use to keep it inside safe limits.
Mandate, SI, KID
A mandate is the recurring authorisation itself. SI (Standing Instruction) is PayGlocal's recurring-payment mechanism that the mandate rides on. The SI here is merchant-initiated — you charge as invoices fall due, up to the amount the customer authorised.
One mandate per client, covering everything
The mandate is stored per client, not per product or per invoice. That means a single authorisation covers every kind of billable item that client has with you — hosting, domains, addons, one-off charges, whatever comes due. You don't ask the customer to re-authorise for each service.
Because it is tied to the client, a client can only have one active mandate at a time. If the same client authorises a new mandate later, the new one supersedes the old — the previous mandate is retired and the new one takes over all future charges. This keeps things unambiguous: there is always exactly one authorisation WHMCS will act on for that client.
The amount guard
A customer authorises recurring charges up to a maximum, and PayGlocal Recurring enforces that for you. When the daily cron looks at an invoice, it compares the amount against the mandate's configured maximum. A charge above that maximum is skipped — the customer is never billed more than they agreed to.
You set the ceiling with SI Maximum Amount Per Payment, a multiple of the first invoice amount (a dropdown from 1x to 5x, default 2x). For example, at 3x a first invoice of 100 USD allows later charges up to 300 USD; anything above that is left for you to handle manually. Pick a multiple that comfortably covers your customer's normal renewals without leaving the door wide open.
Choosing a multiple
If a customer usually renews one service, a low multiple is safest. If they tend to bundle several services onto one invoice, give yourself a little more headroom so legitimate charges aren't skipped.
When charges are attempted
The other setting that governs the mandate is Days Before Due Date to Charge (a dropdown from 1 to 5 days, default 2). This is how early, before an invoice's due date, WHMCS tries the automatic charge. At 2 days, an invoice due March 20 is charged on or after March 18. A small window gives failed attempts time to be noticed and retried before the due date passes.
Mandate statuses
Over its life a mandate moves through a handful of states. You'll see these reflected in the Gateway Log (Utilities → Logs → Gateway Log):
| Status | What it means |
|---|---|
| active | The current, usable authorisation — this is what the cron charges |
| revoked | Cancelled at PayGlocal; no longer chargeable |
| exhausted | The mandate has reached the end of its usable life |
| failed | The authorisation did not complete successfully |
| superseded | Replaced by a newer mandate the client authorised |
What happens when you delete a client
If you delete a client in WHMCS, their active mandate is automatically revoked with PayGlocal. You don't need a separate cleanup step — removing the client cleanly ends their standing authorisation so nothing can be charged afterwards.
Deactivating is not the same as deleting
Deactivating the gateway stops WHMCS from charging, but it does not revoke existing mandates at PayGlocal. Only deleting the client does that automatically. If you need a mandate revoked without deleting the client, do it from your PayGlocal dashboard.
Related pages
- How payments work — the first payment and the automatic charges
- Security — the guardrails behind every charge
- Settings reference — the SI Maximum Amount and Days Before Due fields
- Configuration — set these values during setup