![]() |
Does it matter where your credit card processor is physically located?
To obtain more sales in Europe, is it better to have a 3rd party credit card processor that is physically located in Europe?
And better to have a local processor here in the States for US and Canada sales? Was wondering if location does matter in regards to ease of processing and approvals. Overseas credit card sales might be more scrutinized more by banks if not made within the same continent? |
Unreal. Has the crowd here been stumped? Nobody has an opinion on credit card processing for overseas transactions? I'm flabbergasted.
|
Your processing within VISA Net is in your domicile.
If you deal with a global 3rd party processor their Acquiring Bank relationships are what matters. Why US E-Retailers Need Cross-Border Acquiring |
I would have thought a credit card is used over the world, so it wouldn't matter where you are now. You can transfer money at a flick of a switch. The question is the cost of transferring :2 cents:
|
Please dont listen to Barry he is an idiot who says nothing and tries to sound important.
The biggest thing i would worry about is currency. If you are delivering a digital product this matters "less". But local currency is always best. Thus you may need to show a biller a local address/account to process in a separate currency depending on their rules. A north american biller or european biller likely has the same or similar countries as high risk. Which will cause denials anyway. Not due to processor location. To answer your question in short. No location should not matter unless your biller is terrible. If someone from the UK is purchasing on a USA website and all fraud checks are passed there should be no reason you will see a large increase in denials. |
Thanks :thumbsup
|
Quote:
Please post more questions here, contact myself for our sales department. Thanks, Mitch |
Quote:
I entirely disagree with this statement. The location does matter, but not the one of your payment processor but the one of the acquiring bank they are using. If the acquiring bank is in the USA and your customer (cardholder) has a bank (issuing bank) in the UK for example, the payment can be rejected due to that location issue. There are 3 zones for online payments that are determined by the distance between the acquiring bank and the issuing bank. - local zone: same country - intra zone: same continent (EU zone for example) - inter zone: international The issuing bank sets a daily and a monthly limit for the cardholder. The limit is higher for "local" payments, then lower for "intra" payments and finally even lower for "inter" payments. Therefore, if your customer has already spent (in a day or current month) a certain amount online in the inter zone there is a chance that their limit will not allow them to pay on your website if your acquiring bank is not in their local or intra zone. On top of this, there is the currency issue. You do not want to bill your EU customers in Dollars and vice-versa. If you need more information I will be happy to explain it further. Max [email protected] |
Quote:
In practice, if you have an Euro merchant account, it can happen that some US/Canada cards are declined (by the cardholder's bank, not by YOUR bank!) because trying to do a sale out of US/CA. Then the "best" would be to send US/CA guys to US/CA merchant account etc., still there are some other protectionistic and silly rules about SPECIFIC banks, in fact we see all the time guys being declined by 1 biller then approved by another in strange order (no scrub on OUR end... only in card end). It also happens that cardholders are PHONED immediately by the bank after the declined with a scary question: "Was it you who tried to do a card sale of $XXX in europe a minute ago?", and the guy should approve this. It even happens that EVERY next sale even in same day, the guy is declined and gets a new call (can't pre-approve stable)... now tell me if this is an efficient, fair and internationally open system... |
All times are GMT -7. The time now is 07:03 AM. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
©2000-, AI Media Network Inc