-
Notifications
You must be signed in to change notification settings - Fork 628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[InvalidRequestException] Expose stripeError.code #614
Comments
Hi @ema987 ! Thanks for bringing to us (and the through write up)! I've added this as [task](ANDROID-285 - InvalidRequestException doesn't expose stripeError.code making it difficult to handle it) in to our internal task tracking system. |
Hi @ksun-stripe , thank you for taking care of this! I will keep my eyes open to follow updates! |
@ema987 I'll put up a PR to include |
- Make model fields immutable - Add nullity annotations Fixes #614
@ema987 this will go out in the next SDK release. Can you confirm if this change is what you were looking for? |
Hello @mshafrir-stripe, thank you for the update! I didn't have time to build the latest master branch but looking at the PR it looks like what I was looking for. Thank you! |
Summary
The class InvalidRequestException doesn't expose stripeError.code making it difficult to handle it.
Have a look here at private static void handleAPIError()
Code to reproduce
You can see it just looking at the SDK source code, there is no other code needed. Anyway, one example case where you would need to access the error.code but you can't is when you pay with an unsupported card.
This is the JSON response got from the backend, which is wrapped into an InvalidRequestException and so you can't access the card_declined error.
Android version
Doesn't matter.
SDK version
v8.0.0
Other information
I'm not sure where to open a new issue or put this question here because it's kind of related to the same argument: shouldn't a payment with an unsupported card be returned by the server with a 402 status code (instead of a 400 as it is now) so it will be wrapped into a CardException (which exposes error.code)? Actually imho paying with an unsupported card is not an invalid request (e.g. it doesn't miss any mandatory param) so it should follow a different flow.
Please check the related iOS issue I opened here stripe/stripe-ios#1001
The text was updated successfully, but these errors were encountered: