From 38b47c6ca1018a56385e32efca70a6e7a6fb0d42 Mon Sep 17 00:00:00 2001 From: yeg <1347747024@qq.com> Date: 星期二, 15 九月 2026 13:12:53 +0800 Subject: [PATCH] 商户进件spec --- .scratch/merchant-wechat-onboarding/issues/01-onboarding-wechat-delay-closure.md | 42 ++++++++ .scratch/merchant-wechat-onboarding/spec.md | 221 ++++++++++++++++++++++++++++++++----------- CONTEXT.md | 4 docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md | 2 4 files changed, 210 insertions(+), 59 deletions(-) diff --git a/.scratch/merchant-wechat-onboarding/issues/01-onboarding-wechat-delay-closure.md b/.scratch/merchant-wechat-onboarding/issues/01-onboarding-wechat-delay-closure.md new file mode 100644 index 0000000..397e920 --- /dev/null +++ b/.scratch/merchant-wechat-onboarding/issues/01-onboarding-wechat-delay-closure.md @@ -0,0 +1,42 @@ +# 完成企业商户进件、微信支付与延迟入账开通闭环 + +Status: ready-for-agent +规格：[企业商户进件、微信支付与延迟入账开通闭环](../spec.md) + +## 目标 + +使企业商户在商户端一次提交后可完成汇付进件与人才端收款所需能力，并通过商户端和后台手动刷新，在没有回调的本地环境继续推进。微信配置失败仅重试失败步骤；延迟入账和 D1 自动结算必须取得有效的开通结果证据。 + +## 实施范围 + +- 商户端进件、分阶段进度、刷新与局部重试。 +- 进件应用服务、汇付开通与状态查询适配、必要阶段状态及幂等处理。 +- 管理后台对尚未整体通过申请的刷新、阶段结果与脱敏诊断展示。 +- 参考 6666000226048687 的微信场景及 0.70% 费率等公共规则，商户行业和资质按实际情况配置。 +- 恢复既有企业商户 6666000241335656，并使新增企业商户走完整流程。 + +## 实施顺序 + +1. 核实规格中列出的汇付接口、场景与状态语义，形成与控台参考配置对应的字段依据；只读核对指定存量商户现状。 +2. 复用现有应用服务和通道适配边界，实现分阶段结果收敛、显式刷新、未知结果查询与失败步骤重试。 +3. 对接商户端与后台进度和操作入口，落实权限边界。 +4. 按已确认测试边界验证无回调推进、幂等、部分失败、能力缺失及现有资金语义。 +5. 对指定存量商户制定并执行范围内恢复流程，记录通道证据、未完成的人工办理事项及真实验收结果。 + +## 验收 + +- 满足规格 Testing Decisions 中全部适用验收场景；以外部行为及业务结果判定，不仅验证内部方法。 +- 业务未真正生效或必要能力尚无证据时，不显示全部完成。 +- 复用原商户号和银行卡，仅补齐缺失能力；不处理其他已关闭小微商户。 +- 本次进件不增加定时查询或页面自动轮询；保留已有回调，不修改其他支付补偿任务。 +- 人才端是唯一付款端，商户端仅创建到店订单和核销。 +- 遵守单 checkout 单 Maven、只追加迁移、共享文件最小增量和开发库保护约定。 + +## 边界 + +规格为本 Issue 的权威需求。交易下单、登录、退款和核销实现的范围外问题只读排查并单独交接；不借恢复商户扩大业务范围。真实实名、授权及签约需由适当商户人员完成，不能通过本地改状态代替。 + +## Comments + +- 2026-09-15：按用户指定的 to-spec 技能从本会话合成并发布，应用 ready-for-agent 标签。用户已确认以进件服务为主要测试入口，使用真实测试库、模拟汇付响应，并补充接口权限与页面验收。 +- 2026-09-15：此次交付为规格和执行 Issue，尚未实施业务代码或恢复真实商户。未验证的通道字段、状态语义及存量实时情况已明确列为实施前核查任务。 diff --git a/.scratch/merchant-wechat-onboarding/spec.md b/.scratch/merchant-wechat-onboarding/spec.md index 3507beb..423374b 100644 --- a/.scratch/merchant-wechat-onboarding/spec.md +++ b/.scratch/merchant-wechat-onboarding/spec.md @@ -1,77 +1,182 @@ -# 企业商户进件与微信支付开通 +# 企业商户进件、微信支付与延迟入账开通闭环 -状态：设计质询中，尚未确认完整实施范围。2026-09-15。 +Status: ready-for-agent +更新日期：2026-09-15 +规格来源：本会话已确认的业务决策及只读代码、汇付文档和控台核查。 +测试边界：用户已确认以进件服务为主入口、真实测试库与模拟汇付响应，并补充接口权限和页面验收。 -## 已确认的需求 +## Problem Statement -- 第一阶段支持企业商户。 -- 商户在商户端一次提交资料与微信开通意图；基本进件通过后平台继续开通微信。 -- 支付发生在平台小程序中；用户提到人才端和用户端，仓库实际存在人才端和商户端两个小程序，两者业务称呼及支付职责待核对。 -- 微信配置以汇付商户 `6666000226048687` 为参考，由平台配置，不要求商户手填渠道技术参数。 -- 基本进件通过、微信开通失败时分别展示结果，允许仅重试失败步骤。 -- 商户端展示处理中、审核中、待实名、已开通及失败等细分进度；最终状态来源仍需根据汇付查询与回调文档核实。 -- 本地开发无法接收汇付回调，必须可通过平台主动查询推进；查询频率、入口及上线策略待定。 +企业商户希望在商户端一次提交资料后，完成汇付进件以及人才端收款所需的微信业务配置。当前基本进件、微信配置和业务开通的状态没有形成完整闭环：本地开发环境收不到回调，查看进度只读本地记录，申请会卡在处理中；配置失败后的重试又可能重新提交整份进件。 -## 控台只读核查：参考商户 +已有企业商户 6666000241335656 已进件，但微信能力未完成，需要保留原商户号恢复。后续新增企业商户应直接走完整流程。商户还必须开通延迟入账，使人才用户预购订单的资金在核销并完成交易确认之前不可结算到商户银行卡。 -核查日期：2026-09-15。来源：合作伙伴平台 → 商户信息 → 指定商户 → 一体化收款产品 → 基础支付 → 微信支付详情。 +付款始终发生在人才端。商户端扫描人才码创建到店消费订单、或扫描已购买订单进行核销，并不承担付款。实现不得将该需求误解为多个小程序的支付接入。 -| 项目 | 当前参考值 | +## Solution + +商户在商户端一次提交企业主体、经营和结算资料，平台同时保存微信业务开通意图。基本进件审核通过后，平台按汇付要求完成微信业务、人才端 AppID 配置、必要的实名/授权以及延迟入账和自动结算核验。商户端和后台显示各阶段的真实进度、失败原因与可执行的下一步。 + +微信业务公共配置参考商户 6666000226048687：保留线上公众号、小程序、反扫三个场景，费率 0.70%，最低收费 0 元，内扣、实收；行业、主体、证照、银行卡及实名信息按实际商户办理。实际支付 AppID 使用人才端配置。 + +本地收不到回调时，商户或运营点击“刷新进度”，由平台主动查询汇付，并继续已经满足前置条件的开通步骤。保留回调，不增加进件定时查询或页面自动轮询。配置失败仅重试失败步骤，不重建已通过的进件和银行卡关系。 + +开通延迟入账但不开启强制延迟。预购订单支付后进入延迟户，核销并完成交易确认后进入可结算资金，再按 D1 自动结算到银行卡；到店消费订单支付即核销，不走延迟。核销成功不等于银行卡实时到账。 + +## User Stories + +1. 作为新入驻企业商户，我希望在商户端完成企业进件，以便获得平台收款资格。 +2. 作为企业商户，我希望一次提交主体、经营、联系人和结算资料，以便不用为微信开通重复填写相同内容。 +3. 作为企业商户，我希望系统复用已上传的有效材料，以便减少重复提交。 +4. 作为企业商户，我希望按真实经营内容选择行业，以便微信行业类目和资质匹配。 +5. 作为企业商户，我希望行业所需资料不完整时得到明确提示，以便补充后继续申请。 +6. 作为企业商户，我希望费率、渠道和支付场景由平台按既定规则配置，以便不必理解汇付的技术参数。 +7. 作为企业商户，我希望看到适用的 0.70% 费率和最低收费 0 元，以便理解收款成本。 +8. 作为企业商户，我希望基本审核通过后继续微信开通，以便无需重新发起整套流程。 +9. 作为企业商户，我希望分别看到基本进件、微信业务、实名/授权和支付配置的进度，以便知道具体卡在哪里。 +10. 作为企业商户，我希望审核中与审核失败有不同提示，以便不会误把正常等待当成失败。 +11. 作为企业商户，我希望需要实名或授权时看到汇付提供的办理入口或指引，以便由适当人员完成操作。 +12. 作为企业商户，我希望实名/授权尚未完成时显示待办理，以便不会看到不准确的“已开通”。 +13. 作为企业商户，我希望点击“刷新进度”主动获取汇付结果，以便本地环境没有回调也能推进。 +14. 作为企业商户，我希望刷新发现前置步骤已经成功时继续后续开通，以便不必逐项操作技术接口。 +15. 作为企业商户，我希望看到最后同步时间和最新查询是否成功，以便分辨旧进度与新结果。 +16. 作为企业商户，我希望查询超时时保留原有成功状态，以便不会被错误提示为进件失败。 +17. 作为企业商户，我希望微信配置失败时保留已通过的基本进件，以便不重复申请汇付商户号。 +18. 作为企业商户，我希望只重试失败的开通步骤，以便继续使用现有商户号和银行卡。 +19. 作为企业商户，我希望已在处理中的申请先核实结果，以便重复点击不会产生多份申请。 +20. 作为企业商户，我希望重试失败仍显示最新原因与可行的下一步，以便知道何时补资料或联系运营。 +21. 作为企业商户，我希望只有必要能力真正生效后才显示开通完成，以便不会把受理成功误认为可以收款。 +22. 作为企业商户，我希望确认已开通延迟入账，以便预购订单在未核销时不会结算到银行卡。 +23. 作为企业商户，我希望沿用 D1 自动结算且没有起结和留存金额，以便核销后符合条件的资金按周期到账。 +24. 作为企业商户，我希望延迟入账与自动结算未就绪时看到具体缺项，以便及时补齐配置。 +25. 作为人才用户，我希望始终在人才端完成付款，以便商户端仅承担商户经营操作。 +26. 作为到店消费的人才用户，我希望商户扫码创建订单后由我在人才端付款，并在成功付款时完成核销，以便到店消费当场完成。 +27. 作为预购商品的人才用户，我希望在人才端购买付款后，到店由商户核销，以便付款和使用商品可以分开。 +28. 作为平台运营人员，我希望后台看到与商户端一致的分阶段进度，以便定位开通问题。 +29. 作为平台运营人员，我希望能够对尚未整体开通完成的商户刷新进度，以便恢复卡住的申请。 +30. 作为平台运营人员，我希望看到申请关联信息、通道错误码及同步时间，以便核对汇付处理结果。 +31. 作为平台运营人员，我希望刷新与回调使用一致的状态规则，以便不会因入口不同产生矛盾。 +32. 作为指定存量商户的运营人员，我希望恢复 6666000241335656 的缺失能力，以便不重新办理基本进件。 +33. 作为平台运营人员，我希望恢复前先核对该商户的真实配置，以便只补齐缺失项。 +34. 作为平台运营人员，我希望已关闭的小微商户不被本次恢复涉及，以便不会重新打开无关商户。 +35. 作为商户，我希望自己的进件和刷新操作仅访问自身有权限的申请，以便其他商户无法查看或推进我的资料。 +36. 作为平台运营人员，我希望重复通知、并发刷新和重复提交不会重复开通，以便进度和通道申请保持一致。 +37. 作为平台运营人员，我希望同步及恢复记录保留必要证据并保护敏感资料，以便排查时不会泄露证照、银行卡和密钥。 +38. 作为平台负责人，我希望无需运行进件定时查询，以便进度由现有回调和人工刷新控制，并接受无回调且无人刷新时保留最后已知状态。 + +## Implementation Decisions + +- **业务边界**：改动商户端进件与进度展示、商户进件应用服务、汇付进件/开通/查询适配，以及管理后台进度查询。必要的进件阶段能力判定属于本次闭环。登录、交易下单、退款、核销实现不扩展；范围外问题只读排查并交接。 +- **主体范围**：本阶段支持企业商户。保留无关既有主体代码，不扩展个人/小微进件，不以本次范围为理由批量停用其他历史记录。 +- **付款端**：付款仅在人才端完成，使用微信 AppID wxcfee477acb54d179。商户端承担创建到店消费订单与核销，无需增加双 AppID 登录或下单。参考商户已有的商户端 AppID 绑定不要求新商户复制，也不修改参考商户。 +- **配置模板**：参考商户 6666000226048687，标准费率线上、默认通道、公众号/小程序/反扫三场景，0.70% 费率、最低收费 0 元，非仅借记卡，手续费内扣且实收，不开微信预授权。控台微信渠道号为 00016904，实际接口字段和渠道映射必须由官方文档核实，不能将控台展示值直接猜作 API 参数。 +- **商户独有资料**：行业按真实经营类型映射，不能统一复制参考商户“平台服务”类目；商户名称、主体资质、银行卡、微信子商户号、实名结果等不能作为共享模板。渠道参数由平台控制，商户选择实际行业并按需提供材料。 +- **资金规则**：开通时设置 delay_flag=Y、forced_delay_flag=N。自动结算为 D1 批次结算，起结金额和留存金额均为 0。开通能力与每笔交易是否延迟分别判断；既有到店消费不延迟、其他订单延迟的业务保持一致。 +- **一次提交、分阶段办理**：保存一次进件意图及资料，按通道真实前置条件执行基本审核、业务开通、微信配置、实名/授权和能力核验。具体业务开通与 AppID 配置的调用先后以官方要求为准，不能凭现有调用顺序认定正确。 +- **状态分离**：至少区分基础审核、微信业务、人才端 AppID 配置、实名/授权、延迟入账、自动结算。商户端使用可理解的阶段摘要，后台同时显示必要通道诊断信息。未知、等待、失败和已生效不得合并成同一种状态。 +- **完成判定**：获得汇付商户号或提交受理成功不足以判定开通完成。必须有通道有效证据证明商户基础状态、所需微信能力、人才端绑定、适用实名/授权要求、延迟入账及自动结算满足条件。缺少证据时显示未确认并给出原因。 +- **查询入口**：普通状态读取保持只读，新增或扩展显式“刷新进度”写操作，商户端与管理后台调用同一进度同步逻辑。刷新可能继续办理后续开通，界面提示这个效果。后台入口不再要求申请已经整体通过。 +- **刷新语义**：先查询当前未决步骤及必要能力，更新已知结果，再在前置成功且不存在未决重复申请时继续开通。单次刷新有界返回，不循环等待人工审核完成；必要时提示稍后再次刷新。 +- **同步时机**：仅通过手动刷新和已有回调推进本次进件；不新增进件定时查询、页面自动轮询，也不把推进逻辑接入已有能力定时刷新。其他既有交易补偿任务属于范围外。 +- **超时与未知结果**：通道请求超时或返回无法解析时保留最后有效状态及原关联信息；后续先查询，不因未知结果重新进件。明确失败才提供相应失败步骤的重试，等待实名则提供办理指引。 +- **局部重试**：基本审核已通过时，保留汇付商户号、现有申请关联和银行卡关系，仅重试失败配置。废止在该场景将整份申请及银行卡关闭后重新进件的行为；不影响真正基础审核失败的独立规则。 +- **回调与并发**：手动刷新和已验签回调汇入同一状态处理规则。重复/乱序通知不得让已确认成功的同一次尝试回退；新的有效配置变化应按对应尝试与查询证据解释，不能简单永久忽略所有后续结果。重复点击和并发入口不得重复创建通道申请。 +- **持久化**：优先扩展已有申请和步骤字段，保存必要状态、原请求日期和流水号、通道申请单号、尝试关联、结果码、最后同步时间及脱敏证据。具体新增列在实现前检查现有结构后决定；如需迁移，使用最新共享版本号追加，禁止修改已执行迁移。 +- **返回契约**：两端返回一致的分阶段进度、最后成功同步时间、当前同步错误、可执行操作与失败原因；保留已有消费者所需的兼容信息。最终端点名与字段命名由实现时沿用仓库风格确定。 +- **权限与信息展示**：商户入口按登录商户和门店权限定位申请，不信任前端传入的任意汇付商户号；后台沿用既有运营权限。对商户展示可处理的业务提示，对运营提供必要的脱敏诊断信息。 +- **实名/签约**：需要商户本人完成的实名、授权或签署通过通道提供的指引办理，不能将本地状态改写为通道已授权。接口能否发起实名及所需材料属于实施前核查事项。 +- **存量恢复**：仅恢复 6666000241335656。先只读核对本地关联、汇付审核和实际配置，再复用原商户号补齐缺失能力。保留已成功步骤与银行卡，不批量修复或重新打开其他小微商户。 +- **共享文件**：只在授权业务区域做必要增量改动，不顺手重构共享服务、路由或公共配置。 + +## Testing Decisions + +### 测试边界 + +推荐以现有商户进件应用服务的公开提交、查询、刷新、重试和回调入口为主要测试边界，使用真实 MySQL 测试库，仅在汇付外部网关处控制响应。商户端和后台复用同一进度逻辑，避免为每个内部辅助方法分别建立测试替身。 + +复用现有边界优于新建测试专用接口。如果现有边界无法模拟必要通道结果，优先在汇付调用的统一边界引入最小替换点，不把状态机的内部细节暴露给测试。补充少量 HTTP 权限/契约测试、汇付报文契约测试和页面验收即可。 + +用户已确认上述测试边界：“符合，按此测试边界”。 + +### 好测试的标准 + +- 从给定商户状态和通道结果出发，经公开操作断言两端可见进度、可执行操作和持久化业务结果。 +- 验证不重复申请、不丢失既有商户和银行卡、未确认能力不得误报完成等业务不变量。 +- 对外部请求可验证关键合同字段、请求关联和必要调用次数，因为它们决定是否重复办理；不锁死内部方法顺序、私有字段或实现分支。 +- 使用按商户 ID/申请号隔离的数据，不依赖共享测试库全表数量或其他测试的执行顺序。 +- 常规自动化测试模拟汇付，不对真实商户提交开通、授权或支付请求。指定存量商户的真实结果作为另外记录的验收证据。 + +### 测试模块与先例 + +- 商户进件应用服务：沿用 MerchantSettlementCallbackIdempotencyTests 的 Spring 集成测试方式，扩展手动刷新、通道异步结果和乱序/重复处理。 +- 局部重试：参考 MerchantOnboardingRetryTests 和 MerchantOnboardingRetryReleaseTests 的既有故障场景；其中“关闭申请和银行卡再提交”的期望与新需求冲突，应在适用场景替换为保留原身份并只重试失败步骤。 +- 汇付适配：参考 HuifuBusinessOpenRequiredFieldsTests 的外部字段合同思路，验证参考费率/场景、实际行业、人才端 AppID、延迟入账和结算规则；不再通过重复实现报文构造逻辑证明自身正确。 +- 支付及交易确认：运行 PaymentSettlementTests、PaymentFundConfirmationTests 等相关既有测试作回归，确认两种资金规则；不借回归扩大交易/核销实现范围。 +- 商户端与后台：验证进度、刷新、重试、待实名指引、权限隔离及结果一致性，页面不能把查询错误显示为审核拒绝。 + +### 必须覆盖的验收场景 + +| 场景 | 应观察到的结果 | | --- | --- | -| 商户类型 | 企业商户 | -| 微信渠道号 | 00016904 | -| 微信行业类目 | 线上-企业-756-提供网上交易场所或信息服务的业务、通讯业务、财经类业务及其他平台服务 | -| 业务开通类型 | 标准费率线上 | -| 默认通道 | 是 | -| 开通场景 | 微信线上公众号支付、微信线上小程序支付、微信线上反扫支付 | -| 各场景费率 | 0.70%，最低收取 0.00 元 | -| 仅借记卡 | 否 | -| 手续费 | 内扣、实收 | -| 微信预授权 | 未开通 | -| 实名授权 | 审核通过、已授权 | -| 使用上级商户号发起 AT 交易 | 否 | -| 绑定小程序 | wxcfee477acb54d179；wx550e520ad19458ea | +| 企业首次提交 | 保存一次申请意图；未确认基础审核通过前不越过前置条件 | +| 没有回调，手动查到基础审核通过 | 保留原商户号，更新阶段并继续后续配置 | +| 没有回调，查询业务已开通 | 同步真实能力，继续尚缺的必要步骤 | +| 审核仍在处理 | 保持等待，单次刷新有界返回，不创建重复申请 | +| 微信待实名或待授权 | 显示待办理及有效指引，不显示全部完成 | +| 微信配置或业务开通明确失败 | 基础进件继续保持成功，只允许重试失败步骤 | +| 请求超时且结果未知 | 保留原关联与已成功阶段，下次先查，不盲目补发 | +| 重复点击、两端并发刷新 | 不重复创建基本进件、银行卡或同一步骤申请 | +| 刷新与重复/乱序回调同时到达 | 同一次尝试的成功结果不被旧失败覆盖 | +| 微信成功但人才端绑定未确认 | 明确提示绑定未完成，不能显示全部完成 | +| 微信成功但延迟入账或自动结算未确认 | 显示缺项，不凭请求参数推断开通完成 | +| 通道已经开启全部必要能力 | 两端显示一致的已完成结果与同步时间 | +| 资料或行业不匹配 | 给出具体补充/纠正项，不照搬平台服务类目 | +| 存量指定商户恢复 | 原汇付商户号、已成功步骤和银行卡保持关联 | +| 其他已关闭小微商户 | 不被本次恢复扫描、补开或更改状态 | +| 商户尝试访问其他商户申请 | 请求被权限边界拒绝，不能泄露或推进他人资料 | +| 到店消费和预购订单相关回归 | 前者支付即核销且不延迟；后者核销和确认前资金保持延迟 | +| 无回调且无人刷新 | 本次进件不会被新增定时器或页面轮询主动推进 | -控台微信配置提示：公众号、小程序、反扫 AppID 累计最多配置 5 个。界面可同时填入多个小程序 AppID，但 API 的格式与绑定结果查询方式仍需查证。未修改控台任何配置。 +后端遵守仓库统一测试脚本和共享 MySQL 测试库约定，同一 checkout 一次仅运行一个 Maven 构建；不重置开发库，不删除数据库，不为已记录基线失败重复建立验证工作区。前端按实际可用编译/运行工具完成检查，并明确报告无法执行的验收项。 -参考商户的子商户号、实名结果、企业证照和银行卡属于该商户，不能作为新商户的共享配置。行业类目适用性、附带公众号/反扫能力是否保留，待用户决策；控台渠道号与 API pay_channel_id 的映射也需核实。 +## Out of Scope -## 文档事实 +- 个人/小微商户的新功能，以及已关闭小微商户的恢复、批量重新进件。 +- 指定存量商户以外的历史数据批量修复。 +- 商户端付款、多 AppID 微信登录和多支付端改造。 +- 微信直连、微信预授权、支付宝或其他新增支付产品。 +- 对参考商户本身做配置修改，或复制其企业身份、银行卡、子商户号和实名结果。 +- 新增进件定时查询、页面自动轮询，以及停用/重构其他既有资金确认和对账任务。 +- 新建通用配置中心、复杂模板版本管理或运营费率编辑系统；本次只提供完成需求所需的公共配置。 +- 重构交易下单、核销、退款、分账或主动提现系统。相关范围外缺陷只读记录后交接。 +- 在此次规格生成过程中提交真实进件、支付、签署协议或直接修改生产商户配置。 -来源：[汇付商户业务开通](https://paas.huifu.com/docs/api/doc/#/shgl/shywkt/api_shjj_shywkt_kyc)，页面更新日期 2026-09-10。 +## Further Notes -- `/v2/merchant/busi/open` 面向已完成进件的商户，支持多项业务开通及补开；渠道自身需具有相应权限。 -- `wx_conf_list` 配置微信业务；审核结果与业务开通结果分别通过 `async_return_url` 和 `busi_async_return_url` 通知。 -- 申请审核通过和微信业务开通是不同结果，不能仅凭提交成功或汇付商户号判定可收款。 -- 申请单查询、业务开通结果查询、微信实名查询及多 AppID 配置的准确字段与结果语义，列入后续核查。 +### 证据与约束 -## 现有实现与需求缺口 +- 官方来源：[汇付商户业务开通](https://paas.huifu.com/docs/api/doc/#/shgl/shywkt/api_shjj_shywkt_kyc)，前次读取页面更新时间为 2026-09-10；支持已进件商户多业务开通及补开，申请审核与业务结果分开通知，渠道必须具备相应权限。 +- 参考配置在 2026-09-15 经合作伙伴控台只读核实。参考商户行业为线上平台服务类、已完成实名授权、未开预授权、不使用上级商户号发起 AT 交易；独有资质与已授权结果不适用于其他商户。 +- 当前代码已设置延迟入账 Y、强制延迟 N，以及 D1 自动结算；缺的是实际生效结果核验和后续开通闭环。 +- 当前默认微信费率为 0.60%，与参考值 0.70% 不一致；通道与使用上级商户号的配置也应与参考核实，不能以代码默认值代替需求。 +- 当前本地状态读取不会向汇付同步；后台能力刷新限于整体通过申请，不能救活卡在进件阶段的记录；旧重试会重新提交整份进件。 +- 已有商户能力定时刷新和交易确认补偿任务，与本次“手动推进进件”的需求分开；不得将进件推进挂入这些任务。 +- 本次只读核查尚未查询 6666000241335656 的实际数据库及汇付最新状态，不能将用户报告的卡住现象直接归因于某一通道错误。 +- 领域术语沿用根领域文档；执行已有“商户进件与微信支付开通分别判定”ADR。 -- `MerchantSettlementService.onboardingStatus` 只查询本地最新记录；商户状态页不向汇付同步结果。 -- 微信配置和业务开通已有步骤状态，但完整推进主要依赖同步结果与回调，未发现待审核/开通中申请的主动查询补偿。 -- 后台 payment-capability refresh 仅允许已通过申请，查询商户、结算等能力；不能恢复卡在待审核或微信业务开通中的申请。 -- 现有 retryable 后重提会关闭旧申请并发起全套进件，与单步重试要求不符。 -- 商户端类型未暴露微信配置、业务开通的步骤状态，无法显示已确认的细分进度。 -- 微信绑定与支付下单使用单个全局 AppID。参考商户绑定的第一个 AppID 对应 `rencaika/manifest.json` 的 mp-weixin 配置，第二个对应 `rencaika_merchant/manifest.json`。 +### 技术核查任务 -相关源码： +这些是实现代理可自行查明的接口事实，不是待用户重新决定的业务需求： -- `talent-card-server/src/main/java/com/talentcard/server/business/merchant/MerchantSettlementService.java` -- `talent-card-server/src/main/java/com/talentcard/server/business/payment/huifu/HuifuMerchantBusinessOpenGateway.java` -- `talent-card-server/src/main/java/com/talentcard/server/business/payment/huifu/HuifuMerchantWechatConfigGateway.java` -- `talent-card-server/src/main/java/com/talentcard/server/business/payment/huifu/HuifuMerchantCapabilityGateway.java` -- `talent-card-server/src/main/java/com/talentcard/server/business/payment/huifu/HuifuMiniProgramPaymentGateway.java` -- `rencaika_merchant/services/settlement.uts` -- `rencaika_merchant/pages/merchant-onboarding-pending/merchant-onboarding-pending.uvue` +1. 核实申请单审核、微信业务开通、实名/授权、AppID 绑定和延迟/结算能力的官方查询接口、参数及成功语义。 +2. 本地 SDK 已包含申请单状态查询、商户详细信息查询、微信实名查询及微信配置查询请求类型；SDK 类型存在不证明接口能返回全部验收字段。 +3. 不要将 SDK 中只含门店标识、用于统一进件页面查询的业务状态查询误作本次微信业务审核查询。 +4. 核实三个场景、0.70% 费率、最低收费 0、内扣实收和参考渠道的准确报文；核实实际行业材料及实名所需流程。 +5. 若查不到必要能力的生效证据，应明确未确认及原因，不填造成功结果；记录通道限制并在必要时提出有证据的业务取舍。 +6. 核实指定存量商户原申请、流水号和已开能力，形成可核对的补开动作清单后恢复。 -## 当前决策树前沿 +### 交付完成条件 -- 小程序职责：实际付款是否仅发生于人才端；若两个端都付款，需进一步决定多 AppID 登录/下单的业务范围。 -- 模板边界：平台服务行业类目与各实际入驻商户行业的映射；是否严格保留参考商户附带的公众号/反扫开通项。 -- 状态同步：商户刷新触发查询、后台手动查询、定时查询分别如何参与推进。 -- 存量处理：是否补齐已经进件或处于处理中商户的微信能力。 -- 实施边界：商户端、进件后端、汇付支付适配及管理后台的范围；交易下单、退款、核销若发现问题应只读记录并交接，除非用户另行指定。 +商户端与后台可完成受权限约束的刷新及局部重试；无回调场景能按人工操作推进到真实已完成或明确待办理状态；指定存量商户复用原身份恢复缺项，新企业商户可走同一闭环；必要能力以通道证据确认，测试与无法验证的外部条件均有记录。 -## 关联决定 - -[商户进件与微信支付开通分别判定](../../docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md) +Status 表示规格已按技能发布并可由代理执行技术核查与实现，不表示功能已经实现或真实商户已经恢复。 diff --git a/CONTEXT.md b/CONTEXT.md index 8ca16ad..a154c29 100644 --- a/CONTEXT.md +++ b/CONTEXT.md @@ -30,6 +30,10 @@ ## 进件与微信支付 +**人才端**：人才用户购买商品并完成微信付款的小程序，也是商户发起到店消费订单后的付款端。 + +**商户端**：商户办理进件、扫描人才码创建到店消费订单，以及扫描预购订单核销码完成核销的小程序；付款由人才用户在人才端完成。 + **商户进件**：企业商户提交主体、经营和结算资料，申请成为汇付商户的过程。基本资料审核通过后，微信支付仍可能处于开通中或开通失败。 **微信支付开通**：商户取得在平台小程序内接受微信付款所需业务能力的过程。开通失败可以单独重试，不否定已经通过的基本资料审核。 diff --git a/docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md b/docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md index 3f10002..a1b5542 100644 --- a/docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md +++ b/docs/adr/0001-merchant-onboarding-and-wechat-provisioning.md @@ -2,4 +2,4 @@ 商户端一次提交进件资料与微信支付开通意图，平台在基本进件审核通过后继续开通微信支付。两阶段分别记录结果；基本进件成功而微信开通失败时，保留已通过的商户身份，仅重试失败的开通步骤，避免因支付配置失败重复进件。商户端展示审核、待实名、开通中及失败等阶段，不能用一个整体失败状态抹掉已完成的进件结果。 -本地开发环境无法接收汇付回调，流程需要通过主动查询取得审核及业务结果后继续推进；查询触发方式和上线后的调度策略仍待确认。 +本地开发环境无法接收汇付回调，由商户端“刷新进度”和管理后台刷新主动查询审核及业务结果，并继续已满足前置条件的开通步骤。保留回调处理，不增加定时查询；没有回调且无人刷新时，进度会保持最后已知状态。这一取舍由用户明确选择，不能将它擅自改为后台自动轮询。 -- Gitblit v1.7.1