WO2015080725A1

WO2015080725A1 - Method and system for facilitating multi-currency card payment transactions

Info

Publication number: WO2015080725A1
Application number: PCT/US2013/072221
Authority: WO
Inventors: Mike SIEGEL; Bill GREEN; Mark A. RUDNIK; Greg KUNKEL; Mark W. KIMBALL; Geralyn M. WRIGHT; Kimberly SHANE; Gail Anne RIZZO; Michael Rudy VONWALD; Robert Joseph ULE; Maureen Farrell; Sandie MORRIS; Randy LOMBARD; Allan LOUSHIN
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2013-11-27
Filing date: 2013-11-27
Publication date: 2015-06-04
Also published as: TW201528168A

Abstract

Implementations of the present disclosure disclose a system and method for facilitating multi-currency payment transactions. According to one implementation, a plurality of currency balances are ranked and associated with a user account. Upon receiving a request for authorization of a transaction amount in a purchase currency, at least one currency balance is converted to a different currency based on the purchase currency and the ranking of the currency balances. The transaction is authorized if one or more converted currency balances of the user account exceed the transaction amount.

Description

METHOD AND SYSTEM FOR FACILITATING MULTI-CURRENCY CARD PAYMENT TRANSACTIONS

BACKGROUND

[0001] Today, card payments - mainly due their ease of use and ubiquitous acceptance - are often the preferred means for completing a payment transaction. Though credit, debit, and prepaid cards are commonplace in the area of online purchases, they are equally important for retail purchases at physical merchant point-of-sale (POS) terminals. While travelling internationally and using such cards outside of its originating currency, however, cardholders may incur an inordinate amount of cross-border and currency conversion fees when making purchases abroad.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The features and advantages of the present disclosure as well as additional features and advantages thereof will be more clearly understood hereinafter as a result of a detailed description of implementations when taken in conjunction with the following drawings in which:

[0003] FIG. 1 is a simplified conceptual diagram of a system for facilitating multi-currency payment transactions according to an example implementation.

[0004] FIG. 2 is a simplified block diagram of the multi-currency payment transaction system according to an example implementation.

[0005] FIG. 3 is a sample illustration of the card identifier and currency hierarchy used to facilitate multi-currency payment transactions according to an example implementation.

[0006] FIG. 4 illustrates a sequence diagram of the processing steps for facilitating a multi-currency payment transaction according to an example implementation.

[0007] FIG. 5 illustrates a simplified flow chart of the processing steps for facilitating a multi-currency payment transaction according to an example implementation.

[0008] FIG. 6 illustrates another simplified flow chart of the processing steps for facilitating a multi-currency payment transaction according to an example implementation. DETAILED DESCRIPTION OF THE INVENTION

[0009] The following discussion is directed to various examples. Although one or more of these examples may be discussed in detail, the implementations disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any implementations is meant only to be an example of one implementation, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that implementation. Furthermore, as used herein, the designators "A", "B" and "N" particularly with respect to the reference numerals in the drawings, indicate that a number of the particular feature so designated can be included with examples of the present disclosure. The designators can represent the same or different numbers of the particular features.

[00010] The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the user of similar digits. For example, 143 may reference element "43" in Figure 1 , and a similar element may be referenced as 243 in Figure 2. Elements shown in the various figures herein can be added, exchanged, and/or eliminated so as to provide a number of additional examples of the present disclosure. In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the present disclosure, and should not be taken in a limiting sense.

[00011] Prior attempts to eliminate various fees associated with foreign card transactions include multi-currency prepaid cards, which allow cardholders to pre- purchase funds in specific currencies for the countries being visited. One problem associated with multi-currency prepaid cards is that the card is too dependent on the balance of each individual currency such that goods and services may only be purchased if the requisite purchase amount exists in a single currency balance. Other solutions calculate the cumulative balance of all currencies loaded on the prepaid card and only authorize the transaction if the cumulative net balance exceeds the transaction amount by a predetermined amount (e.g., cumulative balance exceeds transaction amount by more than five dollars in order to cover conversion fees).

[00012] Example implementations provide an improved system and method for facilitating multi-currency payment transactions by allowing cardholders to access funds across ail currency balances on the card for a single purchase. According to one example, implementations described herein convert the stored balances to a purchase currency and authorize transactions based on a hierarchy associated with the stored balances. Moreover, the present configuration serves to provide a user-friendly experience to the cardholder as the risk of being declined is eliminated if one or more of the currency balances on the card will cover the cost of the good and service being purchased.

[00013] Referring now in more detail to the drawings in which like numerals identify corresponding parts throughout the views, FIG. 1 is a simplified conceptual diagram of a system for facilitating multi-currency payment transactions according to an example implementation. As shown in the present example, the system 100 includes a merchant terminal 105 in communication with a host server 1 10 over a network 125.

[00014] The merchant terminal 105 represents a point-of-sale (POS) terminal or device utilized by a retailer to process card payments for the purchase of goods or services. The merchant terminal 105 may include a magnetic strip reader, near field communication (NFC) enabled device, Europay, Mastercard, and Visa (EMV) chip-based device for integrated circuit (IC) cards, or similar data-exchange protocol and device for reading data associated with the multicurrency card belonging to an operating user 102.

[00015] Furthermore, server 1 10 represents a financial institution or host service provider configured to authorize the transaction associated with a particular user account. More particularly, and as will be described in further detail with reference to figures below, the host server 1 10 may receive a payment authorization request from the merchant terminal via network 125 and send a payment authorization to the merchant terminal for completing the purchase if one or more currency balances associated with the user's account exceeds the purchase amount. [00016] FIG. 2 is a simplified block diagram of the muiti-currency payment transaction system according to an example implementation. FIG. 2 is a simplified block diagram of the system implementing the transparent layer for a touch-enabled computing device according to an example of the present disclosure. Here, the system 200 includes a POS terminal 215 in communication with service provider 210 over internetwork 225. The POS terminal 205 includes a card processing unit 207 for reading (e.g., via a magnetic strip) the data from the muiti-currency card. Furthermore, card identify information associated with the user along with the purchase amount of the transaction may be transmitted to the service provider 210 via communication interfaces 208, 218 and network 225.

[00017] Service Provider 210 represents a computing architecture having at least one computer system or host server, which may be operational with numerous other general purpose or special purpose computing system environments or configurations and may include, but is not limited to, personal computer systems, server computer systems, mainframe computer systems, laptop devices, multiprocessor systems, microprocessor-based systems, network personal computers, and distributed cloud computing environments that include any of the above systems or devices, and the like. Moreover, the host server provider system 210 may be described in the genera! context of computer system-executable instructions stored on a computer readable storage, such as program modules, being executed by a computer system. Also, the host server or service provider 210 may be associated with a financial institution and further includes a processing unit 212, user profile database 216, and a currency converter module 217.

[00018] Processor 207 may be, at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one graphics processing unit (GPU), other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 214, or combinations thereof. For example, the processor 212 may include multiple cores on a chip, include multiple cores across multiple chips, multiple cores across multiple devices, or combinations thereof. Processor 212 may fetch, decode, and execute instructions to implement the approaches of the multicurrency payment system. As an alternative or in addition to retrieving and executing instructions, processor 212 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the requisite functionality.

[00019] Machine-readable storage medium 214 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, machine-readable storage medium may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. As such, the machine-readable storage medium can be non-transitory. As described in detail herein, machine- readable storage medium 214 may be encoded with a series of executable instructions for facilitating the multi-currency payment transaction.

[00020] The user profile database 216 includes information pertaining to a registered user account. For example, user profile data may include credit or debit card information and a plurality of account balances in varying currencies and associated with a particular user. The user profile data 216 may be continually updated by the user accessing the host server 210 remotely or automatically as purchases are made on the user account and an associated currency balance.

[00021] Currency converter module 217 includes instructions for converting a currency balance to a purchase currency associated with a transaction amount. According to one example, the currency converter module 217 may be utilized by the processing unit to pull (e.g., via online sources) real-time (e.g., at the time of the authorization request) conversion rates for calculating the conversion from one currency to another; and namely conversion of a currency balance to a purchase currency, or a purchase currency to a primary currency balance for example. For instance, the currency conversion module may convert a user account balance of £20.00 EUR to $35.00 USD given a conversion rate of 1.75 and a transaction amount in a USD currency.

[00022] FIG. 3 is a sample illustration of the card identifier and currency hierarchy used to facilitate multi-currency payment transactions according to an example implementation. As shown here, the multi-currency card 302 may inciude an identifier 320 such as a credit card number, finger print reader, or similar user or card identifying means. In the present example, the user's card may be linked to multiple funded balances with various currency denominations (currency balances 322a - 322d). For example, the funded currency balances may include Euros (EUR) 322a, Australian Dollars (AUD) 322b, British Pounds (GBP) 322c, and United States Dollars (USD) 322d. These different currencies may also be set in hierarchical order by the user from a primary or highest priority level (e.g., Level 1 EUR) to a lowest priority level (e.g., Level 4 USD) based on the number of currencies funded by the user.

[00023] According to one implementation, transactions are approved by the host server if there are sufficient funds within one or more, but not necessarily all, of the currency balances (e.g., 322a - 322d) of the user account. More particularly, one or more of the currency balances 322a - 322d may be converted to the purchase currency associated with the payment transaction in the event that none of the currency balances 322a - 322d match the purchase currency, or if the matching currency balance is less than the transaction amount. Alternatively, the multi-currency payment system may enable a single currency card setup that allows a cardholder to nominate one currency balance on their card. In this example, as funds are loaded on the card they are converted to the nominated currency. When a purchase transaction is processed, a determination is made as to whether the purchase currency is the same as the nominated currency, and if so, then a currency conversion is not performed. On the other hand, if the transaction currency is not the same as the nominated currency, then a currency conversion will be computed for the nominated currency and all other remaining currencies on the card. Once a sufficient amount of funds for the transaction amount is validated, a payment authorization is sent to the POS terminal, or else the transaction is declined by the host server as will be described in further detail with reference to the figures below.

[00024] FIG. 4 illustrates a sequence diagram of the processing steps for facilitating a multi-currency payment transaction according to an example implementation. In segment 450, the user funds the multi-currency card 402 with a plurality of varying currency balances (e.g., USD, EUR, GBP), and also establishes a currency hierarchy or ranking order for each of the balances in segment 452. For example, the user may fund the card 402 at a financial institution or by registering and logging onto a web site hosted by the financial institution (i.e., host server) via a user interface and web-based browser of a client device. The user may then designate various currencies to be funded onto their multi-currency card using their bank routing information or another credit card for example. Next, in segment 454, the user log-in information, card identifier information, and currency balance information are saved on the host server 410 as user profile data.

[00025] Furthermore, when the user utilizes the multi-currency card 402 for the purchase of a good or service at a retail location 405 in segment 456, then an authorization request for payment is sent from the merchant 405 to the host server 410 in segment 458. Upon receiving the payment authorization request in segment 460, the host server 410 is configured to reference the user profile database and account information associated with the payment authorization request (e.g., via the card identifier information within request) and, if necessary, convert one or more currency balances to the purchase currency in segment 462. Moreover, in segment 464, the host 410 confirms the availability of sufficient funds in one currency balance or a combination of multiple currency balances based on the hierarchical order established by the user. Once validated in segment 464, a payment authorization is sent from the host server 410 to the POS terminal 405, which completes the purchase transaction in segment 468.

[00026] In one example scenario, a cardholder may nominate GBP as the primary currency (i.e., highest-ranked currency in hierarchy) and fund their multicurrency card with the following balances and priority levels:

[00027] In the event a sales transaction and authorization request is presented for £125.00 GBP, the host sever will approve the transaction without performing a currency conversion since the primary currency balance (i.e., Level 1 GBP) matches the purchase currency and exceeds the purchase amount by £25.00 GBP. In the event a second transaction is presented and an authorization is sent to the host server for a purchase amount of $300.00 AUD, the system will first check across the currency balances for a matching currency. In the present example, the host server will deduct $200.00 AUD from the Level 2 currency balance ($200.00 AUD) and reduce the transaction amount to $100.00 AUD. Since the system determines that there are insufficient funds in the instant (e.g., matching) currency balance to cover the complete transaction balance, the highest-ranked and funded currency balance is then retrieved by the system. Here, the remaining Level 1 currency balance of £25.00 GBP is then converted to $50.00 AUD (e.g., using a real-time GBP to AUD conversion rate of 2.0), and the Level 1 currency balance and transaction amount are reduced accordingly. With the Level 1 and Level 2 currencies now depleted, the system determines that an additional currency balance will be needed to cover the remaining transaction balance of $50.00 AUD. Therefore, the next highest-ranked and funded currency balance (Level 3) of $50.00 USD is then converted to $50.00 AUD (e.g., using a real-time USD to AUD conversion rate of 1.0). As such, the system will deduct the converted $50.00 AUD from both the Level 3 currency balance and the transaction amount such that Level 3 currency balance is exhausted and the purchase amount is fulfilled. Consequently, the host server sends an approval or authorization message to the POS terminal to complete the transaction.

[00028] In another example scenario, the user may fund the multi-currency card as follows below:

Hierarchy Currency Amount

Level 1 GBP £25.00

Level 2 AUD $100.00

Level 3 USD $75.00 [00029] According to one implementation, the host server may require that the full value of the transaction amount is satisfied or exceeded by a single currency balance without calculating the cumulative value across all currency balances associated with the user account. Using the example account setup above, and in the event of the host server receiving an authorization request for a $100.00 USD purchase, the host server may look at each currency balance for one that matches the purchase currency (USD). Here, the host server may determine that since the matching (instant or target) Level 3 currency balance is only $75.00 USD; there are insufficient funds to cover the full transaction amount. As such, the transaction currency of $100.00 USD may then be converted to the currency of the nominated or highest-ranked currency balance (i.e., GBP LeveH ) or £62.50 GBP (e.g., using a GBP to USD conversion rate of 1.6) and compared with the actual Level 1 currency balance of £25.00 GBP. Since there are insufficient funds in the GBP balance to cover the full transaction amount, the host server and processing unit proceed to check the next hierarchical currency balance or priority level (i.e., Level 2). Here, the $100.00 USD purchase amount is converted to $94.00 AUD (using a 0.94 AUD to USD conversion rate) and compared with the AUD balance of $100.00. Since there are sufficient funds in the Level 2 currency balance, the transaction is approved and a payment authorization confirmation is sent to the merchant terminal. However, the above scenario is just one example as each currency balance may instead be converted to the purchase currency, and the transaction amount may be also be reduced by each currency balance rather than the system searching for a single currency balance that satisfies the entire purchase amount.

[00030] In another implementation, the currency balances of the user account may be converted to the purchase currency when none of the currency balances of the user account match the purchase currency. Using the same multi-currency card setup as in the previous example, in the event the host server receives an authorization request for a€100.00 EUR transaction amount, the host server may look at each currency balance for one that matches the purchase currency (EUR). Here, the host server will determine that none of the currencies match the purchase currency. As such, the highest ranked and funded currency balance (Level 1 ) may then be converted to the purchase currency (EUR). For example, the £25.00 GBP Level 1 currency balance is converted to€30.00 EUR (e.g., using a GBP to EUR conversion rate of 1.2). Since there are insufficient funds in the highest-ranked currency balance (GBP) to cover the full transaction amount, the host server and processing unit deduct the converted €30.00 EUR from the €100.00 transaction amount while proceeding to check the next highest-ranked currency balance or hierarchical priority level (i.e., Level 2). Here, the $100.00 AUD Level 2 currency balance is converted to €67.00 EUR (using a 0.67 AUD to EUR conversion rate) and compared with the remaining transaction amount of €70.00. Since there are insufficient funds in the Level 2 currency balance, the converted funds (€67.00 EUR) are deducted from the Level 2 currency balance and the transaction amount. Next, the Level 3 currency balance is converted to the purchase currency in an attempt to satisfy the remaining€3.00 balance on the transaction amount. Here, the $75.00 USD Level 3 currency balance of the user account is converted to€55.50 EUR (e.g., based on a real-time USD to EUR conversion rate of 0.74). The system then determines that Level 3 currency balance exceeds the remaining transaction amount such that the transaction is approved and a payment authorization or confirmation is sent to the merchant terminal.

[00031] That is, implementations of the present system execute searches for a currency balance matching the purchase currency if it exists, and if nonexistent or insufficient to cover the transaction amount, executes currency conversion calculations (on either the currency balance or transaction currency) from the Level 1 to N balances to fulfill the remaining transaction amount. Moreover, calculating and converting each currency balance to a transaction currency (or vice versa) rather than converting both the currency balance and the purchase currency to a default currency as in prior solutions, allows for a more accurate calculation as one less computation is performed by the system, which could introduce further rounding errors and additional expenses.

[00032] FIG. 5 illustrates is a simplified flow chart of the processing steps for facilitating a multi-currency payment transaction according to an example implementation. In block 502, the host sever and processing unit receive profile date including a currency balance hierarchy for the multi-currency card from an operating user (e.g., via a computing device). As described above, an authorization request is sent to the financial institution or host server in block 504 upon detection of a user attempting to make a retail purchase with the multicurrency card. Next, in block 506, the host server and currency conversion module retrieve the latest currency exchange rates and calculate/convert one or more currency balances to the transaction currency if a currency balance matching the transaction currency is not discovered or in the event that the matching currency balance does not exceed the purchase amount. In one implementation, the currency of the transaction amount is converted to the currency of a nominated or primary currency balance as designated by the user. According to one example, the exchange rates are calculated as the transaction is processed so that the latest exchange rate information is used in the currency conversion computation. In block 508, the host server sends an authorization notification to the merchant terminal upon making a determination that sufficient funds are present in the user account associated with the multi-currency card involved the purchase transaction.

[00033] FIG. 6 illustrates another simplified flow chart of the processing steps for facilitating a multi-currency payment transaction according to one implementation. Initially, the user funds the multi-currency card with two or more balances of varying currencies as well as a hierarchical/ranking order to the each of the currency balances in block 602. In one example, as funds are added or withdrawn on the card, the cardholder may control which currency balance should be increased or decreased accordingly. Upon receiving a payment authorization request from the merchant terminal in block 604, the user profile data associated with the card identifier information is accessed from the profile database by the host server in block 606. A determination is made in block 608 whether the currency of one of the funded card balances on the user's account is equivalent to the currency associated with transaction amount (i.e., determine presence of GBP currency balance for a GBP purchase). Next, the host server determines in block 612 whether the currency balance of the instant priority level, which may be the primary currency balance or a currency balance matching the transaction currency, is greater than the purchase amount. If the balance of the matching currency is less than the purchase amount, then in block 614, the currency balance of the instant priority level is deducted from the transaction amount and the host server loops back through blocks 608 - 618 until a determination is made that either; (1 ) the converted funds of at least one currency balance exceeds the remaining purchase amount {block 612}, or (2) that ail balances on the card are depleted {block 618}. More particularly, if the transaction amount is greater than the highest-ranked (e.g., Level 1) or matching currency balance, the host sever will continue to check (in ranked order) the remaining currency balances and convert each currency balance to the purchase currency in an attempt to satisfy the total value of the transaction amount. Based on the determination made in blocks 612 and 618, the host server sends the POS terminal either an authorization to approve the transaction in block 616, or a message to decline (i.e., sum of balances is less than purchase amount) the transaction in block 620 respectively.

[00034] Implementations of the present disclosure provide a system and method for facilitating a multi-currency payment transaction. Moreover, many advantages are afforded by the implementations of the present disclosure. For instance, the present configuration servers to ensure that the cardholder's purchase will utilize the funds in all the various currency balances to effectively determine if the cardholder has sufficient funds on their card to make the desired purchase. Many prior solutions require the cardholder to manually transfer funds from one currency balance to another during a purchase transaction while implementations described herein save the cardholder the frustration of the purchase possibly being declined when there are actually sufficient funds to make the pending purchase. Moreover, the present configuration makes fewer balance conversions than prior solutions and may also reduce the total converted amount (i.e., does not automatically convert cumulative card balance) so as to reduce the amount of miscellaneous conversion and/or transaction costs incurred as a result of an international payment transaction.

[00035] Furthermore, while the disclosure has been described with respect to particular examples, one skilled in the art will recognize that numerous modifications are possible. Moreover, not all components, features, structures, characteristics, etc. described and illustrated herein need be included in a particular example or implementation. If the specification states a component, feature, structure, or characteristic "may", "might", "can" or "could" be included, for example, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to "a" or "an" element, that does not mean there is only one of the element. If the specification or claims refer to "an additional" element, that does not preclude there being more than one of the additional element.

[00036] It is to be noted that, although some examples have been described in reference to particular implementations, other implementations are possible according to some examples. Additionally, the arrangement o order of elements or other features illustrated in the drawings or described herein need not be arranged in the particular way illustrated and described. Many other arrangements are possible according to some examples.

[00037] The techniques are not restricted to the particular details listed herein. Indeed, those skilled in the art having the benefit of this disclosure will appreciate that many other variations from the foregoing description and drawings may be made within the scope of the present techniques. Accordingly, it is the following claims including any amendments thereto that define the scope of the techniques.

Claims

WHAT IS CLAIMED IS 1. A computer-implemented method for facilitating a payment transaction comprising:

associating a plurality of currency balances with a user account, wherein the user establishes a ranking order for each of the currency balances;

receiving a request for authorization of a payment transaction having a transaction amount in a purchase currency;

converting at least one currency balance to a different currency based on the purchase currency associated with the transaction amount and the ranking of each currency balance; and

authorizing the payment transaction if one or more converted currency balances of the user account exceed said transaction amount.

2. The method of claim 1 , wherein the converting step further comprises:

determining if at least one currency balance of the plurality of currency balances matches the purchase currency associated with the transaction amount; and

converting the highest-ranked currency balance to the purchase currency associated with the transaction amount if the plurality of currency balances does not match the purchase currency or if the matching currency balance is less than the transaction amount.

3. The method of claim 2, wherein the authorizing step further comprises:

determining if the converted highest-ranked currency balance exceeds the transaction amount; and

continually reducing the transaction amount by the plurality of currency balances until the transaction amount is exceeded by at least one converted currency balance on the user account.

4. The method of claim 3, wherein the transaction amount is reduced by a plurality of converted balances in the ranked order associated with the user account.

5. The method of claim 1, further comprising:

converting each of the plurality of balances to the purchase currency associated with the transaction amount;

providing for authorization of the payment transaction if only one of the converted balances exceeds the transaction amount.

6. The method of claim 1 , wherein the currency conversion is based on real-time conversion rates.

7. The method of claim 4, wherein the payment transaction is declined if the sum of the plurality of converted balances does not exceed the transaction amount.

8. A system for facilitating a payment transaction comprising:

a multi-currency card associated with a user account and a plurality of currency balances, wherein the user establishes a hierarchy level for each of the currency balances;

a merchant terminal for facilitating payment of the multi-currency card for a transaction amount in a purchase currency; and

a host server configured to communicate with the merchant terminal and convert at least one currency balance of the user account to the said purchase currency based on the hierarchy level of the currency balances and a currency match of at least one currency balance with the purchase currency,

wherein the host server sends the merchant terminal an authorization for the payment transaction if one or more currency balances of the user account exceed said transaction amount.

9. The system of claim 8, wherein the host server determines if a currency balance matches the purchase currency associated with the transaction amount and converts a first currency balance to the purchase currency of the transaction amount if none of the currency balances match the purchase currency or if the matching currency baiance is less than the transaction amount.

10. The system of ciaim 9, wherein the host determines if the converted currency balance exceeds the transaction amount and continually reduces the transaction amount by one or more converted currency balances until the transaction amount is exceeded by at least one converted balance.

11. The system of claim 10, wherein the transaction amount is reduced by the plurality of converted balances in the hierarchical order associated with the user account.

12. The system of claim 10, wherein the payment transaction is declined if the sum of the plurality of currency balances does not exceed the transaction amount.

13. The system of claim 8, wherein the currency conversion is based on real-time conversion rates.

14. A non-transitory computer readable medium for facilitating a payment transaction and having programmed instructions stored thereon for causing a processor to:

associate a plurality of currency balances with a user account, wherein the user establishes a priority level for each of the currency balances;

receive a request for authorization of payment transaction having a transaction amount in a purchase currency;

determine whether a currency balance of the user account matches the purchase currency associated with the transaction; and

convert at least one currency balance to the purchase currency associated with the transaction if the matching currency balance is less than the transaction amount or if none of the plurality of currency balances match the purchase currency; authorize the transaction if one or more converted currency balances exceed said transaction amount.

15. The non-transitory computer readable medium of claim 14, wherein the programmed instructions stored thereon further cause the processor to: determine if the converted balance exceeds the transaction amount; and continually reduce the transaction amount by the converting prioritized currency balances until the transaction amount is exceeded by at least one balance on the user account.