管理服务的退款和退单拒付
使用追回退还服务，合作伙伴服务可以收到有关其易耗品和应用商店管理的订阅的退款、退货和退单拒付事件通知。
这允许合作伙伴服务实现逻辑，帮助防止和缓解欺诈性交易和退款请求带来的收入损失。
以下信息基于最新版本的追回退还服务，这是针对所有服务的建议方法。
退款易耗品和商店管理的订阅存在风险和欺诈可能性
Microsoft Store 允许用户通过其帐户的订单页面 (https://account.microsoft.com/billing/orders/) 要求数字购买内容的退款或退货。 自动系统允许用户每年收到一定数量的自动退货，前提是满足一定的条件，例如是在退货请求后短时间内购买的。 否则，只有在某些情况下，Microsoft 的客户支持团队才会进行数字物品的退款或退货。
如果易耗品尚未使用或其数量尚未消耗，则将自动从用户余额中删除已退款购买项的数量。 但是，如果在退货前已完成或已消耗物品，则用户的余额永远不会低于 0。 这样的话，当游戏服务消费物品，并且用户收到退款时，用户获得的是游戏内货币点数。 这可能会导致与购买易耗品、在游戏中进行兑换，然后发起退款的易耗品滥用和欺诈行为。
同样，应用商店管理的订阅受要求完全或部分退款的不同区域法律的约束。
根据退款类型，游戏开发人员或发布者可能需要不同的吊销操作。
因此，建议合作伙伴使用追回退还事件服务来检测这些方案，管理和保护易耗品和应用商店管理的订阅的收入流。
利用 Microsoft.StoreServices .NET 库和示例
为了帮助演示本文概述的原则和流程，请查看提供以下内容的 Microsoft.StoreServices 示例：
使用 Microsoft.StoreServices 库管理身份验证并调用 Microsoft Store 服务。
示例逻辑，用于管理易耗品、跟踪待处理的消费请求、核对退款的购买内容、续订过期的用户 Store ID 等。
配置指南，其中包括本文中有关如何为此身份验证方法配置和设置 Microsoft Entra ID 的步骤。
追回退还事件队列
追回退还事件服务基于将事件消息写入为服务的 Entra 应用程序客户端 ID 配置的 Azure 存储队列。
通过 Microsoft Store 服务处理退款、退货或退单拒付时，事件几乎立即写入队列。
因此，这允许服务定期查询整个产品目录中任何最近的追回退还事件，并在系统中协调这些事件。
目前，追回退还事件服务队列支持以下产品类型：
| 产品类型 | ProductKind 值 |
|---|---|
| Microsoft Store 管理的易耗品 | Consumable |
| 开发者管理的易耗品 | UnmanagedConsumable |
| Microsoft Store 管理的订阅 | Pass |
必需的载入和设置
载入追回退还事件队列需要 Microsoft Store 服务团队配置 Azure 存储队列。 Microsoft 将承担队列的托管成本和管理。
若要为自己设置追回退还事件队列，请联系你的开发人员合作伙伴经理或 Microsoft 联系人。 请求队列的设置时，必须提供以下内容：
- 服务将用于进行身份验证以及产品在合作伙伴中心关联的 Entra 应用程序客户端 ID。
- 主要队列的首选地理 Azure 数据中心。 这不是必需的，因为队列可在全球范围内访问，但如果接近自己的服务，则可提供更好的延迟。
提交后，可能需要 1-2 周才能部署队列设置。
访问追回退还事件队列
为了访问回退事件队列，服务使用从服务的 Entra ID 凭据生成的服务访问令牌从 purchase.mp.microsoft.com/v8.0/b2b/clawback/sastoken 获取 SAS 令牌。 SAS 令牌的生存期有限，但服务可以随时请求新的 SAS 令牌。
返回的 SAS 令牌 uri 参数表示追回退还队列的 URI 地址，以及向该队列进行身份验证所需的参数。
但是，若要对队列执行查询和操作，URI 需要添加下面概述的内容，具体取决于要执行的操作。
处理队列中的追回退还消息
使用修改后的 SAS 令牌 uri 参数，服务可以使用以下任一项与追回退还队列交互：
追回退还队列中的每个条目都作为消息写入，其中包含作为这些消息的一部分提供的追回退还事件的详细信息。
若要管理队列上的消息，服务可以通过将以下参数添加到 URI 来执行这些操作：
| 操作 | 添加 URI | 其他参数 | 说明 |
|---|---|---|---|
| 速览 | /messages | peekonly=true | 从队列前面检索一条或多条消息，但不会更改消息的可见性。 |
| 获取 | /messages | 无 | 从队列前面检索一条或多条消息，并设置其可见性超时（默认值为 30 ），使其在超时后才会再次返回。 |
| 删除 | /messages/（来自队列的消息 ID） | popreceipt=（队列消息中的值） | 从队列中永久移除目标消息。 |
使用“获取”操作从队列中检索消息时，它会对返回的消息设置可见性超时（默认值为 30 秒）。 这样可以防止在可见性超时之前处理的消息显示在后续的“获取”操作中。 另一方面，“速览”操作未设置可见性超时，这些消息对所有后续“速览”或“获取”请求都可见。 但是，要从队列中删除消息，需要 popreceipt 值，该值仅在使用 Get 操作的消息中返回。
消息处理的建议流是：
- 从队列中获取消息（或消息集）。
- 从每条消息中提取追回退还事件信息。
- 检查已完成的交易数据库中是否存在与追回退还事件具有相同 ProductId、OrderId 和 LineItemOrderId 的任何匹配交易。
- 从完成的交易中核对系统中向用户授予的商品。
- 将自己的数据库中的交易设置为“已核对”。
- 从消息队列中删除消息。
Get 或 Peek 函数的响应将是具有以下格式的 QueueMessage 项的 XML 列表：
<QueueMessagesList>
<QueueMessage>
<MessageId>string-message-id</MessageId>
<InsertionTime>insertion-time</InsertionTime>
<ExpirationTime>expiration-time</ExpirationTime>
<PopReceipt>opaque-string-receipt-data</PopReceipt>
<TimeNextVisible>time-next-visible</TimeNextVisible>
<DequeueCount>integer</DequeueCount>
<MessageText>message-body</MessageText>
</QueueMessage>
</QueueMessagesList>
QueueMessage 结构
| 参数 | 类型 | 说明 | 必需 |
|---|---|---|---|
MessageId |
GUID |
队列中消息的唯一 ID。 | 是 |
InsertionTime |
datetime |
消息插入队列的 UTC 日期和时间。 | 是 |
ExpirationTime |
datetime |
将从队列中自动删除消息的 UTC 日期和时间。 | 是 |
PopReceipt |
string |
在删除操作中用于从队列中移除消息。 | 否 |
TimeNextVisible |
datetime |
消息将在队列中再次显示的 UTC 日期和时间。 | 是 |
DequeueCount |
int |
消息取消排队的次数（使用 Get API 从队列中拉取）。 | 是 |
MessageText |
string |
Base64 编码字符串，它是追回退还事件的 JSON 结构 | 是 |
追回退还事件结构
队列中的每条消息在 MessageText 中都有编码的 JSON 字符串，该字符串表示具有以下参数的追回退还事件：
| 参数 | 类型 | 说明 | 必需 |
|---|---|---|---|
id |
GUID |
追回退还事件的唯一 ID。 | 是 |
source |
string |
触发事件的源服务。 | 是 |
type |
string |
数据字段的对象格式。 这应为 ClawbackEventContractV2。 | 是 |
data |
ClawbackEventContractV2 |
ClawbackEventContractV2，该对象包含与 Clawback 事件影响的 Order 相关的数据。 | 是 |
time |
datetime |
创建事件的 UTC 日期和时间。 | 是 |
specversion |
string |
合同版本。 应为 1.0。 | 是 |
datacontenttype |
string |
数据参数的格式。 这应为 application/json。 | 是 |
subject |
string |
追回退还服务用于日志记录的其他信息。 | 是 |
traceparent |
string |
追回退还服务用于日志记录的其他信息。 | 是 |
追回事件源值
| 值 | 说明 |
|---|---|
/Purchase/Refund |
事件源自通过 Microsoft 客户支持或 Xbox 支持退货请求站点处理的退货或退款。 |
/Purchase/Chargeback |
事件源自付款机构对订单的退单拒付或退单拒付撤销。 这可以是银行、信用卡退单拒付等。 |
ClawbackEventContractV2 结构
| 参数 | 类型 | 说明 | 必需 |
|---|---|---|---|
lineItemId |
GUID |
确定易耗品采购订单中的细列项目 (对于购物车场景，订单可以有多个 lineItemId)。 | 是 |
orderId |
GUID |
确定产品在用户购买时所属的采购订单。 | 是 |
productId |
string |
在 Microsoft Store 目录中也称为产品的 Store ID。 产品的示例 Microsoft Store ID 为 9NBLGGH42CFD。 | 是 |
productType |
string |
指示产品类型。 有关详细信息，请参阅产品类型值和意义。 | 是 |
purchasedDate |
datetime |
已购买商品的 UTC 日期和时间。 | 是 |
eventDate |
datetime |
已退回或退款商品的 UTC 日期和时间。 | 是 |
sandboxId |
string |
产品购买内容绑定的沙盒。 最终用户的生产环境为“零售”。 | 是 |
eventState |
string |
此特定的追回退还事件的状态。 请参阅 追回退还事件状态。 | 是 |
skuId |
string |
如果 Microsoft Store 目录中有多种产品/服务，则为特定的 SKU 标识符。 SKU 的示例 Microsoft Store ID 为 0010。 | 是 |
subscriptionData |
ClawbackEventSubscriptionData |
如果订单针对订阅产品，则返回ClawbackEventSubscriptionData对象。 这包含与受追回退还事件影响的订阅订单相关的数据。 | 否 |
追回退还事件状态
| 值 | 说明 |
|---|---|
Revoked |
已退还用户款项，并尝试撤销用户权利，但未成功。 对于易耗品，这表示在退货之前服务已履行该商品。 需要与自己的记录和数据进行核对。 请参阅协调易耗品追回退还事件 |
Returned |
已退还用户款项，且已从其帐户中删除其权利。 无需核对服务。 对于易耗品，这表示服务尚未履行购买的商品。 |
Refunded |
已退还用户款项，但允许他们保留对产品的权利。 无需核对服务，但应跟踪此用户帐户，频繁发生此类型的事件可能表明存在欺诈行为。 |
ChargebackReversal |
此项目最初报告为因付款工具（信用卡、银行等）发起的退单而被撤销或退回。 Microsoft 进行了退款申诉，并申诉成功。 该项目的费用已退还到 Microsoft，并且项目状态已还原到用户的帐户。 有关退单拒付的信息，请参阅退单拒付和退单拒付撤销。 此外，有关开发管理的易耗品与应用商店管理的易耗品的特定行为，请参阅退单拒付撤销期间开发托管易耗品的唯一行为。 |
ClawbackEventSubscriptionData 结构
| 参数 | 类型 | 说明 | 必需 |
|---|---|---|---|
recurrenceId |
string |
用户订阅期间的唯一 ID，可与订阅管理 API 一起使用。 | 是 |
durationIntervalStart |
datetime |
与采购订单关联的订阅间隔开始的 UTC 日期和时间。 | 是 |
durationInDays |
int |
订单中为订阅间隔购买的天数。 | 是 |
consumedDurationInDays |
int |
已使用且未退款/返回给用户的天数。 | 是 |
追回退还事件示例
{
"id": "5ef37bd1-8b4b-48c4-9b67-be458d8ab9de",
"source": "/Purchase/Refund",
"type": "ClawbackEventContractV2",
"data": {
"lineItemId": "230e9063-bffe-411a-8aa1-6f99ca091452",
"orderId": "70fd35f2-7e4a-4f27-8df3-a673a5a4d9d9",
"productId": "9N0297GK108W",
"productType": "UnmanagedConsumable",
"purchasedDate": "2023-01-24T21:59:19.5725585+00:00",
"eventDate": "2023-01-26T08:18:52.246847+00:00",
"eventState": "Revoked",
"sandboxId": "XDKS.1",
"skuId": "0010"
},
"time": "2023-01-26T08:18:56.7103057+00:00",
"specversion": "1.0",
"datacontenttype": "application/json",
"subject": "/Purchase/Refund/907eb4af-57bf-4ff6-b040-e9296d169436",
"traceparent": "00-6d2a86a53e8cae15cddaadc43f4d9670-4821cba073c416c1-00"
}
退款与退货
当事件来自 /Purchase/Refund 源时，这表示事件与客户 refund 或 return 请求关联。
这两个术语有时被当作同义词使用，但在 Microsoft Store 服务中，它们各自都有独特的行为，应由你的服务来处理。
在这两种情况下，用户都会收到订单返还的付款，但在如何处理从购买中获得的权利或数目方面有所不同。
退货操作将尝试从用户帐户中移除权利或数目。
但是，退款会导致用户帐户保留购买的权利或数目。
向 Microsoft 客户支持或通过自动化工具发出的请求通常被视为退货请求。
但是，在极少数情况下，根据与客户问题相关的情况，作为一种“弥补”姿态，事件状态可能是 Refund，以努力提供积极的客户服务。
如果有迹象表明购买将被报告为退款，则 Refund 状态也可用于向客户主动退款，以避免退单拒付处理费。
服务应检查 eventState 值，并遵循追回退还事件状态中概述的每个值的核对建议。
有关示例场景，请参阅易耗品的追回退还退货状态行为和应用商店管理的订阅产品的追回退还退货行为
退单拒付和退单拒付撤销
当事件来自 /Purchase/Chargeback 源时，这表示付款机构撤销了订单费用并退还了付款。
退单拒付的常见原因之一支付工具存在欺诈性费用争议。
发生退单拒付事件时，追回退还服务将根据从用户帐户中移除权利或数目的尝试，以 Revoked 或 Returned 状态报告该事件。
在事件发生时，服务应使用与 /Purchase/Refund 中的事件相同的核对操作来处退单拒付事件。
如果认为购买看起来合法且已有使用数量，Microsoft 通常会根据我们提供的信息对退单拒付申请提出申诉。
如果申诉成功，则款项将发送回 Microsoft，并且将在追回退还队列中记录 ChargebackReversal 事件。
此事件将具有与初始退单拒付事件相同的 OrderID。
发生 ChargebackReversal 时，已购买的项目将恢复到用户的帐户。
因此，由于付款已经恢复，服务器在撤销或移除购买的物品方面所采取的任何行动都应该撤销。
退单拒付和退单拒付撤销的时间线可能会有所不同。 退单拒付通常在购买后的 90 天内触发，但有些可能会在购买后 180 天内触发。 如果 Microsoft 对退单拒付提出申诉，整个过程和最终的申诉结果可能需要 3 - 6 个月的时间。
协调易耗品追回退还事件
当检测到已完成或消耗的物品的追回退还事件时，开发团队或发布者可自由决定用户帐户上的正确操作步骤。 下面列出了一些可能的操作，但不仅限于这些。
- 如果可能，请从用户的剩余余额中移除等效的易耗品值（通常为游戏内货币）
- 如果无法从剩余余额中移除数量，则移除在游戏中使用易耗品值购买的最新物品
- 暂时不对用户采取任何措施，但跟踪其帐户，查看这是否属于可能的欺诈或滥用退货模式（例如：购买大量消耗品，然后在游戏中消耗后退回）。
建议你将所采取的核对操作和原因通知用户，并将此信息记录在你的服务中，以避免进一步的客户支持电话或纠纷。 示例：“由于通过 Microsoft 向你的帐户发出退货，我们已从帐户余额中删除了 [product] 的 [数量]。
管理易耗品追回退还事件的要求
若要正确管理和核对与应用商店管理的的易耗品和开发管理的易耗品相关的事件，服务必须跟踪每个消耗事务，并将 includeOrderIds 参数用作 TRUE。
此参数返回与购买订单以及用于满足消耗请求的订单和数量相关的 ID。
这些相同的 OrderID 在追回退还事件中提供，这些事件随后可用于搜索和确定需要根据事件中的数据核对自己数据库中哪些消耗事务和用户。
有关跟踪服务中消耗事务的建议和流程的详细信息，请参阅管理服务中的易耗品
易耗品的追回退还退货状态行为
| 易耗品类型 | 已耗用 | eventStatus | 影响用户对易耗品的权利 | 针对开发人员服务的建议操作 |
|---|---|---|---|---|
Store-managed |
否 | Return |
Qty 将减少购买所授予的金额。 例如：退回前数目 = 1，事件后数目 = 0。 | 无操作，未消耗物品。 |
Store-managed |
是 | Revoked |
Qty 不会减少，因为该物品以前已消耗/已完成。 例如：退回前数目 = 0，事件后数目 = 0。 | 在已完成的事务数据库中搜索匹配的 OrderID、LineItemID 和 ProductID。 从游戏服务器上跟踪的用户余额中撤销购买价值。 |
Dev-managed |
否 | Return |
Qty 将减少购买所授予的金额。 例如：退回前数目 = 1，事件后数目 = 0。 | 无操作，未消耗物品。 |
Dev-managed |
是 | Revoked |
Qty 不会减少，因为该物品以前已消耗/已完成。 例如：退回前数目 = 0，事件后数目 = 0。 | 在已完成的事务数据库中搜索匹配的 OrderID、LineItemID 和 ProductID。 从游戏服务器上跟踪的用户余额中撤销购买价值。 |
易耗品的追回退还退款状态行为
退款事件状态是一种特殊情况，用户可获得退款，但同时保留物品的权利。 有两种主要情况会导致此事件状态：
- 客户服务发放的退款，作为对用户的不便或导致退款的问题的“补偿”。
- 当购买很有可能被报告为退款时，主动发放退款。 这可以避免在处理可能的退单拒付事件时产生额外的费用和资源成本。
因此，当你看到退款事件状态时，正确的操作是使用服务中链接的帐户信息记录该事件。 然后，观察单个帐户上的模式或重复的退款事件状态，这些模式或状态指示该帐户可能存在欺诈或滥用行为。
| 易耗品类型 | 已耗用 | eventStatus | 影响用户对易耗品的权利 | 针对开发人员服务的建议操作 |
|---|---|---|---|---|
Store-managed |
否 | Refund |
数目未减少 | 无吊销操作，允许用户保留权利，但记录事件和任何链接的用户信息以留意重复模式 |
Store-managed |
是 | Refund |
数目未减少 | 无吊销操作，允许用户保留权利，但记录事件和任何链接的用户信息以留意重复模式 |
Dev-managed |
否 | Refund |
数目未减少 | 无吊销操作，允许用户保留权利，但记录事件和任何链接的用户信息以留意重复模式 |
Dev-managed |
是 | Refund |
数目未减少 | 无吊销操作，允许用户保留权利，但记录事件和任何链接的用户信息以留意重复模式 |
易耗品的追回退还退单拒付行为
| 易耗品类型 | 已耗用 | eventStatus | 影响用户对易耗品的权利 | 针对开发人员服务的建议操作 |
|---|---|---|---|---|
Store-managed |
否 | Return |
Qty 将减少购买所授予的金额。 例如：退回前数目 = 1，事件后数目 = 0。 | 无操作，未消耗物品。 |
Store-managed |
是 | Revoked |
Qty 不会减少，因为该物品以前已消耗/已完成。 例如：退回前数目 = 0，事件后数目 = 0。 | 在已完成的事务数据库中搜索匹配的 OrderID、LineItemID 和 ProductID。 从游戏服务器上跟踪的用户余额中撤销购买价值，然后更新跟踪数据库条目以记下这是退单拒付 |
Dev-managed |
否 | Return |
Qty 将减少购买所授予的金额。 例如：退回前数目 = 1，事件后数目 = 0。 | 无操作，未消耗物品。 |
Dev-managed |
是 | Revoked |
Qty 不会减少，因为该物品以前已消耗/已完成。 例如：退回前数目 = 0，事件后数目 = 0。 | 在已完成的事务数据库中搜索匹配的 OrderID、LineItemID 和 ProductID。 从游戏服务器上跟踪的用户余额中撤销购买价值，然后更新跟踪数据库条目以记下这是退单拒付 |
易耗品的追回退还退单拒付撤销行为
| 易耗品类型 | 已耗用 | eventStatus | 影响用户对易耗品的权利 | 针对开发人员服务的建议操作 |
|---|---|---|---|---|
Store-managed |
否 | ChargebackReversal |
来自退单拒付的 Qty 将还原到用户 Qty，因为在退单拒付事件之前没有消耗。 例如：撤销前数目 = 0，撤销后数目 = 1。 | 应按照正常的查询流查看和消耗 Qty。 在已完成的事务数据库中搜索匹配的 OrderID、LineItemID 和 ProductID。 如果找不到匹配项，或者记录未指示它经历了退单拒付，则不执行任何操作。 |
Store-managed |
是 | ChargebackReversal |
来自退单拒付的 Qty 不会还原到用户 Qty，因为在退单拒付事件之前已有消耗。 例如：撤销前数目 = 0，撤销后数目 = 0。 | 在已完成的事务数据库中搜索匹配的 OrderID、LineItemID 和 ProductID。 如果找到匹配项，并且其在系统中记录为退单拒付，请撤消之前对用户余额执行的退单拒付操作。 然后更新跟踪项，以记录已撤消退单拒付。 |
Dev-managed |
否 | ChargebackReversal |
来自退单拒付的 Qty 将还原到用户 Qty，因为在退单拒付事件之前没有消耗。 但数量永远不会显示大于 1，请参阅下面的注意。 | 请参阅下面的注意。 |
Dev-managed |
是 | ChargebackReversal |
来自退单拒付的 Qty 恢复为用户的 Qty，即使其已被消耗。 请参阅下面的注意。 | 请参阅下面的注意。 |
注意
开发管理的易耗品具有独特的退单拒付撤销行为，并且需要其他逻辑来处理这些事件。 有关详细信息，请参阅下文。
退单拒付撤销期间开发管理的易耗品的独特行为
无论是否在退单拒付事件之前消耗了开发管理的易耗品，如果发生退单拒付撤销，则购买中的易耗品数量将重新添加到用户的帐户余额中。 但是，即使开发管理的易耗品具有多个有效权利，开发管理是易耗品也绝不会报告大于 1 的数量。 这是因为开发管理的易耗品旨在阻止用户再次购买易耗品，直到游戏服务将其报告为已消耗/已完成。 在发生退单拒付撤销时，如果用户帐户余额已经不为零，则多个权利仍然有效，并且可以正常单独使用。 请注意，在每次使请求后，用户的余额将保持为“1”，直到所有活动权利都已使用/完成。 因此，系统应正常经历使用流，直到开发管理的易耗品的用户余额报告为“0”。
使用时，如果看到与同一 OrderID、LineItemID 和 ProductId 匹配的记录，请检查该记录是否被标记为正在进行退单拒付核对。
如果已在退单拒付中将其标记为已核对，请撤消对用户帐户余额执行的操作，并将该物品标记为退单拒付撤销。
示例：在撤销之前，Qty = 1，撤销后 Qty = 1，但实际上有 2 个活动权利。 服务消耗 1 件易耗品，使用后用户的数量仍为“1”。 服务再消耗 1 个易耗品，用户的数量现在报告为“0”。
应用商店管理的订阅产品的退单拒付行为
检测到应用商店管理的追回退还事件后，会通过ClawbackEventSubscriptionData 结构将与订阅相关的附加信息添加到追回退还事件中。 具体而言，是否向用户发放了相应订阅间隔的完全或部分付款。 如果订阅向用户帐户授予每月游戏内奖励或货币，你可能希望撤销这些奖励，具体取决于退款与保留款项的天数。
[NOTE!] 收到应用商店管理的订阅追回退还事件后，开发团队和发布者可以自由确定用户帐户的正确操作步骤。 如果采取操作撤消任何物品或权益，建议将所采取的核对操作和原因通知用户，并将此信息记录在你的服务中，以避免进一步的客户支持电话或纠纷。 示例：“由于通过 Microsoft 向你的帐户发出退货，我们已调整了你的 [订阅产品] 权益。”
应用商店管理的订阅产品的追回退还行为
| eventStatus | 方案 | 针对开发人员服务的建议操作 |
|---|---|---|
| Revoked | 订阅间隔包括已使用的天数，订阅权利已从用户帐户中删除。 | 验证退款是部分还是完全退款。 采取适当操作撤消尚未支付的权利，或根据保留的部分付款金额授予部分值。 |
| 返回 | 尚未使用/启动的即将开始的订阅间隔已从用户帐户中删除。 | 无操作，间隔未启动。 |
| 退款 | 当前活动订阅间隔的付款已发回给用户。 | 无吊销操作，允许用户保留权利，但记录事件和任何链接的用户信息以留意重复模式。 使用定期服务遵循正常状态和逻辑。 请参阅通过服务管理订阅产品。 |
| ChargebackReversal | 已将之前“已撤销”状态的订阅间隔还原到用户帐户。 | 在物品核对为已撤销后，撤销采取的任何操作。 遵循定期服务报告的订阅状态的正常状态和逻辑。 请参阅通过服务管理订阅产品。 |
完全和部分退款的示例 ClawbackEventSubscriptionData
场景：每月订阅，用户已于 2023 年 7 月 6 日收到按比例（部分）退款。 用户被退回了 25 天未使用的价格，Microsoft 保留了已使用 6 天的剩余价格。
"subscriptionData": {
"recurrenceId": "mdr:0:ae5cad80acf2428fa64c38529996a3fd:df3763c2-36f8-4bde-8fa5-a29fb6058d62",
"durationIntervalStart": "2023-07-01T00:00:00+00:00",
"durationInDays": 31,
"consumedDurationInDays": 6,
"refundType": "Partial"
}
场景：每月订阅，用户已于 2023 年 7 月 6 日收到全额退款。 用户被退回了为当月订阅支付的全价，Microsoft 未保留任何付款。
"subscriptionData": {
"recurrenceId": "mdr:0:0dc7194514404dd3bf0f678e21716774:23a454d5-f240-4dad-9923-9c3f53f515cc",
"durationIntervalStart": "2023-07-01T00:00:00+00:00",
"durationInDays": 31,
"consumedDurationInDays": 6,
"refundType": "Full"
}
场景：年度订阅，用户已于 2024 年 1 月 15 日收到按比例（部分）退款。 用户被退回了 199 天未使用的价格，Microsoft 保留了已使用 168 天的剩余价格。
"subscriptionData": {
"recurrenceId": "mdr:0:9ed0a48236404b78a017e9e226da94c6:22aa4f3c-1ffc-4dd3-8801-cb2a227a5c46",
"durationIntervalStart": "2023-07-31T00:00:00+00:00",
"durationInDays": 367,
"consumedDurationInDays": 168,
"refundType": "Partial"
}
[NOTE!] 以上示例的年度订阅持续时间 天数为 367 而不是 365。 添加一天是因为 2024 年是闰年，又添加一天是为了将用户的续订日期移到下个月的 1 号，以避免一些月份没有 29 日、30 日或 31 日的问题。 有关详细信息，请参阅了解订阅启动、续订和过期日期。
在后一个示例中，保留追回退还事件之前的付款。 如果订阅授予了每月奖励或游戏内物品，建议确保用户在该时间段内保留授予他们的物品。
在开发沙盒中测试产品退货
沙盒的开发帐户无权访问 support.xbox.com 上的自动产品退货请求工具。 因此，要测试退货场景和追回退还实现，需要在Microsoft 开发人员帐户管理员或 Microsoft 联系人的帮助下，通过执行以下操作请求退货以测试购买内容：
- 验证测试产品设置为非零价格（0.01 美元已足够）。
- 使用测试帐户登录到开发沙盒。
- 在测试帐户上购买产品。
- 在消费请求上使用
includeOrderIds: true选项以履行/消费购买的商品。 - 请注意在消费响应中返回的 OrderId。
- 向 Microsoft 开发人员合作伙伴管理员或 Microsoft 联系人发送电子邮件，请求产品退货。 电子邮件必须包含以下模板示例中的以下信息：
| 请求类型 | OrderID | OrderLineItemId | 测试帐户（电子邮件） | 已购买商品的名称 | 购买日期 | 请求摘要，其他信息 |
|---|---|---|---|---|---|---|
| 返回 | 8060a406-85c8-4d01-a105-ff11725499c9 | cb054aa0-7392-4cc6-af06-53b285e39259 | XDKS-RefundTest0001@xboxtest.com |
易耗品 1 | 2021-08-30T21:53:08.2565331+00:00 | 商品的追回退还测试 |
注意：请确保请求列为“退货”而非“退款”。 用于“退款”的工具将退还款项，但保留用户帐户的权利。 工具中的“退货”将导致权利撤销以及将追回退还事件写入队列中。
Xbox 支持团队的代表将回复你，确认已在 3 个工作日内处理请求。
然后，应该能够在查询中看到正确的追回退还信息。
如果获得开发人员合作伙伴管理员的授权，他们可以提供Xbox 支持团队的电子邮件地址，以便你未来直接发起请求。
不要在组织内广泛共享此别名，请记住在未来的任何直接请求中抄送开发合作伙伴管理员。
注意：退货和退款只会导致具有非零定价产品的追回退还事件。 因此，产品的价格至少需为 0.01 美元。 现已启用此功能，因为所有新创建的测试帐户都将向其添加测试付款方式，他们可以在沙盒中进行测试购买。 如果使用的是没有测试付款方式的较旧帐户，请创建一个新帐户以执行此流程。