#stripe_connect_platform - Existing Sub

1 messages ยท Page 1 of 1 (latest)

strange jasper
#

HI ๐Ÿ‘‹

plain sundial
#

Hi. We are totally confused.

#

We have the Sub. Now what is the next step?

strange jasper
plain sundial
#

Do we make a .update or .delete call. If .delete and we pass in prorate:true we are not getting the correct behaviour as I and my dev have written. Instead of getting a credit balance popualted with the...uh....credit balance, we are getting $0 as the credit balance.

#

Perhaps we need to .update the Sub before deleting it?

#

Linking to the docs in this case is not so helpful.

#

This should be a very common use case no? Not sure why it is so hard to get a response to this question.

strange jasper
#

I suggested using the Upcoming Invoice API prior to the .delete call to return an Invoice object that includes the prorated amount.

#

As you might be familiar with, the Upcoming Invoice API allows you to simulate the impact of changes made to a subscription before making them

plain sundial
#

If I sign up for a $29.97/mo subscription and pay and cancel in 15 days, the prorated balance is about $15. That is what we wish to refund. The upcoming invoice would be $29.97 so I don't understand your logic.

#

I don't understand at all.

strange jasper
#

How did you call the API?

#

Can you share the request ID?

plain sundial
#

That seems like a very complex solution. Why can we not just cancel the Sub and get the actual, real, prorated remaining balance?

#

Instead of simulating as if we were going to cancel?

#

The problem is that the balance isn't getting set correctly when we actually cancel the sub.

#

How do we cancel the sub immediately so the balance owed to the customer is the correct balance actually in the real world owed to the customer???????????

#

Then we can just get that ACTUAL balance and REFUND it

#

Why is this so complex and why would it involve looking at hypothetical future invoices???? There is NO future invoice, b/c the person is cancelling "immediately". There is only a balance owed.

#

Is there another dev who can field this question please?

strange jasper
#

You mean something like this?

plain sundial
#

Yes but VIA THE API not the dashboard

gleaming girder
#

@plain sundial did you get the answer you wanted?

plain sundial
#

I am not sure. Working on it.... Thanks for asking.

gleaming girder
#

cool keep me posted!

plain sundial
#

Stripe::Subscription.delete('sub_')
OR
Stripe::Subscription.delete(stripe_subscription_id, {prorate: true})
....if we need to get a clear amount somewhere to refund the prorated amount.

gleaming girder
plain sundial
#

OK, I'm working through this now.

#

Yeah, this does not appear to work.

#

I have a sub.

#

Upcoming invoice I look up is for $39.97.

#

I cancel the sub:
Stripe::Subscription.delete(stripe_subscription_id, {prorate: true})

#

I look at the upcoming invoice and the amount_due is $0. Not the prorated amount.

gleaming girder
#

I mean upcoming invoice is not what you want?

plain sundial
gleaming girder
#

you seem to be going really fast and rushing through it and saying doesn't work ๐Ÿ˜…

plain sundial
#

That is what I want. What appears as $8.38, the exact prorated amount owed to the customers.

#

Sorry. I am totally confused.

#

Can we start at zero please

#

I have a customer. They are paying $40 per month on a Sub.
i have retrieved the Sub.
sub = Stripe::Subscription

gleaming girder
#

I know you're confused, you're rushing through this

plain sundial
#

Now?

#

I want to cancel immediately, get the prorated amount and refund it. That's it.

gleaming girder
plain sundial
#

I actually do not want to simulate anything

#

I want to actually cancel

#

Then get the actual amount the customer is owed and give it to them. That's it.

#

If you need me to simluate the cancellation, via simulation determine what a simulated cancellation even would calculate as a refund, save that amount, then actually cancel and then refund, I can do that but seems crazytown.

#

Let me try simulating a cancellation. Strange but ok

gleaming girder
#

lol

#

I literally gave you 2 solutions and you rushed to the first one and didn't read the docs for it though

#

I'm sorry, you do this a lot in the thread, adn earlier you were quite impatient with my colleague too

#

Really if you don't want to preview the refund before cancelation, all you have to do is cancel and look at the latest_invoice on the subscription and you're done

#
  stripe_subscription_id, 
  {
    prorate: true,
    invoice_now: true,
    expand: ['latest_invoice'],
  }
)```
plain sundial
#

That solution (just canceling and looking at the invoice) seems like the smartest, simplest way. Yes. Sorry, we are under much pressure at this time trying to get users over to a whole different app

gleaming girder
#

this is likely what you want, if you look at the resulting invoice in the response (since we expand it here) you get all the information you need

plain sundial
#

That is an elegant and simple solution. Thank you!
Stripe::Subscription.delete(
stripe_subscription_id,
{
prorate: true,
invoice_now: true,
expand: ['latest_invoice'],
}
)

gleaming girder
#

I understand you're understand pressure, but you'd gain a lot of time by clearly explaining the question, all in one unique messages (not dozens of short sentences) when you're asking something specific/complex.
I also write a lot of short sentences usually, but when you want to communicate an overall end to end ask it's a lot cleaner

#

also curious who bought you now :p

plain sundial
#

No one bought us. We have an app on a platform and someone bought the platform where the app lived. Let's say Parallelogram Inc. ๐Ÿ™‚

gleaming girder
#

oh I see

#

@plain sundial did it work? I assume so since you're offline which you often do after you get the answer but we never know when to archive the thread so wanted to double check

gleaming girder
#

@plain sundial sure we can, sorry you disappeared and you usually do that when you're done and we have numerous parallel threads to keep track of

#

what's still blocking you? we can't really keep a thread opened for hours unfortunately ๐Ÿ˜ฆ

plain sundial
#

Is there not a way to just have one invoice and get the prorated amount to refund without creating another invoice upon cancellation? Can't we just get the latest invoice on a subscription, store the invoice_id and the charge_id of that last invoice, cancel the sub, get the prorated amount, and refund the Charge with the id from the last invoice?

#

I'm trying to get this really clean in the dashboard.

gleaming girder
#

Well no, that's something we discussed extensively last time together: the previous invoice might not have a charge that is for the right amount

plain sundial
#

I am not understanding why if we cancel with prorate:true, I am not ending up with a clear Balance in the dashboard?

gleaming girder
#

you are

#

you are likely going way too fast again ๐Ÿ˜…

#

Do you have a concrete example where you tried what I recommended and it's not working?

#

because that's exactly what the code I gave you does

plain sundial
#

It is a little hard since I want to 100% make sure we are not refunding the total charge, but instead the prorated charge. But if we spin up a sub and then cancel it, the prorated amount is the full amount. That is an issue with going fast, but I don't want to wait 2 weeks to cancel a monthly sub I just spun up. Hold on. I have a sub_id for you.

gleaming girder
#

sure but we have numerous tools for this

#

for example you can backdate a subscription

#

or you can use test clocks to advance time

plain sundial
#

acct_183tJHHnzkM7EAuH

#

I have a sub. I sent you the ID. The sub is $39.97/mo. I want to cancel it so it is really clear what the prorated balance to be refunded is. Can you tell me how to best do that?

gleaming girder
#

not sure what that customer does? You never canceled the subscription?

#

I'm sorry, I did explain clearly exactly how to do that, I even gave you code ๐Ÿ˜ฆ

plain sundial
#

And before we do that, we should store all the things we need like the ch_ since to refund we need that ch_

gleaming girder
plain sundial
#

The way you explained I can run. We end up with no credit balance and tons of confusing invoices.

#

Is there a cleaner way?

gleaming girder
#

cool please run it and I'll show you

plain sundial
#

ok hold on

gleaming girder
#

thanks let me look

plain sundial
#

canceled_subscription.latest_invoice.total is unfortunately the $39.97 so very confusing if that is prorated or not

#

refund_amount = refund_amount.abs()

gleaming girder
plain sundial
#

Why is the Credit balance always $0?

gleaming girder
#

it shows you the credit you owe them clearly but it's a draft. If you finalize that invoice, it will then move the credit to the customer's balance. But you don't need that since you plan to refund

plain sundial
#

Isn't there a way to cancel so that there is a credit balance? That seems to be the most clear for a customer and for us to understand

gleaming girder
#

What you wanted was a clear record of the calculation, that's exactly waht it gives you, that's why I expanded the invoice, for you to explicitly look at it

plain sundial
#

I issued the refund

#

refund = Stripe::Refund.create(
charge: stripe_charge_id,
amount: refund_amount
)

#

No?

gleaming girder
#

where did you get the refund amount from though?

plain sundial
#

canceled_subscription = Stripe::Subscription.delete(
stripe_subscription_id, {
prorate: true,
invoice_now: true,
expand: ['latest_invoice'],
}
)

#

refund_amount = canceled_subscription.latest_invoice.total

#

refund_amount = refund_amount.abs() since it comes as a negative -39.97

gleaming girder
#

So why do you want a credit balance if you're already doing everything I recommended?

#

Like if you put the credit balance, you then have to clear it explicitly

plain sundial
#

Right now I cannot tell if we are refunding the correct amount since everthing is the total amount 3997

#

OK, I am giving up for today. I just cannot follow you.

#

Yes please archive the thread.

gleaming girder
#

@plain sundial can you try backdating?

#

I mean if you come back tomorrow with the same question and the next day and the next day it's really not a good use of both our times

#

It's fairly straightforward to do, but yes it requires a bit more steps and carefully reading our docs. I know you wish it was a lot easier, but our API can't make every single step work in one call with one parameter. Some require more finesse or syncing

#

At the end of the day, as far as I can tell, you're already at the end and have what you need. If you want to go through the customer balance you'd do
1/ Cancel like you are and get the latest invoice
2/ Finalize that invoice -> This moves the credit in the customer's balance
3/ Read the customer's balance
4/ Refund the most recent charge for the right amount (like we discussed weeks ago it's possible that the most recent charge has a lower amount than the credit and you'd need more charges to refund
5/ Clear up the credit balance since you refunded it

safe plume
#

@gleaming girder you may want to expand on step 5 - I think people think the refund comes from the credit balance

gleaming girder
#

I don't think I need to expand step 5 since they already understood the whole refund steps (and have done them right). They just want the money to flow through the credit balance but I wouldn't (since it's more API requests for the same flow)

safe plume
#

I agree - but the "clear up the credit balance" might mask that making the refunds does not, in itself, change the credit balance

#

i.e. it's not really "cash" or"funds"