In card payment transactions made via a physical POS device, entering the card's PIN keeps the transaction secure; in virtual POS transactions, however, transaction security is provided through the 3D Secure flow.
Are 3D Secure payment methods standardized?
There are 3 different 3D Secure methods:
Model 1: 3D
This model consists of two parts: obtaining 3D authorization and carrying out the payment transaction. Payment and 3D authorization are performed by cardholders, directed by the merchant. Merchants can design their payment pages however they like. Care must only be taken to use specific variable names for integration purposes.
Obtaining 3D authorization;
- Card Number,
- CVV (Security Code),
- Expiration Date, and
- Card Type (value 1 for Visa / 2 for Mastercard), etc. parameters being posted to the correct address via a form.
The action attribute of the prepared form must contain the URL of the relevant address.
In addition to the card information, the merchant's;
- Merchant number,
- Order number,
- Transaction amount,
- Success and failure web pages for the 3D authorization process,
- 3D transaction type (must be 3d),
- Date, and
- SHA1 value must also be included in the posted data.
Payment Transaction;
If the 3D transaction is successful, the payment is carried out using the payment APIs or XML format. Instead of the card number, CVV2, and expiration date fields, only the value sent in the md field is used.
In this model, the process that runs from leaving the merchant's website, through the display of the bank's ACS (Access Control Server) URL, until returning to the merchant's site again, operates asynchronously. During this process, the necessary checks can be performed before authorization is given.
Model 2: 3D Pay
The main difference between the 3D Pay model and the 3D model is that the transaction can be completed without the merchant having to carry out the payment separately.
In the 3D Pay model, the parameters required for payment are added to the parameters required for 3D authorization, and both 3D authorization and payment are carried out, returning the result of both transactions. The newly added installment and transaction type parameters are included in the hash generation. The merchant no longer needs to obtain 3D authorization and then carry out the payment separately.
- As in the 3D Model, a form is prepared in the 3D Pay Model, filled in with the parameters to be entered by the cardholder and by the merchant.
- When the form is posted, the information it contains is processed for the 3D authorization and the payment transaction.
- Information regarding the 3D authorization and payment result, together with the required parameters, is returned to the web pages the merchant specified in the okUrl (if the transaction is successful) or failUrl (if the transaction fails) parameters.
- If the transaction successfully completed the 3D stage, an authorization request has been sent for the card.
- For transactions that fail during the 3D stage, these values are not present.
This model is easier to implement and has simpler integration compared to the 3D Model. However, since the payment is charged directly, if the order is not created successfully, a manual cancellation or refund of the transaction may be required.
Model 3: 3D Pay Hosting
In the 3D Pay Hosting model, unlike the 3D and 3D Pay models, the cardholder's information is not collected by the merchant.
- The page where the credit card information will be entered is opened externally by the system. It is sufficient for the merchant to post its own information and the shopping details.
- When the form is posted, the information it contains is processed for the 3D authorization and the payment transaction.
- Information regarding the 3D authorization and payment result, together with the required parameters, is returned to the web pages the merchant specified in the okUrl (if the transaction is successful) or failUrl (if the transaction fails) parameters.
- If the 3D stage is completed successfully, this means an authorization request has been sent for the card.
- For transactions that fail during the 3D process, these values are not present.
- In this model, the entire payment page is fully hosted by the bank. The merchant does not need to have a card payment page of its own.