---
url: /payglocal-whmcs/features/security.md
description: >-
  Understand how PayGlocal for WHMCS protects payments — JWE encryption, JWS
  signing, dual verification, SSL, no stored card data, and license-gated
  processing.
---

# 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](/payglocal-whmcs/guides/payglocal-keys).

## 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](/payglocal-whmcs/features/payment-flow).

## 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](/payglocal-whmcs/requirements).

## Protecting your private key {#key-security}

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.

::: warning 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](/payglocal-whmcs/guides/payglocal-keys).
:::

## 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](/payglocal-whmcs/licensing).

## Related pages

* [How payments work](/payglocal-whmcs/features/payment-flow) — the flow these protections secure
* [PayGlocal key setup](/payglocal-whmcs/guides/payglocal-keys) — generate and store your RSA keys
* [Requirements](/payglocal-whmcs/requirements) — SSL and the extensions the gateway needs
* [Licensing](/payglocal-whmcs/licensing) — how the license gates payments