This invention relates generally to a payment card system and, more particularly, to a system and method for funding a payment card account from an external source just-in-time for a purchase.
When a user desires to make a purchase using a funding source, such as home equity line or other loan, the user typically must either transfer funds from the funding source into his bank account or use a debit card processed by the funding source (e.g., a bank). In the case of the former, this requires preplanning by the user prior to the purchase, and it also requires a user to estimate the amount of the purchase. If the funding source is a loan, this results in interest accruing before the time of the purchase, and, as the user is likely to transfer more than the amount of an estimated purchase, in the user paying more interest than is necessary.
Because of the disadvantages of transferring funds from a funding source to a bank account in advance, it is often desirable for the user to have a payment card in which funds from the funding source can be used on demand and only in the amounts needed. However, many funding sources do not have their own payment card processing systems. If they contract with a traditional payment card processor, they have to hand over control of funds to the payment card processor. Therefore, there is a need for a system that enables funding source recipients to have the convenience of a payment card without requiring a funding source to be a payment card processor or to hand over control of funds to a payment card processor.
The present disclosure is directed to a system, method, and computer program for funding a payment card account from an external funding gateway just-in-time for a purchase. A payment card processing system maintains a payment card account for a user for funds from a third party funding source. The funds from the third party funding source are the only source of funds for the account, and the payment card processing system does not control or hold funds for the third party funding source. Funds from the third party funding source are credited to the payment card account only just-in-time for approval of a purchase authorization request. This enables users to use funds from a funding source on demand and only in the amounts needed.
In response to a user using the payment card for a purchase, a transaction authorization request for the payment card account is forwarded to payment card processing system via a payment card network (e.g., DISCOVER, VISA, etc.). The payment processing system generates and sends a funding request in real time for the transaction to a third party funding gateway, which may be the third party funding source itself or an entity that services user accounts for the funding source (e.g., determines whether to authorize funds for a purchase). The funding request is for funds equal to the amount of the purchase transaction.
In response to the third party funding gateway approving the funding request, the payment card processing system adjusts the available balance of the payment card to reflect the amount of the funding and approves the purchase authorization request. If the third party gateway declines the funding request, then the payment card processing system declines the transaction. All transaction authorization requests have a response deadline (e.g., 6 seconds) in which the payment card processing system must authorize or decline the request, and, therefore, communications with the funding gateway happen in real time.
In certain embodiments, a payment card may be associated with multiple funding gateways, and, in such embodiments, the system maintains a separate subaccount (or purse) for each funding gateway on the payment card.
A user 210 initiates a transaction online, at a physical store, at an ATM, or elsewhere using a payment card that enables the user to use a third party funding source for the transaction (step 105). A purchase authorization request is routed to a payment card processing system 230 via a payment network 220 (step 110). The payment network 220 is a network that routes payment card communications between merchants (and Merchant Acquirers) and payment card processing systems (e.g., system 230), which are the systems that process transactions for payment cards and maintain payment card balances.
The payment processing system 230 receives and parses the transaction authorization request (step 115). In order to approve a purchase authorization request, the system 230 requires a positive balance in an account sufficient to cover the purchase amount, and, at the time of receipt of the purchase authorization request, the payment card account has a balance of zero (except, in certain cases, there may be funds from a return of an item). This is because the sole source of funds for the payment card account is the external funding source, and the payment payment process system 230 neither holds nor controls the external funds. Consequently, the payment processing system 230 generates a funding request for the transaction (step 120). The amount of funding requested is equal to the purchase price in the purchase authorization request. It then sends the funding request to a third party funding gateway 240 (the “funding gateway”). The request is generated and sent in real time, as there is a time deadline to respond to the the purchase authorization request, typically seven seconds.
The funding gateway 240 may be the funding source itself (e.g., a bank that granted the user a loan), or it may be a company that manages or services user accounts for a funding source. The funding gateway 240 determines whether the user has sufficient funds for the purchase (or whether the user is otherwise authorized to use funds for the purchase) (steps 125, 130, 133)), and responds to the funding request from the payment card processing system accordingly (steps 135, 160). In one embodiment, the funding gateway 240 must respond to the funding request within three seconds.
In response to the funding gateway 240 declining the funding request, the payment card processing system 230 declines the purchase authorization request prior to the payment network 220 deadline (e.g., 7 seconds) for responding to such request (steps 140-155) (i.e., the payment card processing system 230 sends a declination response to the user/merchant via the payment network 220). In response to the funding gateway 240 approving the funding request, the payment card processing system 230 adjusts the available balance of the payment card account to reflect the amount of the funding request (i.e., the purchase amount) and approves the transaction authorization request prior to the payment network 220 deadline for responding to such request (steps 160-185) (i.e., the payment card processing system 230 sends an approval request to the user/merchant via the payment card network). The available balance of the payment card account is adjusted “just in time” to approve the purchase authorization request (see step 170). As the payment card processor does not extend credit to the user itself, the available balance in the payment card account must be at least equal to the purchase amount in order to approve the purchase authorization request (unless partial authorizations are permitted). Upon approving the purchase authorization request, the available balance in the payment card account is returned to zero (see step 178).
In one embodiment, when the transaction is settled, the payment card processing system sends funds for the purchase to the merchant (or merchant acquirer), and the third party funding gateway sends an equivalent amount of funds to the payment card processing system.
In one embodiment, the payment card processing system processes transactions for prepaid payment cards, such as the system described in U.S. Patent Publication No. US-2012-0215605-A1, filed on Feb. 21, 2012 with Ser. No. 13/400,888 and titled “System and Method for Providing a User with a Single Payment Card on which Prepaid and/or Reward Balances Are Tracked for Multiple Merchants,” the contents of which are incorporated by reference as if fully disclosed herein. In such a system, the payment card account for external funds is treated like a prepaid account that is funded just-in-time for a purchase.
In certain embodiments, a single payment card has multiple types of accounts associated with it. For example, there may be an account for funds from an external funding source (as discussed above), as well as prepaid accounts/purses, multi-currency wallets, and credit card accounts. In such cases, the system separately tracks balances and payments for each account associated with the payment card.
In certain embodiments, a payment card may be associated with multiple funding sources, and, in such embodiments, the system maintains a separate subaccount for each funding source. In such case, the user may declare his preferred funding account in advance of the payment card transaction.
If a user returns an item purchased with payment card account (i.e., with funds from the funding source), the refunded amount may be passed on to the funding gateway or held in the user's prepayment card account, depending on funding gateway and how the payment card processing system is configured. In embodiments in which refunds are help in the prepayment card account, the account balance is first checked in response to receiving a purchase authorization request for the prepayment card. If the balance covers the purchase price, the purchase authorization request is approved without a call to the funding gateway. However, the sole source of funds for the account is still the external funding source, as the refunded amount originated from the external funding source.
As used herein, a payment card may be a physical card, an electronic card, or any other payment device that a user can use to purchase goods and services.
In
In
In
In
The methods described with respect to
As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the above disclosure is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
The present application is a continuation of U.S. application Ser. No. 14/919,510, filed on Oct. 21, 2015. The aforementioned application is hereby incorporated by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
6044360 | Picciallo | Mar 2000 | A |
6633878 | Underwood | Oct 2003 | B1 |
6834039 | Kelly | Dec 2004 | B1 |
6931382 | Laage et al. | Aug 2005 | B2 |
7100195 | Underwood | Aug 2006 | B1 |
7318048 | King | Jan 2008 | B1 |
7664405 | Paulson | Feb 2010 | B2 |
7664705 | Walker et al. | Feb 2010 | B2 |
7877297 | Gould et al. | Jan 2011 | B2 |
7921299 | Anantha et al. | Apr 2011 | B1 |
8191766 | Tomchek et al. | Jun 2012 | B2 |
8249985 | Giordano et al. | Aug 2012 | B2 |
8290866 | Little | Oct 2012 | B1 |
8341076 | Wilkes | Dec 2012 | B1 |
8442914 | Killian et al. | May 2013 | B2 |
8447670 | DeLoach | May 2013 | B1 |
8583496 | Yoo et al. | Nov 2013 | B2 |
8612346 | Foth et al. | Dec 2013 | B2 |
8626642 | Foss, Jr. et al. | Jan 2014 | B2 |
8635117 | AcuÑa-Rohter | Jan 2014 | B1 |
9406085 | Hunt, III | Aug 2016 | B1 |
9613358 | Gardner | Apr 2017 | B1 |
9767457 | Ford et al. | Sep 2017 | B1 |
10026089 | Ford et al. | Jul 2018 | B2 |
20020002485 | O'Brien et al. | Jan 2002 | A1 |
20020033416 | Gerszberg et al. | Mar 2002 | A1 |
20020052948 | Baudu et al. | May 2002 | A1 |
20020073045 | Rubin et al. | Jun 2002 | A1 |
20020169720 | Wilson et al. | Nov 2002 | A1 |
20030142664 | Gerszberg et al. | Jul 2003 | A1 |
20040103060 | Foth et al. | May 2004 | A1 |
20040186773 | George et al. | Sep 2004 | A1 |
20050080634 | Kanniainen et al. | Apr 2005 | A1 |
20060078099 | Liebenow et al. | Apr 2006 | A1 |
20060190412 | Ostroff | Aug 2006 | A1 |
20060212407 | Lyon | Sep 2006 | A1 |
20060224454 | Kantor et al. | Oct 2006 | A1 |
20060235789 | Koch | Oct 2006 | A1 |
20060271496 | Balasubramanian et al. | Nov 2006 | A1 |
20070057043 | de la Garza Ortega | Mar 2007 | A1 |
20070063017 | Chen et al. | Mar 2007 | A1 |
20070112655 | Jones | May 2007 | A1 |
20070284436 | Gland | Dec 2007 | A1 |
20080077506 | Rampell et al. | Mar 2008 | A1 |
20080208747 | Papismedov et al. | Aug 2008 | A1 |
20090078755 | Sullivan et al. | Mar 2009 | A1 |
20090112651 | Atkinson | Apr 2009 | A1 |
20090164382 | Sally | Jun 2009 | A1 |
20090171805 | Gould | Jul 2009 | A1 |
20090299841 | Bishop et al. | Dec 2009 | A1 |
20100049599 | Owen et al. | Feb 2010 | A1 |
20100057580 | Raghunathan | Mar 2010 | A1 |
20100058156 | Hardy-McGee | Mar 2010 | A1 |
20100094699 | Beal | Apr 2010 | A1 |
20100161789 | Walia | Jun 2010 | A1 |
20100301113 | Bohn et al. | Dec 2010 | A1 |
20100312629 | Wolf et al. | Dec 2010 | A1 |
20110047038 | Halevi | Feb 2011 | A1 |
20110191209 | Gould et al. | Aug 2011 | A1 |
20110196753 | Hodgdon | Aug 2011 | A1 |
20120011063 | Killian | Jan 2012 | A1 |
20120046985 | Richter | Feb 2012 | A1 |
20120130787 | Stouffer et al. | May 2012 | A1 |
20120173348 | Yoo et al. | Jul 2012 | A1 |
20120215605 | Gardner et al. | Aug 2012 | A1 |
20120253852 | Pourfallah et al. | Oct 2012 | A1 |
20120330744 | Aissa | Dec 2012 | A1 |
20120330840 | Stinchcombe | Dec 2012 | A1 |
20130065564 | Conner et al. | Mar 2013 | A1 |
20130262307 | Fasoli et al. | Oct 2013 | A1 |
20130262313 | Martin et al. | Oct 2013 | A1 |
20130282565 | Barta et al. | Oct 2013 | A1 |
20130290184 | Shapiro et al. | Oct 2013 | A1 |
20130318348 | Lebron et al. | Nov 2013 | A1 |
20140040129 | Akin | Feb 2014 | A1 |
20140096261 | Boldyrev et al. | Apr 2014 | A1 |
20150127457 | Feldman | May 2015 | A1 |
20150363771 | Graylin et al. | Dec 2015 | A1 |
20160086160 | Desai | Mar 2016 | A1 |
20160189229 | Gopalan | Jun 2016 | A1 |
20160342549 | Hathorn | Nov 2016 | A1 |
Number | Date | Country |
---|---|---|
WO 2001041026 | Jun 2001 | WO |
WO-0208996 | Jan 2002 | WO |
WO 2002097752 | Dec 2002 | WO |
Entry |
---|
Learning and Trust in Auction Markets (Year: 2017). |
Improving the Efficiency of Blockchain Applications with Smart Contract based Cyber-insurance (Year: 2020). |
On designing a flexible e-payment system with fraud detection capability CEC 2004 (Year: 2004). |
Secure Digital Payments IEEE press 1999 (Year: 1999). |
Yingjiu Li and Xinwen Zhang, “A security-enhanced one-time payment scheme for credit card,” 14th International Workshop Research Issues on Data Engineering: Web Services for e-Commerce and e-Government Applications, 2004. Proceedings., 2004, pp. 40-47, doi: 10.1109/RIDE.2004.1281701. |
U.S. Appl. No. 14/919,510, Aug. 24, 2018, Office Action. |
U.S. Appl. No. 14/919,510, Mar. 19, 2019, Office Action. |
U.S. Appl. No. 14/919,510, Jul. 23, 2019, Office Action. |
U.S. Appl. No. 14/919,510, Dec. 9, 2019, Office Action. |
U.S. Appl. No. 14/919,510, Jun. 23, 2020, Office Action. |
U.S. Appl. No. 14/919,510, Oct. 4, 2022, Decision on Appeal. |
Number | Date | Country | |
---|---|---|---|
Parent | 14919510 | Oct 2015 | US |
Child | 17658789 | US |