BarrelRider

[raw star]

Hi there

Can you provide me an example of a Subscription that you have tested with so I can see how you are cancelling here?

[slate drum]

Hi Bismarck, sure, this is the subscription ID: sub_1MqLKiEgkYGsrIK1hXtefvQ1

I am subscribing and canceling only via stripe hosted pages.

This is the general flow of what is happening:

1. User subscribes and pays the required amount via stripe hosted page.

2. E.g. 15 days passes and then the user decides to cancel via stripe hosted subscription management page.

3. They cancel via stripe hosted cancelation page and the credit automatically goes into their credit balance. I can see that credit amount in customer dashboard, so user now has a credit in credit balance that normally would be deducted from the next invoice if I didn't refund it.

4. Now upon subscription deletion event I am retrieving the prorated amount of that credit in users balance. That amount comes from the latest invoice that has been created when subscription was cancelled. So now I have cancellation invoice with prorated amount and invoice with the original full payment. Original full payment - prorated amount = used time.

5. I am issuing the actual money refund to original payment method. That amount comes from prorated cancellation amount from the cancellation invoice.

6. Once I have the confirmation that refund has been created sucessfully I am putting a debit for that amount from cancellation invoice on user credit balance so effectively i am 0ing it out because I am debiting the amount that they got in credit for cancelation. I do this manually because this is not automated in stripe.
   It is all in regards to the prorated subscription.

currently I am rewriting this a bit in my code to listen for events, I want to be sure user has balance before I issue the refund.

[raw star]

Thanks for the details, let me take a look

Hmm there should not be a 1 hour delay on the Invoice creation from cancellation. That invoice should be cut immediately.

I see this example uses a test clock so you can't really see this timing here any way

Where are you seeing the 1 hour delay exactly?

[slate drum]

So when I cancelled the subscription and opened the draft invoice, before I moved the clock to 20:41 it said something like "This invoice will be finalised at 20:40".

But weirdly enough one time I moved time by I think couple of minutes by accident and it still finalised the invoice.

[raw star]

Yeah test clocks aren't really going to be perfect with that minutiae. Overall, this new invoice will be created and finalized immediately on cancellation.

That said, if you really want to make sure the Customer has a credit before actioning, you can check their Customer Balance via listing their customer balance transactions: https://stripe.com/docs/api/customer_balance_transactions/list

You can also then debit that balance via the API as well

[slate drum]

hmm so I guess I will just listen for invoice.payment_succeeded event, because I would like to avoid randomly just checking the balance so I don't hit any throttling.

Is that acceptable idea?

[raw star]

Well you are going to receive other invoice.payment_succeeded events, right?

So you can't really rely on that

[slate drum]

true I was hoping I could just figure out by metadata how to tell which customer needs refunding

[raw star]

I would listen for customer.subscription.deleted in this case

Then you can retrieve the Subscription and expand the latest_invoice

Then you can get the necessary details you need

[slate drum]

I am doing that in Laravel by default but I branched out to further events because of that discrepancy, when I check the balance upon that event it says 0 because of the draft, but on live system it will be fine?

I am doing literally what you just said, getting the latest invocie and refund amount and all that, I am just worried that balance comes up as 0 upon that deletion event

[raw star]

What says 0 exactly? Can you drop the payload that you see for the latest_invoice?

I really don't think it should be in draft at this point...

But would love to double check on that

[slate drum]

when I make API to get users balance that says 0.00 and that happens upon cancellation event, as for the payload plase allow me two minutes

So this is the payload

sub id sub_1MqM99EgkYGsrIK13MQyjyeH

That is PHP code servicing that event (Laravel Cashier)

now if it that provided code I would check if the balance is there it would say that balance is 0.

[slate drum]

Hi @steady totem hope you are well, let me know if you need any more info

[steady totem]

@slate drum ah, sorry we missed this thread! Do you mind sharing a quick summary of where you're currently blocked? I'm not a PHP expert so may need to pull in a teammate for help

[slate drum]

no problem

so the issue I am having is not PHP realated

the problem is that Stipe upon cancellation of prorated subscription is supposed to credit user credit account with prorated amount straight away.

What happens though is cancellation invoice is created as a draft and it takes about an hour for it to be finalised.

This bugs me because I wanted to check user balance upon sub cancelation event and I can't do that because if cancellation invoice is not finalised the blanace is not credited with prorated amount

what you see on the screenshots shows cancellation invoice in draft state which should never happen

payload file is cancellation event payload

and my code is simply to provide clearer picture

that invoice is about to be finalised in less than a minute

I think

not sure if something is not broken because
Subscription
invoice will be finalized and charged 3/27/23, 9:55 PM is updated every minute to another minute

something is broken on Stripe side

Each time I refresh the draft page it says the draft will be resolved in the next minute and one minute after the clock updates to say it will be resolved next minute.

The invoice to my understanding should not be in draft state to begin with,

[steady totem]

got it, give me a few minutes to catch up

[slate drum]

no problem at all lemme know if you need more info

[steady totem]

Okay, I'm following. let me pull up details about sub_1MqLKiEgkYGsrIK1hXtefvQ1

[slate drum]

I think current sub is in_1MqMAZEgkYGsrIK1ea4v3V6J

i deleted all previous ones

[steady totem]

Hm, I think my teammate mentioned above that test clocks might not handle this very well

[slate drum]

I think he did, but does that mean i can just assume balance will always be available in real life scenario?

[steady totem]

Does the invoice change at all if you advance the test clock 1hr?

[slate drum]

yeah it does pop back into place, as it should it becomes paid

also if I skip checking balance (because it is 0 with that broken invoice) because refunds are immediate I am adjusting balance and it all works out to 0

but I am just a bit worried that I will go live and I will just have major problem with refunds and things

[steady totem]

Got it, okay. Yep, I think what you're seeing is just part of test clocks.