---
url: /payglocal-recurring-whmcs/features/security.md
description: >-
  The guardrails behind PayGlocal Recurring — JWT-secured API with your RSA
  keys, dual verification of every payment, deduplication, enforced SSL, and no
  card data stored.
---

# Security

Recurring payments only work if you can trust that every charge is genuine, verified, and safe to
act on. PayGlocal Recurring is built so you can. This page explains the guardrails in plain terms
— what protects your customers' payments, what protects you from double-charging, and the couple
of things you're responsible for on your own server.

## Every message is signed and encrypted

All communication with PayGlocal uses a **JWT-secured API**. In practice that means two layers of
protection applied with **your RSA keys**:

* **Encryption (JWE)** — the payload is encrypted so it can't be read in transit.
* **Signing (JWS)** — each request is signed so PayGlocal knows it genuinely came from you, and
  responses are signed so you know they genuinely came from PayGlocal.

You provide these keys during setup: your **merchant private key** and **PayGlocal's public key**,
each identified by a **KID** (Key ID). The [PayGlocal key setup
guide](/payglocal-recurring-whmcs/guides/payglocal-keys) walks through obtaining them.

## Dual verification of every payment

A single confirmation isn't enough to accept money. When PayGlocal reports a payment, the gateway
does **two independent checks** before marking anything paid:

1. It verifies the **signature** on the callback PayGlocal sends.
2. It **cross-checks** the outcome directly against PayGlocal's status API.

Only when both agree is the payment accepted and the mandate stored. This closes the gap where a
forged or replayed callback could otherwise be trusted.

## Deduplication and invoice validation

Automated billing runs repeatedly, so the gateway guards against acting twice. **Deduplication**
prevents the same result from being processed more than once, and **invoice validation** makes
sure a payment is matched to the correct invoice. Together they stop double-charging and
mismatched payments before they can happen.

## SSL/TLS is enforced

Every call to PayGlocal is made over **SSL/TLS** — it isn't optional. You also need a valid SSL
certificate on the endpoint that receives PayGlocal's callback, so results come back over a
secure connection too.

## No card data is stored

The gateway **never stores card details**. Card entry happens entirely on PayGlocal's hosted
checkout, and all WHMCS keeps is the **mandate identifiers** needed to charge future invoices.
There is no cardholder data on your server to protect or to leak.

## What you're responsible for

Two things are in your hands, and both are simple:

::: warning Keep your private key outside the web root
Store your merchant private key `.pem` in a directory **outside the web root**, readable only by
the web-server user (for example `chmod 640`). If it isn't web-accessible, it can't be downloaded.
:::

::: info Payments stop if the license lapses
Payment processing is the **license-gated feature** of this gateway — if the license becomes
inactive, payments are **disabled** until it's active again. Keep your license current and make
sure your server can reach relyweb.co over HTTPS. See
[Licensing](/payglocal-recurring-whmcs/licensing).
:::

## Related pages

* [PayGlocal key setup](/payglocal-recurring-whmcs/guides/payglocal-keys) — generate and place your RSA keys
* [How payments work](/payglocal-recurring-whmcs/features/payment-flow) — where dual verification happens
* [Licensing](/payglocal-recurring-whmcs/licensing) — why payments need an active license
* [Requirements](/payglocal-recurring-whmcs/requirements) — the SSL and key prerequisites