AIM in C# - Encoding International Characters/Symbols

[jncueto]

Hello! We've been using the AIM method without issue for years, but recently started getting quite a few European customers. We've noticed that any orders with special characters, such as umlauts and accents, are being rejected. I found an old thread on these forums stating that Authorize.Net doesn't currently support unicode and it suggested using an expanded western encoding. I am writing to see if:

1. Is this still the case?

2. I'm developing in C# - can anyone tell me what encoding/function to use? I'm using a very similar setup to the sample code where I populate a bunch of entries in a hash and then write it out to a string and I'm assuming I would encode the customer supplied fields in this new encoding as they are put into the hash?

Thank you for any help you can provide!

[Joy]

Hi jncueto,

Although we are currently working to fully support UTF8 as we begin expanding outside of the United States, we have not yet updated every component in our system and you may still see some unexpected behavior using characters outside of the ISO-8859-1 character set.  Hopefully this is a limitation that we will be able to fully remove over the coming months.

Thanks,
Joy

[blackbeltdev]

Can't help you with C# but I'm sure they have something similar to how you would do it in Java:

import java.nio.charset.Charset;

import java.nio.charset.CharsetEncoder;

final CharsetEncoder encoder = Charset.forName("ISO-8859-1").newEncoder();

if (encoder.canEncode(input)) ...

[dominic108]

Can anyone follow-up on this thread. It seems that there is a full support for UTF-8 now, we can infer it from the SDKs, but I cannot find any explicit statement on the AIM documentation about this. How comes that we do not need to specify the charset in some variables?   

[dominic108]

OK I tested their system.  From my test, I see that, for onetime AIM payments, they guess the charset. I don't know what is their detect order, but it seems that UTF-8 is their first guess. If it is a valid UTF-8 byte sequence, they assume it is UTF-8. If it is not a valid UTF-8 byte sequence, then they try another charset. In my test, I entered a fake name "G®ou" in ISO latin-1. Since it has the same byte sequence as "G®ou" in UTF-8, they incorrectly assumed it was "G®ou" (without the Â .) So, it is safer to use UTF-8 than to use ISO latin-1.     I also tested "Éric"  in ISO latin-1. In this case, it does not have a valid UTF-8 byte sequence. So, they correctly used ISO latin-1, which is perhaps their second guess.   

[jefferylovett]

OK I examined their system. From my test, I see that, for onetime AIM payments, they bet the charset. I do not know what's their locate order, however evidently UTF-eight is their first bet. If it's miles a legitimate UTF-eight byte series, they count on it's miles UTF-eight. If it isn't always a legitimate UTF-eight byte series, then they are trying any other charset. In my test, I entered a faux name "G®ou" in ISO latin-1. Since it has the identical byte series as "G®ou" in UTF-eight, they incorrectly assumed it was "G®ou" (with out the  .) So, it's miles more secure to apply UTF-eight than to apply ISO latin-1.