US20140310166A1 - System and method for loading stored value accounts - Google Patents

Abstract

A system and method are provided which allow users to load stored value accounts through online bill payment. The system and method do not rely on the user loading the stored value account sharing online banking login information or account number/routing information. In an aspect, the method includes a user selecting online banking as a payment option, receiving a bill for the load amount, paying the bill through online banking bill pay, the system receiving notification from the bank of an online banking bill payment and the system notifying the stored value account provider of the payment. The cash settlement is released to a stored value account provider in response to load request.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. Patent Application Ser. No. 13/458,455, filed Apr. 27, 2012, now U.S. Pat. No. 8,645,272 and entitled “SYSTEM AND METHOD FOR LOADING STORED VALUE ACCOUNTS,” which claims the benefit of and priority to U.S. Provisional Patent Application Ser. No. 61/500,881, filed Jun. 24, 2011, and entitled “SYSTEM AND METHOD FOR LOADING STORED VALUE ACCOUNTS.” The entire disclosures of the above applications are hereby incorporated by reference, for all purposes, as if fully set forth herein.
BACKGROUND
• Stored value accounts are gaining prevalence as they can be used to support an increasingly wide variety of new payment transactions as people become more comfortable with their use. Historically, stored value accounts were used for gift cards, reloadable prepaid cards, and for prepaid phone cards. In the case of cards, the funds and/or related data are often physically stored on the cards themselves, or accessible by entering a code number on the card into a telephone, computer or other device.
• The use of these stored value accounts has expanded to include government payments (e.g. benefits, food stamps, tax returns), incentives (both corporate employee incentives and merchant incentives for consumers), and is becoming an engine to drive users to user payments, including remittance. Today, there are several companies developing new payment platforms centered on the concept of virtual wallets; these wallets are also driven by stored value accounts. All of these services require the consumer to easily load funds both offline and online
• There are several ways that consumers may currently load funds into stored value accounts including credit card, checks, ACH (Automated Clearing House) debit, payments at a physical location, and PaypalTM
• In order to complete these transactions, online customers must provide financial information such as credit card and bank account number. Some require sensitive personal information such as social security number, or date of birth, or driver's license.
BRIEF SUMMARY
• The present disclosure relates generally to payment processing. More particularly, the present disclosure relates to payment processing for loading stored value accounts.
• Embodiments of the present disclosure provide improvements for loading stored value accounts and making remittance payments using online banking bill payment without providing sensitive financial information. Further, the embodiments described herein provide a benefit for stored value and remittance providers to receive guaranteed payments.
• In some embodiments of the invention, a gateway subsystem is provided that acts as an intermediary for loading value on a stored value account using a bill payment subsystem associated with a user. For example, an electronic load request can be received at the gateway that includes information specifying the stored value account and/or the user. The gateway can then send a bill to the bill payment subsystem where the user is a subscriber.
• The bill payment subsystem can be included in the load requested or looked up in a database at the gateway. In response to sending the bill, a payment notification can be sent to the gateway from the bill payment subsystem. Funds can then be loaded on the stored value account from an account at the gateway. Funds can also be transferred or remitted from the bill payment subsystem to the gateway. Various other systems and methods are disclosed.
BRIEF DESCRIPTION OF THE DRAWINGS
• The present invention is described in conjunction with the appended figures.
• FIG. 1 illustrates a system for initiating a payment to a stored value account from a bill payment system for a user in a load request according to some embodiments of the invention.
• FIG. 2 is a flowchart of process200 for loading funds to a stored value account from a request from a stored value provider or a user according to some embodiments of the invention.
• FIG. 3 is a block diagram illustrating an exemplary computer system300 that can be used to implement various embodiments of the invention.
• FIG. 4 illustrates a block diagram of a computer system capable of being used in at least some portion of the apparatuses or systems of the present invention, or implementing at least some portion of the methods of the present invention.
• In the appended figures, similar components and/or features may have the same numerical reference label. Further, various components of the same type may be distinguished by following the reference label by a letter that distinguishes among the similar components and/or features. If only the first numerical reference label is used in the specification, the description is applicable to any one of the similar components and/or features having the same first numerical reference label irrespective of the letter suffix.
DETAILED DESCRIPTION OF THE INVENTION
• The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the various embodiments of the invention will provide those skilled in the art with an enabling description for implementing one or more embodiments of the invention. Various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims. Various embodiments may be practiced with or without any given specific detail of any specifically described embodiment.
• Circuits, systems, networks, processes, and other elements in the invention may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
• Also, it is noted that individual embodiments of the invention may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but could have additional steps not discussed or included in a figure. Furthermore, not all operations in any particularly described process may occur in all embodiments. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc.
• The term “machine-readable medium” includes, but is not limited to transitory or non-transitory, portable or fixed storage devices, optical storage devices, wireless channels and various other mediums capable of storing, containing or carrying instruction(s) and/or data. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
• Furthermore, embodiments of the invention may be implemented, at least in part, either manually or automatically. Manual or automatic implementations may be executed, or at least assisted, through the use of machines, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium. A processor(s) may perform the necessary tasks.
• The term “load” is used herein to describe adding funds to an account, such as a stored value account. While funds can be loaded to a stored value account through any number of transaction, in embodiments of the invention funds can be loaded to the stored value account from a gateway subsystem. The funds can be in any currency, such as US Dollars, and can be converted to another currency or format before or after being added.
• The term “stored value account” can relate to either a stored value card or a prepaid debit card. Monetary value associated with the card can be stored on the card (e.g., in magnetic storage) or in a database that associates card identification with monetary value. A stored value account can be associated with an anonymous user or with a named user. A stored value account can be associated with a closed system, a semi-closed system, or an open system.
• Generally, embodiments of the invention provide systems and/or methods that allows a user to load funds from their DDA (Direct Deposit Account) using online banking bill payment to a stored value account without disclosing financial or sensitive information. System and/or methods are also provided that allow users to load stored value accounts through online bill payment. The system and method do not rely on the user loading the stored value account by sharing online banking information or account number/routing.
• The method can include receiving a request from a stored value provider to load a stored value account. A bill can be generated for the load amount. A notification may be received by a cash based payment system indicating that an online banking bill payment has been made associated with the bill amount. As a result of the load request, a gateway system may process the payment—associating the payment with the bill and stored value account consumer—and notify a stored value provider that the payment is made and amount can be credited to the account.
• In a further aspect, the present disclosure provides a method of automatically processing an online banking bill payment to load a stored value account involving a consumer paying to load a stored value account, a stored value account provider, a gateway system, and an online banking system. In an embodiment, the method includes: receiving an authorized cash payment request from a user loading a stored value account; submitting a request for payment to the consumer's bank in response to a determination that the loader is registered for auto payment with respect to the gateway system; and releasing the cash payment to the stored value account provider in response to receiving a load request from the user's bank.
• In a further aspect, the method can include receiving a request directly from a stored value account holder. As a result of the request, the cash based payment system can verify the account holder's stored value account number with the stored value provider prior to authorizing the load and generating a bill.
• In another aspect, the present disclosure provides a method of processing an online banking bill payment to submit a remittance payment from a user or a small or medium enterprise to another user or a small or medium enterprise. The method can include notifying a remittance provider that the payment has been received and the remittance provider can transfer funds to the receiver.
• The system and method of embodiments described herein do not rely on the user sharing online banking login information or account number/routing information with the stored value provider. In an embodiment, the method includes a user selecting online banking as a payment option, receiving a bill for the amount they want to load, adding the gateway system as a payee in their online banking bill payment, making a bill payment for the amount they want to load into their stored value account, the gateway system receiving notification from the bank that a payment has been made, and the system notifying the stored value account provider of the payment. The cash settlement is released to a stored value account provider.
• Accordingly, the present disclosure creates a new way for users to load stored value accounts online with cash available in their DDA account using their bank's online bill payment system without providing sensitive financial information to any party involved in the process. Embodiments of the present disclosure provide a streamlined online purchase experience, which is easy, and also less risky than providing routing and account information for an ACH debit transaction. Embodiments of the present disclosure also include the added security and other advantages of online bill payment for the user loading of the stored value account information.
• FIG. 1 illustratessystem100 for initiating a payment to a stored value account from a bill payment system for a user in a load request according to some embodiments of the invention.System100 can includeuser subsystem110, storedvalue provider subsystem120,gateway subsystem130, and/orbill payment subsystem140. Network160 (e.g., the Internet or another banking or merchant network) may communicatively couple each of the subsystems.
• User subsystem110 may be used by a user to conduct various activities withsystem100.User subsystem110 may be used to accessbill payment subsystem140. For instance, a user may utilizebrowser module111 to access an online interface ofbill payment subsystem140. The online interface of the bill payment subsystem can be presented and/or hosted bywebsite module141. For example, the user may view a web page of the entity operating the bill payment subsystem. Such an entity may be a financial institution such as a bank, a credit union, a credit card company, or a financial services provider such as a money transfer service. Through such access a user may subscribe to billpayment subsystem140. A user may also provide account information to thebill payment subsystem140 for loading a stored value card throughgateway subsystem130.
• A user can also useuser subsystem110 to access a stored value account at storedvalue provider subsystem120 to load funds to the user's account and/or select online banking as the payment method. For instance, a user may utilizebrowser module111 to access an online interface of storedvalue provider subsystem120 as presented bywebsite module121. For example, the user may view a web page of the entity operating the stored value provider subsystem. For example, storedvalue provider subsystem120 can be accessed to submit loading details and/or user information for a stored value account load transaction to thegateway subsystem130 and/or to direct the user's browser to thegateway subsystem130. A stored value account load transaction is the transaction by which funds are added, or requested to be added, to the stored value account by the user. The user can be an individual, or a company such as a small and medium enterprise.
• Bill payment subsystem140 can allow a user to pay bills received atbill payment subsystem140 or bills received independently frombill payment subsystem140. The user may have the option inbill payment subsystem140 to identify certain billers as being authorized to have their bills auto-paid. “Auto-paid” meaning that the user need not confirm that a bill from the authorized biller should be paid once received, but instead that once a bill from the biller is received,bill payment subsystem140 should proceed to pay the bill without further instruction by the user. In some embodiments, the user may specify whether regularly occurring and/or non-regularly occurring bills are authorized for auto-payment. Moreover, the user may then add storedvalue provider subsystem120 orgateway subsystem130, and/or an entity associated with it, as an authorized auto-paid biller. All of this and other pertinent information regarding the user and his authorized auto-paid billers may be stored insubscription module142. The user can provide limits on the frequency and/or amount of funds that can be auto-paid.
• Gateway subsystem130 can provide an intermediary betweenbill payment subsystem140 and storedvalue provider subsystem120. In some configurations gateway subsystem can be hosted by, managed, maintained, or part of eitherbill payment subsystem140 or storedvalue provider subsystem120.
• In some embodiments, the user may accessgateway subsystem130, possibly viabrowser module111. In some embodiments, the user may register withgateway subsystem130 viaregistration module135. In other embodiments, the user may be registered withgateway subsystem130 based on an indication received frombill payment subsystem140 or storedvalue provider subsystem120. In some embodiments, the user may need to confirm withgateway subsystem130 that a notification received frombill payment subsystem140 or storedvalue provider subsystem120 should be interpreted as an instruction to register the user withgateway subsystem130. In any case,gateway subsystem130 may or may not confirm withbill payment subsystem140 or storedvalue provider subsystem120 thatgateway subsystem130, and/or an entity associated with it, is confirmed as a pre-authorized biller by the user (or more specifically, a pre-authorized non-regularly occurring biller).Gateway subsystem130 may possibly do this by conducting test billings for very small amounts (i.e., $0.03, $0.14, etc.) to determine ifgateway subsystem130 is properly confirmed and being auto-paid the same amounts bybill payment subsystem140.Gateway subsystem130 may also refund these amounts back to the user's bill payment account as well.
• Gateway subsystem130 can includeload processing module131 that can receive a load request frombill payment subsystem140, storedvalue provider subsystem120 oruser subsystem110. A load request can include a load amount, an account indicator that indicates the stored value card to be loaded (e.g., stored value account number), the name of the user, email address, a user account number or an order number, and/or an indication that payment may be remitted throughbill payment subsystem140. Theload processing module131 can determine whether the user or stored value account are registered for use withgateway subsystem130. This can be done, for example, by looking up registration information indatabase136.Load processing module131 can also determine if the user has authorized loading of a stored value account throughgateway subsystem130.
• Gateway subsystem130 can includerisk management module132 that can determine a risk score for a given transaction. A risk score can be determined based on a payment amount, payment frequency, payment date, aggregated payment amounts over a period of time, etc. In this way, limits can be placed by the user (e.g., through browser module111) on the amount and/or frequency of funds loaded to the stored value account. In some embodiments, risk management will only perform an analysis on auto-pay transactions. The risk score, for example, can include validating that order and user details are consistent with prior loading or bank details and accountholder details. The risk score, for example, can be based on configurable rules and that the order's risk score does not exceed a configurable threshold. If the risk score is above a certain threshold, for example, the risk management module can stop the payment transaction. In some embodiments the
• Gateway subsystem130 can includepayment request module133 that can request payment from thebill payment subsystem140 according to some embodiments of the invention. Once the payment identified in a load request is approved based on therisk management module132,payment request module133 can request payment from bill payment subsystem. In some embodiments that allow for auto-pay,payment request module133 can facilitate auto-payment by requesting payments from bill payment subsystem as indicated by the user for auto-payment with or without first receiving a load request frombill payment subsystem140. Payment frombill payment subsystem140 may occur via fund transfer, ACH transfer, check, etc. Settlement may occur at some future time.
• When load request is sent from bill payment104, sensitive account information atbill payment subsystem140 may not be comprised. Thus, in some embodiments, when the load request is received frombill payment subsystem140, a request for payment may not be sent to the bill payment subsystem. The payment may already be in process awaiting remittance.
• Gateway subsystem130 can includefund transfer module134 that can process payment from thebill payment subsystem140 and/or load funds at the storedvalue provider subsystem120.Fund transfer module134, for example, can receive money transfer or remittance information frombill payment subsystem140 and/or provide the proper documentation regarding the money transfer in the proper account ledger in database208. Moreover,fund transfer module134 can load funds to the stored value account at storedvalue provider subsystem120 and/or update the account information in database208 regarding the payment transfer. In some embodiments, the funds can be pulled from the gateway subsystem's general account and loaded on the stored value account at the storedvalue provider subsystem120. Payment can be remitted frombill payment subsystem140 before or after this transfer.
• Storedvalue provider subsystem120 can includewebsite module121 and/oraccount management module122. A user may utilizebrowser module111 to access an online interface of storedvalue provider subsystem120. The online interface of storedvalue provider subsystem120 can be presented and/or hosted bywebsite module121. The user can access account information and/or change account details throughwebsite module121 by usingaccount management module122.
• In some embodiments,bill payment subsystem140 may or may not send an indication to storedvalue provider subsystem120 and/orgateway subsystem130 thatbill payment subsystem140 and/or an entity associated with it is preauthorized for auto-payment of bills received from it. In some embodiments, limits on the size (i.e., monetary amount) and/or type of purchases (i.e., types of goods and/or services) which are pre-authorized may exist, either at the behest of the user, or based onbill payment subsystem140 operating protocols. In some embodiments, the bill payment subsystem may run a risk analysis, as known in the art, on the user to determine auto-payment limits. In any case, the established limits may or may not be communicated to storedvalue provider subsystem120.
• In some embodiments, once a load transaction is in process, the user may inform storedvalue provider subsystem120 thatgateway subsystem130 will be used to load a stored value account. In some embodiments, this may involveuser subsystem110 providing an account number, authentication value, or other information identifying user's account atgateway subsystem130 to storedvalue provider subsystem120. In turn, storedvalue provider subsystem120 may then communicate load transaction information withgateway subsystem130 to effectuate payment fromgateway subsystem130 to storedvalue provider subsystem120. The load transaction information may include account information associated withgateway subsystem130, a payment request authorized by the user for a specific amount, as well as an identifier associated with the stored value provider (possibly a financial account number associated with the stored value provider). As used herein, when an account is said to be “associated with” a party, it is understood that the account is controlled by, and the balance the property of, the party.
• In other embodiments, storedvalue provider subsystem120 will not receive any information regarding the user's arrangement withgateway subsystem130. Instead,user subsystem110 may informgateway subsystem130 of the load transaction information described above. In these embodiments, storedvalue provider subsystem120 may be informed that a payment is to be expected fromgateway subsystem130. In yet other embodiments, bothuser subsystem110 and storedvalue provider subsystem120 may informgateway subsystem130 of the load transaction information, andgateway subsystem130 may verify that the information provided by each subsystem matches before proceeding with the load transaction.Gateway subsystem130 may store the load transaction information atload processing module131.
• In some embodiments, a user can select online banking as a payment option with the stored value provider. The user can receive a bill for the load amount and pay the bill through online banking bill pay. Then the bill payment system can send an indication to the stored value provider that an online banking bill payment has occurred. A cash settlement can then be released to a stored value account provider in response to load request. Thus, in some embodiments, gateway103 can be by passed by allowing user to request bill payment directly frombill payment subsystem140 to the storedvalue provider subsystem120.
• FIG. 2 is a flowchart of process200 for loading funds to a stored value account from a request from a stored value provider or a user according to some embodiments of the invention. Process200 can be implemented, for example, atgateway subsystem130 shown inFIG. 1. Process200 can start atblock205. At block210 a load request is received from a user or a stored value provider. The load request can be received, for example, atgateway subsystem130. The load request can include a load amount and/or stored valued account information. At block215 a risk score can be determined. The risk score can be used to determine the risk that the load request is fraudulent or not. Various factors discussed elsewhere can be used to determine the risk score. If the risk score is beyond a certain threshold as noted atblock220, then process200 can end atblock240. In some embodiments, a notification can be sent to the user and/or the stored value provider when a load transaction is deemed too risky.
• If the load transaction is not deemed too risky, then process200 proceeds to block225 where a notification is sent to the bill payment subsystem requesting payment. In some embodiments, the notification can be sent to the user who then forwards it to or signs up the gateway for payment throughbill payment subsystem140. The notification can be created, for example, by looking up bill payment information indatabase136 that is associated with the account number provided in the load request. Once the bill payment information is determined, the payment request can be sent to the bill payment subsystem (or the user). The payment request can include at least the payment amount and a bill payment account number that is to be used for the payment. If the bill payment subsystem is previously set up for auto-payment, then process200 proceeds to block230. Funds are loaded onto the stored value account by transferring funds to the stored value provider with an indication that indicates the stored value account where the funds are to be loaded. Any fund transfer process can be used. Payment from the bill payment subsystem can be remitted atblock235. This remittance can occur at some later point in time. Process200 can end atblock240.
• In some embodiments, gateway103 can deduct a processing for processing the transaction. For example, gateway103 may transfer a percentage of the funds required.
• FIG. 3 is a flowchart of process300 for loading funds to a stored value account according to some embodiments of the invention. Process300 can be implemented, for example, atgateway subsystem130 shown inFIG. 1. Process300 can start atblock305. Atblock310, it can be determined that a stored value account should be loaded with funds.
• This can occur based on a recurring auto payment indication. That is, gateway103 can determine that stored value account should be loaded with funds because an authenticated user has indicated that the stored value account should be loaded when certain events occur, such as at certain periods of time, when a certain notification has been received from a third party, when a certain threshold amount is reached in the stored value account, etc. In some cases, this determination can be reached when a bill payment subsystem indicates that a bill payment is being sent or has been sent.
• At block315 a notification can be sent to the bill payment subsystem requesting payment. Block315 can be avoided whenblock310 is initiated in response to a bill payment sent by bill payment subsystem. The notification can sent, for example, after looking up bill payment information in a database. Once the bill payment information is determined, the payment request can be sent to the bill payment subsystem. The payment request can include at least the payment amount and a bill payment account number that is to be used for the payment. If the bill payment subsystem is previously set up for auto-payment, then process300 proceeds to block320. Funds are loaded onto the stored value account by transferring funds to the stored value provider with an indication that indicated the stored value account where the funds are to be loaded. Any fund transfer process can be used. Payment from the bill payment subsystem can be remitted atblock325. This remittance can occur at some later point in time. Process300 can end atblock330.
• FIG. 3 is a block diagram illustrating acomputer system400 that can be used to implement various embodiments of the invention. For example,computer system400 can be used, in whole, in part, in conjunction with another computer system, or with various modifications, to provide the functions of the stored value provider subsystem, user subsystem, bill payment subsystem, gateway subsystem, and/or other components of the invention such as those discussed above.Computer system400 can execute all or part of process200 and/or process300. For example, various functions of the gateway subsystem may be controlled bycomputer system400, including, for example, receiving load request information, determining registration status of a user, sending load requests, receiving load requests, causing payments to be made, loading funds, hosting a website, etc.
• While a number of processes have been described a bill payment to a stored value account can occur in a number of ways initiated by different subsystems. Each of these can implement various other details described herein. In some embodiments a user can initiate the process in two ways. First, the user can request a loading of the stored value account frombill payment subsystem140. Bill payment subsystem can then remit payment togateway subsystem130, which then loads the stored value account at storedvalue provider subsystem120, or directly to storedvalue provider subsystem120. Second, as shown by process200, the user can also send a request togateway subsystem130 where upongateway subsystem130 can send a load bill to billpayment subsystem140 that includes account information and payment amounts. After whichbill payment subsystem140 can remit payment togateway subsystem130.
• In other embodiments, storedvalue provider subsystem120 can initiate loading of the stored value account in two ways. First, as shown by process200, storedvalue provider subsystem120 can send a request togateway subsystem130 where upongateway subsystem130 can send a load bill to billpayment subsystem140 that includes account information and payment amounts. After whichbill payment subsystem140 can remit payment togateway subsystem130. Second, storedvalue provider subsystem120 can send a load payment directly tobill payment subsystem140.Bill payment subsystem140 can remit payment directly to storedvalue provider subsystem120.
• In other embodiments,gateway subsystem130 can initiate loading of the stored value account in two ways. First, as shown in process300,gateway subsystem130 can send a load bill to billpayment subsystem140. Second,gateway subsystem130 can send a load bill to the user who then forwards it to the bill payment subsystem or pays the bill using the bill payment subsystem.
• In yet other embodiments, bill payment subsystem can initiate loading of the stored value account in two ways. First,bill payment subsystem140 can load stored value account directly with storedvalue provider subsystem120. Second,bill payment subsystem140 can initiate payment throughgateway subsystem130.
• Computer system400 includes hardware elements that may be electrically coupled via abus490. The hardware elements may include one or morecentral processing units410, one or more input devices420 (e.g., a mouse, a keyboard, etc.), and one or more output devices430 (e.g., a display device, a printer, etc.).Computer system400 may also include one ormore storage device440. For example, storage device(s)440 may be disk drives, optical storage devices, solid-state storage device such as a random access memory (“RAM”) and/or a read-only memory (“ROM”), which can be programmable, flash-updateable and/or the like.
• Computer system400 may additionally include a computer-readablestorage media reader450, a communications system460 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, BluetoothTM device, cellular communication device, etc.), and workingmemory480, which may include RAM and ROM devices as described above. In some embodiments,computer system400 may also include aprocessing acceleration unit470, which can include a digital signal processor, a special-purpose processor and/or the like.
• Computer-readablestorage media reader450 can further be connected to a computer-readable storage medium, together (and, optionally, in combination with storage device(s)440) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information.Communications system460 may permit data to be exchanged with a network, system, computer and/or other component described above.
• Computer system400 may also comprise software elements, shown as being currently located within a workingmemory480, including anoperating system484 and/orother code488. It should be appreciated that alternate embodiments ofcomputer system400 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Furthermore, connection to other computing devices such as network input/output and data acquisition devices may also occur.
• Software ofcomputer system400 may includecode488 for implementing any or all of the function of the various elements of the architecture as described herein. For example, software, stored on and/or executed by a system such ascomputer system400, can provide the functions of the stored value provider subsystem, user subsystem, bill payment subsystem, gateway subsystem, and/or other components of the invention such as those discussed above. Methods implementable by software on some of these components have been discussed above in more detail.
• The invention has now been described in detail for the purposes of clarity and understanding. However, it will be appreciated that certain changes and modifications may be practiced within the scope of the appended claims.

Claims (1)

What is claimed is:

1. A gateway system for loading funds to a stored value account provider from a bill payment system associated with a user, the gateway system comprising:

a processor; and

a non-transitory storage medium having instructions thereon, the instructions executable by the processor for:

receiving a load request, wherein the load request includes load request information, wherein the load request information includes a stored value account identifier associated with a stored value account and an amount of funds to load to the stored value account;

sending a bill to a bill payment system of which a user is a subscriber, wherein the bill includes the amount of funds to load and an indication of the stored value account identifier;

receiving a payment notification from the bill payment system that indicates that payment has been made;

causing a first payment to be made from a first account associated with the gateway system to a second account associated with the stored value account provider;

wherein the identifier associated with the stored value account comprises an account number of the second account; and

wherein causing a first payment to be made from a first account associated with the gateway system to a second account associated with the stored value account provider occurs in response, at least in part, to receiving a second payment from a third account associated with the user to the first account associated with the gateway system.

Images