为大型物业业主规划充电桩平台：两款车主应用、预付钱包与三级身份验证

一个有四个充电枪的小区，是“场地方”的问题。而一个在多个地区拥有几十个住宅小区、每处都装有充电桩的业主，面对的是另一类问题：总部的人不可能跑到每个充电桩前，所以系统要在没有人工参与的情况下完成四件事——让陌生人能够开始充电、把钱收回来、防止滥用，并按小区和地区向总部呈现发生了什么。

我们最近为一家大型住宅类物业业主做了这样的需求规划。本文讲我们是怎么拆解的，因为只要是拥有多个场地的业主，这套结构都适用。先说明边界：本文不透露业主名称，而且这是一次需求规划，不是上线公告。

已经在运行的，和需要新开发的

需求规划中最有价值的一件事，就是把这两者分清楚。我们这次的划分如下。

我们的平台上已经在运行的功能：

• OCPP 1.6 服务器，充电桩通过加密 WebSocket 连接，支持实时状态和远程启停。
• 网页管理后台：会话、支付、告警、远程控制、审计日志，以及带 VAT 明细的每日收入报表，可导出 Excel。
• 在浏览器中打开的扫码充电页面，访客可用 PromptPay 支付。
• 与合作网络的 OCPI 漫游。

为这位业主规划的新开发内容，尚未交付：

• 把小区和地区作为后台的一级分组，并设置总部、区域、小区三层角色。
• 手机号登录的车主账户，以及预付钱包。
• iOS 与 Android 原生车主应用。
• 作为第二阶段：证件身份验证、推送通知，以及原生应用内的漫游站点。

这份清单必须如实。如果把新开发的内容说得像已经存在，与客户的第一次工作坊就会变成纠错会。

两款车主应用，一个账户

网页应用和原生应用常被当成二选一。但对物业业主来说，它们是进入同一个系统的两扇门。

网页应用面向访客和第一次使用的住户：扫描充电桩上的二维码，无需安装，直接充电。它也是更新最快的方式，因为一次修复，所有人立即生效。

原生应用面向常用用户：增加附近站点地图、充电完成或余额不足时的推送消息、已保存的车辆、指纹或面部解锁，以及身份验证。更新要经过应用商店审核，所以变化更慢。

让这套方案成立的设计原则是：两者使用同一个后端。用户先在网页上使用，之后再安装应用，就能看到同一个账户、余额和历史记录。如果两个版本各有各的账户，你实际上就是在运营两个产品。

两种应用的充电流程相同

流程刻意做得平淡无奇。用户选择站点，余额不足时，应用先引导去充值。然后开始充电，应用实时显示电量和费用，停止后收据会留在历史记录中。

flowchart TD
    A["扫码或打开应用"] --> B["已登录"]
    B --> C["选择站点并查看费率"]
    C --> D["余额充足"]
    D --> E["开始充电"]
    E --> F["实时显示电量 功率和费用"]
    F --> G["停止或充满"]
    G --> H["收据保存到历史记录"]
    B -->|"未登录"| I["手机号加一次性验证码登录"]
    I --> C
    D -->|"不足"| J["用 PromptPay 二维码充值"]
    J --> E

不登录的访客仍可以以游客身份充电，结束时用 PromptPay 支付本次费用。这让任何人都能使用充电桩，对这类业主而言，往往正是公共服务层面的目标。

风险集中在钱包

预付钱包解决了“充了电不付钱”的问题，同时也是整个方案里最容易出事的部分。有三个决定承担了大部分分量。

先冻结，再按实际金额扣款。 会话开始时，系统在钱包里冻结一笔最低金额；停止时扣除实际费用并释放冻结。余额为零无法开始充电，冻结的部分也不会被收费。

只有支付服务商确认后才入账。 充值通过 PromptPay 二维码支付。钱包只在支付服务商的 webhook 确认收款后才入账，绝不因为应用说“已经付了”就入账。在涉及钱的问题上，应用不是可信来源。

通往充电桩只有一道门。 车主 API、管理后台和漫游服务，都通过 OCPP 服务器的控制 API 向充电桩发指令。只有这台服务器与充电桩通信。审计一条路径，比审计三条容易。

三级信任

并非每位车主都需要相同的额度。我们规划了三个级别，每级各有钱包上限。

级别	如何达到	钱包
游客	无账户，每次会话用 PromptPay 支付	无
手机号已验证	输入短信发送的一次性验证码	较低的余额上限
身份已验证	在原生应用中扫描泰国身份证并通过自拍比对	较高的上限

上限由客户一起确定，而不是我们定死。身份验证属于第二阶段的可选功能，因为它是最难做对的部分：既取决于验证服务商的选择，也取决于应用商店对采集证件图像类应用的审核。

两个阶段，每个都可以单独上线

我们这样拆分交付，使第一阶段本身就有用。第一阶段包括生产环境、后台调整、账户与钱包、网页应用和原生应用，以及充电桩接入调试、验收测试和人员培训。第二阶段在原生应用中增加身份验证、漫游站点和推送。两个阶段分别验收、分别开票。

排期上真正的约束是硬件。只有充电桩和现场网络到位，接入调试才能开始，所以我们在启动会上约定就绪日期，并从开发早期起使用模拟充电桩测试。

我们一开始就摆到桌面上的风险

• 钱包相关法规。 预存价值的钱包在泰国会带来法律问题。我们建议在最初几周做法律审查，并让钱包上限可配置，这样规则晚些变化也不必推倒重来。
• 个人数据。 车主的手机号和证件图像受泰国《个人数据保护法》（PDPA）约束。因此方案包含同意页面、加密、保存期限、访问日志，以及应请求删除。
• 托管政策。 政府和大型企业客户往往有托管或安全方面的要求。我们以容器方式运行系统，同一套构建既可跑在我们管理的云上，也可跑在客户自己的数据中心里。
• 应用商店审核。 带钱包和证件采集的应用审核更严，所以每次发版都预留缓冲时间，期间网页应用仍可使用。
• 超出首批规模后的定价。 基础价格覆盖固定数量的充电桩。超出部分，按单桩收取接入费和维保费，并随网络变大而递减，比每次扩容都重新报价更公平。

动手写代码之前要回答的八个问题

如果你拥有或管理众多场地，这些问题比任何功能清单都更能决定范围。

1. 各阶段涉及多少个小区、多少台充电桩，品牌和型号是什么，由谁安装？
2. 充电桩只给住户使用还是对公众开放，住户是否享受不同费率？
3. 谁来定价，是否有停车费或占位费；如果合作方运营部分场地，收入如何分成？
4. 是否要求指定的云或数据中心，需要满足哪些安全标准？
5. 哪些员工角色需要访问后台，各自能看到什么？
6. 每个验证级别的钱包上限是多少，由谁聘请法律顾问？
7. 使用哪家身份验证服务商？
8. 采购流程是否需要泰文文件或特定格式？

如果你想针对自己的物业组合梳理这些问题，请把场地数量、充电桩数量以及谁承担电费发送到 hello@simplico.net，邮件主题写 “Property EV scoping”。我们会在 48 小时内回复一份范围草案。

常见问题

预付钱包已经是你们平台的一部分了吗？
还不是。带 PromptPay 支付的扫码充电页面、OCPP 服务器、管理后台和 OCPI 漫游已经在运行。本文描述的钱包、车主账户、原生应用和身份验证，是规划中的新开发范围。

车主必须安装应用吗？
不必。车主扫描充电桩上的二维码，就能在浏览器中充电，无论是游客还是手机号已验证的账户。原生应用是可选的，增加地图、推送消息和身份验证。

可以先用网页，之后再换成原生应用吗？
可以，设计上就是这样。两者共用账户、钱包和历史记录，余额会跟着车主走。

如何防止钱包为空时开始充电？
开始充电时会冻结一笔最低金额。若余额不足，应用会先引导车主去充值。

业主能按小区和地区查看收入吗？
这种分组属于规划中的后台开发内容。现有后台已提供带 VAT 明细的每日收入，并可导出 Excel。

哪些充电桩能接入平台？
任何通过 WebSocket 支持 OCPP 1.6J 的充电桩。EV CSMS 页面列出了我们实际跑过会话的品牌。

是谁写了这篇文章？
Simplico，一家位于泰国的软件工程工作室。我们为泰国和东南亚的运营商构建并运营充电桩平台。

相关文章

• 充电桩场地方的难题：怎样让物业、酒店或餐厅看到自己的充电桩后台，又不必再多一个账号
• OCPI 详解：CPO 与 eMSP 要实现电动车漫游充电，究竟需要搭建什么
• 不用自己开发的EV充电App：基于OCPP ID标签的二维码充电方案