Challenge display & Verification
You must have a self submitting form within an iframe to display the issuers challenge screen.
To display the issuers challenge screen within the iframe, use the following parameters from the authentication response:
challenge.referencechallenge.urlchallenge.jwt
The content within the iframe is from the issuing bank. The bank performs an identity check on your customer.
Optional MD field
Pass data specific to your checkout session and it will be echoed back in the challenge.returnUrl originally provided in the authentication request. This could for example be a checkout sessionId. Any value provided must be URL encoded with a maximum of 1024 characters.
Challenge form
Once you have the JWT and URL you can create and submit the Challenge form.
Here's an example of how you would set-up the challenge form in an iframe.
Create an iframe and set the
srcattribute with the URL of the page that will POST the Challenge form. This URL should contain in query string parameters thechallenge.jwt,challenge.urland optionallyMDas those will be used in the Challenge form.
<iframe height= "400" width= "390" src="replace-this-with-the-url-of-your-page-that-posts-the-challenge-form"></iframe>
The size you specify for the iframe depends on whether you have provided a challenge.windowSize in the authentication request and the authentication.version returned in the authentication response:
For an authentication.version value of 2.x.x, match the value supplied in the authentication request. If not supplied use the default 400x500.
Create and host the page that POSTs the Challenge form.
Challenge returnUrl
Once the issuer challenge is complete there is a POST to the challenge.returnUrl (you provide in the authentication request). This should go to your backend where you can retrieve any of the form data, initiate the verification request and display a page in the iframe depending on the outcome in the verification response.
Form data in returnUrl POST:
TransactionId- same value aschallenge.referencefrom the authentication response and used in the verification request.MD- If included as part of the challenge form.
Verification
Once the challenge form has been completed, you must make a verification request to verify the result of the challenge form.
POST your verification request to our 3ds:verify action link received in your authentication response if your outcome is challenged.
Verification example request
POST https://try.access.worldpay.com/verifications/customers/3ds/verification
Verification request body:
Verification responses
Here are examples of the verification responses you would receive. To understand what these outcomes mean and how to reproduce them for testing purposes see 3DS testing.
Use the values: version, authenticationValue, eci, transactionId from the request when authorizing a payment. The values prove that the verification was successful, and that the fraud liability has shifted to the issuer.
authentication.version
The version of 3DS used to process the transaction.
authentication.authenticationValue
A cryptographic value that provides evidence of the outcome of a 3DS verification.
Visa - Cardholder Authentication Verification Value (CAVV)
Mastercard - Universal Cardholder Authentication Field (UCAF)
Used when authorizing a payment.
authentication.eci
Electronic Commerce Indicator (ECI). Indicates the outcome of the 3DS authentication.
02 or 05 - Fully Authenticated Transaction
01 or 06 - Attempted Authentication Transaction
00 or 07 - Non 3-D Secure Transaction
Mastercard - 02, 01, 00
Visa - 05, 06, 07
Amex - 05, 06, 07
JCB - 05, 06, 07
Diners - 05, 06, 07
You will need to use this when you are authorizing a payment.
authentication.transactionId
A transaction identifier.
If provided, you should use it as part of your payment authorization.
If the authentication.version has a major version of:
1- value returned known asxid2- value returned known asdsTransactionId
Last updated