Shift4: update response mapping #5002
Conversation
rachelkirk
force-pushed
the
CER-1094_update_shift4_response_mapping
branch
2 times, most recently
from
eb89580
to
ea9389e
Compare
CER_1094 This change updates a few response method to return more accurate codes and messages instead of the currently existing standard error code mapping
rachelkirk
force-pushed
the
CER-1094_update_shift4_response_mapping
branch
from
ea9389e
to
0c4b05d
Compare
| return unless success_from(action, response) | ||
|
|
||
| STANDARD_ERROR_CODE_MAPPING[response['primaryCode']] | ||
| code = response['result'].first&.dig('transaction', 'responseCode') |
There was a problem hiding this comment.
good work! Looks adequately guarded
There was a problem hiding this comment.
This looks good to me. I like pulling the error codes from the actual response. The only question I have is there any need to notify customers since some of the error messages are changing to a more generic "Transaction declined"? ... I'm approving since that is more in your team's wheel house to make that decision but I wanted to mention it.
Heya @DustinHaefele just responding on Rachels behalf since shes out today, but here's what she said: "Transaction Declined will actually be more specific unless a hostResponse is not returned." |
CER_1094
This change updates a few response methods to return more accurate codes and messages instead of the currently existing standard error code mapping. The previously implemented standard error code mapping was not great. It was returning messages not direct from the gateway, which was perhaps an old standard but there have been requests to make the messages returned aligned with the gateway's actual response.
Failed sandbox transactions do not return the
hostResponse, which is from the card networks, but they do returnresponseCode: D. I've made some extensive updates to test cases and responses to more accurately reflect the gateway's responses in production transactions.