Sterk auðkenning í vefverslun
- gögn



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:

  1. When cardholder has inserted his cardnumber the webshop does a forward to 3DSServer/MPI url
  2. 3DSServer/MPI contacts the card scheme and get‘s issuer url and card status
  3. 3DSServer/MPI does a browser forward to issuer ACS web
  4. Cardholder authenticates himself to the issuer
  5. Issuer ACS system does a browser forward to MPI with additional data, CAVV (proof of authentication)
  6. MPI does a brower forward to merchant webshop with status information and CAVV
  7. 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

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
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

RPG 3DS support

Borgun RPG payment API can be browsed at
and docs can be found here

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"


Þessi vefsíða styðst við vafrakökur

SaltPay notar vefkökur m.a. til að greina umferð um vefinn og til að bæta upplifun notanda á síðunni. Nánari upplýsingar um vefkökunotkun