{
  "synthetic": true,
  "execution": "Teaching record only; no live integration tested",
  "slug": "refund-pending-failed-status-ledger",
  "group": "commerce-operations",
  "title": [
    "A requested refund is not a completed refund",
    "退款已请求，不等于退款已完成"
  ],
  "intro": [
    "A merchant commissioning a refund status page needs more than a green success message after an API response. Customers and staff need to distinguish an accepted request, a pending provider state and a failed refund. The display should retain an operation identity so a retry does not obscure the original outcome.",
    "委托制作退款状态页时，接口响应后的绿色提示不足。客户和员工需要区分请求接受、平台处理中及退款失败；显示还须保留操作身份，避免重试掩盖原结果。"
  ],
  "facts": [
    [
      "Stripe documents pending and failed refund outcomes, payment-method differences and status updates. Funds and completion timing depend on the actual method and provider state; creating a refund does not establish that the customer’s bank received it.",
      "Stripe说明退款可能处理中或失败，方式及状态更新各有差异；资金和完成时间依实际方式及平台状态决定，创建退款不证明客户银行已到账。",
      "https://docs.stripe.com/refunds"
    ]
  ],
  "example": [
    [
      [
        "Captured10000 minor units; refundR1=2000 succeeded",
        "Verified provider record",
        "Show R1 succeeded; do not infer a bank posting date"
      ],
      [
        "已捕获10000最小单位，R1退款2000成功",
        "已核实平台记录",
        "显示R1成功，不推断银行入账日"
      ]
    ],
    [
      [
        "R2=1000 pending",
        "Merchant model reserves pending amount",
        "Reserve1000; show pending, not completed"
      ],
      [
        "R2为1000，处理中",
        "商家模型预留处理中金额",
        "预留1000，显示处理中，不写完成"
      ]
    ],
    [
      [
        "R3=1000 failed",
        "Failure record retained",
        "Escalate; do not relabel as success or silently create a new refund"
      ],
      [
        "R3为1000，失败",
        "保留失败记录",
        "升级处理，不能改成成功或悄悄重建退款"
      ]
    ],
    [
      [
        "R1 succeeded plus R2 pending",
        "Declared reservation model",
        "10000−2000−1000=7000 unreserved; not a bank balance"
      ],
      [
        "R1成功加R2处理中",
        "按声明预留模型",
        "10000−2000−1000=7000未预留，不是银行余额"
      ]
    ]
  ],
  "steps": [
    [
      "Agree customer wording and the merchant’s internal reservation rule. Keep captured, requested, pending, succeeded and failed amounts in separate fields with currency and operation IDs.",
      "约定客户文案和内部预留规则；捕获、申请、处理中、成功及失败金额分字段，并保留币种及操作ID。"
    ],
    [
      "Use the four synthetic rows to check arithmetic and state transitions. In an authorised provider test account, reconcile actual status updates without treating a browser return as payment evidence.",
      "用四行合成记录核对算术及状态转换，在获准平台测试账户核对实际更新，不能把浏览器返回当资金证据。"
    ],
    [
      "Require staff to resolve an unknown or failed operation before retrying. Reconcile customer-facing messages with the retained provider record and disclose unresolved completion.",
      "未知或失败先由员工核对再重试；客户文案与平台记录一致，未明完成状态须保留。"
    ]
  ],
  "result": [
    "The7000 is the output of an explicitly declared teaching reservation policy. It is not Stripe’s universal available-refund formula, a payout balance or proof of bank settlement. Keeping R3 visible makes a failure reviewable instead of erasing it with a replacement success badge.",
    "7000来自明确声明的教学预留规则，不是Stripe通用可退公式、提现余额或银行结算证明。保留R3让失败可复查，不用替换成功标记抹掉。"
  ],
  "accept": [
    "Require correct state labels, arithmetic and operation continuity against verified test records. A customer completion promise needs its own method-specific evidence.",
    "须按核实测试记录保证状态、算术及操作连续性；承诺客户到账须另有支付方式依据。"
  ],
  "limit": [
    "Synthetic amounts and policy only. No refund, payment, account lookup or financial advice; provider permissions, fees and actual bank outcomes remain unverified.",
    "仅合成金额与规则，不执行退款、付款、查账户或金融建议；实际权限、费用及银行结果仍未验证。"
  ],
  "oldLinks": [
    {
      "language": "zh",
      "target": "/zh/scenarios/accountant-ecommerce-reconciliation/",
      "anchor": "把退款操作与币种交给电商对账流程",
      "reason": "Provider state and amounts must survive the accounting handover."
    }
  ]
}