定制方案中Twilio账户与平台普通用户账户的关联方式咨询

你这套设计不符合Twilio官方使用规范，同时存在极高的安全风险，上线后大概率会遇到账户封禁、资金盗刷的问题。

原方案的核心问题 #

• 批量为终端用户创建独立Twilio账户、统一代付且完全屏蔽Twilio服务存在的模式，违反Twilio服务条款：独立Twilio账户是给独立经营主体使用的，你这种模式属于未授权转售通信资源，会直接触发平台风控。
• 在自有业务库存储Twilio Auth Token、调用凭证完成鉴权的设计有致命安全漏洞：Auth Token是对应Twilio账户的最高权限密钥，一旦泄露，攻击者可以随意盗打高额付费电话、消耗全部账户余额，你把凭证存在面向业务的数据库、甚至下发到客户端发起请求的做法，几乎必然会出现泄露盗刷。
• 管理成本极高：你手动在Console给每个用户创建独立账户、单独分配号码、核对账单的操作，完全没有用到Twilio原生的多租户能力，后续用户量上来之后根本无法维护。

完全自定义UI场景下的正确对接方式 #

你不需要给每个用户创建独立Twilio账户，所有资源统一放在你自己的1个Twilio主账户下管理即可，全流程合规、支持100%自定义UI，具体逻辑：

• 使用Twilio原生的**子账户（Subaccount）**能力做用户维度的资源和成本隔离：子账户是主账户下的逻辑资源单元，完全符合平台规则，你可以给每个平台用户对应创建1个子账户，为子账户分配专属Twilio电话号码，所有子账户的账单统一汇总到主账户结算，你可以在后台单独查看每个子账户的通话记录、消费数据，还能给单个子账户设置消费上限、呼叫地区限制，出现异常可以随时冻结子账户，不会影响其他用户正常使用。
• 所有Twilio敏感凭证统一存在你自己的服务端加密配置中，绝对不要存储在普通用户业务表、更不要下发到客户端：用户在你的自定义UI上点击呼叫按钮后，请求先发送到你的自有服务端，你先完成自有平台的用户身份校验，确认用户有呼叫权限后，再由服务端拿着对应子账户的凭证调用Twilio的语音接口生成临时呼叫令牌，把这个一次性的临时令牌返回给客户端，客户端用Twilio Voice SDK连接通话即可。整个过程用户完全感知不到Twilio的存在，你可以完全自定义所有UI交互。
• 通话过程中的所有控制逻辑（比如挂断、静音、转接、录音）都可以通过你自己的服务端调用Twilio API实现，客户端只需要和你的服务端、Twilio Voice SDK做交互，全程不会暴露任何敏感凭证。

注意：所有呼出到普通电话号码的场景，你需要遵守运营地的通信监管要求，比如保证外呼号码的显号合规、不得用于骚扰营销类呼叫，否则依然会触发Twilio的合规风控。

内容的提问来源于stack exchange，提问作者delux