Like we're doing with Ingenico, normalize authorization decline reasons and make sure we don't retry authorizations when the decline is for a 'fraudy' reason.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Normalize refusal reasons to ErrorCodes for REST | wikimedia/fundraising/SmashPig | master | +58 -28 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T277120 Epic: Adyen reintegration, Drop In Web | |||
Resolved | jgleeson | T283117 Adyen Checkout: handle authorization decline reasons |
Event Timeline
It looks like they don't have card numbers that return bad responses you can either force it in the /payments call
https://docs.adyen.com/development-resources/test-cards/result-code-testing#test-with-checkout-api
or do some name shenanigans
https://docs.adyen.com/development-resources/test-cards/result-code-testing/testing-with-card-holder-name
This is a result of testing with /payments and with 6 (The following example tests a "Refused" payment result due to an expired card:)
{
"additionalData": {
"cvcResult": "1 Matches", "avsResult": "4 AVS not supported for this card type"
},
"pspReference": "863626831213586F",
"refusalReason": "Expired Card",
"resultCode": "Refused",
"refusalReasonCode": "6",
"merchantReference": "187.11"
}
Change 706805 had a related patch set uploaded (by Ejegg; author: Ejegg):
[wikimedia/fundraising/SmashPig@master] Normalize refusal reasons to ErrorCodes for REST
Change 706805 merged by jenkins-bot:
[wikimedia/fundraising/SmashPig@master] Normalize refusal reasons to ErrorCodes for REST