# 支付流水（GetPayLogListPage）

> 自动生成于 2026-02-13 | 数据来源：实时 API

## 基本信息

| 属性 | 值 |
|------|-----|
| 接口路径 | `PayLog/GetPayLogListPage` |
| 完整 URL | `https://pc.ficoo.vip/apiprod/admin/v1/PayLog/GetPayLogListPage` |
| 请求方法 | `POST` |
| Content-Type | `application/json` |
| 鉴权方式 | Bearer Token（`Authorization` 头） |
| ODS 对应表 | `payment_transactions` |
| 分页方式 | `page` + `limit`（最大 100） |
| 时间范围 | 需要（StartPayTime / EndPayTime） |

## 请求参数

| 参数名 | 类型 | 示例值 | 说明 |
|--------|------|--------|------|
| `StartPayTime` | string | `"2026-02-01 08:00:00"` | 支付起始时间 |
| `EndPayTime` | string | `"2026-02-13 08:00:00"` | 支付结束时间 |
| `siteId` | int | `2790685415443269` | 门店 ID |
| `OnlinePayChannel` | int | `0` | 在线支付渠道（0=全部） |
| `paymentMethod` | int | `0` | 支付方式（0=全部） |
| `relateType` | int | `0` | 关联类型（0=全部） |
| `page` | int | `1` | 页码（从 1 开始） |
| `limit` | int | `100` | 每页条数（最大 100） |

## 响应字段（共 11 个）

| # | 字段名 | 类型 | 示例值 |
|---|--------|------|--------|
| 1 | `siteProfile` | object | {'id': 2790685415443269, 'org_id': 2790684179467077, 'sho... |
| 2 | `create_time` | string | '2026-02-13 04:49:48' |
| 3 | `pay_amount` | float | 0.0 |
| 4 | `pay_status` | int | 2 |
| 5 | `pay_time` | string | '2026-02-13 04:49:48' |
| 6 | `online_pay_channel` | int | 0 |
| 7 | `relate_type` | int | 2 |
| 8 | `relate_id` | int | 3092711340902597 |
| 9 | `site_id` | int | 2790685415443269 |
| 10 | `id` | int | 3092712422508741 |
| 11 | `payment_method` | int | 4 |

## 详细字段分析

> 以下内容迁移自旧版 `payment_transactions-Analysis.md`，包含字段的业务含义、枚举值、跨表关联等详细说明。

二、字段逐一说明（含类型、枚举、可能含义）
1. 门店维度字段
1.1 siteProfile

类型：对象（Object）

含义：门店信息快照，与其他 JSON 中的 siteProfile 结构一致。

关键子字段（只列最重要的，结构与前面文件相同）：

id：门店 ID（本数据中固定为 2790685415443269）。

org_id：组织 ID。

shop_name：店名（例如“朗朗桌球”）。

full_address / address：详细地址 / 简要地址。

business_tel：门店电话。

longitude / latitude：经纬度。

tenant_id：租户 ID。

site_label：门店标签（如 “A”）。

shop_status：门店状态枚举（本数据中为 1，表示正常营业）。

以及 WIFI、灯控、客服二维码等配置字段。

说明：

siteProfile.id 与本记录的 site_id 完全一致。

在整个系统中，这是一份门店维度的冗余快照，方便前端和报表使用。

1.2 site_id

类型：整数（long）

观测：所有记录均为 2790685415443269。

含义：支付记录所属的门店 ID。

关联关系：

与其他所有 JSON 中的 site_id / siteId 对应，是全局的门店外键。

与 siteProfile.id 相同，保证“门店维度”一致。

2. 支付流水主键与业务关联
2.1 id

类型：整数（long）

特征：200 条记录中的 id 全部唯一。

含义：支付流水记录的主键 ID。

作用：

在“支付记录”这个表内部，唯一标识一条支付流水（包括金额为 0 的记录）。

2.2 relate_type

类型：整数（int），明显是 枚举字段。

观测到的枚举值及数量：

2：出现 196 次。

5：出现 3 次。

1：出现 1 次。

含义（从结构与其他表关联推断）：

表示“这条支付记录关联的业务类型”。

不同的 relate_type，relate_id 指向不同业务表：

relate_type = 2：
通过数据实际比对，可以确认：

relate_id 对应 结账记录.json 中的 settleList.id（即结账单 ID / order_settle_id）。

本类型是“结账单支付流水”。

relate_type = 5：
通过与 会员卡流水（tenantMemberCardLogs） 的比对：

在 tenantMemberCardLogs 中，存在字段 relate_id = 本表.relate_id，from_type = 3，且有充值金额 account_data。

因此可以判断：relate_type = 5 对应“会员卡余额/充值类业务”的支付流水。

relate_type = 1：
当前样本中只有 1 条，且在其他 JSON 中没有找到同 ID 的记录，具体业务类型不明，结构上可先视作“其他业务类型（预留枚举值）”。

总结：relate_type 是“支付关联业务类型”的枚举，至少包括：

2：结账单支付；

5：会员卡充值/账户操作支付；

1：其他少见业务类型（暂不确定）。

2.3 relate_id

类型：整数（long）

特征：

200 条记录中，relate_id 全部互不重复（n_unique=200）。

含义：关联业务记录的主键 ID（按 relate_type 不同指向不同表）。

具体关联关系：

当 relate_type = 2：

relate_id = 结账记录表（结账记录.json）中 settleList.id。

即：一条结账单，会在本表中对应一条支付记录（当前样本里是一对一，结构上允许扩展为一对多）。

当 relate_type = 5：

relate_id = 会员卡流水（tenantMemberCardLogs）中的 relate_id 字段，而非该表的主键 id。

说明：充值/余额变更有自己的“业务单号”，该单号在支付记录和会员卡流水中共享。

当 relate_type = 1：

未在其他已解析表中找到对应 ID，只能确认它是一种保留业务类型。

3. 支付金额与时间字段
3.1 pay_amount

类型：浮点数（float）

观测数据：

不同取值共 36 个。

最小值：0.0，最大值：3000.0。

分布特征（只看结构）：

0.0：出现 140 次。

其他典型值：4.0, 5.0, 6.0, 10.0, 14.0, 15.0, 20.0, 48.0, 96.0, 1000.0, 3000.0 等。

含义（结构层面）：

本条支付流水的“支付金额”，单位为元。

特别情况：

140 条 pay_amount = 0 的记录，其 (relate_type, payment_method) 组合全部为 (2, 2)。
从结构角度看，可以解读为：

这部分支付流水记录通过 payment_method=2 标记了某种支付渠道，但金额为 0；

金额实际可能由其他渠道/卡券抵扣（具体业务逻辑不在本次分析范围）。
这里仅说明“0 元支付记录在结构上是合法且被大量使用的”。

3.2 create_time

类型：字符串（string），格式 "YYYY-MM-DD HH:MM:SS"

特征：

200 条记录中，create_time 全部唯一。

含义：

支付记录创建时间，通常与发起支付请求的时间一致（创建支付流水的时间戳）。

3.3 pay_time

类型：字符串（string），格式同上。

特征：

200 条记录中，pay_time 也全部唯一。

在数据中 create_time 与 pay_time 多数完全一致，说明支付完成较快。

含义：

实际支付完成时间（支付状态变为成功的时间戳）。

从结构角度：

create_time 可以用来追踪“付费动作发起时间”。

pay_time 记录“支付成功时间”。
在异步支付场景，二者有可能不一致（当前样本中大多相同）。

4. 支付状态与渠道、方式字段
4.1 pay_status

类型：整数（int），枚举。

样本情况：所有记录 pay_status = 2。

含义（结合命名和导出结果推断）：

支付状态枚举字段。

当前导出只包含状态为 2 的记录，很明显是“支付成功”的状态。

其他可能存在的枚举值（未出现在本数据中）：

例如 0=未支付，1=支付中，3=支付失败，4=已退款等（仅示例，具体需参考系统配置）。

结论（结构）：
导出的 支付记录.json 是“成功支付流水”的子集，其他状态被过滤掉。

4.2 payment_method

类型：整数（int），枚举。

样本分布：

2：140 条记录。

4：60 条记录。

含义：

支付方式枚举，例如微信、支付宝、现金、银行卡、储值卡等某一种。

当前数据中只出现了 2 种枚举值，但没有文字说明映射关系。

从结构角度的判断：

这是区分不同支付“方式/通道”的关键字段；

应与系统中的“支付方式配置表”存在映射关系（本次导出未包含该配置表）。

需要注意：
虽然可以猜测 2 和 4 可能对应常见通道（如微信/支付宝等），但在缺乏配置表的情况下不宜直接下结论，这里只确认它是“支付方式枚举”的字段。

4.3 online_pay_channel

类型：整数（int），枚举。

样本情况：所有记录 online_pay_channel = 0。

含义（命名层面）：

线上支付渠道枚举，例如：

0：无 / 线下；

1：微信；

2：支付宝；

……

但当前时间范围内，所有记录均为 0，没有其他枚举值出现。

结构特点：

这个字段是为细分“在线支付通道”准备的；

当前门店在本次导出时间段内，可能没有使用该字段（或所有支付统一走某种方式未拆分）。

5. 其他结构性字段

这里主要就是前面已经涉及的：

siteProfile：门店快照（对象）。

site_id：门店 ID，所有记录相同。

id：支付流水主键。

relate_type & relate_id：业务关联键。

没有额外隐藏字段，本表结构很精简、单一职责较强。

三、与其他 JSON 的关联关系（从字段角度）

本表核心作用：承载“支付结果”层面的信息，通过 relate_type + relate_id 把不同业务域的流水（结账单、会员卡流水等）统一串到“支付系统”上。

1. 与结账记录（结账记录.json）的关系

关联字段：

当 relate_type = 2 时：

支付记录.relate_id = 结账记录.settleList.id

结构含义：

每一笔结账单（settleList.id）对应一条支付记录（当前样本中是一条记录，relate_id 唯一）。

通过这个关系，可以：

从结账记录跳转到对应的支付记录；

从支付记录反查对应的结账单。

补充：

在整个系统中，结账记录.id 也对应各类明细表的 order_settle_id（台费、助教等），因此：

支付记录 间接成为连接“支付系统”与“台费/助教/商品明细”的桥梁。

2. 与会员卡流水（tenantMemberCardLogs）/ 余额变更记录的关系

对于 relate_type = 5 的记录：

在 tenantMemberCardLogs 中存在：

tenantMemberCardLogs.relate_id = 支付记录.relate_id

tenantMemberCardLogs.payment_method = 支付记录.payment_method

tenantMemberCardLogs.account_data = 充值金额（例如 1000.0）。

结构含义：

这些支付记录对应的业务类型是“会员卡余额充值/账户变动”。

relate_id 在这里扮演“充值业务单号”的角色，在支付表和会员卡流水中共享。

3. 与门店维度的关系

site_id 与各个表（结账记录、台费流水、助教流水等）的 site_id 一致。

siteProfile 作为冗余的门店信息快照，与其他文件中的门店快照结构一致。

4. 与结算/小票维度的间接关系

支付记录 →（通过 relate_id）→ 结账记录 →（通过 id/orderSettleId）→ 小票详情/台费/助教明细。

结构上，这构成一条完整的链路：

业务明细表（台费/助教等）只记录“消费内容”；

结账记录汇总明细，形成一条“结算单”；

支付记录在“结算单”基础上记录“实际支付行为”。

四、本表暴露出的结构性设计特点和线索

从纯结构、字段设计角度，本表有几个明显的设计意图和特点：

强烈的“统一支付网关”设计
通过 (relate_type, relate_id) 组合，支付系统不直接关心支付的是“台费单、结账单还是会员卡充值单”，而是：

不同业务系统约定一个 relate_type；

将各自的业务主键（或业务单号）写入 relate_id。
这样整个支付层可以统一处理资金动作，而上层业务只需按约定填字段。

支付成功流水视角，非全量支付事件日志

pay_status 全部为 2；

没有看到待支付、失败、关闭等状态。
说明当前导出的 支付记录.json 实际上是“支付成功流水卡片”，而不是“完整交易生命周期日志”。
对数据建模时，应该把“支付记录”视为 成功资金落地的事实表。

支付方式与线上渠道双层枚举结构

payment_method：高层次区分支付方式（现金/卡/微信/支付宝/储值卡等）；

online_pay_channel：更细粒度区分“线上支付通道”（按实际配置可能划分微信/支付宝等）。
当前样本中 online_pay_channel 全为 0，说明这个维度还没被实际利用，但结构已经预留，用于以后精细化拆分。

允许一单多笔支付的设计空间

结构上，relate_id 并没有强制唯一，可以允许：

同一个 relate_id + 不同 payment_method；

同一结账单部分现金、部分在线等组合支付。

虽然本时间段样本中每个 relate_id 只出现一次（对 relate_type=2 来说），但从设计上看，完全可以扩展为一对多。
在后续建模时不要假定“一个 relate_id 一定只对应一条支付记录”，这只是当前时间段的实际情况。

0 元支付流水的大量存在

规模：200 条记录中，有 140 条 pay_amount = 0，且全部 (relate_type=2, payment_method=2)。

结构意义：

系统会对“金额为 0 的支付动作”也产生支付流水记录，这可能是为了：

记录“某个支付方式参与了本单，但实际金额由其他方式/卡券承担”；

或记录内部结算/记账动作。

对后续分析和建模来说，不能简单按“pay_amount > 0”过滤数据，否则会丢失一大批结构上真实存在的支付行为。

门店维度冗余一致性

site_id 与 siteProfile.id 始终一致；

该模式与台费流水、助教流水、结账记录中的门店设计完全统一。
这种“一份数字外键 + 一份冗余快照”的模式，对于你后面做数据中台/数仓建模有直接影响：

在数仓中一般会把 site_id 建成维度外键；

siteProfile 只在上游 ODS 层保留快照，DW 层不一定全量展开。