- 费用与税费处理——谁承担税费、 每种模式下向客户收取什么，以及税费如何出现在您的 结算文件中。
- 优惠券与促销码—— 折扣引擎端到端：定义优惠券、发放促销码、核销记录、 数据分析、账户级上限。
- Point Topup 分销商 API——六个 分销商接口、目录与定价字段、订单状态。
我分几次退了一笔订单，每次退回多少税？
每次退款按其在订单中自己的份额计算税费——最后一次 除外，它会被修正以使总额精确对平。 原因是取整。每次计算税费都取整到两位小数，所以 多次部分退款下，各次单独计算的税费之和 可能比原支付实际收取的税费偏高或偏低。放任不管， 分四次全额退款的客户可能拿回比所付多一分， 或少一分。 所以最后一次退款不是计算的——而是推导的：
“耗尽订单”指已做的退款加上这一次达到或超过
原订单金额。失败的税费退款不计入累计总额，所以
在税费侧失败的退款不会侵蚀余额。并且如果
减法结果为负，金额会被置底为零，而不是允许
走向错误方向。
这保证的性质：**以任意次数全额退款一笔订单，
您拿回的税费恰好等于所收取的税费。**没有任何方向的累积
取整漂移。
如果我的退款加起来超过原订单怎么办？
超出部分不退。在计算任何税费之前，退款的计税 基数会按剩余额度截断：
第三行是需要规划的：一旦订单的税费已全额退还，
针对它的额外退款活动不再产生税费
退还，静默进行，没有错误。不会多退，但也没有任何东西
告诉您税费部分为零。如果您在对账税费，请对照
原支付的税费数字对账，而不是把每次退款看似冲回的税费加总。
拒付退税和退款一样吗？
它走同样的累计核算——拒付和退款共用 一个针对原支付的累计总额，所以拒付像退款一样消耗 剩余可退税费，最后一笔的修正应用于两者中 最后落地的那个。 默认值上有一个区别：拒付默认视为全额。 发生部分拒付时，金额必须显式提供； 没有提供则冲回的是原金额全额。 拒付对您其余资金的影响——费用、结算、争议 金额——是另一个主题： 费用与税费处理。我的订单税费算不出来，订单被拒了吗？
取决于原因，两种结果相反：
所以”税费计算失败”不是单一行为。降级路径为
税费对您该订单确实不适用的情形而存在，且
有意静默：降级的订单看起来像普通的不含税订单，
没有填充任何税费字段。它不是您会看到的错误。
邮编情形是您集成中值得处理的，因为它
由您发送的数据引起且可修复。邮编无法对应其国家
的地址——错位的编码、国家不匹配、
该国不使用的邮编格式——会让订单失败而不是
降级。如果您自己收集地址，请在创建订单前按国家校验
邮编；如果由收银台页面收集，会提示
客户修正。
超时时还有短暂重试，所以一次缓慢的计算本身不会
让您的订单失败。
为什么我的订单完全没有计算税费？
因为税务安排是按国家持有的，不是按账户。有一个 不等于有全部。 对于您没有安排的国家的订单，没有可据以计算的东西， 所以计算报告一个可降级失败，订单 不含税继续。那是正常的、预期的路径——不是配置错误。 按国家模型的另外两个性质解释了原本令人费解的 行为：- 计算税费所需的输入和汇缴税费所需的输入是 两个不同的集合，按国家分别定义。因此一笔订单可能 携带计算税费所需的一切，却在汇缴目的上 仍不完整，或反过来。某国家要求哪些字段来自您的 安排，而不是一个通用列表。
- 决定税费的国家不一定是缴纳税费的地方。 两者都按安排记录，可以不同。
为什么我的核销记录还是 CREATED？
因为它所属的订单尚未到达最终状态。折扣
记录在创建订单时预留，之后才确认，这意味着
CREATED 对进行中的订单是正常的，不是卡住的记录。
记录随订单推进：
值得据此设计的后果：
- **
CREATED预留占用库存。**被放弃的收银台会占用其名额直到 订单关闭。如果限量优惠券看起来已用完，而您的核销 历史显示的已确认使用少于上限，未关闭的预留通常就是差额。 - **只有
COMPLETED计数。**数据分析统计已确认的核销，所以 其他任何状态的记录都不会出现在您的折扣报表中。 - **记录可能在您的订单从未存在的情况下被作废。**当创建订单
在折扣预留之后、订单持久化之前失败时，
预留仍会释放——您会看到一条背后没有订单的
VOIDED记录。那是清理，不是幽灵订单。
退款会把核销名额还回来吗？
只有全额退款会，且仅在账户的冲回策略下。 部分退款让记录保持COMPLETED，名额保持已消耗。
理由是部分退款并未撤销购买，所以
折扣仍然被使用了。实际影响是，用 ONCE 优惠券购买
并部分退款的客户不会拿回优惠券。
策略设置、零金额订阅试用对名额的影响，以及
为什么冲回永远不会把计数器推成负数，都在
优惠券与促销码中说明。
客户能在一笔订单上叠加两个折扣吗？
不能。**一笔订单只带一个折扣。**没有任何方向的叠加： 您不能对已有折扣的订单应用第二个折扣， 客户也不能对您已折扣的订单再加一个。 三条独立规则强制执行，各有不同信息：
三者都以
A0003 返回，具体信息在响应中携带——
A0003 详情的格式见
读懂您的支付方式配置。
如果您商业上需要”同时两个优惠”，那是一张按合并价值配置的
优惠券，不是一笔订单上两张优惠券。
“discount calculation result has expired” 是什么意思？
您被报出的折扣金额是有时效的，而您用一个过期的结果 去创建订单。 计算折扣和创建订单是两步：计算 返回客户将支付的金额，创建订单引用该结果。 如果两步之间间隔太久——客户把页面开着不动、收银台 流程跨会话持有报价——被引用的结果不再 被接受，订单被拒绝，并附带让您重新计算的信息。 重新计算就是修复，且应该自动进行：遇到该错误时，重新运行 折扣计算并对新结果创建订单。不要把它 当作优惠券问题，也不要向客户显示折扣失败—— 优惠券没问题，只是您的报价过期了。请准备好重新计算的 金额可能不同，因为资格会重新检查：期间 达到核销上限的码现在会被直接拒绝。哪些折扣错误说明是我的设置问题，而不是客户的问题？
这些在创建订单时返回，全部以A0003。区分很重要，因为
一半是您要修的，一半只是优惠按配置
正常工作：
第一行是最浪费时间的，因为它看起来像优惠券
问题：您创建的每张优惠券在 Portal 中都显示有效，却在
创建订单时被拒绝。如果什么都不打折，先检查总开关再检查
优惠券。
完整的资格判定顺序，包括依赖您发送客户标识符的
按客户和仅首次规则，在
优惠券与促销码中。
未支付的 Point Topup 订单占用库存多久？
不是无限期。创建 Point Topup 订单会预留其所需的库存， 如果订单始终未支付，该预留会在一个默认保留期后 自动释放（这是运营设置，不是合同条款——不要 基于它做倒计时）。 两个后果：- **未支付订单不是您可以依赖的占位。**如果您在支付前 预先创建订单，或让客户稍后再来支付，届时商品可能 已不可用。在可用性重要时，请及时支付而不是 提前创建订单。
- **释放的库存不会复活订单。**订单保持 原状态；释放预留让商品可供其他买家购买， 不会在您这边取消或重新定价任何东西。
一笔 Point Topup 订单能带多个商品吗？
不能。一笔 Point Topup 订单恰好带一个 SKU，数量为一。其他 任何数量在创建时都会被拒绝。 要购买多个商品，请创建多笔订单。每笔都有自己的幂等键、 自己的预留和自己的结果，这通常也是您想要的： 一个商品失败不会连带其他商品。 另请注意，此类订单的PAY_SUCCESS 状态表示支付
成功且履约由您完成——Waffo 不交付该
SKU。不要把 PAY_SUCCESS 读作”客户已拿到商品”。字段
参考和其他状态见
Point Topup 分销商 API。