#lil-nasty_best-practices

1 messages ¡ Page 1 of 1 (latest)

jaunty orioleBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1268319492035973193

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

limpid sapphireBOT
#

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.

rigid wedge
#

Note that this is in a subscriptions context where the invoice is generated automatically by stripe based on a price's recurring interval

#

I assume invoice.created would prob be the field, but not sure if that's accurate, especially for payment methods that take time to process (like a bank account)

true mountain
#

You'd want to look at invoice.paid in this case

#

Unless you specifically want the date that the invoice was created instead

rigid wedge
#

invoice.paid is a boolean

#

I need the date of the payment for the invoice

true mountain
#

invoice.paid the webhook event, which is an Event object that contains an Invoice object

rigid wedge
#

So would I simply take the date we received the paid event?

true mountain
#

Exactly

rigid wedge
#

For card payments this is a simple answer because they happen almost immediately, but I want to ensure the payment date we display to the user is consistent with their bank statement if they used a bank account and it paid more than a day later

#

From what I understand bank account payments can take more than 1 day, but I believe in many cases that the bank displays the payment date as the day the payment processing was initiated

true mountain
#

Which delayed payment method are you using? ACH? SEPA?

rigid wedge
#

We offer many

#

One sec, I'll find the list

#

We offer

image.png
#

We offer many

#

I realized we can't rely on created date either bc if a payment fails and the user updates their payment method 2 days later and then pays the date would be wrong

#

There's also the potential scenario where the webhook event fails and is retried a day later

true mountain
#

You would still get only get an invoice.paid event on the successful attempt, so that's not really a problem. As for the payment date, as far as I know, Invoices won't send an invoice.paid event until the funds reconcile

true mountain
rigid wedge
#

So event.created would be the field for that, right?

#

Just double checking

true mountain
#

Correct

rigid wedge
#

Is there anyway to differentiate if an invoice is for one of the reasons below?

  1. Reg subscription payment
  2. Subscription created
  3. Subscription trial ended
  4. Subscription upgrade proration
#

I need to know which scenario caused the invoice out of those 4

#

I see billing_reason on the invoice object, but idk that it would be sufficient to differentiate all of those

true mountain
rigid wedge
#

So proration items would determine it's scenario 4
On the subscription object I would need to check the trial_end and things like that or is there a simpler way to determine the other 3?

#

I think if it's the initial payment that would be simple because the invoice has billing reason subscription_create

#

But for trial end I suppose I'd have to compare trial end date and the invoice creation date?

true mountain
#

Yep, exactly

#

You're 100% on track

rigid wedge
#

Actually I think the following would prob work

  1. Reg payment
    billing_reason === subscription_cycle
  2. Subscription creation payment
    billing_reason === subscription_create
  3. Subscription trial ended payment
    billing_reason === subscription_update && subscription.trial_end === TODAY
  4. Upgrade proration payment
    billing_reason === subscription_update && LINE_ITEMS_CONTAIN_PRORATION
true mountain
#

That sounds like the right path

rigid wedge
#

Ok, great

#

I'll set those all up and use test clocks to verify

#

Thank you!

true mountain
#

Sure thing! Best of luck!