Method and system for expediting payment delivery

Abstract

A method and system of the present invention are directed to expediting payments for scheduled delivery (e.g., next day delivery) to various payees or recipients. A computer implemented method and system for expediting payments may include receiving recipient data and payment data from a customer at a remote location; wherein recipient data comprises recipient identifier and payment data comprises payment type; obtaining a payment instrument based at least in part on the payment data; debiting an amount of the payment instrument from an account identified by the customer; and delivering the payment instrument to a facility; wherein the facility delivers the payment instrument to a recipient identified by the recipient data entered by the customer.

Description

FIELD OF THE INVENTION

The present invention relates generally to expediting payments, and more specifically to expediting payments for scheduled delivery (e.g., next day delivery) to various payees or other recipients.

BACKGROUND OF THE INVENTION

For many consumers, including corporations and small businesses, there may be instances where an immediate payment is necessary to avoid late fees, service charges, termination of a service or contractual issues. Repeated late payments may also result in a negative credit report and other adverse consequences. An Internet connection enables consumers to easily schedule payments to various payees through a personal account. However, some payees may request or even require a guaranteed payment, rather than a personal check or online payment. Currently, if consumers want to send a guaranteed payment instrument, the consumer is required to go to a bank (or other institution) and obtain a certified check, cashier's check or other similar instrument. However, as most establishments close at a reasonable closing time, around 5 pm, the transaction must occur during normal business hours. The consumer would then be required to delivery the guaranteed payment to a mail facility for overnight delivery, prior to closing time, which is generally around 6-8 pm. As a result, depending on the consumer's availability and overall convenience, it may take a consumer a few days to delivery a guaranteed payment.

To effectively delivery physical payment instruments to a payee, consumers are still required to coordinate with a mail facility or other distribution center. While some services may provide a guaranteed payment instrument, a recipient is generally required to pick up the payment instrument at a pick-up center.

Other drawbacks may also be present.

SUMMARY OF THE INVENTION

Accordingly, one aspect of the invention is to address one or more of the drawbacks set forth above.

In accordance with an exemplary embodiment of the present invention, a computer implemented method for expediting payments comprises the steps of receiving recipient data and payment data from a customer at a remote location; wherein recipient data comprises recipient identifier and payment data comprises payment type; obtaining a payment instrument based at least in part on the payment data; debiting an amount of the payment instrument from an account identified by the customer; and delivering the payment instrument to a facility; wherein the facility delivers the payment instrument to a recipient identified by the recipient data entered by the customer.

In accordance with further aspects of this exemplary embodiment, the payment type comprises one or more of cashier's check, certified check and money order; the payment type comprises one or more of a token, stored value card, cash, gift certificate, and bearer bond; the recipient data and payment data are entered by the customer on a first day and the payment instrument is delivered to the recipient at least one day after the first day; the method further comprising the step of associating one or more documents from the customer with the payment instrument for delivery to the recipient; the method further comprising the step of providing a tracking identifier to the customer for tracking the delivering of the payment instrument to the recipient; the method further comprising the step of providing status data of the payment instrument to one or more of the facility and the recipient; the method wherein the steps are performed at a financial institution location; the payment instrument is generated at the financial institution location; the method further comprising the step of authenticating the customer to confirm identity of the customer; the payment instrument comprises a stored value card wherein the recipient provides authentication data before the stored value card is activated; the authentication data is provided to a service provider associated with the stored value card; and the stored value card is activated for a designated value after authentication data from the recipient is verified.

In accordance with another exemplary embodiment of the present invention, a computer implemented system for expediting payments, the computer implemented system comprising an information module for receiving recipient data and payment data from a customer at a remote location; wherein recipient data comprises recipient identifier and payment data comprises payment type; payment module for obtaining a payment instrument based at least in part on the payment data and debiting an amount of the payment instrument from an account identified by the customer; and delivery module for delivering the payment instrument to a facility; wherein the facility delivers the payment instrument to a recipient identified by the recipient data entered by the customer.

In accordance with another exemplary embodiment of the present invention, at least one signal embodied in at least one carrier wave for transmitting a computer program of instructions configured to be readable by at least one processor for expediting payments, the computer process comprises receiving means for receiving recipient data and payment data from a customer at a remote location; wherein recipient data comprises recipient identifier and payment data comprises payment type; obtaining means for obtaining a payment instrument based at least in part on the payment data; debiting means for debiting an amount of the payment instrument from an account identified by the customer; and delivering means for delivering the payment instrument to a facility; wherein the facility delivers the payment instrument to a recipient identified by the recipient data entered by the customer.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary system for expediting payments, according to an embodiment of the present invention.

FIG. 2 illustrates an exemplary processor for expediting payments, according to an embodiment of the present invention.

FIG. 3 is an exemplary flowchart illustrating a method for expediting payments, according to an embodiment of the present invention.

FIG. 4 is an exemplary customer interface, according to an embodiment of the present invention.

FIG. 5 is an exemplary customer interface, according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

An embodiment of the present invention is directed to next day payment services that may be scheduled remotely by a sender (e.g., payor) and does not require pick-up for the recipient/payee. Rather, the payment is sent directly to the payee (or other designated recipient).

FIG. 1 illustrates an exemplary system for expediting payments, according to an embodiment of the present invention. A user, such as customer 110 and customer 112, may schedule a next day delivery of a guaranteed payment remotely through a communication channel 120. Communication channel may include an Internet channel, a Voice Response Unit (VRU) channel over a telephone, or other communication medium. For example, the customer may schedule payments via a computer, laptop, cell phone, PDA, or other remote device.

An embodiment of the present invention enables the customer 110 to communicate with a Financial Institution 130 to schedule a payment. For example, customer 110 may schedule the payment for next day delivery. The payment may be scheduled as late as 10 pm, even as late as midnight. While most conventional delivery service pick-up windows (e.g., UPS™, FedEx™, etc.) close at 6-8 pm, an embodiment of the present invention provides a means for next day payment that is currently unavailable.

Over communication channel 120, customer 110 may provide financial institution 130 information for scheduling a payment for next day delivery. For example, customer 110 may convey the customer's account information (e.g., checking account number, savings account, etc.), security information (e.g., user ID, password (or PIN), etc.) information for the payee/recipient (e.g., address, account number, etc.), and payment information (e.g., type of payment, delivery date, etc.). Other information may also be submitted.

Financial institution 130 then takes the information and generates a physical payment instrument. For example, the physical payment instrument may be a check generated by a check printer or other device. The physical payment instrument may include a guaranteed payment instrument, such as a cashier's check, certified check, money order, check drawn on a bank's account, as compared to an institution or individual, etc. Financial Institution 130 may place the payment instrument into an envelope (e.g., express mail envelope) for delivery. The placement into an envelope may be manual or automated (e.g., an envelope stuffing machine or payment instrument printed so that it may be folded into an envelope, etc.). According to another example, the payment instrument may be obtained from a merchant, a provider or other entity. In the case of a stored value card, the financial institution may receive the stored value card from a provider.

Financial institution 130 may then provide the envelopes to a Mail/Delivery Facility (e.g., an express mail agency (EMA), etc.) 140. For example, financial institution 130 may send the envelopes to Mail/Delivery Facility 140 or Mail/Delivery Facility 140 may pick up the envelopes from financial institution 130. Other arrangements may be agreed upon. Mail/Delivery Facility 140 may then delivery the envelopes with the payment instrument to a designated payee 150 by the next day (e.g. by 10 am) or other scheduled time period. Payee 150, 152 may represent other recipients as well. According to an exemplary application, financial institution 130 and Mail/Delivery Facility 140 may be located in close physical proximity. In addition, an arrangement between financial institution 130 and Mail/Delivery Facility 140 may agree that mail may be accepted at Mail/Delivery Facility 140 after normal business hours. Other arrangements may be agreed upon.

Through an embodiment of the present invention, consumers 110, 112 may schedule next day payments remotely, schedule payment delivery past normal EMA deadlines, and deliver a physical instrument directly to the recipient/payee (with no pickup required) where the instrument may be a guaranteed instrument (or other payment instrument).

Through an embodiment of the present invention, the burden is released from the customer because the financial institution handles the transaction. For example, financial institution 130 may generate or obtain the payment instrument, load the payment instrument into an envelope and provide the envelope to a mail/delivery service.

An embodiment of the present invention may also be applied for walk-in customers to the financial institution or other facility. The payment instrument may be other than a cashier's/certified check. For example, the payment instrument may include a stored value card, cash (in various currencies) or other commodity. The payment instrument may include any token of a designated monetary value, which may be fixed or variable. Other examples may include gift certificates, bearer bonds and other similar types of payments. The customer may receive a tracking number supplied by an EMA agent, which may be provided directly by the financial institution (via email or web page) or may be provided by the EMA.

FIG. 2 illustrates an exemplary processor for expediting payments, according to an embodiment of the present invention. Financial Institution 130 may include a processor 130 for expediting payments (e.g., bill payments, etc.). Processor 130 may be part of Financial Institution 130, separate from Financial Institution 130, associated with Financial Institution or based on other arrangement. Processor 130 may include various modules for performing payment functions. For example, Central Processor 130 may include Customer Information Module 210, Payee/Recipient Information Module 212, Generate Payment Module 214, Coordinate Delivery Module 216, Send Payment Module 218, Customer Interface 220, EMA Interface 222, Payee/Recipient Interface 224 and/or other modules, as represented by 226. The modules of Processor 130 may be further combined, duplicated and/or separated. The modules of Processor 130 may also be provided across multiple processors. Other implementations may be realized.

The various modules of Processor 130 may access and/or store data at Databases 230, 232. Various types of data may be stored at and/or accessed from databases 230, 232. Additional databases may be implemented. Further, the databases may be consolidated into a single database as well. Database may include various types of databases, including relational databases. Database 230, 232 may store customer data, payee/recipient data, payment data, etc. Other data may be stored and/or accessed. Other sources of information (e.g., external and/or internal sources of data) may also be accessed by the various modules of Processor 202.

Customers 110, 112 may access Processor 202, via a communication channel 120, such as Internet or other network.

Customer Information Module 210 may receive data from one or more customers, as represented by 110, 112. For example, customer information data may include security information, customer account information, authentication data and/or other data. Security information may include a user name (or identifier), password (or PIN) and/or other security data. Customer account information may include account identifier, account number and/or other account data. For example, authentication may involve verifying customer identity as well as whether the customer is authorized to schedule a payment, access the system of an embodiment of the present invention and/or perform other actions.

Payee/Recipient Information Module 212 may receive data from one or more customers, as represented by 110, 112. For example, payee/recipient information data may include payee/recipient identifier, payment information and/or other data. Payee/Recipient identifier may include name, company, address, phone number, account number, description, payee/recipient contact information and/or other data. Payment information may include amount, type of payment, delivery method, delivery time, check memo and/or other payment data.

Generate Payment Module 214 may generate or obtain one or more payment instruments based at least in part on the payee/recipient information received by Payee/Recipient Information Module 212. Payment instruments may include check, certified check, cashier's check, money order, electronic payment, etc. Various other paper or electronic payment instruments may be generated. In another example, cash (in various currencies) may be delivered to an identified payee/recipient. A token of a monetary value may also be generated or the token may be obtained from another entity. Tokens may include stored value cards, gift certificates, etc. For example, a stored value card may be received from a merchant or other source.

For example, a stored value card (or other similar instrument) may be delivered to an intended recipient. Upon receipt, the intended recipient may contact an entity (e.g., financial institution, merchant, service provider, etc.) for authentication. When authentication is verified, the stored value card may be automatically loaded with an appropriate amount or value. Therefore, unintended recipients will not be able to use the stored value card. The authentication process may involve contacting an entity and providing identification information. For example, an intended recipient may call (or otherwise contact) a service provider and provide a password (or PIN) that was delivered in a different manner (e.g., via email delivery, separate phone contact, mail delivery, etc.). In another example, other authentication information may be provided, including social security number, mother's maiden name, etc. The intended recipient may contact a service provider to activate the stored value card via phone call, email contact, website, and/or other form of communication. For example, the intended recipient may access Payee/Recipient Interface 224 for authentication.

Coordinate Delivery Module 216 may identify specifics directed to delivering the payment instrument. Module 216 may identify a payment route, delivery time, delivery method, and/or special delivery instructions. For example, a customer may request a certified check to be sent to a specific payee/recipient by 10 am the next morning where a signature by an authorized recipient is required.

Send Payment Module 218 may send the payment instrument to a mail facility (or other facility, such as a delivery facility, etc.), such as an Express Mail Facility. The payment instrument may be forwarded to the mail facility, picked up by the mail facility or via other delivery arrangement.

Customer Interface 220 provides an interface for customers to access Processor 202. For example, a customer may check the status on pending or other types of scheduled deliveries. In addition, the customer may receive a tracking number (or other identifier) for tracking a payment in progress. The customer may be alerted when a delivery is received by a payee/recipient, through a preferred mode of communication (e.g., email alert, cell phone message, text message, etc.). EMA Interface 222 provides an interface for the Express Mail Facility (or other mail facility or delivery facility) to access Processor 202. For example, an EMA may be alerted as to how many delivers to expect from financial institution 130 and when to expect each delivery. Payee/Recipient Interface 224 provides an interface for various payees or recipients to access Processor 202. For example, a payee may also check on the status of a payment. The payee (or recipient) may be alerted when a payment is to be expected and how many to expect. Other specifics may also be conveyed.

FIG. 3 is an exemplary flowchart illustrating a method for expediting payments, according to an embodiment of the present invention. At step 310, a customer may schedule a payment. At step 312, payee/recipient data may be entered. At step 314, payment data may be entered. At step 316, a financial institution may generate a payment instrument. At step 318, payment amount (which may or may not include fees or other charges) may be debited from a payor account. At step 320, the financial institution may delivery the payment instrument to a mail/delivery facility (e.g., EMA or other facility). At step 322, the express mail facility may delivery the payment instrument to an identified payee/recipient. While the process illustrated in FIG. 3 discloses certain steps performed in a particular order, it should be understood that the present invention may be practiced by adding one or more steps to the process, omitting steps within the process and/or altering the order in which one or more steps are performed.

At step 310, a customer may schedule a payment. For example, a customer may represent an individual, company or other entity desiring to make a bill payment or other type of payment. The customer may access a customer interface through a communication channel, such as Internet, VRU or other electronic, wireless or other type of communication medium. Payments may also be scheduled through a wireless device, such as a PDA, cell phone, etc. The customer may identify a payee (or recipient), type of payment, delivery of payment and/or other data related to scheduling a next day payment or other scheduled payment. The customer may schedule a payment until midnight local time. Deliveries may include Saturday, Sunday and holiday deliveries as well as international deliveries.

At step 312, payee/recipient data may be entered. The customer may identify the payee (or recipient) of the payment. The payee/recipient may include an individual, company, merchant, service provider, government entity, non-profit entity and/or other recipient of a payment. Payee/recipient data may include payee identifier (e.g., name, company name, etc.), payment location (e.g., street address, P.O. box, Internet address, etc.) and/or other payee/recipient data. The customer may also include an account identifier associated with the payee/recipient. For example, a company may identify the customer through a unique account identifier, which may be included as payee/recipient data. According to another example, a customer may upload attachments for inclusion with the payment instrument. For example, a customer may upload a remittance advice for delivery with a certified check. Other attachments may include documents, letters, etc.

At step 314, payment data may be entered. The customer may identify a preferred payment instrument. Examples of payment instruments may include check, cashier's check, certified check, money order, electronic payment, etc. Payment data may include amount, date, date of delivery, account identifier, memo and/or other data related to the payment instrument. Other payment specifics may include requiring a signature from the payee/recipient (or other authorization mechanism), time of delivery, receipt by an identified person or agent, descriptions, instructions (for the customer, the payee/recipient or other) and/or other payment specifics.

At step 316, a financial institution may generate or obtain a payment instrument. A check generating device may be located at the financial institution for generating the payment instrument. In another example, software may be loaded at the financial institution for generating the payment instrument. In yet another example, a payment generating device may be separate from the financial institution. In addition, the payment generating device may be located at a separate location, such as the EMA, payee/recipient location and/or other location. According to another example, payment instruments may be received from an entity, such as a merchant, service provider, etc.

At step 318, the payment amount (which may or may not include a service fee) may be debited from the customer's identified account.

At step 320, the financial institution may delivery the payment instrument to a mail/delivery facility. After the payment instrument is generated or obtained, the financial institution may place the payment instrument in an envelope (or other delivery container) for delivery to a mail facility (or other facility, such as a delivery facility, etc.). The placing of the payment instrument in an envelope may be manual, automatic, semi-automatic, etc. The envelope may be an express delivery envelope, for example. The envelopes may include a flag (or identifier) for delivery to the mail facility.

The financial institution and the mail facility (or other facility, such as a delivery facility, etc.) may have an agreement for accepting deliveries from the financial institution. For example, the financial institution may delivery the payment instruments to the mail facility. In another example, the mail facility may conduct scheduled pickups of the payment instrument. The financial institution and the mail facility may be located within close proximity to facilitate delivery and/or pickup. The mail facility may include a mail service (e.g., UPS, FedEx™, etc.), distribution center and/or other facility for receiving and/or delivering mail.

According to another exemplary application, the delivery of the payment instrument may be electronic through an electronic communication medium.

At step 322, the express mail facility may delivery the payment instrument to an identified payee/recipient. The delivery may occur within 24 hours or less of the scheduling of the express payment. In another example, the delivery may occur by the morning of the next day (e.g., 10 am). In addition, the delivery may be scheduled for delivery at a later time, one or more days later. Depending on payment data specifics, a signature or other authentication may be required upon delivery of the payment instrument. Other specifics and/or restrictions may be imposed.

FIG. 4 is an exemplary customer interface, according to an embodiment of the present invention. FIG. 4 illustrates an exemplary screen shot available to a customer for scheduling a payment in accordance with an embodiment of the present invention. Recipient Information 410 may include payee/recipient data. In this exemplary application, recipient information 410 may include name 412 (e.g., name of payee/recipient or other payee/recipient identifier), attention of 414 (e.g., receiving individual, etc.), address 416, phone number 418, account number or description 420 and check memo 422. Other payee/recipient data and/or other information may also be entered or displayed.

Payment Information 430 may include payment data. In this exemplary application, payment information 430 may include payable to 432, pay from 434, amount 436, send on date 438, delivery by date 440, payment method 442 (e.g., overnight delivery, etc.) and total charges/fees 444. Charges and/or fees may or may not be applied to the delivery service. Other payment data and/or other information may also be entered or displayed.

The customer may modify data by selecting 450, send the payment by selecting 452 or cancel the action by selecting 454. Other actions and/or options may be available.

FIG. 5 is an exemplary customer interface, according to an embodiment of the present invention. FIG. 5 may include a summary page of payment activity. A customer may check the status on payments and confirm delivery and/or other actions. Payment activity summary page 502 may include Payable To 510, Pay From 512, Amount 514, Send On 516, Deliver By 518, Status 520, Available Action 522 and/or other data. Payable To 510 may include payee/recipient identification, including company or service name. Pay From 512 may include an account from which the payment instruments are drawn for each payment. Multiple accounts may be used for a single payment. Amount 514 may include a payment amount. Send On 516 may include date (which may include time) of delivery and Deliver By 518 may include date (which may include time) of delivery. Status 520 may include data associated with the status of a scheduled payment. Status 520 may include in-process, pending, shipped, cancelled, returned, etc. Available Action 522 may include view, modify, and/or other actions.

According to an embodiment of the invention, the systems and processes described above invention may be implemented on any general or special purpose computational device, either as a standalone application or applications, or even across several general or special purpose computational devices connected over a network and as a group operating in a client-server mode. According to another embodiment of the invention, a computer-usable and writeable medium having a plurality of computer readable program code stored therein may be provided for practicing the process of the present invention. The process and system of the embodiments of the present inventions may be implemented within a variety of operating systems, such as a Windows® operating system, various versions of a Unix-based operating system (e.g., a Hewlett Packard, a Red Hat, or a Linux version of a Unix-based operating system), or various versions of an AS/400-based operating system. For example, the computer-usable and writeable medium may be comprised of a CD ROM, a floppy disk, a hard disk, or any other computer-usable medium. One or more of the components of the system or systems embodying the embodiments of the present inventions may comprise computer readable program code in the form of functional instructions stored in the computer-usable medium such that when the computer-usable medium is installed on the system or systems, those components cause the system to perform the functions described. The computer readable program code for the embodiments of the present inventions may also be bundled with other computer readable program software. Also, only some of the components may be provided in computer-readable code.

Additionally, various entities and combinations of entities may employ a computer to implement the components performing the above-described functions. According to an embodiment of the invention, the computer may be a standard computer comprising an input device, an output device, a processor device, and a data storage device. According to other embodiments of the invention, various components may be computers in different departments within the same corporation or entity. Other computer configurations may also be used. According to another embodiment of the invention, various components may be separate entities such as corporations or limited liability companies. Other embodiments, in compliance with applicable laws and regulations, may also be used.

According to one specific embodiment of the present invention, the system may comprise components of a software system. The system may operate on a network and may be connected to other systems sharing a common database. Other hardware arrangements may also be provided.

Other embodiments, uses and advantages of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification and examples should be considered exemplary only. The intended scope of the invention is only limited by the claims appended hereto.

Claims

1. A computer implemented method for expediting payments, wherein the method is executed by a programmed computer processor which communicates with a customer via a network, the computer implemented method comprising the steps of: receiving, at an information module using at least the programmed computer processor, recipient data, delivery data, and payment data from the customer at a remote location via the network, wherein the recipient data comprises a recipient identifier, the delivery data comprises a delivery date and time designated by the customer, and payment data comprises a payment type designated by the customer;obtaining, at a payment module using at least the programmed computer processor, a stored value card via the network based at least in part on the payment data including the type designated by the customer;debiting, at the payment module using at least the programmed computer processor, an amount of the stored value card from an account identified by the customer; anddelivering, by a delivery module using at least the programmed computer processor, the stored value card to a facility via the network, wherein the facility is a delivery facility and wherein the delivery facility delivers the stored value card based on the delivery data to a recipient identified by the recipient data entered by the customer;wherein the recipient data and payment data are entered by the customer on a first day and the stored value card is delivered to the recipient at least one day after the first day; andwherein the recipient provides authentication data before the stored value card is activated, wherein the authentication data is provided to a service provider associated with the stored value card, wherein the stored value card is activated for a designated value after authentication data from the recipient is verified.

2. The method of claim 1, wherein the payment type comprises one or more of cashier's check, certified check and money order.

3. The method of claim 1, further comprising the step of: associating one or more documents from the customer with the stored value card for delivery to the recipient.

4. The method of claim 1, further comprising the step of: providing a tracking identifier to the customer for tracking the delivering of the stored value card to the recipient.

5. The method of claim 1, further comprising the step of: providing status data of the stored value card to one or more of the facility and the recipient.

6. The method of claim 1, wherein the steps of claim 1 are performed at a financial institution location.

7. The method of claim 6, wherein the stored value card is generated at the financial institution location.

8. The method of claim 1, further comprising the step of: authenticating the customer to confirm identity of the customer.

9. A computer implemented system for expediting payments, wherein the system comprises a programmed computer processor that communicates with a customer via a network, the computer implemented system comprising: information module using at least the programmed computer processor for receiving recipient data, delivery data, and payment data from the customer at a remote location via the network, wherein the recipient data comprises recipient identifier, the delivery data comprises a delivery date and time designated by the customer, and payment data comprises a payment type designated by the customer;payment module using at least the programmed computer processor for obtaining a stored value card via the network based at least in part on the payment data including the payment type designated by the customer and debiting an amount of the stored value card from an account identified by the customer; anddelivery module using at least the programmed computer processor for delivering the stored value card to a facility via the network, wherein the facility is a delivery facility and wherein the delivery facility delivers the stored value card based on the delivery data to a recipient identified by the recipient data entered by the customer;wherein the recipient data and payment data are entered by the customer on a first day and the stored value card is delivered to the recipient at least one day after the first day; andwherein the recipient provides authentication data before the stored value card is activated, wherein the authentication data is provided to a service provider associated with the stored value card, wherein the stored value card is activated for a designated value after authentication data from the recipient is verified.

10. The system of claim 9, wherein the payment type comprises one or more of cashier's check, certified check and money order.

11. The system of claim 9, further comprising the step of: associating one or more documents from the customer with the stored value card for delivery to the recipient.

12. The system of claim 9, further comprising the step of: providing a tracking identifier to the customer for tracking the delivering of the stored value card to the recipient.

13. The system of claim 9, further comprising the step of: providing status data of the stored value card to one or more of the facility and the recipient.

14. The system of claim 9, wherein the steps of claim 1 are performed at a financial institution location.

15. The system of claim 14, wherein the stored value card is generated at the financial institution location.

16. The system of claim 9, further comprising the step of: authenticating the customer to confirm identity of the customer.

17. A non-transitory computer readable medium comprising instructions, performing the method as recited in claim 1.