[BUG] Using a plus in an email results in an authorized transaction, but no order being created

[erikhansen]

:bug: Bug report

Current Behavior

In a guest checkout, if a user uses a plus (+) symbol in their email (e.g., erik+123@example.com), the Accept Hosted checkout process will fail. The user's credit card will be authorized, but the validation at this line… https://github.com/ParadoxLabs-Inc/authnetcim/blob/c556d14e04e09da80275cf9244d67cce9ba9de59/Observer/PaymentMethodAssignDataObserver.php#L204 …will cause the order to not be saved. The reason is that the $transactionDetails->getData('customer_email') function will return erik 123@example.com, since Authorize.net Accept Hosted apparently doesn't support + in a customer email.

Expected Behavior

I can imagine several solutions to this problem:

1. Prevent + from being used for customer and/or checkout emails - This solution is not ideal since users have become accustomed to being able to use this email format (243 of the 204,647 customers in this client's DB are using a +)
2. Maybe Authorize.net Accept Hosted supports some sort of encoding (such as url encoding + to %2B) that would allow us to use + symbols
3. Change the extension so that everything between a + and an @ symbol in an email is stripped before sending it to Authorize.net, and then change the validation check to compare that stripped down email. The downside to this approach is that users will receive emails from Authorize.net at an email that is different from what they provided.

Minimal reproduction of the problem with instructions

See above for details.

Environment

Authnetcim version: 2.4.4 Magento version: Adobe Commerce 2.4.4-p11 PHP version: 8.1

[erikhansen]

@rhoerr We just encountered this issue in pre-launch testing. I'm curious if you have a solution/recommendation for this? Only 0.1% of customers use +, so we are fine with a simple solution.

[rhoerr]

Hi @erikhansen! Thanks for reporting. Could you try this out? https://github.com/ParadoxLabs-Inc/authnetcim/commit/5392e9d6a9190c9881bfabfeebc46ef90c1fad83

We're not clear why this has only recently started. Seems like a regression on Authorize.net's side, or possibly a bug with their getTransactionDetails endpoint.

A space character is not valid for emails, so changing any encountered spaces to + in the details response seems like a safe operation.

[erikhansen]

@rhoerr Man, you're always one step ahead. We'll try that out and report back, thanks.

[erikhansen]

@rhoerr I hope this is an acceptable place to ask this follow-up question: for the orders that failed to be saved due to the validation in https://github.com/ParadoxLabs-Inc/authnetcim/blob/c556d14e04e09da80275cf9244d67cce9ba9de59/Observer/PaymentMethodAssignDataObserver.php#L204 would you expect that the authorization would be automatically voided? Based on this article, it looks like "We try to automatically void the transaction, but depending on the type of error this is not always possible." It seems like this would be a type of order that could be automatically voided.

In case it's helpful, these are the extension settings:

[rhoerr]

@rhoerr I hope this is an acceptable place to ask this follow-up question: for the orders that failed to be saved due to the validation in ...

Will review in depth when time allows. The code that references is in TokenBase: https://github.com/ParadoxLabs-Inc/tokenbase/blob/master/etc/events.xml#L26 which runs Observer/CheckoutFailureVoidTransactionObserver.php upon sales_model_service_quote_submit_failure.

It could be that event doesn't trigger here, or any of the numerous conditions falls through.