A system, method, and computer program are provided for capturing a unique identifier for a merchant used in purchase transaction approval requests. A merchant is able to register with a payment card system via a merchant interface. A payment card number is associated with and provided to the merchant via the interface with instructions to perform a purchase transaction with the payment card number. The system receives requests for approval of payment card transactions, where each request includes a payment card number and a unique identifier for a merchant. For each request, the system determines whether the payment card number includes an indicator that the payment card number is for the purpose of capturing a unique identifier for a merchant. In response to receiving a request with a payment card number that includes the indicator, a unique identifier accompanying the request is automatically associated with the registering merchant.
|
1. An automated method, performed by a payment card system, for capturing a unique identifier for a merchant used in purchase transaction approval requests, the method comprising:
providing a merchant interface via which a merchant is able to register with the payment card system, wherein the merchant enters a merchant name in the interface in registering;
in response to a merchant initiating registration with the payment card system, associating a payment card number with the merchant and providing the payment card number to the merchant via the merchant interface with instructions for the merchant to perform a purchase transaction with the payment card number in order to capture a unique identifier of the merchant, wherein the payment card number includes an indicator that indicates to the payment card system that the payment card number is for the purpose of capturing a unique identifier of a merchant, wherein the unique identifier is a merchant's mid;
receiving at the payment card system one or more requests for approval of payment card transactions, wherein each request includes a payment card number and a mid for a merchant;
for each such request received, determining whether a respective payment card number associated with the request includes the indicator that indicates to the payment card system that the respective payment card number is for the purpose of capturing a mid for a merchant;
in response to receiving a request, among the one or more requests for approval, having a payment card number that includes the indicator, automatically associating a mid accompanying the request with a merchant previously associated with the payment card number;
in response to receiving a request, among one or more requests for approval, having a payment card number that does not include the indicator and having a mid that does not match a mid of a registered merchant, determining whether other merchant information accompanying the request matches information, including name and address information, previously stored in association with a registered merchant;
in response to the other merchant information in the request matching information previously associated with a registered merchant, determining whether the matching information has been confirmed for the registered merchant a threshold number of times;
in response to the matching information being confirmed the threshold number of times, approving the transaction request if there are sufficient funds or credit for the transaction for use with the matching registered merchant in an account of a payment card holder associated with the transaction, and sending a message to the matching registered merchant inquiring as to whether the merchant has changed its merchant processor or added a new merchant location; and
in response to the matching information not being confirmed a threshold number of times, declining the transaction.
11. One or more non-transitory computer-readable media comprising computer program code that when executed by a payment card system enables the payment card system to perform the following method for capturing a unique identifier for a merchant used in purchase transaction approval requests, the method comprising:
providing a merchant interface via which a merchant is able to register with the payment card system, wherein the merchant enters a merchant name in the interface in registering;
in response to a merchant initiating registration with the payment card system, associating a payment card number with the merchant and providing the payment card number to the merchant via the merchant interface with instructions for the merchant to perform a purchase transaction with the payment card number in order to capture a unique identifier of the merchant, wherein the payment card number includes an indicator that indicates to the payment card system that the payment card number is for the purpose of capturing a unique identifier of a merchant, wherein the unique identifier is a merchant's mid;
receiving at the payment card system one or more requests for approval of payment card transactions, wherein each request includes a payment card number and a mid for a merchant;
for each such request received, determining whether a respective payment card number associated with the request includes the indicator that indicates to the payment card system that the respective payment card number is for the purpose of capturing a mid for a merchant;
in response to receiving a request, among the one or more requests for approval, having a payment card number that includes the indicator, automatically associating a mid accompanying the request with a registering merchant previously associated with the payment card number;
in response to receiving a request, among the one or more requests for approval, having a payment card number that does not include the indicator and having a mid that does not match, a mid of a registered merchant, determining whether other merchant information accompanying the request matches information, including name and address information, previously stored in association with a registered merchant;
in response to the other merchant information in the request matching information previously associated with a registered merchant, determining whether the matching information has been confirmed for the registered merchant a threshold number of times;
in response to the matching information being confirmed the threshold number of times, approving the transaction request if there are sufficient funds or credit for the transaction for use with the matching registered merchant in an account of a payment cardholder associated with the transaction, and sending a message to the matching registered merchant inquiring as to whether the merchant has changed its merchant processor or added a new merchant location; and
in response to the matching information not being confirmed a threshold number of times, declining the transaction.
10. A payment card system for capturing a unique identifier for a merchant used in purchase transaction approval requests, the payment card system comprising:
one or more processors;
one or more memory units coupled to the one or more processors, wherein the one or more memory units store instructions that, when executed by the one or more processors, cause the payment card system to perform the operations of:
providing a merchant interface via which a merchant is able to register with the payment card system, wherein the merchant enters a merchant name in the interface in registering;
in response to a merchant initiating registration with the payment card system, associating a payment card number with the merchant and providing the payment card number to the merchant via the merchant interface with instructions for the merchant to perform a purchase transaction with the payment card number in order to capture a unique identifier for the merchant, wherein the payment card number includes an indicator that indicates to the payment card system that the payment card number is for the purpose of capturing a unique identifier of a merchant, wherein the unique identifier is a merchant's mid;
receiving at the payment card system one or more requests for approval of payment card transactions, wherein each request includes a payment card number and a mid for a merchant;
for each such request received, determining whether a respective payment card number associated with the request includes the indicator that indicates to the payment card system that the respective payment card number is for the purpose of capturing a mid for a merchant;
in response to receiving a request, among the one or more requests for approval, having a payment card number that includes the indicator, automatically associating a mid accompanying the request with a merchant previously associated with the payment card number;
in response to receiving a request, among one or more requests for approval, having a payment card number that does not include the indicator and having a mid that does not match a mid of a registered merchant, determining whether other merchant information accompanying the request matches information, including name and address information, previously stored in association with a registered merchant;
in response to the other merchant information in the request matching information previously associated with a registered merchant, determining whether the matching information has been confirmed for the registered merchant a threshold number of times;
in response to the matching information being confirmed the threshold number of times, approving the transaction request if there are sufficient funds or credit for the transaction for use with the matching registered merchant in an account of a payment cardholder associated with the transaction, and sending a message to the matching registered merchant inquiring as to whether the merchant has changed its merchant processor or added a new merchant location; and
in response to the matching information not being confirmed a threshold number of times, declining the transaction.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
after associating a mid with a registering merchant, using said mid to look up the merchant in a mid database;
comparing information about the merchant in the mid database to information entered by the merchant in the merchant interface during registration; and
in response to identifying a disparity between the information in the mid database and the information entered by the merchant during registration, updating the mid database to match the information entered by the merchant during registration.
8. The method of
9. The method of
in response to the request indicating that the merchant associated with the request does not accept split-tender transactions, notifying the merchant that the merchant is not currently configured to accept split-tender transactions.
12. The one or more non-transitory computer-readable media of
13. The one or more non-transitory computer-readable media of
14. The one or more non-transitory computer-readable media of
15. The one or more non-transitory computer-readable media of
16. The one or more non-transitory computer-readable media of
17. The one or more non-transitory computer-readable media of
after associating a mid with a registering merchant, using said mid to look up the merchant in a mid database;
comparing information about the merchant in the mid database to information entered by the merchant in the merchant interface during registration; and
in response to identifying a disparity between the information in the mid database and the information entered by the merchant during registration, updating the mid database to match the information entered by the merchant during registration.
18. The one or more non-transitory computer-readable media of
in response to the request indicating that the merchant associated with the request does not accept split-tender transactions, notifying the merchant that the merchant is not currently configured to accept split-tender transactions.
|
1. Field of the Invention
This invention relates generally to a payment card system and, more particularly, to a system and method for capturing a unique identifier for a merchant used in purchase transaction approval requests.
2. Description of the Background Art
Whether a customer is shopping in a brick and mortar merchant location or visiting an online retailer, he is likely to use a credit card, debit card, gift card, or other payment card in order to complete a purchase transaction. When a customer attempts to use a payment card for a purchase at a merchant, the payment card number (e.g., credit card number), purchase amount, and one or more unique identifiers for the merchant are sent, via a merchant processor (e.g., an acquiring bank), to the issuing bank or other entity responsible for approving/declining transactions for the card. These identifiers typically include a merchant ID (MID) and/or a terminal ID (TID), which are assigned to merchants and terminals, respectively by a merchant processor. Issuing banks maintain merchant databases that map merchants to their respects MIDs and TIDs so that they identify the merchant for purposes of fraud detection, marketing, customer analysis, etc. As the issuing banks that approve/decline transactions are usually not the entities that assign MIDs and TIDs to merchants, discrepancies between the MIDs/TIDs in the issuing banks' databases and the MIDs/TIDs currently used by corresponding merchants often arise. They typically occur when a merchant switches merchant processors, moves a credit card terminal to a different location, opens a new location, etc. In a typical credit card transaction, while a correct MID or TID is ideal, it is not critical. For example, in the case where a customer uses a credit card to make a purchase, the issuing bank primarily decides whether to authorize the transaction based on whether the credit card holder has sufficient credit for the purchase, not based on the identity of the merchant.
International Application No. PCT/US2012/25932, filed on Feb. 21, 2012 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,” which is incorporated herein by reference in its entirety, describes a system and method in which multiple merchant purses are associated with a user's account (which may be associated with a physical or electronic card). Each purse corresponds to one merchant, and represents the user's credit balance with the merchant (e.g., prepaid deposits plus rewards). The balance associated with each merchant purse is separately tracked.
In this situation where there are multiple merchant credits associated with the same account, it is critical that the purchase transaction be settled with the correct merchant and, therefore, it is necessary for the payment card processor to be able to correctly identify the merchant sending the purchase authorization request. For example, if the payment card processor cannot identify the merchant or maps the MID in the authorization request to the wrong merchant, the transaction would either be denied or the system would debit the wrong merchant purse. If a customer is constantly denied approval of a purchase request due to a discrepancy in the MID and/or other merchant identifying information, the customer has an unsatisfactory experience with the payment card. Therefore, there is a need for enabling a payment card processing system to automatically capture the MID and/or other unique identifiers for a merchant used in purchase transaction approval requests.
The present invention is directed to a system, method, and computer program for capturing one or more unique identifiers (e.g., a merchant ID (MID), a merchant name, a merchant address, latitude and longitude, store number, terminal ID (TID), etc.) for a merchant used in purchase transaction approval requests. A merchant is able to register with a payment card system by entering a merchant name in a merchant interface. In response to a merchant initiating registration with the payment card system, a payment card number is associated with the merchant and provided to the merchant via the merchant interface with instructions to perform a purchase transaction with the payment card number. The payment card number includes an indicator (e.g., one or more numbers immediately following the BIN or IIN in a payment card number) that indicates that the payment card number is for the purpose of capturing a unique identifier of a merchant.
The payment card system (or a system that processes payment card transaction for the payment card system) regularly receives requests for approval of payment card transactions (also referred to herein as “purchase authorization requests” or “authorization requests”), where each request includes a payment card number and a unique identifier for a merchant. For each request received, the system determines whether the payment card number associated with the request includes the indicator indicating that the payment card is for the purpose of capturing a unique identifier for a merchant. In response to receiving a request with a payment card number that includes the indicator, one or more unique identifiers for the merchant within the request is automatically associated with the registering merchant previously associated with the payment card number. This enables the system to recognize such unique identifier(s) in future authorization requests from the registering merchant.
In certain embodiments, the instructions to the registering merchant to perform a purchase transaction also include a specified purchase transaction amount. In response to receiving a request for approval of a purchase transaction with a payment card number that includes the indicator, one or more unique identifiers accompanying the request is only associated with the merchant previously associated with the payment card number if a purchase amount in the request matches the specified purchase transaction amount provided to the merchant.
In certain embodiments, after associating a unique identifier with a registering merchant, the system uses the unique identifier to look up the merchant in a database. The system then compares information about the merchant in the database to information entered by the merchant in the merchant interface during registration. In response to identifying a disparity between the information in the database and the information entered by the merchant during registration, the system updates the database to match the information entered by the merchant during registration.
The present invention also provides an improved method for handling transactions including unknown MIDs. In certain embodiments, when a payment card processing system receives a MID it does not recognize, it determines if other merchant information (e.g., latitude and longitude, store ID, TID, merchant name, etc.) accompanying the authorization request matches known information about a registered merchant, where such known information has been confirmed a threshold number of times. If the only difference between certain merchant information in the current authorization request and a threshold number of previously valid authorization requests received from the merchant is the MID, the system assumes that merchant has changed its MID and approves the transaction if the account holder has sufficient funds or credit in his account for the transaction.
The present invention is directed to a system, method, and computer program for capturing a unique identifier for a merchant used in purchase transaction approval requests. As used herein, a payment card processing system is any system within a payment card network that processes requests for approval of purchase transactions using a payment card, such as a payment card issuer (e.g., the issuing bank). The payment card system may be any system associated with the underlying bank issuing the credit card, the company marketing the card, or the company managing the card.
As seen in
The merchant begins the registration process by entering identifying information, such as, for example, the merchant name, merchant address, etc. and agreeing to terms and conditions. A payment card number is associated with the registering merchant (i.e., the “assigned payment card number”) (step 120). The payment card number has the same format as an account holder's payment card number (i.e., 16 digits with the same MIN and BIN/IIN of the account holder's payment card number) and includes an indicator that indicates to the system that the payment card number is only for the purpose of capturing a merchant's unique ID. For example, in a preferred embodiment, the payment cards within the payment card system have 16 digits and are structured as follows: the first 6 digits are the BIN or IIN, the value of digits 7 and 8 indicate whether or not the payment card is for unique ID capture, digits 9-15 are random, and digit 16 is the checksum.
The payment card system provides instructions, via the merchant interface, to the merchant to perform a purchase transaction (e.g., using a nominal amount or zero) using the assigned payment card (step 130). The purchase transaction would typically be performed as a “card not present” transaction since the merchant would not have a physical card.
When the registering merchant performs a purchase transaction with the payment card number provided during the registration process, the purchase authorization request is sent to a payment card processing system (which may or may not be the same as the payment card system) that processes purchase authorization requests for the payment card. Authorization requests include a payment card number, a purchase amount, and one or more data items that uniquely identify the merchant (e.g., a MID, TID, address, latitude/longitude, etc.). For each authorization request received, the payment card processing system determines whether the payment card number in the request includes the indicator indicating that the payment card number is only for the purpose of capturing a unique identifier of a merchant (step 140). A unique identifier for a merchant may include one or more of a MID, a merchant name, a merchant address, latitude and longitude, store number, TID, enabled/disabled partial authorization, and any other unique identifier that is sent to the payment card processing system during the purchase transaction approval request.
In response to receiving a request with a payment card number that includes the indicator, the payment card processing system automatically associates one or more data items (e.g., MID, latitude/longitude, address, etc.) within the request that uniquely identify a merchant (i.e., a unique identifier) with the registering merchant previously assigned the payment card number (step 150). A person of skill in the art would understand that
In one embodiment, the above method is used to associate a MID in an authorization request with a registered merchant. The above invention enables the payment card system to identify the MID currently being used by a registered merchant.
In certain embodiments, for an additional layer of security, the instructions to perform a purchase transaction also include a specified purchase transaction amount. In response to receiving a request for approval of a purchase transaction with a payment card number that includes the indicator, the unique identifier accompanying the request is only associated with the merchant previously associated with the payment card number if a purchase amount in the request matches the specified purchase transaction amount provided to the merchant. This embodiment is described with respect to
In certain embodiments, an authorization request includes an indication of whether or not the merchant accepts split-tender transactions. In one embodiment, when the system receives an authorization request with payment card number that is for the purpose of capturing a unique identifier for the merchant, the system also checks to see if the authorization request indicates whether or not the merchant accepts split-tender transactions. If the authorization request indicates that the merchant does not accept a split-tender transaction, the system automatically sends a message to the merchant (via email, via the registration interface, etc.) notifying the merchant that he/she/it is not currently configured to accept split-tender transactions.
In certain embodiments, after associating a unique identifier with a registering merchant, the system uses the unique identifier to look up the merchant in a database. For example, the merchant may pass the MID and merchant name/address information to a credit card company and the credit card company uses the information to update its MID database. The MID database stores MIDs in association with other merchant information (e.g., merchant name and address). In the preferred embodiment, the MID database is stored within the payment network association system. The system then compares the merchant information in the database to information entered by the merchant in the merchant interface during registration. In response to identifying a disparity between the information in the database and the information entered by the merchant during registration, the system updates the database to match the information entered by the merchant during registration.
Although the present invention may be used in any type of payment card system, the present invention is particularly useful in a prepayment card system that enables a payment cardholder to associate multiple merchant purses with the payment cardholder's account. In one embodiment of a payment card system, prepaid deposits by the account holder to the one or more merchants are held in the merchant purses, and each merchant purse in a payment cardholder's account is uniquely identified using a unique identifier captured in accordance with the method described above with respect to
With prepaid payment cards, account holders are only able to use the card for merchants for which the user has made a prepaid deposit. When a payment card processing system receives a purchase authorization request for such payment cards, the payment card processing system determines whether the authorization request is from a merchant for which the payment card holder may use the account. If a registered merchant's MID or other unique identifier changes and no notice is provided to the system, the system may erroneously decline a transaction. A further embodiment of the invention provides a method for handling authorization transactions that minimize the likelihood of such erroneous declines.
Referring to
If the MID is recognized, the system determines whether the account holder has sufficient funds or credit in the account for use with the merchant associated with the MID (step 235). If there is not sufficient funds or credit in the account for use with the merchant, the request is declined (step 240), but if there is, the request is approved (step 250). In certain embodiments, this process occurs in two steps. If the MID is recognized, the system determines if the account holder has a merchant purse in the account for the merchant associated with the MID. If there is a merchant purse in the account for the merchant, the system then checks whether the merchant purse or overflow account, if any, has sufficient funds or credit for the transaction. If there are sufficient funds or credit, then the request is approved, but if there are no sufficient funds or credit, the request is declined.
If, however, the MID is not recognized, the system determines whether other merchant information accompanying the authorization request, such as name, address, latitude/longitude, TID, store number, etc., match certain non-MID information for a registered merchant (step 255). If the other information does not match, the request is declined (step 260), but if there is a match, the system determines whether the matching information has been previously confirmed a threshold number of times (step 265). The threshold number of times may be zero or more, but is preferably greater than one. In one embodiment, the matching non-MID information is considered to have been confirmed once for each previous, valid authorization request from the merchant that included the matching non-MID information. In other words, the system determines if the only difference between certain merchant data in the current authorization request and previous authorization requests is the MID. If the system does not confirm a match for a threshold number of times, the request is declined (step 270), but if it does, the system assumes that the request for the purchase transaction approval comes from a registered merchant with the non-MID matching information (the “matching merchant”) (step 275).
The system then 1) proceeds to step 235 to determine if the account holder has sufficient funds or credit in the account for use with the matching merchant (step 280), and 2) sends a message (via email, text, the merchant interface/portal, etc.) to the matching merchant inquiring as to whether the merchant has changed its merchant processor or has a new location (step 285). The system may provide an interface via which the merchant can respond to the request (e.g., Merchant Portal 430 in
The methods described with respect to
In the preferred embodiment, the payment system network 300 includes various payment card processing systems 310, 315, 320 for processing different payment cards. These systems are usually associated with the issuing bank for the payment card (e.g., CapitalOne, Citicard, Bank of America, etc.). The payment card processing systems 310, 315, 320 are connected to a payment network association (e.g., Visa, MasterCard, Discover, etc.) 330, one or more merchant processors 340, and one or more merchants 350 via a network (e.g., a wide area network (WAN)) 380. In one embodiment, when a customer requests a purchase from a merchant 350 (e.g., swipes his card), the merchant 350 processes the request via one or more merchant processors 340 and sends the request, along with the MID, to the payment card processing system 310 to authorize the transaction. If there is credit or funds available, the payment card processing system 310 authorizes the transaction by sending an authorization code to the merchant processors 340 for completion of the purchase transaction by the merchant 350. Then, the merchant 350, via the merchant processors 340, batches together all of the purchase transactions from the day and sends them to the payment network association 330 for settling with the payment card systems 310, 315, 320.
System 400 includes a Merchant Boarding Validation Module 420 that validates merchant MIDs, TIDs, and other information in accordance with the method described with respect to
System 400 includes a Merchant Portal 430 (e.g., a web-based application or a dedicated application) via which a merchant can register, as well as create and manage deals and campaigns. The Merchant Portal 430 provides the interface via which the merchant registers with System 400, as described with respect to
System 400 includes an Accounts and Transactions Database 410. The database stores information on each account holder 410a. Each account may have one or more purses associated with the account. For example, for Cardholder X's account, there are three purses associated with the account: Merchant A Purse 410b, Merchant B Purse 410c, and Merchant C Purse 410d. A person skilled in the art would understand that there may be more or less purses associated with an account within the scope of the present invention. Each merchant purse may have one or more sub-accounts that are used to manage the accounting when a user attempts to purchase a product/service using the user account. For example, a purse funds sub-account may specify available purse funds, as well as various bank/institution transaction fees that accrue when the prepayment card is used to make a purchase. Another sub-account may track prepaid and rewards dollars including committed (but unfunded) merchant reward dollar amounts and funded merchant reward dollar amounts. The Accounts and Transactions Database 410 also includes Registered Merchant Information 415, which is merchant information obtained during the registration process and during the process described with respect to
System 400 includes an Authorization Engine 460 that processes account purchases. The Authorization Engine 460 traverses Database 410 to determine whether or not a user has sufficient funds, or an overflow account, in an applicable merchant purse to complete a purchase from the merchant using the account. Authorization Engine 460 interfaces with the merchant processor by means of a Merchant Processor Interface 475.
System 400 also includes a Sub-Account Rules Engine 450 that applies sub-accounting rules to the merchant purses within Database 410. The sub-accounting rules define how rewards are calculated and which funds in the subaccounts (e.g., prepaid funds vs. reward funds) are used to settle a transaction. System 400 also includes a Settlement Engine 440 that manages the settlement and funding of transactions. System 400 includes a Payment Network Association Interface 470 via which transaction data (e.g., sales draft information) from merchants is provided to settle transactions.
For each request received for approval of a purchase transaction using a payment card, the payment card processing system determines whether the payment card number includes the indicator indicating that the payment card number is only for the purpose of capturing a unique identifier of a merchant (step 540). If the payment card number does not include the indicator, the transaction is processed normally (step 555). In response to receiving a request with a payment card number that includes the identifier, the system determines whether the purchase amount in the request matches the purchase amount specified in the instructions during registration (step 560). If the purchase amount in the request does not match the purchase amount specified in the instructions, the merchant's unique ID is not captured (step 565). If there is a match, the system associates a unique identifier (e.g., the MID) accompanying the request with a registering merchant previously assigned the payment card number (step 570).
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 disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
Patent | Priority | Assignee | Title |
10026089, | Aug 19 2013 | Marqeta, Inc. | System, method, and computer program for dynamically identifying a merchant associated with an authorization request for a payment card |
11023885, | Jun 30 2017 | Marqeta, Inc.; MARQETA, INC | System, method, and computer program for securely transmitting and presenting payment card data in a web client |
11165886, | Jan 03 2020 | Bank of America Corporation | Multi-distribution resource allocation system |
11341486, | May 21 2018 | Bank of America Corporation | System for secure transfer of encrypted resources and asynchronous execution |
11599627, | Dec 03 2018 | Bank of America Corporation | System employing smart device for secure and authenticated event execution |
11631103, | Jun 13 2019 | CAPITAL INTELLECT, INC | System and method for tracking earned rewards for online transaction |
11636465, | Oct 21 2015 | Marqeta, Inc. | System, method, and computer program for funding a payment card account from an external source just-in-time for a purchase |
Patent | Priority | Assignee | Title |
6044360, | Apr 16 1996 | RESTRICTED SPENDING SOLUTIONS, LLC | Third party credit card |
6931382, | Jan 24 2001 | Kioba Processing, LLC | Payment instrument authorization technique |
7664405, | Sep 28 2004 | CALIX, INC | Pluggable optical diplexer/triplexer module |
7664705, | Mar 31 1999 | PayPal, Inc | Methods and systems for accepting offers via checks |
8191766, | Mar 04 2008 | MasterCard International Incorporated | Methods and systems for managing merchant identifiers |
8249985, | Nov 29 2007 | Bank of America Corporation | Sub-account mechanism |
8290866, | Jul 14 2008 | The PNC Financial Services Group, Inc. | Family purchase card for developing financial management skills |
8341076, | May 25 2004 | GALILEO FINANCIAL TECHNOLOGIES, LLC | Automatic overdraft attached to prepaid debit card accounts |
8447670, | Jan 13 2006 | JP Morgan Chase Bank, N.A. | Universal payment protection |
8626642, | Aug 22 2003 | CC Serve Corporation | System and method for dynamically managing a financial account |
8635117, | Mar 15 2013 | Allowify LLC | System and method for consumer fraud protection |
20020002485, | |||
20020073045, | |||
20020169720, | |||
20040186773, | |||
20060078099, | |||
20060190412, | |||
20060212407, | |||
20060224454, | |||
20070112655, | |||
20070284436, | |||
20080077506, | |||
20080208747, | |||
20090078755, | |||
20090164382, | |||
20090299841, | |||
20100049599, | |||
20100057580, | |||
20100094699, | |||
20100301113, | |||
20100312629, | |||
20110047038, | |||
20120130787, | |||
20120215605, | |||
20120253852, | |||
20120330840, | |||
20130065564, | |||
20130262307, | |||
20130282565, | |||
20130290184, | |||
20140040129, | |||
WO141026, | |||
WO2097752, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Aug 16 2013 | GARDNER, JASON M | MARQETA, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 031039 | /0330 | |
Aug 19 2013 | Marqeta, Inc. | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Sep 28 2020 | M2551: Payment of Maintenance Fee, 4th Yr, Small Entity. |
Nov 17 2020 | BIG: Entity status set to Undiscounted (note the period is included in the code). |
Date | Maintenance Schedule |
Apr 04 2020 | 4 years fee payment window open |
Oct 04 2020 | 6 months grace period start (w surcharge) |
Apr 04 2021 | patent expiry (for year 4) |
Apr 04 2023 | 2 years to revive unintentionally abandoned end. (for year 4) |
Apr 04 2024 | 8 years fee payment window open |
Oct 04 2024 | 6 months grace period start (w surcharge) |
Apr 04 2025 | patent expiry (for year 8) |
Apr 04 2027 | 2 years to revive unintentionally abandoned end. (for year 8) |
Apr 04 2028 | 12 years fee payment window open |
Oct 04 2028 | 6 months grace period start (w surcharge) |
Apr 04 2029 | patent expiry (for year 12) |
Apr 04 2031 | 2 years to revive unintentionally abandoned end. (for year 12) |