Important: the following functionalities are not yet available on the test or live environment! More details to follow soon.

COPYandPAY

For users of COPYandPAY, minimal additional effort is required compared to the current integration. The workflow is identical to the current 3D Secure 1.0 implementation. The widget will handle the entire additional communication and will be responsible for collecting required browser based information automatically. Following data must be collected by the merchant and send in via

• Server/Server, create checkoutId
• being collected by adding additional input fields to the payment widget (see here)

Server to Server

For users who are integrating via server to server will need to follow EMVCo's guidelines on the frontend integration. Please follow the steps described below:

1. Prepare your front-end and follow EMVCo's recommendation (see Section 4 "EMV 3-D Secure User Interface Templates, Requirements, and Guidelines" here) on how the authentication window should be shown in the webshop (eg. in and iframe or in a lightbox).
2. Prepare your back-end and send following additional information along with the payment information:

Server to Server response

{
	"id": "8ac7a4a0686138d701687eebfbc74747",
	"paymentType": "DB",
	"paymentBrand": "VISA",
	"result": {
		"code": "000.200.000",
		"description": "transaction pending"
	},
	"resultDetails": {
		"clearingInstituteName": "Elavon-euroconex_UK_Test"
	},
	"card": {
		"bin": "411111",
		"last4Digits": "1111",
		"holder": "Jane Jones",
		"expiryMonth": "05",
		"expiryYear": "2020"
	},
	"redirect": {
		"url": "https://test.oppwa.com/v1/threeDSecure/execute",
		"parameters": [{
			"name": "name",
			"value": "value"
		}],
		"preconditions": [{
			"origin": "iframe#hidden",
			"waitUntil": "iframe#onload",
			"description": "Hidden iframe post for 3D Secure 2.0",
			"method": "POST",
			"url": "methodURL",
			"parameters": [{
				"name": "methodData",
				"value": "methodData"
			}]
		}]
	},
	"risk": {
		"score": "100"
	},
	"buildNumber": "deebd8c9af7d84ddee98c38b7f4afcc814012b5b@2019-01-22 13:58:00 +0000",
	"timestamp": "2019-01-24 08:13:41+0000",
	"ndc": "8a8294174b7ecb28014b9699220015ca_0557df43f75643d19479440642979e00"
}

1. Open a hidden iframe and post data to the methodURL

   <form name='' action='call.url' method='POST'>
   	<INPUT type='hidden' name='preconditions.parameters[].name' value='preconditions.parameters[].value'>
   </form>
   <script>
   	window.onload = submitForm;
   	function submitForm() { downloadForm.submit(); }
   </script>

2. Redirect the shopper within and iframe to the redirect URL if onLoad event received from 1.

   <form name='' action='redirect.URL' method='POST'>
   	<INPUT type='hidden' name='redirect.parameters[].name' value='redirect.parameters[].value'>
   </form>
   <script>
   	window.onload = submitForm;
   	function submitForm() { downloadForm.submit(); }
   </script>

Fields required for 3D Secure 2.0

Please note that in order to have a better rate of successful risk-checks during the risk based authentication, it is recommended to send as many fields as possible. This will positively affect the number of frictionless flows.

Source is the cardholder or cardholder's environment

Merchant related fields configured in the gateway

Optional settings

Merchants have the possibility to set the preference of a transaction being challenged or not. This really is only a preference, and won't guarantee that the issuer will or will not request a challenge from the cardholder. It is up to the issuer if they consider the merchant's preference, and if they include it when they assess the risk of the transaction.

For example when a card is being stored for later use (eg. for One click checkout), a challenge may be requested by the merchant. In another example, there might be some regional mandates that certain transactions have to be challenged and the merchant should ask for a mandated challenge.

Send the field threeDSecure.challengePreference with one of the following values:

The field threeDSecure.challengePreference is optional. If not sent, the value "01 - No preference" applies by default.

Information about the cardholder's account and history with the merchant

The following fields are not mandatory, but it is strongly recommended to send them. They are affecting the accuracy of the issuer's risk check, and will result in more frictionless flows.

The field values below can be collected by the 3D Secure Requestor* about the cardholders activity on their webshop.

*3D Secure Requestor denotes the merchant