We do have in-built support for response validation using a HASH digital signature. Refer to the section 7.1 in the WPF integration documentation. This is usually an optional feature. Please contact us or create a ticket here to get it enabled for your channels.
The parameter HASH contains a generated SHA-1 hash of the following response parameters:
- PAYMENT.CODE
- IDENTIFICATION.TRANSACTIONID
- IDENTIFICATION.UNIQUEID
- CLEARING.AMOUNT
- CLEARING.CURRENCY
- PROCESSING.RISK_SCORE
- TRANSACTION.MODE
- PROCESSING.RETURN.CODE
- PROCESSING.REASON.CODE
- PROCESSING.STATUS.CODE
- and the “secret” generated while the Merchant Account was setup and only the merchant knows this
To guarantee the integrity of the response parameters and to make sure they have not been manipulated you have to regenerate the SHA-1 hash value and compare it with the received HASH.
The String to generate the hash is built like this:
PAYMENT.CODE + "|" + IDENTIFICATION.TRANSACTIONID + "|" + IDENTIFICATION.UNIQUEID + "|" + CLEARING.AMOUNT + "|" + CLEARING.CURRENCY + "|" + PROCESSING.RISK_SCORE + "|" + TRANSACTION.MODE + "|" + PROCESSING.RETURN.CODE + "|" + PROCESSING.REASON.CODE + "|" + PROCESSING.STATUS.CODE + "|" + secret
For the sample response above the String looks like this (sample secret is “abcd1234”):
“CC.DB|MerchantAssignedID|402880e5faf35d0700faf35d0cec0002|000.100.110|298.00|EUR||INTEGRATOR_TEST|90|00|abcd1234”
Note: If one of the parameters above is not part of the response message (in the example this is PROCESSING.RISK_SCORE), you have to set an empty string instead.
For this string a SHA-1 hash needs to be generated and compared with the received HASH.
In case your hash and the received HASH parameter are not the same you can assume that the response parameters were manipulated.