Appearance
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.
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.
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 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 → 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:
- It verifies the callback signature with PayGlocal's public key, confirming the message is authentic and untampered.
- 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.
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.
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 for the common causes.
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.
Related pages
- Security — how the encryption and verification protect you
- PayGlocal key setup — the RSA keys this flow uses
- Configuration — enter your merchant details and keys
- Going live — test in sandbox, then switch to production
- Troubleshooting — when a payment doesn't complete