#barrel-status-webhooks

1 messages · Page 1 of 1 (latest)

graceful rockBOT
molten grail
#

Hi 👋

#

I'm a little unclear how the customer credit balance is involved here

trim timber
#

Hello Snufkin

#

Oh let me explain

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

molten grail
#

Okay that makes sense

trim timber
#

so I was just thinking if checking the status from refund object from stripe API is better or worse than listening for the event.

#

I did test locally and event came immediately so I would say it is easier and cleaner to look at the status but I can't find any confirmation anywhere.

#

I am generally looking for the most trusted way of doing that if that makes sense.

#

But on the other hand event seems to be better as it happens after everything is processed, or at least this is what I hope is happening

molten grail
#

Generally we recommend listening to events for updates on statuses

graceful rockBOT
trim timber
#

That makes sense, though I am not polling the API, that is handled on subscription cancellation event but I assume that something might not be processed immediately (extrapolated from the bit about polling API).

I see, bottom line always best to listen for events rather than immediate API responses.

Thank you!