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
I don't closely follow the Authorize.Net's Java SDK development, but It was brought to my attention that the MD5 driven transHash is being depreciated and soon will not included in the response from Authorize.Net's API.
My main concern / question was this: Will our existing implementation break once transHash goes away - we are not using this method ourselves, but I took a quick look at the code base here and it appears that at least one method isAuthorizeNet seems to rely on this transHash? Taking that a step further, it appears that createResult relies on isAuthorizeNet, so I'm wondering if this isn't something that pretty soon is going to "break"?
* Verify that the relay response post is actually coming from
* AuthorizeNet.
*
* @return boolean true if the txn came from Authorize.Net
*/
public boolean isAuthorizeNet() {
String amount = ((Transaction)this.target).getRequestMap().get(AuthNetField.X_AMOUNT.getFieldName());
String MD5Value = ((Transaction)this.target).getMD5Value();
String apiLoginId = ((Transaction)this.target).getRequestMap().get(AuthNetField.X_LOGIN.getFieldName());
String transId = getTransId();
String transHash = getTransHash();
return net.authorize.Result.isAuthorizeNetResponse(MD5Value, apiLoginId, amount, transId, transHash);
}
* Create a result for SIM based on the response map.
*
* @param apiLoginId merchant api login Id
* @param merchantMD5Key MD5 key that is created in the Security Settings in the merchant interface.
* @param responseMap
*
* @return the result
*/
public static Result createResult(String apiLoginId, String merchantMD5Key, Map<String, String[]> responseMap) {
Result result = new Result();
result.reformatResponseMap(responseMap);
result.apiLoginId = apiLoginId;
result.merchantMD5Key = merchantMD5Key;
String responseCodeStr = result.responseMap.get(ResponseField.RESPONSE_CODE.getFieldName());
String responseReasonCodeStr = result.responseMap.get(ResponseField.RESPONSE_REASON_CODE.getFieldName());
// if this txn didn't come from authnet - bail!
boolean isMD5Ok = result.isAuthorizeNet();
if(!isMD5Ok) {
responseCodeStr = null;
responseReasonCodeStr = null;
result.getResponseMap().put(ResponseField.RESPONSE_REASON_TEXT.getFieldName(), "Unable to verify MD5 value.");
}
....... SNIP SNIP SNIP.....
}
The text was updated successfully, but these errors were encountered:
Hi,
These methods have already been marked as deprecated in the SDK and have been removed in the latest version of the SDK (v2.0.0).
As per the official announcements, transHash (which uses MD5 based hashing) will be deprecated and a new field transHashSHA2 (based on SHA-512 based hash utilizing a Signature Key) has been made available.
To perform verification on this field, we have provided a sample code for convenience.
Do let us know if you have any further questions on this.
I don't closely follow the Authorize.Net's Java SDK development, but It was brought to my attention that the MD5 driven
transHash
is being depreciated and soon will not included in the response from Authorize.Net's API.See:
this
this
and this
My main concern / question was this: Will our existing implementation break once transHash goes away - we are not using this method ourselves, but I took a quick look at the code base here and it appears that at least one method
isAuthorizeNet
seems to rely on thistransHash
? Taking that a step further, it appears thatcreateResult
relies onisAuthorizeNet
, so I'm wondering if this isn't something that pretty soon is going to "break"?The text was updated successfully, but these errors were encountered: