#overture8

1 messages · Page 1 of 1 (latest)

elfin fulcrumBOT
abstract oak
#

Hi there

elfin fulcrumBOT
abstract oak
#

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?

scenic spade
#

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.

buoyant belfry
#

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

scenic spade
#

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)
buoyant belfry
#

Gotcha

scenic spade
#

That's the one!

buoyant belfry
#

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).

scenic spade
#

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

buoyant belfry
#

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?

scenic spade
#

Yeah, this one in_1NBfe8B3t6gffdAgrRUrIjkm

#

Oh wait, sorry - I've given you the wrong one!

#

Here is one with a fee: in_1NOTqvF17YelgPJsOdjlIKsC

buoyant belfry
#

Ok no worries. Looking

#

Let me ask a colleague. Will get back to you

scenic spade
#

No problem - thanks.

buoyant belfry
#

Colleague is still looking into this

#

Will let you know when I know more

scenic spade
#

Thanks - while they're looking into that... Do you know approach to Question 1 above is correct?

buoyant belfry
#

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

scenic spade
#

No worries. Thanks - Just wanted to be sure.

elfin fulcrumBOT
buoyant belfry
#

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

scenic spade
#

Ah, ok. I have two questions:

  1. 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"?
  2. Going forward, should we be using something different from "always_invoice" when updating a subscription?
buoyant belfry
#
  1. 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.
  2. 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

scenic spade
#

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?

buoyant belfry
#

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

scenic spade
#

Yes, that sounds good. Please disable the legacy behaviour.

buoyant belfry
#

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

scenic spade
#

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?

winged vigil
#

codename_duchess had to head out so I'm stepping in - give me a minute to check

scenic spade
#

thank you

winged vigil
#

That subscription has no application_fee_percent configured for it at all - so it's expected the fe would be 0