Hash HMAC-Authentication in Notify
The shop must verify that a notification request really comes from Pay-Jet Cockpit. Otherwise an attacker can initialise a transaction and then falsify this notification. A shop operator will not manually check whether a corresponding transaction was performed in each case. Therefore, the module must do this automatically.
Currently, the notification request is only encrypted. However, this encryption does not guarantee the authenticity of a message. It only guarantees that a message cannot be listened in on. Therefore, this safety measure is insufficient.
As a result, the response parameter MAC is used, which is formed via the same algorithm as the MAC in request. Only the data parameters differ.
The following data pattern applies here for hash generation: PayID*TransID*MerchantID*Status*Code
The MAC parameter is only returned to the URLSuccess or URLFailure and for URLNotify.
Your integration must check whether the response received is authentic.
The following table describes how you can generate the Hash values to validate Pay-Jet Cockpit response that you received:
Step | Task | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Please log on to Pay-Jet Support, which supplies you with the Hash password. | ||||||||||||||||||||||||||||||
2 | The HMAC value is calculated with the aid of the password and several parameter values. For the calculation, the parameters PayID, TransID, MerchantID, Status and Code are used and separated with asterisks:
| ||||||||||||||||||||||||||||||
3 | Use the HMAC SHA-256 algorithm, which nearly all programming languages support, in order to calculate the Hash value with the password and the parameter values. | ||||||||||||||||||||||||||||||
4 | Verify
to ensure that the message you have received is authentic. |
The MAC parameter is only returned to the URLSuccess or URLFailure and for Notifys.
Important: Passwords may never be send via email, because in this case immediately the security of encrypted Requests/Responses is no longer assured. If accidentally passwords were sent via email, new passwords must be deposited at the merchant's expense with a single process or during next standard release. Pay-Jet explicitly point on the risk of further using such compromised MIDs. If a merchant nevertheless continues such a compromised MID, he bears the liability risk for possible losses due to the compromised passwords on his own.