"An unexpected error occured." when User Edits Account
My partner Dave and I hired a fellow to develop a site which uses CG and authorize.net. My partner and I are about to launch the site, but we're having a few issues in testing that I hope you can help with...
I created a test user called "demouser" and signed up with an authorize.net "dummy" VISA card: 4111-1111-1111-1111 as authorize.net allows.
The account was created and I can see the user in CheddarGetter. However, whenever this test user (i.e. me for now) attempts to make any changes to his account, he's given an error message:
There were problems with the following fields:
An unexpected error occured. Please try again later.
That's all of the information given. My developer says:
This issue must be related to Authorized.net -> CheddarGetter as
when you're in test mode, this issue doesn't come up, so there may be
something that CheddarGetter doesn't require, but ADN does require and
we're not transmitting it (as cheddargetter doesn't need it).
The thing is, CG is in test mode (as is authorize.net) on my account (our product name is "Evolvr"). So what's the problem? Why can't our demo user change his account settings? How do we resolve the issue?
Is "CIM Validation Mode" on https://cheddargetter.com/admin/gateway/edit new? I don't recall seeing it before.
Discussions are closed to public comments.
If you need help with Cheddar please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Marc Guyer on 17 Feb, 2010 11:11 PM
Hmm... test mode on the authorize.net side is a bit annoying. It doesn't let you do much of anything. Maybe you haven't seen the error report: http://cheddargetter.com/admin/report/errors
This message is also displayed at the top of the customer detail page in CG:
Where are you seeing this?
I suspect that this message is being displayed in your app as a fallback for when CG has returned an error message that your app doesn't have an error handler for.
CIM Validation Mode is new. Until recently, CG used the mode that we found appropriate under various circumstances. That decision was made before VISA started shaking things up regarding card validations. Whatever the reason, we decided it was a better idea to allow you to determine which validation mode you want. Since your plans all have an immediate charge at signup, you should probably just set this to 'none'. More information at the bottom of this article: http://support.cheddargetter.com/faqs/getting-started-19/configuring-authorizenet
Support Staff 2 Posted by Marc Guyer on 17 Feb, 2010 11:18 PM
Also, I just read a post about your service which talks about accepting non-US credit cards. This is possible if you do not use AVS. Again, more info on that here: http://support.cheddargetter.com/faqs/getting-started-19/configuring-authorizenet. Under the AVS section in that article it states:
3 Posted by Erik J. Barzesk... on 18 Feb, 2010 05:56 AM
Thanks for the response. Nothing shows up in the error log when I (the demo user) try to change my membership plan on my site. The error shows up on my site, I mean, but not in the error log in CG (https://cheddargetter.com/admin/report/errors).
Thanks for the info on international credit cards. I'll look into that.
Support Staff 4 Posted by Marc Guyer on 18 Feb, 2010 03:57 PM
Thanks Erik -- We've found the error in our logs and found the bug -- it's an obscure (and odd) Authorize.Net behavior. We'll be releasing a patch to workaround the problem this afternoon. Stay tuned...
5 Posted by Erik J. Barzesk... on 18 Feb, 2010 04:11 PM
Staying tuned. Thanks.
On the issue of international cards, do you recommend we automatically substitute a valid zip code if someone puts in an international postal code? We'd prefer not to put text that says "If you're outside the U.S., just put 90210" because that makes the whole thing look awfully insecure.
So do you recommend doing it automatically if the billing code the person types in is not a valid U.S. zip code?
Support Staff 6 Posted by Marc Guyer on 18 Feb, 2010 04:40 PM
Good question. This is a fraud concern. I have to officially recommend
requiring domestic zip code for all transactions.
However, if you choose to accept non-US credit cards, then just ask the
customer to indicate that they don't have a zip code (or their credit card
billing address is outside the US). The key is in the AVS settings. If
you uncheck "G" then the only time a card will be accepted without a zip or
with a bogus zip is when the card issuing bank does not support AVS, which
essentially means that the card issuing bank is outside of the US. This
way, if the card issuing bank is a domestic one, zip will still be required.
7 Posted by Erik J. Barzesk... on 19 Feb, 2010 03:18 PM
I'm still seeing the unexpected errors with nothing to show in the Error Log. Was this bug fixed? We'd like to launch later today.
Support Staff 8 Posted by Marc Guyer on 19 Feb, 2010 04:35 PM
We should have a patch deployed this afternoon.
Support Staff 9 Posted by Marc Guyer on 19 Feb, 2010 09:26 PM
Ok -- the fix is out.
10 Posted by Erik J. Barzesk... on 19 Feb, 2010 10:52 PM
Thanks. Looks like it's working here. Appreciate it.
I think you might have misunderstood my earlier question about zip codes. Or I misunderstood the response. :-)
We'll require the zip code for all U.S. addresses. I'm trying to figure out the best way to handle international cards - do we supply any U.S. zip code? Do any five digits work (i.e. 11111)? Should we automatically try "11111" if the user enters a non-five-digit code (i.e. it's likely to be international)?
It seems that's the best way to go because:
a) if it's a U.S. card and they mistyped their zip code as five digits, it'll be declined.
b) if it's a U.S. card and they mistype their zip code with an A or only typing 4 digits and we thus auto-substitute "11111" then it'll be declined just like a
b) if it's an international card and we substitute 11111 because they've typed "Q85 P5M" or something as their code, it'll go through.
d) if it's an international card and they type 90210 or something themselves, it'll go through.
So the auto-subbing if the user enters an inappropriate code seems to be the best option... yes?
Support Staff 11 Posted by Marc Guyer on 19 Feb, 2010 11:09 PM
I suggest asking the customer if they have a US zip code. If they do, they must enter it correctly. If they don't have a US zip code, you don't need to pass CG anything (or you can provide a bogus one).
12 Posted by Erik J. Barzesk... on 19 Feb, 2010 11:24 PM
OK, so what about an international customer who puts something in the zip code field? Am I correct in assuming that's the same as the third case you've listed above?
Support Staff 13 Posted by Marc Guyer on 20 Feb, 2010 12:32 AM
That is correct.
14 Posted by Erik J. Barzesk... on 20 Feb, 2010 04:09 PM
So I have one question left. The guide says "In that case, just send CheddarGetter any valid zip code like "90210", for example." Is that a requirement or is it largely irrelevant what the international card user types?
Support Staff 15 Posted by Marc Guyer on 20 Feb, 2010 04:41 PM
If you send anything via the ccZip field, it must be 5 digits. You can
also not send the ccZip at all when the customer is using an
international card.
EDIT: This is no longer true. 5 digit format restriction has been lifted. This was done to allow acceptance of non-US postal codes.
16 Posted by Erik J. Barzesk... on 05 Mar, 2010 04:41 PM
Our developer tells me that sending nothing creates a problem. Is it related to the fact that we have "Require credit card billing zip code" checked in our settings?
Temporarily he's worked around this by submitting "12345" for International customers (I think).
Again, we'd like to require the zip code for our U.S. customers (and AVS is set up that way), but we don't want our International customers to see a dummy zip code just to get through processing.
We had a customer sign up and he first tried leaving the zip code field blank, then he tried using his native (Sweden or something) postal code, both of which our developer removed and submitted as a blank to CheddarGetter. This resulted in errors (on March 2).
subscription[ccZip]:isEmpty: A value is required
Support Staff 17 Posted by Marc Guyer on 05 Mar, 2010 04:51 PM
Yes, this is due to the "Require credit card billing zip code" being checked in CG.
You can uncheck that and it will still be "required" at the gateway for AVS purposes (for US customers).
We actually just released an update that accepts more billing address fields and lifts the 5 digit format restriction on the zip code field. We did this to allow for any type of postal code. So, now you can allow an international customer to enter anything and it will be accepted by CG. CG will pass that on to the gateway. As long as you have "G" unchecked in your gateway settings, the international customer will be approved.
18 Posted by Erik J. Barzesk... on 05 Mar, 2010 05:12 PM
Great. I'll talk to our developer and have him sync up with this. Obviously we'd like to accept blank postal codes AND international postal codes like "A3C 4J9" for international cards as well as accept and enforce proper zip codes for the U.S.
Can you clarify when "just released" was? Our developer was trying things as recently as yesterday morning.
If our developer has any questions I'll ask that he post them here.
Support Staff 19 Posted by Marc Guyer on 05 Mar, 2010 06:14 PM
It was this morning.
Also, I was poking around your account and discovered that your "Customer Account URI" in settings is incorrect.
Just checked out your demo. I might just signup someday down the road.
20 Posted by eric on 11 Mar, 2010 07:08 PM
I'm also getting the "An unexpected error occured," but when trying to create a customer. Additionally, the error isn't logged in the errors report.
I checked my authorize.net settings against the minimum required by CG in http://support.cheddargetter.com/faqs/getting-started-19/configurin... , and everything looks right. My authorize.net account is currently in test mode, but I tried switching to live mode and had the same problem.
Also, excluding a field or providing badly formatted data will trigger the expected validation errors, it's only when submitting what appears to be valid data that I get the unexpected error.
Any suggestions?
Support Staff 21 Posted by Marc Guyer on 11 Mar, 2010 07:44 PM
You've found a small oddity with the authorizenet api and full billing address fields. We've released a patch that should fix the problem for you.
You weren't seeing this error in the log because it was an error on the CG side.
22 Posted by eric on 11 Mar, 2010 07:48 PM
Great, Marc. It seems to be working now. Thanks for the impressive response time on the fix.
Marc Guyer closed this discussion on 19 Mar, 2010 05:51 PM.