I am attempting to use the API to add a credit card to a contact. I can successfully add the card within Keap, as I see it on the contact’s record, but the API takes a while and returns the following error to my app:
Authorize error: Auth failed for 'Test Account' - java.lang.StringIndexOutOfBoundsException: String index out of range: 3 .
I have several questions:
When adding a credit card, is it authorizing it in a merchant account as a part of the process?
How does it know which merchant account to choose? In the case of the API, it seems to be choosing the very first one it comes across - in our case, it’s this Test Account.
How do we get it to not use certain merchant accounts?
Outside of API usage, we actually went into the Keap interface to try and edit the Test Account, and it keeps presenting us with an error. This makes me think this Merchant Account is somehow bugged, and it won’t let us do anything about it. What recourse can we take regarding this? I’ve already chatted with support regarding this, but there was nothing they could do.
Assuming this is a Sandbox account for Authroize.net or affiliate account, there are certain values when used in testing that will allow developers to trigger and test specific responses. If you can use this info to confirm you’re not unknowingly passing a value intended to fail:
If this is a sandbox, make sure it’s set to Simulator mode in the Keap settings.
If this is a Live account and you’re using it in Test Mode, I would recommend getting a Sandbox account.
My sandbox account was connected to a client’s account, and I had to remove it because Keap was validating the cards, and as you stated since it was the first merchant account in the list, and I had CIM turned on, my sandbox was collecting real CC data.
I didn’t try to figure out how to change it, I just removed my sandbox from the client account and deleted the live data in my Sandbox.
Depending on the mechanism being used by Keap to determine which merchant account to validate against, you may need to delete the test account, and add it back so the live account has a lower primary key, or… rename the test account so it’s sorted after the Live account, and see if the order precedence changes the account used for validating cards.
Good morning Andy! I passed the questions along to our ecommerce team and they provided the following:
I’m assuming the endpoint they are referring is /v1/contacts/{contactId}/creditCards
When adding a credit card, is it authorizing it in a merchant account as a part of the process?
Yes, the information is being sent to the processor(s) to perform their own authorization of the card information.
How does it know which merchant account to choose? In the case of the API, it seems to be choosing the very first one it comes across - in our case, it’s this Test Account.
If there exists multiple AuthNet accounts connected, then the card will be authorized through through each of them
How do we get it to not use certain merchant accounts?
There isn’t a way in the v1 to select/ignore a merchant. If they use the v2 method of adding payment method via the JS package, then the payment method added will be based on the default merchant,
Outside of API usage, we actually went into the Keap interface to try and edit the Test Account, and it keeps presenting us with an error. This makes me think this Merchant Account is somehow bugged, and it won’t let us do anything about it. What recourse can we take regarding this? I’ve already chatted with support regarding this, but there was nothing they could do.
Sounds like an issue we could investigate, but it would have to go through the Keap Support process for us to receive a ticket in order to resolve.
Thank you Tom - very insightful answers! I actually went through support, and they also had no idea why, when we try to edit our Test Account, it errors out. I told them to escalate it and gave them an email to get back to me, but that was yesterday and haven’t heard anything. If there is a way to simply remove our Test Account, that would be great. I’ll talk to support again.