现代信用卡处理系统是否允许持卡人姓名中的变音符号？

Question

背景：很多人都有变音符号的名称无法用ASCII表示，例如JOSÉGONZÁLEZ

似乎some evidence磁条上的编码只能处理持卡人姓名中的非重音拉丁字母A-Z。

这导致很多人阅读question 2004532，现已有几年了，并得出结论，他们不应该让人们将变音符号放在信用卡表格的“持卡人姓名”字段中。

这里的实际最佳做法是什么？像条纹/ braintree等“现代”支付API是否要求，允许或禁止带有变音符号的持卡人姓名？

Answer 1

这是一个很好的问题，我相信它会因处理器而异。但是，如果我们想看一下我认为的大局，“仍然还没有”。

寻找了这个我找到了：

• 这PDF from UniCredit Bank Czech Republic and Slovakia, a.s.建议忽略变音符号（参见第7页）
• Authorize.Net does not support them（2）
• Realx Payments does not support them

我找不到Braintree或Stripe的任何内容，因为他们的API文档没有明确提到有效字符（至少我可以在搜索时找到。我没有实现任何API，所以我不熟悉它们）

<强>更新

我通过电子邮件发送了Braintree，这是他们的答复：

  

我们允许客户和持卡人姓名等特殊字符，如变音符号。应该注意的是，客户ID不允许使用特殊字符。

更新2

刚从Authorize.Net（我添加的链接）回复：

  

我们支持ISO/IEC 8859-1 character set中的字符。

更新3

刚刚从Stripe回复：

  

Stripe的所有内容都使用UTF-8，因此变音符号不会成为问题。

Answer 2

我认为最佳做法仍然是消毒输入。

在幕后，在授权过程中不使用持卡人姓名，但在结束日期结算时提交（有时，取决于交易类型）。这意味着您提供的名称对授权没有任何影响。

当提交结算时，它必须不超过26个ITU-T.50字符，在十六进制20-5F的范围内。您可以在此处查看此表：http://www.zytrax.com/tech/ia5.html

此信息来自APACS 70标准，第3册。不在线提供

现代支付API仍然必须符合银行标准，而这些标准几乎已有数十年的历史。使用这些标准的系统数量几乎不可能实现现代化。如果支付处理商做允许变音符号（如此处评论中的@agf注释），则必须在提交给商家银行之前由处理者对其进行消毒。

Answer 3

从我们的项目看起来像Adyen，DataCash，EcorePay，EMP，MPI，NetPay，SafeCharge，SoEasyPay，Transact24，WireCard，LPS，Nerex，Authorize.NET接受变音符号。 但是LPS，Nerex，Authorize.NET分别需要持卡人的名字和姓氏，这可能会导致问题。

NetGate Asia（日本卡处理器）的大多数问题 - 它要求名字只能在[a-zA-Z]中，而不是撇号，而且不允许使用偶数。