为预约系统接入 FPS 或其他电子支付，关键不在支付按钮，而在于先约定好资金、预约和记录如何保持一致。以下是务实而概括的考虑，具体要求取决于所选的支付服务商、银行或收单机构，请向对方确认。
付款流程由谁负责
涉及付款的预约会经过四个环节：订单、收款、退款和收据。每个环节都应指定负责人，并明确以哪个系统的记录为准。
- 订单：由预约系统决定销售内容、时段和价格。
- 收款：由支付服务商确认是否真的收到款项。不应只因为客户回到了你的网站，就把预约标记为已付款。
- 退款：明确谁可以发起退款、谁负责审批，以及是通过支付服务商处理，还是在系统之外办理。
- 收据：明确由哪个系统开具收据、内容包括什么，以及如何补发。
另外还要决定，付款处理期间时段保留多久，之后如何释放。
对账和异常情况
正常付款并不难，真正需要花心思设计的是异常情况。以下各项，请先约定如何发现和处理：
- 重复扣款：客户付了两次，或同一个付款确认收到多次。每张订单使用唯一的参考编号，并保证系统重复收到确认时也不会出错。
- 超时或结果不明：客户已付款但系统没有收到确认，或者相反。可以设置“待确认”状态，在释放或取消预约前，先向支付服务商查询结果。
- 部分退款：客户只取消同一订单中的其中一项预约。须确保退款金额、预约状态和收据保持一致。
建议定期对账，把预约记录与支付服务商的报表及结算记录逐项核对，并指定专人跟进对不上的项目。Webhook 可以及时通知付款事件，但不保证一定送达，所以仍应设置定时核对。
交易数据的权限和审计
付款数据只应让有需要的人查看。为前台员工、财务和管理员分别设置角色，并决定谁可以查阅、导出或退款。同时保留审计日志，记录谁在何时修改了预约、退款或价格。存储的付款数据不要超出支付服务商集成所需，API 密钥等机密信息也不应放在代码或共享文档中。
与会员、ERP 及门禁集成，无需重写
多数场地已有会员名单、会计软件或门禁系统，一般不必重写。可以把预约系统看作整条流程中的一环，并在可行时通过 API 或定时导出连接其他系统：
- 会员：决定会员身份和折扣是直接读取现有名单，还是复制到预约系统。
- ERP 或会计：约定传送哪些字段（例如订单编号、金额和付款日期），以及传送频率。
- 门禁：确认预约已付款后才开放进出权限，预约取消或退款时要同步收回。
可参阅系统集成说明，以及 technine.io 的系统集成与自动化服务。
上线检查清单
- 已配置测试商户账号和测试环境，并与生产环境分开
- 测试用例涵盖支付成功、失败、取消、超时、重复扣款和部分退款
- 用接近真实的数据检查收据、通知和报表
- 已检查角色、权限和审计日志
- 已约定对账流程和异常情况负责人
- 切换计划：时间、待命人员、处理进行中预约的方法，以及回退方案
- 支付服务商的支持联系方式，以及内部上报途径
常见问题
接入 FPS 或电子支付，要重做整个预约系统吗？
不一定。不少现有系统可以加入支付环节，并连接现有记录。工作量取决于现有系统如何存储预约数据，以及工作流程是否清晰。
技术和合规要求应由谁确认？
应向你的支付服务商、银行或收单机构查询，并咨询贵公司的财务或法律顾问。本文不能代替他们的意见。
预约应该在付款前还是付款后确认？
取决于业务模式。不少场地会先短暂保留时段，收到款项后才确认。无论如何选择，都应提前明确保留时间和释放规则。