Configuration

Once PayGlocal Recurring is activated, everything you configure lives on one native WHMCS screen: Setup → Payment Gateways → PayGlocal Recurring. This page walks you through each field in the order you'll fill it, explains the two settings that decide how much and when recurring charges are attempted, and finishes with a sandbox test payment so you can confirm the whole flow before customers use it.

Get your keys first

Configuration assumes you already have your RSA key files and their KIDs. If you don't, follow the PayGlocal key setup guide first — it walks through generating the merchant private key and downloading PayGlocal's public certificate, each with its KID (Key ID), and where to place the .pem files on your server.

Setup → Payment Gateways → PayGlocal Recurring

Open the configuration screen

Go to Setup → Payment Gateways → PayGlocal Recurring. If you don't see it here yet, it hasn't been activated — open Setup → Payment Gateways → All Payment Gateways, find PayGlocal Recurring, and click Activate first. The configuration form appears as soon as the gateway is active.

Enter your credentials

Work down the form top to bottom. The settings reference lists every field with its default; the steps below explain what to type and why.

License Key

Paste your PayGlocal Recurring license key (from your relyweb.co account). On this gateway the license-gated feature is payment processing itself — while the license is inactive, the gateway will not initiate payments. Keep this key correct and your server able to reach relyweb.co over HTTPS.

Merchant ID (MID)

Enter your PayGlocal Merchant ID from onboarding. This identifies your merchant account on every request the gateway makes to PayGlocal.

Merchant Private Key File Path and KID

• Merchant Private Key File Path — the absolute server path to your merchant RSA private key .pem file (for example /home/user/keys/merchant_private.pem). Keep this file outside the web root, readable only by the web-server user (chmod 640).
• Merchant Private Key ID (KID) — the Key ID that PayGlocal assigned to that key (from Key Management in the GCC dashboard). The gateway uses it to tell PayGlocal which key signed the request.

PayGlocal Public Key File Path and KID

• PayGlocal Public Key File Path — the absolute server path to PayGlocal's public key file (the Common Certificate you downloaded), stored the same secure way.
• PayGlocal Public Key ID (KID) — the KID of that PayGlocal public key. The gateway uses it to verify the signed callbacks PayGlocal sends back.

Match the environment

Your keys and KIDs must match the environment you're pointing at — UAT (sandbox) keys while Test / Sandbox Mode is Yes, and production keys once it's No. Mixing them causes signature-verification failures.

Choose the recurring behaviour

Two dropdowns control how automatic charges behave. These are the settings worth thinking about.

SI Maximum Amount Per Payment

This caps each recurring charge as a multiple of the first invoice amount — a Standing Instruction (SI) authorises charging up to a ceiling, and this multiplier sets that ceiling. Pick from 1x to 5x; the default is 2x.

Why it matters: it's a guardrail. The daily cron skips any invoice above the mandate's maximum, so a customer is never charged more than they authorised. Set it high enough to cover normal renewals plus a bit of headroom (added services, price changes), but no higher than you're comfortable auto-charging.

Worked example. At 3x, if the customer's first invoice was 100 USD, later charges of up to 300 USD are allowed. An invoice for 350 USD would exceed the ceiling and be skipped.

Days Before Due Date to Charge

This is how many days before an invoice's due date the daily cron attempts the automatic charge. Choose 1 to 5 days; the default is 2 days. A wider window gives more time to retry before the due date; a narrower window charges closer to when payment is actually due.

Worked example. At 2 days, an invoice due March 20 is charged on or after March 18.

The cron does the charging

Automatic charges depend on the WHMCS daily cron running. It finds unpaid invoices due within this window, looks up the client's active mandate, and charges it. See How payments work for the full flow.

Test / Sandbox Mode

Set this to Yes to route everything through PayGlocal's UAT (sandbox) environment while you set up and test; set it to No for live production. The default is No. Remember to swap your keys/KIDs to match whenever you change this.

Save and take a sandbox test payment

1. Click Save Changes at the bottom of the form.
2. With Test / Sandbox Mode = Yes and your UAT keys in place, create a test invoice and pay it as a customer. On the invoice, click Pay & Authorize Recurring, complete payment on PayGlocal's hosted checkout, and authorise the recurring mandate.
3. Confirm the result: the invoice should be marked Paid and the mandate stored for that client. If anything fails, check the Gateway Log at Utilities → Logs → Gateway Log — that's where this gateway records its activity.

Ready for real payments?

When your sandbox test succeeds, switch Test / Sandbox Mode to No, replace your UAT keys and KIDs with production ones, and click Save Changes. The going-live checklist covers the full switch.

Related pages

• PayGlocal key setup — generate your RSA keys and KIDs
• Settings reference — every field, with defaults
• How payments work — the first payment and automatic renewals
• Going live — the sandbox → production checklist