语音验证码与闪呼验证：何时用语音来验证

本指南面向验证手机号或发送一次性密码（OTP）、并想了解语音适合放在哪里的产品经理、工程师和风控团队。文中解释语音验证码和闪呼如何运作，它们何时优于短信和WhatsApp，如何防范其欺诈风险，以及如何构建一个兼顾完成率、成本和风险的备用顺序。

什么是语音验证码？它是如何运作的？

语音验证码是通过自动电话送达的一次性密码：平台拨打用户的电话，由文本转语音（TTS）的声音朗读验证码。它可以触达任何能接电话的号码，包括固话，并且不需要应用或数据网络。

一次典型的语音验证码通话分为五步：

1. **您的后端生成验证码，**连同过期时间一起保存其哈希值，并通过服务商发起呼叫。
2. **平台使用约定的主叫号码拨出电话，**最好是在每个国家对您的品牌来说易于识别且保持一致的号码。
3. **接听后播放一段简短的问候语，**例如“我是Hala Pay，现在为您播报验证码。”
4. **逐位朗读验证码，**数字之间有停顿，并且至少重复一遍。
5. **向用户提供重听选项，**例如“按1键重听验证码”，然后结束通话。通话结果（已接听、忙线、无人接听、失败、时长）会返回给您的系统。

验证码应该如何朗读？

每个数字单独、缓慢地朗读。“四、七、一、九、零、二”比“四十七万一千九百零二”更容易记下来。大多数TTS引擎都支持语音合成标记语言（SSML），这是W3C标准，可让您把文本标记为逐个字符、插入停顿并控制语速。请使用它，而不是依赖引擎对数字的默认解读。

语音话术的良好做法：

• **问候语控制在几秒之内。**用户正拿着笔或守在键盘前等待；每多一句话都会延误验证码。
• **验证码至少说两遍，**两次之间稍作停顿，然后提示按键重听。
• **只有在有帮助时才分组。**六位数字按三位一组读（“四七一……九零二”），可能更便于记忆。
• **绝不要求用户在通话中说出或输入验证码。**验证电话只负责传递验证码，绝不能收集验证码。这能让您的流程与社会工程学的诈骗话术区分开来。

如何选择语言，包括阿拉伯语？

按您手上最强的信号来选择语言，顺序是：用户在您应用中选择的语言、账户资料，然后才是号码的国家区号。沙特的号码并不意味着用户偏好阿拉伯语，而住在迪拜的外籍人士可能想要印地语、乌尔都语、他加禄语或英语，所以已保存的偏好胜过猜测。

对于阿拉伯语语音验证码：

• **使用专为阿拉伯语设计的TTS声音，**并请母语者测试。对这样简短而正式的消息，现代标准阿拉伯语是最稳妥的默认选择。
• **逐位朗读数字。**阿拉伯语口语中许多数字是个位在十位之前，所以把验证码当作一个整数来读，很容易听错。逐个数字朗读可消除歧义。
• 在人口构成混杂的市场，**可以考虑双语通话：**一段简短的阿拉伯语问候和验证码，然后是“English请按2”。保持简短；双语菜单会给每通电话增加几秒钟。
• **让品牌名称易于识别。**如果您的品牌通常用拉丁字母书写，请检查TTS声音如何用阿拉伯文读它。

我们的阿拉伯语客户消息指南对方言选择和双语设计有更深入的介绍。

闪呼验证是如何运作的？

闪呼验证会向用户的号码拨出一通非常短的电话，并在被接听之前挂断。验证码就是来电显示号码本身，通常是它的最后几位数字，所以既不会播放任何内容，也不需要接听。

验证码有两种方式到达您的应用：

• **自动：**在Android上，具备相关通话记录或手机状态权限的应用可以检测来电并匹配号码，用户无需任何操作。平台的权限政策适用，许多应用会避免申请这些权限。
• **手动：**用户看到未接来电，并把最后几位数字输入您的应用。这在任何手机上都可使用，包括不允许应用读取通话记录的iPhone。

闪呼有哪些局限？

闪呼速度快，且不依赖短信线路，但它有实实在在的限制：

• **运营商态度各异。**一些运营商把闪呼看作不用支付A2P短信费用就能验证用户的手段。在部分国家，它们已经屏蔽闪呼、引入特殊的落地费，或要求其走指定线路。政策会变化，所以请向服务商确认各国的支持情况，并定期复核。
• **主叫号码必须完整到达。**在某些国际线路上，主叫号码可能被篡改或替换，从而破坏验证码。能可靠送达主叫号码的优质线路是前提条件。
• **不加解释会让用户困惑。**来自陌生国际号码的未接来电，看起来像“Wangiri”回拨诈骗。请在呼叫之前告诉用户会发生什么，并且绝不要让他们回拨这个号码。
• **它验证的是对号码的持有，而不是身份。**与任何电话网络方式一样，它会因SIM卡交换和呼叫转移而被削弱。

语音何时优于短信或WhatsApp？

当文字无法触达用户或用户无法阅读时，语音是更好的渠道。在大多数其他情况下，WhatsApp或短信更便宜、更快，这就是语音通常排在备用顺序靠后位置的原因。

无障碍是要求，而不是锦上添花

有视力障碍、阅读障碍或识字水平较低的用户，可能觉得语音验证码比文字通知更容易；而有听力损失的用户，则会觉得语音通话更困难。NIST SP 800-63B指出，通过语音发送的验证码，听力有问题的人可能难以理解，并要求为所有用户提供替代方案。务实的答案是给用户选择：并排显示“改为电话通知我”和“通过短信发送”，并按照WCAG 2.2的要求，让验证码输入框能被屏幕阅读器正常使用。

语音验证码的安全局限是什么？

语音验证码和短信验证码有相同的弱点：它们证明的是对某个手机号的控制权，而号码可能被携转、SIM卡被交换或来电被转接。NIST SP 800-63B将通过公共电话网络（短信或语音）进行的带外认证归类为“受限”验证器。使用它的组织必须评估风险，向用户提供有意义的告知，并提供不受限的替代方案。OWASP多因素认证速查表更进一步，建议处理敏感个人数据或涉及资金风险的应用不要使用短信和电话。

语音还有一个特有的弱点：**语音信箱。**如果未接听的验证码电话转入语音信箱，验证码可能被录进一个由弱PIN或默认PIN保护的信箱。请使用应答机检测，在机器接听时不朗读验证码就结束通话，并把“语音信箱”视为一次失败的送达，这可能触发另一个渠道。

攻击者如何滥用语音验证？

语音验证是流量泵送的目标，尤其是国际收入分成欺诈（IRSF）的目标。攻击者向某些号码段触发验证电话，他们自己或通话链路中的合作方可从落地收入中分成。每通电话都由您付费。

这种攻击通常表现为：

• 脚本向您的真实用户很少来自的目的地的号码突发大量请求。
• 同一号码段内连续或有规律的号码。
• 因为通话越长收入越多，**电话被接通后一直保持，**直到您的流程允许的最长时间。
• **从未完成验证的请求。**攻击者对验证码根本不感兴趣。

ITU-T E.156建议书规定了ITU如何处理所报告的国际号码资源滥用，这说明该问题在标准层面已被认可。但它并不保护您的预算；真正保护预算的，是您自己的控制措施。同样的模式也适用于短信，详见我们的短信泵送指南。

语音验证码的欺诈防控清单

1. **目的地白名单。**仅对有真实用户的国家启用语音验证，并每季度复核名单。
2. **屏蔽增值和高风险号段。**询问服务商默认屏蔽了哪些号段，并加入您自己的号段。
3. **限制通话时长。**语音验证码通话远不需要一分钟。验证码重复之后就挂断，并设置严格的最长时长。
4. **多维度限流：**按手机号、设备、IP地址、账户和目的国家分别限制，并设置一个全局花费上限，超出时暂停语音。
5. **要求此前的步骤失败。**在备用流程中，只有在同一会话中已尝试过短信或WhatsApp之后，才提供语音，这会提高攻击者的成本。
6. **为请求设门槛。**在发送任何验证之前（而不仅仅是语音之前），使用机器人检测或挑战。
7. **关注转化率。**按国家统计已验证会话数除以已拨出电话数。某个国家的比率下降，是泵送最早的信号。
8. **重试方面遵循NIST。**NIST SP 800-63B要求对失败尝试限流，并规定生成新验证码不应重置失败尝试次数。请把同样的思路用于重发：新的一通电话不是重新开始。

如何设计WhatsApp、短信和语音的备用瀑布？

备用瀑布先尝试最便宜的合适渠道，只有在有证据表明上一次尝试失败时才继续。对于海湾地区及其他WhatsApp盛行市场的许多消费类应用，一个实用的顺序是：WhatsApp，然后短信，然后语音。

瀑布设计步骤

1. **先对号码分类。**如果号码查询或您自己的数据显示它是固话，就直接跳到语音。我们的HLR查询指南说明了查询能告诉您什么。
2. **整个会话使用同一个验证码，或有意识地轮换。**要么在有效期内跨渠道复用同一个验证码，要么在发送新验证码时让旧验证码失效。不要让多个有效验证码同时存在。
3. **用信号而不是仅靠计时器来触发。**送达状态、“不在WhatsApp上”的响应和用户的操作，是比固定延迟更好的触发条件。保留一个较短的超时作为兜底。
4. **让用户可以提前跳到下一步。**短暂的倒计时之后，显示“通过短信发送”和“改为电话通知我”。用户知道自己的消息什么时候没到。
5. **限制步骤数量。**三个渠道、每个一次尝试，通常就够了。更多的重试多半只对攻击者有利。
6. **记录每一次尝试，**包括渠道、状态、成本和结果，这样您就能按国家和渠道比较完成率。
7. **如实设定有效期。**NIST SP 800-63B要求带外认证在10分钟内完成。许多团队对登录和支付使用更短的有效期。

界面和电话应该说什么？

好的用户体验文案会让用户对即将发生的事有所准备，这对语音和闪呼来说最为重要，因为一通意外的来电看起来很可疑。

语音验证码呼叫之前（界面）： “我们现在将拨打+971 5X XXX XX12，并朗读您的6位验证码。请准备好纸笔。”

通话中（语音）： “我是Hala Pay。您的验证码是：4、7、1、9、0、2。再重复一遍：4、7、1、9、0、2。Hala Pay绝不会要求您透露此验证码。按1键可重听。”

闪呼之前（界面）： “我们将给您一个简短的未接来电。请输入来电号码的最后4位数字。无需接听或回拨。”

适用于各种语言的文案规则：

• **显示脱敏后的号码，**让用户能发现输错的情况。
• 在语音话术中先说明品牌。
• 用用户的语言加入一句“切勿告知他人”。
• **说明不要做什么：**不要接听（闪呼）、不要回拨、除了重听之外不要按任何键。
• **用母语习惯翻译，**而不是逐字翻译，并请母语者录制或测试阿拉伯语版本。

语音验证的成本是多少？

语音和消息使用不同的定价模型，所以请比较每次完成验证的成本，而不是每次尝试的成本。

由此可以得出三点实用建议。保持语音通话简短，因为时长是成本驱动因素。把语音作为备用，这样只有在更便宜的渠道失败时才支付语音费率。并且按国家衡量每个已验证用户的成本，因为一个便宜却送不到的渠道，会因流失的注册而变得昂贵。关于各渠道的参考标价，请使用我们的价格估算器；最终费用以报价为准。

实战示例：利雅得的一款支付应用

“Hala Pay”（虚构）是一款在沙特阿拉伯、阿联酋和埃及都有用户的支付应用，它发现没有WhatsApp的用户，以及短信送达较慢的地区的用户，在手机验证环节注册停滞。

• **瀑布：**首先是WhatsApp复制验证码；如果WhatsApp在短暂超时内未送达，则通过已报备的Sender ID发送短信；如果短信未送达，或用户点击“电话通知我”，则发起语音验证码电话。
• **语言：**通话语言跟随应用的语言设置。阿拉伯语电话使用阿拉伯语TTS声音逐位朗读数字；英语则通过按键提供。
• **欺诈控制：**语音仅对这三个市场启用，增值号段被屏蔽，通话在读两遍并给一次可选的重听机会之后结束，并有一个每日语音花费上限，达到后会暂停该步骤并通知风控团队。
• **语音信箱：**当信箱接听时，应答机检测会在不朗读验证码的情况下结束通话。
• **高风险操作：**添加新收款人时，要求在已注册的设备上进行应用内确认，而不是使用电话网络验证码。
• **复盘：**团队每周按国家和渠道，比较每次尝试的已验证注册数以及每个已验证用户的成本，并调整超时。

语音验证码和闪呼有哪些常见错误？

• **把验证码当作整数来朗读，**而不是逐位朗读。
• **问候语过长，**既延误验证码，又增加计费秒数。
• 因为没有使用应答机检测，把验证码留在了语音信箱里。
• **对所有国家都启用语音，**结果在账单上发现了IRSF。
• **无限次重发，**或者每生成一个新验证码就重置尝试计数器。
• **事先不告知就拨出电话，**导致用户无视陌生号码。
• 在没有确认运营商支持的情况下，以为闪呼在所有地方都能使用。
• **把语音验证码当作强认证，**用于支付或账号找回。
• **忽视固话，**导致登记了固话的用户永远无法完成验证。
• **局限：**运营商政策、主叫号码规则和监管要求因国家而异，并会变化。本指南描述的是实践，不构成法律意见；在新市场上线之前，请向服务商和相关监管机构确认现行情况。

OmniChannels.ai 如何提供帮助

OmniChannels.ai把语音与WhatsApp身份验证模板和短信结合，用于验证码和通知。语音涵盖语音验证码、闪呼、短信转语音回退，以及包括阿拉伯语在内的文本转语音，并与我们的客户团队一起，围绕您的号码、国家和通话流程开通，而不是通过公开的REST接口提供。渠道回退按使用场景配置，送达状态被统一为一种Webhook格式。语音与BroadNet Technologies配合提供，其呼叫中心软件DialerBee同样提供应答机检测。请在我们的语音开发者指南中了解语音是如何开通的。