Release notes

• Added the encryptedCard parameter to the /storedPaymentMethods endpoint. This parameter is used for card encryption with JWE.

• The /cardDetails response now includes:
  • fundingSource: the funding source of the card, for example DEBIT, CREDIT, or PREPAID.
  • isCardCommercial: indicates if the card is a commercial card or a consumer card.

• Fixed an issue where payments with the following paymentMethod.type would break in some cases:
  • klarna
  • klarna_account
  • klarna_paynow
  • klarna_b2b
  • walley
  • walley_b2b
  • ebanking_FI
• When blockedPaymentMethods is set to scheme, Bancontact is no longer blocked.

For integrations using Drop-in or the Gift card Component:
Drop-in and the Component now correctly get the last four digits of gift cards from the API response and show them on the payment form.

To be compliant with regulations, the logo you can download for Visa/Dankort has been updated.

• POST /paymentMethods:
  • To comply with EU consumer choice regulations, The name of the payment method group for cards is now Cards instead of Credit Card. When you use Drop-in with this API version, the payment method list shows this payment method group as Cards.
• POST /payments:
  • When you make a partial payment with a gift card, and the shopper gets redirected for 3D Secure 2 authentication, the return URL includes redirectResult instead of MD and PaRes. This aligns with other 3D Secure redirect flows.
• POST /paymentLinks:
  • When you create a payment link through the API, the setting to store payment method details in the Customer Area no longer works. Instead, you have to use the storePaymentMethodMode parameter to indicate if the details of the payment method will be stored.
  • metadata: more than 80 characters will result in a validation error.

• POST /paymentLinks:

  • expiresAt format is now ISO 8601 with a time zone offset indicator (YYYY-MM-DDThh:mm:ss+TZD). For example, 2020-12-18T10:15:30+01:00. This format is consistent with the other timestamps that we return.

    Previously, the format included the timezone indicator Z.

For the /sessions request using a stored payment method with recurringProcessingModel:CardOnFile, the shopperInteraction is now correctly set to ContAuth for subsequent payments.

Fixed an issue rare internal issue that caused the /payments response to not include a resultCode.

Platforms can now book chargeback fees separately from the disputed amount, to a balance account specified in the platformChargebackLogic.costAllocationAccount field of the /payments request.

When using /sessions for Drop-in and Components, it is no longer possible to have more than 5 refusals per session.

Responses to Amazon Pay POST /payments requests now contain additionalData.amazonPayToken. You can use this token as a reference, for example when troubleshooting your payment directly with Amazon Pay.

• For the /payments or /sessions request to store payment details or make a payment with stored payment details:
  You now must include the recurringProcessingModel parameter.

• For the /sessions request to store payment details:
  You now must include the recurringProcessingModel parameter.

• For the /paymentMethods/balance request to check a gift card balance:
  You now must include the amount parameter.

• For Pix, the /payments response no longer includes action.url. You must use action.qrCodeData to render the QR code.

• You must now make a /payments or /sessions request to store payment details. You can no longer configure it from the Customer Area.

• For the /sessions request:

  • The storePaymentMethod parameter. Use storePaymentMethodMode instead.
  • If the required reference parameter isn't included, you now get a validation error.

• For /payments and /sessions requests including line items for custom risk rules:
  You can now use the lineItems parameter instead of additionalData.riskdata.basket.

• The /storedPaymentMethods endpoint:

  • Make a GET request to list the stored payment details for a shopper, if there are any available.
  • Make a DELETE request to disable stored payment details to stop charging a shopper with the particular recurring detail ID.

• For /sessions and /paymentLinks requests:
  You can now include the storePaymentMethodMode parameter to set when to store the shopper's payment details.

• For the /paymentMethods request:
  When you include the shopperReference parameter, stored payment details in the response now contain the supportedRecurringProcessingModel parameter.

• For specific industries, such as hospitality, you can specify a reason when making a merchant-initiated transaction with stored payment details. In the /payments request, include the industryUsage parameter to specify a reason for the payment. Possible values:

  • delayedCharge.
  • noShow.
  • installment.

In the Customer Area, on the Settings > Checkout Settings page:

• Turning on the enableRecurring toggle no longer adds the required parameters to store payment details in payment requests.
• Turning on the enablePayout toggle no longer adds the required parameters to store payment details for payouts.

• For /payments and /sessions requests to make payments with stored payment details:
  When you include shopperInteraction: ContAuth and recurringProcessingModel: CardOnFile, the transactions now always get processed as CardOnFile payments.

• If you contacted our Support Team to enable filtering payment methods based on your store, when making a /paymentMethods or /sessions request including store:
  The response now includes only payment methods available for the specified store.

• For /paymentMethods and /sessions requests including allowedPaymentMethods with scheme and card in the array:
  The response no longer includes wallet payment methods.

When you enable receiving the fraudResult parameter in the /payments/details response, you now receive it for 3D Secure 2 transactions. Previously, fraudResult wasn't returned for 3D Secure 2 transactions.

Support for setting credit card installment options in the /sessions request.

Added support for partial authorization. This allows shoppers to pay for their goods with another card, if the balance of their initial card is less than the value of the goods.

Fixed issue where the /payments and /payments/details responses incorrectly showed BCMC cards as Mastercard or Visa. The payments were correctly handled as BCMC, but the reponses had the incorrect paymentMethod.brand.

POST /payments

• The fraudResult.results list now no longer contains the FraudCheckResult for each list item. Each list item now only contains the values of the individual risk checks. See code samples.

POST /paymentMethods

• The format of the expiryYear returned for stored cards is now the last two digits of the year.

POST /sessions

• authenticationData object in the request.

POST /payments

• authenticationData object in the request.
• paymentMethod object in the reponse.

POST /payments/details

• authenticationData object in the request.
• paymentMethod object in the reponse.

Fields related to 3D Secure authentication are now grouped under the new authenticationData object. The old 3D Secure authentication fields have been deprecated.

See field mapping and code samples.

Fixed an issue where some payments with redirect data couldn't be completed.

• You can now use the /donations endpoint on all versions of the API.

• If Amazon Pay is configured as a blocked payment method, it's no longer returned in the /paymentMethods response.

Fixed an issue where 3D Secure 1 redirect flow couldn't be completed.

Fixed an issue where payment requests with a billing address had the stateOrProvince field populated with ZZ.

Fixed an issue with Prosodie and Illicado gift cards where the balance check request always returned a Success result code.

We fixed an issue where iDEAL payments could be refused if the POST /payments request included a store.

• The POST /paymentMethods repsonse now contains the brands array for Bancontact.

• Fixed an issue where metadata for 3D Secure payments wasn't being returned in the CANCELLATION webhook. To get this metadata, you need to configure it as an additional setting.

• POST /paymentMethods
  • The details array has been removed.
  • The list of issuers for payment methods like iDEAL or Dotpay, is now in the paymentMethods.issuers array.
  • For cards, if the paymentMethods.brands array has a single element, the value of the paymentMethods.name is now the brand name of the available card brand, instead of Credit Card.
• POST /payments
  • checkoutAttemptId replaces conversionId.
• POST /paymentLinks
  • amount.value fields now must be integers. Values like 10.5 now produce a validation error.
• GET paymentLinks/{linkId}
  • New status value, paymentPending for payment methods that have a pending state. Previously, such states had the completed status.
• For payment link resources, storePaymentMethodMode replaces storePaymentMethod from previous versions. The allowed values for storedPaymentMethodMode are:
  • disabled (default), the shopper's payment details are not stored.
  • enabled and shopperReference is provided, the shopper's payment details are stored.
  • askForConsent, the shopper can choose in the Pay by Link UI if they want their payment details to be stored.

• POST /sessions: creates a payment session for Web Drop-in and Web Components integrations.
• POST /paymentMethods
  • For payment methods with issuer lists, each issuer object now has a disabled field indicating if the issuer is available.
• POST /payments
  • Responses with action.type: qrCode now contain the expiresAt field which has the expiry date in ISO8601 format.
  • In your request, you can now send all the fields from the EMV 3D Secure 2.1.0 specification.
  • mpiData.tokenAuthenticationVerificationValue
• POST /orders
  • The initial amount of the order is always returned in the amount object.

• POST /paymentLinks
  • Fixed an issue where the payments page didn't show a phone number field when configured as part of requiredShopperFields.

• POST /payments and POST /donations requests:
  • homePhone
  • mobilePhone
  • workPhone
  • deliveryEmail
  • challengeIndicator

• POST /payments
  • All address fields are now optional.

Fixed an issue where girocard_applepay didn't appear in the brands array for Apple Pay in the /paymentMethods response.

Fixed an issue where JCB cards enabled for Apple Pay would show up as part of the paymentMethod.brands array instead of the brands array for Apple Pay. This means Web Drop-in and Components would render the Apple Pay logo as part of the Card Component.

POST /paymentLinks

• themeId field to customize the appearance of the payment page when creating a payment link. This field is available in Checkout API v67 and later.

All lists of countries/regions are now ordered alphabetically for each translation.

We fixed an issue where a splits array included in the /payments/{paymentPspReference}/captures request was not processed correctly.

• Finnish e-banking now appears as Verkkopankkimaksu in the front end when the locale is set to fi-FI.

• For iDEAL payments, sending emoji in the productTitle no longer causes an error during the redirect.

For redirect 3D Secure payments, the amount object in the /payments/details response is now returned in the same way as for all other payments.

For native 3D Secure 2 payments, the amount object in the /payments/details response is now returned in the same way as for all other payments.

• Splitting funds for Adyen for Platform accounts is now possible when doing refunds and amount updates.

• Fixed an issue where he /payments/details response did not contain the 3D Secure 2 fields in the additionalData object.
• Website cross-origin isolation using COOP and COEP is now supported for Web Components 3.4.0 and above, as well as all assets on checkoutshopper.

Card data decryption failures now return the correct error 174 - Unable to decrypt data, instead of 175 - Unable to parse JSON data.

We improved the error message that you get when including an invalid redirectResult in the /payments/details request.

We fixed an issue where shoppers couldn't add a gift card payment to an existing order.

Checkout API v67 and above now supports the 3D Secure authentication-only flow.

In Checkout API v64 and below, the /paymentMethods response now has supportsRecurring: true for cards.

Note that supportsRecurring was removed in Checkout API v65.

When the shopper cancels a Bancontact mobile payment, you will now receive a resultCode Cancelled instead of resultCode: Unknown as before.

You can now do your captures, refunds, cancellations, reversals, and asynchronous authorisation adjustments using the Checkout API.

Have a look at the new endpoints in API Explorer:

• /payments/{paymentPspReference}/captures
• /payments/{paymentPspReference}/amountUpdates
• /payments/{paymentPspReference}/refunds
• /payments/{paymentPspReference}/reversals
• /payments/{paymentPspReference}/cancels
• /cancels

For the 3D Secure 1 flow in v67, the fraud result is now correctly returned in the /payments/details response.

Fixed an issue affecting v67, where the pspReference was missing from the /payments/details response for Zip and Afterpay Touch.

Added support for cross-origin isolated websites.

For iDEAL payments in v66 and earlier, you will now get a validation error when making a /payments/details request with a redirectResult and paymentData belonging to different payments.

For the 3D Secure redirect flow in v67, we fixed an issue where the merchantReference could be missing from the /payments/details response.

Fixed an issue where adding a gift card payment to an order could result in a validation error if the request was made using one of our plugins.

For the native 3D Secure 2 flow in Checkout API v67 and above, we fixed an issue where the merchantReference was not returned in the /payments/details response.

• We fixed an issue where the PayPal Component could fail when doing a zero-auth transaction.
• For Amazon Pay, we fixed an issue where a redirect 3D Secure flow was incorrectly triggered instead of the native 3D Secure flow.

When making an /applePay/sessions request, you no longer receive an error when specifying a domainName with a slash (/) at the end.

We fixed an issue where a /payments response with status 500 (Internal Server Error) could include an incorrect pspReference value.

For 3D Secure redirects, the loading page now has text informing the shopper that the process might take a few minutes to complete.

For Checkout API v67 and above, making a /payments/details request with a URL-encoded redirectResult no longer results in a validation error.

• 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.

• Recurring BACS Direct Debit payments no longer generate an error in the test environment.

Fixes an issue where updating stored card details using an alias would not work.

You no longer receive a validation error when making a valid payment request for Japanese convenience stores.

Making a BLIK payment with saved payment details no longer results in an error.

• We've added a button that the shopper can select in case they are not automatically redirected back to your returnUrl: Click here if you are not redirected.

We fixed an issue where a /paymentMethods request with amount:0 would sometimes return an empty response.

• POST /paymentMethods

  • For Apple Pay and Google Pay, the response now contains the brands array.
  • If you enabled Boleto Bancário, the response now contains paymentMethod.type: primeiropay_boleto for Boleto Bancário payments through PrimeroPay.
  • New payment method: bank transfer, with paymentMethod.type: bankTransfer_IBAN.

• POST /payments

  • If you enabled Boleto Bancário, you can now include paymentMethod.type: primeiropay_boleto to make a payment with Boleto Bancário through PrimeroPay.
  • For bank transfers:
    • The request has paymentMethod.type: bankTransfer_IBAN.
    • The response has action.type: bankTransfer and action.paymentMethodType: bankTransfer_IBAN.

• POST /payments

  • For redirects, except 3D Secure redirects, the response now contains details.key: redirectResult instead of details.key: payload.
  • Sending a shopperReference of less than three characters now results in a validation error:

    Copy code
    {
    "status": 422,
    "errorCode": "216",
    "message": "The shopper reference must be at least 3 characters long.",
    "errorType": "validation",
    "pspReference": "R8QTPCQ8HXSKGK82"
    }

• POST /payments/details

  • For redirects, except 3D Secure redirects, redirectResult is now the only way to specify the redirect result in the request, replacing payload.

• GET /paymentLinks/{linkId}

  • In the response, the status field now returns completed instead of paid to avoid confusion for payment methods that require an additional action.

The error messages for client key issues now contain more information about the exact cause of the problem.

When using saved payment details to make a payment, the payment no longer fails if you don't specify a paymentMethod.type.

We fixed an issue where making a non-EUR gift card payment with the order object was not working as expected.

• POST /payments: When making partial payments with an order object and without an amount, the API now automatically sets the amount to either the gift card balance or the remainingAmount, whichever is lower.

• POST /payments: Fixed an issue that caused updating stored card details using an alias to fail.

• If using the Klarna widget, you no longer get an error when making a /payments/details request.

• All endpoints
  • When a request fails due to validation errors, the response now returns the pspReference in the response body.
• POST /payments
  • You can now send the following additional parameters when providing risk-related information.
    • riskData.profileReference
    • riskData.fraudOffset
    • riskData.customFields
  • When making a payment with a gift card, the API now requires the paymentMethod.brand.
• POST /paymentLinks
  • You can now use the riskData object to send risk-related settings.
• POST /paymentMethods
  • For gift cards, the response now contains the gift card brand in the brand parameter.
• POST /paymentMethods/balance
  • If the gift card has a limit for how much balance can be used in a single transaction, the response now contains this limit in the transactionLimit field.

• POST /payments
  • BACS payments now have a voucher payment flow. This means the response now contains action.type: voucher instead of redirect.

• POST /paymentMethods
  • The response no longer contains the following parameters:
    • supportsRecurring
    • oneClickPaymentMethods: Use storedPaymentMethods instead.
    • groups: Use brands instead.

For African eWallets and eBanking, the shopperEmail, shopperName, and the telephoneNumber are no longer required parameters for the /payments request.

We fixed an issue in v64 where valid fields could trigger a validation error.

• We now accept shopperLocale with both underscores (for example en_US) and hyphens (for example en-US).

• All endpoints

  • If an API request contains a field that is not recognized, or if the format is not valid, we now return an error message with error code 702 instead of dropping the field. The error message contains information about why the validation failed, for example:

    Copy code
    {
      "status": 400,
      "errorCode": "702",
      "message": "Structure of PaymentRequest contains the following unmapped fields exampleErrorField",
      "errorType": "validation"
    }

• POST /payments

  • For Boleto Bancário, when a shopperEmail is provided, we now send an email with the Boleto code to the shopper.

• POST /paymentLinks

  • In the request, you can now specify installmentOptions.plans and installmentOptions.preselectedValue.

• POST /payments
  • For Bancontact mobile and WeChat Pay, when making a request with paymentMethod.type bcmc_mobile_QR or wechatpayQR, the response now returns Pending instead of PresentToShopper result code. This result code is now consistent with other QR code payment methods such as BLIK and Swish.

• POST /paymentMethods

  • The response for Amazon Pay, Apple Pay, Google Pay, and PayPal now contains a configuration object. Example for Google Pay and Apple Pay:

    Copy code
    {
     "paymentMethods":[
       {
         "configuration":{
           "merchantId":"0123456789"
         },
         "name":"Google Pay",
         "type":"paywithgoogle"
       },
       {
         "configuration": {
           "merchantDisplayName": "Merchant Name",
           "merchantIdentifier": "1000"
         },
         "name": "Apple Pay",
         "type": "applepay"
       }
     ]
    }

• POST /payments

• POST /payments

  • In the response, we have marked a number of fields as deprecated. Although they are deprecated, these fields have not yet been removed from the response and you can still use them.

    In a future version of the API, the deprecated fields will be removed and replaced by fields in the action object. We recommend that you start using the fields in the action object in the response.

    This applies to the following fields:

    Response field	Solution
    authentication	Use the action object instead to get the values to be used in further calls to the /payments/details endpoint. Applies to 3D Secure 2 payments.
    details [InputDetail]	Use the action object instead to get all the fields needed to submit in the /payments/details call.
    outputDetails	Use the action object instead to get the details that will be presented to the shopper.
    paymentData	Use action.Paymentdata instead.
    redirect	Use the action object instead to get information about the redirect URL for payment flows that require a redirect.

• POST /paymentLinks
  • The response now returns the payment link id along with all other parameters sent in the request. In previous versions, the response only contained the URL, expiry date, reference, and amount.
• POST /payments
  • When making a request with paymentMethod.type bcmc_mobile, the response now returns both url and qrCodeData. This allows you to offer both QR code and app redirect to your shoppers.
  • We now return an error if the origin in the request contains more than 80 characters or if the URL is invalid.

• POST /paymentMethods
  • For giropay, the bic is no longer returned in the response. If you are using Web Drop-in or Components, the front end will no longer require a BIC. When shoppers select to pay with giropay, they are now redirected to giropay's website where they can provide their BIC.
  • For Bancontact mobile, the response now only returns bcmc_mobile. This new payment method type combines the bcmc_mobile_QR and bcmc_mobile_app types from previous versions of the API.
  • If transaction rules for payment methods are set up for your account, these are now evaluated when you send a /paymentMethods request.
• POST /paymentLinks
  • If a request is successful, the response now returns HTTP 201 instead of an HTTP 200 result code.

• When risk data are included in the payments request, this no longer results in an invalid signature calculation.

Ratepay Direct Debits payments using Austrian (AT) IBANs is now working.

• onBinValue now works when a card number is pasted into the field. For more information, see Web Components 3.9.0.

• We improved the /paymentMethods response when getting a list of available payment methods in Sweden. This means that if you are using Drop-in or Components and send a /paymentMethods request with countryCode: SE, you'll see the following UI improvements in line with Swedish regulations.
  • The payment method title has been changed to Card.
  • From API version v49 and later: If you support Maestro, the icon for Maestro is shown first.

• If a Klarna payment request is missing invoice lines, you will now receive the following error message: No InvoiceLines provided.

• Optional shopper information sent in an Oxxo payment request will now show up in the Offers tab in your Customer Area.

• We improved the reliability of 3D Secure 1 authentications after partial payments with gift cards.

• We fixed an issue where the 3D Secure 2 flow could break when receiving an unsupported screen.colorDepth value on Google Chrome v83 or v84.
• We fixed an issue where metadata was not being sent back in the webhook event.

Before this version, the /paymentMethods response would return wechatpayMiniProgram and wechatpaySDK if channel:Web. These payment methods are now only when channel:Android or channel:iOS.

To force a card transaction to use a debit funding source, you can now include in the /payments request: paymentMethod.fundingSource: debit .

• The /paymentMethods response now returns ACH also when the request includes amount.value: 0.
• The deviceFingerprint is now correctly propagated for all payment methods.

When updating stored payment details, you can now send in an unencrypted expiration date.

• POST /paymentMethods:
  • For giropay, the response now indicates bic as an optional field.
  • In the response, the brands array only contains scheme payment methods. Previously, tokenized cards, such as Apple Pay, were returned in the same array.

• Native payment method (previously supported through Hosted Payment Pages (HPP)): Swish. Payment method type: swish.

• POST /payments:
  • For Multibanco, the response now contains the action object for type:voucher. You can use the information in the action object to present the voucher to the shopper.

• POST /payments:
  • The response now contains an action object that indicates the action to be taken for completing the payment.
• POST /payments/details:
  • The response now contains the merchantReference field. This is the reference you passed in the /payments request.

• POST /payments:
  • storePaymentMethod replaces enableOneClick and enableRecurring.

• Native payment method (previously supported through Hosted Payment Pages (HPP)): Oxxo. Payment method type: oxxo.

• Native payment methods (previously supported through Hosted Payment Pages (HPP)):
  • Gift cards.
  • Oney. Payment method type: facilypay.

• POST /paymentMethods:
  • For giropay, the Business Identifier Code (BIC) key is now returned in bic instead of giropay.bic.

• Native payment methods (previously supported through Hosted Payment Pages (HPP)):
  • Boleto Bancário. Payment method type: boleto.
  • DOKU. Payment method type: doku.
  • Dragonpay. Payment method type: dragonpay.
  • eContext. Payment method types: econtext_atm, econtext-stores, econtext_seven_eleven, econtext_online.
  • Ratepay. Payment method type: ratepay.

• For WeChatPay, support for payment method type: wechatpayMiniProgram.
• For payment methods that require you to present a voucher to the shopper, the response now includes resultCode:presentToShopper.

• Payment methods:
  • Bancontact:
    • Bancontact card: the shopper pays using a card. Payment method type: bcmc.
    • Bancontact mobile: the shopper pays using a bank app that supports Bancontact mobile. Payment method type: bcmc_mobile.
  • MoMo:
    • MoMo website: the shopper pays using a desktop browser. Payment method type: momo_wallet.
    • MoMo app: the shopper pays using a mobile app. Payment method type: momo_wallet_app.
• POST /paymentMethods:
  • The response now contains the groups object, which is an array of payment methods that will be recognized.
  • For payment methods that support recurring payments, the response now includes supportsRecurring:true.

• For payments with wallet tokens, you no longer need to include to additionalData prefix in the additionalData object. For example, instead of additionalData.paywithgoogle.token, use paywithgoogle.token.

• New payment method types for WeChatPay: wechatpaySDK, wechatpayQR, wechatpayWeb.

• POST /payments:
  • For iDEAL, paymentMethod.issuer replaces paymentMethod.idealIssuer.
  • In the response, details.payload replaces returnUrlQueryString.