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 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:

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.

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.

Related pages

• PayGlocal key setup — generate and place your RSA keys
• How payments work — where dual verification happens
• Licensing — why payments need an active license
• Requirements — the SSL and key prerequisites