Muhammad Awais

[regal cove]

Does card exception will always have payment intent?

Good question. Checking in to this.

This is about our PHP library correct?

[pseudo wedge]

Yes

Also I want to know when does exception block will be executed?

[pseudo wedge]

For my second question, I know if there is an API rate limit or a similar error occurs then it will be catched inside 2nd catch block. What do we need to do in that case?

[regal cove]

I am having trouble finding documentation on this. If you are already working with a payment intent I think the response should always have a payment intent in the response. Just in case I think you should keep the payment intent's ID in a variable that you can check if the response does not have it

It would also be helpful to log the request ID when you get either of these errors. That will help Stripe support look up your issue https://stripe.com/docs/api/request_ids

For rate limit errors, we suggest retrying the request with an exponential backoff. https://stripe.com/docs/rate-limits#common-causes-and-mitigations
For example, if you get a rate limit error, you could try the request again in 1 second, then 2 seconds, then 4 and so on.

We also have this doc on general error handling https://stripe.com/docs/error-handling?lang=node#error-types

[pseudo wedge]

If we are just creating the payment intent
```php
try {
$paymentIntent = $stripe->paymentIntents->create(array_merge([
'amount' => $amount,
'currency' => 'usd',
'payment_method_types' => $type,
], $options));
return $paymentIntent;
catch (CardException $e) {
$response = $e->getJsonBody();
$paymentIntent = "";
if(isset($response['payment_intent'])){
$paymentIntent = $response['payment_intent'];
}
return $paymentIntent;
} catch (Exception $e) {
dd($e);
}

then we won't have payment intent id, except receiving it in response

[regal cove]

That makes sense. I am still trying to check in to what you will see in that scenario. I think you would always get a payment intent ID back as long as it is a CardException.

[pseudo wedge]

ok

How can I trigger 2nd catch block?

[regal cove]

The doc that I sent shows that invalid request errors can be thrown. So giving us some invalid value in a parameter should throw an exception that would trigger that block

For example if you give us a negative amount for the payment intent amount

[pseudo wedge]

insufficient funds will fall under card exception right?

[regal cove]

Yes insufficient funds is a decline code which will get thrown as a card exception

We have a doc with test cards that you can use to trigger various card errors https://stripe.com/docs/testing#declined-payments

Also I found the code in our PHP library that throws these errors https://stripe.com/docs/declines#responding-to-failures-api

So it looks like CardExceptions are only thrown for declines. You can always expect to see a payment intent ID if you were making a payment intent call and got that decline

[pseudo wedge]

Actually, I have a different flow, I have to capture the payment and then release it later, on payment release I have to create another payment intent to charge the actual order amount to the user.

That's why I can't test full flow with those cards.

[regal cove]

It is possible to only get a charge ID back, but that will only happen if you are working directly with the Charges API

I am not sure if I understand your flow. Why are you initially capturing those funds just to release them later?

Those cards will help you test those declines. If you want to see how your code reacts, you will either need to use those cards or make your own mock endpoint that returns an error as Stripe would

[pseudo wedge]

We have to do some operations on our end, we want to make sure this is a real customer before doing those operations.
That's why we are capturing $1 before starting those operations

[regal cove]

Gotcha, that makes sense. So you might need special test logic here to use one of our decline cards instead once your other checks have passed

[pseudo wedge]

So you mean I should pass pm_card_threeDSecure2Required code while creating the payment intent for the actual payment?

Why we are retrieving the payment intent again while we have the payment intent on the error object?

[twin basin]

👋 catching up since my teammate had to run!

[pseudo wedge]

👋

[twin basin]

If your intent is to trigger a charge that will decline, these are the test cards you should use: https://stripe.com/docs/testing?testing-method=payment-methods#declined-payments

[twin basin]

can you share the link to the doc that includes this code sample?

[pseudo wedge]

https://stripe.com/docs/payments/save-during-payment?platform=web#charge-saved-payment-method

👋

[twin basin]

So in that sample, there's no real need to retrieve the PaymentIntent again