-
Notifications
You must be signed in to change notification settings - Fork 956
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
[Error handling] Add support for HTTP status codes #1001
Comments
Hi @ema987, I'm not sure I understand what you want to use the HTTP status code for. Have you found a case where we're not providing enough information in the Thanks, |
Hi @danj-stripe, thank you for your attention. Actually I haven't found an exact case where the iOS behaves wrongly on itself, but it behaves differently from the Android one (please see the linked issue) in the case you try to make a payment with an unsupported card. I opened this issue on the iOS repository to make you aware of the situation. I have spoken with @michelle-stripe before, please have a chat with her, probably she knows more details about the situation. Then we could report them here for everyone. Thank you, |
Hi @ema987, I appreciate you flagging this. I believe exposing the info from I think the iOS SDK's approach is sufficient for now. I do agree that the HTTP status code is nice to have on iOS and that our mobile SDKs should behave similarly, so I've added a task to our backlog to update iOS too. If you do run into a problem where you need the status code on iOS in order to correctly handle an error, please let us know. Thanks, |
Summary
The iOS SDK just creates a data structure based on the JSON response from the backend, actually ignoring the HTTP error codes, relying then only on the code field to make choices about errors.
This is not what happens in the Android SDK, which make choices based on HTTP status codes and could cause different behaviours.
Code to reproduce
You can see the difference just looking at the SDKs source code, there is no other code needed. Anyway, one example case where you can get a different behaviour is when you pay with an unsupported card: the iOS SDK exposes the card_declined code, while the Android SDK doesn't, wrapping it into an InvalidRequestException. Please check the related Android issue I opened here stripe/stripe-android#614
iOS version
Doesn't matter.
Installation method
Cocoapods
SDK version
v13.1.0
The text was updated successfully, but these errors were encountered: