Patent Application
20160034888
Disclosed herein are methods and systems for facilitating payment from a branded stored-value account. In the disclosed systems and methods, a communications interface of a service provider system receives a confirmation that a stored-value account, branded for a first merchant, contains a value. The communications interface also receives a request to enable a payment using the value from the first-merchant-branded stored-value account at a second merchant. Then the communications interface transmits a request to the first-merchant-branded stored-value account for an amount from the first-merchant-branded stored-value account and receives the requested amount from the first-merchant-branded stored-value account. The communications interface and a processor of the service provider system then place the amount in a virtual account, and the communications interface initiates a display showing the amount in the virtual account as a branded stored-value account for the second merchant.
Together with this written description, the figures further explain the principles of, and to enable a person skilled in the relevant art, to make and use the claimed systems and methods.
Stored-value accounts have risen in popularity as an alternative to cash or other forms of payment. A stored-value account refers to monetary or other value (such as points, miles, Stars (Starbucks rewards), and alternative currencies such as Bitcoin) stored in a merchant account for use at that specific merchant. Stored-value accounts may be loaded one time or can be rechargeable. One-time load accounts have a one-time limit, for example merchant gift cards and prepaid phone cards.
Rechargeable accounts, on the other hand, can be reloaded and used again like a credit card. But unlike a credit card, the user cannot go into debt with a stored-value account because the user can only use the amount in the account. One popular example of a stored-value account is the Starbucks Card that allows users to add money to their account, earn birthday and other rewards, and receive exclusive offers, all for use at Starbucks and affiliated merchants. Stored value-accounts, including stored-value cards, can save customers and/or merchants considerable amounts of money by allowing lower transaction fees for the customers and/or merchants for each use of the stored-value account.
Two additional categories of stored-value accounts are closed-system accounts and semi-closed-system accounts. In closed-system accounts, payments from the account are only accepted at a single merchant. For example, a customer may buy a card for a fixed amount and can only use the card at the merchant that issued the card. Merchants often prefer these types of accounts because they ensure the stored funds are spent only at their stores. Generally, few if any laws govern these types of accounts, and closed-system account issuers are not normally required to obtain a money transmitter license.
Semi-closed system accounts are similar to closed-system accounts. However, holders of semi-closed system accounts are permitted to make payments using their accounts at multiple merchants, for example, those within a geographic area. These types of accounts are generally issued by a third party, rather than the merchant who accepts the card. Examples include university card accounts and mall gift card accounts. The laws governing these types of cards are unsettled. Depending on the state, the issuer may or may not be required to have a money transmitter license or other similar license. For example, the District of Columbia, Connecticut, Florida, Illinois, Iowa, Louisiana, Maryland, Minnesota, Mississippi, North Carolina, Oregon, Texas, Vermont, Virginia, West Virginia, Washington, and Wyoming all explicitly require a money transmitter license to operate a semi-closed stored-value system. And other states may require a license depending on the interpretation of their laws. Moreover, under federal law, it is a crime for an issuer to conduct a money transmitting business without a license.
In addition to the possible legal pitfalls with semi-closed systems and the need for a money transmitter license, semi-closed systems suffer from problems with customer perception of who is responsible for a given transaction. For example, if a customer purchases a stored-value account at a first merchant and uses the account at a second merchant within a semi-closed system, the customer may not know who is responsible for problems with the transaction: the first merchant, the second merchant, or the third-party issuer. Because customer service is very expensive, the first merchant may not want to provide customer service for a transaction made at the second merchant without some prior agreement between the merchants and an agreed-upon method for accounting and reporting the costs of the customer service to the second merchant or the third-party issuer.
According to one embodiment, systems and methods for facilitating payment from a branded stored-value account that overcome many of the difficulties of the current systems. Un a further embodiment, the systems and methods do not require merchants to obtain money transmitter licenses and that overcome the problems of customer-identification of the responsible merchant.
References to “one embodiment”, “an embodiment”, “example embodiment”, “various embodiments”, etc., indicate that the embodiment(s) so described may include particular features, structures, or characteristics, but not every embodiment necessarily includes the particular features, structures, or characteristics. Further, some embodiments may have some, all, or none of the features described for other embodiments.
In a scenario consistent with
According to one embodiment, the service provider system 103 receives a request to enable a payment using the value in the stored-value account 104 for the first merchant 101 at the second merchant 102. The request can come from various sources including the customer 100, the first merchant 101, or the second merchant 102. Alternatively, the request may be generated automatically including through geolocation information for the customer. For example, geolocation information may be used to determine that the customer 100 has entered a physical location of the second merchant 102 and the request to enable a payment could be sent automatically to the service provider 103 or generated by a portion of the service provider system 103 according to the geolocation information.
The service provider system 103 also receives a confirmation that the stored-value account 104 contains a value. Alternatively, the service provider system 103 receives a confirmation by determining from its own records that the stored-value account 104 contains a value. The service provider system 103 then transmits a request to the entity responsible for holding or maintaining the first-merchant-branded stored-value account 104 for an amount from the stored-value account 104 for the customer 100 to use at the second merchant 102. The service provider system 103 receives the requested amount from the entity responsible for holding or maintaining the first-merchant-branded stored-value account 104 and places the amount in a virtual account 105. Then the service provider system 103 initiates a display showing the amount in the virtual account as a branded stored-value account for the second merchant 102. This display can be a display on computer screen or mobile device for the customer 100 or it may be a printed sheet or card indicating that the second-merchant 102 is responsible for the second-merchant-branded stored-value account. The display showing the amount in the virtual account as a branded stored-value account for the second merchant may also show contact information for the second merchant. Contact information can be a phone number, email address, website link, click-to-chat, click-to-dial, or the like. The display indicating that the second-merchant 102 is responsible for the new stored-value account is important so that the customer 100 knows to contact the second merchant 102 regarding any issues with the virtual stored-value account including returns, balance inquiries, or issues requiring customer service. Also, in this embodiment, because the service provider handles the transmission of any money instead of the first merchant 101 or the second merchant 102, the merchants are not required to obtain money transmitter licenses.
The service provider system 103 may comprise one or more computer systems capable of carrying out the functionality described herein. For example,
Service provider system 300 also includes a main memory 302, such as random access memory (RAM), and may also include a secondary memory 306. The secondary memory 306 may include, for example, a hard disk drive 307 and/or a removable storage drive 308, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, flash memory device, etc. The removable storage drive 308 reads from and/or writes to a removable storage unit 310. Removable storage unit 310 represents a flash memory device including a USB drive, etc., which is read by and written to by removable storage drive 308. The removable storage unit 310 includes a computer usable storage medium having stored therein computer software, instructions, and/or data.
In alternative embodiments, secondary memory 306 may include other similar devices for allowing computer programs or other instructions to be loaded into a service provider system 300. Such devices may include, for example, a removable storage unit 311 and an interface 309. Examples of such may include a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 311 and interfaces 309, which allow computer software, instructions, and/or data to be transferred from the removable storage unit 311 to a service provider system 300.
Moreover, embodiments may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of one or more data signals embodied in and/or modulated by a carrier wave or other propagation medium via a communication link (e.g., a modem and/or network connection).
Service provider system 300 may also include a communications interface 312. Communications interface 312 allows computer software, instructions, and/or data to be transferred between a service provider system 300 and external devices. Examples of communications interface 312 may include a wired or wireless network interface, a communications port, etc. Software and data transferred via communications interface 312 are in the form of signals 313 which may be electronic, electromagnetic, optical, or other signals capable of being transmitted or received by communications interface 312. These signals 313 are provided to and from the communications interface 312 via a communications path (e.g., channel) 314. This channel 314 carries signals 313 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a wireless communication link, and other communications channels.
Computer programs (also referred to as computer control logic) are stored in main memory 302 and/or secondary memory 306. Computer programs may also be received via communications interface 312. Such computer programs, when executed, enable the service provider system 300 to perform features discussed herein. In particular, the computer programs, when executed, enable the processor 301 to perform the features of the presented methods. Accordingly, such computer programs represent controllers of the service provider system 300.
In an embodiment, software may be stored in a computer program product and loaded into a service provider system 300 using removable storage drive 308, interface 309, hard drive 307, or communications interface 312. The control logic (software), when executed by the processor 301, causes the processor 301 to perform the functions and methods described herein.
In another embodiment, the methods are implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions and methods described herein will be apparent to persons skilled in the relevant art(s). In yet another embodiment, the methods are implemented using a combination of both hardware and software.
Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing firmware, software, routines, instructions, etc.
In one embodiment, the communications interface of a service provider system 103 receives a confirmation that a stored-value account 104 branded for a first merchant 101 contains a value. The communications interface of the service provider also receives a request to enable a payment using the value from the first-merchant-branded stored-value account at a second merchant 102. The communications interface of the service provider system 103 then transmits a request to the entity responsible for maintaining the stored-value account 104 for an amount from the first-merchant-branded stored-value account 104 and receives the requested amount from the first-merchant-branded stored-value account. The communications interface and a processor of the service provider system 103 place the amount in a virtual account 105. And the communications interface of the service provider system initiates a display showing the amount in the virtual account as a branded stored-value account for the second merchant.
In one embodiment, the virtual account is an account held by the second merchant. Alternatively, the virtual account is held by the first merchant or the service provider.
In another embodiment, the communications interface of the service provider system transfers the amount from the virtual account to the second merchant as a payment. After the payment is made, the customer may wish to return the purchased item and reverse the payment. Because the customer received a display showing the amount in the virtual account as branded for the second merchant, the customer will work through the second merchant to reverse the payment. In one example, when the customer requests a reversal of the payment, the second merchant sends a request to the service provider system to reverse the payment. The communications interface of the service provider system receives the request from the second merchant to reverse the payment and reverses the payment.
When a payment is reversed, the merchants or the service provider may wish to restrict how the reversed payment may be used in the future. For example, the second merchant may have a policy that returns may only be exchanged for store credit. In one example, the processor of the service provider system may mark the reversed payment as restricted, that is, the reversed payment may not put funds back into general use. Restrictions may include that the customer's component the reversed balance that is restricted can only be spent at a specific merchant, or must be spent within a certain time (e.g., must be spent within 30 days). Also, reversals may have reversal of fees associated with the initial amount spent.
As discussed above, the value in the stored-value account may be money including standard and alternative currencies like Bitcoin, miles, points, Stars, or other types of rewards. The processor of the service provider system may have to convert the amount from the first-merchant-branded stored-value account from a first value type to a second value type. For example, if the first-merchant-branded stored-value account contains rewards points, but the second merchant only deals in dollars, the service provider system may convert the miles to dollars using exchange criteria and rates determined by the merchants, the service provider, or general exchange rates. The exchange criteria and rates may include, for example, a limitation on the amount from the first-merchant-branded stored-value account that may be used at the second merchant or the frequency at which value form the first-merchant-branded stored-value account may be used at the second merchant.
In another embodiment, the systems and methods may be used with a mobile device of a customer. The mobile device may contain the elements shown in
The communications interface of the mobile device receives a request to enable a payment using the value from the first-merchant-branded stored-value account at a second merchant. This request may be from the customer selecting or inputting the second merchant is an application of the mobile device. Alternatively, the request can be automatically generated through geolocation information for the mobile device or may be initiated by the second merchant. The communications interface of the mobile device transmits a request to the entity responsible for maintaining the stored-value account for an amount from the first-merchant-branded stored-value account. This request may go directly to the entity responsible for maintaining the stored-value account, or it may go to the service provider who then transmits the request to the entity responsible for maintaining the stored-value account. Then the communications interface of the mobile device receives a confirmation that the requested amount from the first-merchant-branded stored-value account has been placed in a virtual account. This confirmation may come directly from the entity responsible for maintaining the stored-value account or it may come through the service provider. After receiving the confirmation, the display of the mobile device displays the amount in the virtual account as a branded stored-value account for the second merchant.
The communications interface of the mobile device may also receive confirmation that the amount from the virtual account was transferred to the second merchant as the payment. Also, if the customer wants to reverse the payment, the communications interface of the mobile device may receive a request to reverse the payment. This request may come from direct customer input to the mobile device, or the request may come from the second merchant directly or via the service provider. After receiving a request to reverse the payment, the communications interface of the mobile device may receive a confirmation of the reversed payment. Reversal may require approval by the second merchant and/or by the customer and/or by the service provider. Reversal may result in creating a restricted-funds balance as described above.
In one embodiment, the mobile device display shows the amount in the first merchant-branded stored-value account with a first skin for the first merchant and shows the amount in the virtual account with a second skin for the second merchant. A skin is a custom graphical appearance achieved by the use of a graphical user interface that can be applied to specific applications. As such a skin can completely change look and feel and navigation interface of an application. The change from the first skin for the first merchant to the second skin for the second merchant helps identify the responsible merchant to the customer.
The figures included herein serve as embodiments of the presented systems and methods. Each individual process or sub-process performed within the embodiments described can be performed by one or more parties, as well as one or more computer systems. For example, in one embodiment, some or all of the communications and data transfers between the customer, service provider system, and merchant are performed via an automated computer-based system, such as an application program interface. As such, the embodiments presented in the figures are not intended to be limiting.
