Security

How PayGlocal for WHMCS proves a payment is genuine before it touches an invoice, and what you must do to keep it that way.

Encrypted and signed requests (JWE + JWS)

Every request your server sends is both encrypted and signed:

Layer	What it does	Key used
JWE (JSON Web Encryption)	Scrambles the request so only PayGlocal can read it in transit	PayGlocal's public key
JWS (JSON Web Signature)	Signs the request so PayGlocal can prove it came from you, unaltered	Your merchant private key

Both rely on the RSA key pair you set up — see PayGlocal key setup.

Verification of every result

The gateway never trusts an incoming result on face value:

Check	Role	Behaviour
Signature verification (JWS)	Authoritative gate	The signed callback is verified with PayGlocal's public key. A callback whose signature can't be verified is rejected and never marks an invoice paid.
Status-API cross-check	Best effort	Independently confirms the transaction and its details. If it disagrees with the callback, its status is trusted; if it's briefly unreachable, the gateway proceeds with the signature-verified result.

The signature check defends against forged or replayed callbacks: a fake or tampered message alone can never move money into your books. See How payments work for the full sequence.

No card data on your server

• Hosted PayCollect: Customers enter payment details directly on PayGlocal's secure checkout.
• Zero local card data: WHMCS never processes, transmits, or stores sensitive cardholder information.
• Reduced PCI scope: Authentication and 3-D Secure compliance are handled entirely by PayGlocal.

SSL/TLS in transit

All communication with PayGlocal, and the customer's return to WHMCS, happens over SSL/TLS. Your WHMCS domain must have a valid SSL certificate — the payment callback endpoint depends on it. See Requirements.

Protecting your private key

Your merchant private key proves requests are yours. Guard it:

• Store both .pem files outside the web root — never in a directory the browser can reach.
• Set restrictive permissions with chmod 640 so only the web-server user can read them.
• Point the gateway at absolute paths, not files inside public_html.
• Don't casually regenerate your RSA keys — it invalidates the configured key and stops payments until you update the paths and KIDs.

Keep private keys off the web

If a private key file is readable over the web, treat it as compromised: generate a new key pair in the GCC dashboard and update your configuration. See PayGlocal key setup.

Payments are license-gated

Your License Key is validated when a payment runs. If the license is inactive, the gateway disables payment processing until it is active again — a deliberate safeguard, not a card-data risk. See Licensing.

Related pages

• How payments work — the flow these protections secure
• How recurring payments work — the amount guard and mandate lifecycle
• PayGlocal key setup — generate and store your RSA keys
• Requirements — SSL and the extensions the gateway needs
• Licensing — how the license gates payments