#mkp_webhooks

1 messages ยท Page 1 of 1 (latest)

fossil orchidBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

๐Ÿ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1251025300993736777

๐Ÿ“ Have more to share? Add details, code, screenshots, videos, etc. below.

untold viper
#

Test mode btw

solar coyote
#

hello! you can test out winning or losing a dispute according to the instructions here : https://docs.stripe.com/testing#evidence

Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes, and bank authentication. You can also test non-card payment methods and redirects.

#

can you elaborate more on what you mean by setting the dispute status on their subscription?

untold viper
#

Its an internal bookkeeping thing to disallow service to disputed charges until they get resolved. So people don't think they can just open disputes for 'refunds' with my platform and still use the service while it goes on.

#

Is there a way to force a charge into dispute?

solar coyote
#

i'm guessing you're asking how to test this out?

In essence, you should make the first payment with a test card that will be successful, then change the default_payment_method used for the subscription/customer to that of the relevant dispute test card here : https://docs.stripe.com/testing#disputes so that the subsequent invoice will be disputed

Then test out winning or losing a dispute according to the instructions here : https://docs.stripe.com/testing#evidence

in case you haven't seen this yet, you can use test clocks to mimic the passing of time : https://stripe.com/docs/billing/testing/test-clocks

Learn how to move Billing objects through time in test mode.

Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes, and bank authentication. You can also test non-card payment methods and redirects.

untold viper
#

Ah okay. So first you would complete the charge with the relevant 4000... card number, instead of 4242... which is a success and it will set the status as a dispute so I can put the winning_evidence/losing_envidence to test out what will happen.

#

Thanks so much!

solar coyote
#

Stripe doesn't do anything to the subscription if the dispute is won or lost

untold viper
#

I have it as the default, so I can customize it to my liking I assume

solar coyote
#

your screenshot is for payment reties, not for disputed payments

untold viper
#

So from what I can tell here I have it set to disable auto renewal. Which should cause an customer.subscription.update event near the .dispute.created event

#

Or am I mistaking with the term cancel? Its a pretty loaded word in subscriptions!

solar coyote
#

cancel the subscription immediately without prorating != disable auto renewal. what you refer to as disable auto renewal is more likely cancel the subscription at the end of the period

untold viper
#

Why are you guys so knowledgable?? Going as far as using !=

#

Absolutely blown away

solar coyote
#

customer.subscription.deleted is emitted when the subscription is actually cancelled. e.g. if you choose to cancel the subscription at the end of the period, this event will be emitted at the end of the period

#

the folks who are answering questions here are engineers ๐Ÿ˜…

untold viper
#

Speak to me the language of the programming gods! haha

Gotcha. I suppose I should just leave it as cancel the subscription at the end of the period, in case of wins. So I don't have to black magic the subscription back from death, if its even possible I don't even need to know.

solar coyote
#

so i wouldn't depend on it being completed in time if your subscription is monthly

untold viper
#

I also feature a yearly on this one. So I guess it is a cause for concern.

#

But I am fine for the user to resubscribe if they really want to continue using it after the dispute.

solar coyote
#

personally, cancelling at the end of the period makes sense since the user has already paid for it

untold viper
#

Yeah. You get the full ride of what you paid for if I won, you don't if I don't win. In that case, the transaction is entirely reversed, Im out $15, and I can expect the customer.subscription.deleted? I'll probably have to test for the answer as described above.

solar coyote
#

to be clear, this setting applies when a dispute is opened - not when it's won or lost

untold viper
#

Yep!

solar coyote
#

so if you win the dispute, yes we will return the $15 dispute fee to you. The customer's subscription will possibly / likely be cancelled at this point (if not, it will be cancelled at the end of the billing period)

untold viper
#

Uhg its so difficult to find the giant list of events available and the description with it.

solar coyote
untold viper
#

Yep.

#

Lol!

#

Okay so I guess the worst case scenario is I listen to charge.dispute.closed and check status === 'won' / status === 'fail' on the Dispute object and use the api to expand the charge in search of the relevant data and manually ensure that my database properly handles the charges.

solar coyote
#

sounds about right to me. As always, you'll want to test it out to make sure everything works as per what you expect

untold viper
#

Of course. Thanks for ensuring no stones were left unturned alex!

#

I think I have all the information I need to continue from here. You've been a big help!