|
Elizabeth
|
May 26, 2016 at 5:39 pm
My customer has Authorize.net on the site….
Today a customer registered and paid with an AMEX. On Authorize.net’s side it was declined because AMEX was not ready on their account. On EE end, it approved the transaction, so the customer almost got a free class. They only caught it because they logged into Authorize.net and saw the Declined transaction.
|
|
Tony
|
May 27, 2016 at 3:24 am
Hi Dorian,
Are you using EE3 or EE4 on this site?
What is the default registration status set within the event itself?
|
|
Elizabeth
|
May 27, 2016 at 8:56 am
EE4
|
|
Elizabeth
|
May 27, 2016 at 8:57 am
What do you mean by What is the default registration status set within the event itself?
|
|
Tony
|
May 27, 2016 at 9:04 am
If you edit the event this user registered onto, look within the ‘Event Registration Options’ and you will find a ‘Default Registration Status’ setting – http://take.ms/vDYz6
In that example it is Pending Payment, what is it set to on yours?
As its EE4 you should be able to view the Transaction for this user (View the Registration and click the ‘View Transaction’ button)
There you will find a Auth.net payment, what does it show for Gateway Response? Here is an example from a PayPal Payment – http://take.ms/vDYz6
|
|
Elizabeth
|
May 27, 2016 at 9:18 am
Says “Pending”
Her transaction status says: Transaction Status: Complete
Current Registration Status : Approved
|
|
Tony
|
May 27, 2016 at 9:20 am
What does it show for Gateway Response?
|
|
Elizabeth
|
May 27, 2016 at 9:34 am
She went in a manually adjusted the info, so it is gone.
They only take AMEX if someone calls in, so the Auth payment needs to send the customer back an error if the try to use AMEX through auth.net.
|
|
Tony
|
May 27, 2016 at 9:57 am
The payment within the transaction takes all of the details from Auth.net so it heavily depends on what they (auth.net) send to you your site.
Has the user enabled Amex within their Auth.net account?
Without any kind of error we can’t say how this happened.
During testing Amex cards reject when they should and are accepted when they should, the payment (and transaction) follows this, so we need to know what happened with this payment.
Can I take a look at the logs on your site? If so you’ll need to send temporary admin login details using this link:
https://eventespresso.com/send-login-details/
|
|
Elizabeth
|
May 31, 2016 at 2:10 pm
Did you get a chance to log in?
|
|
Tony
|
May 31, 2016 at 2:25 pm
I’ve just double checked and as far as I can tell we have not received login details for your site.
If you can use the above link to send the details (assigning them to myself) I’ll take a look into this.
|
|
Elizabeth
|
May 31, 2016 at 2:27 pm
I did a few days ago…I’ll try again.
|
|
Tony
|
May 31, 2016 at 3:25 pm
Thank you, I received the login details.
So I checking into transaction 2329 on your site.
The log files show the response from Auth.net, but they are not from an Amex card, they are from a visa card and the payment was accepted. The response was an approved payment from Auth.net with a response code of ‘1’, which basically means auth.net accepted that payment.
You mentioned earlier the user had already been in and altered the details within the transaction, I don’t know what they have changed but as far as auth.net’s response is concerned they payment was accepted. Have you double checked within the auth.net account to confirm the payment did not go through?
|
|
Elizabeth
|
May 31, 2016 at 3:32 pm
It was Registration # 3273 – Ann Anderson
|
|
Elizabeth
|
May 31, 2016 at 3:33 pm
She ended up deleting the Auth.net info and manually entering it.
|
|
Tony
|
June 1, 2016 at 11:22 am
Ok so I had a look into that registration and I can’t see any reason for the transaction to have been complete. All of the log entries show the payment as declined and as the transaction has now be edited I can track it down any further so unfortunately I can’t investigate to find out why.
However I did find another registration #3270 that attempted to pay using Amex and has the payment has same response codes as the other transaction. That registration rejected the payment and then the admin accepted and applied it through the admin, so it appears the auth.net payment methods is rejecting Amex cards as expected.
I did notce an issue with one of the registrations on the site, #3291
If you view the registration you’ll notice the tables look different from the others – https://monosnap.com/file/n7CnbKkX7REx0x1wJ8jU3f294EiWjp
Notice there is no event/ticket information shown?
If you view the Transaction you’ll find similar there – https://monosnap.com/file/fYzT2bapFb7JswIwXDrd289QnhRMcn
Theres no tickets within the transaction so EE does not know what to apply the payment to and shows overpaid.
The only time we have seen this happen is when Admins add registrations from within the admin and ether open up multiple tabs and switch between different registrations at the same time, or use the browser back button to add multiple registrations. In order for the admin registrations to work can not do either of those and must complete the registration before moving onto another (we have multiple warnings shown within EE when this happens)
|
