---
url: /payglocal-whmcs/features/payment-flow.md
description: >-
  Follow a PayGlocal payment from Pay Now through the encrypted, signed handoff,
  the hosted checkout, and the dual-verified callback that marks your invoice
  paid.
---

# How payments work

When a customer pays a WHMCS invoice with PayGlocal, they never enter card details on your site.
The gateway hands the payment off to PayGlocal's hosted **PayCollect** checkout, then confirms the
result with two independent checks before it touches the invoice. This page walks you through what
happens at each step so you know exactly what the customer sees and how the "paid" status is
earned.

## The journey at a glance

| Step | What happens | Where |
| --- | --- | --- |
| **1. Pay Now** | The customer clicks Pay Now on their invoice | Your WHMCS |
| **2. Encrypt & sign** | The gateway builds an encrypted, signed request and gets a redirect URL | Your server ↔ PayGlocal |
| **3. Hosted checkout** | The customer pays on PayGlocal's secure page | PayGlocal |
| **4. Verified callback** | PayGlocal returns a signed result; the gateway verifies it and cross-checks the status | Your server ↔ PayGlocal |
| **5. Marked paid** | The invoice is set to Paid and the customer is returned | Your WHMCS |

## Step 1 — The customer clicks Pay Now

Your customer opens their invoice and chooses PayGlocal as the payment method, then clicks
**Pay Now**. Nothing sensitive is collected on your page — the button simply starts the handoff.

![The Pay Now button on a WHMCS invoice](/payglocal-whmcs/img/payglocal-payment-flow-pay-now.png)
*Client Area → Invoices → Pay Now*

## Step 2 — The request is encrypted and signed

Before your server talks to PayGlocal, it protects the payment request. It **encrypts** the
payload with JWE (JSON Web Encryption) using PayGlocal's public key, and **signs** it with JWS
(JSON Web Signature) using your merchant private key.

::: info JWE and JWS
**JWE** encrypts the request so only PayGlocal can read it. **JWS** signs it so PayGlocal can
prove the request genuinely came from you. Both rely on the RSA key pair you configured — see
[PayGlocal key setup](/payglocal-whmcs/guides/payglocal-keys).
:::

PayGlocal validates the request and returns a one-time redirect URL for the checkout page.

## Step 3 — The customer pays on PayGlocal's hosted checkout

The customer is redirected to PayGlocal's **PayCollect** hosted page, where they choose a card or
alternative method and complete the payment. Because this page is hosted by PayGlocal, the card
details are entered on their secure environment — never on your server. This keeps your PCI scope
small and lets PayGlocal handle 3-D Secure and other authentication.

![PayGlocal's hosted PayCollect checkout page](/payglocal-whmcs/img/payglocal-payment-flow-checkout.png)
*PayGlocal → PayCollect hosted checkout*

## Step 4 — The result is signed and double-checked

When the payment finishes, PayGlocal sends a **signed (JWS) callback** back to your WHMCS. The
gateway does not trust it blindly. It performs **dual verification**:

1. It **verifies the callback signature** with PayGlocal's public key, confirming the message is
   authentic and untampered.
2. It **cross-checks the transaction with PayGlocal's status API**, independently confirming the
   payment really succeeded on PayGlocal's side.

Only when *both* checks agree does the gateway accept the payment. This protects you against
spoofed or replayed callbacks — a result is never taken at face value.

::: tip Why two checks?
A signature proves the message is genuine; the status cross-check proves the payment actually
cleared. Requiring both means a forged callback alone can never mark an invoice paid.
:::

## Step 5 — The invoice is marked paid

With both checks passed, the gateway records the payment against the invoice and sets it to
**Paid**. The customer is returned to WHMCS to a confirmation. Every step is written to the
gateway log, so you can trace exactly what happened.

![A gateway log entry for a completed PayGlocal payment](/payglocal-whmcs/img/payglocal-payment-flow-gateway-log.png)
*Utilities → Logs → Gateway Log*

## When things don't complete

If a customer abandons the checkout or a payment is declined, no signed success callback arrives
and the invoice stays unpaid — exactly as it should. If a payment succeeded at PayGlocal but the
invoice didn't update, the Gateway Log is the first place to look: it records the verification and
status-check outcomes. See [Troubleshooting](/payglocal-whmcs/troubleshooting) for the common
causes.

::: warning Payments require an active license
Payment processing is gated by your license. If the license is inactive, the gateway will not
process payments. See [Licensing](/payglocal-whmcs/licensing).
:::

## Related pages

* [Security](/payglocal-whmcs/features/security) — how the encryption and verification protect you
* [PayGlocal key setup](/payglocal-whmcs/guides/payglocal-keys) — the RSA keys this flow uses
* [Configuration](/payglocal-whmcs/configuration) — enter your merchant details and keys
* [Going live](/payglocal-whmcs/guides/going-live) — test in sandbox, then switch to production
* [Troubleshooting](/payglocal-whmcs/troubleshooting) — when a payment doesn't complete