Very interesting... sorry for the trouble. I wonder if I can use utf8_decode() to sanitize fields prior to encryption.

For us I think it'd be a rare thing, but you never know when someone will use a character like that in their last name. And for European cart merchants especially, it'll affect them more, I'm sure.

If encoding or decoding to utf8 would work. I'm wondering how the pathauto module does it? I think it might actually use the same premise to take non-standard chars and convert them to their standard equivalent.

Pathauto was the first module I thought of, too. I'll try to check it out and work that into the encryption class...

Transliteration is the keyword, see install.txt. The complete i18n-ascii-full.txt has 470kb.
Would be nice if all the pathauto users who already configured i18n-ascii.txt could recycle it for cc encrytion.

Heh.. we just had another person email us with this issue. I guess we have more Swedish customers than I thought! Any update on this? (No rush, really - just checking.)

I'm gonna need some help on this one... I'd love to have a simple solution for core, even if it just means stripping out illegitimate characters. There's a transliteration module available at http://drupal.org/project/transliteration that we can maybe hook into further. Anyone wanna take this on?

As soon as I get some free time I can contribute. This week is Comic-Con, and we have a booth there, so this week was gone before it even started But it is something we need since we have international customers. I wonder how (if?) anyone in Germany or Sweden has approached or dealt with this issue?

The odd thing is Drupal itself, without that module, seems to have disagreed with the character as well. The name Björn (when used in a username) is created as Bj-rn. I will look into installing that module as a counter to that issue as well..

Actually, I just got it to work.

- Installed Tranlisteration module.
- Went into uc_credit.module. Everywhere there was mention of check_plain($_POST['cc_owner']) I replaced it with check_plain(transliteration_get($_POST['cc_owner'])).

I was able to test this by creating a test order, and just editing the Order Details, Payment method (Credit Card).

Originally:
- Add a user "Test Test" with all card details. Saves fine.
- Edit details of Card Owner to say "Björn Test" and re-save.
- Reload order details, all of the Credit Card data is gone from the order.

After I edited the .module:
- Edit details of Card Owner to say "Björn Test" and saved.
- Reloaded order. Card Owner now shows as "Bjorn Test" (note the transliterated "o").
- All card data is visible in the order.

I think this would be enough to satisfy this issue? What do you think? The entire process only took a few minutes but I haven't done any thorough testing. Initial results are positive, though. My only concern is that this would add another module dependency. Or you could just add switches in, as per the README doc:

So maybe not a dependency per se, but a recommendation for any stores who might be selling outside of the US.

Yeah, I think I like this idea... I just have to remember to document it.

A lot of people won't even need to collect CC names, so for most people it's quite likely they'll never be attempting to encrypt unsupported characters anyways. Thanks for lending a hand!

When you say they "won't need to collect CC names" .. is that an option? I hadn't even thought to look - can I remove the Card Owner field? Will that field get replaced by the "Billing Information" names? Or can it just be removed without any issues? I'll look at our authorize.net settings and see if we're requiring a name on the cards. If that's the case then maybe I'll just do away with that field altogether...

Yeah, it's totally an option in the CC settings. Our company uses CyberSource and I don't think we ever enter names. I'm honestly not even sure which of the payment modules accommodate the CC name and which just use the billing name.

After consulting with our accounting department, we do need to keep the Card Owner field - so I think leveraging the Transliteration module would be a good idea. I honestly have never seen a store that did not ask for a separate Card Owner, or at least only asked for the Billing Address (no names) and then used the Card Owner field as the Billing information name.

So I think that leaving them as-is should be the way to go. If the Billing customer info isn't getting encrypted then there's no need to transliterate it; but any text strings that have the potential to break encryption should be.