Email validation for checkout and lead forms

At checkout, never block a paying customer; on a lead form, use the flags for quality. One API, two policies.

Checkout and lead capture have opposite risks. At checkout the only unforgivable outcome is turning away someone with a card in hand, so the policy is: reject only what certainly cannot receive email, and never on a maybe. On a lead form nobody is paying yet, and the question is quality: is this a person at a company, a free-mail address, a role mailbox, a throwaway?

Both get the same response. What differs is which fields your code reads.

Wire it in

const v = await verify(email, { timeout: 2000 });   // POST /v3/verify

// Checkout: reject only the certainly wrong. Everything else proceeds; the receipt confirms.
if (v.verdict === 'undeliverable' && !v.did_you_mean) return reject(v.reason);

// Lead form: score, don't block.
const lead = {
  email,
  reachable: v.verdict === 'deliverable',
  corporate: !v.flags.free_provider && !v.flags.role_account,
  throwaway: v.flags.disposable,
  provider: v.provider,             // e.g. "google.com" — the company's mail host
};

What to do with each answer here

Checkout, undeliverable	Block, with did_you_mean offered first. This is the only verdict that blocks a purchase.
Checkout, risky or unknown	Take the order. The order confirmation is your confirmation email.
Lead form, any verdict	Accept the submission; route by flags and verdict. A deliverable corporate address goes to sales now; a free-provider or unknown one goes to nurture.
Lead form, disposable	Accept and discard quietly, or reject; either is fine, and the flag makes it your choice.

What this does not do

provider is the registrable domain of the mail host (google.com for Google Workspace), not a company name.
Lead scoring on flags is policy, not verification. The verdict is the only thing we measured.

Reference: the API, handling results, result codes. A free key gives you 100 verifications a month: get one.