#bhaumik1665_webhooks

1 messages ¡ Page 1 of 1 (latest)

wooden ridgeBOT
fossil spadeBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

wooden ridgeBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1260112924152692847

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

daring ember
shadow parrot
#

I'm sorry but, I don't want to use different events, the reason is that payment_intent.succeeded is triggered for all four payments.

I will anyway need to identify type of payment in the payment_intent.succeeded event to skip invoice & subscription payment. If I use invoice.paid event as well.

can you give me details regarding single event only payment_intent.succeeded?

daring ember
#

To use payment_intent.succeeded event to identify what payments are made from, additional API requests will be made via Invoice and Subscription Retrieval APIs like what you mentioned. This can potentially hit the rate limit: https://stripe.com/docs/rate-limits

I'd recommend using:

  • payment_intent.succeeded events for one-time payments
  • invoice.paid events for invoice and subscription payments
Rate limits

Learn about API rate limits and how to work with them.

shadow parrot
#

It's okay, Stripe is not used too frequently for payments, because my system has subscription payments and those payments are not that much.

Maybe 20-40 payments a week (including subscription create & subscription renew)

daring ember
#

In your attempt by inspecting billing_reason after making additional request to retrieve the Invoice object from Payment Intent in payment_intent.succeeded event, this will work too. However, we generally don't recommend due to the rate limit concern

shadow parrot
#

yes, billing_reason would be useful.

daring ember
#

Please note that payment_intent.succeeded event won't be created if the invoice is $0, e.g. subscription with trial or coupon applied with 100% off

#

Only invoice.paid event will be sent for $0 invoice

fossil spadeBOT
shadow parrot
#

Thank you for that information!.

#

I want to know the difference between subscription_update & subscription_cycle in billing_reason

when can I get above value for billing_reason?

when I used Stripe Test clock to trigger renewal I got subscription_cycle for that 2nd invoice of the subscription.

when I can I get subscription_update?

tranquil flicker
shadow parrot
#

yes, but I cannot understand that based on a single statement A subscription was updated.

can you help me with detail?

tranquil flicker
#

So exactly what info you want to get from an invoice object?

shadow parrot
#

I want to know what kind of invoice payment would have subscription_update as billing_reason

tranquil flicker
#

Isn't this already explained in the API reference ?

shadow parrot
#

maybe yes, but I am unable to find it.

tranquil flicker
shadow parrot
#

I'm sorry jack but I'm not able to get it from the single A subscription was updated. statement.

when subscription update type invoice is created and paid?

tranquil flicker
#

That's a different question

shadow parrot
#

I'm sorry seems like I'm unable to explain you my question.

#

let me put it in a different way.

tranquil flicker
#

No worries, maybe you can walk me thorugh with an example?

shadow parrot
#

which type of invoice would have billing_reason as subscription_update?

when the subscription upgrade happens with a prorated amount and that amount invoice would have billing_reason = subscription_update?

let's say initially, a subscription was created with (2 x Gold plan), in the middle of the billing cycle, the customer wanted to upgrade and the new quantity would be (3 x Gold Plan), so I create a prorated amount invoice for that (using

$subscriptionData = [
    'items' => data_get($attributes, 'prices'),
    'payment_behavior' => 'default_incomplete',
    'proration_behavior' => 'always_invoice',
    'payment_settings' => [
        'save_default_payment_method' => 'off'
    ],
];
$updateSubscription = Subscription::update($subscriptionId, $subscriptionData);

that prorated invoice will have billing_reason = subscription_update?

#

FYI - I'll complete the payment using Stripe JavaScript SDK (stripe.confirmCardPayment())

tranquil flicker
#

Yes, since you update the susbcription, the resulting invoice will have billing_reason=subscription_update/

shadow parrot
#

ok

#

and billing_reason = subscription_cycle will be there for both actual upcoming month/quarter renewal payment and sandbox test clock advance time, correct?

I just want to confirm if subscription_cycle will be available in the Stripe Production as well or not.

tranquil flicker
#

No, for renewals it will be subscription_cycle

shadow parrot
#

yes talking about renewal only.

#

renewal from sandbox test clock advance time OR actual production renewal.

#

there?

tranquil flicker
#

What's the question?

shadow parrot
#

subscription_cycle will be available for both sandbox test clock advance time and actual production renewal event on the specific interval.

correct?

it's not applicable only to the simulator, correct?

tranquil flicker
#

It's available in production. and I believe I've already told you the billing_reason will be subscription_cycle for renewals.