服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 员工确认的原因是按日历日期提前切换：balanceUsed可能已显示新周期的0，而currentPeriodEnd仍指向当天稍晚的结束时刻。
- balanceUsed表示该区间的累计用量记录金额，不是剩余额度；currentPeriodEnd是周期结束时间，cappedAmount才是商家可被收取的用量上限。
- 下个周期边界，用同一响应、同一用量项目和完整UTC时间戳核对已有记录；若仍不一致，保留x-request-id交官方支持追踪。
- 10月13日是员工确认修复的日期；10月14日用户说自10月9日起未再遇到，属于个体反馈，不能据此确定上线日或所有账户已恢复。
修复了什么：日期到了，不等于周期结束了
10月13日13:32 UTC，Shopify官方开发者社区中标为Shopify Staff的Donal-Shopify表示，负责计费逻辑的团队已发布修复。这是员工确认修复的时间，帖子没有给出准确部署日期或适用API版本清单。
员工解释，原先的用量余额按账单周期的日历日期切换，没有使用完整时间戳。因此在周期最后一天，balanceUsed可能已经显示新周期的0，但currentPeriodEnd仍指向当天稍晚的时刻。
按该回复，修复后用量收费的周期切换改为遵循完整时间戳。它解决的是周期边界计算问题，不能据此认定每个账户都已验证正常，也不代表新增费用、额度或退款安排。
先把三个字段的含义分开
Shopify Admin GraphQL 2026-07的AppUsagePricing文档将balanceUsed定义为该计费区间内用量记录的累计金额。读到0，不能直接理解为商家还有完整额度，更不能当作此前没有收费的证明。
AppSubscription的currentPeriodEnd表示当前周期结束的具体日期与时间。核对时保留完整时间戳和时区，不要只比较日期，也不要把它与另一条订阅或另一次响应里的金额拼在一起。
cappedAmount是商家在该区间可被收取的用量费用上限，interval表示收费频率。这些字段各有用途；本次修复没有宣布改变用量上限或商家的计费授权。文档版本用于说明字段，不能当作修复只覆盖2026-07的证据。
真实旧例：07:43查询，周期18:01才结束
在10月1日的后续回复中，员工核对了用户提供的请求：查询发生在07:43 UTC，currentPeriodEnd却是同日18:01 UTC；该周期已有19.99美元用量收费，balanceUsed仍返回0。这里的金额是该案例的已收费金额，不是新的价格或套餐。
员工当时确认，请求返回HTTP 200，且没有GraphQL操作错误，但仍把字段边界不一致的问题交给计费团队。10月13日又明确说明，10月1日的请求发生在修复生效之前，旧响应不会体现后来变化。
这个案例提醒开发者：显示0和实际收费记录是两件事。先核对同一用量项目已有的记录与业务状态，不要为了补上显示金额重复创建费用，也不要把0当成新的可用额度。
下个周期末，按同一组证据核对
先在自己有权限查看的现有查询或记录中，确认订阅身份、用量项目及实际currentPeriodEnd。记录完整UTC时间戳；如果业务界面显示本地时间，先换算到同一时区，再比较先后顺序。
再把同一响应里的balanceUsed与该用量项目已有的usageRecords等记录对照。确认查询时间是否仍早于currentPeriodEnd，以及所看记录是否属于该区间，避免把不同项目或不同周期的数据混用。
如果边界仍不一致，保留该响应的x-request-id，交Shopify官方支持按请求追踪，并附上查询时刻、周期结束时刻和实际观察。按现有授权核对即可，不需要为验证新闻创建新的收费记录。
一个未执行的例子：只看日期会漏掉什么？
以下是假设，未执行真实查询：某订阅的currentPeriodEnd为10月15日18:00 UTC。17:50 UTC查询时，同一用量项目已有该周期的记录，balanceUsed却显示0。虽然日历都写着10月15日，查询仍早于18:00，不能仅因日期相同就说旧周期已结束。
如果实际响应中的currentPeriodEnd已经变成下一周期的结束时间，就需要先确认响应对应哪个周期，再判断0是否与那个区间的记录相符。关键是把时间、订阅和用量项目对齐，而不是看到0就重新收费。
修复确认与用户反馈，分别说明了什么？
10月14日08:26 UTC，原报告者sinuhe回复称，自10月9日起没有再遇到问题。它是该用户的后续观察，能补充问题进展，但不能反推10月9日就是正式上线日，也不能代替其他账户在自身周期边界的核对。
目前可依赖的公开结论是：员工已确认按完整周期时间戳切换的修复，并请用户在下一次周期结束前检查。若仍出现不一致，沿用请求追踪路径处理；公告没有要求重复收费，也没有提供普遍适用的退款或补偿方案。
资料来源
常见问题
currentPeriodEnd为null，是这次问题的表现吗？
不能直接这样判断。AppSubscription 2026-07文档说明，订阅非活跃时currentPeriodEnd为null。先核对订阅状态及所查对象；不要把空值当成已经跨入下一周期，也不要直接归因于这次时间戳问题。
HTTP 200且没有GraphQL错误，能证明金额正确吗？
不能。10月1日的旧案例就是请求成功但字段边界仍需调查。响应成功与业务含义一致需要分别判断，应继续对照完整周期时间和对应的用量记录。
必须升级到某个API版本才能获得修复吗？
员工回复没有公布API版本范围或指定升级步骤。本文引用2026-07文档解释字段，不代表该版本是修复起点。按应用现有版本和实际响应核对，不能把改版本视为已被确认的补救办法。
没有保存x-request-id，还能向支持提供什么？
员工早期回复建议，没有请求标识时，可提供操作或查询名称及准确UTC时间，帮助定位请求。也应说明当时观察到的balanceUsed与currentPeriodEnd；按官方支持渠道要求提供必要上下文，避免公开商家凭据或完整计费数据。