A user reported seeing the message “User Authentication Failed” when attempting to charge a customer’s credit card. This led me to something that may or may not be the cause of the error message, but I’d like to know the answer either way.
When you check the Credit Card Order checkbox in the Order Entry | Header | Credit Card tab (OrderHed.CreditCardOrder), it populates fields like OrderHed.CCZip, which are displayed in a box called Address Verification.
Where are these fields populated from? When we update a customer’s billing address, their old address keeps showing up in these OrderHed.CC* fields.
I guess there could be a use case for the address associated with a credit card being independent from the customer’s billing address. The problem is that the OrderHed.CC* fields aren’t editable in Order Entry, so the address of the first successful transaction becomes permanently associated with the card. Hopefully the solution is as simple as customizing the fields to be editable.
Well if you have another successful transaction it should be the new address going forward… Remember it grabs the Last aka “Most Current” succesful transaction.
Same goes if their card expires… just on the next order, use the new card details and problem solved.
The Catch-22 is that if the customer’s billing ZIP changed, you won’t have another successful transaction. The address from the last successful transaction will be declined, and you can’t edit the field to run a transaction with the new ZIP. (That’s assuming the CC* fields are what is sent to the gateway. That’s my doubt about whether this has something to do with the error message that was reported.)
I do see the reason, you dont want Order Entry folks to change values for the Customer… that would be a SOX Violation… But the Person receiving cash via Cash Receipt Entry, probably can overwrite those fields… Maybe make a Deposit to the SO.
So if a customer calls and says, “here’s my credit card number and ZIP”, the CSR can handle it. But if a customer calls and says, “same card as last time, but my ZIP changed” (which would be verified by the gateway), the CSR can’t do it for legal reasons?
I already call myself a Git lawyer. I hate it when programmers have to be actual lawyers.
I guess Because ultimately to process a Card you only need the Zip – and card number, 3 digits, first name last name… the Address is not required, neither is the city or state. But for some reason we still collect it.
Indicates whether you want to move the Street Address and Postal Code for the credit card transaction into the Street and Zip fields for the credit card processor.
When you select this check box, you activate the address verification fields (Street Address and Postal Code) on the Order Entry - Credit Card sheet. Users can then enter information in these fields.Knowledge Page - EpicCare.pdf (107.8 KB)
Checked the box in Credit Card Configuration and saved. Created a new test order to make sure the old one wasn’t carrying any old settings. No difference. The street address and postal code remain un-editable and are still populated with the old, incorrect ZIP. The city and state are editable, but they always were. The same fields are editable or not in Cash Receipt Entry.
Restarting Order Entry didn’t help. I’ll follow up with Epicor. I’m on an ancient version, so maybe this was a half-implemented feature that was completed in 700.
Let us know when you find the solution for older versions. Maybe they will just say you need an Updatable Dashboard – or throw in a RowRule on the Form Customizations and override the Disabled Flag.
Because ultimately to process a Card you only need the Zip – and card number, 3 digits, first name last name… the Address is not required, neither is the city or state. But for some reason we still collect it.
