A no-match means the submitted value did not match the selected client’s current Support PIN. It does not by itself tell you whether the cause is the wrong account, an old PIN or a caller who cannot complete verification. Follow a short check sequence without revealing the stored value to help the caller answer.

Check the account and current PIN

1. Confirm the client account selected on PD Support PIN → Verify is the one the request concerns.
2. Ask the client to sign in and read the current Support PIN from their dashboard.
3. Check whether it was recently regenerated or rotated, or whether an earlier successful verification changed it through one-time mode.
4. Enter the current value carefully, retaining leading zeroes. For mixed-character PINs, letter matching is case-insensitive.
5. Read the new result before continuing with your support process.

If the client has never had a PIN, opening their dashboard creates one when its Support PIN panel is enabled. Staff can also open their client profile when that integration is enabled. Submitting a check on Verify does not create a PIN to match.

Use Verify or the client’s profile for the staff check. The module does not add a PIN checker to Blesta’s admin ticket view.

Review the activity record

Open Report & Activity → Activity, filter to the relevant verification event and use Older/Newer to reach the time of the failed check. Review the client, result and By column. Look for regeneration, rotation or a previous match near the same time.

A sequence of wrong checks needs attention, but it is not proof of a particular cause. Use your team’s alternative identity-check process when the caller cannot provide a matching current PIN. Never read the stored PIN to an unverified caller or regenerate it just to make the current request pass.

Handle API authentication and rate limits separately

If the API returns 401, check its key and supported authentication method. If it returns 429, pause checks for that client and respect retry_after. Failed staff, API and assistant checks contribute to the same per-client failure count used by the API and assistant lockout. Do not switch channels to keep guessing; follow your alternative identity-check process instead.

HTTP 200 can still contain match=false. Check the result fields in the API integration guide rather than using transport success as proof of verification.

Check the result against the settings

Compare the selected customer account, current PIN, rotation settings and Activity timeline. An ordinary no-match or an active rate limit does not mean the module has failed. For API checks, distinguish the HTTP result from the PIN match result. Do not reveal or regenerate a customer’s PIN to make a failed caller check pass.

See how Support PIN verification works in Blesta for the overall workflow, or explore PD Support PIN.