ishan-charges

[lean gull]

@solid shard hi! not sure what you mean, can you expand on what this "insufficient funds reason" is you're trying to test?

We have two test cards for refunds, they are at https://stripe.com/docs/testing#cards-responses .

[solid shard]

Basically, I will create a charge object using a customer's card and with 'capture' value set to 'true'. Then, I will create a refund object using the previously created charge object's id and will refund only some amount of the total amount which was actually captured.

After reading stripe docs, I got to know that refund failure scenarios can be:

1. Some problem with the card issuer.
2. Some problem with the bank account.
3. Insufficient platform stripe balance.

[solid shard]

When I create this refund object, I want to receive a 'charge.refund.updated' webhook event with the status of 'failure' and failure reason as 'Insufficient funds'. How can I do this ?

[solid shard]

On the link which you have mentioned, using the card with number '4000000000005126' fails the refund due to 'expired_or_canceled_card' reason. Using the card with number '4000000000007726', the refund is held in a pending state initially, but later when I receive a 'charge.refund.updated' webhook event, the status of the refund is always 'success'.

[lean gull]

yes those are the two cards and the only things you can test

there's no way to directly test your scenario 3, sorry. But usually it doesn't happen, what usually happens if you get a pending refund(which there is a test card for)

I'm not sure 3 even happens, I think it's always just pending refunds are created when you don't have sufficient balance, that is how it's meant to work.

[solid shard]

So, I will never receive a 'charge.refund.updated' webhook event with status as 'failure' ?

[lean gull]

you can. That's what the 4000000000005126 card does.

the way it works is you
a) create a refund and it's successful
b) later, it's possible the bank pushes the funds back a few weeks later. You get a webhook with the failed refund happens. (https://stripe.com/docs/refunds#failed-refunds)

a) might give you a pending refund instead when you don't have the money(the refund is sent when you do have balance again), but it doesn't generally fail outright.

[solid shard]

So, if there is any problem with the card issuer or the bank account, I will get a 'charge.refund.updated' webhook event with status of 'failure' and if there is insufficient platform stripe balance, I will never get a 'charge.refund.updated' webhook event with status of 'failure'. The refund will remain in 'pending' state until and unless funds become available. Right ?

[lean gull]

I think so

[solid shard]

And if a refund goes in pending state and afterwards balance beocmes available, will stripe try to initiate the refund again ?

[lean gull]

yes

[solid shard]

I had one more question.

try {
Refund.create();
} catch(StripeException se) {

}

If there is no issue with the amount that has to be refunded and the request body is also right, then will the control ever go in 'catch' block ?

[lean gull]

sure, the API request could fail for lots of reasons

like maybe there's an internal error and you get a 500 status, or the network request itself fails

you need error handling on all API requests

[solid shard]

Considering there is no network error or internal error, will the control go in catch block ?

Basically my request has reached Stripe. Will stripe give me any exception ?

And I am going to refund only unrefunded amount only.

[lean gull]

best way to answer that is to test it in test mode. As far as I know you usually only get pending refunds. But if your account already has a large negative balance we might just fail the request outright instead instead of letting you accumulate more refunds(but that shouldn't really happen unless your business is mass refunding and in those cases you should reach out to us about wiring funds; so it's an edge-case you're unlikely to hit)

[solid shard]

Using those 2 cards, the control never goes in 'catch' block. Initially, the refund's status is 'success' and then in 'charge.refund.updated' event, it will fail for the first card and for the second one it always succeeds.

[lean gull]

makes sense

[solid shard]

We are not going to do mass refunding and we are always going to try to maintain a positive platform stripe balance. So, most probably, in our case, control will not go in 'catch' block unless and until there is some network error, right ?

[lean gull]

sure yes

[solid shard]

Thank you so much for confirming.

I am done.

Bye.

[solid shard]

Sorry. Just had another query. Apart from these reasons, internal error and network error, are there are any other causes of failure ?

[lean gull]

I suppose not? but it's an API request, you should always be ready for it to fail in some way and at least log the error.