Sterk auðkenning í vefverslun
- gögn
General
The process goes through the cardholders browser and it‘s only purpose is to authenticate the cardholder.
If authentication is successful then issuer will take full responsibility on the purchase.
Authorization of amount follows the authentication. The authentication can be seen as pre-prosessing to the authorization.
The steps as seen from the cardholder browser are as follow:
- When cardholder has inserted his cardnumber the webshop does a forward to 3DSServer/MPI url
- 3DSServer/MPI contacts the card scheme and get‘s issuer url and card status
- 3DSServer/MPI does a browser forward to issuer ACS web
- Cardholder authenticates himself to the issuer
- Issuer ACS system does a browser forward to MPI with additional data, CAVV (proof of authentication)
- MPI does a brower forward to merchant webshop with status information and CAVV
- Webshop performs purchase authorization
Iframe can be used.
The changes in process for the merchant is to do the browser forward to 3DSServer/MPI, wait for the process to finish and then send the CAVV information with the authorization request.
Connecting to MPI
3DSecure 3DSServer/MPI Test Access information is in zipfile MPITestAccess.zip
For advanced access then 3DSServer/MPI also support webservice access. It allowes for more control of the MPI process, it is detailed in document mpi_web_service.pdf
These lines are taken from the MpiDemo.zip.
The SecretKey is used to create a digest of the data needed by 3DSServer/MPI – this is essentially the login credentials. Then it is a simpe html-post.
3DSServer/MPI returned values
In document mpi_merchant_interface.pdf in chapter 2.6 is a description of the values returned by 3DSServer/MPI.
Most important is authentication status (SecurityLevelIndicator) which can take three state values:
- 0 = authentication unsuccessful. Cardholder could not finish the authentication process. This makes fraud much more likely.
- 2 = authentication successful (Fully Authenticated). 3DS validated and issuer takes full responsibility for sale.
- 1 = merchant supports 3DS but issuer does not - issuer takes responsibility. This status is better explaned in the mpi_merchant_interface.pdf document. It main definition is that the merchant tried 3DS but it failed because issuer does not support 3DS (mdStatus 2).
There are two other data items of note:
- CAVV which is sent with the authorization
- XID which does only exist for Visa. It is sent with the authorization
From MPI_merchant_interface manual
Payment Gateway – adding 3DS data
3DS data (CAVV, XID, SecurityLevelIndicator) is sent to the payment gateway in the getAuthorization() method.
3DSServer/MPI only returns CAVV, it can either be sent in as UCAF or both UCAF/CAVV always filled with 3DSServer/MPI CAVV value.
From B-Gateway manual (or https://docs.borgun.is/paymentgateways/bgateway/#getting-authorizations)
RPG 3DS support
Borgun RPG payment API can be browsed at
https://test.borgun.is/rpgapi/
and docs can be found here
https://docs.borgun.is/paymentgateways/bapi/
The 3DS values are added to the payment
POST /api/payment
"ThreeDSecure": {
"DataType": "Unknown",
"MpiToken": "string",
"SecurityLevelInd": "string",
"CAVV": "string",
"UCAF": "string",
"Xid": "string"
},
Mpitoken is returned by mpi support function which also creates the 3DSServer/MPI connection string.
POST /api/mpi/v1
{
"Version": "string",
"MerchantId": "string",
"Xid": "string",
"MDStatus": "string",
"MDErrorMsg": "string",
"TXStatus": "string",
"IREQCode": "string",
"IREQDetail": "string",
"VendorCode": "string",
"ECI": "string",
"CAVV": "string",
"CAVVAlgorithm": "string",
"MD": "string",
"Digest": "string",
"Metadata": {
"Payload": "string"
}
}