Upgrading to Version `71`

[remcotolsma]

Dear Pronamic Support Team,

I am writing to request assistance regarding the upcoming compliance deadline for co-badged cards using Visa/Mastercard and local EU schemes (Cartes Bancaires, Bancontact, Dankort) as informed by Adyen. We are using the Pronamic payment integration with the Adyen plugin on our WordPress website.

According to Adyen's recent communication, it's crucial to ensure that our payment integration complies with the new consumer choice scheme rules by December 31st, 2023. Key aspects to be addressed include:

1. Integration Check and Upgrade: We need to verify and possibly upgrade our current Adyen integration to comply with the new requirements.

2. Payment Scheme Identification: During checkout, our system should clearly identify available payment schemes with equal visual quality and clarity.

3. Inclusion of Credit and Debit Card Options: Our checkout process must include options for both credit and debit cards without discrimination.

4. Upgrading to Version 71: Adyen has released version 71, which includes compliance features. We need guidance on implementing this upgrade.

5. Custom Modifications: If necessary, we might need to change credit card component names in our integration. Assistance on this would be appreciated.

6. Support and Clarification: Any additional support or clarification regarding these changes would be greatly beneficial.

We understand the importance of adhering to these compliance requirements and wish to ensure a seamless transition. Your prompt assistance in guiding us through this upgrade process will be invaluable.

Thank you for your attention to this matter.

Internal HelpScout ticket: https://secure.helpscout.net/conversation/2484929624/26783?viewId=1425710

[remcotolsma]

I just tested v71, the label of the credit card payment method changed in Dutch from "Credit Card" to "Credit en Debit card".

v68

v71

---

I don't think there are any exciting changes that we need to deal with, according to https://docs.adyen.com/online-payments/release-notes/?integration_type=api&version=71:

Breaking Changes

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

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.

Changed

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

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

Removed

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.

New

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

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.

Fixed

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

Deprecated

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.

[remcotolsma]

Upgraded in https://github.com/pronamic/wp-pronamic-pay-adyen/commit/21da986f66472e006f1b04a9d3b79870ce6f2227.