Performs the cardholder's 3DS authentication.

Must be called after POST /v1/acquiring/payments/3ds/setup.

The 200 response has two possible outcomes, distinguished by code:

• ACCEPTED (frictionless): authentication is complete, no cardholder interaction. Use cavv, xid,
  authenticationId and directoryServerTransactionId in the threeDsData field of the payment call.
• WAITING_3DS_AUTHENTICATION (challenge): the issuer requires the cardholder to authenticate. Run the
  challenge flow below.

Challenge flow

1. Open an iframe and submit an HTML form to it: POST to stepUpUrl (application/x-www-form-urlencoded)
   with the fields JWT = accessToken and MD = authenticationId. Size the iframe with iframeDimensions.
2. The cardholder completes the challenge inside the iframe.
3. The issuer posts the result to your returnUrl (form-urlencoded) with the fields TransactionId,
   Response (sometimes JWT) and MD. Because this request runs inside the iframe, your endpoint must
   answer with an HTML page that notifies the parent window (e.g. window.parent.postMessage).
4. Call POST /v1/acquiring/payments/3ds/challenge-result with authenticationTransactionId =
   TransactionId received in step 3 (fallback: authenticationId) and the same requestId used here.

Rejection: when the issuer refuses the authentication, the response is 422 with
errors[0].code = AUTH_REJECTED and the issuer's message in errors[0].msg (for example "Frictionless
Authentication rejected by the Issuer."). Any 422, and any response other than 200 with code
ACCEPTED or WAITING_3DS_AUTHENTICATION, means the payment must not proceed with 3DS data.