Do modern credit card processing systems allow diacritics in cardholder names?

16
votes

Background: a lot of people have names with diacritics that can't be represented in ASCII, for example JOSÉ GONZÁLEZ

There seems to be some evidence that the encoding on a magnetic stripe can only handle unaccented latin letters A-Z in cardholder names.

This is leading a lot of people to read question 2004532, now several years old, and conclude that they shouldn't let people put diacritics in the "cardholder name" field of their credit card forms.

What is the actual best practice here? Do "modern" payment APIs like stripe / braintree etc. require, allow, or disallow cardholder names with diacritics?

3
credit-cardstripe-paymentsbraintree

3 Answers

9
votes

This is a good question and I am sure it will vary from processor-to-processor. But if we wanted to look at the bigger picture I think it would be, "still not yet" probably.

Having searched around for this I found:

I could not find anything from Braintree or Stripe specifically as their API documentations do not explicitly mention valid characters (at least i could find while searching. I haven't implemented either API so I do not know them intimately).

Update

I emailed Braintree and this is their response:

We do allow special characters such as diacritics for customer and cardholder name. It should be noted that special characters are not allowed for customer ids.

Update 2

Just heard back from Authorize.Net (link added by me):

We support characters in the ISO/IEC 8859-1 character set.

Update 3

Just heard back from Stripe:

Everything at Stripe uses UTF-8, so diacritics won't be a problem.

3
votes

I would say best practice is still to sanitize input.

Behind the scenes, the cardholder name is not used during the authorization process, but is (sometimes, depending on type of transaction) submitted during end of day settlement. The impact of this means that the name you provide has no impact whatsoever on the authorization.

When it is submitted for settlement it must be no more than 26 ITU-T.50 characters, in the range hexadecimal 20-5F. You can see the table for this here: http://www.zytrax.com/tech/ia5.html

This information is from the APACS 70 Standard, book 3. Not available online

Modern payment APIs still have to conform to banking standards, and those standards are literally decades old. The number of systems that use those standards makes it near impossible to modernise. Where payment processors do allow diacritics (as @agf notes in a comment here) they must be sanitized by the processor before submission to merchant bank.

1
votes

From our project it looks like Adyen, DataCash, EcorePay, EMP, MPI, NetPay, SafeCharge, SoEasyPay, Transact24, WireCard, LPS, Nerex, Authorize.NET accepts diacritics. But LPS, Nerex, Authorize.NET requires cardholder's First and Last names separately and it may cause a problems.

The most problems with NetGate Asia (Japanese Card Processor) - it requires First and Last names to be only in [a-zA-Z], without apostrophe ', and even numbers not allowed.