#cris-moshtix_code

1 messages ¡ Page 1 of 1 (latest)

placid ridgeBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1344589794444972032

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

magic nexus
#

You can use test card that isn't listed as aysnc refund test card. For example 4242 4242 4242 4242: https://docs.stripe.com/testing#cards

Test card numbers

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.

placid ridgeBOT
hollow oar
#

This isn't the answer I was looking for. I need a credit card to test declined refunds, without any previous approval.

fluid cosmos
#

Could you please clarify what you mean by "without any previous approval"?

placid ridgeBOT
hollow oar
#

Your online doc states the following:
Asynchronous failure
4000000000005126
The charge succeeds. If you initiate a refund, its status begins as succeeded.
Some time later, its status transitions to failed and sends a refund.failed

This is not what I'd like to test. All I need is a simple refund decline.

solemn coral
#

There's no synchronous failure for refunds, they're an async process. We mimic that behaviour with those test cards

hollow oar
#

Async is fine, but why "status begins as succeeded"?! Is this always the case?

solemn coral
#

Yes, or pending

#

As I said, the test cards mimic how refunds live behaviour

hollow oar
#

Ok, but then I have a logic problem. Your webhook is sending back a refund.update event, which I use to complete the refund on my side. Meaning I finilise the refund on my end.
Receiving a refund.failed later means I have to revert the entire process, which is quite complicated on the platform I'm working on as this affects quite a few records, with other complexities I don't need to mention.

#

Is there something from the "status begins as succeeded" first webhook which I can detect as a temp status? Like if the refund is pending?

solemn coral
#

Can you share some example evt_xxx IDs that are causing confusing?

hollow oar
#

This is a sandbox transaction

solemn coral
#

Not an evt_xxx ID but ok, I can look

hollow oar
solemn coral
#

Alright, let me have a look

hollow oar
#

Thanks

placid ridgeBOT
solemn coral
#

Thanks for the patience, seems this is expected and can occur so unfortunately you'd need to potentially account for a failure post 'success'

hollow oar
#

Though this can happen, it's obviously poorly handled on your (or the banks) side. It's going to be very hard for us to handle this. Can I assume this is the banks system, and not Stripe, behaviour?

In any case, how come u also don't have just a decline as the very first response? Even a pending, and then decline would work.
You already have:
success
pending > success

how about:
fail
pending > fail

solemn coral
#

Can I assume this is the banks system, and not Stripe, behaviour?
Not sure I can confirm that, nor why it matters?

hollow oar
#

If it's on your end, hopefully u can review it

#

If it's on the banks side, I gues we all have to deal with it

solemn coral
#

Yeah maybe it's valid feedback for us but I'm sure it was designed this way for a reason

hollow oar
#

Ok, I'll be in touch with Chris McDonnell to follow up on this as it seems something that requires some deeper discussion before I can proceed with my integration. Thanks for your help.