What's the REAL maximum length for text labels?

[lightwave365]

I am in the process of setting max character limits for fields that we will let our customers modify to meet their needs. When I send this over as a merchant name using the Java SDK for Accept Hosted:

"Dunder Mifflin How much text can we fit in here before it cannot fit anymore"

I get the following error:

Response Code: [E00013] 
Response Text: [Invalid Setting Value. hostedPaymentOrderOptions: maximum length is 100.]

Now correct me if I'm wrong but that is LESS than 100. It's 76 characters. I'm not even close to the maximum.

The same issue happens with the 'Pay' button text:

"Pay Now With a 50 Character Limit On The Label"

Response Code: [E00013] 
Response Text: [Invalid Setting Value. hostedPaymentButtonOptions: maximum length is 50.]

That is 46 characters. Definetely closer to the maximum but not over it yet.

So what is going on here? Is the API lying to me? Is something out of date? I need some concrete values so I can continue to build my solution.

Thanks.

Edit:

And maybe this will help. For the code I'm using your API to do everything:

SettingType buttonSettings = new SettingType();
buttonSettings.setSettingName("hostedPaymentButtonOptions");

JSONObject buttonSettingsJSON = new JSONObject();
buttonSettingsJSON.put("text", getPayButtonText() );

buttonSettings.setSettingValue( buttonSettingsJSON.toString() );

ArrayOfSetting settingsList = new ArrayOfSetting();
settingsList.getSetting().add(buttonSettings);

GetHostedPaymentPageRequest requestToAuthNet = new GetHostedPaymentPageRequest();
requestToAuthNet.setHostedPaymentSettings(settingsList);

[kabutotx]

Don't use hosted but maybe it is saying the whole JSON line.  Not just that text string.

[Renaissance]

I am not familiar with Java, but it may be that that error message is giving you byte length rather than character length. All of the API calls work the same in the end regardless of the language used, I think, and with my php integration I can tell you that the character length allowed is quite a bit less than 100. I can’t remember the exact number but I got an error message way below that point. I was looking for a value I could use to pass something like “please click the continue button after viewing or printing your receipt”. I ended up using the order description and it worked just fine.

[lightwave365]

Don't you see a problem with that though? If the API is giving us incorrect error messages that sounds like a bug to me.

Byte length seems a bit odd. Why measure length in that? That's like measuring in number of vowels per sentence. It makes no sense.

[Renaissance]

Yeah I’m just speculating. It would be strange. Agreed. I might try a string real quick and see what it will let me get away with. The only plausible reason I could think of is that somehow the byte weight of the string factored in somehow. Otherwise 100 characters is 100 characters.

[Renaissance]

And that obviously assumes there is no bug.

[Renaissance]

Just tried it. I get the same 100 max limit for anything greater than 24 characters for the merchant name. I think it may be that aggregate of the order options characters that are being counted.

[lightwave365]

It would be lovely if someone who actually supports this software responded instead of just us users speculating what might be true about something we know nothing about.

I do appreciate you Renaissance for trying to help me with my issues though. Customer service is just terrible here and I absolutely dread whenever I need to update our software with Authorize.Net. Even if it is only once every five years. It's five years too many.

[lightwave365 · Accepted solution]

Alright, since no one at this company cares about potential customers and their problems at all, I did trial-and-error research myself. I'm posting my results in hopes that it will help people in the future who have questions about their API. Though I would highly suggest against this unintuitive headache and just use PayPal instead.

Renaissance was right in that it looks like it's including the entire JSON in the max length validation. Why? No idea. That is a really poor way of handling custom text by including other hardcoded text that is out of their control. So when you send your custom text like this, it's including these entire lines for the length validations:

"show":true,"merchantName":"Greater International Airport School for the Deaf and Blind"

"text":"Pay Now With Venmo, PayPal, Or My Tears"

To confirm this I set up a name that was just barely on the text limit but still passed. If I had added another character to the name it would have failed. Then I took that good name and changed the 'true' to a 'false', thus adding one more character to the entire JSON but not touching the merchantName string. That failed. So the entire JSON is affecting it.

Which means that I will want to impose a maximum length of about 60 for the merchantName and 30 for the payButtonText if I want to avoid the API returning an error any of my customers.

Oh and apparnetly there is zero limit on the hostedPaymentReturnOptions. My text was blown way off the page without failing to get a nonce. Just more wild inconsistencies with the API.

Hopefully this helps any future people who run into this problem.

Problem resolved.

Good job, lightwave365 (and Renaissance) .

Edit: Seriously man, you delete my post because I talk bad about your customer service? Who is running this place? Do you care about people getting help at all?

[Anurag]

Hi @lightwave365

Thanks for your post. This is a bug where the max length  check is being done on 

whole JSON inside the settingValue.

We have added a bug for the dev team to look into it . 

Thanks

Anurag