Create Customer Profile requests with emails containing a + symbol return E00013 "email is invalid"
Request without error: http://www.screencast.com/t/a5sxNsEn
Request with error: http://www.screencast.com/t/RZPbDcl57S
Request and response without error: https://gist.github.com/jantzenw/cf672ec18b36ac069109dcb452a2d525
Request and response with error: https://gist.github.com/jantzenw/a65636cd78f9757b5eb1222dd63766d5
The first instance of this error was today at 2018-03-29T14:23:40+00:00.
It is critical that the email validation be updated to allow + symbols because this is a valid email character: https://support.google.com/mail/answer/22370?hl=en#alias. This is commonly used in testing to allow multiple accounts to share the same inbox.
โ03-29-2018 08:54 AM
We appreciate everyone who has commented about the impact on their systems. Our product team is carefully reviewing all of your feedback plus additional received through other channels.
Please stay tuned, if there are further developments, we'll post to this thread.
Richard
โ04-03-2018 07:14 PM
How is the last update at 7:00 pm yesterday? The lack of communication on this is unacceptable and the update to disallow a legal email character is unaccetable and frankly, surreal. This issue is affecting multiple companies for account creation in this thread. There has been little to no communication from auth.net. Additionally, the responses have all been a different story.
Are you fixing this or just reviewing? What does your comment even mean?
"Our product team is carefully reviewing all of your feedback plus additional received through other channels."
Please update us ASAP
โ04-04-2018 08:46 AM - edited โ04-04-2018 08:47 AM
Hi All ,
Thanks for the patience with this issue .
The team is working on getting the fix out for it early next week .
Will keep the thread posted on updates .
Thanks
โ04-04-2018 10:34 AM
Thank you for updating this thread. I am glad to hear there is a fix in the works. Though the ETA of "next week" seems like a long time considering your team pushed this to production. I wanted to comment and keep up the pressure. My logs are filling up with this error. Seems like real commerce conversions are being lost.
โ04-04-2018 10:51 AM
This is pretty rediculous and causing your customers actual revenue loss for customers who may have a + sign in their 100% valid email address... Fix/rollback should be released Immediately.
โ04-05-2018 11:22 AM
The proper way to avoid SQL injection is to escape or strip characters. Blocking valid (and very common) email addresses is ridiculous. Your slow response to a production issue that is blocking valid transactions and costing your customers sales is also ridiculous. This is yet another example of why I advise all my clients away from Auth.net whenever possible.
โ04-05-2018 02:59 PM
Hi All
The fix for the + sign was pushed last night to prod .
Again we are sorry for this mishap and doing internal RCA to avoid such issues for future .
Please do keep me posted in case any such issues .
Thanks
โ04-09-2018 10:16 AM - edited โ04-09-2018 10:17 AM
Thanks for the update, Anurag, this appears to be working again through the API.
Unfortunately, on the sandbox server through the CIM interface, there still seems to be a restriction. See https://i.imgur.com/4AiiNfc.jpg for a screenshot. I cannot update an existing user's email to contain "+".
โ04-17-2018 05:51 PM
Hi @schmich
Yes thats an existing behaviour and we are looking into unifying the validation across the API & UI in our future releases .
Thanks
Anurag
โ04-18-2018 12:06 PM
It seems that the restriction is still being enforced in the UI. I also found the same restriction affecting the getCustomerProfileRequest email field.
Any update on this fix?
โ08-09-2018 02:52 PM