WHMCS Card Expiry Tracker
Catch expiring cards before the gateway declines them.
- WHMCS addon module
- Version 1.1.0
- In development
Downloads are not open yet. This product is still in development — the button will go live when the first public release is ready.
A WHMCS addon module that emails clients before the card stored against their account expires, so the gateway does not decline the next automatic payment and nobody spends the following week chasing failed invoices.
It runs once a day on the WHMCS daily cron, resolves each stored card's true expiry date through the supported API, and decides what is due. Two reminders go out by default — thirty days and seven days before expiry — each carrying a link straight to the update-card page. An optional third fires once the card has actually expired.
No card number is ever read, logged or stored. The module asks WHMCS for pay-method metadata and works with the card type, the last four digits and the expiry month; that is all it needs and all it touches.
Inside the product
33 things WHMCS Card Expiry Tracker takes off your plate, grouped by the job they do.
The daily check
One pass a day over every stored card, built to survive a missed cron run and a gateway that formats dates however it likes.
Runs on the WHMCS daily cron
Hooks the existing daily job at priority one. There is no separate crontab entry, scheduled task or CLI script to set up or forget.
Reads no card numbers
Expiry dates come from the supported pay-methods API. The card table is queried only for client ID, type and default flag.
Seven date formats parsed
MM/YY, MM/YYYY, MMYY, MM-YY, YYYY-MM, YYYYMM and MMYYYY, with impossible months and years rejected rather than guessed at.
Bank-accurate expiry basis
A card is treated as dying on the last day of its expiry month by default, with a setting to warn from the first day instead.
Survives a missed day
Stages are evaluated as "N days or fewer remaining" rather than exactly N, so a cron outage does not silently skip a batch.
Cannot break daily cron
The whole run is wrapped so a failure is logged and stops there, leaving the rest of your WHMCS daily job to finish normally.
Who gets reminded, and when
Two pre-expiry reminders plus an optional chase, narrowed by whichever filters suit how you bill.
Two stages, freely set
Thirty days and seven days by default; both are plain day counts you can change. Enter them in the wrong order and the module sorts it out.
Optional after-expiry notice
Off by default. Sends one further email once the card has expired, and stops chasing after a configurable grace window.
Tokenised cards included
Locally stored cards and gateway tokens — Stripe, Authorize.Net and anything else using WHMCS pay methods — are each independently toggleable.
Narrow the scope
Limit to each client's default card, to active clients only, or to clients who actually have a recurring service or live domain.
Cap the first live batch
An optional per-run send limit throttles the first real run. Anything over the cap is counted as skipped, not lost, and goes tomorrow.
Built for large installs
Clients are processed in chunks and errors are capped, with a documented cost of roughly one API call per client holding a card.
Emails you control
Three standard WHMCS email templates, created on activation and yours to rewrite from that moment on.
Three seeded templates
Expiring Soon, Final Reminder and Has Expired, added as ordinary General templates you edit in the normal WHMCS screen.
Your wording is never overwritten
Seeding skips any template that already exists, so edits survive reinstalls and upgrades. Only genuinely missing ones are recreated.
Eleven card merge fields
Card type, last four, description, expiry, days remaining, days since expiry, gateway name and the update link, alongside every standard client field.
Sent through WHMCS itself
Delivery uses the WHMCS mail API, so messages respect the client's language and appear in their email history like any other.
Configurable update link
Points at the payment-methods page by default, and takes either a relative path or a full URL if you send clients somewhere else.
Warnings where clients look
Two client-area surfaces for the people who never open the email, both reading a pre-built snapshot rather than calling a gateway.
Dashboard panel
A native homepage panel showing the card, the expiry wording and an update button. On by default, with a configurable warning window.
Optional site-wide banner
A dismissible alert injected across invoice and service pages with no theme template edits, off by default.
Urgency you can see
Expired or within seven days renders red; anything further out renders amber, and the wording changes once the card has actually gone.
Free at page-load time
Both surfaces read one indexed row from a snapshot table rebuilt by each run. Neither ever calls a payment gateway on a page load.
Alerts and run history
Mirror the run into your team's chat, and keep a record of what every run actually did.
Three notification events
Card expiring, card expired and run summary, raised through the WHMCS Notifications system rather than a bolted-on integration.
Route them anywhere
Because they are standard notification events, Slack, Teams, a Discord webhook or plain email all work through a normal notification rule.
Per-card or summary only
Two independent switches: an event per reminder sent, and a single end-of-run summary — so a big batch need not become a hundred pings.
Admin email digest
An optional summary of cards checked, notices due, sent, already notified and failed, sent only when something actually happened.
Every run recorded
Trigger, mode, clients and cards scanned, sent, skipped, failed, duration and errors, kept for the last two hundred runs.
A reminder log
The last three hundred notices with sent date, client, card expiry period, stage, recipient address and status.
Going live without an accident
The module assumes you do not want to discover a mistake by emailing every client at once.
Test mode is on by default
Nothing sends until you say so. A test run collects who would be contacted and shows you the list first.
A guided checklist
Six steps — system URL, templates, update link, test run, review, go live — each reporting its own live state so you can see what is left.
Duplicate-proof by design
A unique index on card, expiry period and stage, claimed before sending and released on failure, so overlapping runs cannot double-send.
Failures retry tomorrow
A mail error releases the slot rather than marking it done, so a transient SMTP problem does not silently skip a client.
Health warnings on the overview
Flags a missing system URL, missing templates, test mode still on, and a last run more than two days ago — which is how you notice cron stopped.
Uninstall keeps its history
Deactivating preserves the notice ledger and your templates, so reactivating never re-sends what has already gone out.
Any WHMCS installation taking recurring card payments — hosting, SaaS or services.
What it needs
- Platform
- WHMCS 7.8 or newer
- PHP
- 8.1 or newer
- Tested to
- WHMCS 9.0 and the 8.13 LTS line
- Covers
- Locally stored and gateway-tokenised cards
Questions about WHMCS Card Expiry Tracker?
Every product is backed by the Keen2Support helpdesk. Customers raise tickets from inside the software itself, and replies sync straight back — no separate portal to remember, no password to lose.