Opayo payment integration error - Unprocessable Entity

[akabucko]

Describe the bug

Once upgrading the Formie plugin to version 2.1.10 or above, Opayo payment integration stopped working causing an error on the form letting users pay with the following error:

Client error: POST https://pi-test.sagepay.com/api/v1/transactions resulted in a 422 Unprocessable Entity response: {"statusCode":"3078","statusDetail":"The CustomerEMail format is invalid.","transactionId":"(truncated...)

I have a multi-step form that pays invoices through the Opayo payment integration. The bug seems to have been introduced in the 2.1.10 update and in the changelog, there is a fix for Opayo which could have introduced the issue - Fixed Opayo payments not sending customer email address. In the error above the email field is 'CustomerEMail'. Could the naming convention here be causing a problem? If not, is there anything you would advise me to check to fix the issue?

I've currently downgraded to 2.1.9 which is working fine while I investigate the issue too but thought I'd mention it incase its a bug.

Steps to reproduce

1. Fill in the Opayo integration form passing validation checks
2. Once the user submits an error validation message appears
3. Error message - Client error: POST https://pi-test.sagepay.com/api/v1/transactions resulted in a 422 Unprocessable Entity response: {"statusCode":"3078","statusDetail":"The CustomerEMail format is invalid.","transactionId":"(truncated...)
4. The user is unable to submit the form and pay through Opayo.

Form settings

• Multi-page form: Yes
• Submission Method: Ajax
• Client-side Validation: No
• Custom Form Templates: No
• Opayo Payment: Yes

Craft CMS version

4.9.4

Plugin version

2.1.10

Multi-site?

No

Additional context

No response

[engram-design]

Interesting. So that commit was about failing to send the email address correctly at all, it simply wasn't being sent.

I was working with an agency on Opayo and some other fixes. At the time during testing, I noticed that the emails started to throw an error, despite them not having done so to that point.

I didn't think that the casing mattered - customerEmail vs CustomerEMail, but maybe it does?!

Out of interest, does the change at https://github.com/verbb/formie/blob/67b5ec3ddce25c1b7ce12231924c41f3711f2a92/src/integrations/payments/Opayo.php#L792 make a difference? The Opayo docs are a bit here, there and everywhere on the matter.

[akabucko]

Interesting. So that commit was about failing to send the email address correctly at all, it simply wasn't being sent.

I was working with an agency on Opayo and some other fixes. At the time during testing, I noticed that the emails started to throw an error, despite them not having done so to that point.

I didn't think that the casing mattered - customerEmail vs CustomerEMail, but maybe it does?!

Out of interest, does the change at

https://github.com/verbb/formie/blob/67b5ec3ddce25c1b7ce12231924c41f3711f2a92/src/integrations/payments/Opayo.php#L792

make a difference? The Opayo docs are a bit here, there and everywhere on the matter.

That seems to be the change that has caused the issue, once I've made the code change it gives me the same error again and won't let me submit the form (screenshots attached).

Client error: POST https://pi-test.sagepay.com/api/v1/transactions resulted in a 422 Unprocessable Entity response: {"statusCode":"3078","statusDetail":"The CustomerEMail format is invalid.","transactionId":"552A1C99-6E0E-8436-A0FD-DD26 (truncated...

The Opayo docs aren't the best, are they? Do you think this is a casing issue then?

Thanks for your help on this!

[engram-design]

Just to be clear, if you manually modify that line from:

$payload['customerEmail'] = $this->getFieldSetting('billingDetails.billingEmail');

to:

$payload['customerEMail'] = $this->getFieldSetting('billingDetails.billingEmail');

That makes the error go away and the email be sent to Opayo?