---
url: /payglocal-recurring-whmcs/features/payment-flow.md
description: >-
  A walkthrough of the two PayGlocal Recurring flows — the customer's first
  payment that authorises a mandate, and the automatic charges the WHMCS daily
  cron makes afterwards.
---

# How payments work

PayGlocal Recurring has two flows, and it helps to understand both. The **first payment** is
where the customer takes an action and authorises a mandate. Every payment after that is
**automatic** — the WHMCS daily cron does the work and the customer sees nothing. This page walks
through each so you know what your customers experience and what happens behind the scenes.

## The first payment

The first time a customer pays an invoice through this gateway, they set up the recurring
authorisation at the same time.

### 1. The customer clicks *Pay & Authorize Recurring*

On the WHMCS invoice, PayGlocal Recurring shows a **Pay & Authorize Recurring** button instead of
a plain pay button. The wording is deliberate: paying this invoice also authorises you to charge
future ones.

![The Pay & Authorize Recurring button on a WHMCS invoice](/payglocal-recurring-whmcs/img/payglocal-recurring-payment-flow-pay-button.png)
*Client Area → Invoices → (an unpaid invoice)*

### 2. They pay on PayGlocal's hosted checkout

The customer is redirected to **PayGlocal's hosted checkout**. They enter their card details on
PayGlocal's secure page, complete any 3-D Secure step, and confirm — which both settles this
invoice and **authorises the recurring mandate**. Because the checkout is hosted by PayGlocal,
card details are never entered on your site.

### 3. WHMCS verifies and stores the mandate

When the payment completes, PayGlocal sends a signed result back to WHMCS. The gateway verifies
it, saves the customer's **mandate**, and marks the invoice **Paid**. From here on, that client
has one active mandate ready for automatic charges.

::: info Dual verification, behind the scenes
You don't have to do anything for this, but it's worth knowing: the gateway doesn't take the
callback at face value. It checks the callback's signature **and** cross-checks the outcome
against PayGlocal's status API before accepting the payment. See
[Security](/payglocal-recurring-whmcs/features/security) for why this matters.
:::

## The automatic charges

Once a mandate exists, you stop being involved — the **WHMCS daily cron** handles renewals.

### 1. The daily cron runs

Your WHMCS daily cron must be running for this to work; it's what drives every recurring charge.

### 2. It finds invoices in the window

The cron looks for unpaid invoices due within your **Days Before Due Date to Charge** window. At
the default of **2 days**, an invoice due March 20 becomes eligible on March 18.

### 3. It charges the active mandate

For each eligible invoice, the cron finds the client's **active mandate** and charges it
automatically — no customer action, no re-entering card details. A charge that would exceed the
mandate's maximum is **skipped** rather than forced through (the
[amount guard](/payglocal-recurring-whmcs/features/recurring-mandates#amount-guard)).

### 4. The invoice is marked Paid

On a successful charge, WHMCS marks the invoice **Paid** just as it would for a manual payment.
Everything the cron does — successes, skips, and failures — is recorded in the **Gateway Log**
(**Utilities → Logs → Gateway Log**), which is where you look if a renewal didn't go through.

::: tip Keep the cron healthy
The automatic flow is only as reliable as your daily cron. If renewals stop happening, confirm the
WHMCS daily cron is running before anything else.
:::

## Related pages

* [How recurring mandates work](/payglocal-recurring-whmcs/features/recurring-mandates) — the authorisation the cron charges
* [Security](/payglocal-recurring-whmcs/features/security) — how each charge is verified
* [Test in sandbox, then go live](/payglocal-recurring-whmcs/guides/going-live) — try both flows safely first
* [Error reference](/payglocal-recurring-whmcs/errors) — what the Gateway Log statuses mean