3DS service via API
Caution
The 3DS service API is very advanced, and it is suggested to investigate other options such as async payments instead of this
Warning
Please note that calling the 3DS service API may incur extra charges
Flow
After getting card details, call Version
Handle receipt of response, and potentially open hidden iframe with threeDSmethodURL
Capture hidden iframe rendering event to update the aREQ object threeDSCompInd
Note
See EMVCo for format of requests to send to Issuing 3ds server on https://www.emvco.com/emv-technologies/3-d-secure/
- Compose aREQ object
Send object to Authenticate method
Handle response - may require a Challenge
Note
See EMVCo for format of aREQ object on https://www.emvco.com/emv-technologies/3-d-secure/
If Challenge, compose the challenge to ACSurl
When challenge complete, call Result
Handle response
Warning
The 3DS environment is very restricted in Testing, and live testing may actually be required
Message versions
The version PayLolly recommends in the response of Version (and the versions it lists as available) is capped at 2.2.0 until 2.3.1 is enabled on the platform: a 3DS server that offers 2.3.1 is answered with the best version up to 2.2.0 that both the card issuer's server and the directory support. Versions 2.1.0 and 2.2.0 behave exactly as before. Always compose the aREQ with the version returned by Version.
Message extensions
messageExtension (in the requests and responses that carry it) is a list of objects, one per extension agreed with the scheme:
| Field | Description |
|---|---|
id |
Extension id |
name |
Extension name |
criticalityIndicator |
true when the receiver must understand the extension |
data |
The extension content (any JSON value) |
Extensions returned by the issuer (for example Visa and Mastercard data) are now kept with the payment: previously they were lost when the payment was stored.
The shape of each element is accepted leniently, in requests you send and in responses we receive: id and name may be any text or number, criticalityIndicator a boolean or the text true / false (anything else is ignored), and data any JSON value. An element that does not follow the EMV format is never the reason a request is refused.
Testing
Please contact us for testing methodology and verification
Warning
Additional fees may apply for the verification as its not an autoamted process