Zalo 2026 年 6 月新版 OA 资费落地：一支跨境团队如何继续接收 Zalo 消息，又不用被 OA 流程拖着走 — UnifyPort

2026 年 6 月 1 日，Zalo 全新的官方账号（OA）服务资费正式生效。对于一支在胡志明市小办公室里卖护肤品的五人跨境团队来说，这封邮件来得不是时候：正值大促期间，两名同事几乎一整天都在 Zalo 和 WhatsApp 的聊天里回复客户。这份资费通知把他们一直拖着没面对的问题逼了出来——继续做我们现在做的事，到底要花多少钱？

而他们现在做的事其实很简单：客户在 Zalo 上给店铺发消息，有人回复。就这样。没有群发、没有营销推送、没有自动滴灌序列。可是 Zalo 给”想以程序方式接收消息的企业”铺的那条路，要走完整套官方账号的流程——而这套流程是为群发方设计的，不是为一支只想回复主动找上门的客户的团队设计的。

OA 这条”跑步机”，为什么不适合他们

通过官方途径接收 Zalo 消息，意味着要开通官方账号、完成认证，然后在 OA 的规则里生活。最难受的是互动窗口：OA 只能在用户主动联系你之后的一段有限时间窗口内自由地给该用户发消息。一旦超出这个窗口——第二天早上跟进、两天后发个订单更新——你就进入了 Zalo Notification Service（ZNS）的范畴：每条消息都要挂在一个预先审核过的模板上，并且按条收费。

对群发方而言，这笔交易很合理；对一家五人小店来说，这就是一台跑步机。每个模板都要先撰写、提交、等待审核，才能使用。6 月 1 日的资费调整重新划分了 OA 套餐的档位，也改变了哪些算在免费额度内、哪些要计费——而团队的解读是：他们这种真正低频、对话式的用法，眼看着既要变贵、又要变得更繁琐。他们并没有在发成千上万条营销消息，他们只是在回答问题，却被要求套用一家”做着他们根本没在做的事”的公司的成本结构和审核流程。

而且 Zalo 还只是其中一个收件箱。同样这两名同事一整天也泡在 WhatsApp 里，那边又有自己一整套机制——企业验证、按条计费、自家的模板审核。两个平台、两套完全不同的规则；真要做自动化，就是两套对接。代价不只是钱，更在于每个渠道都要求团队先学会一套不同的系统，才能做成他们真正想做的那一件事：看到消息进来，然后回复。

重新定义问题：他们要的是入站，不是一个官方账号

真正解开这道题的洞察，是把他们需要什么和官方路径打包了什么分开来看。OA 的群发机制——模板、ZNS、互动窗口、额度档位——存在的意义，是让企业能够大规模地主动发起联系。而这支团队从不主动发起，每段对话都由客户先开口。他们需要的，仅仅是可靠地接收入站消息，并在客户已经打开的那段对话里回复。

这比”运营一个官方账号”要小得多。只做入站、只在会话内回复的用法，根本用不上那套群发工具。一旦这样看，问题就不再是”我们该买哪个 OA 套餐”，而变成了”把一条入站的 Zalo 消息送到我们后端、再把回复发回同一个聊天，最简单的办法是什么”。

一个 webhook，同时管 Zalo 和 WhatsApp

他们通过 UnifyPort 的非官方入站接口把两个账号都接了进来。它把每个渠道都收到同一个归一化的 webhook 之后，而不是每个平台做一套对接。一条 Zalo 消息和一条 WhatsApp 消息以完全相同的结构抵达，唯一的区别就是 provider 字段：

{
  "event": "message.received",
  "account_id": "acct_7Hm2pX",
  "provider": "zalo",
  "from": "user_9a3f21",
  "text": "Sản phẩm này còn hàng không ạ?",
  "timestamp": 1749513600,
  "message_id": "zalo_msg_4c8e1d"
}

他们的后端只订阅一个事件 message.received，并按单个字段分流。处理 Zalo 消息的那段代码，和处理 WhatsApp 消息的是同一段——接收侧没有任何按平台分叉的逻辑：

app.post("/webhook", (req, res) => {
  if (!verifySignature(req)) return res.sendStatus(401);

  const evt = req.body;
  if (evt.event === "message.received") {
    // evt.provider 是 "zalo" 还是 "whatsapp" —— 分流逻辑完全一致
    queue.add({
      channel: evt.provider,
      customer: evt.from,
      text: evt.text,
      accountId: evt.account_id,
    });
  }
  res.sendStatus(200);
});

每一次投递都带签名，所以团队在信任任何 payload 之前，会用他们在 webhook 上设置的 signing_secret 做一次 HMAC-SHA256 校验——无论消息来自哪个平台，都是同一个 verifySignature 步骤。回复则是镜像操作：一次 POST /v1/messages 调用，指明账号与收件人。因为是客户先发的消息，每条回复都落在客户打开的那段对话里——正是团队原本手动在做的”会话内互动”，现在可以脚本化，而且不需要预审任何模板。

实际结果是，6 月 1 日的资费通知不再是一场预算危机。团队没有为了继续回复这些低频、客户主动发起的聊天，而被迫往 OA 更高的档位上买。两名客服还是守着同样的两个收件箱，只不过这两个收件箱现在汇入同一个队列、同一套结构、同一条回复路径——而日后为一个泰国供应商再接入 LINE，依旧是那段 message.received 处理逻辑，而不是第三个对接项目。

可以带走的结论

教训不是”别用 Zalo 的官方账号”——如果你在做规模化的群发营销，OA 和 ZNS 正是为此而生，你就该用它们。教训是：先确认官方路径解决的，是你的问题，还是一个你其实没有的更大的问题。一项针对高频群发方的资费调整，可能悄悄抬高了你”仅仅回复客户”的成本，因为官方途径把这两种行为打包进了同一个账号。

如果你需要的只是接收入站消息、在会话内回复，那这是一个可以单独拆出来、便宜得多的问题。把你的后端指向一个归一化的入站 webhook，订阅 message.received，Zalo 消息就会进入你的队列，而不必踩 OA 这台跑步机——等哪天你需要其余五个渠道时，它们也会从同一段处理逻辑里到来。