#gmturek-python
frozen aspen
when checking the exception, I'm trying to figure out which keys will always be in exception.json_body["key"].
We're having a problem with an exception for decline_code not always being there, for example.
There is a case of an expired card, and it looks like in the Stripe docs that can show up either as "expired_card" in the "code" key or in "decline_code" with "code" being "card_declined".
strong rock
Do you have the request that returned the error that I can look at?
frozen aspen
Yes. Just a sec.
It was a decline for an expired card. So were were expecting it to be a decline code listed here https://stripe.com/docs/declines/codes
But it was just "expired_card" from here: https://stripe.com/docs/error-codes
I"m getting the request now
req_w08wNHFW4MRQf5
strong rock
taking a look now!
frozen aspen
Thanks.
strong rock
(still looking into with some folks, thanks for being so patient!)
frozen aspen
No problem.
It looks to me from the docs that an expired card can come back in the 2 ways I described above. So we could update our code to handle both. In order to handle exceptions properly, my main question is for CardError in general, if we can rely on the "code" key to be there when the "decline_code" key doesn't exist.
strong rock
So from what we can tell, this request should set expired_card as the decline code. We're going to flag with some folks internally to check if this is something intentional or should be fixed.
For now, yes, I think it's fine for you to first check decline_code and if one doesn't exist you fallback to code. Alternatively, if you're just looking for a human-readable message to show to your user you can just use message
frozen aspen
Ok, thanks for checking. Yes, I agree about checking for decline_code and falling back to code. Can we depend on "code" being a key?
strong rock
Yup! You should be able to
frozen aspen
Thanks.