Why we dropped Twilio Verify for Google: a Korean KYC dead end

[keib918-commits]

Pollreal needs one thing before anyone can vote: a phone number verified once. We built that on Twilio Verify, and this week we dropped it for Google Identity Platform (Firebase phone auth). Writing down why, in case it saves another non-US founder a week.

What happened with Twilio

• To send verification SMS to numbers you haven't verified yourself, Twilio requires an approved Primary Customer Profile (business KYC). Until then every send to a real user fails with error 21608.
• Our authorized representative is Korean. For South Korea, the identity flow offers only Korea Digital ID (mobile-carrier verification) — there is no option to upload an ID document instead.
• The carrier verification passed every time. The selfie step that follows failed every time ("Couldn't verify photos" — three attempts on two days). Our guess: in the carrier flow there is no ID photo for the selfie to be compared against, so a Korean representative can't pass it by retrying.
• We asked for a manual review on the failure screen, then opened a support ticket. No reply in five days, on an upgraded, prepaid account that could not send a single SMS.

What we use now

• Google Identity Platform sends and checks the code. Our server calls it directly; Google's user record is deleted as soon as the code is confirmed (we keep only a keyed hash of the number).
• reCAPTCHA SMS defense is on in enforce mode: Google scores each request for SMS toll fraud and refuses to send when the score is too high.
• Internet/VoIP numbers are still refused by a numbering-plan check before anything is sent; our own per-number, per-network, per-country and daily caps stay as they were.
• Cost per code turned out lower too: USD 0.01 for Korea and the US on Google's price list, versus about USD 0.10 (Korea) / 0.06 (US) for Verify plus SMS on Twilio.

Trade-offs

• We lost Twilio Lookup's carrier line-type check. The numbering-plan check catches most virtual numbers; the SMS fraud score covers the abuse case it was really there for. Not identical — if you know a better free signal, tell us.
• Google bills per SMS sent rather than per successful verification, so the daily caps matter more. We get an email the moment a cap is hit.
• We asked Twilio to refund the unused balance and close the account.

Open question: how else can we check the carrier line type?

This is the piece we would most like help with. Before sending a code, we want to know whether a number is a real mobile line or a VoIP / virtual / internet number — the kind that can be bought in bulk to create fake voters.

• What we have now: a numbering-plan check (libphonenumber metadata). It is free and offline and refuses ranges that are VoIP by design (Korea's 070, for example), but it cannot see numbers that were ported to a virtual provider.
• What we gave up: Twilio Lookup's line-type intelligence, which asks the carrier side and does see ported numbers.
• What we need: global coverage (sign-ups come from many countries), a per-lookup cost in the cents or less, and no KYC wall for a small non-US company.

Is there another way to get a reliable line type — another lookup provider you have actually used, a carrier or HLR source, or a signal we haven't thought of? Real-world experience, including "we tried X and it was useless", is very welcome in the comments.

Also: has anyone else hit the same Korea KYC wall on Twilio (or another provider)? Curious whether there is a path we missed.