Get rid of the errors when using umlauls in payer name

[priezz]

Removed cartPayerName helper as it takes the name from the profile, where it (the name) could contain umlauts and other non-latin characters,
which are not accepted by payment gateways and the payment form produces an error as the result. This should not be a problem as the customer
should always type in the name as it is on the credit card anyway.

[aaronjudd]

This removes a feature though.. the idea is that why would a user need to type in their name if we already have it? Wouldn't it be easier to transform the name?
Additionally, we plan to remove or mask this input with a more skeuomorphic payment entry UX in the future (so it will be again likely be dependant on the entry in the addressbook at some future even if this is removed now).

[priezz]

But the problem is that the name in the address book is often (well, for US it is not the case) not the same as written on the card, so the user has to enter it anyway. So, if this field is prefilled, the chance that the user will not check it is much higher. I think that is the reason why payment forms are very rare prefilled with some data. Maybe it would be a better choice to name the fields the way to let browsers (like Chrome and Safari) fill them with saved card data?

[priezz]

As for the name transformation - I do not know the correct way to transform national characters into latin ones. So, we you still want to keep this helper, I would propose to return the empty string in case the name from the address book contains at least one non-latin symbol.

[aaronjudd]

Well it seems that some card companies are restricted to a limited subset of ASCII characters, we could probably just do something like:

str.replace(/[^\x00-\x7F]/g, "");

I think most payment methods don't require or validate the name, just the card information, but accept this information for tracking purpose, so the correctness of the data may not be all that important, as long as it's in the acceptable ASCII / ISO 646 character set. (but not surprised if there is some variation on every processor).

[priezz]

str.replace(/[^\x00-\x7F]/g, "");

In this case instead of, say, Saško Štoltz, we will get Sako toltz, which, in my opinion, is much worst than the empty field.

I think most payment methods don't require or validate the name, just the card information, but accept this information for tracking purpose

Yes and no. Finally this information comes to the card issuer (some bank in majority of cases) and if the information is improper the transaction could be cancelled. For example US banks require not even the name, but the correct payer's address as well. Some banks require nothing. Some banks do not even attach the cardholder's name to the card. So it depends. Anyway, before the transaction comes to the issuer, it is processed by acquirer and here rules could differ.

[aaronjudd]

OK, fine but removing something that would be a feature for 80% of users to prevent 20% the inconvenience of emptying the field and retyping their name doesn't make sense. Why not just check if there are potentially non ASCII / ISO 646 characters and return empty strings in the helper in that case?

[priezz]

Why not just check if there are potentially non ASCII / ISO 646 characters and return empty strings in the helper in that case?

You are right. Will do it this way tomorrow. What is better, to open the new PR for that or fix this one?

[aaronjudd]

cool. it's fine either way. Might be easier for you to start a new one, so you don't have to revert the files in this PR and can start with a clean branch. if so, just close this one.