How can the integrity of the authentication event be protected at every stage?

In computer security, integrity means that the data has not been tampered with. With payments an example of tampering would be to change the recipient of a payment, or to modify the amount of the transaction that is authorized. The RTS emphasises integrity in the context of Dynamic Linking, as described in Article 5: The payment service provider is required to ensure the integrity and authenticity of the credentials used to identify the payer, the amount of the transaction and the payee through the phases of the authentication and of the information displayed to the user. Integrity is usually verified by using hashing algorithms, where the transaction data can be compared to a “checksum” which always should be the same for the same data. This test can be done on data as it is sent over the internet, on code running on a device, or even on what is displayed to a customer. 

In an Open Banking ecosystem the payment process is called request-to-pay (Payment Initiation). For consumer payments a practical example would be that the customer chose to pay by bank on checkout when buying something online. The stages of the authentication in this case would be: 1) The merchant sends a secure payment request to the consumer’s bank, which 2) requests a SCA authentication with the consumer. 3) The consumer approves the payment, and the 4) merchant receives the confirmation of a successful transaction. Finally, 5) the credit would be transferred from the consumer’s bank to the merchant’s bank. 

This means that the customer’s bank (a payment service provider, or PSP) is required to test the integrity of the transaction on the following steps: the connection with the merchant, the connection with the consumer (e.g. the bank’s smartphone app), during the approval, as the result of the approval is returned, and as the confirmation is sent back to the merchant. There is a possibility of fraud in all of these steps, but the most vulnerable steps are considered to be the process on the customer’s smartphone, as that is far from a controlled environment. 

It is important to note that the above description is valid for payments under the PSD2 and with 3DS 2.x, while 3DS 1.x has less requirements to test the integrity during the payment process. With 3DS 1.x and there was a requirement that the transaction is verified through two separate channels, one of which could be a text message sent with SMS, which doesn’t support integrity verification. As the market has moved to supporting single device payments it has become required that the integrity and authenticity should be protected through the entire payment process.