客户发来邮件说「已经取消了，为什么还被扣了一笔」，客服最容易先道歉再退款，结果后来发现那笔 transaction 是取消前已经生成的续费，或者客户只是取消了应用内权限、没有进 Paddle Customer Portal。先把时间线拉直，比争论「是不是系统错扣」更快。
这里不把具体司法辖区的税务处理写成结论。金额较大或涉及公司报销时，让客户把 invoice PDF、credit note 和自己的税务顾问对齐。
取消了还扣费，先分成哪三种情况？
第一类是客户在 Customer Portal 里选择当前周期结束时取消。Paddle 会在 subscription 上留下 scheduled_change，到 effective_at 才把状态改成 canceled；在此之前，subscription 仍可能显示 active。
第二类是 transaction 已经在取消前创建或完成。Paddle 的 transaction 是财务记录，完成后不能直接改写，只能通过 refund 或 credit adjustment 留下另一条记录。
第三类是手工收款 invoice。collection_mode=manual 的 transaction 进入 billed 后会成为已开具 invoice；如果 invoice 本身开错，处理路径和自动扣款的 refund 不一样。
| 客户看到的现象 | Paddle 后台先看哪里 | 默认回复方向 |
|---|---|---|
| Portal 显示已取消，但后台仍 active | subscription.scheduled_change 和 effective_at | 说明将在当前周期结束时生效 |
| 银行卡或 PayPal 已扣款 | transaction.status、created_at、completed_at | 判断是否需要 refund adjustment |
| 客户收到 invoice 但没付款 | collection_mode=manual、status=billed | 看 credit、取消 invoice 或取消相关 subscription |
| 客户要税务发票 | GET /transactions/{transaction_id}/invoice | 提供 invoice PDF，不替客户判断税务可用性 |
Customer Portal 里要让客户看到什么？
Customer Portal 是 Paddle 托管的账单管理页，客户可以看 payments、下载 invoice、更新付款方式，也可以管理 subscription。取消订阅时，Portal 会进入 cancellation flow；按官方文档，Portal 取消默认是在当前账期结束时生效。
你自己的 SaaS 后台不要只放一个「取消成功」toast。更稳的做法是把客户引到 Paddle 的 portal 链接，或者在应用里展示 Paddle 返回的 cancellation 深链。客服回复里写清楚三项：取消发起时间、effective_at、下一次是否还有 next_billed_at。
如果客户使用了 Apple 隐私邮箱、团队邮箱别名或旧邮箱购买，magic link 可能发到他们没留意的地址。此时不要手工替客户改邮箱后立刻退款，先找到 customer、subscription 和 transaction 是否属于同一个 email。
后台该看 subscription、transaction 还是 invoice？
订阅争议不能只看一个页面。subscription 回答「以后还会不会续费」，transaction 回答「这笔钱有没有形成财务记录」，invoice 回答「客户拿到的付款或请款凭证是什么」。
处理顺序可以这样定：
- 打开 Paddle > Customers，按客户邮箱找 customer。
- 进入对应 subscription，看
status、scheduled_change、next_billed_at和当前 billing period。 - 找到最近一笔 transaction，看
status、collection_mode、金额、税额和invoice_number。 - 如果客户已经付款，再判断是否创建 refund adjustment；如果是未付款的手工 invoice，再判断 credit 或 cancel invoice。
团队在旅行、共享办公室或远程客服排班时，最怕 Paddle、邮箱和 CRM 一会儿在个人电脑登录，一会儿换到临时网络。可以把账单、退款和工单后台固定给一名负责人，用独立开发者出海稳定专线承载这类核心后台操作；它只能减少登录环境干扰，不能替代 Paddle 里的 transaction 证据。
退款、credit note 和发票证据怎么摆给客户？
Paddle 的 refund 和 credit 都走 adjustment，但目的不同。refund 是把已收款项退回；credit 是减少已开具 invoice 的应收金额或记入客户余额。Paddle 会为 refund 或 credit 生成 credit note PDF，原 transaction 本身仍保留。
| 动作 | 常见前提 | 给客户的证据 | 不要承诺什么 |
|---|---|---|---|
| refund | 自动收款 transaction 已 completed | adjustment id、金额、credit note PDF | 不承诺银行或 PayPal 的具体到账日 |
| credit | 手工 invoice 已 billed 或 past_due | credit note PDF、更新后的欠款金额 | 不说等同现金退款 |
| cancel invoice | manual transaction 为 ready 或 billed | canceled 状态、失效的付款链接 | 不说 subscription 也自动取消 |
| revise transaction | 客户地址、business 或税号要修正 | revised invoice PDF | 不替客户确认税务抵扣 |
金额、税额或公司抬头错了，不要在邮件里手改 PDF。Paddle 文档把已 billed 或 completed 的 transaction 当作财务记录处理；要改客户信息，走 revise transaction，要改金额，走 adjustment。
客户证据表怎么写才够用？
客服最省时间的不是写长邮件，而是把争议压成一张表。客户看到证据后，通常会从「你们又扣费」变成「这笔是取消前的账期」或「这张 invoice 需要补公司税号」。
| 证据项 | 从哪里拿 | 写给客户时怎么说 |
|---|---|---|
| 客户邮箱 | Customer 详情页 | 这笔订阅绑定在某个邮箱下 |
subscription_id | Subscription 详情页或 API | 说明是哪一个计划，不混同团队其他席位 |
scheduled_change.effective_at | Subscription 详情页或 webhook | 说明取消生效时间 |
next_billed_at | Subscription 详情页 | 判断未来是否还会续费 |
transaction_id | Transactions 列表 | 说明争议对应哪一笔付款 |
invoice_number 和 invoice PDF | Transaction invoice API | 给报销或财务记录使用 |
adjustment_id 和 credit note | Adjustment 详情页 | 说明退款或 credit 已如何记录 |
表格里不要写客户完整卡号、完整地址或无关身份资料。能用 Paddle ID 和金额说明的，就不要把个人信息贴进客服工单。
哪些情况该停下来让财务或税务顾问看？
只要客户问「这张 invoice 能不能报销」「VAT/GST 是否能抵扣」「公司抬头改完是否等于重开发票」，客服都不要下税务结论。你可以提供 Paddle 生成的 invoice PDF、revised invoice PDF 或 credit note PDF，但不要替客户判断当地税法。
如果客户已经发起 card dispute 或 PayPal dispute，先把 transaction、refund adjustment、credit note 和邮件时间线整理好，再进争议平台回复。退款和争议并行时，某些支付方式可能会让处理链路变复杂，客服不要承诺「今天一定到账」。
如果相关金额超过你的内部授权阈值，比如年付企业席位或多 seat 账单，先暂停口头承诺。让财务负责人看 invoice、税额、退款金额和服务实际交付日期，客服只负责同步 Paddle 后台状态。