Patent Application
20200193421
The present disclosure relates to methods and systems that allow tourists having foreign bank accounts access to domestic payment instruments. More specifically, the present disclosure relates to methods and systems for providing a universal, global, virtual-to-physical payment adapter.
A country may have large numbers of visitors (e.g., tourists) every year. These visitors may have accounts at financial institutions in their home country but none in the visited country, or may possess a credit or debit card that is not accepted in the visited country, making it difficult for those visitors to engage in commerce in the visited country. Most retailers in other parts of the world do not have a mechanism in place to accept alternative payment methods, especially in physical retail.
Using the United States (US) as an example, in 2016, four million Chinese tourists visit the US every year, and spent about billion dollars on goods outside of travel, food, on lodging, averaging about $2500 per person per trip.
The US is an attractive tourist destination for Chinese tourists in particular due to the availability of a wide range of possible items, including non-counterfeit items. Chinese tourists tend to be large consumers of luxury goods and often buy in bulk, and are mostly directed by tour operators to locations where they can shop.
However, unlike the US, where credit cards such as MasterCard™ and VISA™, are ubiquitous, the use of these credit cards in China is very small, which means that most Chinese tourists do not have a Visa or MasterCard credit card, in which case transactions must be done in cash. A Chinese tourist can get a credit or debit card from China's UnionPay Bank, but this card is not accepted in many places in the US, in which case transactions again must to be done in cash. Either situation tends to restrict how much a visitor can spend in a physical store.
Furthermore, many Chinese do not use credit cards at all, and instead preferring to use WeChatPay™—a payment and money transfer feature of the messaging application WeChat™—for electronic payments (rather than cash) for many day-to-day purchases, and to use AliPay™ from AliBaba™ for making online payment of goods—similar to the use of PayPal™ in the US, and may also use AliPay mobile app for purchases in the physical stores.
As a result, there are significant barriers that prevent a Chinese tourist, for example, to engage in commercial transactions in the US. Enabling a US merchant to accept a UnionPay Bank credit card, a WeChat funds transfer, or an AliPay electronic transaction would require a significant and expensive change to the existing electronic payment infrastructure, and this is just in regard to two countries: Chinese visitors to the US.
The same barriers may exist to prevent visitors from countries other than China and for visitors to countries other than the US. Additional infrastructure changes may be required for each additional country supported as either a source of visitors or a target destination for those visitors.
Thus, there is a need to allow visitors from one country to perform commercial transactions within another country in the absence of a commonly supported payment instrument.
Methods and systems for providing a universal, global, virtual-to-physical payment adapter are provided. The subject matter of the present disclosure provides the physical and logical infrastructure to provide a universal interface between any type of payment or money transfer system and any payment acceptance system, and specifically bridges the gap between systems that transfer funds but can't directly to make purchases and the payment acceptance systems that process such purchases (such as Visa, Discover, Mastercard, BharatQR, WeChat Pay, and other payment systems used by merchants). In some embodiments, certain functionality is provided by an Omnyway Payment Server (OPS), which may include software, circuitry, processors, memory, and/or other hardware. The functions of an OPS may be distributed among multiple hardware entities and may be distributed across multiple physical, geographic, and/or logical locations.
In one application, for example, the methods and systems disclosed herein provide a bridge between social or mobile wallet applications that allow transfer of funds from person to person (e.g., Venmo, Zelle and others) and traditional payment methods including prepaid, debit, and credit cards (in physical or digital/virtual form) as currently accepted by the existing payment acceptance infrastructure. Such an application may be referred to as a Virtual-To-Physical Payment (V2PP) application or service.
In another application, for example, the subject of the present disclosure enables visitors from one country to make purchases, payments, or other transactions using the financial systems of another country. In one embodiment, methods and systems of the present disclosure offer a visitor to another country the freedom to use the visitor's preferred mobile payment method at physical retail stores in countries that they are visiting.
In one example scenario, Chinese tourists can make payments at US merchants using payment mechanisms already extant in the US. According to one embodiment, which will be described in more detail below, such a transaction may take place at a backend server in China (via WeChat, for example) while the US merchant is paid in dollars, with no change required at the merchant's Point Of Sale (POS) front-end.
In a second example scenario, US residents, tourists or visitors can use a mobile app or a personal computer to make payments at Chinese merchants using payment mechanisms already extant in China. According to one embodiment, which will be described in more detail below, such a transaction may take place at a backend server in or outside of China (via Visa, Mastercard, Discover, Venmo, or other payment schemes) while the Chinese merchant is paid in RMB, with no change required at the merchant's Point Of Sale (POS) front-end or eCommerce site.
Such an application for either scenario may be referred to as a Global Traveler Payment (GTP) application or service. It will be understood that V2PP and GTP may be considered different aspects of the services provided by an OPS.
The methods and systems of the present disclosure have utility far beyond enabling global traveler payments, however: they can be used to connect any type of payment or money transfer system with any payment acceptance system in one or more countries, whether the two systems are in the same country or in different countries. As such, the term “foreign” is used to mean “foreign to the existing payment acceptance infrastructure” rather than “foreign country”—although in some scenarios the payment or money transfer system and/or the payment acceptance infrastructure may indeed be in a foreign country or in different countries from each other.
A significant advantage that the methods and systems of the present disclosure have over prior art systems is that subject matter of the present disclosure allows the use of pre-existing payment systems without modification, e.g., requiring no software or hardware change in the existing POS system of a merchant.
According to one aspect of the present disclosure, a method for providing for providing a universal, global, virtual-to-physical payment adapter comprises receiving information associated with a desired domestic transaction, the information including information identifying a user and an amount in a first currency; converting the amount in the first currency to an amount in a second currency; sending information including the amount in the second currency; receiving an instruction to initiate the desired transaction;
sending, to a foreign bank, a request to authorize the desired transaction, the request including information for identifying the user and the amount in the second currency; receiving, from the foreign bank, authorization of the desired transaction, the authorization including information identifying the user; determining a card number or otherwise identifying a payment instrument associated with the identified user; sending, to a domestic bank, a request that funds be added to the payment instrument and/or that a credit limit of the payment instrument be changed;
According to another aspect of the present disclosure, a Omnyway Payment Server (OPS) server for providing a universal, global, virtual-to-physical payment adapter comprises at least one processor, and memory comprising instructions executable by the at least one processor whereby the process is adapted to operate according to any of the methods of the present disclosure.
According to yet another aspect of the present disclosure, an OPS server for providing a universal, global, virtual-to-physical payment adapter comprises one or more modules whereby the OPS server is adapted to operate according to any of the methods of the present disclosure.
According to yet another aspect of the present disclosure, an OPS server for providing a universal, global, virtual-to-physical payment adapter is adapted to operate according to any of the methods of the present disclosure
According to yet another aspect of the present disclosure, a computer program comprises instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods of the present disclosure.
According to yet another aspect of the present disclosure, a carrier contains the computer program above, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.
According to yet another aspect of the present disclosure, an OPS may present participating local merchants's offers and/or product information graphically, in text, or in voice to (local or traveler) users through social media app, mobile app, or a personal computer to show merchants using virtual-to-physical payment adapter to users, and may also incite users through discounts or offers to visit and make purchases at participating local merchants using computer program comprises instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods of the present disclosure.
According to one aspect of the present disclosure, a method for providing a universal, global, virtual-to-physical payment adapter comprises: receiving first information associated with a desired transaction, the information comprising information identifying a user and an amount; sending, to a first financial entity, a request to authorize the desired transaction, the request comprising information for identifying the user and the amount; receiving, from the first financial entity, authorization of the desired transaction, the authorization comprising information identifying the user; determining a payment instrument or financial account to be involved in the transaction; sending, to a second financial entity, a request to prepare the payment instrument or financial account for the desired transaction; receiving, from the second financial entity, a result of that request; and sending, to the identified user, an instruction to initiate the desired transaction.
In some embodiments, the first financial entity and the second financial entity comprise domestic banks.
In some embodiments, the first financial entity comprises a foreign bank and wherein the second financial entity comprises a domestic bank; or the first financial entity comprises a domestic bank and wherein the second financial entity comprises a foreign bank and wherein receiving the first information comprises receiving the first information from a mobile application or personal computer of the user.
In some embodiments, receiving the information identifying an amount comprises receiving information identifying an amount in a first currency and wherein the method further comprises, prior to sending the request to authorize the desired transaction: converting the amount in the first currency to an amount in a second currency; sending the amount in the second currency to the user for approval; and receiving from the user approval to send the request to authorize the desired transaction.
In some embodiments, determining the payment instrument or financial account to be involved in the transaction comprises determining a payment instrument to be involved in the transaction; sending the request to prepare the payment instrument or financial account for the desired transaction comprises sending a request that funds be added to the payment instrument and/or that a credit limit of the payment instrument be changed; and sending the instruction to initiate the desired transaction comprises sending an instruction to present the payment instrument to a merchant involved in the desired transaction for processing by the merchant.
In some embodiments, receiving the first information further comprises receiving information identifying a Point Of Sale, POS, terminal or other merchant equipment for performing a transaction; determining the payment instrument or financial account to be involved in the transaction comprises determining a financial account associated with the merchant equipment; sending the request to prepare the payment instrument or financial account for the desired transaction comprises sending a request that funds be added to the financial account and/or that a credit limit of the financial account be changed; and sending the instruction to initiate the desired transaction comprises sending an instruction to request the merchant to process the desired transaction using the financial account associated with the merchant equipment.
In some embodiments, the method further comprises: receiving an indication of the result of the processed transaction; and notifying the user of the result of the processed transaction.
According to another aspect of the present disclosure, a payment server for providing a universal, global, virtual-to-physical payment adapter comprises: at least one processor; and memory comprising instructions executable by the at least one processor whereby the payment server is configured to: receive first information associated with a desired transaction, the information comprising information identifying a user and an amount; send, to a first financial entity, a request to authorize the desired transaction, the request comprising information for identifying the user and the amount; receive, from the first financial entity, authorization of the desired transaction, the authorization comprising information identifying the user; determine a payment instrument or financial account to be involved in the transaction; send, to a second financial entity, a request to prepare the payment instrument or financial account for the desired transaction; receive, from the second financial entity, a result of that request; and send, to the identified user, an instruction to initiate the desired transaction.
In some embodiments, the first financial entity and the second financial entity comprise domestic banks.
In some embodiments, the first financial entity comprises a foreign bank and wherein the second financial entity comprises a domestic bank.
In some embodiments, receiving the information identifying an amount comprises receiving information identifying an amount in a first currency and wherein the payment server is further configured to, prior to sending the request to authorize the desired transaction: convert the amount in the first currency to an amount in a second currency; send the amount in the second currency to the user for approval; and receive from the user approval to send the request to authorize the desired transaction.
In some embodiments, determining the payment instrument or financial account to be involved in the transaction comprises determining a payment instrument to be involved in the transaction; sending the request to prepare the payment instrument or financial account for the desired transaction comprises sending a request that funds be added to the payment instrument and/or that a credit limit of the payment instrument be changed; and sending the instruction to initiate the desired transaction comprises sending an instruction to present the payment instrument to a merchant involved in the desired transaction for processing by the merchant.
In some embodiments, receiving the first information further comprises receiving information identifying a Point Of Sale (POS) terminal or other merchant equipment for performing a transaction; determining the payment instrument or financial account to be involved in the transaction comprises determining a financial account associated with the merchant equipment; sending the request to prepare the payment instrument or financial account for the desired transaction comprises sending a request that funds be added to the financial account and/or that a credit limit of the financial account be changed; and sending the instruction to initiate the desired transaction comprises sending an instruction to request the merchant to process the desired transaction using the financial account associated with the merchant equipment.
In some embodiments, the payment server is further configured to: receive an indication of the result of the processed transaction; and notify the user of the result of the processed transaction.
In some embodiments, the payment server is further configured to: present participating local merchants' offers and/or product information graphically, in text, or in voice to users; identify merchants that support the services provided by the payment server; and/or incite users through discounts or offers to visit and make purchases at participating local merchants.
In some embodiments, the payment server provides notifications to the user via a social media app, a mobile app, or a personal computer.
According to another aspect of the present disclosure, a payment server for providing a universal, global, virtual-to-physical payment adapter is configured to: receive first information associated with a desired transaction, the information comprising information identifying a user and an amount; send, to a first financial entity, a request to authorize the desired transaction, the request comprising information for identifying the user and the amount; receive, from the first financial entity, authorization of the desired transaction, the authorization comprising information identifying the user; determine a payment instrument or financial account to be involved in the transaction; send, to a second financial entity, a request to prepare the payment instrument or financial account for the desired transaction; receive, from the second financial entity, a result of that request; and send, to the identified user, an instruction to initiate the desired transaction.
In some embodiments, the payment server is configured to perform any of the methods described herein.
According to another aspect of the present disclosure, a payment server for providing a universal, global, virtual-to-physical payment adapter comprises one or more modules operable to: receive first information associated with a desired transaction, the information comprising information identifying a user and an amount; send, to a first financial entity, a request to authorize the desired transaction, the request comprising information for identifying the user and the amount; receive, from the first financial entity, authorization of the desired transaction, the authorization comprising information identifying the user; determine a payment instrument or financial account to be involved in the transaction; send, to a second financial entity, a request to prepare the payment instrument or financial account for the desired transaction; receive, from the second financial entity, a result of that request; and send, to the identified user, an instruction to initiate the desired transaction.
In some embodiments, the one or more modules are further operable to perform any of the methods described herein.
According to another aspect of the present disclosure, a non-transitory computer readable medium stores software instructions that, when executed on at least one processor, cause the at least one processor to: receive first information associated with a desired transaction, the information comprising information identifying a user and an amount; send, to a first financial entity, a request to authorize the desired transaction, the request comprising information for identifying the user and the amount; receive, from the first financial entity, authorization of the desired transaction, the authorization comprising information identifying the user; determine a payment instrument or financial account to be involved in the transaction; send, to a second financial entity, a request to prepare the payment instrument or financial account for the desired transaction; receive, from the second financial entity, a result of that request; and send, to the identified user, an instruction to initiate the desired transaction.
According to another aspect of the present disclosure, a computer program comprises instructions which, when executed on at least one processor, cause the at least one processor to: receive first information associated with a desired transaction, the information comprising information identifying a user and an amount; send, to a first financial entity, a request to authorize the desired transaction, the request comprising information for identifying the user and the amount; receive, from the first financial entity, authorization of the desired transaction, the authorization comprising information identifying the user; determine a payment instrument or financial account to be involved in the transaction; send, to a second financial entity, a request to prepare the payment instrument or financial account for the desired transaction; receive, from the second financial entity, a result of that request; and send, to the identified user, an instruction to initiate the desired transaction.
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the invention, and together with the description serve to explain the principles of the invention.
Card embodiments according to embodiments of the present disclosure.
The embodiments set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
Methods and systems for providing a universal virtual to physical payment adapter are presented herein. The subject matter of the present disclosure provides the physical and logical infrastructure to provide a universal interface between any type of payment or money transfer system and any payment acceptance system, and specifically bridges the gap between systems that transfer funds but can't directly to make purchases and the payment acceptance systems that process such purchases (such as Visa, Discover, Mastercard, AliPay, WeChat Pay, BharatQR and other systems used by merchants).
In one application, for example, the methods and systems disclosed herein provide a bridge between social or mobile wallet applications that allow transfer of funds from person to person (e.g., Venmo, Zelle and others) and traditional payment methods including prepaid, debit, and credit cards (in physical or digital form) as currently accepted by the existing payment acceptance infrastructure.
In another application, for example, the subject of the present disclosure enables visitors from one country to make purchases, payments, or other transactions using the financial systems of another country. For example, Chinese tourists can make payments at US merchants using payment mechanisms already extant in the US. According to one embodiment, which will be described in more detail below, such a transaction may take place at a backend server in China (via WeChat, for example) while the US merchant is paid in dollars, with no change required at the merchant's Point Of Sale (POS) front-end. Such an application may be referred to as a Omnyway Payment Server (OPS) application or service.
The methods and systems of the present disclosure have utility far beyond enabling global traveler payments, however: they can be used to connect any type of payment or money transfer system with any payment acceptance system in one or more countries, whether the two systems are in the same country or in different countries. As such, the term “foreign” is used to mean “foreign to the existing payment acceptance infrastructure” rather than “foreign country”—although in some scenarios the payment or money transfer system and/or the payment acceptance infrastructure may indeed be in a foreign country or in different countries from each other.
A significant advantage that the methods and systems of the present disclosure have over prior art systems is that subject matter of the present disclosure allows the use of pre-existing payment systems without modification, e.g., requiring no software or hardware change in the existing POS system of a merchant.
As used herein, the term “authorization” refers to the process by which a financial system determines whether or not a buyer has sufficient funds to complete a purchase or other financial transaction. If so, the transaction is authorized; if not, the transaction is denied. Authorization happens in real time, at the time the transaction is attempted (e.g., when the buyer “swipes” his or her credit card at a POS terminal).
As used herein, the term “settlement” refers to the process that takes place after successful authorization in which funds are transferred from an account of the buyer to an account of the seller (e.g., the retailers get their money from the sale). Settlement happens after authorization, sometimes hours or days later.
As used herein, the term “application”, when used as a noun, refers to a software program that runs or is hosted on a computing device, such as a personal computer, smartphone, or other electronic device. An application may alternatively be referred to as “an app”.
In the embodiment illustrated in
The merchant 14 may comprise a Point Of Sale (POS) terminal or an internet connected device accepting online payments (smartphone, tablet, PC, etc.), in which case the merchant 14 may also be referred to herein as “the merchant POS 14” or “the POS 14”. The Acquiring Bank 16 may also be referred to herein as “the domestic bank 16”, “the domestic financial entity 16”, or “the domestic entity 16”. The Issuing Bank 18 may also be referred to herein as “the foreign bank 18”, “the foreign financial entity 18”, or “the foreign entity 18”.
In the embodiment illustrated in
In the embodiment illustrated in
An example operation of system 10 will now be described.
In the embodiment illustrated in
At step 204, the user 20 begins to shop, e.g., at a physical or online store of the merchant 14. In the embodiment illustrated in
In one embodiment, if the user 20 decides to complete the purchase, the user 20 may notify the OPS 12 by sending a instruction or request to confirm the purchase (step 214), e.g., by tapping on a “confirm purchase?” button on the OPS application or other means. In one embodiment, upon receiving the confirmation in step 214, the OPS 12 will initiate a request for payment from the foreign bank 18 (step 216). In the embodiment illustrated in
In the embodiment illustrated in
In the embodiment illustrated in
In the embodiment illustrated in
In the embodiment illustrated in
At step 300, the user 20 begins to shop, e.g., at a physical or online store of the merchant 14. In the embodiment illustrated in
At step 306, the user 20 communicates the total in the domestic currency, as well as some information that identifies the POS or other merchant equipment, to the OPS 12. In one embodiment, the user 20 enters the total into the OPS application on their smartphone. In one embodiment, the user scans a QR code displayed by the merchant or the POS terminal; the QR code contains the POS ID or other identifier of a merchant equipment. In other embodiments, this information may be obtained via manual entry, scanning or text or bar codes, via wireless communication with the POS or other merchant equipment, etc. In some embodiments, the local payment system being supported by the merchant could be automatically recognized by the OPS 12 through data received from a user mobile or social application, or from a PC, e.g., a QR code read by the user's mobile or social app as displayed by the local merchant. In the embodiment illustrated in
In one embodiment, if the user 20 decides to complete the purchase, the user 20 may notify the OPS 12 by sending a instruction or request to confirm the purchase (step 310), e.g., by tapping on a “confirm purchase?” button on the OPS application or other means. In one embodiment, upon receiving the confirmation in step 310, the OPS 12 will initiate a request for payment from the foreign bank 18 (step 312). In the embodiment illustrated in
In the embodiment illustrated in
In the embodiment illustrated in
In the embodiment illustrated in
Steps 338, 340, and 342 remaining in
The process illustrated in
WeChat™ is a master application that can host applications, which can likewise host other applications, or “apps within apps”. In other words, WeChat™ operates like an extensible framework. In one embodiment, WeChat™ hosts an Omnyway™ application or subscription, which the Chinese traveler downloads into or subscribes to in WeChat™ prior to leaving China, or on their arrival in the destination country. In one embodiment, the Omnyway™ application may contain special offers and promotions targeted to particular cities, destinations, and/or stores.
In the embodiment illustrated in
In the embodiment illustrated in
The operation of the system illustrated in
Once in the destination country, if the user wants to make a purchase, in one embodiment, the user shows the app to the retailer so that the retailer can scan the information that is presented by the app to the retailer. Example information includes, but is not limited to, discounts, special offers, coupons, other incentives, or other information that may be pertinent to the transaction. In one embodiment, the retailer then provides a (potentially discounted) total to the user. The user enters the total into the Omnyway™ application.
In one embodiment, Omnyway™ will work with the domestic bank that issues the physical cards, e.g., domestic bank 16. In one embodiment, the OPS 12 captures the card swipe information (card number, merchant ID, terminal ID, and/or total amount, etc.) from the merchant POS 26 and transfers this to information to the domestic bank 16 via a payment network such as the Visa™, Discover™, or MasterCard™ network. This US portion of the transaction goes through the normal authorization process to verify that the user has sufficient funds. In one embodiment, the domestic bank 16 will have created the equivalent of a prepaid card for the exact amount, in which case the domestic bank 16 will respond to the authorization request with an indication that there is enough money in the account. In this manner, the OPS 12 operates to create an instant account on the card. Once the domestic bank 16 processes the authorization, the exact amount is removed from the card, and the card will again have no value.
In one embodiment, during settlement, funds are moved from the user's account to an intermediary account that is controlled by Omnyway™, which may be an account in the user's home country, the country being visited, or in another country. In the above example, funds may be moved from the Chinese tourist's account to a bank account in a Chinese bank.
In the embodiments described above, WeChat™ operates as the front-end to the foreign bank(s) 18. In another embodiment, an additional entity may operate as an intermediary between the OPS 12 and various payment infrastructures. An example of such an entity is ADYEN™, which provides a unified API to backend payment processors such as WeChat™, AliPay™, Visa·8, Discover™, and others. In such embodiments, the foreign payment scheme/processor 24 in
In yet another embodiment, the OPS 12 may be configured to use different payment infrastructures, and optionally use different payment infrastructures for different purposes. For example, in one embodiment, the OPS 12 may be configured to provide a front-end prepaid card and a backend payment via either WeChat™ or AliPay™. In one embodiment, the user may use an Omnyway™ smartphone application to select whether to use WeChat™ or AliPay™, which determines which backend settlement process to use.
In yet another embodiment, the OPS 12 may be configured to work with new generation of Social payment, Mobile payment, or Real Time ACH payment infrastructure that is not integrated with a traditional payment acceptance infrastructure within a country, where the user could be a local resident besides a Traveler from another country. For example, in one embodiment, the OPS 12 may be configured to provide a front-end foreign or local issued prepaid, credit, or debit (physical and/or virtual) card and a backend payment via either Zelle™ or Venmo™ in the United States, PayMe™ in Hong Kong, Faster Payments in UK, and IMPS or Pay™ in India, WeChat Pay or AliPay in China, and additional new generation payments in same or other countries. For example: US residents, tourists or visitors can use a third party or social media mobile app or a personal computer to make payments at Chinese merchants using payment mechanisms already extant in China. Such a transaction may take place at a backend server inside or outside of China (via Visa, Mastercard, Discover, Venmo, or other payment schemes) while the Chinese merchant is paid in RMB, with no change required at the merchant's Point Of Sale (POS) front-end or eCommerce site. In one embodiment, the user may use an Omnyway™ smartphone, social or bot application to select whether to use Zelle℠ or Venmo™ in United States, PayMe™ in Hong Kong, Faster Payments in UK, IMPS or Pay™ in India, and additional new generation payment systems in same and other countries, which determines which backend settlement process to use.
In one embodiment, the card provided to the user 20 is a credit card. In one embodiment, the transaction information is provided to the issuing bank (e.g., the foreign bank 18), which verifies that the user's credit is good (e.g., there is no actual balance on the account). The merchant 14 gets the money during settlement, usually a day later. If the user 20 fails to pay the credit card bill, the issuing bank suffers the loss.
In one embodiment, the card provided to the user 20 is a prepaid card. In one embodiment, the transaction goes to the bank that issued the prepaid card (e.g., the domestic bank 16), which verifies that the prepaid card has an actual balance sufficient to cover the transaction, in which case the transaction is processed and money is transferred from the prepaid card account to the merchant account. If the prepaid card balance is not sufficient to cover the transaction, in one embodiment the domestic bank 16 indicates how much money is available. For example, the merchant 14 may be notified that the card has X amount of funds, and the user 20 should pay the remaining balance of Y by cash or using a different card or financial instrument. In these embodiments, the OPS 12 instantly creates a prepaid card with a specific amount.
In one embodiment, the system is configured to support multiple front-end systems (e.g., prepaid card, credit card, debit card, virtual card, etc.) as well as multiple back-end systems (e.g., ADYEN™, WeChatPay™, AliPay™, Tenpay, Visa™, MasterCard, Discover, American Express, JCB, CUP, Zelle℠, Venmo™, IMPS, PayMe™, Yandex Pay, Pay™, Cartes Bancaires, SEPA direct debit, Giropay, Sofort, iDEAL, Qiwi, JioMoney, BHIM, BACS Direct, Interac, Boleto, Elo, POLi, Carrier Billing, Pay-easy, Konbini, paysafecard, Pay-by-links, Hipercard, etc.)
In alternative embodiments, however, the merchant may be issued a physical card, which the merchant swipes (or inserts if it is a chip card) on its point of sale system at the time of transaction. In one embodiment, the user may scan or otherwise acquire information (e.g., a QR code) from the merchant's card, which may then be sent to an OPS 12 by, for example, an application on the user's mobile device. Examples of both User Card and Merchant Card implementations may be found
For example, in one embodiment, a customer selects items for purchase and takes them to a POS sale register at merchant premises, and the merchant begins the checkout process. Before, during, or after the checkout process the user receives information, provided by the merchant, that identifies the POS terminal or other equipment (such as a tablet device with hardware that can read information from a credit card) engaged in the checkout process. This information may be a POS terminal ID or other information that identifies the equipment involved in the checkout process or otherwise involved in the commercial transaction. For simplicity of description, the term POS terminal will be used for the remainder of this example, but the subject matter of the present disclosure is not limited to just POS terminals.
In one embodiment, the user may scan a QR code, bar code, or other graphic element using the user's mobile phone. Such information may be displayed by the POS terminal, displayed somewhere else on the merchant premises, or otherwise provided by the merchant via other means, including but not limited to via wired or wireless communication, provided aurally to the user, recited to the user who then enters the information manually, etc. This information is provided to the the OPS 12, e.g., via an application on the user's smart device.
In one embodiment, the OPS 12 uses that information to identify the merchant and/or identify the entity/location of the transaction in progress. In one embodiment, each POS terminal (or other device) is associated with its own credit card/debit card/prepaid card account or other financial account, hereinafter referred to as the “card account” for brevity, in which case the OPS 12 uses the received information to identify the card account associated with the POS terminal as well as financial institution associated with the card account, referred to herein as the “issuing bank”.
The merchant notifies the user of the total, which the user enters into the application, and which the application provides to the OPS 12. The OPS 12 then verifies that the user has sufficient funds or credit in the user's account, and if not, in one embodiment the OPS 12 notifies the user that the transaction is denied.
If the user has sufficient funds or credit limit, in one embodiment, the OPS 12 requests confirmation of the transaction from the user. If needed, the OPS 12 may convert the total from a domestic currency to the user's native currency, which is displayed to the user during the request for confirmation. If the user approves the transaction, the OPS 12 instructs the issuing bank to transfer funds (if a debit card or prepaid card) or increase the credit limit (if a credit card) in an amount sufficient to cover the transaction total.
The OPS 12 then notifies the user to instruct the merchant to “swipe the card”, which may entail actually swiping a physical card maintained by the merchant, or may entail virtually swiping a virtual card via a software process, but in either case is processed like a normal credit/debit/prepaid card transaction using existing systems. The existing payment network processes and approves the transaction, then notifies the OPS 12 of the result, which the OPS 12 provides to the user, e.g., via the user's mobile application.
Advantages of the systems and methods of the present disclosure include, but are not limited to: providing opportunities to bring foreign visitors to US businesses; providing opportunities to provide discounts and inducements to customers to come to particular merchants; providing a framework for shared fees, referral fees, affiliate fees, and the like.
In addition, the systems and methods of the present disclosure may be tuned to the customs, practices, and needs of particular countries. For example, in Germany, debit cards are used more frequently than credit cards; thus, in one embodiment, the “prepaid card” mechanism will not be used, in favor of another, equally valid mechanism. In another example, some countries only accept credit cards from a few, well-known providers, such as Visa™, Discover™ and MasterCard™; in these countries, the systems and methods of the present disclosure would coordinate with these providers instead of with WeChatPay™, for example. In yet another example, India has created a system called Aadhaar that links bank information to biometric information. Thus, in one embodiment, the OPS 12 may be configured to transmit, receive, and process biometric or other specialty information.
In order to uniquely identify entities that participate in the OPS systems and methods of the present disclosure, in one embodiment the OPS 12 creates and maintains a universal identifier, or “universal ID”, for each individual. In one embodiment, an individual is a physical person. In one embodiment, a universal ID may be mapped to a combination of person +payment instrument. For example, a universal ID may be mapped to both one person with a Visa™ card and to another person with a MasterCard™ card.
In one embodiment, universal IDs may be logically grouped, e.g., as members of a business entity, as members of a family unit, or other logical groupings. In one embodiment, transactions are specific to a particular individual identified by a universal ID while discounts and promotions may be offered to individuals or to logical groups of individuals. In one embodiment, each logical group does not have its own universal ID, but in alternative embodiments, a logical group may have its own universal ID.
In one embodiment, the OPS 12 may include or communicate with a database for storing and maintaining universal ID information.
Those skilled in the art will recognize improvements and modifications to the preferred embodiments of the present invention. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.
This application claims the benefit of provisional application Ser. No. 62/546,541, filed Aug. 16, 2017, the disclosure of which is hereby incorporated herein by reference in its entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2018/056209 | 8/16/2018 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62546541 | Aug 2017 | US |
