A person can go to a merchant to purchase a pre-paid payment card. For example, a person might visit a drugstore and purchase a $50.00 pre-paid debit card using cash, a credit card, or a debit card associated with his or her bank account. He or she can then give the pre-paid payment card to another party (e.g., as a gift, to repay a debt, in exchange for a product or service, etc.). Visiting a merchant, however, may be an inconvenient and time consuming process. Moreover, some people might not have a debit card that can be used to withdraw funds from a bank account.
It would therefore be desirable to provide accurate and efficient systems and methods to facilitate a transfer of funds from a bank checking account to a pre-paid payment card that can be provided to another party.
A person can go to a merchant to purchase a pre-paid payment card. For example, a person might visit a drugstore and purchase a $50.00 pre-paid debit card using cash, a credit card, or a debit card associated with his or her bank account. He or she can then give the pre-paid payment card to another party (e.g., as a gift, to repay a debt, in exchange for a product or service, etc.). Visiting a merchant, however, may be an inconvenient and time consuming process. Moreover, some people might not have a debit card that can be used to withdraw funds from a bank account. It would therefore be desirable to provide accurate and efficient systems and methods to facilitate a transfer of funds from a bank checking account to a pre-paid payment card that can be provided to another party.
The process 100 of
The banking transaction server 250 might be, for example, associated with a Personal Computer (“PC”), laptop computer, an enterprise server, a server farm, and/or a database or similar storage devices. The banking transaction server 250 may, according to some embodiments, be associated with a bank, a credit card company, or any other party.
According to some embodiments, an “automated” banking transaction server 250 may identify a bank account owner when he or she attempts to make a transaction using the banking transaction server 250. For example, the banking transaction server 250 may automatically use Optical Character Recognition (“OCR”) software to detect a bank account owner (e.g., the drawer party who wrote the check document). As used herein, the term “automated” may refer to, for example, actions that can be performed with little (or no) intervention by a human.
As used herein, devices, including those associated with the banking transaction server 250 and any other device described herein, may exchange information via any communication network which may be one or more of a Local
Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.
The banking transaction server 250 may retrieve data from a check image database 230 and/or a payment account database 240. The payment account database 240 might be associated with, for example, payment accounts such as bank accounts. The check image database 230 and the payment account database 240 may be locally stored or reside remote from the banking transaction server 250. As will be described further below, the check image database 230 and payment account database 240 may be used by the banking transaction server 250 to generate and/or transmit a pre-paid payment card 270. According to some embodiments, the banking transaction server 250 communicates information to an external device, such as by transmitting an electronic file to an email server, a workflow management system, POS device, etc. In other embodiments, the banking transaction server 250 might store transaction information in a transaction history database 280.
Although a single banking transaction server 250 is shown in
In accordance with some embodiments, the systems and methods described herein provide a framework to create pre-paid payment cards 270. By way of example, and without limiting the generality of the foregoing, a pre-paid payment card 270 might be associated with a debit account or any other type of financial transaction account in which funds may be stored. Further, as used herein in, the term “issuer” can include, for example, a financial institution (i.e., bank) issuing a card, a merchant issuing a merchant specific card, a stand-in processor configured to act on-behalf of the card-issuer, or any other suitable institution configured to issue a payment card. As used herein, the term “transaction” can be associated with, for example, a merchant, a merchant terminal, an online account, or any other suitable institution or device configured to initiate a financial transaction per the request of an account owner.
The information in the payment account database 240 may be associated with, for example, a banking network, a “payment card processing system” or “credit card processing networks,” such as the MasterCard® network that allows account owners to use payment cards issued by a variety of issuers to shop at a variety of merchants. With this type of payment card, a card issuer or attribute provider, such as a bank, extends credit to an account owner to purchase products or services. When an account owner makes a purchase from an approved merchant, or withdraws funds via an ATM, the card number and amount of the purchase, along with other relevant information, are transmitted via the processing network to a processing center, which verifies that the card has not been reported lost or stolen and that the card's credit limit has not been exceeded. In some cases, the account owner's signature is also verified, a personal identification number is required or other user authentication mechanisms are imposed. The account owner is required to repay the bank for the purchases or cash withdrawals, generally on a monthly basis.
The payment account database 240 may further store a “business classification,” which is a group of merchants and/or businesses, by the type of goods and/or service the merchant and/or business provides. For example, the group of merchants and/or businesses can include merchants and/or business, which provide similar goods and/or services. In addition, the merchants and/or businesses can be classified based on geographical location, sales, and any other type of classification, which can be used to associate a merchant and/or business with similar goods, services, locations, economic and/or business sector, industry and/or industry group. According to some embodiments, different business classifications may be associated with different biometric standards.
The payment account database 240 may also store a “merchant category code” or “MCC,” which is a four-digit number created by MasterCard® or VISA® and assigned to a business by the acquirer when the business first starts accepting one of these cards as a form of payment. The MCC is used to classify the business by the type of goods or services it provides. For example, in the United States, the merchant category code can be used to determine if a payment needs to be reported to the IRS for tax purposes. In addition, MCCs are used by card issuers to categorize, track or restrict certain types of purchases. According to some embodiments, different MCCs may be associated with different biometric standards.
In accordance with some embodiments, data associated with payment card transactions is stored within the transaction history database 280. The data may include, for example, a listing of sales amount for each payment card transaction including the a transaction date, transaction amount, drawer party identifier, payee party identifier, a type of pre-paid payment card, delivery instructions etc.
At S310, a banking transaction server may receive, from a remote drawer party device, an electronic image file associated with a check document and a “drawer party” identifier. As used herein, the phrase “drawer party” refers to the person who signed the check document (e.g., the person providing payment). The remote drawer party device might be associated with, for example, a smartphone, a camera, a scanner, a web camera, a facsimile machine and/or a copier.
At S320, information about the electronic image file may be stored into a check image database, the check image database storing, for each of a plurality of banking transactions, information about the electronic image file and the drawer party identifier. At S330, a banking transaction server may retrieve, from the check image database, the information about the electronic image file and drawer party identifier.
At S340, the banking transaction server may automatically determine supplemental information associated with the banking transaction. The automatically determined supplemental information might include, for example, a drawer party postal address, a drawer party bank account number, a check amount, a check date, a check description, a payee party name (i.e., the person receiving the funds from the drawer party), a payee party postal address, a payee party electronic message address, a payee party bank account number, a payment type, and a payment delivery type.
At S350, the banking transaction server may transmit a signal to facilitate a delivery of a pre-paid payment token to a payee party associated with the banking transaction. As used herein, the phrase “pre-paid payment token” might refer to, for example, a pre-paid debit card (e.g., a physical or virtual pre-paid debit card) or any other device or account able to store funds. Note that according to some embodiments the payee party may be the same as the drawer party. That is, a person might write a check payable to himself or herself and then use that check to receive a pre-paid debit card.
According to some embodiments, the pre-paid payment token is associated with a physical pre-paid payment card that will be mailed to a payee party postal address. According to other embodiments, the pre-paid payment token is associated with a physical pre-paid payment card that will be picked-up by the payee party. For example, the payee party might be instructed to visit his local drugstore to pick up a pre-paid debit card (and the ChequeOut Platform will automatically arrange with the merchant to have a valid pre-paid debit card waiting there for the appropriate amount of funds). In other embodiments, the pre-paid payment token might comprise a physical pre-paid payment card delivered to a payee party postal address via a delivery service. For example, an Uber driver might have a device installed in his or her car that automatically creates pre-paid debit cards (for an appropriate amount of funds) along with instructions regarding where the card should be delivered. Some or all of this function may be implemented via Application Programming Interfaces (“APIs”). Note that the pre-paid payment token might be associated with a Primary Account Number (“PAN”), an expiration date, and/or a Card Security Code (“CSC”).
Instead of a physical payment card, some embodiments described herein may be associated with a creation of a “virtual” pre-paid payment token. For example, the pre-paid payment token might be associated with a virtual pre-paid payment card delivered via a payment portal (e.g., associated with a ChequeOut web page). Other embodiments might be associated with a virtual pre-paid payment card delivered via an electronic message, such as an email message or a Simple Messaging Service (“SMS”) text message. In either case, the virtual account might be associated with a PAN, an expiration date, and/or a CSC as appropriate.
According to some embodiments, a banking transaction server might transmit signals to facilitate delivery of pre-paid payment tokens to the payee party on a periodic basis. For example, a parent might arrange for his or her child to receive $200.00 each month while attending college. In this case, the pre-paid payment token might comprise a re-usable pre-paid payment card (e.g., the same pre-paid debit card might receive funds on the first day of each month).
Note that a banking transaction server might interact with other devices and/or platform to facilitate generation of a pre-paid payment card. For example, the payee party's bank may need to pay a specific amount of money from the person's account. The person writing the check (the drawer party) may have a transaction banking account (often called a current or checking account) where the money is held. The drawer party writes the various details including the monetary amount, date, and a payee party on the check and signs it to arrange for his or her bank (known as the drawee bank) to pay the appropriate amount. Any of these steps in the transaction might involve the automatic exchange of electronic messages with the banking transaction server.
Similarly, in
As another example, in
As still another example, in
In this way, a banking transaction server may facilitate a creation of a pre-paid payment token using an image of a check document. Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example,
The processor 810 also communicates with a storage device 830. The storage device 830 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 830 stores a program 812 and/or ChequeOut application platform logic 814 for controlling the processor 810. The processor 810 performs instructions of the programs 812, 814, and thereby operates in accordance with any of the embodiments described herein. For example, an electronic image file associated with a check document and a drawer party identifier may be received by the processor 810 from a remote drawer party device and information about the electronic image file may be stored into a check image database 900. The processor 810 may retrieve the information about the electronic image file and drawer party identifier from the check image database and automatically determine supplemental information associated with the banking transaction. The processor 810 may then transmit a signal to facilitate a delivery of a pre-paid payment token to a payee party associated with the banking transaction.
The programs 812, 814 may be stored in a compressed, uncompiled and/or encrypted format. The programs 812, 814 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 810 to interface with peripheral devices.
As used herein, information may be “received” by or “transmitted” to, for example: (i) the banking transaction server 800 from another device; or (ii) a software application or module within the banking transaction server 800 from another software application, module, or any other source.
In some embodiments (such as shown in
Referring to
The check image identifier 902 may be, for example, a unique alphanumeric code identifying a banking transaction that involves the user name 904 (e.g., his or her legal name) as the drawer party. The check image 906 might comprise a file or pointer associated with a graphical image file of a check document. The amount 908 might represent the funds associated with the banking transaction, and the pre-paid payment card type 910 could indicate, for example, a physical card, a virtual card, a method of delivery, etc. Note that other information might also be stored in the check image database 900, such as a check date, a payee party name or account identifier, a PAN, an expiration date, a CVC, etc.
Thus, according to some embodiments, an improved banking transaction server might automatically let a person use funds from his or her checking account to create a pre-paid debit card. Moreover, the person can do so without visiting a merchant, he or she may feel comfortable that the process is secure, etc. Moreover, although some embodiments have been described herein as using an electronic image file of a check document from a drawer party identifier, note that other embodiments may be implemented. For example, some embodiments might involve a flow in which a user manually enters bank account information to arrange for a debit. In such embodiments, the user might not need to prepare a check at all. The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.