Appearance
How payments work
Trace a PayGlocal payment from Pay Now to a Paid invoice. The customer never enters card details on your site — the gateway hands off to PayGlocal's hosted PayCollect checkout, then verifies the signed result before touching the invoice.
The journey at a glance
| Step | What happens | Where |
|---|---|---|
| 1. Pay Now | Customer clicks Pay Now on their invoice | Your WHMCS |
| 2. Encrypt & sign | Gateway builds an encrypted, signed request and gets a redirect URL | Your server ↔ PayGlocal |
| 3. Hosted checkout | Customer pays on PayGlocal's secure page | PayGlocal |
| 4. Verified callback | PayGlocal returns a signed result; the gateway verifies its signature and cross-checks the status | Your server ↔ PayGlocal |
| 5. Marked paid | The signature-verified result marks the invoice Paid; the customer returns | Your WHMCS |
Step 1 — Customer clicks Pay Now
Customer opens the invoice, selects PayGlocal, and clicks Pay Now. Nothing sensitive is collected on your page.
Client Area → Invoices → Pay Now
Step 2 — Request is encrypted and signed
The gateway protects the request before sending it:
| Layer | Purpose | Key used |
|---|---|---|
| JWE (JSON Web Encryption) | Encrypts the payload so only PayGlocal can read it | PayGlocal's public key |
| JWS (JSON Web Signature) | Signs the payload so PayGlocal can prove it came from you | Your merchant private key |
Both rely on the RSA key pair you configured — see PayGlocal key setup. PayGlocal validates the request and returns a one-time redirect URL.
Step 3 — Customer pays on the hosted checkout
The customer is redirected to PayGlocal's PayCollect hosted page and completes the payment there. Card details are entered on PayGlocal's environment — never on your server — keeping your PCI scope small and letting PayGlocal handle 3-D Secure.
PayGlocal → PayCollect hosted checkout
Step 4 — Result is verified and cross-checked
PayGlocal sends a signed (JWS) callback to your WHMCS. The gateway runs two checks:
| Check | Role | On failure / disagreement |
|---|---|---|
| Signature verification (JWS) | Authoritative gate. Verifies the callback with PayGlocal's public key. | If the signature can't be verified, the callback is rejected and the invoice is left untouched. |
| Status-API cross-check | Best effort. Confirms the final status and fills in details the callback doesn't carry (merchant transaction ID, amount). | If the status API disagrees, its status is trusted; if it's unreachable, the gateway proceeds with the signature-verified result and notes this in the Gateway Log. |
Signature is the gate
The signature check is what protects you against spoofed or replayed callbacks — an unsigned or tampered message is never accepted. The status cross-check is a best-effort confirmation, not a second required gate.
Step 5 — Invoice is marked paid
On a signature-verified success, the gateway records the payment and sets the invoice to Paid, then returns the customer to a WHMCS confirmation. Every step is written to the Gateway Log.
When things don't complete
- Abandoned or declined — no signed success callback arrives, so the invoice stays unpaid.
- Paid at PayGlocal but not updated in WHMCS — check Utilities → Logs → Gateway Log; it records the verification and status-check outcomes. See Troubleshooting.
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