Security

Taking international card payments means moving money and trust across the internet, so this gateway is built to prove — at every step — that a payment is genuine before it touches an invoice. This page explains the protections in plain terms so you understand what keeps your payments safe and what you're responsible for.

Encrypted and signed requests (JWE + JWS)

Every request your server sends to PayGlocal is both encrypted and signed:

• JWE (JSON Web Encryption) scrambles the request with PayGlocal's public key, so only PayGlocal can read it in transit.
• JWS (JSON Web Signature) signs the request with your merchant private key, so PayGlocal can prove it genuinely came from you and wasn't altered on the way.

Together they mean a request is confidential and provably yours. Both rely on the RSA key pair you set up — see PayGlocal key setup.

Dual verification of every result

The gateway never trusts an incoming payment result on face value. When PayGlocal reports a payment, it runs two independent checks:

1. Signature verification — the signed (JWS) callback is verified with PayGlocal's public key, confirming the message is authentic and untampered.
2. Status-API cross-check — the gateway independently asks PayGlocal to confirm the transaction really succeeded.

An invoice is only marked paid when both checks agree. This defends against forged or replayed callbacks: a fake message alone can never move money into your books. The full sequence is described in How payments work.

No card data on your server

Customers pay on PayGlocal's hosted PayCollect checkout, so card numbers are entered on PayGlocal's secure environment — never on your site. Your WHMCS never sees, transmits, or stores card details, which keeps your PCI scope small and puts authentication (including 3-D Secure) in PayGlocal's hands.

SSL/TLS in transit

All communication with PayGlocal, and your 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 is what proves requests are yours, so 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 — doing so 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

Payment processing itself is protected by your license. Your License Key is validated when a payment runs; if the license is inactive, the gateway disables payment processing until it is active again. This is a deliberate safeguard, not a card-data risk. See Licensing.

Related pages

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