#bhaumik1665_intents-and-invoices

1 messages ยท Page 1 of 1 (latest)

shrewd palmBOT
#

๐Ÿ‘‹ 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/1259854762745135206

๐Ÿ“ Have more to share? Add details, code, screenshots, videos, etc. below.

amber badgeBOT
royal gale
#

Hi there ๐Ÿ‘‹ you can use Test Clocks to advance a testmode Subscription through its full lifecycle, so you can see exactly how it will behave in your system. I'm not sure whether your flow adjusts the description of the Payment Intent, so I'm not sure how reliable that field will be for your needs.

Payment Intents you created directly won't be associated with an Invoice, so their invoice field should be null:
https://docs.stripe.com/api/payment_intents/object#payment_intent_object-invoice

For Payment Intents that do have an Invoice, you can retrieve that associated Invoice to get more context on where it came from. The billing_reason field is a good one to check for that context:
https://docs.stripe.com/api/invoices/object#invoice_object-billing_reason

acoustic girder
#

so you're saying that

  • if payment intent -> invoice property is null then its manual PaymentIntent::create()
  • if payment intent -> invoice property is available I fetch invoice data &
    - if billing_reason of invoice is subscription_create then its fresh subscription purchase
    - if billing_reason of invoice is subscription_update then its subscription renewal

Am I correct?

royal gale
#

Yup

acoustic girder
#

and I should not be dependent on the description for subscription purchase identification, correct?

royal gale
#

If you don't change our default values you may be able to rely on it, but that seems fragile in my opinion.

acoustic girder
#

yes, you're right, its fragile.

and this billing_reason is not in developer's hand and automatically populated by Stripe based on the respective event.

correct?

royal gale
#

Yup, exactly

acoustic girder
#

and one more doubt

what about manual invoice creation from stripe dashboard and link sent to customer manually.

then?

royal gale
#

Can you elaborate on what you're trying to ask there? When you create a test Invoice that way, does the behavior of billing_reason not align with what we document it will be?

acoustic girder
#

We have 4 different payment types

  • PaymentIntent::create() -> from code base when new product is purchased -> one time payment
  • Subscription::create() -> from code when new subscription is purchase -> recurring payment
    • This also has a subscription renewal
  • Invoice create from stripe dashboard (to ask customer for some additional payment - this is out side of the code)
#

now we have identified differentiator for first three using invoice property -> null -> and then fetch -> billing_reason

what about manual invoice create from Stripe dashboard -> from the screenshot I attached.

how can I know if that kind of payment happened in the system in the payment_intent.successed event.

royal gale
#

billing_reason will be manual, but you won't know whether it came from the dashboard or code. I think you would need to add your own tracking for that.

acoustic girder
#

but I think if it came from PaymentIntent::create() (code) then invoice property will be null

And if it came from dashboard then invoice property will have multiple options from that my useful option are as below

  • subscription_create -> fresh subscription purchase
  • subscription_update -> renewal subscription payment
  • manual -> manual invoice create from Stripe dashboard -> from the screenshot I attached

correct? or what?

royal gale
#

In our API ref we list an explanation for each possible enum value for the billing_reason field, for manual we do indicate:
manual: Unrelated to a subscription, for example, created via the invoice editor.

What you're describing sounds right, but I'm having a hard time understanding what you're looking for clarity on. When you create Payment Intents and Invoices in test mode using the scenarios you describe, are you able to see the fields being populated on the objects as I've been describing?

acoustic girder
#

as of now, I have not tried looking into the invoice -> billing_reason but give me time until tomorrow afternoon IST, I'll look and get back to you.

can we keep this thread open until then?

royal gale
#

No, we do not keep threads open that long. I'll close it after about 20 mins of inactivity. You can always start a new thread if things are still unclear tomorrow, just let us know what your question/concern is at that point and whichever of our team members who is working the channel will lend a hand.

acoustic girder
#

okay, thanks for your help so far.

we're able to clear 3 points

  • if payment is one-time payment then invoice will be null
  • if payment is subscription purchase payment then invoice will have some value & when I fetch that invoice, its billing_reason will be subscription_create
  • if payment is subscription renew payment then invoice will have some value & when I fetch that invoice, its billing_reason will be subscription_update

correct for above 3 points?

royal gale
#

if payment is one-time payment then invoice will be null
If the Payment Intent isn't associated with an Invoice, then invoice is null. You can have one-off Invoices.

Otherwise, yes

acoustic girder
#

okay, thanks.

let me try above 3 and then I'll look into manual invoice creation from stripe dashboard -> the screenshot I attached and see billing_reason property for that kind of payment.

#

also, this billing_reason property will be available in older subscriptions as well, correct?

I already have active subscriptions in my production.

so let's say that my oldest subscription was from 2018 and that subscription's renewal event happened in this month, I'll get billing_reason as subscription_update for that as well.

correct?

royal gale
#

Yes, is that not what you're seeing in your testing?

acoustic girder
#

in testing, I don't have that old subscription.

shrewd palmBOT
#

bhaumik1665_intents-and-invoices

tidal rover
#

Hello toby has to step out but I can help. Catching up on this thread

#

When you say you don't have that old subscription, do you mean that you don't have a subscription that old in test mode but you do in livemode?