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

System and method for loading stored value accounts Download PDF

Info

Publication number
US20140310166A1
US20140310166A1 US14/171,466 US201414171466A US2014310166A1 US 20140310166 A1 US20140310166 A1 US 20140310166A1 US 201414171466 A US201414171466 A US 201414171466A US 2014310166 A1 US2014310166 A1 US 2014310166A1
Authority
US
United States
Prior art keywords
stored value
subsystem
payment
account
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/171,466
Inventor
John A. MacMillan
Marwan Forzley
Samer FORZLEY
Sheila H. JAMES
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Western Union Financial Services Inc
Original Assignee
Western Union Financial Services Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Western Union Financial Services Inc filed Critical Western Union Financial Services Inc
Priority to US14/171,466 priority Critical patent/US20140310166A1/en
Publication of US20140310166A1 publication Critical patent/US20140310166A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/349Rechargeable cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/28Pre-payment schemes, e.g. "pay before"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules

Definitions

  • 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 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.
  • a gateway subsystem 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.
  • 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.
  • 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 process 200 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 system 300 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.
  • 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.
  • 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.
  • a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method can include receiving a request directly from a stored value account holder.
  • 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.
  • 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 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.
  • 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 illustrates system 100 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.
  • System 100 can include user subsystem 110 , stored value provider subsystem 120 , gateway subsystem 130 , and/or bill payment subsystem 140 .
  • Network 160 e.g., the Internet or another banking or merchant network
  • User subsystem 110 may be used by a user to conduct various activities with system 100 .
  • User subsystem 110 may be used to access bill payment subsystem 140 .
  • a user may utilize browser module 111 to access an online interface of bill payment subsystem 140 .
  • the online interface of the bill payment subsystem can be presented and/or hosted by website module 141 .
  • 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 bill payment subsystem 140 .
  • a user may also provide account information to the bill payment subsystem 140 for loading a stored value card through gateway subsystem 130 .
  • a user can also use user subsystem 110 to access a stored value account at stored value provider subsystem 120 to load funds to the user's account and/or select online banking as the payment method.
  • a user may utilize browser module 111 to access an online interface of stored value provider subsystem 120 as presented by website module 121 .
  • the user may view a web page of the entity operating the stored value provider subsystem.
  • stored value provider subsystem 120 can be accessed to submit loading details and/or user information for a stored value account load transaction to the gateway subsystem 130 and/or to direct the user's browser to the gateway subsystem 130 .
  • 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 subsystem 140 can allow a user to pay bills received at bill payment subsystem 140 or bills received independently from bill payment subsystem 140 .
  • the user may have the option in bill payment subsystem 140 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 subsystem 140 should proceed to pay the bill without further instruction by the user.
  • the user may specify whether regularly occurring and/or non-regularly occurring bills are authorized for auto-payment.
  • the user may then add stored value provider subsystem 120 or gateway subsystem 130 , 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 in subscription module 142 . The user can provide limits on the frequency and/or amount of funds that can be auto-paid.
  • Gateway subsystem 130 can provide an intermediary between bill payment subsystem 140 and stored value provider subsystem 120 .
  • gateway subsystem can be hosted by, managed, maintained, or part of either bill payment subsystem 140 or stored value provider subsystem 120 .
  • the user may access gateway subsystem 130 , possibly via browser module 111 .
  • the user may register with gateway subsystem 130 via registration module 135 .
  • the user may be registered with gateway subsystem 130 based on an indication received from bill payment subsystem 140 or stored value provider subsystem 120 .
  • the user may need to confirm with gateway subsystem 130 that a notification received from bill payment subsystem 140 or stored value provider subsystem 120 should be interpreted as an instruction to register the user with gateway subsystem 130 .
  • gateway subsystem 130 may or may not confirm with bill payment subsystem 140 or stored value provider subsystem 120 that gateway subsystem 130 , 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 subsystem 130 may possibly do this by conducting test billings for very small amounts (i.e., $0.03, $0.14, etc.) to determine if gateway subsystem 130 is properly confirmed and being auto-paid the same amounts by bill payment subsystem 140 . Gateway subsystem 130 may also refund these amounts back to the user's bill payment account as well.
  • very small amounts i.e., $0.03, $0.14, etc.
  • Gateway subsystem 130 can include load processing module 131 that can receive a load request from bill payment subsystem 140 , stored value provider subsystem 120 or user subsystem 110 .
  • 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 through bill payment subsystem 140 .
  • the load processing module 131 can determine whether the user or stored value account are registered for use with gateway subsystem 130 . This can be done, for example, by looking up registration information in database 136 . Load processing module 131 can also determine if the user has authorized loading of a stored value account through gateway subsystem 130 .
  • Gateway subsystem 130 can include risk management module 132 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 module 111 ) on the amount and/or frequency of funds loaded to the stored value account.
  • 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 subsystem 130 can include payment request module 133 that can request payment from the bill payment subsystem 140 according to some embodiments of the invention. Once the payment identified in a load request is approved based on the risk management module 132 , payment request module 133 can request payment from bill payment subsystem. In some embodiments that allow for auto-pay, payment request module 133 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 from bill payment subsystem 140 . Payment from bill payment subsystem 140 may occur via fund transfer, ACH transfer, check, etc. Settlement may occur at some future time.
  • load request is sent from bill payment 104
  • sensitive account information at bill payment subsystem 140 may not be comprised.
  • a request for payment may not be sent to the bill payment subsystem. The payment may already be in process awaiting remittance.
  • Gateway subsystem 130 can include fund transfer module 134 that can process payment from the bill payment subsystem 140 and/or load funds at the stored value provider subsystem 120 .
  • Fund transfer module 134 can receive money transfer or remittance information from bill payment subsystem 140 and/or provide the proper documentation regarding the money transfer in the proper account ledger in database 208 .
  • fund transfer module 134 can load funds to the stored value account at stored value provider subsystem 120 and/or update the account information in database 208 regarding the payment transfer.
  • the funds can be pulled from the gateway subsystem's general account and loaded on the stored value account at the stored value provider subsystem 120 . Payment can be remitted from bill payment subsystem 140 before or after this transfer.
  • Stored value provider subsystem 120 can include website module 121 and/or account management module 122 .
  • a user may utilize browser module 111 to access an online interface of stored value provider subsystem 120 .
  • the online interface of stored value provider subsystem 120 can be presented and/or hosted by website module 121 .
  • the user can access account information and/or change account details through website module 121 by using account management module 122 .
  • bill payment subsystem 140 may or may not send an indication to stored value provider subsystem 120 and/or gateway subsystem 130 that bill payment subsystem 140 and/or an entity associated with it is preauthorized for auto-payment of bills received from it.
  • 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 on bill payment subsystem 140 operating protocols.
  • 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 stored value provider subsystem 120 .
  • the user may inform stored value provider subsystem 120 that gateway subsystem 130 will be used to load a stored value account. In some embodiments, this may involve user subsystem 110 providing an account number, authentication value, or other information identifying user's account at gateway subsystem 130 to stored value provider subsystem 120 .
  • stored value provider subsystem 120 may then communicate load transaction information with gateway subsystem 130 to effectuate payment from gateway subsystem 130 to stored value provider subsystem 120 .
  • the load transaction information may include account information associated with gateway subsystem 130 , 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).
  • 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.
  • stored value provider subsystem 120 will not receive any information regarding the user's arrangement with gateway subsystem 130 . Instead, user subsystem 110 may inform gateway subsystem 130 of the load transaction information described above. In these embodiments, stored value provider subsystem 120 may be informed that a payment is to be expected from gateway subsystem 130 . In yet other embodiments, both user subsystem 110 and stored value provider subsystem 120 may inform gateway subsystem 130 of the load transaction information, and gateway subsystem 130 may verify that the information provided by each subsystem matches before proceeding with the load transaction. Gateway subsystem 130 may store the load transaction information at load processing module 131 .
  • 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.
  • 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.
  • gateway 103 can be by passed by allowing user to request bill payment directly from bill payment subsystem 140 to the stored value provider subsystem 120 .
  • FIG. 2 is a flowchart of process 200 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.
  • Process 200 can be implemented, for example, at gateway subsystem 130 shown in FIG. 1 .
  • Process 200 can start at block 205 .
  • a load request is received from a user or a stored value provider.
  • the load request can be received, for example, at gateway subsystem 130 .
  • the load request can include a load amount and/or stored valued account information.
  • 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 at block 220 , then process 200 can end at block 240 .
  • a notification can be sent to the user and/or the stored value provider when a load transaction is deemed too risky.
  • process 200 proceeds to block 225 where a notification is sent to the bill payment subsystem requesting payment.
  • the notification can be sent to the user who then forwards it to or signs up the gateway for payment through bill payment subsystem 140 .
  • the notification can be created, for example, by looking up bill payment information in database 136 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 process 200 proceeds to block 230 .
  • 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 at block 235 . This remittance can occur at some later point in time. Process 200 can end at block 240 .
  • gateway 103 can deduct a processing for processing the transaction. For example, gateway 103 may transfer a percentage of the funds required.
  • FIG. 3 is a flowchart of process 300 for loading funds to a stored value account according to some embodiments of the invention.
  • Process 300 can be implemented, for example, at gateway subsystem 130 shown in FIG. 1 .
  • Process 300 can start at block 305 .
  • it can be determined that a stored value account should be loaded with funds.
  • gateway 103 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.
  • a notification can be sent to the bill payment subsystem requesting payment.
  • Block 315 can be avoided when block 310 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.
  • 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 process 300 proceeds to block 320 . 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 at block 325 . This remittance can occur at some later point in time. Process 300 can end at block 330 .
  • FIG. 3 is a block diagram illustrating a computer system 400 that can be used to implement various embodiments of the invention.
  • computer system 400 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 system 400 can execute all or part of process 200 and/or process 300 .
  • various functions of the gateway subsystem may be controlled by computer system 400 , 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.
  • 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.
  • a user can initiate the process in two ways. First, the user can request a loading of the stored value account from bill payment subsystem 140 . Bill payment subsystem can then remit payment to gateway subsystem 130 , which then loads the stored value account at stored value provider subsystem 120 , or directly to stored value provider subsystem 120 . Second, as shown by process 200 , the user can also send a request to gateway subsystem 130 where upon gateway subsystem 130 can send a load bill to bill payment subsystem 140 that includes account information and payment amounts. After which bill payment subsystem 140 can remit payment to gateway subsystem 130 .
  • stored value provider subsystem 120 can initiate loading of the stored value account in two ways. First, as shown by process 200 , stored value provider subsystem 120 can send a request to gateway subsystem 130 where upon gateway subsystem 130 can send a load bill to bill payment subsystem 140 that includes account information and payment amounts. After which bill payment subsystem 140 can remit payment to gateway subsystem 130 . Second, stored value provider subsystem 120 can send a load payment directly to bill payment subsystem 140 . Bill payment subsystem 140 can remit payment directly to stored value provider subsystem 120 .
  • gateway subsystem 130 can initiate loading of the stored value account in two ways. First, as shown in process 300 , gateway subsystem 130 can send a load bill to bill payment subsystem 140 . Second, gateway subsystem 130 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.
  • bill payment subsystem can initiate loading of the stored value account in two ways. First, bill payment subsystem 140 can load stored value account directly with stored value provider subsystem 120 . Second, bill payment subsystem 140 can initiate payment through gateway subsystem 130 .
  • Computer system 400 includes hardware elements that may be electrically coupled via a bus 490 .
  • the hardware elements may include one or more central processing units 410 , one or more input devices 420 (e.g., a mouse, a keyboard, etc.), and one or more output devices 430 (e.g., a display device, a printer, etc.).
  • Computer system 400 may also include one or more storage device 440 .
  • 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.
  • RAM random access memory
  • ROM read-only memory
  • Computer system 400 may additionally include a computer-readable storage media reader 450 , a communications system 460 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, BluetoothTM device, cellular communication device, etc.), and working memory 480 , which may include RAM and ROM devices as described above.
  • computer system 400 may also include a processing acceleration unit 470 , which can include a digital signal processor, a special-purpose processor and/or the like.
  • Computer-readable storage media reader 450 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 system 460 may permit data to be exchanged with a network, system, computer and/or other component described above.
  • Computer system 400 may also comprise software elements, shown as being currently located within a working memory 480 , including an operating system 484 and/or other code 488 . It should be appreciated that alternate embodiments of computer system 400 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 of computer system 400 may include code 488 for implementing any or all of the function of the various elements of the architecture as described herein.
  • software stored on and/or executed by a system such as computer system 400 , 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.

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 process 200 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 system 300 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 illustrates system 100 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. System 100 can include user subsystem 110, stored value provider subsystem 120, gateway subsystem 130, and/or bill payment subsystem 140. Network 160 (e.g., the Internet or another banking or merchant network) may communicatively couple each of the subsystems.
  • User subsystem 110 may be used by a user to conduct various activities with system 100. User subsystem 110 may be used to access bill payment subsystem 140. For instance, a user may utilize browser module 111 to access an online interface of bill payment subsystem 140. The online interface of the bill payment subsystem can be presented and/or hosted by website module 141. 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 bill payment subsystem 140. A user may also provide account information to the bill payment subsystem 140 for loading a stored value card through gateway subsystem 130.
  • A user can also use user subsystem 110 to access a stored value account at stored value provider subsystem 120 to load funds to the user's account and/or select online banking as the payment method. For instance, a user may utilize browser module 111 to access an online interface of stored value provider subsystem 120 as presented by website module 121. For example, the user may view a web page of the entity operating the stored value provider subsystem. For example, stored value provider subsystem 120 can be accessed to submit loading details and/or user information for a stored value account load transaction to the gateway subsystem 130 and/or to direct the user's browser to the gateway subsystem 130. 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 subsystem 140 can allow a user to pay bills received at bill payment subsystem 140 or bills received independently from bill payment subsystem 140. The user may have the option in bill payment subsystem 140 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 subsystem 140 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 stored value provider subsystem 120 or gateway subsystem 130, 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 in subscription module 142. The user can provide limits on the frequency and/or amount of funds that can be auto-paid.
  • Gateway subsystem 130 can provide an intermediary between bill payment subsystem 140 and stored value provider subsystem 120. In some configurations gateway subsystem can be hosted by, managed, maintained, or part of either bill payment subsystem 140 or stored value provider subsystem 120.
  • In some embodiments, the user may access gateway subsystem 130, possibly via browser module 111. In some embodiments, the user may register with gateway subsystem 130 via registration module 135. In other embodiments, the user may be registered with gateway subsystem 130 based on an indication received from bill payment subsystem 140 or stored value provider subsystem 120. In some embodiments, the user may need to confirm with gateway subsystem 130 that a notification received from bill payment subsystem 140 or stored value provider subsystem 120 should be interpreted as an instruction to register the user with gateway subsystem 130. In any case, gateway subsystem 130 may or may not confirm with bill payment subsystem 140 or stored value provider subsystem 120 that gateway subsystem 130, 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 subsystem 130 may possibly do this by conducting test billings for very small amounts (i.e., $0.03, $0.14, etc.) to determine if gateway subsystem 130 is properly confirmed and being auto-paid the same amounts by bill payment subsystem 140. Gateway subsystem 130 may also refund these amounts back to the user's bill payment account as well.
  • Gateway subsystem 130 can include load processing module 131 that can receive a load request from bill payment subsystem 140, stored value provider subsystem 120 or user subsystem 110. 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 through bill payment subsystem 140. The load processing module 131 can determine whether the user or stored value account are registered for use with gateway subsystem 130. This can be done, for example, by looking up registration information in database 136. Load processing module 131 can also determine if the user has authorized loading of a stored value account through gateway subsystem 130.
  • Gateway subsystem 130 can include risk management module 132 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 module 111) 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 subsystem 130 can include payment request module 133 that can request payment from the bill payment subsystem 140 according to some embodiments of the invention. Once the payment identified in a load request is approved based on the risk management module 132, payment request module 133 can request payment from bill payment subsystem. In some embodiments that allow for auto-pay, payment request module 133 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 from bill payment subsystem 140. Payment from bill payment subsystem 140 may occur via fund transfer, ACH transfer, check, etc. Settlement may occur at some future time.
  • When load request is sent from bill payment 104, sensitive account information at bill payment subsystem 140 may not be comprised. Thus, in some embodiments, when the load request is received from bill payment subsystem 140, a request for payment may not be sent to the bill payment subsystem. The payment may already be in process awaiting remittance.
  • Gateway subsystem 130 can include fund transfer module 134 that can process payment from the bill payment subsystem 140 and/or load funds at the stored value provider subsystem 120. Fund transfer module 134, for example, can receive money transfer or remittance information from bill payment subsystem 140 and/or provide the proper documentation regarding the money transfer in the proper account ledger in database 208. Moreover, fund transfer module 134 can load funds to the stored value account at stored value provider subsystem 120 and/or update the account information in database 208 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 stored value provider subsystem 120. Payment can be remitted from bill payment subsystem 140 before or after this transfer.
  • Stored value provider subsystem 120 can include website module 121 and/or account management module 122. A user may utilize browser module 111 to access an online interface of stored value provider subsystem 120. The online interface of stored value provider subsystem 120 can be presented and/or hosted by website module 121. The user can access account information and/or change account details through website module 121 by using account management module 122.
  • In some embodiments, bill payment subsystem 140 may or may not send an indication to stored value provider subsystem 120 and/or gateway subsystem 130 that bill payment subsystem 140 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 on bill payment subsystem 140 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 stored value provider subsystem 120.
  • In some embodiments, once a load transaction is in process, the user may inform stored value provider subsystem 120 that gateway subsystem 130 will be used to load a stored value account. In some embodiments, this may involve user subsystem 110 providing an account number, authentication value, or other information identifying user's account at gateway subsystem 130 to stored value provider subsystem 120. In turn, stored value provider subsystem 120 may then communicate load transaction information with gateway subsystem 130 to effectuate payment from gateway subsystem 130 to stored value provider subsystem 120. The load transaction information may include account information associated with gateway subsystem 130, 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, stored value provider subsystem 120 will not receive any information regarding the user's arrangement with gateway subsystem 130. Instead, user subsystem 110 may inform gateway subsystem 130 of the load transaction information described above. In these embodiments, stored value provider subsystem 120 may be informed that a payment is to be expected from gateway subsystem 130. In yet other embodiments, both user subsystem 110 and stored value provider subsystem 120 may inform gateway subsystem 130 of the load transaction information, and gateway subsystem 130 may verify that the information provided by each subsystem matches before proceeding with the load transaction. Gateway subsystem 130 may store the load transaction information at load processing module 131.
  • 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, gateway 103 can be by passed by allowing user to request bill payment directly from bill payment subsystem 140 to the stored value provider subsystem 120.
  • FIG. 2 is a flowchart of process 200 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. Process 200 can be implemented, for example, at gateway subsystem 130 shown in FIG. 1. Process 200 can start at block 205. At block 210 a load request is received from a user or a stored value provider. The load request can be received, for example, at gateway subsystem 130. The load request can include a load amount and/or stored valued account information. At block 215 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 at block 220, then process 200 can end at block 240. 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 process 200 proceeds to block 225 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 through bill payment subsystem 140. The notification can be created, for example, by looking up bill payment information in database 136 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 process 200 proceeds to block 230. 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 at block 235. This remittance can occur at some later point in time. Process 200 can end at block 240.
  • In some embodiments, gateway 103 can deduct a processing for processing the transaction. For example, gateway 103 may transfer a percentage of the funds required.
  • FIG. 3 is a flowchart of process 300 for loading funds to a stored value account according to some embodiments of the invention. Process 300 can be implemented, for example, at gateway subsystem 130 shown in FIG. 1. Process 300 can start at block 305. At block 310, 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, gateway 103 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 block 315 a notification can be sent to the bill payment subsystem requesting payment. Block 315 can be avoided when block 310 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 process 300 proceeds to block 320. 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 at block 325. This remittance can occur at some later point in time. Process 300 can end at block 330.
  • FIG. 3 is a block diagram illustrating a computer system 400 that can be used to implement various embodiments of the invention. For example, computer system 400 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 system 400 can execute all or part of process 200 and/or process 300. For example, various functions of the gateway subsystem may be controlled by computer system 400, 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 from bill payment subsystem 140. Bill payment subsystem can then remit payment to gateway subsystem 130, which then loads the stored value account at stored value provider subsystem 120, or directly to stored value provider subsystem 120. Second, as shown by process 200, the user can also send a request to gateway subsystem 130 where upon gateway subsystem 130 can send a load bill to bill payment subsystem 140 that includes account information and payment amounts. After which bill payment subsystem 140 can remit payment to gateway subsystem 130.
  • In other embodiments, stored value provider subsystem 120 can initiate loading of the stored value account in two ways. First, as shown by process 200, stored value provider subsystem 120 can send a request to gateway subsystem 130 where upon gateway subsystem 130 can send a load bill to bill payment subsystem 140 that includes account information and payment amounts. After which bill payment subsystem 140 can remit payment to gateway subsystem 130. Second, stored value provider subsystem 120 can send a load payment directly to bill payment subsystem 140. Bill payment subsystem 140 can remit payment directly to stored value provider subsystem 120.
  • In other embodiments, gateway subsystem 130 can initiate loading of the stored value account in two ways. First, as shown in process 300, gateway subsystem 130 can send a load bill to bill payment subsystem 140. Second, gateway subsystem 130 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 subsystem 140 can load stored value account directly with stored value provider subsystem 120. Second, bill payment subsystem 140 can initiate payment through gateway subsystem 130.
  • Computer system 400 includes hardware elements that may be electrically coupled via a bus 490. The hardware elements may include one or more central processing units 410, one or more input devices 420 (e.g., a mouse, a keyboard, etc.), and one or more output devices 430 (e.g., a display device, a printer, etc.). Computer system 400 may also include one or more storage device 440. 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 system 400 may additionally include a computer-readable storage media reader 450, a communications system 460 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, BluetoothTM device, cellular communication device, etc.), and working memory 480, which may include RAM and ROM devices as described above. In some embodiments, computer system 400 may also include a processing acceleration unit 470, which can include a digital signal processor, a special-purpose processor and/or the like.
  • Computer-readable storage media reader 450 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 system 460 may permit data to be exchanged with a network, system, computer and/or other component described above.
  • Computer system 400 may also comprise software elements, shown as being currently located within a working memory 480, including an operating system 484 and/or other code 488. It should be appreciated that alternate embodiments of computer system 400 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 of computer system 400 may include code 488 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 as computer system 400, 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.
US14/171,466 2011-06-24 2014-02-03 System and method for loading stored value accounts Abandoned US20140310166A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/171,466 US20140310166A1 (en) 2011-06-24 2014-02-03 System and method for loading stored value accounts

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201161500881P 2011-06-24 2011-06-24
US13/458,455 US8645272B2 (en) 2011-06-24 2012-04-27 System and method for loading stored value accounts
US14/171,466 US20140310166A1 (en) 2011-06-24 2014-02-03 System and method for loading stored value accounts

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13/458,455 Continuation US8645272B2 (en) 2011-06-24 2012-04-27 System and method for loading stored value accounts

Publications (1)

Publication Number Publication Date
US20140310166A1 true US20140310166A1 (en) 2014-10-16

Family

ID=48224395

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/458,455 Expired - Fee Related US8645272B2 (en) 2011-06-24 2012-04-27 System and method for loading stored value accounts
US14/171,466 Abandoned US20140310166A1 (en) 2011-06-24 2014-02-03 System and method for loading stored value accounts

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13/458,455 Expired - Fee Related US8645272B2 (en) 2011-06-24 2012-04-27 System and method for loading stored value accounts

Country Status (1)

Country Link
US (2) US8645272B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170116608A1 (en) * 2015-10-22 2017-04-27 Align Commerce Corporation System and method for payment processing using crypto currencies

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9443268B1 (en) 2013-08-16 2016-09-13 Consumerinfo.Com, Inc. Bill payment and reporting
US10325314B1 (en) 2013-11-15 2019-06-18 Consumerinfo.Com, Inc. Payment reporting systems
US10657529B2 (en) * 2017-10-03 2020-05-19 The Toronto-Dominion Bank System and method for clearing point-of-sale terminal pre-authorizations
US11855971B2 (en) * 2018-01-11 2023-12-26 Visa International Service Association Offline authorization of interactions and controlled tasks
US10880313B2 (en) 2018-09-05 2020-12-29 Consumerinfo.Com, Inc. Database platform for realtime updating of user data from third party sources
CN109493028A (en) * 2018-11-20 2019-03-19 北京千丁互联科技有限公司 A kind of method of payment and device
CN112825045B (en) * 2019-11-20 2022-12-30 上海哔哩哔哩科技有限公司 Payment request processing method, system and storage medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040081302A1 (en) * 2002-08-01 2004-04-29 Ktfreetel Co., Ltd. Method for divisional billing and device thereof
US20070118477A1 (en) * 2003-11-14 2007-05-24 Graves Phillip C Value Insertion Using Bill Pay Card Preassociated with Biller

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6289322B1 (en) 1998-03-03 2001-09-11 Checkfree Corporation Electronic bill processing
US5420606A (en) 1993-09-20 1995-05-30 Begum; Paul G. Instant electronic coupon verification system
US6128603A (en) 1997-09-09 2000-10-03 Dent; Warren T. Consumer-based system and method for managing and paying electronic billing statements
US6381582B1 (en) 1997-09-29 2002-04-30 Walker Digital, Llc Method and system for processing payments for remotely purchased goods
HUP0103385A2 (en) 1998-06-19 2002-01-28 Protx Limited Verified payment system
JP3516339B2 (en) 1998-09-15 2004-04-05 イン タッチ テクノロジーズ リミテッド Communication service
US6609113B1 (en) 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
BR0013326A (en) 1999-07-30 2002-05-28 Safewww Inc System and method for secure purchases through a network
US6502747B1 (en) 1999-10-26 2003-01-07 First Data Corporation System and method for performing money transfer transaction using TCP/IP
AU1757201A (en) 1999-11-05 2001-05-14 American Express Travel Related Services Company, Inc. Systems and methods for facilitating commercial transactions between parties residing at remote locations
US6738901B1 (en) 1999-12-15 2004-05-18 3M Innovative Properties Company Smart card controlled internet access
US6629081B1 (en) 1999-12-22 2003-09-30 Accenture Llp Account settlement and financing in an e-commerce environment
AU2001247496A1 (en) 2000-03-17 2001-10-03 United States Postal Service Methods and systems for providing an electronic account to customer
US7499875B1 (en) 2000-03-17 2009-03-03 Ebay Inc. Method and apparatus for facilitating online payment transactions in a network-based transaction facility using multiple payment instruments
CA2305249A1 (en) 2000-04-14 2001-10-14 Branko Sarcanin Virtual safe
US20030046237A1 (en) 2000-05-09 2003-03-06 James Uberti Method and system for enabling the issuance of biometrically secured online credit or other online payment transactions without tokens
WO2001093484A2 (en) 2000-06-02 2001-12-06 Financial Resources Network, Inc. Foundation funds generation system and method
US7593893B1 (en) 2000-06-13 2009-09-22 Fannie Mae Computerized systems and methods for facilitating the flow of capital through the housing finance industry
US20020029269A1 (en) 2000-06-29 2002-03-07 Campus Pipeline, Inc. Methods and systems for coordinating the termination of sessions on one or more systems
US20040260657A1 (en) 2000-07-18 2004-12-23 John Cockerham System and method for user-controlled on-line transactions
US7424457B2 (en) 2000-08-08 2008-09-09 Squaretrade, Inc. Managing an electronic seal of certification
US20020099618A1 (en) 2000-08-30 2002-07-25 Sergio Stiberman Vehicle lease exchange method & system
JP2002117361A (en) 2000-10-06 2002-04-19 Hitachi Ltd Electronic account settlement method and electronic account settlement system
US9715691B2 (en) 2001-01-16 2017-07-25 Gtj Ventures, Llc Apparatus and method for providing transaction history information, account history information, and/or charge-back information
US7464057B2 (en) 2001-03-30 2008-12-09 Citibank, N.A. Method and system for multi-currency escrow service for web-based transactions
JP2003016295A (en) 2001-06-28 2003-01-17 Nec Corp Method, system and program for online shopping
US7225156B2 (en) 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
US7249069B2 (en) 2001-08-27 2007-07-24 United Parcel Service Of America, Inc. International cash-on-delivery system and method
US7346575B1 (en) 2002-01-07 2008-03-18 First Data Corporation Systems and methods for selectively delaying financial transactions
GB0202542D0 (en) 2002-02-04 2002-03-20 Tth Man Ltd System for account authorisation
US8611919B2 (en) 2002-05-23 2013-12-17 Wounder Gmbh., Llc System, method, and computer program product for providing location based services and mobile e-commerce
EP2284784B1 (en) 2002-06-12 2017-12-13 CardinalCommerce Corporation Universal merchant platform for payment authentication
US7693783B2 (en) 2002-06-12 2010-04-06 Cardinalcommerce Corporation Universal merchant platform for payment authentication
DE10234004A1 (en) 2002-07-25 2004-02-19 Merck Patent Gmbh Process and system for processing order processes
US7251656B2 (en) * 2002-07-26 2007-07-31 Checkfree Corporation Electronic payments using multiple unique payee identifiers
US20050038707A1 (en) 2002-08-30 2005-02-17 Navio Systems, Inc. Methods and apparatus for enabling transactions in networks
BR0314158A (en) 2002-09-10 2005-07-12 Visa Int Service Ass Method and system for authentication and data provisioning
US7478057B2 (en) 2002-11-29 2009-01-13 Research In Motion Limited Method for conducting an electronic commercial transaction
JP4778899B2 (en) 2003-09-12 2011-09-21 イーエムシー コーポレイション System and method for risk-based authentication
US20080052231A1 (en) 2006-08-22 2008-02-28 Mark Moscal Transaction system
US7878393B2 (en) 2006-12-07 2011-02-01 Moneygram International, Inc. Method and apparatus for distribution of money transfers
US8706631B2 (en) 2007-03-22 2014-04-22 Sound Starts, Inc. Credit and transaction systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040081302A1 (en) * 2002-08-01 2004-04-29 Ktfreetel Co., Ltd. Method for divisional billing and device thereof
US20070118477A1 (en) * 2003-11-14 2007-05-24 Graves Phillip C Value Insertion Using Bill Pay Card Preassociated with Biller

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170116608A1 (en) * 2015-10-22 2017-04-27 Align Commerce Corporation System and method for payment processing using crypto currencies

Also Published As

Publication number Publication date
US8645272B2 (en) 2014-02-04
US20130117177A1 (en) 2013-05-09

Similar Documents

Publication Publication Date Title
US8645272B2 (en) System and method for loading stored value accounts
US10002353B2 (en) Methods and systems for conducting transactions
US8712914B2 (en) Method and system for facilitating micropayments in a financial transaction system
US9355394B2 (en) Systems and methods of aggregating split payments using a settlement ecosystem
JP6513254B2 (en) Intermediary-mediated payment system and method
US20140379578A1 (en) Method and system for conducting on-behalf electronic financial transaction
US8924291B2 (en) Consolidated payment options
US11030589B2 (en) Hosted disbursement system
US20120078736A1 (en) On-demand generation of tender ids for processing third-party payments via merchant pos systems
US20110225067A1 (en) Fraud prevention using customer and agent facing devices
US20120095912A1 (en) Systems and methods for electronic purchase transaction processing
US10650472B2 (en) Single use account pool processing system and method
US10740731B2 (en) Third party settlement
AU2012204043B2 (en) Multi-sided disbursement platform
US20140052616A1 (en) Payment system and methods for brokering consumer-pay transactions
US20170004465A1 (en) Methods and systems for for implementing virtual international banking
US20230097407A1 (en) Digital tag
US8280807B2 (en) System of transferring and utilising reusable credit
AU2008329649B2 (en) Control system arrangements and methods for disparate network systems
WO2009070716A1 (en) Control system arrangements and methods for disparate network systems

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION