---
title: "语音验证码与闪呼验证：何时用语音来验证"
description: "语音验证码（Voice OTP）与闪呼（Flash Call）验证全解析：运作原理、语音何时优于短信或WhatsApp、IRSF欺诈防范、WhatsApp到短信再到语音的备用通道设计、用户界面文案和成本比较，帮助出海团队提高验证完成率并控制风险。"
canonical: "https://omnichannels.ai/zh/blog/voice-otp-guide/"
language: "zh"
updated: "2026-10-10"
publisher: "BroadNet Technologies"
brand: "OmniChannels.ai"
category: "omnichannel"
primaryQuery: "voice otp"
keywords: ["语音验证码", "闪呼验证", "电话验证码", "短信转语音备用", "阿拉伯语语音验证码", "IRSF欺诈", "验证码备用通道", "文本转语音验证码"]
published: "2026-10-10"
author: "OmniChannels.ai Editorial Team"
reviewer: "BroadNet Messaging Solutions Team"
readingMinutes: 15
answer: "语音验证码会拨打用户的电话，用文本转语音以用户的语言朗读一次性验证码，通常读两遍。闪呼则通过一通短暂的未接来电验证号码，验证码就藏在来电显示号码中。当号码是固话、用户需要听觉而非文字，或WhatsApp和短信未能送达时，可以使用语音。请用目的地管控、限流和限制通话时长来保护它。"
takeaways: ["语音验证码在电话中朗读一次性验证码，因此能触达固话以及无法阅读短信的用户，这是短信和WhatsApp做不到的。", "闪呼通过一通未接来电验证号码，验证码包含在来电显示号码里；部分运营商会限制这类流量或对其重新定价，所以需要按国家确认是否可用。", "NIST SP 800-63B因SIM卡交换和拦截风险，将通过电话网络（短信或语音）发送的一次性验证码归为受限验证器。", "语音验证是国际收入分成欺诈的目标，因此目的地白名单、按号码和IP的限流以及最长通话时长至关重要。", "对许多消费类应用来说，合理的备用顺序是WhatsApp、短信、语音，每一步都由缺少送达或验证信号来触发，而不是仅靠固定的计时器。"]
faq: 
  - q: "什么是语音验证码？"
    a: "语音验证码是通过自动电话送达的一次性密码。平台拨打用户的号码，由文本转语音的声音朗读数字，通常读两遍，并提供按键重听的选项。它在手机和固话上都可使用，无需数据网络或应用，也适合那些觉得听数字比读短信更容易的用户。"
  - q: "闪呼验证是如何运作的？"
    a: "闪呼验证会向用户的号码拨出一通非常短的电话，并在被接听之前挂断。验证码包含在来电显示号码中，通常是它的最后几位数字。在Android上，具备相应权限的应用可以自动读取来电；在其他环境下，用户需要输入未接来电上显示的数字。不会播放任何声音，也不需要用户接听。"
  - q: "语音验证码比短信验证码更安全吗？"
    a: "本质上不是。两者都经由电话网络传输，NIST SP 800-63B都将它们视为受限验证器，因为号码可能被携转、SIM卡被交换或来电被转接。语音还有自身的风险：如果电话转到语音信箱，验证码可能被存放在信箱里。请将语音用于提高触达和可访问性，而对于高风险操作，仍应使用通行密钥（passkey）或验证器应用等更强的方式。"
  - q: "闪呼在所有地方都被允许吗？"
    a: "不是。一些运营商把闪呼视为规避A2P短信费用的手段，已将其屏蔽、收取特殊的落地费，或要求其走指定线路。规则和运营商的态度因国家而异，并会随时间变化。在设计依赖闪呼的流程之前，请向服务商确认哪些目的地支持闪呼。"
  - q: "语音验证码可以用阿拉伯语送达吗？"
    a: "可以。支持阿拉伯语的文本转语音引擎可以用阿拉伯语朗读引导语和数字，语言可根据用户的应用设置或账户资料来选择。请让阿拉伯语话术保持简短，并测试数字是如何被朗读的，因为多位数的顺序和读法与英语不同。逐位朗读验证码可以避免大多数问题。"
  - q: "语音验证码与短信相比如何定价？"
    a: "短信和WhatsApp通常按条计价，而语音通常按通话时长计价，常见为按分钟或按固定增量计费，费率因目的地以及号码是手机还是固话而差异很大。闪呼通常按每次呼叫尝试计费。由于每次验证语音的成本可能更高，多数团队把它作为备用渠道，而不是首选渠道。"
sources: 
  - title: "NIST SP 800-63B：身份验证与验证器管理"
    url: "https://pages.nist.gov/800-63-4/sp800-63b.html"
  - title: "OWASP多因素认证速查表"
    url: "https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html"
  - title: "ITU-T E.156：针对已报告的E.164号码资源滥用，ITU-T行动指南"
    url: "https://www.itu.int/rec/T-REC-E.156"
  - title: "W3C语音合成标记语言（SSML）1.1版"
    url: "https://www.w3.org/TR/speech-synthesis11/"
  - title: "W3C网页内容无障碍指南（WCAG）2.2"
    url: "https://www.w3.org/TR/WCAG22/"
---

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

Canonical: https://omnichannels.ai/zh/blog/voice-otp-guide/
Language: zh
Publisher: OmniChannels.ai by BroadNet Technologies

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

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

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

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

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

### 验证码应该如何朗读？

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

语音话术的良好做法：

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

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

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

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

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

我们的[阿拉伯语客户消息](/blog/arabic-customer-messaging-best-practices/)指南对方言选择和双语设计有更深入的介绍。

## 闪呼验证是如何运作的？

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

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

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

### 闪呼有哪些局限？

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

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

## 语音何时优于短信或WhatsApp？

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

| 情形 | 最佳首选渠道 | 语音为何有帮助 |
|---|---|---|
| 用户登记的是固话（如家庭或办公室号码） | 语音验证码 | 固话无法接收短信或WhatsApp；NIST SP 800-63B明确描述了拨打有线电话并口述验证码的做法 |
| 短暂超时后短信仍未送达 | 语音验证码作为备用 | 使用与失败的短信线路不同的网络路径 |
| 用户有视力障碍或识字水平较低 | 将语音作为可选项提供 | 语音播报的数字，免去了阅读通知的需要 |
| 用户在漫游，或所在地区短信送达较差 | 有数据网络则用WhatsApp，否则用语音 | 在短信线路无法连通的地方，电话可能接得通 |
| Android应用验证自身设备的号码 | 运营商允许时用闪呼 | 如果获得了通话记录权限，则无需输入验证码 |
| 高价值支付或账号找回 | 使用更强的认证因素，而非语音 | 通过电话网络送达属于受限验证器 |

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

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

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

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

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

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

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

这种攻击通常表现为：

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

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

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

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

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

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

| 步骤 | 渠道 | 在以下情况继续下一步 | 说明 |
|---|---|---|---|
| 1 | WhatsApp身份验证模板 | 短暂超时内没有已送达状态，或该号码不在WhatsApp上 | 复制验证码、一键或零点击；参见我们的[验证码消息指南](/blog/otp-authentication-messages-guide/) |
| 2 | 来自已报备Sender ID的短信 | 短暂超时内没有送达报告，或用户点击“没收到？” | 对手机号码覆盖面最广 |
| 3 | 语音验证码电话 | 短信失败，或用户选择“电话通知我” | 也是固话的首选 |
| 停止 | 提供其他方式 | 语音无人接听，或验证仍未完成 | 联系客服、邮件或更强的认证因素 |

### 瀑布设计步骤

1. **先对号码分类。**如果号码查询或您自己的数据显示它是固话，就直接跳到语音。我们的[HLR查询指南](/blog/hlr-lookup-number-validation/)说明了查询能告诉您什么。
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位数字。无需接听或回拨。”

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

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

## 语音验证的成本是多少？

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

| 方式 | 通常的计费依据 | 成本的决定因素 |
|---|---|---|
| WhatsApp身份验证模板 | 按已送达消息计费，依接收方市场 | 该市场Meta的身份验证费率，加上服务商费用 |
| 短信验证码 | 按条（按分段）计费 | 目的地、运营商、线路和消息长度 |
| 语音验证码 | 按通话时长，常按分钟或固定增量 | 目的地、手机还是固话、通话长度、最小计费增量 |
| 闪呼 | 按每次呼叫尝试 | 目的地，以及运营商是否收取特殊费用 |

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

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

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

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

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

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

## OmniChannels.ai 如何提供帮助

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