#overture8
1 messages · Page 1 of 1 (latest)
Hi there
Okay so let's start by clarifying what you mean by "manually updated out of band"?
Do you mean when they were paid using the Hosted Invoice Page?
No. Just to clarify - we have a Stripe Connect set up. So, in some instances, we allow our customers set up subscriptions with no card attached - so they are then required to update the status of the invoices manually, when they receive the money outside of the system (say via cash or something). They update the status in our app - and it updates the invoice via the API.
Hi there. Taking over for bismarck as they need to step out
Catching up
How exactly do you update the invoice via the api?
I was under the impression you could only mark an invoice paid out of band via the dashboard
Via the ruby library, here's an example of how it's done:
Stripe::Invoice.pay(stripe_id, {paid_out_of_band: true}, operator.stripe_options)
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Gotcha
That's the one!
Ok for question 1, I think the invoice would still have a collection method of send_invoice even if the customer paid with the link in the email (since collection method involved them being sent the invoice via email). For question 2, can you send me an example of a proration invoice without a fee? AFAIK, there should always be a fee (but we aren't exactly pricing experts in here).
For question 1. Yes, the invoice still has a collection method of send_invoice - however, we need to differentiate between the ones that were marked as paid via the paid_out_of_band approach I mentioned above and the ones that were paid by card via the customer clicking on the pay now invoice link. I think we do this via the related payment_intent record being in a "succeeded" state?
I'll get you an example for question 2...
Here's an invoice with a null app fee in_1NI6zfEC67MVU9EdlgP66vJx
Oh application fee. I was thinking Stripe fee. Ok that is different
Looking
Got it. Do you have one with a fee that I can compare it to handy?
Yeah, this one in_1NBfe8B3t6gffdAgrRUrIjkm
Oh wait, sorry - I've given you the wrong one!
Here is one with a fee: in_1NOTqvF17YelgPJsOdjlIKsC
No problem - thanks.
Thanks - while they're looking into that... Do you know approach to Question 1 above is correct?
I think we do this via the related payment_intent record being in a "succeeded" state?
Yeah I think this is a good way to do it
Sorry didn't answer before
No worries. Thanks - Just wanted to be sure.
Ok cool I heard back from my teammate on this. So your account has legacy behavior configured for it where when you update a Sub and use always_invoice, we consider that to be a "one-off" Invoice even though it really isn't one (so that's why in_1NI6zfEC67MVU9EdlgP66vJx didn't inherit the sub's application fee settings). However, in_1NOTqvF17YelgPJsOdjlIKsC was created via a sub schedule, where the subscription's application fee was inherited.
Is this desired behavior for you? If it isn't I can remove this legacy configuration so that application fee is created in both scenarios
Ah, ok. I have two questions:
- We have several invoices that are possibly affected by the "always_invoice" issue you mentioned. Is there any way for us to query the invoice (or subscription) object to see if it was updated with "always_invoice"?
- Going forward, should we be using something different from "always_invoice" when updating a subscription?
- If you're a Sigma user, I think you can query for requests that you passed always_invoice. Otherwise the process is a bit more manual.
- That's really up to you. If you want/need to invoice them immediately then always_invoice is the move. Otherwise if it doesn't really matter there's nothing wrong with using create_prorations (which is the default anyway)
But again, we can disable this legacy behavior for you if you so desire
So you can continue using always_invoice and have the application fee passed along
Yeah, regarding disabling the legacy behaviour for the "always_invoice" setting. That probably does make sense for us, as we would like the application fee to appear on the related invoice. However, just to check - are there any other side effects when disabling the legacy behaviour?
No this configuration only does one thing: it prevents flow-down of subscription's application fee for any one-off subscription invoices
But in your case it sounds like you always want them to inherit that application fee
Yes, that sounds good. Please disable the legacy behaviour.
Will do. I'll ping here when it's done so you can test it out in test mode
Ok it's done
Recommend you test it out in test mode to confirm it looks all good
Ok, thanks a lot for your help. I'll give this a test shortly.
Could you do me a favour and check another one. This invoice in_1NC9eAJrkV1Sbv19eE7dzLOb also has a null fee - but it isn't for a proration. Any ideas what is causing this?
codename_duchess had to head out so I'm stepping in - give me a minute to check
thank you
That subscription has no application_fee_percent configured for it at all - so it's expected the fe would be 0