Listed below are the steps that a Transparent Redirect transaction will take. There are also 3 diagrams to show the transaction data flow in different scenarios.

1. The cardholder navigates to the merchant’s website and supplies their card details into the merchant’s payment The payment form is hosted directly on the merchant’s system.
2. The Merchant and transactional data, optionally along with Customer information are passed to the payment gateway (Transparent Redirect URL), as part of a transparent The customer is unaware of this redirection as nothing changes on screen whilst processing takes place. The data passed to the payment gateway will be checked for errors at this point.
   1. If errors occur (for example; Variable Tampering), the payment gateway doesn’t allow the transaction to go any further and the error details are passed back to the Merchant’s system (CallbackURL) and moves to step 11.
   2. If no errors occurred, the transaction moves to step
3. The payment gateway contacts the Directory Server to query whether this card is enrolled in the 3D Secure
4. The Directory Server determines whether the card is enrolled in the 3DS scheme, then passes this information back to the payment
   1. If the card is enrolled in the 3D Secure Authentication Scheme, the transaction moves to step
   2. If not, the transaction moves to step
5. The payment gateway passes the URL of the cardholder’s bank’s Access Control Server (ACSURL) and additional data from which a Payment Request string (PaREQ) is created, to the merchant’s system (CallbackURL) as part of a transparent Again, the customer is unaware of this redirect. The data passed to the Merchant’s System should be checked for errors at this point.
   1. If errors occur (for example; Variable Tampering), the transaction shouldn’t go any further and moves to step
   2. If no errors occurred, the transaction moves to step
6. The customer is then redirected by the merchant’s system (CallbackURL) to their bank’s Access Control Server (ACSURL) and they are greeted with the last 4 digits of their credit card & the identification text they specified when registering their card for 3D Secure. This redirection is not transparent; it is very much visible to the
7. The customer then validates their card details using their 3D Secure password, which is validated by their bank’s Access Control Server.
8. The Access Control Server then initiates a redirect of the customer’s browser back to a secure processing page on the merchant’s website (TermURL), which forwards the payment response string (PaRES) from the Access Control Server to the payment gateway (Transparent Redirect URL) using a transparent page redirect. The data passed to the payment gateway will be checked for errors at this point.
   1. If errors occur (for example; Variable Tampering), the details will be passed back to the merchant’s system (CallbackURL) and the transaction won’t go any
   2. If no errors occurred, the transaction moves to step
9. The payment gateway checks the contents of the payment response (PaRES).
   1. If the transaction is declined (following a 3D Secure authentication failure), move to step
   2. If not, the transaction moves to step
10. The payment gateway then submits the transaction to the bank for authorisation. The results of the transaction are then passed back to the merchant’s system (CallbackURL) in a transparent redirect. The data passed to the Merchant’s System should be checked for errors at this point.
    1. If errors occur (for example; Variable Tampering), the transaction HAS already been processed, but the merchant’s system should stop the transaction from going any
11. The merchant’s system should display the transaction result to the customer (or desired error information if any occurred before this point)