> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 交易与退款字段参考

> Portal 上支付或退款记录每个字段的实际含义：退款上的两个商户订单 ID、Initiation Type（CIT/MIT）及其为何通常为空、卡信息以及卡号如何掩码、金额为何显示为短横线，以及退款按钮为何缺失或灰显。

本页是 Portal 中单条支付或退款记录的逐字段参考——某一列是什么意思，以及你期望有值时它为何为空。退款*规则*（几次、多少、跨币种、返还费用）见
[退款 FAQ](/docs/zh/support/refund-faq)；看板指标见[Portal 看板与分析](/docs/zh/support/portal-analytics-faq)；领取导出文件见
[导出与报表下载](/docs/zh/support/export-center-faq)。

## 一笔支付带有哪些标识，我该引用哪个？

四个，且不可互换：

| 列 | 谁的标识 | 用途 |
| - | - | - |
| `Order Id` | Waffo 的 | 向 Waffo 支持引用某笔交易——发这个 |
| `Merchant Order Id` | 你的 | 匹配回你自己的订单记录 |
| `Payment Request Id` | 请求的 | 追踪创建该订单的具体那一次尝试 |
| `Merchant User Id` | 你的 | 你在创建订单时传的客户标识 |

提工单时，先给 `Order Id`。你自己的订单 ID 可用作交叉核对，但在全平台不唯一，所以单凭它追踪会更慢。

退款有自己的一套标识——见下文。

## 一笔支付带有哪些时间戳，为什么有三个？

| 列 | 标记的是 |
| - | - |
| `Created Datetime` | 订单创建的时间 |
| `Payment Date` | 该支付归属的日期 |
| `Payment Time` | 支付本身的时间 |

它们是有意分开的：一笔在午夜前创建、午夜后支付的订单，创建时间戳在前一天，支付日期在后一天。匹配打款时按 `Payment Date` 对账；
排查订单量或限额拒绝时按 `Created Datetime`——每日交易限额从创建时起计，见
[Payin 协议与交易限额](/docs/zh/support/payin-agreements-and-limits-faq)。

未设置的时间戳显示为 `-`，所以未支付的订单显示创建时间，其余两项为短横线。

## 一条退款显示两个商户订单 ID，分别是什么？

它们是不同的对象，混淆它们是最常见的对账错误：

| 列 | 属于 | 内容 |
| - | - | - |
| `Merchant Order Id` | **退款** | *你*为退款请求分配的订单 ID |
| `Merchant Original Order ID` | **原支付** | 你为被退款的那笔支付分配的订单 ID |

所以要把退款追溯到销售，用 `Merchant Original Order ID`。要追踪你自己的退款指令，用 `Merchant Order Id`。

`Merchant Original Order ID` 出现在退款列表、退款详情的商户信息块，以及退款导出中。值缺失时 Portal 显示 `-`。

Waffo 一侧的标识与之并列：退款自身的收单订单 ID、退款请求 ID，以及——当退款来自批量时——`Refund Batch ID`，单笔退款时为 `-`。

## 我能按原支付的订单 ID 搜索退款吗？

能。`merchantOriginalOrderId` 是退款列表组合搜索选择器中的字段之一，且为**精确**匹配——不是前缀也不是子串匹配。请粘贴完整的原订单 ID。

如果没有结果，请确认你搜的是原*支付*的 ID 而不是退款自身的 ID，并确认值末尾没有多余空格。

## 退款按钮为什么不见了或者是灰的？

有三种状态，含义各不相同：

| 状态 | 它告诉你的是 |
| - | - |
| 按钮**不存在** | 该订单永远不能从 Portal 退款——其状态不是支付成功，或协议根本不允许退款 |
| 按钮**灰显** | 这类订单可以退款，但这一笔订单当前不满足条件 |
| 按钮**可用** | 你可以退款 |

按钮灰显时，以下五个条件中有一个未通过：

| 条件 | 为何阻断 |
| - | - |
| 退款形式仍可用 | 协议可能只允许一次退款，或只允许全额退款——如果已经用过，就没有可用的退款形式了 |
| 在退款期内 | 只在协议的退款窗口内接受退款，从订单创建起计，首尾两天均包含 |
| 订单上没有争议冻结 | 处于争议中的订单被冻结，不能从 Portal 退款 |
| 未达最大退款次数 | 一笔订单可承载的退款记录数有上限，成功的和进行中的都算 |
| 剩余可退金额大于零 | 已全额退款——或有一笔全额退款仍在进行中——就没有可退的了 |

注意后两项都计入进行中的退款。你几秒前提交的退款已经占用了一个名额和对应金额，这就是为什么在任何东西结清之前按钮就可能变灰。

退款面板和订单详情都显示 `Remaining Refundable Amount`，所以你可以直接看到第三个数字。哪些支付方式支持退款见你的
[Payin 协议页面](/docs/zh/support/payin-agreements-and-limits-faq)。

没有退款权限的用户无论上述条件如何都看不到该按钮——见
[商户 Portal 操作](/docs/zh/support/portal-operations-faq)。

## Initiation Type 这一列是什么？

`Initiation Type` 用于区分卡交易是谁触发的：

| 值 | 含义 |
| - | - |
| `CIT` | 持卡人发起——客户在场并主动操作，如首次支付或手动再次购买 |
| `MIT` | 商户发起——你基于已存储的授权触发，如订阅续订 |

它是**按交易**的属性，所以出现在支付列表上而不在汇总视图中。

## Initiation Type 为什么一直显示短横线？

因为该值只有在你**按它筛选**时才会填充。这是有意设计，不是你的数据有缺口：

| 你的操作 | 该列显示 |
| - | - |
| 正常打开支付列表 | 每一行都是 `-` |
| 筛选 `Initiation Type` = `CIT` | 返回行显示 `CIT` |
| 筛选 `Initiation Type` = `MIT` | 返回行显示 `MIT` |

所以该列是**对你筛选条件的确认**，不是可浏览的属性。要看两者的分布，请查询两次——每个值一次——而不是扫一遍未筛选的列表。

该列也只对签约了订阅的账户展示，因为区分在那里才有意义。如果你的列表里根本没有这一列，原因就在这里。

## 支付记录会显示哪些卡信息？

在支付详情的支付信息块中，当支付方式为卡时：

| 字段 | 说明 |
| - | - |
| `Cardholder name` | 支付时提供的 |
| `Card number` | 掩码显示，带卡组织 logo |
| `Card expiry date` | 支付时提供的 |
| `Issuing country` | 卡的发卡国 |
| `Issuing bank` | 卡的发卡行 |
| `Order Failure Code` | 仅失败订单有 |
| `Order Failure Description` | 仅失败订单有 |

以上每一行在**没有值时都会省略**——该块不显示空标签。所以缺少 `Issuing bank` 一行意味着该交易没有这项数据，而不是字段被移除了。非卡支付方式不显示任何卡信息行。

这些值是记录在该笔交易上的值。之后不会刷新，所以同一张卡在不同时间的两笔交易可能合理地不一致。

`Cardholder name` 是你客户的个人数据。在任何导出或存储中请相应对待。

## 卡号是怎么掩码的？

**前 6 位，然后星号，然后后 4 位**——例如 16 位卡号显示六位数字、六个星号和四位数字。较短的值安全降级：6 到 9 个字符的值显示前 6 位、其余为星号；更短的值原样显示。

完整卡号在 Portal 和导出中都不可获得，也没有任何设置可以显示它。如果你需要跨交易匹配一张卡，请用掩码值加上有效期和卡组织，而不要期望拿到完整卡号。

## 金额为什么显示为短横线？

Portal 只在**同时**有数字和币种时才渲染金额。缺任何一个，单元格显示 `-`。

值得了解这一点，因为 `-` 因此不代表零。真正的零显示为带币种代码的格式化 `0.00`；短横线表示这一对数据不可用。

## 金额和币种是怎么格式化的？

| 规则 | 行为 |
| - | - |
| 顺序 | **金额在前，币种代码在后**——`1,234.56 USD`，而不是 `USD 1,234.56` |
| 分组 | 千位分隔符和小数采用 `en-US` 惯例，与你选择的界面语言无关 |
| 符号 | 币种**符号被去掉**；只显示三字母代码 |
| 方向 | 记录有方向时，入账前缀 `+`，出账前缀 `-` 并显示为红色 |

如果你在解析导出的数字，请按代码而不是符号解析，也不要假设分隔符惯例跟随 Portal 的语言设置。

## 为什么支付列表上没有结算状态列？

main 上没有这一列。支付列表带有订单自身的状态、创建和支付时间戳，以及——相关时——其订阅 ID，但没有结算状态。

结算状态**在**争议列表上可用，那里它既是列也是筛选项。支付级别的结算信息请以结算报表为准，而不是交易列表：见
[结算报表](/docs/zh/support/settlement-reports-faq)和[结算周期](/docs/zh/support/settlement-cycle-faq)。

## Order Failure Code 和 Order Failure Description 是什么？

它们只出现在失败的订单上，是同一答案的两半：一个你可以在自己系统里据以分支的稳定代码，和一段人可读的描述。逻辑用代码，支持沟通用描述。

常见失败原因及应对汇总在[错误与排障](/docs/zh/support/errors-troubleshooting-guide)；限额拒绝专门见
[Payin 协议与交易限额](/docs/zh/support/payin-agreements-and-limits-faq)。

## 支付记录为什么显示订阅 ID？

因为该支付是在订阅下扣的。支付列表带有关联的订阅 ID，以便单笔扣款可以追溯到产生它的订阅；一次性支付上为 `-`。

反过来——从订阅到它的各笔扣款——见
[订阅生命周期管理](/docs/zh/support/subscription-lifecycle-management)。

## 支付记录显示哪些费用数字？

支付详情带有一个 `Fees` 块，显示该交易收取的费用，为金额加费用币种。你的费用**基准**——百分比、固定费、下限和上限——不在交易上；它在你的
[Payin 协议页面](/docs/zh/support/payin-agreements-and-limits-faq)。

支付被退款（含部分退款）时费用如何处理，见[退款 FAQ](/docs/zh/support/refund-faq)。

## 文档里提到的字段在 Portal 上显示为短横线，是数据缺失吗？

通常不是。Portal 在三种不同情形下都刻意显示 `-` 而不是 `N/A`、空单元格或零，分清它们能省一张支持工单：

| 原因 | 示例 |
| - | - |
| 该属性不适用于这条记录 | 单笔退款上的 `Refund Batch ID`；一次性支付上的订阅 ID |
| 该属性只在特定查询下填充 | CIT/MIT 筛选之外的 `Initiation Type` |
| 该交易没有这个值 | 卡数据未携带的发卡行 |

三种情况都无法通过重新打开记录恢复。属于第二种时，带上相应筛选条件重新查询。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.