# 交付包 · 合规与资质清单

> 项目：**要店帮 · 红包商城**（芋道商城多租户底座 + 店员积分返现 / 晒单核销 / 红包提现）
> 版本：V1.0（对应交付批次 20261104）
> 读者：**法务 / 合规 / 商务**（不需要技术背景）
> 关联文档：《腾讯云商用上线准备方案.md》（资质办理总表与成本估算的主文档）、《交付包-部署与运维手册.md》（技术侧密钥与数据留存）、《交付包-运营SOP.md》（业务侧执行动作）

---

## 0. 本文档怎么用

| 你的角色 | 只需要看 |
|---|---|
| **法务** | 第 1 章（主体与责任划分）、第 6 章（合同要点） |
| **合规** | 第 3 章（小程序类目）、第 4 章（隐私与数据）、第 5 章（资金与合规） |
| **商务** | 第 2 章（资质清单）、第 5 章（资金与合规）、第 7 章（检查清单） |
| **项目负责人** | 第 7 章检查清单 + 《腾讯云商用上线准备方案.md》第 3 章 |

> 📌 **本项目已采用的模式是「混合模式」**：平台提供系统与技术能力并作为小程序/备案等对外主体，但**每客户配备独立的微信支付商户号**，客户的资金由客户的商户号收付。这一模式的责任划分见第 1 章，这是全文最重要的前提。
>
> 📌 本文档中标注「**需业务方确认**」的，是必须由业务方拍板、不能由技术侧推断的事项。标注「**以实际为准**」的是时效、费用、比例等会变动的数值。清单的完整办理台账与成本估算见《腾讯云商用上线准备方案.md》第 3 章与第 1.3 节，本文不重复造。

---

## 1. 主体与责任划分

### 1.1 三种可选模式

| 模式 | 小程序/备案主体 | 微信支付商户号 | 资金收付方 | 优点 | 缺点 |
|---|---|---|---|---|---|
| **A. 完全平台模式** | 平台 | 平台统一 | 平台代收代付 | 客户接入快 | 平台承担资金归集与二清风险；客户对账复杂 |
| **B. 完全客户模式** | 客户 | 客户 | 客户 | 责任最清晰 | 客户接入慢，需逐个注册小程序与备案 |
| **C. 混合模式（本项目采用）** | **平台** | **每客户一套** | **客户的商户号** | 兼顾接入效率与资金隔离 | 需明确"平台主体 vs 客户资金"的界面 |

### 1.2 本项目的实际形态（C 模式）

```
        ┌─────────────────────────────────────────────┐
        │  平台主体（要店帮运营方）                       │
        │  · 小程序主体 / 公众号主体 / ICP 备案主体       │
        │  · 域名、服务器、系统的产权与运营责任           │
        │  · 平台统一的技术、客服、投诉兜底               │
        └─────────────────────────────────────────────┘
                              │ 提供 SaaS 系统能力
                              ▼
        ┌─────────────────────────────────────────────┐
        │  客户主体（商家，如连锁药房）                   │
        │  · 独立微信支付商户号（每客户一套）              │
        │  · 独立域名（system_tenant.websites 绑定）     │
        │  · 费用池充值、店员奖励发放、线下打款           │
        │  · 资质持有人：药品/医疗器械经营许可等           │
        └─────────────────────────────────────────────┘
```

### 1.3 责任划分表

| 事项 | 平台责任 | 客户责任 | 边界说明 |
|---|---|---|---|
| 系统可用性、运维、数据备份 | **主责** | 配合提供环境与账号 | SLA 与赔付条款见服务协议 |
| 多租户数据隔离 | **主责** | — | 框架强制；`tenant-id` 不一致直接 403 |
| 敏感凭据加密存储 | **主责** | 提供凭据 | 微信商户号凭据整段 AES 加密落库，响应中不返回明文 |
| 门店/店员/任务的业务真实性 | 提供工具与风控 | **主责** | 平台的风控只是辅助筛查，不构成对真实性的担保 |
| 店员奖励规则制定 | 提供配置能力 | **主责** | 单件积分、奖励金额、日上限均由客户设定 |
| 店员奖励资金 | 提供费用池记账能力 | **主责**（充值 + 打款） | 平台不经手客户资金 |
| 打款执行 | 提供台账与状态机 | **主责**（线下转账 + 回填凭证） | 本版为人工打款 |
| 对账 | 提供对账视图 | **主责**（逐笔核对并标记） | 平台提供 `v_clerk_withdraw_reconcile` |
| 资质与类目 | 提示清单 | **主责**（提供与持有） | 资质一律由客户主体持有 |
| 小票等 UGC 内容安全 | 提供审核工具与规则 | **主责**（人工复核与处置） | 平台侧内容安全 API 为技术手段，不替代客户责任 |
| 个人信息处理 | 按数据处理协议作为受托方 | **主责**（决定处理目的与方式） | 见第 4 章 |
| 用户投诉与纠纷 | 平台级兜底与升级通道 | 一线处理与首问负责 | 争议裁决按合同 |
| 发票开具 | 按合同向客户开票 | — | 客户向其消费者开票 |

### 1.4 必须写进合同的三条边界（法务重点）

1. **客户资质责任不可转移**。客户上传的门店清单、任务指定品种、经营范围，均以客户提交的资质为依据。平台仅做技术校验，不对经营资质真实性作担保。
2. **资金责任边界**。费用池余额、店员应得金额、线下打款结果均由客户负责；平台仅提供记账、台账与对账视图。平台不对店员奖励的兑付承担兜底责任。
3. **数据角色约定**。客户为个人信息处理者（决定处理目的与方式），平台为受托处理方（仅按客户指令处理）。详见第 4 章与数据处理协议。

> ⚠️ 上述边界若不在合同中明确，最常见的纠纷是：店员在客户门店工作但未获发奖励，店员向平台投诉，而实际应向客户主张。**必须在合同中约定：店员与商家的奖励关系由商家直接建立，平台非该关系的合同相对方。**

---

## 2. 必需资质清单

> **完整办理台账、进度跟踪表与代办/自办分工见《腾讯云商用上线准备方案.md》第 3 章（3.1 办理总表 / 3.2 逐项办理明细 / 3.3 进度跟踪表）。**
> 下表为按责任主体归集后的速查版本，"阻塞上线"列与方案文档保持一致。

### 2.1 客户主体资质（客户办理，平台不代办）

| # | 资质/事项 | 主体 | 办理渠道 | 阻塞上线 | 时效（以实际为准） | 备注 |
|---|---|---|---|---|---|---|
| B1 | 营业执照 | 客户 | 工商登记 | **是** | 已有 | 经营范围须覆盖药品/医疗器械销售 |
| B2 | 药品经营许可证 | 客户 | 药监部门 | **是**（涉药时） | 依审批 | 类目申请必需，见第 3 章 |
| B3 | 第二类医疗器械经营备案凭证 | 客户 | 药监部门 | **是**（涉械时） | 依审批 | 与经营范围对应 |
| B4 | 食品经营/仅销售预包装食品备案 | 客户 | 市场监管 | 视类目 | 依审批 | 涉及非药品类时 |
| B5 | 法人身份证 / 经办人身份证 | 客户 | — | 是 | 已有 | 小程序管理员认证 |
| B6 | 对公账户信息 | 客户 | 银行 | **是** | 已有 | 微信支付商户号申请必需 |
| B7 | 门店清单 + 各店许可证编号 | 客户 | 内部整理 | **是** | 内部 | 用于白名单门店导入 |
| B8 | 推广/促销方案与奖励规则说明 | 客户 | 内部 | 建议 | 内部 | 备案与争议举证用 |
| B9 | 微信支付商户号（每客户一套） | 客户 | 微信支付商户平台 | **是**（收款时） | 依平台 | 平台代为配置落地，详见 2.3 |
| B10 | 平台服务协议 + 数据处理协议 | 双方 | 签署 | **是** | 以实际为准 | 见第 6 章 |

### 2.2 平台主体资质与账号（平台办理为主，客户配合）

| # | 资质/事项 | 主体 | 办理渠道 | 阻塞上线 | 时效（以实际为准） | 备注 |
|---|---|---|---|---|---|---|
| A1 | 域名注册 + 实名 | 平台 | DNSPod 等 | **是** | 1–2 工作日 | 主体名称须与营业执照完全一致 |
| A2 | ICP 备案 | 平台 | 工信部备案系统 | **是（最长前置）** | 通常数周 | 备案/小程序/支付三者主体须一致 |
| A3 | 小程序注册与认证 | 平台 | 微信公众平台 | **是** | 依平台 | 企业主体认证费见方案文档附录 B（E1） |
| A4 | 腾讯云账号 + CVM + TCR | 平台 | 腾讯云 | 是 | 依采购 | 资源清单见方案第 4 章 |
| A5 | 短信签名与模板 | 平台 | 腾讯云短信 | 否 | 以实际为准 | 客户需提供签名来源证明 |
| A6 | OCR 服务 | 平台 | 腾讯云 OCR | 否 | — | 未开通时自动降级人工审核，不阻断业务 |
| A7 | 内容安全能力接入 | 平台 | 微信内容安全 API | **是** | — | 见第 4.4 节 |
| A8 | 《用户隐私保护指引》 | 平台起草 | 微信公众平台 | **是** | 内部 | 客户审阅确认，见第 4 章 |
| A9 | 微信服务器域名配置 | 平台 | 微信公众平台 | **是** | 依平台 | 必须已备案 + HTTPS + 443 |
| A10 | 小程序服务类目与对应资质 | 平台申报 | 微信公众平台 | **是** | 依平台 | **类目选错是驳回高频原因** |

### 2.3 每客户独立商户号：本项目的落地方式

| 项 | 说明 |
|---|---|
| 数量 | 每客户一套微信支付商户号（`pay_app` / `pay_channel` 原生带 `tenant_id`） |
| 谁申请 | 客户主体向微信支付商户平台申请 |
| 谁配置 | 客户在后台「支付管理 → 商户号配置」录入，平台提供字段说明与校验 |
| 密钥保护 | `pay_channel.config` 整段 AES 加密落库（密文前缀 `ENC1:`，兼容历史明文）；查询接口只返回 `hasApiV3Key` / `hasPrivateKey` 等布尔位，**明文不出现在任何响应中** |
| 回调地址 | 客户独立域名下的 `/pay/notify/`，**必须与商户平台配置完全一致且为 https** |
| 结算 | 资金直接进入客户自己的商户号账户，**平台不经手客户资金** |
| 费率 | 登记在 `feeRate` 字段，费率以实际为准 |

**这套设计对合规的意义**：客户的收款资金从始至终在客户自己的商户号里，平台只提供系统能力，**在资金链路上不形成代收代付**。这一点应在合同与备案材料中明确表述，是本项目最重要的合规减险点。

> ⚠️ 同时要确认：**小程序的支付分账/服务商模式选择**。若采用"服务商模式"，平台作为服务商可能承担更重的合规义务；若采用普通直连商户模式，则需确认小程序主体与商户号主体的绑定关系是否被微信允许。**这一点需业务方确认，并在第一期上线前形成书面结论。**

---

## 3. 小程序类目与资质

### 3.1 为什么医药类目是重点

医药、医疗健康类目在微信小程序中属**重点监管行业**：

- 类目与资质**必须逐条匹配**，选错是驳回的第一高频原因。
- 主体、类目、经营范围三者需自洽。
- 部分类目可能涉及前置/后置审批（如涉及互联网药品信息服务的，需业务方确认，见《腾讯云商用上线准备方案.md》附录 C 第 C9 项）。

### 3.2 类目与资质对照表（需业务方按实际经营范围确认）

| 拟经营品类 | 需要的类目资质 | 主体要求 | 备注 |
|---|---|---|---|
| 处方药 / 非处方药销售 | 药品经营许可证 | 客户主体 | 经营范围须覆盖 |
| 医疗器械（II 类） | 第二类医疗器械经营备案凭证 | 客户主体 | 资质编号需与门店一致 |
| 保健食品 | 食品经营许可 / 仅销售预包装食品备案 | 客户主体 | 视具体品类 |
| 消毒产品 | 依当地规定 | 客户主体 | 需业务方确认 |
| 中药材 / 中药饮片 | 药品经营许可证（中药类） | 客户主体 | 需业务方确认 |
| 互联网信息服务（若涉及） | 可能的前置/后置审批 | 客户主体 | **需业务方确认（C9）** |

### 3.3 类目申报的操作要求

| 要求 | 说明 |
|---|---|
| 资质主体必须一致 | 营业执照、许可证、小程序主体、备案主体、支付商户号主体应尽量统一 |
| 许可证须在有效期内 | 过期或即将过期的资质会导致类目失效与商品下架 |
| 类目与商品一一对应 | 每个上架商品都要落在已获批类目下 |
| 提交前逐条自检 | 逐条对照类目要求核对材料，**不要凭印象提交** |

### 3.4 类目变更的运维影响

| 变更 | 需同步处理 |
|---|---|
| 新增类目 | 重新核对指定品种池与任务可售范围 |
| 下线类目 | 下架对应商品；检查是否有在途任务引用该品种 |
| 资质到期 | 提前预警，到期前不影响在售（**续期提醒机制需建立**） |

> 📌 资质到期是**静默风险**：不主动查就发现不了。建议在《交付包-运营SOP.md》第 6 章的每日巡检清单里加一条资质有效期检查。

---

## 4. 隐私与数据合规

### 4.1 个人信息收集清单

> 下表按"系统实际会处理什么"列，供撰写《用户隐私保护指引》与数据处理协议使用。字段以实际代码实现为准，发布前请与研发做一次最终对齐。

| # | 信息类型 | 具体字段 | 收集场景 | 处理目的 | 保留期限 |
|---|---|---|---|---|---|
| P1 | 手机号 | 手机号 | 店员注册登录 | 账号标识、登录验证、提现联系 | 需业务方确认（建议≥合同终止后按法定期限） |
| P2 | 姓名 | 真实姓名 `real_name` | 店员实名 | 提现打款、实名核验 | 同上 |
| P3 | 身份证号 | 证件号（系统内含 `id_card_hash` 哈希字段） | 店员实名 | 实名核验、风控 | 同上；建议仅存哈希 + 密文，明文不留存 |
| P4 | 岗位 | 职位 `position` | 店员资料 | 任务权限、等级评定 | 同上 |
| P5 | 门店信息 | 绑定门店、门店地址 | 店员绑门店 | 任务可见性判定、晒单审核 | 业务存续期 |
| P6 | 头像与昵称 | 头像、昵称 | 店员资料 | 展示、排行榜 | 同上 |
| P7 | 交易与账户信息 | 钱包余额、积分、流水、提现记录 | 激励业务 | 记账、对账、争议举证 | **建议≥3 年**（与会计凭证保存期一致，以业务方确认为准） |
| P8 | 收款信息 | 收款账户/账户标识 | 店员申请提现 | 打款 | 同上；打款完成后按最小必要原则处理 |
| P9 | 设备信息 | 设备指纹 `device_fp` | 风控 | 反刷单 | 建议较短（以业务方确认） |
| P10 | 小票图片 | 上传的小票图片及其 OCR 识别文本 | 店员晒单 | 审核真实性、重复凭证识别 | **建议短期留存**（审核完成后按约定删除，期限需业务方确认） |
| P11 | 行为日志 | 登录日志、操作日志 | 全系统 | 安全审计、排障 | **建议≥3 年**（以实际为准） |
| P12 | 网络信息 | IP、访问日志（nginx access log 含真实 IP） | 访问 | 风控、对账 | 同上 |

> ⚠️ **特别提示**：P10 小票图片与 OCR 文本可能包含**顾客的用药信息**，属于敏感度较高的信息。是否构成敏感个人信息、如何在隐私指引中描述，需法务判定。
> ⚠️ **特别提示**：P3 身份证与 P8 收款账户属高敏感字段。系统中的处理方式（哈希、加密、权限隔离）需与法务确认是否满足最小必要与存储加密要求。

### 4.2 《用户隐私保护指引》要点

平台需在小程序后台配置《用户隐私保护指引》，并在客户端接入隐私弹窗（`wx.getPrivacySetting`），**禁止默认勾选**。要点：

| # | 要点 | 说明 |
|---|---|---|
| 1 | 收集清单与本表一致 | 指引里写的字段必须与实际采集一致，**不要多写也不要漏写** |
| 2 | 用途一一对应 | 每个字段说明为什么收集、用来做什么 |
| 3 | 第三方 SDK 清单 | 列出实际接入的 SDK（微信支付、腾讯云 OCR、腾讯云短信等）及各自收集的信息 |
| 4 | 存储与加密说明 | 说明关键字段（身份证、收款信息、支付凭据）的加密措施 |
| 5 | 共享/转让/公开披露情形 | 明确列出，不做模糊表述 |
| 6 | 存储地点与跨境 | **声明境内存储、不向境外提供**（见 4.6） |
| 7 | 保存期限 | 按本表第 5 列写，与实际清理策略一致 |
| 8 | 用户权利行使路径 | 查询、更正、删除、撤回同意、注销账号的具体入口与受理时限 |
| 9 | 联系方式 | 明确受理主体与联系方式 |
| 10 | 弹窗交互 | 不得默认勾选；未同意时不得采集非必要信息 |

### 4.3 店员端（免登录）的特殊合规问题

店员端 H5 是**免登录**的公开端（接口走 `/app-api/incentive/clerk/**`），首次打开自动建档（生成 openid 存本地、建 `clerk_member` 记录）。这带来两个必须处理的问题：

| 问题 | 处理要求 |
|---|---|
| **无账号体系就没有"同意"入口** | 必须在首次进入时弹出隐私授权说明，用户勾选后方可继续；**拒绝不得采集非必要信息**，但可展示公开内容 |
| **openid 遗失 = 账号找不回** | 需提供手机号绑定/换绑能力；门店店员换手机时不应丢失钱包与成长值 |

> ⚠️ 免登录是**技术实现**，不是**可以免同意的理由**。个人信息处理规则对免登录端同样适用。

### 4.4 UGC 内容安全审核接入要求

小票图片与任务文字属于用户生成内容，**必须接入内容安全能力**：

| # | 要求 | 说明 |
|---|---|---|
| 1 | 接入内容安全 API | 文本与图片分别处理（对应 `msgSecCheck` / `imgSecCheck` 类能力） |
| 2 | **前端 + 服务端双重审核** | 前端提示 + 服务端强制校验，不能只做前端 |
| 3 | 违规处置闭环 | 命中 → 拒绝上传或转人工 → 记录 → 处置结果可追溯 |
| 4 | 人工复审为最终把关 | 系统的风控评分与 OCR 只是辅助；**高风险单必须人工判定**（见 SOP 第 3.3 节） |
| 5 | 审核记录留存 | 命中与放行都要留痕，供监管检查 |
| 6 | 黑名单机制 | `mall_blacklist` 已在用；误伤需人工复核（见 SOP 3.7 A 条） |

> 📌 接入内容安全是**一票阻塞项**（见方案文档附录 B 的 E7）。本项与"零容忍项"对应，未接入不得上线。

### 4.5 数据留存与删除

| 数据类别 | 留存策略 | 删除方式 |
|---|---|---|
| 交易/账务（钱包、流水、提现、打款凭证） | 按会计凭证保存要求保留，**建议≥3 年** | **不建议物理删除**，必要时做脱敏/归档 |
| 行为与审计日志 | 建议≥3 年 | 归档后删除明细 |
| 小票图片与 OCR 文本 | 审核完成后按约定保留期处理 | 到期物理删除（含对象存储） |
| 已离职店员的个人资料 | 按约定 | 非账务类可删除；账务类保留 |
| 账号注销后的数据 | 按合同与法定期限 | 详见 4.2 第 8 项的用户权利路径 |

**删除操作的技术注意事项**：

| 注意 | 说明 |
|---|---|
| 逻辑删除 ≠ 数据删除 | 演示数据清理用 `deleted=b'1'` 是逻辑删除，**个人信息的删除需物理删除或去标识化** |
| 备份中的数据 | 备份文件同样含个人信息，删除策略应覆盖备份（加密存储 + 到期销毁） |
| 对象存储 | 小票图片若存 COS，删除要覆盖 COS 侧与数据库引用两侧 |
| 留痕 | 删除动作本身要留审计记录 |

### 4.6 数据跨境与出境声明

| 项 | 现状 |
|---|---|
| 数据存储地点 | **境内**（腾讯云 CVM / 云数据库 / COS 境内地域） |
| 是否向境外提供 | **不向境外提供** |
| 第三方 SDK 数据流向 | 微信支付、腾讯云 OCR、腾讯云短信均为境内服务；提交隐私指引时需如实列出 |
| 涉及境外的情况 | 若未来引入境外 OCR / 分析类 SDK，**必须重新评估并更新隐私指引与告知** |
| 合同条款 | 数据处理协议中明确"数据处理与存储均在中国境内，不向境外提供" |

> ⚠️ 隐私指引中的"存储地点"表述必须与实际部署一致。若客户未来部署到境外机房，须重新做合规评估并更新指引。

### 4.7 数据安全措施（已实现的，供法务核实）

| 措施 | 实现方式 |
|---|---|
| 租户隔离 | 芋道框架强制：登录态租户与请求头 `tenant-id` 不一致直接 403 |
| 支付凭据加密 | `pay_channel.config` 整段 AES 加密落库；响应只返回布尔位 |
| 字段级加密 | MyBatis-Plus 字段加密，密钥走环境变量、不落代码 |
| 传输加密 | 全站 HTTPS + HSTS（`max-age=31536000; includeSubDomains`）+ 安全响应头 |
| 密钥管理 | `.env` 权限 600；密钥不入库不入仓 |
| 网络隔离 | MySQL / Redis / 后端 48080 **只绑 127.0.0.1**，不对公网暴露 |
| 敏感响应脱敏 | 商户号配置接口不返回明文凭据 |
| 日志与审计 | 打款操作人、打款时间、审核时间、对账状态全部落库可追溯 |
| 备份 | 每日 03:17 自动备份，保留 14 天 |
| 风控 | 黑名单 + 重复凭证指纹 + 风控评分 + OCR 置信度分级 |
| 数据发现 | 打款台账对账视图 `v_clerk_withdraw_reconcile` 供财务核对 |

---

## 5. 资金与合规

### 5.1 费用池的性质说明（关键，需法务确认表述）

| 项 | 说明 |
|---|---|
| 是什么 | 商家为"店员推广奖励"预充值到平台的**预付资金池**，专款专用 |
| 谁的钱 | **商家（客户）自己的钱**。充值在客户主体内部流转，不属于平台收入 |
| 平台是否沉淀资金 | 平台通过为每客户配置**独立微信支付商户号**收款，充值款项进入**客户自己的商户号**，**平台不经手客户资金** |
| 与"预付卡/储值"的关系 | 从形式上接近预付资金安排，**需业务方向法务/监管口径确认**是否触发预付资金相关要求 |
| 建议表述 | 在合同中明确："费用池为商家为发放店员推广奖励而预存的专项费用，所有权归商家，平台仅按商家指令记账与核销" |

> ⚠️ **这是本项目最需要法务出具结论的一点**。请业务方明确：费用池是否触发任何预付资金、储值卡、单用途商业预付卡相关的地方监管要求。相关待确认事项已归集在《腾讯云商用上线准备方案.md》附录 C。

### 5.2 商家转账（第二期自动打款）的资质要求

本版为人工打款。若第二期接入微信商家转账，需满足以下**前置条件**（详细背景见方案文档附录 B 的 E5 与第 7 章）：

| # | 条件 | 说明 | 状态 |
|---|---|---|---|
| 1 | 开通**运营账户** | **次日 0:00 生效，且不可关闭**；所有运营业务强制从运营账户出资 | 需业务方确认 |
| 2 | **配置请求来源 IP** | 调 API 的必要条件；必须填本系统服务器的固定出口 IP | 需业务方确认 |
| 3 | 开通产品并签约 | 依商户实际业务场景 | 时效以实际为准 |
| 4 | 提交**转账场景证明资料** | 依平台审核要求 | 以实际为准 |
| 5 | 商户号资质与额度 | 依商户号实际状态 | 以实际为准 |
| 6 | 主体资格 | 暂不支持小微商户（部分场景对个体工商户有支持，以实际为准） | 需业务方确认 |
| 7 | 单笔限额 | 红包样式单笔 ≤ 200 元 | 以实际为准 |

> ⚠️ **决策时点很重要**：运营账户一旦开通**不可关闭**，且次日 0:00 才生效。因此第二期的商务决策应在**系统改造开工前**完成，不要在代码改完后再申请。
> 📌 **业务规则也要匹配**：若单笔限额 200 元，则客户的单笔提现金额上限必须与之对齐；费用池单笔扣减也要相应设置上限。

### 5.3 人工打款期间的账务与发票处理

| 环节 | 处理要求 |
|---|---|
| 打款性质 | 商家向其雇员/合作店员支付的**推广奖励**，属商家与店员之间的劳务/服务报酬关系，**平台非付款方** |
| 记账位置 | 商家自己的账套，计入推广费用或销售费用科目（具体科目以商家财务制度为准） |
| 凭证 | 银行流水号 / 微信交易单号即打款凭证，**必须留存**（系统内已留痕在 `payout_voucher`） |
| 留存年限 | 建议 ≥ 3 年（与会计凭证保存期一致），具体以业务方确认 |
| 发票 | 打款给个人店员，一般**不涉及**向店员开票；是否涉及代扣代缴个税由商家财务按其所在地规定判断（**需业务方财务确认**） |
| 商家向平台付款 | 按服务协议约定开票；服务类型与税率以实际合同与税务口径为准 |
| 平台向客户开票 | 依据服务协议约定的服务内容开具；涉及多客户的，按各自合同分别开具 |
| 预付性质 | 若费用池按预收处理，未消耗部分在结算时按合同约定结转或退还 —— **需法务与财务确认口径** |

### 5.4 退款与争议处理

#### 5.4.1 退款场景

| 场景 | 处理规则 |
|---|---|
| 商城订单退款 | 走标准商城退款流程；**与激励业务无关**，不涉及费用池 |
| 晒单通过后店员申诉、商家改判驳回 | 若已发放，需从费用池扣回；**扣回失败（余额不足）时**，从商家后续充值中抵扣，或按合同约定另行结算 |
| 提现被驳回 | 冻结金额应自动释放回店员可提现余额；**冻结未释放属系统异常**，走平台排查 |
| 打款后追回（转错人） | 线下追回；系统内用"标记打款失败"回退状态并在备注写明；**追不回的责任由商家承担** |
| 重复打款 | 系统有唯一索引与状态机防重，但仍应每日对账发现；**多付部分由商家追回** |
| 客户终止合作 | 未消耗费用池余额按合同退还或结转；已发放未结算的打款按合同清算 |

#### 5.4.2 争议处理机制

```
店员提出申诉
      ↓
商家一线处理（首问负责，处理结论写入系统备注）
      ↓  未解决
平台升级通道（按合同约定的时限受理）
      ↓
按合同条款裁决（事实认定 + 规则适用）
      ↓
裁决结论与执行情况归档
```

| 需在合同中明确的 | 说明 |
|---|---|
| 谁是争议相对方 | 店员与商家的奖励关系由商家直接建立；平台介入为协助与裁决，非合同相对方 |
| 受理时限 | 平台受理与答复时限以实际为准 |
| 举证责任 | 谁主张谁举证；小票等证据由提交方提供 |
| 资金争议的暂缓规则 | 争议期间是否冻结对应金额（建议冻结，避免不可逆） |
| 仲裁/诉讼管辖 | 明确管辖地 |
| 责任上限 | 平台责任上限的约定方式（建议与合同额挂钩，以法务判断） |

### 5.5 反洗钱与反欺诈（店员侧）

| 风险 | 系统措施 | 合同/制度配套 |
|---|---|---|
| 同一店员薅多个商家的任务 | 任务可见性按商家隔离；风控评分 | 商家之间不共享店员黑名单（**需业务方确认是否要共享**，涉及数据共享合法性） |
| 批量注册小号 | 手机号唯一性约束；设备指纹 | 实名核验 + 设备指纹 |
| 伪造/复用小票 | 重复凭证指纹去重 + OCR | 保留申诉通道与人工复核 |
| 虚假门店刷单 | 白名单门店 + 区域授权 | 定期核查门店真实性 |
| 店员间倒卖账号 | — | 账号非转让，条款中明确 |

> ⚠️ "商家之间是否共享店员黑名单"是**数据共享**问题，涉及商家之间的数据流动合法性。**需业务方与法务明确**：本版不共享（各商家独立），如需共享须另行评估并签署数据共享约定。

---

## 6. 合同要点建议

> 以下为**谈判要点方向**，不是正式法律文本。具体条款由法务起草。

### 6.1 服务协议（平台 ⇄ 商家）要点

| # | 条款 | 建议内容要点 |
|---|---|---|
| 1 | 服务范围 | SaaS 系统使用 + 技术支持；**不含**代垫资金、代发奖励、代开发票 |
| 2 | 主体与责任边界 | 见本文第 1.3 节；特别写明平台非店员奖励的合同相对方 |
| 3 | 资质承诺 | 客户保证其具备经营本业务所需的一切资质，并保证资质在服务期内持续有效 |
| 4 | 资金与结算 | 费用池充值规则、消耗规则、余额处理、结算周期、退款规则 |
| 5 | 打款责任 | 客户自行完成打款；平台提供台账与对账视图；因客户打款差错造成的损失由客户承担 |
| 6 | 费率与计费 | 服务费/交易费的具体口径与费率（**以实际合同为准**） |
| 7 | 服务等级（SLA） | 可用性指标、故障响应与恢复时限、赔付方式（以实际为准） |
| 8 | 数据使用范围 | 平台仅按客户指令处理；**不得**将客户数据用于其他客户或模型训练 |
| 9 | 保密 | 双方商业信息与客户名单的保密义务 |
| 10 | 知识产权 | 平台软件的著作权归属；客户业务数据归属客户 |
| 11 | 免责 | 不可抗力、第三方服务（微信、腾讯云）故障的处理 |
| 12 | 违约与终止 | 违约情形、终止条件、终止后的数据导出与费用池清算 |
| 13 | 争议解决 | 协商 → 仲裁/诉讼 → 管辖地 |

### 6.2 数据处理协议（DPA）要点

| # | 条款 | 建议内容要点 |
|---|---|---|
| 1 | 角色定义 | 客户为处理者，平台为受托方（**含"仅按指令处理"义务**） |
| 2 | 处理目的与范围 | 店员信息、门店信息、交易记录、小票图片与 OCR 文本；逐项对应第 4.1 节 |
| 3 | 处理期限 | 与服务期一致；终止后的返还或删除安排 |
| 4 | 安全措施 | 引用本文第 4.7 节的已实现措施 |
| 5 | 子处理者 | 列出实际第三方（腾讯云、微信支付等）及其职责 |
| 6 | 跨境 | 明确不向境外提供（第 4.6 节） |
| 7 | 数据主体权利响应 | 协助客户响应查询、更正、删除、撤回等请求的时限与流程 |
| 8 | 安全事件 | 通知时限、配合义务、事件处置流程 |
| 9 | 审计与检查 | 客户合理审计权与配合方式 |
| 10 | 责任划分 | 安全事件责任、第三方原因导致的责任分担 |
| 11 | 终止后处理 | 数据返还格式、删除证明 |

### 6.3 推广服务补充约定（商家 ⇄ 店员）要点

> 建议以"公示规则 + 确认"的方式落地（门店公示、店员确认），避免逐个签署的法律成本。

| # | 条款 | 建议内容要点 |
|---|---|---|
| 1 | 奖励规则 | 单件积分、奖励金额、计算口径、发放条件（以任务公示为准） |
| 2 | 资格与范围 | 哪些门店、哪些店员参与；任务可见性规则 |
| 3 | 真实性承诺 | 店员承诺所上传凭证真实有效；违反的后果 |
| 4 | 审核与申诉 | 审核时限、驳回须说明理由、申诉渠道与时限 |
| 5 | 发放与兑付 | 发放时点、兑付渠道、**兑付时效**（SLA，以实际为准） |
| 6 | 税务 | 报酬性质与可能的代扣代缴说明 |
| 7 | 个人信息 | 店员同意商家处理其信息用于结算与审核 |
| 8 | 争议 | 与商家的争议处理方式；商家为相对方 |
| 9 | 规则变更 | 变更的提前告知期与方式 |

### 6.4 合同签署前检查

- [ ] 三份协议的主体名称与营业执照**完全一致**（含括号、全称）
- [ ] 费用池条款与第 5.1 节的性质表述一致
- [ ] 打款责任与第 5.3 节一致
- [ ] 店员为相对方的条款已写入（**争议最高频的漏洞点**）
- [ ] DPA 的处理清单与第 4.1 节一致
- [ ] 费率与打款时效已写入具体数值（不留"以实际为准"的空洞表述）

---

## 7. 上线前检查清单

> 可直接勾选。带 ⚪ 的项在《腾讯云商用上线准备方案.md》附录 C 中有对应的待业务方确认条目。

### 7.1 主体与合同

- [ ] 营业执照、经营范围覆盖实际经营品类
- [ ] 药品经营许可证 / 医疗器械备案凭证在有效期内
- [ ] 各门店许可证编号已收集，与门店清单一一对应
- [ ] 服务协议已签署
- [ ] 数据处理协议已签署
- [ ] 推广服务补充约定或公示规则已就位
- [ ] 费用池性质表述已在合同中明确（第 5.1 节）
- [ ] 店员为合同相对方的条款已写入
- [ ] 打款时效 SLA 已写入具体数值
- [ ] ⚪ 费用池是否触发预付资金相关地方监管要求，法务已出结论
- [ ] ⚪ 打款给店员的个税处理方式，财务已确认

### 7.2 小程序与平台账号

- [ ] 小程序主体与备案主体、支付主体一致（或已明确书面结论）
- [ ] ICP 备案通过
- [ ] 小程序认证完成
- [ ] 服务类目已申请通过，**与实际经营品类逐条匹配**
- [ ] 《用户隐私保护指引》已配置并发布
- [ ] 隐私弹窗已接入，`wx.getPrivacySetting` 可用，**未默认勾选**
- [ ] 隐私指引内容与第 4.1 节清单一致（不多不少）
- [ ] 第三方 SDK 清单已如实披露
- [ ] 微信服务器合法域名已配置（已备案 + HTTPS + 443 + 证书链完整）
- [ ] 内容安全能力已接入（文本 + 图片，**前端 + 服务端双重**）
- [ ] 微信支付商户号已申请，费率已登记
- [ ] ⚪ 小程序支付模式（服务商 vs 直连）已形成书面结论

### 7.3 资金与账务

- [ ] 每客户独立商户号已配置，`ready` 校验通过
- [ ] 支付回调地址与商户平台配置**完全一致**且为 https
- [ ] 费用池已充值，安全水位已设定
- [ ] 打款台账对账视图可正常导出
- [ ] 对账周期已确定（建议日对账 + 月度总账）
- [ ] 打款凭证留存年限已确定（建议 ≥3 年）
- [ ] 资质到期预警机制已建立
- [ ] ⚪ 是否共享商家间店员黑名单，已明确

### 7.4 数据与隐私

- [ ] 个人信息收集清单已与研发做最终对齐
- [ ] 身份证、收款信息的加密与最小必要处理已核实
- [ ] 小票图片与 OCR 文本的留存期限已确定，删除流程可执行
- [ ] 备份文件同样纳入删除/销毁策略
- [ ] 账号注销与数据删除流程可执行
- [ ] 店员端免登录的隐私授权入口已就位（首次进入弹窗）
- [ ] 店员换手机 / 找回账号路径已验证
- [ ] 数据境内存储声明与实际部署一致

### 7.5 业务与运营

- [ ] 商家管理员账号与角色已配置
- [ ] 店员端任务可见性五道防线已逐条验证
- [ ] 重复凭证、黑名单、区域越权的处理流程已培训到商家
- [ ] 打款五步法已培训到出纳
- [ ] 店员操作指引已下发到门店
- [ ] 客服与投诉受理人、受理时限已确定
- [ ] 每日巡检清单已交给商家（含资质有效期检查）

### 7.6 技术与运维（与运维方共同确认）

- [ ] 全站 HTTPS + HSTS 生效
- [ ] MySQL / Redis / 后端 48080 未对公网暴露
- [ ] `.env` 权限 600 且未入库
- [ ] `MYBATIS_ENCRYPTOR_PASSWORD` 已离线备份并有书面交接记录
- [ ] 每日备份任务已生效，**已做过一次实际恢复演练**
- [ ] 自动化回归 17 套件 / 466 用例全绿
- [ ] 监控与告警已接入
- [ ] ⚪ 弱证据晒单（无小票）是否允许，已明确
- [ ] ⚪ 门店定位是否使用，已明确（影响隐私指引与安全头）

---

## 8. 文档间关系与免责说明

| 本文档 | 引用关系 |
|---|---|
| 《腾讯云商用上线准备方案.md》 | 资质办理总表、成本估算、安全加固总表、上线检查表、待确认事项的**权威来源** |
| 《交付包-部署与运维手册.md》 | 技术侧密钥管理、备份留存、故障排查 |
| 《交付包-运营SOP.md》 | 业务侧执行动作、异常处理、打款标准动作 |

> ⚠️ **免责与确认声明**：本文档所列资质清单为基于系统当前功能范围整理的**最小必要清单**，非监管机构的官方要求目录。类目要求、资质要求、办理时效与费用会随监管与平台政策调整，**最终以主管部门与平台审核结论为准**。
> 标注「**需业务方确认**」「**以实际为准**」的条目，**必须在上线前完成确认并留下书面记录**，不得默认通过。
> 涉及法律意见的部分（费用池性质、预付资金监管适用、个税处理、争议管辖），本文档仅提供要点方向，**正式法律意见以法务出具为准**。