当前位置: 首页 > 知识库问答 >
问题:

续订订阅时是否引发Customer.subscription.Updated事件?

沙星波
2023-03-14

每当订阅更改时发生。例子包括从一个计划切换到另一个计划,或从试用状态切换到活动状态。

...这意味着,如果current_period_startcurrent_period_end值发生更改,则将引发该事件,但它不会确认是否发生更改,也不会确认在本例中是否发生更改。

但是,该第三方网页声明,当成功进行续订时,它不会引发(https://www.masteringmodernpayments.com/stripe-webhook-event-cheatsheet#8)。

因此,在我的应用程序中,在收到invoice.payment_succeed事件后,我的程序代码如何确定客户的订阅期下一个结束时间?

共有1个答案

雍志新
2023-03-14

我已经验证了在计费期结束时调用customer.subscription.updated

为此,我截获了在这段时间结束时发生的所有webhooks(仅供参考:我使用了一个AWS Lambda函数,该函数从AWS API网关接收事件,然后将事件放在SQS队列中:))

我同意customer.subscription.updated事件的Stripe文档可以更加清晰,并且可以通过以下语句来覆盖这个用例....

为了保护Stripes文档中有关订阅生命周期的内容,它确实表示“下面的图像显示了发生的最重要事件的生命周期”,我认为customer.subscription.updated在创建发票和支付时并不是一个重要事件。

关于Stripe如何处理句点结束的一些详细信息:

>

  • 在我的测试中,Stripe在订阅的current_period_end属性中的时间戳之后大约2分钟引发了customer.subscription.updated事件。该事件有两个与之关联的数据对象。第一个是带有新值的订阅。第二个是PreviousAttributes对象,它具有前两个current_period_startcurrent_period_end值。

    在创建发票大约一个小时后,同时生成了三个事件:invoice.payment_succeedcharge.succeedinvoice.updated

    您如何对待账单期的展期与发票的付款状态实际上取决于您,并且在很大程度上取决于您的应用程序类型。这就是Stripe API的美妙之处(它是一件美妙的事情)。

    在我的情况下,我将账单期间的展期与发票的付款状态分开处理。我的应用程序关心计费周期何时结束,并基于此更新使用情况,但任何支付失败都会生成警报&并脱机处理。

  •  类似资料:
    • 问题内容: 每当我打开应用程序时,我都想检查自动续订订阅状态。 这是为了确保用户仍订阅了该服务。我该如何实现? 有什么想法吗?谢谢 PS:我正在使用 问题答案: 这是几种进行收据验证的方法,以检查是否已将用户授予订阅。这是正确执行此操作的两种方法: 如此处所写,在本地进行收据验证。 远程执行收货验证,因为它是写在这里。提到不应将收据发送到应用程序内的App Store。简短的摘要: 您的应用会将收

    • Node.js应用程序可以使用composer-client.BusinessNetworkConnection.onAPI调用从业务网络订阅事件。事件在业务网络模型文件中定义,并由交易处理函数文件中的指定交易处理。有关发布事件的更多信息,请参阅发布事件。 在你开始之前 在应用程序可以订阅事件之前,你必须定义一些事件和发送它们的交易。还必须部署业务网络,并且必须具有可连接到该业务网络的连接配置文件

    • 简介 Redis 的列表类型键可以用来实现队列,并且支持阻塞式读取,所以 Redis 能够非常容易的实现一个高性能的优先队列。同时在更高层面上,Redis 还支持“发布/订阅”的消息模式,可以基于此构建一个聊天系统。 发布示例 发布(Publish)即将消息发布到频道中。示例代码: // 发送消息 Redis::publish('chan-1', 'Hello, World!'); // 发送消息

    • 我有一个Spring靴2.0.0。M7 Spring Webflux应用程序,其中我使用的是Thymeleaf Reactive。 我注意到,在我的微服务上,当我在SSE模式(文本/事件流)下调用一个返回数据流的endpoint时,即使该数据流已被正确处理,也会在该数据流上发生cancel()。 例如,这里有一个简单的控制器endpoint: 以下是我在SSE模式下请求时得到的订阅流量日志: 我们

    • STOMP规范规定订阅必须有id头。 https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE_id_Header 订阅id标头 由于单个连接可以与服务器有多个打开的订阅,因此必须在框架中包含id标头以唯一标识订阅。id标头允许客户端和服务器将后续消息或取消订阅帧与原始订阅关联。在同一连接中,不同的订阅必须使用不同的订阅标识符。

    • 我在WPF中编写代码,其中有两个视图模型。在一个视图模型中,我正在关闭一个prism弹出窗口,在关闭时,我将调用我的发布方法,如: 而我的subscribe事件如下所示: 以下是这两个类接收事件聚合器的方式: 这是我的第二堂课: 每次取消交互时,发布都会被发布,但不会被调用,因为订阅。 在具有subscribe方法的其他类之前被调用。会有问题吗?我只想在交互完成时初始化我的集合视图,而不破坏MVV

    • 主要内容:发布/订阅流程,常用命令汇总,基本命令应用Redis PubSub 模块又称发布订阅者模式,是一种消息传递系统,实现了消息多播功能。发布者(即发送方)发送消息,订阅者(即接收方)接收消息,而用来传递消息的链路则被称为  channel。在 Redis 中,一个客户端可以订阅任意数量的 channel(可译为频道)。 消息多播:生产者生产一次消息,中间件负责将消息复制到多个消息队列中,每个消息队列由相应的消费组进行消费,这是分布式系统常用的

    • 发布/订阅 消息顺序 当使用 pub/sub API的时候,你需要做一个决定:那就是对于来自同一个连接的消息是应该按顺序处理还是应该并行处理。 按顺序处理意味着你不需要关心线程安全,并且保持了事件的顺序;消息会以完全相同的顺序接收处理(通过队列),因此,这意味着消息能够被相互延迟。 另外一种选择是并发处理。使用并发处理 不能保证 工作处理的有序性,并且你的代码要对并行消息完全负责确保它不会破坏内部