Add a hidden bot-trap field to WHMCS signup and order forms, review its matches, then decide whether to reject matching submissions. The honeypot is an additional signal, not a replacement for the other signup and order controls.

Start with observation

1. Open PD Modules → PD Shield → Settings.
2. Enable Invisible honeypot on order/signup forms.
3. Leave Block honeypot hits (otherwise log only) disabled while evaluating your forms.
4. Press Save settings.

With observation enabled, a filled trap is recorded but this rule does not refuse the request. Other protections can still refuse or hold the same activity.

Check your real customer forms

The trap is added by a script in the page. It helps detect submissions that fill that field; a direct automated request that never loads the form script may not receive or fill it. Do not use the absence of honeypot matches as proof that bots are absent.

Use your controlled testing process to check normal registration and checkout with the forms, browser behaviour and password managers your customers use. A password manager can fill a hidden field unexpectedly, so a hit is not proof that the visitor is a bot.

Choose a test offering that cannot provision a real resource or create an unintended charge. Do not repeat live orders solely to obtain a match.

Review Bot trap activity

Open PD Shield → Activity and inspect Bot trap matches. Compare times and outcomes with your controlled tests. Resolve unexpected genuine-user matches before enforcing the trap; do not change unrelated rules simply because they appear in the same Activity list.

Enable rejection when appropriate

1. Return to PD Shield → Settings.
2. Enable Block honeypot hits (otherwise log only).
3. Keep the invisible-honeypot setting enabled and press Save settings.
4. Recheck genuine-customer registration and checkout through your controlled testing process.

A filled trap can now refuse a registration or checkout. Action when a rule matches is the velocity response; it does not override the honeypot’s separate enforcement switch.

Return to observation if genuine buyers are affected

Disable Block honeypot hits (otherwise log only) and save to stop honeypot rejection while retaining observation. Inspect the affected form and browser behaviour before enabling enforcement again. Disabling enforcement does not approve an order already held by another rule.

Keep full customer records, credentials and submitted form data out of shared screenshots.

See the PD Shield WHMCS guide for related setup, or explore PD Shield.