明确账户所有权和开户职责
首先绘制 POS 平台与各个已连接商户账户之间的关系。记录由谁负责发起开户、提供企业信息以及答复问题。与 NeroPay 确认平台、商户和 NeroPay 分别承担哪些职责；不要假设平台账户能让团队不受限制地访问商户信息。
考虑商户拥有多个营业地点或使用多个 POS 安装实例时会出现的情况。内部记录需要清楚表明每笔支付对应的企业和账户。确定开户设计之前，询问 NeroPay，了解支持的账户结构是否适用于预期设置。
- 指定一名运营负责人和一名技术负责人，负责此次集成。
- 列出预计需要管理的商户详细信息和账户关系。
- 请 NeroPay 确认开户职责和访问要求。
- 记录由谁处理未完成的申请或商户信息变更。
确认环境并记录支付流程
与 NeroPay 一起审查现有集成文档，并确认拟议用途支持哪些环境。明确如何申请访问权限、谁可以使用各个环境，以及开始正式使用前需要完成哪些事项。在确认可用性之前，不要围绕假定存在的测试环境、端点或设备进行设计。
梳理从 POS 销售到记录付款结果的整个流程。明确团队必须完成的有文档记录的任务、每个阶段所需的信息，以及可能需要工作人员介入的环节。讨论中也要包括尚未解决或中断的付款，而不只是顺利完成的销售。
- 索取相关文档，并确认其适用于您的使用场景。
- 列出 NeroPay 确认的环境、设备和访问安排。
- 为每项有文档记录的集成任务和待解答问题指定负责人。
- 商定在考虑正式上线前需要准备哪些证明材料。
设计参考信息和事件处理方式，以便对账
确定 POS 将如何把销售参考编号与有文档记录的集成所提供的付款信息关联起来。商定支持团队和商户在调查问题时应使用哪个参考编号。请向 NeroPay 确认付款参考编号的格式、可用性和含义，不要假设所有系统使用相同的标识符。
查看有文档记录的付款事件、各事件的含义，以及应用程序应如何响应。收到事件与完成销售对账是两回事：团队仍需制定记录比对和差异调查流程。询问如何识别尚未解决的结果，以及升级处理时应保留哪些信息；不要假设记录会自动同步。
- 将 POS 销售参考编号映射到 NeroPay 文档中记录的付款参考编号。
- 列出支持的事件，以及系统或团队针对每种事件将采取的操作。
- 明确工作人员将如何识别缺失、无法匹配或不明确的记录。
- 商定升级处理的联系人，以及提交问题时应包含的信息。
通过实例审查商户可见信息
假设示例：某 POS 服务提供商为一家拥有两台收银机的英国咖啡馆提供服务。该服务提供商希望经理能够从任一收银机追踪销售，并找到相应的付款记录。上线前，团队记录咖啡馆所属的商户账户、每台收银机如何识别销售，以及可用的付款参考编号。团队与 NeroPay 讨论有文档记录的事件和对账流程，包括销售无法匹配时的处理方法。
服务提供商还会询问支持哪些面向商户的可见性设置，以及由谁配置这些设置。实际需要权衡的是：工作人员需要足够的信息来调查付款，同时访问权限应与商定的职责相符。请向 NeroPay 确认可用设置和权限，不要向咖啡馆承诺特定界面或访问级别。
- 使用一个有代表性的商户场景，逐步演练入驻流程和一笔销售。
- 检查获授权的审核人员能否按照商定的参考编号关联各项记录。
- 记录有关可见性或权限的问题，以便向 NeroPay 咨询。
- 列出上线前的各项决定、负责人和待解决事项。
重要信息
常见问题
参加首次 NeroPay 讨论时，我们应该准备什么？
准备一份简短说明，介绍您的 POS 平台、预期的商户账户关系、拟议的付款流程，以及有关环境、文档、访问权限和入驻流程的问题清单。确定能够做出技术和运营决策的人员。
我们能决定商户会看到什么吗？
合作伙伴可以配置受支持的面向商户的可见性设置。请向 NeroPay 询问哪些设置适用于您的使用场景，以及适用哪些权限，然后再设计或承诺特定的商户体验。
我们如何知道对账方案是否有效？
使用双方认可的示例，检查获授权的审核人员能否将一笔 POS 销售追溯到相应的付款记录，并识别任何未匹配或结果不明确的情况。根据已记录的集成行为，与 NeroPay 一起审查结果；此项检查不能取代持续进行的对账流程。
我们是否应假设事件会自动更新每条记录？
不应。与 NeroPay 一起审查已记录的事件及其含义，然后决定应用和团队将如何处理这些事件。另行规划核对记录和调查差异的流程。