29 KiB
29 KiB
聚合支付系统竞品分析
研究范围：中国市场，重点关注服务连锁餐饮、连锁零售及平台企业的聚合支付、统一支付接入、商户管理与交易运营能力。
研究时间：2026 年 6 月。
说明：竞品公开资料通常不会披露连锁企业客户数、支付交易份额和合同价格。本文区分“公开事实”与“基于公开产品定位的判断”，不以企业累计商户数直接推导聚合支付市场份额。
1. 结论摘要
聚合支付已不是一个依靠“聚合微信和支付宝”即可建立优势的市场。主流厂商已沿三条路线发展：
- 技术聚合路线：以统一 API、SDK 和开发者工具降低多渠道接入成本，代表为 Ping++。
- 持牌支付 PaaS 路线：将支付、商户进件、账户、分账、结算和对账组合输出，代表为汇付天下、银联商务和富友支付。
- 支付与门店经营一体化路线：以聚合收款为入口，叠加收银硬件、餐饮或零售 SaaS、会员营销与供应链，代表为收钱吧。
对于本公司的聚合支付系统，不建议正面复制持牌机构的收单网络，也不建议建设覆盖商品、会员、营销和供应链的通用门店 SaaS。更合理的竞争方向是：
面向已有 POS 和业务系统的中大型连锁企业，提供可控、可解释、可嵌入的支付接入与交易运营中台，并与自有对账、分账产品形成完整闭环。
应重点建立以下差异：
- 连锁集团、品牌、加盟商、门店、终端、商户号的多层级配置模型
- 可同时连接客户自有商户号、银行通道和持牌支付机构的通道中立能力
- 支付状态一致性、异常处置和可观测性
- 标准支付流水直接进入连锁业务对账系统
- 经对账确认后直接进入分账系统
- 面向企业现有 POS、ERP、小程序的低侵入集成，而不是强制替换前台系统
2. 市场范围与竞争格局
2.1 市场定义
本文所称聚合支付，是指不改变最终资金结算责任主体，通过技术系统统一连接多种支付渠道、收单机构和业务入口，并向企业提供支付受理、交易管理、商户配置、账务数据及相关运营服务。
本产品当前目标市场不是面向夫妻店提供一个收款码，而是面向以下客户提供企业级支付中台：
- 多品牌、多区域、多门店的连锁经营企业
- 同时管理直营网点与加盟门店的品牌总部
- 已经存在 POS、扫码点餐、小程序、商城等多个交易入口的企业
- 需要接入多个银行或持牌支付机构的企业
- 需要将支付流水继续用于对账、分账和经营核算的企业
2.2 市场规模与趋势
“聚合支付技术服务”缺少统一、持续的官方市场规模统计，不能与第三方支付交易规模直接画等号。可以用支付基础市场规模判断其业务承载空间：
- 中国人民银行数据显示，2025 年银行处理移动支付业务 2314.64 亿笔、571.97 万亿元；非银行支付机构处理网络支付业务 13254.45 亿笔、337.81 万亿元。来源
- 艾瑞咨询对更宽口径的“中国第三方综合支付”估算显示，2024 年交易规模约为 580.7 万亿元，其中企业支付约 205.3 万亿元。该口径包含的业务明显大于聚合支付技术服务，不可视为本产品 TAM。来源
市场已进入成熟期，主要变化不是消费者支付方式从无到有，而是：
- 支付机构和技术服务商从收款工具转向“支付 + 账户 + 分账 + 对账 + SaaS”
- 大型企业更关注支付系统稳定性、数据主权、多通道路由和资金合规
- 线下支付继续与 POS、会员、营销、外卖、供应链等门店系统融合
- 监管提高支付机构和收单外包服务机构的准入、备案、数据安全及风险管理要求
- 外卡、数字人民币、跨境支付和条码互联互通扩大支付方式复杂度
- 单纯聚合二维码高度同质化，竞争价值向行业场景、运营效率和数据闭环迁移
2.3 关键成功因素
企业级聚合支付的关键成功因素包括：
- 支付结果正确，重复请求、回调丢失和状态未知不会产生资金差错。
- 接口稳定、文档清晰、联调和上线周期短。
- 能管理复杂的组织、门店、终端、商户号和支付通道关系。
- 能提供交易查询、异常定位、退款控制、审计和监控。
- 具备合规的资金链路，不形成无牌“二清”。
- 能与企业已有 POS、ERP、财务、对账和分账系统集成。
- 服务商具备持续接入新渠道并处理渠道规则变化的能力。
3. 竞品集合
3.1 五家主要竞品
| 竞品 | 类型 | 市场位置 | 主要优势 | 对本产品的直接威胁 |
|---|---|---|---|---|
| Ping++ | 聚合支付 API / 金融科技 SaaS | 技术聚合代表 | API、SDK、开发者体验、渠道聚合 | 最接近“统一支付接入中台”的产品形态 |
| 汇付天下·斗拱 | 持牌支付 PaaS | 企业支付平台型强手 | 支付、进件、账户、分账、结算一体化 | 可向企业和软件服务商直接输出完整支付基础设施 |
| 银联商务 | 大型持牌收单与行业解决方案商 | 规模与渠道领导者 | 全国服务网络、支付方式、银行和银联生态 | 大客户资质、线下受理和资金服务能力强 |
| 收钱吧 | 收单外包服务与门店 SaaS | 线下商户服务领导者 | 硬件、服务网络、门店 SaaS、连锁餐饮方案 | 可用支付入口打包替换连锁客户的经营系统 |
| 富友支付·富掌柜 | 持牌支付与行业 SaaS | 综合型支付服务商 | 支付牌照、行业 SaaS、分账及担保等增值能力 | 可提供支付、经营和资金能力的一体化方案 |
3.2 相邻及间接竞争者
- 微信支付、支付宝开放平台：企业直接接入时可以绕过聚合服务商，但企业需要自己承担多渠道适配、统一状态和运营平台建设。
- 商业银行聚合收单：银行可依靠账户和客户关系提供较低费率及资金服务，但跨行、跨机构的通道中立性通常有限。
- 拉卡拉、通联支付、连连数字等持牌机构：具备支付、账户或行业方案能力，可能进入同一客户项目。
- 客如云、美团收银等餐饮 SaaS：以订单和收银为核心，将支付作为内置能力，可能直接控制交易入口。
- 客户自研支付中台：大型连锁企业可能选择自建，以换取数据控制、定制能力和通道议价权。
4. 竞品一：Ping++
4.1 基本信息与定位
- 运营主体为上海简米网络科技有限公司，成立于 2014 年。
- 官方定位已从单一支付 SDK 扩展为开放银行与科技金融服务商。
- 官方披露合作企业超过 4000 家、累计处理订单交易超过 100 亿笔，支持 300 多个主流互联网平台，系统建设能力支持 TPS 不低于 10000。来源
- 主要客户是需要在 App、网站、小程序或平台业务中快速接入支付的互联网企业和产业平台。
- 产品形态与本公司的“统一支付 API + 交易管理”最接近。
4.2 核心优势
- 一套 API 和 SDK 聚合多个支付渠道，开发者价值明确。
- 具备交易管理、可视化统计、多维报表、多用户权限、交易监控和渠道对账等能力。
- 公开开发者文档、SDK、帮助中心和系统状态页，降低技术采购的不确定性。
- 提供试用版、标准版、专业版和定制版，形成标准 SaaS 到项目定制的产品梯度。
- 已将聚合支付与合规分账、银行账户等产品组合，能够覆盖平台型企业的后续资金需求。
- 公开披露具有收单外包服务机构备案、等保三级、PCI DSS 和 ISO 等资质。
4.3 弱点与空白
以下为基于公开产品信息的判断，需要通过客户访谈或试用进一步验证：
- 产品历史和公开案例更偏线上互联网业务，对复杂连锁门店组织和终端管理的强调弱于其通用支付 API。
- 客户仍需自行申请相应支付渠道和权限，Ping++ 主要解决技术聚合，不天然解决所有商户进件和线下实施问题。
- 标准套餐存在应用数、并发数和接口调用量边界，大型连锁客户最终可能进入定制采购。
- 对支付后端的财务对账、门店差异闭环和连锁经营主体核算不是其公开差异重点。
4.4 商业模式与价格
- 采用软件服务订阅、版本套餐和定制服务模式。
- 官网当前展示版本差异但采用“咨询购买”，注册和试用门槛较低。来源
- 公开页面显示套餐按并发、接口调用次数、应用数、功能和服务等级区分。
- 支付渠道交易费仍由实际支付渠道或收单机构决定，不能将软件费与支付费率混为一体。
4.5 竞争威胁
- 已占据“快速统一接入多渠道支付”的清晰心智。
- 开发者生态、文档和标准 API 会提高客户切换成本。
- 支付与分账、账户产品组合后，可直接覆盖本公司的支付和分账产品边界。
- 如果其加强连锁门店模型、线下终端和行业模板，将成为最直接的产品竞争者。
5. 竞品二：汇付天下·斗拱
5.1 基本信息与定位
- 汇付天下成立于 2006 年，定位为企业收款和资金管理平台服务商。来源
- 曾于 2018 年在港交所上市，2021 年完成私有化退市。
- 斗拱定位为集全栈支付运营与软件开发于一体的综合 PaaS 平台。
- 目标客户包括企业商户、平台企业、SaaS 服务商和支付服务商。
5.2 核心优势
- 同时具备持牌支付能力和开放 PaaS 能力，不只提供技术转接。
- 支持线下场所、公众号、小程序、PC 网站、App 等多种经营场景。
- 产品覆盖支付、商户进件、统一账户、自动结算、多方分账、对账和银行连接等层级。来源
- 向服务商开放商户进件、收款、账户和资金能力，适合软件公司嵌入自己的行业产品。来源
- 组件化能力较强，客户可以基于 PaaS 组合业务，而不是只购买固定收银产品。
- 具备支付机构的合规、资金处理和风控基础设施。
5.3 弱点与空白
以下为基于产品模式的判断：
- 产品覆盖面广，接入涉及商户准入、签约、合规材料和资金方案，企业采购及联调复杂度可能高于纯技术 API。
- 作为持牌支付机构，其商业目标包含支付交易和资金服务，不是完全通道中立。
- 对只想保留既有商户号、银行关系和前台系统的客户，完整平台方案可能偏重。
- 连锁品牌的集团—品牌—加盟商—门店经营关系需要通过行业方案配置，不是公开产品的唯一核心模型。
5.4 商业模式与价格
- 主要收入可能由支付手续费、账户和资金服务费、增值产品费、PaaS 或定制项目费组成。
- 官方未公开统一企业报价，通常按行业、交易规模、支付产品和资金方案销售。
- 获客方式包括直销、行业解决方案中心、SaaS 合作伙伴和支付服务商生态。
5.5 竞争威胁
- 可以同时提供支付接入与资金闭环，减少客户采购多个供应商的必要性。
- 服务商生态允许 POS、ERP 或 SaaS 厂商直接嵌入斗拱，形成渠道规模。
- 其支付、分账和结算能力会同时威胁本公司的聚合支付与分账产品。
- 未来如果强化连锁行业数据和对账能力，可能形成从支付到经营资金管理的完整替代方案。
6. 竞品三：银联商务
6.1 基本信息与定位
- 银联商务成立于 2002 年 12 月，由中国银联控股，是首批获得人民银行支付业务许可的机构之一。
- 官方披露截至 2025 年 12 月累计服务商户超过 2800 万家、累计铺设终端超过 4400 万台。来源
- 业务覆盖线下、互联网和移动支付，并向餐饮、零售、文旅等行业提供综合解决方案。
- 在五家竞品中，支付受理网络、机构信用和大型项目资源最强。
6.2 核心优势
- 覆盖银行卡、二维码、云闪付、外卡、数字人民币等多种支付方式。
- 具备全国服务和终端部署网络，适合大规模线下门店实施。
- 天满开放平台提供支付 API 和商户交易能力，可与企业系统集成。来源
- “小 U 云店”等产品将综合支付与门店连锁管理、商品、营销和数据分析结合。来源
- 餐饮行业方案已覆盖支付、点餐、外卖、会员、进销存、统一对账、分账及供应链资金划付。来源
- 银联和银行生态、线下终端以及公共事业和大型商户项目经验构成较强壁垒。
6.3 弱点与空白
以下为基于大型收单机构模式的判断：
- 产品和组织体系庞大，标准化销售、属地机构与项目定制并存，客户体验可能受地区和方案团队影响。
- 对寻求多家收单机构灵活切换的企业，其通道中立性不如独立支付编排中台。
- 全套行业方案较重，可能与客户既有 POS、ERP、会员和供应链系统产生边界冲突。
- 中型连锁客户若只需要轻量 API、统一交易和异常运营，可能面临方案过重或沟通链路较长的问题。
6.4 商业模式与价格
- 主要采用支付收单手续费、终端和硬件、SaaS 服务、行业解决方案及项目服务等组合模式。
- 企业报价未公开，费率和项目价格通常取决于行业、卡种、支付方式、门店规模、设备和服务范围。
- 获客依靠银联与银行生态、全国分支服务体系、直销和行业合作伙伴。
6.5 竞争威胁
- 对注重机构资质、全国交付、外卡和银行卡受理的大型连锁客户具有明显优势。
- 可以通过银行或银联合作关系进入客户，采购信任成本较低。
- 其行业解决方案不仅替代支付中台，还可能替代 POS、门店 SaaS、对账和分账系统。
- 支付互联互通和外卡受理持续推进，会进一步放大其网络优势。
7. 竞品四：收钱吧
7.1 基本信息与定位
- 收钱吧成立于 2013 年，定位为数字化门店综合服务商。
- 官方披露其服务网络覆盖中国境内所有城市（含香港），为超过 1000 万实体商家提供服务，全国 50 多个城市设有分公司，服务团队超过 10000 人。来源
- 产品覆盖扫码支付、刷卡、分期、预授权、外卡、支付终端、餐饮和零售 SaaS、营销、外卖及连锁餐饮方案。
- 2024 年发布面向连锁品牌的“全来店”产品系列，2025 年披露已合作 300 多家连锁餐饮品牌。来源
7.2 核心优势
- 从聚合支付起步，线下商户认知强，收款设备和实施服务成熟。
- 软硬件产品丰富，覆盖码牌、音箱、扫码设备、智能 POS、收银机和云打印机。
- 能将支付与点单、会员、营销、外卖、发票、供应链等门店经营场景打包销售。
- 本地服务网络适合解决门店安装、培训、设备更换和售后问题。
- 对餐饮和零售商户形成“开箱即用”价值，决策链路通常短于企业自建支付中台。
- 企账通和全来店使其开始进入连锁账务和总部管控场景。
7.3 弱点与空白
以下为基于产品定位的判断：
- 核心优势是门店全套产品和线下服务，不一定适合希望保留自有 POS、支付商户号和技术架构的大型企业。
- 产品矩阵广，支付中台的开放性、通道编排深度和企业级可观测能力不是其公开传播重点。
- 面向单店和中小商户的标准产品与大型连锁的复杂组织、权限和系统集成需求存在差异。
- 使用其完整门店生态可能增加客户对硬件、收银系统和运营服务的供应商绑定。
7.4 商业模式与价格
- 聚合支付通常与交易服务、硬件、SaaS 年费和增值运营服务组合。
- 公开传播存在“0 元开通”和低门槛硬件策略；大型连锁产品按门店数和功能需求询价。
- 获客依靠直营团队、全国服务团队、合作伙伴、支付入口和门店 SaaS 交叉销售。
7.5 竞争威胁
- 可利用庞大线下商户基础和服务网络快速进入连锁品牌。
- 支付、硬件、收银和运营一体化降低客户一次性部署难度。
- 全来店向总部管控和供应链扩展后，会与公司餐饮数字化产品线产生更广泛竞争。
- 如果客户愿意整体替换收银和门店系统，本公司的“只做支付中台”价值可能不够突出。
8. 竞品五：富友支付·富掌柜
8.1 基本信息与定位
- 富友支付成立于 2011 年，是持牌第三方支付机构。
- 官方披露其具备互联网支付、银行卡收单、多用途预付卡、跨境支付等相关资质，并通过“富掌柜”提供收单和商户数字化服务。
- 官网披露有超过 60 万家企业合作。来源
- 主要覆盖中小微商户、大中型商户、连锁企业和细分行业 SaaS 场景。
8.2 核心优势
- 兼容主扫、被扫及多类支付方式，具备持牌支付和资金服务能力。
- 富掌柜提供支付聚合、语音播报、后台查账、电子发票、分期、卡券核销、结算和电子对账等能力。
- 行业 SaaS 覆盖餐饮、零售、美业、生鲜、茶饮和加油站等场景。
- 对连锁商户提供多层级经营数据、门店管理、会员、营销和进销存能力。
- 官网明确提供积分、营销、分账和担保等增值服务，可以向支付后链路延伸。
- 跨境和多用途预付卡等资质拓宽了复杂支付场景。
8.3 弱点与空白
以下为基于公开材料的判断：
- 产品传播偏支付服务和富掌柜行业方案，独立、通道中立的企业支付编排中台心智较弱。
- 部分公开产品说明和规模数据更新时间较早，企业选型时需要进一步核实当前功能、服务范围和案例。
- 采用其支付、结算和行业 SaaS 全套方案可能与客户既有系统及收单关系发生冲突。
- 对集团级支付异常运营、状态一致性和跨机构监控的公开说明不充分。
8.4 商业模式与价格
- 主要由支付手续费、商户服务、硬件、行业 SaaS、增值支付和资金服务构成。
- 官网未公开标准企业价格，预计按支付产品、交易规模、门店和行业方案定价。
- 通过金融机构合作、分支机构、渠道和行业协会拓展市场。
8.5 竞争威胁
- 持牌能力使其可以直接完成支付和结算，而本产品需要依赖合作机构。
- 支付、分账、担保、预付卡和跨境能力可以覆盖更复杂的企业资金场景。
- 富掌柜将支付与门店经营结合，对希望单一供应商交付的连锁客户有吸引力。
- 若其开放 API 和企业级商户模型增强，会与本产品形成正面竞争。
9. 横向能力对比
评分含义：5 为公开能力和市场证据很强，3 为具备基础能力或需项目化实现，1 为公开信息较弱。评分是基于公开资料的相对判断，不代表实际生产性能测试结果。
| 能力 | Ping++ | 汇付斗拱 | 银联商务 | 收钱吧 | 富友支付 | 本产品建议目标 |
|---|---|---|---|---|---|---|
| 统一支付 API / SDK | 5 | 5 | 4 | 3 | 3 | 5 |
| 持牌收单与资金处理 | 2 | 5 | 5 | 2 | 5 | 1 |
| 多支付方式覆盖 | 5 | 5 | 5 | 4 | 5 | 4 |
| 商户进件与结算 | 2 | 5 | 5 | 4 | 5 | 2 |
| 连锁组织与门店管理 | 3 | 3 | 4 | 5 | 4 | 5 |
| POS 与线下终端生态 | 2 | 4 | 5 | 5 | 5 | 3 |
| 开发者体验 | 5 | 5 | 4 | 3 | 3 | 5 |
| 支付状态一致性 | 4 | 5 | 5 | 4 | 4 | 5 |
| 异常处置与可观测性 | 4 | 4 | 4 | 3 | 3 | 5 |
| 财务对账闭环 | 3 | 4 | 5 | 4 | 4 | 5 |
| 多方分账与结算 | 4 | 5 | 5 | 4 | 5 | 5（通过分账系统） |
| 门店经营 SaaS | 1 | 3 | 5 | 5 | 5 | 1 |
| 通道中立性 | 5 | 2 | 2 | 2 | 2 | 5 |
| 私有化与深度定制 | 4 | 4 | 4 | 3 | 4 | 5 |
10. 可利用的市场空白
10.1 “已有系统不替换”的中大型连锁
多数综合竞品倾向销售支付、收银硬件和门店 SaaS 全套方案。已有成熟 POS、ERP、会员和小程序的连锁企业并不希望整体替换，只需要统一支付接口、商户号管理、异常运营和标准流水。
机会：
- 提供独立支付中台，不介入商品、点单和会员
- 支持渐进式接入，按品牌、区域或门店灰度迁移
- 兼容原有商户号和收单关系
10.2 多收单机构的通道中立管理
持牌机构通常优先使用自身支付和资金能力，银行方案也倾向本行渠道。大型连锁企业希望保留多家银行和支付机构，以获得成本议价、风险分散和业务连续性。
机会：
- 通道适配器标准
- 按门店、支付方式和收单机构配置路由
- 通道健康度监控和人工切换
- 独立比较成功率、耗时、错误码和成本
10.3 支付异常的可解释运营
市场大量产品可以“发起支付”，但总部运营人员更需要回答：
- 顾客是否实际扣款？
- POS 为什么没有收到成功结果？
- 哪个环节丢失了回调？
- 是否需要重新查单或关闭订单？
- 退款失败应由门店、总部还是渠道处理？
机会：
- 标准状态机和完整事件时间线
- 渠道错误码翻译与处理建议
- 自动查单、补偿和异常任务
- 门店、客服、运营和技术的分角色视图
10.4 支付—对账—分账的一体化但边界清晰
竞品常把支付、对账和分账包装在同一平台，但产品边界和数据可信链路未必清晰。本公司已有独立对账和分账产品规划，可形成：
支付生成标准流水 → 对账确认渠道实收 → 分账执行资金分配
机会：
- 支付系统不自行替代财务核销
- 对账系统形成可分账可信结果
- 分账系统只消费已确认数据
- 三个系统使用统一订单、流水、主体和状态标准
10.5 行业模板而非行业大套件
企业客户需要行业适配，但不一定需要重新购买完整行业 SaaS。
机会：
- 连锁餐饮的营业日、门店终端、加盟商和退款权限模板
- 连锁零售的多终端、交接班和大促高并发模板
- 连锁药店的医保与普通支付区分模板
- 平台业务的子商户、担保和分账衔接模板
11. 推荐竞争定位
11.1 定位陈述
面向已有业务系统的连锁经营企业，提供通道中立的聚合支付中台，统一管理集团到门店的支付配置、交易状态和异常处置，并无缝连接对账与分账系统。
11.2 需要强调的差异点
- 不是收款码工具：面向多品牌、多门店、多商户号的企业级支付治理。
- 不绑定单一收单机构：兼容客户现有银行、微信支付宝直连和持牌支付机构。
- 不强制替换 POS：通过标准 API、SDK 和适配器嵌入已有业务系统。
- 支付结果可解释：提供状态机、事件时间线、异常任务和自动补偿。
- 天然连接财务闭环：标准支付流水直接进入对账，对账结果直接进入分账。
- 支持客户可控部署：根据客户等级提供 SaaS、专属实例或私有化部署。
11.3 优先目标客户
- 50 家以上门店、已有 POS 或业务中台的连锁餐饮品牌
- 同时存在直营和加盟门店、商户号归属复杂的品牌
- 已经使用两家及以上收单机构或银行通道的企业
- 正在建设统一对账、分账或资金管理平台的客户
- 对支付数据、系统可控性和故障处置有明确要求的中大型客户
11.4 暂时避免的市场
- 只需要低费率收款码的单店和微型商户
- 强依赖全国硬件铺设、上门安装且软件价值较低的项目
- 要求本公司直接提供收单和资金结算但不接受合作持牌机构的客户
- 首期即要求覆盖完整 POS、会员、营销、外卖和供应链的客户
- 仅凭支付费率决定采购、没有软件服务付费意愿的客户
12. 未来 12—18 个月的竞争风险与应对
| 风险 | 可能性 | 影响 | 应对 |
|---|---|---|---|
| 持牌机构继续开放 PaaS，统一 API 成为基础能力 | 高 | 高 | 将优势放在连锁模型、异常运营和三系统闭环 |
| 收钱吧等门店 SaaS 向大型连锁总部管控扩展 | 高 | 中高 | 坚持兼容既有 POS，联合而非替换行业 SaaS |
| 银行以低费率打包聚合收单 | 高 | 中 | 提供跨银行管理、路由和数据中立价值 |
| 客户选择自研支付中台 | 中高 | 高 | 提供私有化、源码级扩展或联合建设模式 |
| 监管加强收单外包、数据和反洗钱要求 | 高 | 高 | 明确技术服务边界，完成备案与安全体系建设 |
| 支付互联互通降低“聚合渠道”价值 | 中 | 中 | 从支付方式聚合升级为企业支付运营和财务数据治理 |
| 竞品通过支付费率补贴软件 | 中高 | 中高 | 避免单独销售支付，绑定对账、分账和行业方案价值 |
13. 产品与市场行动建议
13.1 产品验证
- 选取 3 家已有 POS 且门店超过 50 家的连锁客户，验证是否愿意为独立支付中台付费。
- 盘点每家客户的商户号、收单机构和门店关系，检验多层级模型能否覆盖 80% 以上场景。
- 用真实异常案例验证交易时间线、主动查单和补偿任务的价值。
- 将同一批支付流水送入对账系统，验证支付—对账数据标准。
- 与一家银行和一家持牌支付机构完成技术及商务合作验证。
13.2 竞品实测
建议申请或演示以下产品，不只依赖官网资料：
- Ping++ 试用版：评估 API、状态模型、交易工作台和报表
- 汇付斗拱：评估服务商进件、统一账户、分账和接口复杂度
- 银联商务天满：评估线下支付接口、商户号和终端模型
- 收钱吧全来店：评估连锁总部管控、支付与 POS 绑定程度
- 富友富掌柜：评估连锁商户、电子对账及增值资金能力
13.3 销售话术验证
应测试客户是否认可以下价值主张：
- “保留现有 POS 和收单关系，只统一支付接入与运营”
- “总部统一管理门店、终端和商户号”
- “支付异常从跨多个后台排查，变为一条交易时间线”
- “支付流水不再二次加工，直接用于对账和分账”
- “新增支付通道时，业务系统无需重复改造”