#bhaumik1665_intents-and-invoices
1 messages ยท Page 1 of 1 (latest)
๐ 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.
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
so you're saying that
- if payment intent -> invoice property is
nullthen its manual PaymentIntent::create() - if payment intent -> invoice property is available I fetch invoice data &
- ifbilling_reasonof invoice issubscription_createthen its fresh subscription purchase
- ifbilling_reasonof invoice issubscription_updatethen its subscription renewal
Am I correct?
Yup
and I should not be dependent on the description for subscription purchase identification, correct?
If you don't change our default values you may be able to rely on it, but that seems fragile in my opinion.
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?
Yup, exactly
and one more doubt
what about manual invoice creation from stripe dashboard and link sent to customer manually.
then?
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?
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.
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.
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 purchasesubscription_update-> renewal subscription paymentmanual-> manual invoice create from Stripe dashboard -> from the screenshot I attached
correct? or what?
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?
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?
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.
okay, thanks for your help so far.
we're able to clear 3 points
- if payment is one-time payment then
invoicewill benull - if payment is subscription purchase payment then
invoicewill have some value & when I fetch that invoice, itsbilling_reasonwill besubscription_create - if payment is subscription renew payment then
invoicewill have some value & when I fetch that invoice, itsbilling_reasonwill besubscription_update
correct for above 3 points?
if payment is one-time payment then invoice will be null
If the Payment Intent isn't associated with an Invoice, theninvoiceis null. You can have one-off Invoices.
Otherwise, yes
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?
Yes, is that not what you're seeing in your testing?
in testing, I don't have that old subscription.