验证码、订单通知、预约提醒。没有人会退订这些 —— 但它们失败的方式和营销短信不同，设置的方式也要不同。
促销短信晚到二十分钟没关系；验证码晚到二十分钟就已经失败了 —— 用户放弃了，更糟的是又请求了三次，四条你全都付了钱。两者共用同一个送达网络，除此之外几乎没有共同点：
| 交易短信 | 营销短信 | |
|---|---|---|
| 同意 | 交易本身即隐含同意 | 需要明确同意 |
| 时效 | 以秒计 | 当天到就可以 |
| 用量 | 不可预测，由事件触发 | 事先规划 |
| 发件人 | 短代码，用户收验证码时信任它 | 品牌 Sender ID |
| 失败代价 | 用户登录不了 | 少了一次曝光 |
1. 用短代码发。银行已经把用户训练成「验证码就从 5 位数号码发来」。从陌生品牌名发来的验证码看起来像钓鱼，会被忽略。注意收件人不能回复我们的共享短代码 66886，我们也收不到回复 —— 短代码详细介绍。
2. 交易短信保持干净。不用 emoji —— 一个就会让短信变成 Unicode，在我们的通道上把每段可用字数从 156 降到 66，可能悄悄把你的验证码拆成两段收费。验证码里也不要夹带营销字眼：那会破坏让这条短信合法的隐含同意。
3. 让重试变得安全。事件触发的发送，代码总有一天会在超时后重试。重试不是幂等的话，一次结账卡顿就变成两条验证码、两次扣费。通过我们 API 发送的每个请求都接受 Idempotency-Key，重复的请求会返回原来的结果，而不是再发一次。
单号码发送不会排在群发后面：三个号码以内的请求一被接收就交给运营商。接入验证码的完整清单在 API 文档的 OTP 部分；验证码的费用、速度和发件号码见短信验证码。
交易短信的失败从内部是看不到的：用户不会开工单说「验证码没收到」，他们直接走了。要看两样东西：
交易短信的用量跟着你的生意走，不跟着套餐走 —— 淡季就该花得少，而不是一样多。预付额度、没有月费、不会过期，比按最忙那一周买的订阅更合适。目前价格见价格页。
交易短信由收件人自己的行为触发 —— 验证码、订单更新、预约提醒 —— 同意隐含在交易里。促销短信是广告，按 PDPA 需要明确同意。两者在操作上也不同：交易流量对延迟敏感、用量不可预测。
不需要另外的营销同意，因为短信是客户要求的服务的一部分。但号码仍然只能用于这个用途 —— 在验证码里夹带促销，就把它变成了营销短信，也就失去了这个依据。
在马来西亚网络上，短信本身通常几秒内就到手机。运营商的送达回执可能要几分钟到几小时才回来，回来之前报告会显示「处理中」。用户说要等好几分钟或根本没收到，常见原因是内容被过滤或线路问题，而不是手机问题 —— 看逐个号码的送达报告和已提交、已送达之间的差距。
可以，通过 REST API。交易短信一般都这样设置，因为触发点是你应用里的事件，而不是有人上传名单。
如果带了 Idempotency-Key 请求头，第二次请求会返回第一次的结果，不会再发、也不会再扣钱。不带的话，第二次会被当成新短信。事件触发的发送，一定要带上这个请求头。