Release notes

• POST /payments
  • For native 3D Secure 2 authentication, the response now contains action.type: threeDS2. This replaces the threeDS2Fingerprint and threeDS2Challenge parameters used in earlier versions.
  • For redirect 3D Secure authentication, the payment is now authorized after the /payments request, when the shopper completes the authentication on the issuer's site. In previous versions, the payment was only authorized after the /payments/details request.
• POST /payments/details
  • For native 3D Secure 2 authentication, the response can no longer contain an action object. This means that native 3D Secure 2 payments no longer require multiple /payments/details requests.
  • For redirect 3D Secure authentication, the /payments/details request is no longer required to authorize the payment, only to verify the payment result. As with other redirect payment methods, the payment is already authorized before the shopper is redirected back to your website.

    To know the payment result even when the shopper did not return to your website, listen for the AUTHORISATION webhook.

  • For redirect 3D Secure authentication, the shopper is now redirected back to you from the issuer with an HTTP GET instead of HTTP POST. The returnURL is appended with a redirectResult.
  • For redirect 3D Secure authentication, you now need to submit the redirectResult appended to the returnUrl when the shopper is redirected back to you. This replaces the MD and the PaRes parameters used in previous versions, and aligns the flow for 3D Secure redirects with all other redirects.

The changes in this version have broken the Klarna widget integration. We are working on fixing this. In the mean time, we recommend that you don't update to this version if you're using the Klarna widget.

• POST /payments
  • We removed the following fields that were marked as deprecated in v64:
    • details
    • paymentData
    • redirect
    • authentication
    • outputDetails

• POST /paymentMethods

  • When using SEPA payments with stored details, the storedPaymentMethods field in the response now contains an object with type: sepadirectdebit:

  Copy code
  "storedPaymentMethods" : [
        {
           "ownerName" : "John Doe",
           "iban" : "GB33BUKB20201555555555",
           "id" : "9916068117659492",
           "name" : "SEPA Direct Debit",
           "supportedShopperInteractions" : [
              "ContAuth"
           ],
           "type" : "sepadirectdebit"
        }
  ]

• POST /paymentLinks

  • requiredShopperFields to specify fields that the shopper needs to fill in before completing the payment.
  • themeId field to cusomize the appearance of the payment page when creating a payment link.

• POST /payments
  • For payment methods with action.type: redirect, the response no longer contains paymentData.
• POST /payments/details
  • For payment methods with action.type: redirect, you no longer need to submit paymentData.
• POST /paymentLinks
  • Sending a shopperReference of less than three characters now results in a validation error.