Accepting Credit Card Payments in Different Currencies

The purpose of this article is to familiarize merchants and other merchant services industry players with the key issues of accepting credit card payments in different currencies.

With the growth of online business and the advance of the general process of globalization, there are more and more businesses that are servicing customers worldwide. Particularly, as online stores expand, they run into various currency-related issues at two levels:

  • When a payment is made by a customer from a different country
  • When they have a supplier from a different country
    • Example

      A bookstore is headquartered in the US and servicing customers in the UK, US and Canada. It has suppliers coming from all three countries.

      While the easiest way for the bookstore would be to accept all payments in US dollars, the approach has several disadvantages:

      • When customers from outside the US visit the online store, they don’t know the exact price of any item in their local currency, because all the books are priced in US dollars. Conversion rate is going to depend on the bank of the customer, so the customer can never really know what the final price is going to be. On top of that, some banks use the practice of surcharging additional fees on foreign purchases.
      • Once the store collects all the payments and they are funded into the US bank account, the store has to pay its suppliers (publishing houses, etc). If suppliers are located in different currency zone, the bookstore has to do currency conversion. This results in certain problems, as currencies tend to fluctuate (and causes significant fluctuations in profit margin).

      There are two solutions that are generally utilized to solve the abovementioned problems.

      The first solution is to do authorization in the local currency (for instance, British pounds) and do settlement in the primary currency (US dollars in the abovementioned example).

      The advantage of this solution is that the business can price its items in the local currency. A book can cost 10 US dollars in the USA, 10 Canadian dollars in Canada and 8 pounds in Britain. Under this approach a customer can know the exact price and not pay any additional banking fees, because the transaction is going to take place in the local currency of the customer.

      The disadvantages of this solution are as follows.

      • In such cases transactions of this type are going to involve additional costs for the merchant because of various cross-border assessments charged by card associations.
      • The approach does not solve the problem with the suppliers. While paying its suppliers (a bookstore is a retail business, purchasing products from suppliers on a regular basis) the company still has to do currency conversion.

      The second solution involves doing authorization and settlement within the local currency (both authorization and settlement in pounds).

      Handling card-present transactions in several countries is an extremely difficult task. Handling card-not-present transactions in several countries is less problematic, but it is still a challenge.

      Under any scenario (card-present or CNP), the only way to do transaction settlement in the local currency is to have a bank account in this currency. In many cases local regulations require companies to open this bank account within a local bank, so a multi-currency account might nod be an option. For example, a UK merchant service provider (MSP) might not be willing to use a Canadian-issued bank account even if it is in pounds. Consequently, the company might be required to have either a local bank account and\or a business presence (tax ID) in the country.

      The immediate challenge resulting from these requirements is the need to manage and reconcile multiple accounts. Another challenge is that, due to the structure of the market, the company might be required to deal with different merchant service providers. While there are merchant service providers available, that could handle multiple countries on the same system, they are likely to charge additional premiums for their service. For example, a business can use Stripe or PayPal, but these MSPs charge around 3% plus $0.25 a transaction, making the process very expensive (especially on large volumes of transactions, or in Europe where most cards are EMV-type cards and standard interchange is generally under 1%).

      Due to complexity of transaction settlement in multiple currencies, small and medium-size businesses might be better off doing authorization in specific local currency, and settlement – in a unified currency. In those cases when they need to pay suppliers (say, once a month), they can utilize special services, such as Currency Cloud, XE, XOOM, Amex FX, and others. These services allow businesses to do wires (bank transfers) involving currency conversion without having to pay international wire fees, as well as “lock” exchange rates or at least reduce the impact of currency fluctuations.

      Such services are usually offered by large companies with business presence in many countries, so that the funds are transferred within one organization (such as Amex), which charges only a fixed interchange rate established at the market for a current day (say, about 1.5-2%). Under such an arrangement wire fees are either not charged or significantly reduced, depending on transaction volume.

Encrypted MSRs and Payment Terminals

The purpose of this article is to analyze card-present transaction processing in greater detail and see how traditional and encrypted magnetic stripe readers (MSRs) as well as payment terminals are used, as well as to explain how MSR or terminal can, potentially, take an application, relying on it, out of PCI scope.

Generally, every credit card payment transaction can be classified as either card-present or card-not-present (CNP) one. Card-present transactions usually involve usage of a physical card, and, thus, a swipe of a magnetic stripe, which requires usage of a special device, called magnetic stripe reader (MSR). Card not present transactions include online and over-the-phone transactions where card information is manually keyed.

From traditional to encrypted MSRs

Traditional MSRs

Initially, traditional MSRs were introduced to read credit card swipes. After a card was swiped, the card data was transferred to the merchant’s payment processing application. The application, in its turn, generated the message for the payment gateway or underlying payment processing system, which would then process the transaction and respond with either approval or decline. Consequently, the swipe data from the card’s magnetic stripe (known as track data) was passed through the merchant’s payment processing application.

With the development of software industry new needs emerged. These were the needs for wider payment processing functionality within larger applications specialized to service a specific market such as restaurant software, supermarket POS, health club management software, country club management software etc.

In other words, if initially, specialized terminals were designed exclusively for payment processing, later the need for an integrated solution emerged. The solution had to incorporate payment processing functionality, but, at the same time, it had to be specialized for a certain industry.

As business software packages became more and more complex, they had to incorporate many additional functions beside basic payment processing functionality. Since software package was involved in communication with the payment gateway, and, therefore, had access to credit card information, it was getting within PCI scope. Consequently, it required PCI audit (generally, a complex and expensive procedure). It was necessary to somehow reduce or eliminate the need for PCI audit of the software which was not directly involved in the processing of credit cards.

For card-not-present transactions the problem was solved by the introduction of payment pages. While payment pages allowed merchants to resolve the issue of getting most of their web-based applications out of PCI scope, for desktop applications (and web applications, for which usage of payment pages was not feasible or desirable) the issue of PCI scope reduction remained relevant.

Encrypted MSRs

One of the solutions of the above-mentioned problem became available with the introduction of encrypted MSRs. An encrypted MSR functions just as an unencrypted (traditional) MSR. The only difference is that card data is encrypted at the point of swiping, using the encryption key injected in the device. The decryption key (to decrypt the data) is only available to the payment application, which will eventually handle this transaction and is not available to the software package that the merchant uses to run its business. Consequently, only the PSP’s payment application (which does have the encryption key) is capable of decrypting the swipe. So, when the swipe is read, neither the merchant, nor the business-specific software application, are able to decrypt it. Thus, only the payment gateway remains within the PCI scope (but PCI-compliance is a standard requirement for any payment gateway).

However, encrypted MSRs do not address one subset of scenarios, which, while minor, still represents a sizable number of transactions for retail businesses. Particularly, sometimes a card may be unreadable, so that the need for keyed entry arises. The card number, its expiration date and other data for a transaction has to be input manually in some way. Therefore, a business software package relying on MSRs cannot stay entirely out of PCI scope.

To avoid abovementioned scenarios and to enhance the way of dealing with credit card transactions in retail industry, payment terminals are used.

Payment Terminals and Their Types

Unlike a reader, which is a peripheral hardware device, a terminal is a mini-computer, specifically designed to facilitate card-present payment processing. It has its own operating system, which can run applications within itself. It has its own network card and can communicate with external systems, such as payment servers, directly. Consequently, it has the ability to establish a data flow of its own between itself and a payment application, which is not going to involve the software application that controls it.

There are several advantages that terminals have over MSRs. On one hand, a terminal allows a business to accept card swipes, while on the other hand, more advanced terminals allow for keyed entry of credit card data, PIN-based transactions and supplementary functionality, such as ability to round up change for charity donations, tip adjustments, customer satisfaction surveys, etc.

Payment terminals are generally classified as standalone terminals and attached terminals {}.

A standalone terminal has no API or DLL of any type through which an external application can communicate with it. It is mostly used by smaller businesses that use terminals simply to process payments. These businesses, generally, either do not rely on any software package to run their business, or use manual process to reconcile all the payments. Example of such a business is a small restaurant that handles orders on paper and just needs a way to accept credit card payments from customers.

An attached terminal has an API or a DLL that allows an external software application to interact with it. Consequently, attached terminals are generally used by those businesses that rely on some software package for their day-to-day business activities. Example of a business using an attached terminal is a supermarket where payment terminals need to be integrated with the main POS application.

Attached terminals provide a unique advantage to applications that rely on them. A business application is able to initialize the transaction providing terminal with the amount as well as various details (such as item listing, which can be displayed on the screen) through the API. After that the terminal captures the credit card information (either swiped or keyed) or PIN (when applicable) and sends it to the payment gateway, gets a response (approval or decline) and forwards the response back to the business application, without exposing cardholder data to the application itself.


Terminals are ideally suited for purely retail businesses that do not utilize recurring payments in any way, because, in most cases, these businesses do not have any provision for cardholder data flow from the system to the payment service processor (within the context of their application). Those businesses, that (in conjunction with their retail operations) utilize some type of e-commerce functionality and potential recurring billing, can use a combination of terminals, payment pages and tokenization techniques in order to be able to process transactions (accept payments) of various types, but still remain outside of PCI scope.

In cases when payment pages are a suitable option and the cost of terminals (which are more expensive than MSRs) is a major concern for a business, the preference may be given to encrypted MSRs. The only thing to be kept in mind in such cases is that MSRs do not support PIN-debit and EMV card processing on their own.

What is payment aggregation?

What is payment aggregation?

Payment aggregation is a processing arrangement when a large business (called the aggregator) is processing transactions on behalf of many smaller businesses belonging to its portfolio.

How can payment aggregation be practically implemented?

Payment aggregation can be implemented in one of the two ways.
In case of so-called straight aggregation, the aggregator (payment service provider) gets underwritten by credit card payment processor and processes transactions of all of its sub-merchants using the same merchant ID (MID).
In case of sub-merchant aggregation (sub-merchant funding) the aggregator processes transactions of the smaller businesses under different MIDs, remits the funds to sub-merchants and withholds the fees but still bears financial responsibility for all the accounts.
Due to increased possibility of fraud with the straight aggregation model, sub-merchant aggregation is a preferred way to organize processing.
In respective articles you can find some more detailed information on payment aggregation model and sub-merchant funding.

Who can benefit from payment aggregation?

One of the categories of merchant services industry players, frequently using payment aggregation, includes software and service companies, customers of which need to accept payments from their respective customers. Payment aggregation model allows software providers to function as payment service providers using either payment processor integration or some white label payment gateway offering, which they use under their own brands.

What are the risks associated with payment aggregation?

In these types of arrangements the payment aggregator usually gets the preferred processing rate from the underlying payment processor or bank. In return, it, generally, assumes the risk (financial liability) for its entire portfolio. Consequently, aggregator becomes responsible for any transaction fraud or chargeback associated with its sub-merchants.

Credit Card Fraud Protection Tools

The purpose of this article is to familiarize the key merchant services industry players with the main credit card fraud protection tools. Before credit card payment industry emerged, criminals physically robbed the banks. With the advance of e-commerce and online payment market bank robberies were partly “replaced” by fraudulent transactions of different types. Expansion of electronic payment industry was followed by the expansion of credit card fraud. As a result, a necessity for credit card fraud protection tools emerged. These tools are intended to minimize fraud possibility and prevent potential losses of funds, resulting from such fraud.

Some information on importance of credit card fraud protection tools in payment gateway software can be found in respective article.

Here we are presenting an overview of some popular and useful credit card fraud protection techniques, arranged into several groups.

Geographical Location Based Techniques

IP Geolocation

The technique is based on pinpointing the customer by his/her IP address location. If transaction comes from a high-risk (untrustworthy) geographical location, it can be considered a risky or potentially fraudulent one.

Proxy Detection

The technique involves flagging high-risk IP addresses, suspicious proxies, as well as satellite connections serving high-risk geographies.
Some fraudsters are capable of evading IP geolocation controls by using proxies to spoof their IP addresses. Proxy detection helps to identify spoofing. Proxy Detection tools detect both anonymous and open proxies (these are compromised computers that allow traffic to be routed through them). Open proxies are often used for online credit card fraud.

Card Profile (Bank Identification Number)

The technique involves verification of the information on the credit card, such as card association, issuing country, bank and card type ( card, debit card, prepaid card).
For instance, if a merchant does not want to accept foreign-issued cards, or if the issuing country comes from a high-risk region, then respective transactions can be declined.
The information, represented in credit card BIN (6 to 9 digits of card number) allows merchants to make informed decisions related to transaction processing. More detailed information on credit card BIN and intelligence as payment gateway software features can be found in respective article {link}.

Techniques Based on Accuracy of Customer-supplied Data

E-mail Identity Verification

The technique involves verifying whether the customer’s e-mail address is linked to the customer’s name and address. It is always useful to check whether the address is valid, and whether it actually exists or not.
If customer’s identity is not confirmed with the e-mail used for a purchase, the purchase can be declined.

E-mail Profile

The technique involves verification of such characteristics as gender, age, and location associated with the email. As in the case of the previous technique, it is worth checking, whether the e-mail is valid or actually exists.
If information obtained based on e-mail does not coincide with the data specified by the customer during the purchase, the transaction can be declined.

Telephone Profile

The technique involves verification of phone type (e.g. Voice over IP (VOIP), prepaid cell phone) and location associated with the phone number. While stationary home phone is associated with a specific place within a given country, VOIP can be used at any location. Consequently, usage of a VOIP phone can be considered a sign of potential fraud. This criterion itself can not be considered a decisive one, but it can be taken into account in combination with some other fraud signs, if they are present.

Reverse Address Lookup

The technique involves verification of the name(s) associated with the shipping and billing address. If an e-mail specified in the order does not correspond to shipping and billing addresses, the transaction can be considered a high-risk one, and the order can be declined.

Professional Social Network Lookup

The technique involves verification of such information as company (or individual customer’s) affiliation, location, and potential mutual connections on professional social networks, such as LinkedIn and others.
If the number of potential connections come from high-risk locations, or is too few, then additional checks may be necessary.

Other Techniques

Risk Scoring

Risk scoring (or fraud scoring) technique involves usage of a third-party service which performs an overall risk assessment of a transaction. Assessment results serve as a guideline for the merchant to decide whether to approve this transaction or not.

Website Traffic Information

The technique involves verification of traffic and linking information, which are necessary to determine legitimacy of company or e-mail domains. The obtained information on a companies and domains can be used to check e-mails coming from the domain, used for the purchase, and, potentially, check the company, in the name of which the order was made.
For example, web-sites with large volumes of non-human traffic are marked respectively and analyzed for potential fraud.


The technique involves verification of billing and shipping address locations via satellite or street view.
If the two addresses are completely different (for instance, locations are situated in different countries), additional checks may be needed for the order.

Domain Registration Lookup

The technique involves verification of the registration information of the website or email domain. For example, if a domain is unregistered, registered abroad, or if a test e-mail is returned by mail delivery system, then the respective domain should be considered a suspicious\questionable one.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

What is a credit card descriptor?

What is a credit card descriptor (soft descriptor)?

A credit card descriptor is a text, rendered on a cardholder’s statement, describing a particular product or service, purchased by the cardholder. Descriptors are intended to help the cardholder identify the products or services purchased. More information on credit card descriptors can be found here.

What is the difference between static and dynamic descriptors?

Depending on the acquirer and the underlying technology, used to process transactions, it may or may not be possible to specify a description for each transaction, as it is processed. The term “dynamic descriptor” is used to signify, that the underlying system is able to describe transactions on per-transaction level at the time of processing, so that each transaction can have its own descriptor. When “static descriptor” term is used, it is implied that the descriptor for all transactions, processed through a given MID, is specified at the MID level, and, therefore, description of individual transactions is not possible.

Are descriptors available for both credit card and ACH transactions?

Generally, some form of descriptor is always used on all credit card transactions. In the ACH world per-transaction description is not really possible. However, NACHA file format (used for ACH processing) allows merchants to include item descriptions for groups of ACH transactions. Therefore, it is possible to have both name of the merchant, and description of the item, i.e., group of related ACH transactions. The concept is, thus, similar to the one of dynamic descriptors.

How can billing descriptors reduce credit card chargebacks?

Billing descriptors reduce the risk of erroneous credit card chargebacks. If a billing descriptor is informative enough, it will remind the customer\cardholder of a previous purchase. In case of poor billing descriptor (if there is no descriptor, or if a descriptor is not informative) the customer might not remember a specific transaction and request a chargeback, which the merchant will have to deal with.

What are the best practices for descriptors?

At the very least, a billing descriptor should contain merchant name and customer service phone number. In the ideal case, if a customer copies your descriptor and does an online search (in Google or Bin), your company should come in as the first page on the list.

What is a recurring billing?

What is the difference between committed and uncommitted recurring billing?

Recurring billing is a process when a merchant charges a customer’s account at regular time intervals for purchases of goods and services. Uncommitted recurring billing does not involve any minimum number of required payments, while under committed billing a customer is required to do a specific number of payments. Under committed billing, if a payment is missed, and account becomes delinquent, the creditor (a subscription-based business using recurring billing system) generally attempts to collect any past dues.

What payment schedule types are available for subscription-based businesses?

The three recurring billing schedule (or payment plan) types are:
• fixed plan (when a limited number of payments are charged at regular time intervals),
• unlimited plan (when the number of payments is unlimited, and they recur until being cancelled by the customer),
• hybrid plan (when after a certain period of time a fixed plan becomes an unlimited one). More information on the subject can be found here.

What is the difference between repeat billing and recurring billing?

Under repeat billing no outstanding balances and past dues are accumulated, while under recurring billing the amounts owed by the customer are accumulated and stored in order to facilitate further collections attempts. An online dating web-site subscription is a typical example of repeat billing, while a typical example of recurring billing is a two-year-commitment on a cell phone plan. Consequently, the second approach is more complex in terms of recurring payment processing. More information on the subject can be found here.

How is credit card data handled during recurring payment processing?

If a business, using some recurring billing solutions, stores the actual credit card data, it falls within PCI scope and has to undergo the costly PCI audit procedure. The two techniques, allowing merchants to reduce their PCI scope or even get out of it, are credit card tokenization and profiling. More information on the subject can be found here.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

What is payment gateway software?

What is payment gateway software?

Payment gateway software is a server application facilitating exchange of payment related data (cardholder and transaction information) between a merchant and a payment processor or an acquiring bank. For example, payment gateway software can provide connectivity between merchants’ POS systems and a legacy processing platform used by some bank; often it also handles PCI-compliance-related issues, such as credit card tokenization, reducing merchants’ PCI scope exposure.

What is a licensed payment gateway solution?

In case of licensed payment gateway solution a company (a merchant or a payment service provider) licenses, either in a binary form, or in the form of software code, a payment gateway software from another company and deploys it within its own PCI-compliant infrastructure.
It allows the licensee to have greater control of payment gateway infrastructure. Licensed payment gateway cost is more significant upfront, but subsequent use of the payment gateway solution doesn’t impose any per-transaction processing fees.

What is a hosted payment gateway solution?

In case of hosted payment gateway solution a merchant (payment service provider) uses (“white-labels”) an existing solution that resides within a PCI-compliant environment of the hosted payment gateway provider. This payment gateway solution does not require merchants to incur any gateway maintenance costs or to have their own PCI-compliant environments, but merchants do have to pay per-transaction processing fees. In case of hosted solution the merchant might be required to go through payment gateway integration before transaction processing is possible. More information on hosted and licensed payment gateway solutions can be found here.

What is a white label payment gateway?

White label payment gateway is a hosted payment gateway solution, which is sold by a company under its own brand, while the actual service provided by one of its vendors on sub-contractual basis. The white label payment gateway concept allows the company to bolster its image in the eyes of its customers by providing a new critical service under its own brand. More information on the subject can be found here.

What is an ACH payment gateway?

What is an ACH payment gateway?

An ACH payment gateway is a kind of payment gateway that allows to process ACH transactions. Usually it connects to various banks or ACH processing networks to provide access to all of its financial institutions for its merchants.

What is the difference between ACH and credit card transaction processing?

ACH transactions do not involve payment cards – just bank accounts, so credit card transaction processing is usually performed by credit card processors/acquirers, while ACH transaction processing is, mostly, handled by banks. However, in today’s merchant services industry there are payment gateways, allowing merchants to process both credit card and ACH transactions through one and the same API.

What is a lifetime of an ACH transaction?

ACH transaction file is submitted to the bank, which, usually, forwards it to Federal Reserve, which funds a 1005 of transactions in the file. Subsequently the Federal Reserve will dispatch a request to respective banks to complete money transfers.

What is an ACH return and how should it be handled?

An ACH return is a rejection of an ACH transaction due to insufficient funds on the account or for some other reasons (complete list of ACH return codes can be found here). If at the stage, when Federal Reserve requests money from the bank, it turns out that the transaction cannot be processed, since Federal Reserve has already funded the respective merchant, it takes the money back from the bank, while the bank takes it back from the merchant. Verification of availability of funds on the account can take up to two months, during which ACH fraud can occur. Consequently, the best way to deal with ACH returns is to avoid them, i.e. check whether all the information necessary for ACH payment processing is up-to-date, whether account is not included into some blacklist, whether the account (or IP) does not come from some high-risk location, etc.

What is the role of ACH reserves in ACH payment processing?

ACH reserves represent one of the ACH fraud protection mechanisms. ACH reserve is a certain amount withheld by a PSP\underwriter from deposit of a merchant (fixed amount or percentage of ACH transactions, processed by its sub-merchants) to protect its business from potential ACH-returns. More information can be found here.

What is a credit card chargeback?

What is a credit card chargeback?

A credit card chargeback is one of the customer protection means. Credit card chargeback is a dispute between a cardholder and a merchant over a certain amount of money, happening when the cardholder believes that the money has been charged illegitimately or by mistake (for products or services he or she did not purchase).
Credit card chargebacks are an important issue to be considered by all merchant services industry players. A merchant should remember that if more than 1% of processed transactions result in chargebacks, the merchant account is terminated. An underwriter should remember, that it bears financial liability for its sub-merchants, so, in this case, it is the underwriter who carries the burden of chargebacks, issued by sub-merchants’ customers.

How can merchants deal with credit card chargebacks?

The merchant company needs to get chargeback information delivered to it as soon as possible, identify the chargeback, and dispute it, if necessary. If the volume of transactions processed by a particular merchant is large, it makes sense to automate the whole process of credit card chargeback handling. More information on credit card chargeback handling can be found here.

What is credit card chargeback fraud and how can businesses prevent it?

Customer fraud related to credit card chargebacks involves fraudsters who use stolen credit card numbers to purchase products and services. Merchant chargeback fraud happens when a fraudster (who has a merchant account) obtains multiple account numbers (for instance, from some database), processes transactions using these stolen cards, and disappears, once his bank account gets funded.
Mechanisms, generally used for credit card chargeback fraud protection, include verification of account-related data, such as geographical location, address, card code, and others. Underwriters can hold special chargeback reserves to cover chargebacks, issued by their sub-merchants’ customers.
More information on chargeback fraud protection can be found here.

What is credit card tokenization?

What is credit card tokenization and payment tokenization?

Credit card tokenization is an approach used by businesses, which process credit card payments, to reduce their PCI scope. In order to ensure cardholder data protection, PCI requires credit card numbers to be handled in a special way. Basically, the more contact with actual credit card numbers your payment system has, the higher your PCI scope is, and, consequently, you have undergo the more extensive annual PCI audit. Credit card tokenization service allows merchants to reduce their PCI scope by replacing real credit card numbers with tokens, which are generated using special hashing (and other) algorithms. The actual card numbers card numbers are stored by tokenization service provider, and not by the merchant, so if the merchant’s the system is ever compromised, the card numbers cannot be stolen. The term “credit card tokenization” is more accurate than “payment tokenization”, because it is card number that is actually replaced by a token.

How can credit card tokenization be implemented?

From conceptual viewpoint, there are two approaches to credit card tokenization. They can be called pure tokenization and customer profiling. Under the first credit card tokenization approach only the customer’s credit card number is tokenized when a transaction is processed. Under the second approach the whole profile of a customer is maintained and when a transaction is processed, all the data (card expiration date, billing address) which is necessary for the transaction to come through, is “pulled” from that profile.
From hardware viewpoint, there are also two approaches to credit card tokenization implementation. They are: tokenization through appliance and tokenization as service. Under the first approach the company needs a special PCI-compliant hardware device, to perform tokenization. Under the second approach credit card tokenization service is delegated to the payment gateway, credit card processor, or some third party. The second approach (credit card tokenization as service) can actually get the merchant out of PCI scope, although it requires more integration-related efforts. More information on credit card tokenization and its implementation can be found here .