You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
handleApiError maps all 402 status code responses to CardException. We have received responses that in the Stripe dashboard are "type": "invalid_request_error", but result in a CardException. (The CardException has a null code which causes us problems.) An example of the Response body is shown further below.
I have been in touch with Stripe support who say "our error documentation doesn't map status codes to specific error types, so the invalid_request_error may not always go hand in hand with the 404 status code.". So I think handleApiError needs to allow for invalid_request_error type in the case 402: branch.
Example of Response body for invalid_request_error type which results in CardException:
Response body
{
"error": {
"message": "The payment is blocked because the used IBAN has been suspended. You can learn more about this at https://support.stripe.com/questions/sepa-debit-chargebacks-faq and if you need assistance processing a payment please contact us via https://support.stripe.com/contact/ for further information.",
"type": "invalid_request_error"
}
}
To Reproduce
Using the Charges API create a Charge with an underlying payment source where the associated IBAN has been disputed 3 times in row. Such that Stripe block the Charge and return an invalid_request_error response. See https://support.stripe.com/questions/sepa-debit-chargebacks-faq
Expected behavior
Expected the Stripe Java SDK to translate the invalid_request_error with HTTP status code 402 into an InvalidRequestException.
Actual behavior: CardException where only the message property is populated, notably not the code.
Hi @jstafford406, you are right that the logic should be using the type of the error to determine the exception type. Unfortunately making this change will result in a breaking change for customers so we'll have to postpone it to the next major.
Is there a way you can workaround this problem for the time being?
Is there a way you can workaround this problem for the time being?
Thanks for following up! Yes we have a workaround for the most pressing case - we catch the CardException and look in the message for "The payment is blocked because the used IBAN has been suspended" to identify when we should have got an InvalidRequestException.
Describe the bug
handleApiError maps all 402 status code responses to
CardException
. We have received responses that in the Stripe dashboard are "type": "invalid_request_error", but result in aCardException
. (The CardException has a nullcode
which causes us problems.) An example of the Response body is shown further below.I have been in touch with Stripe support who say "our error documentation doesn't map status codes to specific error types, so the invalid_request_error may not always go hand in hand with the 404 status code.". So I think
handleApiError
needs to allow forinvalid_request_error
type in thecase 402:
branch.Example of Response body for
invalid_request_error
type which results inCardException
:To Reproduce
Using the Charges API create a Charge with an underlying payment source where the associated IBAN has been disputed 3 times in row. Such that Stripe block the Charge and return an invalid_request_error response. See https://support.stripe.com/questions/sepa-debit-chargebacks-faq
Expected behavior
Expected the Stripe Java SDK to translate the invalid_request_error with HTTP status code 402 into an InvalidRequestException.
Actual behavior: CardException where only the
message
property is populated, notably not thecode
.Code snippets
No response
OS
macOS
Java version
Java 11
stripe-java version
20.121.0
API version
2020-08-27
Additional context
At https://support.stripe.com/questions/sepa-debit-chargebacks-faq Stripe note this is new behavior since 2022-03-07. This is exactly consistent with when we started seeing this issue.
The text was updated successfully, but these errors were encountered: