Bulk PAN verification without tripping rate limits

Do not fire everything at once

A naive loop that sends 5,000 requests in a tight loop will hit a per-minute cap, get throttled, and leave you with a mix of results and 429s that are painful to reconcile. Spread the work: a queue with a fixed worker count, or a scheduled job that processes a few hundred per run.

Aim to stay comfortably under the documented per-minute and per-hour limits with headroom, because retries also consume quota.

Idempotency keys save you

Attach a stable key to each row (the PAN plus a batch id) and record the result against it. If the job dies halfway, you resume from where you stopped instead of re-charging for PANs you already checked. This also makes the job safe to re-run after a code fix.

Store the full raw response, not just your pass or fail. Downstream teams will ask what name the check returned for a given vendor months later.

Handle the three outcomes distinctly

Every row lands in one of three buckets: verified and matched, verified but mismatched, or could-not-verify (invalid format, inactive, upstream error). Only the last bucket is worth retrying. Mismatches go to a review queue; do not retry them automatically because the answer will not change.

Export the review queue as a CSV with the input, the returned name, and your similarity score so a reviewer can clear it in minutes.

Cost control

Failed and not-found lookups on a good API are free, so the expensive part is the successful checks. De-duplicate your input list first: vendor masters are full of the same PAN under slightly different names, and you often cut the billable volume by a fifth.