US9715689B1 - Interoperable mobile wallet refund - Google Patents

Interoperable mobile wallet refund Download PDF

Info

Publication number
US9715689B1
US9715689B1 US14/030,929 US201314030929A US9715689B1 US 9715689 B1 US9715689 B1 US 9715689B1 US 201314030929 A US201314030929 A US 201314030929A US 9715689 B1 US9715689 B1 US 9715689B1
Authority
US
United States
Prior art keywords
computer system
code
transaction
bank computer
merchant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US14/030,929
Inventor
Stephen M. Ellis
Michael J. Kennedy
Ashish Bhoopen Kurani
Melissa Lowry
Uma Meyyappan
Bipin Sahni
Nikolai Stroke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wells Fargo Bank NA
Original Assignee
Wells Fargo Bank NA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wells Fargo Bank NA filed Critical Wells Fargo Bank NA
Priority to US14/030,929 priority Critical patent/US9715689B1/en
Assigned to WELLS FARGO BANK, N.A. reassignment WELLS FARGO BANK, N.A. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LOWRY, MELISSA, ELLIS, STEPHEN M, KENNEDY, MICHAEL J, KURANI, ASHISH BHOOPEN, MEYYAPPAN, UMA, SAHNI, BIPIN, STROKE, NIKOLAI
Priority to US15/374,925 priority patent/US10049355B1/en
Priority to US15/423,449 priority patent/US9972012B1/en
Publication of US9715689B1 publication Critical patent/US9715689B1/en
Application granted granted Critical
Priority to US15/975,478 priority patent/US10580008B1/en
Priority to US16/101,133 priority patent/US10769621B1/en
Priority to US16/806,893 priority patent/US11361307B1/en
Priority to US17/011,902 priority patent/US11514433B1/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3676—Balancing accounts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G06Q30/015—Providing customer assistance, e.g. assisting a customer within a business location or via helpdesk
    • G06Q30/016—After-sales

Definitions

  • the present disclosure relates generally to the field of systems that use mobile devices to transfer funds. More specifically, the present disclosure relates to systems and methods for enabling individuals to use their electronic devices to transfer funds, purchase products, receive refunds and services.
  • Payments for products and services are often completed using credit cards, debit cards, checks or cash.
  • mobile handheld electronic device such as a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, and so on. Most of these devices tend to have a wireless Internet connection.
  • a person may wish to make payments to or receive refunds from merchants or other individuals using these mobile devices.
  • a person may wish to transfer funds to or receive funds from other individuals using their mobile devices. Enhanced systems and methods of facilitating such transactions would be desirable.
  • One embodiment includes a computer-implemented method for providing a computer-implemented system and method that includes receiving, by a messaging hub computer system, from a point of sale (POS) device of a merchant, a request to process a refund for a transaction that occurred between the merchant and a mobile device of a payor, the request comprising a previously used code that was exchanged between the POS device and the mobile device.
  • the method includes determining, by the messaging hub computer system, a first financial institution based at least partially on a portion of the code, and receiving, from a computer system of the first financial institution, payment credential information of an account held by the payor to process the refund using the payment credential information.
  • the method may further include transferring, by the messaging hub computer system, the refund from an account held by the merchant to the account held by the payor.
  • One embodiment includes a computer system that includes a processor coupled to machine readable storage media having instructions stored therein that, when executed by the processor, cause the processor to transmit, by a recipient bank computer system, a refund transaction request for a previous transaction between a merchant and a payor, to a messaging hub computer system, the refund transaction request including a previously used dynamic token, a refund transaction amount, and an indication that the transaction is a refund transaction.
  • the processor configured to receive from the messaging hub computer system underlying payment credential information for an account held by the payor that was used for the previous transaction and transfer, by the recipient bank computer system, the refund from an account held by the merchant to the account held by the payor.
  • a computer-implemented method for performing a transaction includes receiving, by a POS (Point of Sale) device, a previously used dynamic token from a mobile device for a refund transaction, the previously used dynamic token identifying a previous transaction that transferred funds to a merchant from a payor, and determining the transaction amount for the previous transaction using the previously used dynamic token.
  • the method further includes transmitting the previously used dynamic token and the transaction amount to a recipient bank computer system and receiving an approval/decline indicator for the refund transaction from the recipient bank computer system.
  • the method includes generating a receipt approving or declining the refund transaction for the payor.
  • FIG. 1 is a schematic diagram of a computer-implemented payment processing system according to an example embodiment.
  • FIG. 2 a is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 2 b is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 3 a is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 3 b is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 4 is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 5 is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 6 is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 7 is a process implemented by the payment processing system of FIG. 1 .
  • FIG. 8 is a process implemented by the payment processing system of FIG. 1 .
  • a computer-implemented payment processing system 100 may be used to set up and utilize a mobile wallet account.
  • the user may be a business entity and/or an individual consumer that has one or more source accounts with a financial institution.
  • the source accounts may include business or consumer demand deposit accounts.
  • the mobile wallet account can be created for the user to transmit funds from a demand deposit account in return for purchase of goods or services to a merchant. Additionally, funds can be transferred from the demand deposit account to another person.
  • FIG. 1 is a schematic diagram of a computer-implemented payment processing system according to an example embodiment.
  • an interoperable mobile wallet platform is provided that may be accessed by consumers that bank at various different banking institutions and by merchants that bank at various different banking institutions.
  • the mobile wallet client application 6 (or various branded variations thereof) may be offered through multiple banks and may utilize the services of multiple banks to complete transactions. Such an arrangement may promote broader adoption of the mobile banking platform by merchants and consumers.
  • a payment processing system 100 may include various computer systems such as a mobile device 1 , mobile wallet bank computer system 10 , messaging hub computer system 20 , recipient bank computer system 30 and merchant computer system 40 .
  • the computer system of a given banking institution may operate as the mobile wallet bank computer system in the context of some transactions and may operate as the recipient bank computer system in the context of other transactions.
  • the computer systems 1 , 10 , 30 , 40 and 50 may communicate with each other to complete transactions.
  • the connection of mobile device 1 is such that it does not communicate directly with the messaging hub computer system 20 or the recipient bank computer system 30 .
  • the mobile device 1 may be configured to communicate some information to the messaging hub computer system 20 and/or the recipient bank computer system 30 . Interconnections of the computer systems 1 , 20 , 30 , 40 and 50 will now be briefly described.
  • the mobile device 1 may be used by an individual user (e.g., a business owner or employee, a consumer, and so on) to create and interact with a mobile wallet account.
  • the mobile device 1 may, for example be, a handheld computer, a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, or other suitable device.
  • the mobile device 1 comprises a network interface logic 2 , a display device 4 , an input device 5 , and a mobile wallet client application 6 .
  • Network interface logic 2 may include, for example, program logic that connects the mobile device 1 to a network.
  • the mobile device 1 may receive and display screens including account information, transaction instructions, and so on.
  • such screens may be used to request username and password information. Such screens may also be used to prompt the user to provide information regarding the amount of the payment and which merchant or individual (e.g., name, address, phone number or e-mail, a selection of a recipient by the user from his memory or from by the user from the mobile device 1 , and so on) is to receive the payment. Such screens are presented to the user via the display device 4 .
  • the input device 5 may be used to permit the user to initiate account access and to facilitate receiving requested information from the user.
  • users may also be provided with the ability to access the payment processing system 100 using another type of computer (e.g., a desktop or laptop computer executing browser software) to perform the operations described herein as being performed by the mobile device 1 .
  • another type of computer e.g., a desktop or laptop computer executing browser software
  • the mobile wallet client application 6 may comprise program logic executable by the mobile device to implement at least some or all of the functions described herein. As will be appreciated, the level of functionality that resides on the mobile device 1 as opposed to the banking computer system 30 may vary depending on the implementation.
  • the client application 6 may be a web browser that is configured to receive and display mobile web pages (e.g. web pages prompting the user to provide information to create an account, web pages displaying account balance information and past transactions, and so on).
  • the mobile wallet client application 6 may also include a code/token generator capable of generating a unique code/token for each transaction. As described below, the unique code/token may then be transmitted by the mobile device 1 as part of a transaction to facilitate authentication of the transaction.
  • the user may also use other devices (e.g., laptop or desktop computer system, not shown) to create and access account.
  • the mobile wallet application 1 is used in connection with merchant computer system 40 located at a bricks and mortar store location.
  • the mobile wallet application 6 may also be used in connection with online merchant transactions.
  • merchants may be provided with the ability to have a mobile storefront and profile within the mobile wallet application 6 .
  • merchants may be provided with the ability to display marketing material, provide information, and promote products or discounts.
  • Merchants may also be provided with the ability to sell items directly through their mobile storefront for the account holder to purchase from within the mobile application 6 .
  • the mobile device 1 may include, in addition to the other features previously described, a code processing system 7 .
  • the code processing system 7 may include a code scanner (i.e. camera), and/or a code generator.
  • the code processing system 7 may receive a numerical code from the mobile wallet bank computer system 10 and generate an image that represents the received code on the display device 15 .
  • the code processing system 7 may receive a code from the mobile wallet bank computer system 10 .
  • the code processing system 7 may use a code/token generator as described in FIG. 1 .
  • the code generator 8 of the mobile device 1 may generate or receive a unique code for a transaction at a point of sale location. The unique code may identify the transaction number for the mobile wallet bank computer system 10 .
  • the code may be a dynamic token that remains valid for a single transaction, and/or a temporary period of time.
  • the code is a POS exchange code that is exchanged between a POS (Point of Sale) device 40 of the merchant and a mobile device 1 of the user in exchange for goods or services that are received by the user.
  • POS Point of Sale
  • the bank computer system 10 includes code/QR generator 11 , transaction verification logic 13 , code determination logic 15 , account database 17 , and profile database 19 .
  • the code generator 11 may receive a request from an account holder to initiate a transaction.
  • a transaction may be initiated by generating a QR code that can be scanned by a merchant or individual.
  • the account holder may access the code generator 11 via a mobile wallet application that is being executed on the mobile device 1 .
  • the QR code may be generated without the account holder providing the merchant's name or amount of transaction.
  • the code generator 11 can be configured to generate a QR code that incorporates at least one of a date, time, unique transaction identifier, and geographic location of the mobile device.
  • the code generators 11 and 18 can be configured to generate optically scanned or non-optically scanned codes.
  • optically scanned codes include bar codes, two dimensional codes (e.g. QR code and other similar codes), three dimensional codes (e.g. QR code with color and others characteristics), and four dimensional codes (e.g. QR code with color and timestamp information).
  • non-optically scanned codes may include, near field communication (NFC), RFID, HID or other RF signal to transmit the code.
  • the transaction verification logic 13 may receive a transaction amount from the messaging hub computer system 20 .
  • the transaction verification logic 13 may generate a message to send to the mobile device 1 for verifying the transaction amount.
  • the account holder via mobile device 1 may approve the transaction amount to the bank computer system 10 .
  • the account database 17 may store details regarding financial institution accounts. In particular, the account database 17 may store each financial transaction that occurred. Each financial transaction may include the amount of the transaction and the merchant. In some embodiments, the messaging hub computer system 20 stores account information for the user, so the account information is not received from the mobile wallet bank computer system 10 .
  • the profile database 19 may store other information regarding the account holder.
  • the profile database 19 may store information useful for generating offers and advertisements that are selected specifically for the account holder.
  • the messaging hub computer system 20 may also be operative to process the transaction between the two parties.
  • the mobile wallet bank computer system 10 is configured to communicate with the mobile device 1 and the messaging hub computer system 20 .
  • the content of the communication with the messaging hub computer system 20 may include account information regarding the user, confirmation of the code and approval/declining a transaction between the user of the mobile device 1 and a merchant.
  • the messaging hub computer system 20 is configured to communicate with one or more financial institutions that provide financial accounts to various individuals or merchants.
  • the messaging hub computer system 20 may include various components such as validator 21 discussed in greater detail below.
  • the messaging hub computer system 20 is configured to act as an intermediary between two financial institutions such as mobile wallet bank computer system 10 and recipient bank computer system 30 .
  • the messaging hub computer system 20 may act as a message router that is configured to assure that the correct information is transmitted to the correct financial institution to facilitate a transaction between two parties (e.g. a user and a merchant or a user and another user or between two merchants). Additionally, the messaging hub computer system 20 provides a single interface for each bank to communicate with a plurality of other banks.
  • the messaging hub computer system 20 may be a third party provided interface for one or more financial institutions.
  • the messaging hub computer system 20 may be provided by an exchange service that allows banks to transmit information securely between banks to process transactions where funds are transferred from one bank to another bank.
  • funds may be transferred from an account held by the user of the mobile device 1 to an account held by a merchant with a merchant computer system 30 .
  • the messaging hub computer system 20 includes a processor and a non-transitory memory that are configured to receive and transmit information between one or more financial institutions. The information received from a sending financial institution may identify the recipient financial institution.
  • the interface between the messaging hub computer system 20 and the financial institutions uses bank level security encryption to send and receive messages.
  • the validator 21 in the messaging hub computer system 20 , performs an initial validation of the code that is received from the recipient bank computer system 30 .
  • a portion of the received code may identify the financial institution that should receive the messages from the messaging hub computer system 20 .
  • the validator 21 may access stored information that correlates codes with electronic contact information for financial institutions.
  • a database may be used to determine the correlation between a portion of the code and a financial institution with which the code corresponds.
  • the validator 21 includes a comparator configured to compare the time provided by the merchant computer system 40 with the time provided via the QR code generated by the mobile device 1 . If the time provided by the QR code and the merchant computer system 40 exceeds a predetermined time limit (e.g., five minutes), the messaging hub computer system 20 will deny the transaction.
  • a predetermined time limit e.g., five minutes
  • the recipient bank computer system 30 includes network interface logic 32 , account processing logic 34 , and accounts database 36 .
  • bank account information e.g., routing number and/or account number
  • the financial institution that provides the mobile wallet account for the user and the financial institution that typically provides banking services to the user may be two different financial institutions.
  • the code generator 31 may receive a request for a code to provide to a merchant, the code being generated to be displayed on a merchant point of sale machine or an ecommerce website.
  • the merchant may display the code for the account holder to scan using a mobile device. Generating the code including embedding in the code a transaction identification number, a geographic location of the merchant, and a timestamp.
  • the financial institution may send the code to the merchant for the mobile device to scan.
  • the mobile device 1 may scan the code from a merchant display device.
  • the mobile device 1 may amend the code to add further authentication information to the code and send the code to the financial institution.
  • the financial institution may receive the amended code from the mobile device to transfer funds from an account held by the account holder to the merchant.
  • the requested funds are transferred to the merchant upon verifying the geographic location of the mobile device to be within a predetermined distance of the location of the merchant.
  • the amended code is amended to include authentication information (e.g. geographic location, account number, pass code, pin code) from the mobile device for the financial institution.
  • the merchant computer system 40 may be configured in generally the same manner as the other computer systems described herein.
  • the computer system 40 may be another mobile device, such as a handheld computer, cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, or other suitable device.
  • the fund recipient is a merchant (e.g., a brick and mortar merchant, a retail website or other online merchant, etc.)
  • the computer system 40 may comprise a point of sale (POS) device or other computer system (e.g., one or more servers each with one or more processors) configured to execute instructions, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with the fund recipient.
  • POS point of sale
  • the merchant computer system 40 may be used at a point of sale to conduct transaction with the account holder.
  • the merchant computer system 40 may comprise a point of sale computer system such as a cash register system connected to a central server system operated by the merchant.
  • the merchant computer system 40 may comprise a mobile computing device (e.g., smart phone, tablet PC, etc.) operated by a store clerk as the clerk moves throughout the store. Again, the mobile computing device in such an embodiment may connect to a central server system operated by the merchant.
  • the merchant computer system 40 includes code scanner 44 , fund requesting logic 48 , and fund receiving logic 49 .
  • the code scanner 44 may be configured to scan codes, such as but not limited to, optically scanned or non-optically scanned codes. Examples of optically scanned codes include bar codes, two dimensional codes (e.g. QR code and other similar codes), three dimensional codes (e.g. QR code with color and others characteristics), and four dimensional codes (e.g. QR code with color and timestamp information). Examples of non-optical codes include, near field communication (NFC), RFID, HID or other RF signal to transmit the code.
  • Code scanner 44 may include a light emitting device that scans a code using infrared, laser, or other types of communication technology. In one embodiment, the code scanner 44 scans a QR code. After scanning the QR code the QR code scanner 44 determines the information that was incorporated into the QR code by the mobile device 1 that generated the code.
  • the fund requesting logic 48 communicates a fund request to the recipient bank computer system 130 . In one embodiment, the fund requesting logic 48 also sends the amount of transaction to the financial transaction.
  • the merchant computer system 40 may further connect to or integrate with other hardware.
  • the merchant computer system 40 may connect to a card reader for reading credit cards, debit cards, stored value cards, and so on.
  • the merchant computer system 40 may be configured to prompt the user to provide a random security code.
  • the random security code may be generated by the mobile device 1 , by a separate security dongle, or in another manner.
  • the security code may be provided to the merchant computer system 40 directly by the mobile device, may be keyed into the merchant computer system (e.g., by a store clerk), or may be received in another manner.
  • the merchant may transmit the QR code to the recipient bank computer system 30 , as previously described.
  • the recipient bank computer system 30 may then return account information (e.g., a credit card number, debit card number, alternative payment type, demand deposit account, etc.) to backend servers associated with the merchant computer system 40 to permit the transaction to be processed in the same manner as a conventional credit card or debit card transaction. Other mechanisms for processing payments may also be used.
  • the recipient bank computer system 30 is configured to communicate with the merchant computer system 40 and the messaging hub computer system 20 .
  • the recipient bank computer system 30 is configured to receive funds to the financial institution of the user (e.g. mobile wallet bank computer system 10 ).
  • the recipient bank computer system 30 may be configured to communicate with the mobile device 1 and/or the mobile wallet bank computer system 10 .
  • the merchant computer system 40 is configured to communicate with the recipient bank computer system 30 and the mobile device 1 .
  • the merchant computer system 40 is configured to receive a code (e.g. QR code) and other information from the recipient bank computer system 30 .
  • the merchant computer system 40 may be configured to communicate with the mobile device 1 and/or the mobile wallet bank computer system 10 .
  • the interface between the merchant computer system 40 and the recipient bank computer system 30 uses bank level security encryption to send and receive messages.
  • the issuing bank computer system 50 is operative to transfer funds from the demand deposit account held by the user to the recipient bank computer system 30 under the direction of the recipient bank compute system 30 or the messaging hub computer system 20 .
  • the issuing bank computer system 50 may be configured to communicate via a network with the messaging hub computer system 20 , the mobile wallet bank computer system 10 and the recipient bank computer system 30 .
  • the issuing bank computer system 50 is configured to receive funds from various mobile wallet bank computer systems 10 and transmit the funds to the appropriate recipient bank computer systems 30 .
  • the issuing bank computer system 50 may include an account processing logic 52 that determines which user has a credit card account and an account database that store information regarding user accounts. In other embodiments, the issuing bank computer system 50 is configured to be a registry information provider.
  • the registry information may include an identifier for the user mobile wallet account and the registry information such as the user default account number may be provided to the messaging hub computer system 20 .
  • the registry information may include other information that allows the messaging hub computer system 50 to obtain the account information from another financial institution.
  • FIG. 2 a depicts a first process for completing a transaction that may be implemented by the payment processing system of FIG. 2 a .
  • the two parties to the transaction in FIG. 2 a are a user of mobile wallet application 6 (e.g., consumer) and a merchant. Again, as above, it will be appreciated that other types of transactions may be possible.
  • the user may provide input to the POS (Point of Sale) device 40 .
  • POS Point of Sale
  • a user purchasing merchandise at a bricks and mortar merchant may be at a checkout counter or other type of POS arrangement.
  • the user may be presented with a series of payment options at the POS device 40 (e.g., credit card, debit card, mobile, and so on).
  • the user may select a payment type (here, “mobile”) to pay for goods or services, and the POS device 40 may receive the selection of the payment option.
  • a payment type here, “mobile”
  • the user may access the mobile wallet application 6 on mobile device 1 and select a “pay now” or similar option on the mobile device.
  • the mobile wallet application 6 may also offer the user various payment types (e.g., various credit cards, debit cards, alternative payment type, demand deposit account and so on).
  • the user may have pre-specified a default payment type that may be used.
  • the mobile device 1 may receive the user input and initiate communication with the mobile wallet bank computer system 10 .
  • the mobile device 1 may send a request to the mobile wallet bank computer system 10 for a code that may be used to identify the transaction that will occur between the user and the POS device 40 .
  • the request to the mobile wallet bank computer system 10 includes the wallet platform ID (WPI) that identifies a unique identification number for the wallet and/or the version of the wallet application that is being used.
  • the message that is transmitted may include information identifying the user (e.g., a device identifier for the mobile device 1 , a unique identifier (e.g., wallet user ID (WUI)) associated with the mobile wallet application 6 when installed by the user, etc.). Information regarding the payment type selected by the user may also be sent.
  • the mobile wallet bank computer system 10 may be configured to receive requests directly from the mobile device 1 for codes or other information.
  • the mobile wallet bank computer system 10 may generate a random code or sequential code as described above, e.g., in connection with FIG. 1 .
  • the code may represent a unique identifier (e.g., dynamic token (DT)) for the transaction that is about to be completed between the user and the merchant.
  • the code may also include a transaction identifier and verification codes that identify the mobile wallet bank computer system 10 to the messaging hub computer system 20 when the code is received by the messaging hub computer system 20 .
  • the code may include a trace ID (TID) which is part of the dynamic token and is used by the issuing bank for security and matching purposes.
  • the mobile wallet bank computer system 10 may generate a code based on a standard that the messaging hub computer system 20 can decode and understand.
  • the mobile device 1 may process the code using the code processing system 7 .
  • the code may be sent over a wireless link between the mobile device 1 and the mobile wallet bank computer system 10 .
  • the code may be sent as a numeric code.
  • the code processing system 7 may be configured to convert the code into a displayable image that may be scanned by the POS device 40 .
  • the code may be sent as an image (e.g., QR code or bar code).
  • the mobile device 1 may generate a display and the POS device 40 may optically scan the displayed code.
  • the code and a merchant identification number (e.g., Merchant ID (MID) that represents a unique identifier for the merchant that is tied the merchant registry information in the messaging hub computer system 20 ) from the POS device 40 is transmitted to the recipient bank computer system 30 .
  • the recipient bank computer system 30 may be configured to transmit the code and the merchant identification number to the messaging hub computer system 20 .
  • the messaging hub computer system 20 may perform an initial validation of the code and then decode it to determine the banking institution (e.g., issuer identifier (II) or wallet platform ID (WPI)) with which it is associated (i.e., to determine which banking institution generated the code).
  • the code or a portion of the code (e.g., TID) may be matched with a number that identifies the banking institution (e.g., the last three or four digits may be used to access a lookup table).
  • the code and the merchant identification number is sent to the mobile wallet bank computer system 10 .
  • the mobile wallet bank computer system 10 confirms the code's validity. Details of the code (TID) may be compared against codes previously generated by the mobile wallet bank computer system 10 (in this example, the code is the same as that generated in step 204 ). Additionally, the mobile wallet bank computer system 10 may confirm that the code has not expired. For example, the code that was originally generated at step 204 may expire within a predetermined period of time, such as, 15 minutes, 10 minutes, 5 minutes, or another period of time. Also, the mobile wallet bank computer system 10 may confirm that the code has not already been used for another transaction.
  • the mobile wallet bank computer system 10 transmits the messaging hub computer system 20 payment information (e.g. account information) for the payment account to be used for the transaction.
  • the payment information may be the payment identifier (PI) in one embodiment.
  • PI payment identifier
  • the mobile wallet bank computer system 10 may send stored merchant loyalty information to the messaging hub computer system 20 .
  • the messaging hub computer system 20 transmits the payment information and the loyalty information to the recipient bank computer system 30 .
  • the recipient bank system 30 transmits the loyalty information to the POS device 40 .
  • the POS device 40 uses the loyalty information to calculate the final transaction amount and transmits the transaction amount to the recipient bank computer system 30 .
  • the recipient bank system 30 processes the transaction using the payment information received from the messaging hub computer system 20 . For example, if a credit card number is received, the recipient bank system 30 may submit the credit card transaction for approval and the credit card transaction may be processed as a standard four party credit card transaction between a customer, a merchant, an issuing bank and an acquiring bank.
  • the recipient bank system 30 provides an indication whether the transaction is approved or declined to the POS device 40 .
  • the POS device 40 prints a receipt for the user.
  • the user may opt via the mobile wallet application 6 to have the receipt sent electronically to the mobile device 1 via the messaging hub computer system 20 .
  • the recipient bank system 30 provides an indication whether the transaction is approved or declined to the mobile wallet bank computer system 10 through the messaging hub computer system 20 .
  • the mobile wallet bank computer system 10 sends a notification to the mobile wallet application. Based on this information, a message may be displayed to the user via the mobile device 1 at the point of sale indicating whether the transaction was approved or declined.
  • each message that is transmitted for steps 201 to 217 includes the code to identify the transaction.
  • the banks computer systems 10 and 30 and the messaging hub computer system 20 may receive the sensitive account information (e.g., credit card number) during the various steps discussed herein, however, the POS device 40 or the mobile device 1 need not receive the user's account information. Hence, account security may be enhanced.
  • the messaging hub computer system 20 facilitates a secure transmission of sensitive information and aids the banks by providing a single point of contact. Moreover, the messaging hub computer system 20 creates a messaging format that each banking entity must comply with for the messages.
  • a code is generated on the display of the mobile device 110 and the code is displayed for optical scanning by the POS device 40 .
  • the user presents the mobile device for scanning at the time of sale, creating a user experience for the user that is somewhat similar to presentation of a credit card.
  • FIG. 2 b is a process implemented by the payment processing system.
  • the credit card issuer bank is different than the mobile wallet application provider.
  • FIGS. 2 b and 3 b for simplicity mobile device 1 and mobile wallet bank computer system 10 are shown as being combined, but it will be appreciated that they operate in a manner that is similar to FIGS. 2 a , and 3 a .
  • Table 2 below describes the messages that are transmitted in various steps and the content of the messages.
  • Table 2 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIGS. 2 b and 3 b .
  • the messaging hub that is referred to in Table 2 is the messaging hub computer system 20 from FIGS.
  • the beta issuer that is referred to in Table 2 may operate or signify the card issuer computer system 50 from FIGS. 2 b and 3 b .
  • the POS scanner referred to in Table 2 is shown in FIGS. 2 b and 3 b as POS device 40 .
  • the recipient bank computer 30 shown in FIGS. 2 b and 3 b is discussed in Table 2 as the gamma acquirer.
  • the steps from FIG. 3 b may use similar messages and routing as shown in FIG. 2 b .
  • the POS device 40 initiates the process of FIG. 3 b .
  • the steps shown in FIG. 3 b transmit similar data as the step described for FIG. 2 b .
  • Dynamic Token makes a request for a provider (DT) Dynamic token using a previously provisioned Payment Identifier User selects Payment Identifier associated with the underlying payment method 252 - Dynamic Alpha Wallet sends II: Issuer WUI: PI: Payment Token (DT) request for Dynamic Identifier Wallet Identifier request sent to Token to the User Info Messaging Hub Messaging Hub WPI: (MH) Wallet Platform Info 253 - Dynamic Messaging Hub (MH) II: Issuer WUI: PI: Payment Token (DT) passes request for Identifier Wallet Identifier request sent to Dynamic Token (DT) User Info Beta Issuer to the appropriate Wallet Issuer.
  • DT Payment Token
  • DT passes request for Identifier Wallet Identifier request sent to Dynamic Token (DT) User Info Beta Issuer to the appropriate Wallet Issuer.
  • WPI Platform Info 254 - Beta issuer Beta issuer generates a WUI: II: Issuer DT: Dynamic generates Dynamic Token in Wallet User Identifier Token.
  • Dynamic Token Track 1 or 2 format Info and sends back to and sends it back to the WPI: the MH MH (Messaging Hub) Wallet (Messaging Hub)
  • the Dynamic Token is Platform in Track 1 or Track 2 Info format and includes issuer specific info, dynamic data and the last 4 digits of the underlying payment type 255 - MH sends MH sends the WUI: II: Issuer DT: Dynamic the Dynamic Dynamic Token (DT) Wallet User Identifier Token Token (DT) to the to the Alpha Wallet.
  • Alpha Wallet WPI Wallet Platform Info 256 - POS Scanner
  • the Alpha Wallet will via scan via scan DT: Dynamic reads or accepts either display the Token the DT Dynamic Token as a QR Code for scanning by the POS or transmit the Dynamic Token to the POS via other communication methods.
  • Dynamic Token 260 - Beta Issuer Beta issuer matches ACN/UPC: confirms the DT's the DT to the original Actual Card validity and PI that was associated Number/ retrieves the actual with the DT and then Underlying card determines the Payment number/underlying underlying payment Credential payment credential credential 261 - Beta Issuer AID: II: Issuer ACN/UPC: sends the Acquirer ID Identifier Actual Card ACN/UPC to the MID: Number/ MH Merchant ID Underlying Payment Credential Trace ID: A subset of the DT for the transaction that is used for issuer security and matching 262 - MH Sends MH looks at the AID AID: II: Issuer ACN/UPC: the ACN/UPC to associated with the Acquirer ID Identifier Actual Card the Gamma message and sends the MID: Number/ Acquirer along ACN/UPC to the Merchant ID Underlying with a Trace ID.
  • Payment Credential Trace ID A subset of the DT for the transaction that is used for issuer security and matching 263 - Gamma Gamma Acquirer
  • ACN/UPC Acquirer processes payment Actual Card processes payment using the ACN/UPC Number/ using the via its existing process Underlying ACN/UPC and includes the Trace Payment ID for issuer matching Credential and security.
  • Approve/Decline Acquirer sends Approval/Decline to the POS 265 - POS prints Existing process Approve/Decline receipt as normal 266 - Gamma Gamma Acquirer II: Issuer AID: Approve/Decline Acquirer sends sends Identifier Acquirer ID Approval/Decline Approval/Decline to MID: to MH MH based upon the II Merchant ID 267 - MH sends MH sends II: Issuer AID: Approve/Decline Approval/Decline Approval/Decline to Identifier Acquirer ID to the Alpha the Alpha Wallet based MID: Wallet upon the II Merchant ID 268 - Alpha Alpha Wallets sends Wallets sends an an email and push email and push notification to the notification to the Alpha Wallet User Alpha Wallet User
  • FIG. 3 a is a process implemented by the payment processing system.
  • a code (DT) is generated and displayed by the POS device 40 and optically scanned by the mobile device 1 .
  • Such an arrangement avoids the need for the POS device 40 to include a scanner.
  • the user may select using a mobile device 1 as a payment option at the POS device 40 .
  • the POS device 40 Upon receiving the user input, the POS device 40 sends a request to the recipient bank system 30 , specifically, a request for a numerical code (DT), a QR code or other code as described herein.
  • the recipient bank system 30 creates the code (e.g. numerical, barcode, or QR code, etc.).
  • the recipient bank system 30 may send the code to POS device 40 for display on POS terminal screen or printed on a receipt.
  • the mobile device 1 may receive the code by using a camera.
  • a user may access the mobile wallet application in the mobile device 1 and request that a payment be made.
  • the mobile device 1 may transmit the code to the mobile wallet bank 10 at step 304 .
  • the mobile wallet bank computer system 10 sends the code to the messaging hub computer system 20 .
  • the code may identify the merchant using merchant identifier and merchant registry information (MRI).
  • the messaging hub computer system 20 at step 306 , sends the code to the recipient bank system 30 .
  • the recipient bank system 30 determines the validity of the code and also determines the whether the codes is expired, not previously used, etc.
  • the recipient bank system 30 accesses the database and determines the merchant identification for the (POS ID and/or MID) POS device 40 .
  • the merchant identification is transmitted from the recipient bank system 30 to the messaging hub computer system 20 and the messaging hub computer system 20 transmits the merchant identification to the mobile wallet bank computer system 10 .
  • the mobile wallet bank computer system 10 receives the merchant identification and the transaction code.
  • the mobile wallet bank computer system 10 sends the payment information regarding user payment account and any stored merchant loyalty information to the recipient bank system 30 through the messaging hub computer system 20 .
  • the recipient bank system 30 may transmit the loyalty information to the POS device 40 to be displayed for the user.
  • the final transaction amount is determined by the POS device 40 and transmitted to the recipient bank computer system 40 .
  • the recipient bank system 30 receives the transaction amount and processes the transaction using the payment information that the recipient bank system 30 received from the mobile wallet bank computer system 10 , at step 311 .
  • the recipient bank system 30 also determines whether the transaction is approved or denied.
  • the approval or denial is transmitted to the POS device 40 .
  • the POS device 40 prints a receipt or sends a receipt to the user.
  • the recipient bank system 30 sends an approval and/or decline message to the mobile wallet bank 10 via a messaging hub computer system 20 .
  • the mobile wallet bank system 10 transmits a notification to the mobile device 110 to inform the mobile device 110 regarding the approval or decline decisions at step 315 .
  • FIG. 3 b is a process implemented by the payment processing system.
  • Table 2 above describes the messages that are transmitted in various steps and the content of the messages.
  • Table 2 refers to the steps from FIG. 2 a .
  • the steps from FIG. 3 b may use similar messages and routing as shown in FIG. 2 a .
  • FIG. 3 b illustrates a process implemented by the payment processing system of FIG. 1 .
  • the credit card issuer bank is a separate entity than the mobile wallet application provider.
  • Table 4 below describes the messages that are transmitted in various steps and the content of the messages.
  • the process of FIG. 7 is initiated by the POS device 40 by initiating the transaction request for the code.
  • the steps shown in FIG. 7 transmit similar data as the step described for FIG. 6 .
  • the recipient bank system 30 receives the credit card number of the user, submits the credit card transaction for approval, and the credit card transaction is processed as a standard four party credit card transaction between a customer, a merchant, an issuing bank and an acquiring bank.
  • the messaging hub computer system 20 operates to communicate information between the mobile wallet bank computer system 10 and the recipient bank computer system 30 .
  • a demand deposit account is used as a source of funds and the messaging hub computer system 20 may facilitate processing of the transaction by transmitting information about demand deposit accounts held by the sender and the recipient.
  • a demand deposit account is an account in which deposits can be “demanded” by an account holder at any time. Funds in a demand deposit account can be withdrawn at any time without any advance notice to the depository or financial institution. For example, many checking and savings accounts are demand deposits and are accessible by the account holder through a variety of banking options, including teller, ATM and online banking. In contrast, a term deposit is a type of account that cannot be accessed for a predetermined period (typically the loan's term). Demand deposit accounts may have features such as no maturity period (or an original maturity of fewer than seven days), payable on demand, may be interest bearing, no limit on the number of withdrawals or transfers an account holder may make, and no eligibility requirements.
  • various entities may charge fees, to the user, the merchant or the bank, in order to use the funds in a demand deposit account at a point of sale location. For example, when the user uses a debit card to access their funds, the user may be charged a debit card fee by the bank. In another example, when the user uses a debit card through an open loop payment processor, the merchant and/or the bank may be charged a fee in connection with the transaction. Systems and methods described herein may in some cases reduce the fees charged to the user, the merchant or the bank.
  • FIG. 4 illustrates another method for completing a transaction that is implemented by the payment processing system of FIG. 1 .
  • the two parties to the transaction in FIG. 4 are a user of mobile wallet application 6 (e.g., consumer) and a merchant.
  • the merchant may also be using a mobile wallet application that is the same or similar to the mobile wallet application that is being used by the consumer.
  • mobile wallet application 6 e.g., consumer
  • the merchant may also be using a mobile wallet application that is the same or similar to the mobile wallet application that is being used by the consumer.
  • other types of transactions may be possible.
  • the user may provide input to the POS device 401 .
  • a user purchasing merchandise at a merchant location may be at a checkout counter or other type of POS arrangement.
  • the user may be presented with a series of payment options at the POS device 40 (e.g., credit card, debit card, mobile device, and so on).
  • the user selects a payment type (here, “mobile”) to pay for goods or services, and the POS 40 receives the selection of the payment option.
  • a payment type here, “mobile”
  • the user may access the mobile wallet application 6 on the mobile device 1 and select a “pay now” or similar option on the mobile device.
  • the mobile wallet application 6 may also offer the user various payment types (e.g., various credit cards, debit cards, alternative payment type, demand deposit account, bank account, money market account and so on).
  • the user may have pre-specified a default payment type that may be used prior to the transaction being initiated by the POS device 40 or the user reaching the POS device 40 .
  • a profile may be stored on the mobile device 1 or the mobile wallet bank computer system 10 .
  • the profile may store a priority of payment types, for example, in the most preferred to the least preferred option.
  • the payment option chosen by the user may be a demand deposit account that is provided by a financial institution.
  • the mobile wallet bank may provide the demand deposit account.
  • another financial institution e.g. other bank 1 , other bank 2 , etc.
  • the mobile wallet bank may store identification information for the demand deposit account, such as but not limited to, the routing number, bank account number and other account identification information.
  • the mobile device 1 may receive the user input and initiate communication with the mobile wallet bank computer system 10 .
  • the mobile device 1 may send a request to the mobile wallet bank computer system 10 for a code that may be used to identify the transaction that will occur between the user and the owner of the POS device 40 .
  • the message that is transmitted may include information identifying the user (e.g., a device identifier for the mobile device 1 , a unique identifier associated with the mobile wallet application 6 when installed by the user, etc.). Information regarding the payment type selected by the user may also be sent.
  • the mobile wallet bank computer system 10 may be configured to receive requests directly from the mobile device 1 for codes and/or other information.
  • the mobile wallet bank computer system 10 may generate a random code or sequential code as described above, e.g., in connection with FIG. 1 .
  • the code may represent a unique identifier for the transaction that is about to be completed between the user and the merchant.
  • the code may also include a transaction identifier and verification codes that identify the mobile wallet bank computer system 10 to the messaging hub computer system 20 when the code is received by the messaging hub computer system 20 .
  • the mobile wallet bank computer system 10 may generate a code based on a standard that the messaging hub computer system 20 can decode and determine which entity to communicate with next.
  • the code may represent a coded version of the demand deposit account information (i.e. routing number and account number) that may be decoded by the messaging hub computer system 20 using a key that is embedded within a decodable version of the code.
  • the mobile device 1 may process the code using the code processing system 7 .
  • the code may be sent over a wired or wireless link between the mobile device 1 and the mobile wallet bank computer system 10 .
  • the code may be sent as a numeric code and transformed into a QR code for display purposes.
  • the code processing system 7 may be configured to convert the code into a displayable image that may be scanned by the POS device 40 .
  • the code may be sent as an image (e.g., QR code or bar code).
  • the mobile device 1 may generate a display and the POS device 40 may optically scan the displayed code.
  • the recipient bank computer system 30 may be configured to transmit the code and the merchant identification number to the messaging hub computer system 20 .
  • the messaging hub computer system 20 may perform an initial validation of the code and then decode it to determine the banking institution with which it is associated (i.e., to determine which banking institution generated the code).
  • the code or a portion of the code may be matched with a number that identifies the banking institution (e.g., the last three or four digits may be used to access a lookup table).
  • the code and the merchant identification number is sent to the mobile wallet bank computer system 10 .
  • the mobile wallet bank computer system 10 confirms the code's validity. Details of the code may be compared against codes that were previously generated by the mobile wallet bank computer system 10 (in this example, the code is the same as the code that was generated in step 404 ). Additionally, the mobile wallet bank computer system 10 may confirm that the code has not expired. For example, the code that was originally generated at step 404 may expire within a predetermined period of time, such as, 15 minutes, 10 minutes, 5 minutes, 3 minutes or another period of time. The mobile wallet bank computer system 10 maintains a record of the time when each code was generated.
  • the mobile wallet bank computer system 10 When the mobile wallet bank computer system 10 receives the code from the messaging hub computer system 20 or another entity, the mobile wallet bank computer system 10 compares the time the code was generated and the time when the code was received from the messaging hub computer system 20 . In some embodiments, the mobile wallet bank computer system 10 provides the time the code was generated to the messaging hub computer system 20 and the messaging hub computer system 20 may perform the time comparison. Also, the mobile wallet bank computer system 10 may confirm that the code has not already been used for another transaction.
  • the mobile wallet bank computer system 10 transmits the payment information (e.g. account information) to the messaging hub computer system 20 .
  • the payment information may include the routing number and the account number for the demand deposit account to be used for the transaction.
  • the mobile wallet bank computer system 10 may send stored merchant loyalty information to the messaging hub computer system 20 .
  • the user account and loyalty information is stored in a database maintained at the messaging hub computer system 20 , and the mobile wallet computer system 10 is not accessed by the messaging hub computer system 20 for this information.
  • the messaging hub computer system 20 may transmit the payment information and the loyalty information to the recipient bank computer system 30 .
  • the recipient bank system 30 transmits the loyalty information to the POS device 40 .
  • the POS device 40 uses the loyalty information to calculate the final transaction amount and transmits the transaction amount to the recipient bank computer system 40 .
  • the messaging hub computer system 20 triggers the transaction to occur between the user identified or chosen demand deposit account and the recipient bank computer system 30 (e.g., merchant demand deposit account).
  • the messaging hub computer system 20 may receive the purchase amount and the registry information for both the user demand deposit account and the recipient's bank account.
  • the messaging hub computer system 20 may transfer funds from the demand deposit account to the recipient bank account.
  • the recipient bank system 30 processes the transaction using the payment information received from the messaging hub computer system 20 . For example, when the demand deposit account information is received, the recipient bank system 30 may submit the transaction for approval to the ACH processing system to process the transaction between a customer, a merchant, an issuing bank and an acquiring bank.
  • the messaging hub computer system 20 provides an indication whether the transaction is approved or declined to the POS device 40 via recipient bank computer system 30 .
  • the POS device 40 prints a receipt for the user.
  • the user may choose via the mobile wallet application 6 to have the receipt sent electronically to the mobile device 1 via the messaging hub computer system 20 .
  • the messaging hub computer system 20 sends an indication whether the transaction is approved or declined to the mobile wallet bank computer system 10 .
  • the mobile wallet bank computer system 10 sends a notification to the mobile wallet application 6 . Based on this information, a message may be displayed to the user via the mobile device 1 at the point of sale indicating whether the transaction was approved or declined.
  • each message that is transmitted for steps 401 to 417 includes the code to identify the transaction.
  • the banks computer systems 10 and 30 and the messaging hub computer system 20 may receive the sensitive account information (e.g., demand deposit account information) during the various steps discussed herein, however, the POS device 40 or the mobile device 1 need not receive the user's account information. Hence, account security may be enhanced.
  • the messaging hub computer system 20 facilitates a secure transmission of sensitive information and aids the banks by providing a single point of contact.
  • the messaging hub computer system 20 creates a messaging format that each banking entity must comply with for transmitting messages.
  • a code is generated on the display of the mobile device 1 and the code is displayed for optical scanning by the POS device 40 .
  • the user presents the mobile device for scanning at the time of sale, creating a user experience for the user that is somewhat similar to presentation of a credit card.
  • FIG. 5 is a process implemented by the payment processing system 100 .
  • a code is generated and displayed by the POS device 40 and optically scanned by the mobile device 1 .
  • Such an arrangement avoids the need for the POS device 40 to include a scanner.
  • the user may select using a mobile device 1 as a payment option at the POS device 40 .
  • the POS device 40 Upon receiving the user input, the POS device 40 sends a request to the recipient bank system 30 , specifically, a request for a numerical code, a QR code, an RFID code, a near field communication code or other code as described herein.
  • the recipient bank system 30 creates the code (e.g. numerical, barcode, or QR code, etc.).
  • the recipient bank system 30 may send the code to POS device 40 for display on POS terminal screen or printed on a receipt.
  • the mobile device 1 may receive the code by using a camera.
  • a user may access the mobile wallet application in the mobile device 1 and request that a payment is made.
  • the mobile device 1 may transmit the code to the mobile wallet bank 10 at step 504 .
  • the mobile wallet bank computer system 10 sends the code to the messaging hub computer system 20 .
  • the messaging hub computer system 20 at step 506 , sends the code to the recipient bank system 30 .
  • the recipient bank system 30 determines the validity of the code and also determines the whether the codes is expired, not previously used, etc.
  • the recipient bank system 30 accesses the database and determines the merchant identification for the POS device 40 .
  • the merchant identification is transmitted from the recipient bank system 30 to the messaging hub computer system 20 and the messaging hub computer system 20 transmits the merchant identification to the mobile wallet bank computer system 10 .
  • the mobile wallet bank computer system 10 receives the merchant identification and the transaction code.
  • the mobile wallet bank computer system 10 sends the payment information regarding user demand deposit account and any stored merchant loyalty information to the messaging hub computer system 20 .
  • the recipient bank system 30 may transmit the loyalty information to the POS device 40 to be displayed for the user.
  • the final transaction amount is determined by the POS device 40 and transmitted to the recipient bank computer system 40 .
  • the POS device 40 and the recipient bank computer system 40 may transmit the final transaction amount to the messaging hub computer system 20 , at step 510 .
  • the messaging hub computer system 20 may process the transaction between the user identified demand deposit account and the merchant demand deposit account after receiving the transaction amount, at step 511 .
  • the messaging hub computer system 20 may receive the funds equaling the transaction amount from the demand deposit account of the user.
  • the received funds may be transferred to the recipient bank demand deposit account.
  • the funds may be transferred using an ACH process to the demand deposit account held by the recipient.
  • the messaging hub computer system 20 sends the approval or denial is transmitted to the POS device 40 .
  • the POS device 40 prints a receipt or sends a receipt to the user.
  • the recipient bank system 30 sends an approval and/or decline message to the mobile wallet bank 10 via a messaging hub computer system 20 .
  • the mobile wallet bank system 10 transmits a notification to inform the mobile device 1 regarding the approval or denial decisions at step 515 .
  • FIG. 6 illustrates a process implemented by the payment processing system of FIG. 1 .
  • the credit card issuer bank is different than the mobile wallet application provider.
  • FIGS. 6 and 7 for simplicity mobile device 1 and mobile wallet bank computer system 10 are shown as being combined, but it will be appreciated that they operate in a manner that is similar to FIGS. 4, and 5 .
  • Table 3 below describes the messages that are transmitted in various steps and the content of the messages from FIG. 6 .
  • FIG. 7 illustrates a process implemented by the payment processing system of FIG. 1 . Table 3 refers to the steps from FIG. 6 . However, the steps from FIG. 7 may use similar messages and routing as shown in FIG. 6 . In the embodiment shown in FIGS.
  • the credit card issuer bank is a separate entity than the mobile wallet application provider.
  • the POS device 40 initiates the process of FIG. 7 .
  • the steps shown in FIG. 7 transmit similar data as the step described for FIG. 6 .
  • Table 3 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIGS. 6 and 7 .
  • the messaging hub that is referred to in Table 3 has the messaging hub computer system 20 from FIGS. 6 and 7 .
  • the beta issuer that is referred to in Table 3 may operate or signify the card issuer computer system 50 from FIGS. 6 and 7 .
  • the POS scanner referred to in Table 3 is shown in FIGS. 6 and 7 as POS device 40 .
  • the recipient bank computer 30 shown in FIGS. 6 and 7 is discussed in Table 3 as the gamma acquirer.
  • WPI: Wallet Platform Info 604 - Beta issuer Beta issuer generates a WUI: Wallet II: Issuer DT: Dynamic generates Dynamic Token in User Info Identifier Token.
  • Dynamic Token Track 1 or 2 format and WPI Wallet and sends back to sends it back to the MH Platform Info the MH (Messaging Hub) (Messaging The Dynamic Token is in Hub) Track 1 or Track 2 format and includes issuer specific info, dynamic data and the last 4 digits of the underlying payment type. 605 - MH sends MH sends the Dynamic WUI: Wallet II: Issuer DT: Dynamic the Dynamic Token (DT) to the Alpha User Info Identifier Token Token (DT) to Wallet.
  • WPI Wallet the Alpha Wallet Platform Info 606 - POS
  • the Alpha Wallet will via scan via scan DT: Dynamic Scanner reads or either display the Token accepts the DT Dynamic Token as a QR Code for scanning by the POS or transmit the Dynamic Token to the POS via other communication methods.
  • Token Merchant ID 610 - Beta Issuer Beta issuer matches the CRI: confirms the DT to the original PI that Consumer's DT's validity and was associated with the Registry Info retrieves the DT and then identifies Consumer's the Consumer's Registry Registry Info Info 611 - Beta Issuer AID: II: Issuer CRI: sends the Acquirer ID Identifier Consumer's Consumer's MID: Registry Info Registry Info to Merchant ID the MH 612 - MH MH triggers money triggers money movement from the movement Consumer's DDA to the Merchant's DDA upon knowing the Final Purchase Amount, the CRI and the MRI. This is where the money movement occurs.
  • FIG. 8 illustrates a process implemented by the payment processing system of FIG. 1 to process a refund transaction between a user and a merchant.
  • the credit card issuer bank is different than the mobile wallet application provider.
  • Table 4 below describes the messages that are transmitted in various steps and the content of the messages from FIG. 8 .
  • Table 4 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIG. 8 .
  • the messaging hub that is referred to in Table 4 has the messaging hub computer system 20 from FIG. 8 .
  • the beta issuer that is referred to in Table 4 may operate or signify the card issuer computer system 50 from FIG. 8 .
  • the POS scanner referred to in Table 4 is shown in FIG. 8 as POS device 40 .
  • the recipient bank computer 30 shown in FIG. 8 is discussed in Table 4 as the gamma acquirer.
  • POS sends POS will send the II: Issuer MID: PUDT the refund amount Previously Used Dynamic Identifier Merchant and PUDT to Token (Track 1 or 2 Data) as part of ID Gamma Acquirer to its existing the PUDT acquirer/processor. This will be flagged as a refund transaction.
  • 804 - Gamma The Gamma Acquirer reads II: Issuer AID: PUDT Acquirer sends the II as part of the PUDT Identifier Acquirer PUDT to CE and sends the PUDT to the as part of ID CE. the PUDT MID: This will be flagged as a Dynamic Merchant refund transaction.
  • Token ID 805 - CE receives The CE reads the II as part II: Issuer AID: PUDT DT and routes to of the PUDT, recognizes it Identifier Acquirer the Beta Issuer as a Beta II and sends the as part of ID PUDT to the Beta Issuer. the PUDT MID: This will be flagged as a Merchant refund transaction.
  • ID 806 - Beta Issuer Beta issuer matches the n/a n/a ACN/UPC: confirms the PUDT to the original PI that Actual Card PUDT's validity was associated with the Number/ and retrieves the PUDT and then determines Underlying actual card the underlying payment Payment number/underlying credential.
  • Credential payment credential This will be flagged as a that was used for refund transaction. the initial purchase. 807 - Beta Issuer AID: II: Issuer ACN/UPC: sends the Acquirer ID Identifier Actual Card ACN/UPC to the MID: Number/ CE Merchant Underlying ID Payment Credential 808 - CE Sends the CE looks at the AID AID: II: Issuer ACN/UPC: ACN/UPC to the associated with the message Acquirer ID Identifier Actual Card Gamma Acquirer and sends the ACN/UPC to MID: Number/ the appropriate acquirer.
  • the arrangement shown in FIG. 8 includes mobile device 1 , messaging hub 20 , recipient bank computer 30 , POS device 40 , and card issuer computer system 50 .
  • the mobile device 1 may be operated by a user to request a previously used dynamic token that was used to complete a transaction, e.g., between the user and a recipient merchant.
  • the user may be presented with a display that shows previous transactions that the user of the mobile device 1 has transacted. The user may select one of the previous transactions in order to identify the dynamic token to be requested.
  • the user may be provided with the ability to search for the transaction, e.g., by searching for the name of the recipient merchant, by searching for transaction amounts within a specified dollar range, by scrolling through a historical list of transactions, or by searching using another criterion.
  • the previously used dynamic tokens may be stored on the mobile device 1 , the mobile wallet bank computer system 10 , the messaging hub 20 , or in another location. Once the previous transaction is identified, the previously used dynamic token for the identified transaction may be retrieved from the memory of the mobile device 1 , storage of the mobile wallet bank computer system 10 or the messaging hub 20 , depending on where the dynamic token is stored. In various embodiments, for each previous transaction, if the associated dynamic token is not stored on the mobile device 1 or a cloud based storage that is accessible by the mobile device 1 , then the location of the dynamic token is stored on the mobile device 1 or the cloud based storage.
  • the POS device 40 may be set to refund mode to read or accept the previously used dynamic token.
  • the mobile device 1 may communicate the previously used dynamic token to the POS device 40 .
  • the mobile device 1 may display the previously used dynamic token as a QR code for a scan by the POS device 40 or transmit the dynamic token to the POS device 40 via other means of communications.
  • Such other communication methods may include, for example, near field communication (NFC), Bluetooth, Hypersonic or other communication technologies.
  • the message routing information in step 802 may be the previously used dynamic token being scanned or transmitted by or from the POS scanner 40 or the mobile device 1 .
  • the POS device 40 may send the previously used dynamic token to the recipient bank computer 30 .
  • the POS device 40 may determine the amount of funds that were transferred using the previously used dynamic token. In some embodiments, determining the amount of funds may include accessing a database using the previously used dynamic token to identify a transaction and retrieving the transaction amount from the database.
  • the transaction amount and the previously used dynamic token may be sent to the recipient bank computer 30 in a message that identifies the transaction as being a refund transaction.
  • the previously used dynamic token may comprise track 1 and track 2 data.
  • the message to the recipient bank computer 30 may include a merchant identifier and an issuer identifier that identifies the issuer of the credit card that was used for the original transaction. In some embodiments, the issuer identifier may be part of the previously used dynamic token.
  • the recipient bank computer 30 may send the previously used dynamic token including the issuer identifier to the messaging hub 20 .
  • the information that is sent to the messaging hub 20 may include an acquirer identifier and a merchant identifier from the recipient bank computer 30 . Providing the acquirer identifier and the merchant identifier allows the messaging hub 20 to identify the recipient bank computer 30 when sending the refund at step 808 .
  • the messaging hub 20 receives the previously used dynamic token and routes the previously used dynamic token to the card issuer computer system 50 .
  • the messaging hub 20 determines the identity of the card issuer computer system 50 .
  • the messaging hub 20 reads a portion of the previously used dynamic token to determine which card issuer computer system 50 should receive the dynamic token.
  • the messaging hub 20 may additionally flag the transaction as a refund transaction to the card issuer computer system 50 in one embodiment.
  • the card issuer computer system 50 may confirm the previously used dynamic token's validity and retrieve the actual card number/underlying payment credential that was used for the original purchase transaction. In one embodiment, the card issuer computer system 50 matches the previously used dynamic token to the original payment identifier that was associated with the previously used dynamic token and determines the underlying payment credential. The card issuer computer system 50 may determine the actual card number and/or the underlying payment credentials.
  • the card issuer computer system 50 sends the actual card number or underlying payment credentials, acquirer identifier, merchant identifier and issuer identifier to the messaging hub 20 .
  • the actual card number/underlying payment credential allows the messaging hub 20 or the recipient bank computer 30 to process a refund from the card issuer computer system 50 to the payor of the mobile device 1 .
  • the results from step 806 may be sent by the card issuer computer system 50 to the messaging hub 20 .
  • the messaging hub 20 may send the actual card number or the payment credentials to the recipient bank computer 30 in order to process a refund using the actual card number or the payment credentials.
  • the messaging hub 20 determines the acquirer identifier associated with the recipient bank computer 30 .
  • the messaging hub 20 sends the actual card number or the underlying payment credential to the appropriate acquirer.
  • the message may be sent to the recipient bank computer 30 to process the refund.
  • the recipient bank computer 30 may process a refund using the actual card number or the underlying payment credentials. In one embodiment, the recipient bank computer 30 may process the refund to the account of the actual card number. In another embodiment, the owner of the mobile wallet or the mobile device 1 may be provided with store credit that will be honored at the POS device 40 . In another embodiment, a gift card identifier number may be transmitted to the mobile wallet bank computer 10 .
  • the recipient bank computer 30 may send a refund approval/decline to a POS device 40 or other POS computers.
  • a refund receipt may be printed at the POS device 40 .
  • the refund may also be declined for various reasons by the POS device 40 .
  • a refund may be declined based on the policies that are specified by the owner of the POS device 40 .
  • a receipt may be printed that informs the payor the reason or reasons for the refund being declined.
  • the reasons for the refund decision may be sent to the mobile device 1 via the messaging hub 20 .
  • the approval/decline decision may be sent to the messaging hub 20 by the recipient bank computer 30 .
  • the recipient bank computer 30 includes the issuer identifier, acquirer identifier and the merchant identifier with the approval or decline decision.
  • the approval/decline decision may be received by the messaging hub 20 and the approval/decline decision message may be sent to the mobile wallet bank computer 10 .
  • the mobile wallet bank computer system 10 may transmit the decision to the mobile device 1 .
  • the content of the message may include the issuer identifier, acquirer identifier, merchant identifier and the approval/decline decision.
  • the software on mobile device 1 or mobile wallet bank computer 10 may send an e-mail or push notification to the mobile wallet application.
  • the approval or decline decision may be stored on the mobile device 1 .
  • the refund functionality described above in FIG. 8 may also be used to offer refunds for recurring transactions that occur periodically. These transactions can occur using various payment types, such as but not limited to, demand deposit account, debit card, credit card or other forms of payment.
  • the system described above may be configured to have a persistent token (e.g. special token or specially flagged token) that does not expire or can be used multiple times.
  • a persistent token e.g. special token or specially flagged token
  • the cable company may use the same token on a periodic basis (e.g. monthly, yearly, weekly or quarterly).
  • the merchant in this example, the cable company
  • the messages for a persistent token may include a flag during the debit/credit charge that identifies the token as a recurring token.
  • the messaging hub computer system 20 may send a message to the merchant to deactivate the recurring token and discard the token.
  • the messaging hub computer system 20 may update its storage records such that, when a transaction is initiated using a deactivated recurring token, the messaging hub computer system 20 informs the issuing bank computer system 50 that an attempt to use a deactivated recurring token has been initiated.
  • machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor.
  • machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media.
  • Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.
  • Embodiments have been described in the general context of method steps which may be implemented in one embodiment by a program product including machine-executable instructions, such as program code, for example in the form of program modules executed by machines in networked environments.
  • program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
  • Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein.
  • the particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
  • embodiments may be practiced in a networked environment using logical connections to one or more remote computers having processors.
  • network computing environments may encompass many types of computers, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and so on.
  • Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network.
  • program modules may be located in both local and remote memory storage devices.
  • An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit.
  • the system memory may include read only memory (ROM) and random access memory (RAM).
  • the computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media.
  • the drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer.
  • terminal as used herein is intended to encompass computer input and output devices.
  • Input devices include a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function.
  • the output devices include a computer monitor, printer, facsimile machine, or other output devices performing a similar function.

Abstract

A computer-implemented system and method that includes receiving, by a messaging hub computer system, from a point of sale (POS) device of a merchant, a request to process a refund for a transaction that occurred between the merchant and a mobile device of a payor, the request comprising a previously used code that was exchanged between the POS device and the mobile device. The method includes determining, by the messaging hub computer system, a first financial institution based at least partially on a portion of the code, and receiving, from a computer system of the first financial institution, payment credential information of an account held by the payor to process the refund using the payment credential information. The method may further include transferring, by the messaging hub computer system, the refund from an account held by the merchant to the account held by the payor.

Description

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS
This application claims the benefit of U.S. Provisional Patent App. Ser. No. 61/738,376, filed Dec. 17, 2012, incorporated herein by reference in its entirety.
FIELD
The present disclosure relates generally to the field of systems that use mobile devices to transfer funds. More specifically, the present disclosure relates to systems and methods for enabling individuals to use their electronic devices to transfer funds, purchase products, receive refunds and services.
BACKGROUND
Payments for products and services are often completed using credit cards, debit cards, checks or cash. At the same time, most people carry some type of mobile handheld electronic device, such as a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, and so on. Most of these devices tend to have a wireless Internet connection. A person may wish to make payments to or receive refunds from merchants or other individuals using these mobile devices. Likewise, a person may wish to transfer funds to or receive funds from other individuals using their mobile devices. Enhanced systems and methods of facilitating such transactions would be desirable.
SUMMARY
One embodiment includes a computer-implemented method for providing a computer-implemented system and method that includes receiving, by a messaging hub computer system, from a point of sale (POS) device of a merchant, a request to process a refund for a transaction that occurred between the merchant and a mobile device of a payor, the request comprising a previously used code that was exchanged between the POS device and the mobile device. The method includes determining, by the messaging hub computer system, a first financial institution based at least partially on a portion of the code, and receiving, from a computer system of the first financial institution, payment credential information of an account held by the payor to process the refund using the payment credential information. The method may further include transferring, by the messaging hub computer system, the refund from an account held by the merchant to the account held by the payor.
One embodiment includes a computer system that includes a processor coupled to machine readable storage media having instructions stored therein that, when executed by the processor, cause the processor to transmit, by a recipient bank computer system, a refund transaction request for a previous transaction between a merchant and a payor, to a messaging hub computer system, the refund transaction request including a previously used dynamic token, a refund transaction amount, and an indication that the transaction is a refund transaction. The processor configured to receive from the messaging hub computer system underlying payment credential information for an account held by the payor that was used for the previous transaction and transfer, by the recipient bank computer system, the refund from an account held by the merchant to the account held by the payor.
A computer-implemented method for performing a transaction, the method includes receiving, by a POS (Point of Sale) device, a previously used dynamic token from a mobile device for a refund transaction, the previously used dynamic token identifying a previous transaction that transferred funds to a merchant from a payor, and determining the transaction amount for the previous transaction using the previously used dynamic token. The method further includes transmitting the previously used dynamic token and the transaction amount to a recipient bank computer system and receiving an approval/decline indicator for the refund transaction from the recipient bank computer system. The method includes generating a receipt approving or declining the refund transaction for the payor.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic diagram of a computer-implemented payment processing system according to an example embodiment.
FIG. 2a is a process implemented by the payment processing system of FIG. 1.
FIG. 2b is a process implemented by the payment processing system of FIG. 1.
FIG. 3a is a process implemented by the payment processing system of FIG. 1.
FIG. 3b is a process implemented by the payment processing system of FIG. 1.
FIG. 4 is a process implemented by the payment processing system of FIG. 1.
FIG. 5 is a process implemented by the payment processing system of FIG. 1.
FIG. 6 is a process implemented by the payment processing system of FIG. 1.
FIG. 7 is a process implemented by the payment processing system of FIG. 1.
FIG. 8 is a process implemented by the payment processing system of FIG. 1.
 DETAILED DESCRIPTION
Referring to FIG. 1, a computer-implemented payment processing system 100 is shown that may be used to set up and utilize a mobile wallet account. The user may be a business entity and/or an individual consumer that has one or more source accounts with a financial institution. The source accounts may include business or consumer demand deposit accounts. The mobile wallet account can be created for the user to transmit funds from a demand deposit account in return for purchase of goods or services to a merchant. Additionally, funds can be transferred from the demand deposit account to another person.
FIG. 1 is a schematic diagram of a computer-implemented payment processing system according to an example embodiment. In the example of FIG. 1, an interoperable mobile wallet platform is provided that may be accessed by consumers that bank at various different banking institutions and by merchants that bank at various different banking institutions. Hence, the mobile wallet client application 6 (or various branded variations thereof) may be offered through multiple banks and may utilize the services of multiple banks to complete transactions. Such an arrangement may promote broader adoption of the mobile banking platform by merchants and consumers.
Specifically, as shown in FIG. 1, a payment processing system 100 may include various computer systems such as a mobile device 1, mobile wallet bank computer system 10, messaging hub computer system 20, recipient bank computer system 30 and merchant computer system 40. As will be appreciated, in practice, the computer system of a given banking institution may operate as the mobile wallet bank computer system in the context of some transactions and may operate as the recipient bank computer system in the context of other transactions.
In FIG. 1, the computer systems 1, 10, 30, 40 and 50 may communicate with each other to complete transactions. As shown in FIG. 1, the connection of mobile device 1 is such that it does not communicate directly with the messaging hub computer system 20 or the recipient bank computer system 30. In other implementations, the mobile device 1 may be configured to communicate some information to the messaging hub computer system 20 and/or the recipient bank computer system 30. Interconnections of the computer systems 1, 20, 30, 40 and 50 will now be briefly described.
The mobile device 1 may be used by an individual user (e.g., a business owner or employee, a consumer, and so on) to create and interact with a mobile wallet account. The mobile device 1 may, for example be, a handheld computer, a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, or other suitable device. The mobile device 1 comprises a network interface logic 2, a display device 4, an input device 5, and a mobile wallet client application 6. Network interface logic 2 may include, for example, program logic that connects the mobile device 1 to a network. As described in greater detail below, for example, the mobile device 1 may receive and display screens including account information, transaction instructions, and so on. In an example embodiment, such screens may be used to request username and password information. Such screens may also be used to prompt the user to provide information regarding the amount of the payment and which merchant or individual (e.g., name, address, phone number or e-mail, a selection of a recipient by the user from his memory or from by the user from the mobile device 1, and so on) is to receive the payment. Such screens are presented to the user via the display device 4. The input device 5 may be used to permit the user to initiate account access and to facilitate receiving requested information from the user. As will be appreciated, in addition to or instead of the mobile device 1, users may also be provided with the ability to access the payment processing system 100 using another type of computer (e.g., a desktop or laptop computer executing browser software) to perform the operations described herein as being performed by the mobile device 1.
The mobile wallet client application 6 may comprise program logic executable by the mobile device to implement at least some or all of the functions described herein. As will be appreciated, the level of functionality that resides on the mobile device 1 as opposed to the banking computer system 30 may vary depending on the implementation. The client application 6 may be a web browser that is configured to receive and display mobile web pages (e.g. web pages prompting the user to provide information to create an account, web pages displaying account balance information and past transactions, and so on). The mobile wallet client application 6 may also include a code/token generator capable of generating a unique code/token for each transaction. As described below, the unique code/token may then be transmitted by the mobile device 1 as part of a transaction to facilitate authentication of the transaction. As will be appreciated, the user may also use other devices (e.g., laptop or desktop computer system, not shown) to create and access account.
In FIG. 1, the mobile wallet application 1 is used in connection with merchant computer system 40 located at a bricks and mortar store location. As previously indicated, however, the mobile wallet application 6 may also be used in connection with online merchant transactions. For example, in another embodiment, merchants may be provided with the ability to have a mobile storefront and profile within the mobile wallet application 6. For example, merchants may be provided with the ability to display marketing material, provide information, and promote products or discounts. Merchants may also be provided with the ability to sell items directly through their mobile storefront for the account holder to purchase from within the mobile application 6.
The mobile device 1 may include, in addition to the other features previously described, a code processing system 7. The code processing system 7 may include a code scanner (i.e. camera), and/or a code generator. In one embodiment, the code processing system 7 may receive a numerical code from the mobile wallet bank computer system 10 and generate an image that represents the received code on the display device 15. In one implementation the code processing system 7 may receive a code from the mobile wallet bank computer system 10. In another embodiment, the code processing system 7 may use a code/token generator as described in FIG. 1. The code generator 8 of the mobile device 1 may generate or receive a unique code for a transaction at a point of sale location. The unique code may identify the transaction number for the mobile wallet bank computer system 10. In some embodiments, the code may be a dynamic token that remains valid for a single transaction, and/or a temporary period of time. The code is a POS exchange code that is exchanged between a POS (Point of Sale) device 40 of the merchant and a mobile device 1 of the user in exchange for goods or services that are received by the user.
The bank computer system 10 includes code/QR generator 11, transaction verification logic 13, code determination logic 15, account database 17, and profile database 19. The code generator 11 may receive a request from an account holder to initiate a transaction. A transaction may be initiated by generating a QR code that can be scanned by a merchant or individual. The account holder may access the code generator 11 via a mobile wallet application that is being executed on the mobile device 1. In various embodiments, the QR code may be generated without the account holder providing the merchant's name or amount of transaction. The code generator 11 can be configured to generate a QR code that incorporates at least one of a date, time, unique transaction identifier, and geographic location of the mobile device. In other embodiments, the code generators 11 and 18 can be configured to generate optically scanned or non-optically scanned codes. Examples of optically scanned codes include bar codes, two dimensional codes (e.g. QR code and other similar codes), three dimensional codes (e.g. QR code with color and others characteristics), and four dimensional codes (e.g. QR code with color and timestamp information). Examples of non-optically scanned codes may include, near field communication (NFC), RFID, HID or other RF signal to transmit the code.
The transaction verification logic 13 may receive a transaction amount from the messaging hub computer system 20. The transaction verification logic 13 may generate a message to send to the mobile device 1 for verifying the transaction amount. Upon receiving the verification message, the account holder via mobile device 1 may approve the transaction amount to the bank computer system 10.
The account database 17 may store details regarding financial institution accounts. In particular, the account database 17 may store each financial transaction that occurred. Each financial transaction may include the amount of the transaction and the merchant. In some embodiments, the messaging hub computer system 20 stores account information for the user, so the account information is not received from the mobile wallet bank computer system 10.
The profile database 19 may store other information regarding the account holder. For example, the profile database 19 may store information useful for generating offers and advertisements that are selected specifically for the account holder. In some embodiments, the messaging hub computer system 20 may also be operative to process the transaction between the two parties.
As shown in FIG. 1, the mobile wallet bank computer system 10 is configured to communicate with the mobile device 1 and the messaging hub computer system 20. The content of the communication with the messaging hub computer system 20 may include account information regarding the user, confirmation of the code and approval/declining a transaction between the user of the mobile device 1 and a merchant.
As shown in FIG. 1, the messaging hub computer system 20 is configured to communicate with one or more financial institutions that provide financial accounts to various individuals or merchants. The messaging hub computer system 20 may include various components such as validator 21 discussed in greater detail below. The messaging hub computer system 20 is configured to act as an intermediary between two financial institutions such as mobile wallet bank computer system 10 and recipient bank computer system 30. The messaging hub computer system 20 may act as a message router that is configured to assure that the correct information is transmitted to the correct financial institution to facilitate a transaction between two parties (e.g. a user and a merchant or a user and another user or between two merchants). Additionally, the messaging hub computer system 20 provides a single interface for each bank to communicate with a plurality of other banks.
The messaging hub computer system 20 may be a third party provided interface for one or more financial institutions. In one embodiment, the messaging hub computer system 20 may be provided by an exchange service that allows banks to transmit information securely between banks to process transactions where funds are transferred from one bank to another bank. In the example shown in FIG. 1, funds may be transferred from an account held by the user of the mobile device 1 to an account held by a merchant with a merchant computer system 30. The messaging hub computer system 20 includes a processor and a non-transitory memory that are configured to receive and transmit information between one or more financial institutions. The information received from a sending financial institution may identify the recipient financial institution. The interface between the messaging hub computer system 20 and the financial institutions uses bank level security encryption to send and receive messages.
The validator 21, in the messaging hub computer system 20, performs an initial validation of the code that is received from the recipient bank computer system 30. In another embodiment, a portion of the received code may identify the financial institution that should receive the messages from the messaging hub computer system 20. The validator 21 may access stored information that correlates codes with electronic contact information for financial institutions. In another implementation, a database may be used to determine the correlation between a portion of the code and a financial institution with which the code corresponds.
The validator 21 includes a comparator configured to compare the time provided by the merchant computer system 40 with the time provided via the QR code generated by the mobile device 1. If the time provided by the QR code and the merchant computer system 40 exceeds a predetermined time limit (e.g., five minutes), the messaging hub computer system 20 will deny the transaction.
The recipient bank computer system 30 includes network interface logic 32, account processing logic 34, and accounts database 36. When the mobile wallet account is created, the user is prompted to provide bank account information (e.g., routing number and/or account number) for the source account that is used as a source of funds for the mobile wallet account. Thus, the financial institution that provides the mobile wallet account for the user and the financial institution that typically provides banking services to the user may be two different financial institutions.
In another embodiment, the code generator 31 may receive a request for a code to provide to a merchant, the code being generated to be displayed on a merchant point of sale machine or an ecommerce website. The merchant may display the code for the account holder to scan using a mobile device. Generating the code including embedding in the code a transaction identification number, a geographic location of the merchant, and a timestamp. The financial institution may send the code to the merchant for the mobile device to scan. The mobile device 1 may scan the code from a merchant display device. The mobile device 1 may amend the code to add further authentication information to the code and send the code to the financial institution. The financial institution may receive the amended code from the mobile device to transfer funds from an account held by the account holder to the merchant. In one embodiment, the requested funds are transferred to the merchant upon verifying the geographic location of the mobile device to be within a predetermined distance of the location of the merchant. In another embodiment, the amended code is amended to include authentication information (e.g. geographic location, account number, pass code, pin code) from the mobile device for the financial institution.
The merchant computer system 40 may be configured in generally the same manner as the other computer systems described herein. For example, if the fund recipient is an individual, the computer system 40 may be another mobile device, such as a handheld computer, cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, or other suitable device. If the fund recipient is a merchant (e.g., a brick and mortar merchant, a retail website or other online merchant, etc.), the computer system 40 may comprise a point of sale (POS) device or other computer system (e.g., one or more servers each with one or more processors) configured to execute instructions, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with the fund recipient.
The merchant computer system 40 may be used at a point of sale to conduct transaction with the account holder. For example, the merchant computer system 40 may comprise a point of sale computer system such as a cash register system connected to a central server system operated by the merchant. As another example, the merchant computer system 40 may comprise a mobile computing device (e.g., smart phone, tablet PC, etc.) operated by a store clerk as the clerk moves throughout the store. Again, the mobile computing device in such an embodiment may connect to a central server system operated by the merchant.
The merchant computer system 40 includes code scanner 44, fund requesting logic 48, and fund receiving logic 49. The code scanner 44 may be configured to scan codes, such as but not limited to, optically scanned or non-optically scanned codes. Examples of optically scanned codes include bar codes, two dimensional codes (e.g. QR code and other similar codes), three dimensional codes (e.g. QR code with color and others characteristics), and four dimensional codes (e.g. QR code with color and timestamp information). Examples of non-optical codes include, near field communication (NFC), RFID, HID or other RF signal to transmit the code. Code scanner 44 may include a light emitting device that scans a code using infrared, laser, or other types of communication technology. In one embodiment, the code scanner 44 scans a QR code. After scanning the QR code the QR code scanner 44 determines the information that was incorporated into the QR code by the mobile device 1 that generated the code.
The fund requesting logic 48 communicates a fund request to the recipient bank computer system 130. In one embodiment, the fund requesting logic 48 also sends the amount of transaction to the financial transaction.
The merchant computer system 40 may further connect to or integrate with other hardware. For example, in one embodiment, the merchant computer system 40 may connect to a card reader for reading credit cards, debit cards, stored value cards, and so on. As another example, the merchant computer system 40 may be configured to prompt the user to provide a random security code. The random security code may be generated by the mobile device 1, by a separate security dongle, or in another manner. The security code may be provided to the merchant computer system 40 directly by the mobile device, may be keyed into the merchant computer system (e.g., by a store clerk), or may be received in another manner.
After scanning the QR code, the merchant may transmit the QR code to the recipient bank computer system 30, as previously described. The recipient bank computer system 30 may then return account information (e.g., a credit card number, debit card number, alternative payment type, demand deposit account, etc.) to backend servers associated with the merchant computer system 40 to permit the transaction to be processed in the same manner as a conventional credit card or debit card transaction. Other mechanisms for processing payments may also be used.
As shown in FIG. 1, the recipient bank computer system 30 is configured to communicate with the merchant computer system 40 and the messaging hub computer system 20. The recipient bank computer system 30 is configured to receive funds to the financial institution of the user (e.g. mobile wallet bank computer system 10). In other implementations, the recipient bank computer system 30 may be configured to communicate with the mobile device 1 and/or the mobile wallet bank computer system 10.
As shown in FIG. 1, the merchant computer system 40 is configured to communicate with the recipient bank computer system 30 and the mobile device 1. The merchant computer system 40 is configured to receive a code (e.g. QR code) and other information from the recipient bank computer system 30. In other implementations, the merchant computer system 40 may be configured to communicate with the mobile device 1 and/or the mobile wallet bank computer system 10. The interface between the merchant computer system 40 and the recipient bank computer system 30 uses bank level security encryption to send and receive messages.
As shown in FIG. 1, the issuing bank computer system 50 is operative to transfer funds from the demand deposit account held by the user to the recipient bank computer system 30 under the direction of the recipient bank compute system 30 or the messaging hub computer system 20. The issuing bank computer system 50 may be configured to communicate via a network with the messaging hub computer system 20, the mobile wallet bank computer system 10 and the recipient bank computer system 30. The issuing bank computer system 50 is configured to receive funds from various mobile wallet bank computer systems 10 and transmit the funds to the appropriate recipient bank computer systems 30. The issuing bank computer system 50 may include an account processing logic 52 that determines which user has a credit card account and an account database that store information regarding user accounts. In other embodiments, the issuing bank computer system 50 is configured to be a registry information provider. The registry information may include an identifier for the user mobile wallet account and the registry information such as the user default account number may be provided to the messaging hub computer system 20. In other embodiments, the registry information may include other information that allows the messaging hub computer system 50 to obtain the account information from another financial institution.
As will appreciated, during operation of the system shown in FIG. 1, various parameters may be passed between the computer systems 1, 20, 30, 40 and 50. An exemplary listing of such parameters is set forth below in Table 1. These parameters may be alphanumeric values.
TABLE 1
Term Definition
Payment A static value that is tied to an underlying
Identifier (PI) payment type or consumer registry info
Issuer A unique number that identifies the issuer to
Identifier (II) ensure appropriate routing of Dynamic Token
requests
Wallet A unique ID per Wallet/Version combo
Platform
ID (WPI)
Wallet User A unique ID per user of each wallet
ID (WUI)
Dynamic A tokenized value that is sent to the issuer or
Token (DT) acquirer for validation and retrieval of key
information to drive a purchase transaction
Previously A previously used tokenized value that is
Used Dynamic used to drive a refund transaction
Token (PUDT)
Trace ID (TID) A subset of the Dynamic Token that is used by
the issuer for security and matching purposes
Merchant ID A unique ID for each merchant that is tied to a
(MID) Merchant Registry Info
Acquirer ID A unique ID for each acquirer/processor
(AID)
POS ID (PID) A unique ID for each point of sale terminal
Merchant A Merchant specific data element that allows
Registry MH to look up the DDA or other profile info
Info (MRI)
Consumer A Consumer ID that allows MH to look up the
Registry DDA or other profile info
Info (CRI)
FIG. 2a depicts a first process for completing a transaction that may be implemented by the payment processing system of FIG. 2a . For purposes of providing an example, it is assumed that the two parties to the transaction in FIG. 2a are a user of mobile wallet application 6 (e.g., consumer) and a merchant. Again, as above, it will be appreciated that other types of transactions may be possible.
At step 201, the user may provide input to the POS (Point of Sale) device 40. For example, a user purchasing merchandise at a bricks and mortar merchant may be at a checkout counter or other type of POS arrangement. The user may be presented with a series of payment options at the POS device 40 (e.g., credit card, debit card, mobile, and so on). The user may select a payment type (here, “mobile”) to pay for goods or services, and the POS device 40 may receive the selection of the payment option.
Next at step 202, the user may access the mobile wallet application 6 on mobile device 1 and select a “pay now” or similar option on the mobile device. As previously discussed, the mobile wallet application 6 may also offer the user various payment types (e.g., various credit cards, debit cards, alternative payment type, demand deposit account and so on). In one embodiment, the user may have pre-specified a default payment type that may be used. The mobile device 1 may receive the user input and initiate communication with the mobile wallet bank computer system 10.
At step 203, the mobile device 1 may send a request to the mobile wallet bank computer system 10 for a code that may be used to identify the transaction that will occur between the user and the POS device 40. The request to the mobile wallet bank computer system 10 includes the wallet platform ID (WPI) that identifies a unique identification number for the wallet and/or the version of the wallet application that is being used. The message that is transmitted may include information identifying the user (e.g., a device identifier for the mobile device 1, a unique identifier (e.g., wallet user ID (WUI)) associated with the mobile wallet application 6 when installed by the user, etc.). Information regarding the payment type selected by the user may also be sent. The mobile wallet bank computer system 10 may be configured to receive requests directly from the mobile device 1 for codes or other information.
At step 204, the mobile wallet bank computer system 10 may generate a random code or sequential code as described above, e.g., in connection with FIG. 1. In one embodiment, the code may represent a unique identifier (e.g., dynamic token (DT)) for the transaction that is about to be completed between the user and the merchant. In other embodiments, the code may also include a transaction identifier and verification codes that identify the mobile wallet bank computer system 10 to the messaging hub computer system 20 when the code is received by the messaging hub computer system 20. In other embodiments, the code may include a trace ID (TID) which is part of the dynamic token and is used by the issuing bank for security and matching purposes. In some embodiments, the mobile wallet bank computer system 10 may generate a code based on a standard that the messaging hub computer system 20 can decode and understand.
After receiving the code from the mobile wallet bank computer system 10, the mobile device 1 may process the code using the code processing system 7. In one embodiment, the code may be sent over a wireless link between the mobile device 1 and the mobile wallet bank computer system 10. In one embodiment, to reduce bandwidth requirements and transmission times, the code may be sent as a numeric code. In such an embodiment, the code processing system 7 may be configured to convert the code into a displayable image that may be scanned by the POS device 40. In other embodiments, the code may be sent as an image (e.g., QR code or bar code). At step 205, the mobile device 1 may generate a display and the POS device 40 may optically scan the displayed code.
At step 206, after scanning the code from the mobile device 1, the code and a merchant identification number (e.g., Merchant ID (MID) that represents a unique identifier for the merchant that is tied the merchant registry information in the messaging hub computer system 20) from the POS device 40 is transmitted to the recipient bank computer system 30. At step 207, after receiving the code, the recipient bank computer system 30 may be configured to transmit the code and the merchant identification number to the messaging hub computer system 20. Upon receiving the code, the messaging hub computer system 20 may perform an initial validation of the code and then decode it to determine the banking institution (e.g., issuer identifier (II) or wallet platform ID (WPI)) with which it is associated (i.e., to determine which banking institution generated the code). In some embodiments, the code or a portion of the code (e.g., TID) may be matched with a number that identifies the banking institution (e.g., the last three or four digits may be used to access a lookup table).
Next, at step 208, the code and the merchant identification number is sent to the mobile wallet bank computer system 10. At step 209, the mobile wallet bank computer system 10 confirms the code's validity. Details of the code (TID) may be compared against codes previously generated by the mobile wallet bank computer system 10 (in this example, the code is the same as that generated in step 204). Additionally, the mobile wallet bank computer system 10 may confirm that the code has not expired. For example, the code that was originally generated at step 204 may expire within a predetermined period of time, such as, 15 minutes, 10 minutes, 5 minutes, or another period of time. Also, the mobile wallet bank computer system 10 may confirm that the code has not already been used for another transaction.
At step 210 a, upon verifying the code, the mobile wallet bank computer system 10 transmits the messaging hub computer system 20 payment information (e.g. account information) for the payment account to be used for the transaction. The payment information may be the payment identifier (PI) in one embodiment. For example, a credit card or debit card number, demand deposit account or alternative payment of the user may be transmitted. Additionally, the mobile wallet bank computer system 10 may send stored merchant loyalty information to the messaging hub computer system 20. After step 210 a, the messaging hub computer system 20 transmits the payment information and the loyalty information to the recipient bank computer system 30.
Next, at step 211, the recipient bank system 30 transmits the loyalty information to the POS device 40. At step 212, the POS device 40 uses the loyalty information to calculate the final transaction amount and transmits the transaction amount to the recipient bank computer system 30. At step 213, upon receiving the transaction amount, the recipient bank system 30 processes the transaction using the payment information received from the messaging hub computer system 20. For example, if a credit card number is received, the recipient bank system 30 may submit the credit card transaction for approval and the credit card transaction may be processed as a standard four party credit card transaction between a customer, a merchant, an issuing bank and an acquiring bank.
Next, at step 214, the recipient bank system 30 provides an indication whether the transaction is approved or declined to the POS device 40. Next, at step 215, the POS device 40 prints a receipt for the user. As another example, the user may opt via the mobile wallet application 6 to have the receipt sent electronically to the mobile device 1 via the messaging hub computer system 20.
Next at step 216, the recipient bank system 30 provides an indication whether the transaction is approved or declined to the mobile wallet bank computer system 10 through the messaging hub computer system 20. At step 217, the mobile wallet bank computer system 10 sends a notification to the mobile wallet application. Based on this information, a message may be displayed to the user via the mobile device 1 at the point of sale indicating whether the transaction was approved or declined.
In various embodiments, each message that is transmitted for steps 201 to 217 includes the code to identify the transaction. The banks computer systems 10 and 30 and the messaging hub computer system 20 may receive the sensitive account information (e.g., credit card number) during the various steps discussed herein, however, the POS device 40 or the mobile device 1 need not receive the user's account information. Hence, account security may be enhanced. The messaging hub computer system 20 facilitates a secure transmission of sensitive information and aids the banks by providing a single point of contact. Moreover, the messaging hub computer system 20 creates a messaging format that each banking entity must comply with for the messages.
In the embodiment of FIG. 2a , a code is generated on the display of the mobile device 110 and the code is displayed for optical scanning by the POS device 40. Hence, the user presents the mobile device for scanning at the time of sale, creating a user experience for the user that is somewhat similar to presentation of a credit card.
Referring now to FIG. 2b , FIG. 2b is a process implemented by the payment processing system. In the embodiment shown in FIG. 2b , the credit card issuer bank is different than the mobile wallet application provider. In FIGS. 2b and 3b , for simplicity mobile device 1 and mobile wallet bank computer system 10 are shown as being combined, but it will be appreciated that they operate in a manner that is similar to FIGS. 2a, and 3a . Table 2 below describes the messages that are transmitted in various steps and the content of the messages. Table 2 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIGS. 2b and 3b . The messaging hub that is referred to in Table 2 is the messaging hub computer system 20 from FIGS. 2b and 3b . The beta issuer that is referred to in Table 2 may operate or signify the card issuer computer system 50 from FIGS. 2b and 3b . The POS scanner referred to in Table 2 is shown in FIGS. 2b and 3b as POS device 40. The recipient bank computer 30 shown in FIGS. 2b and 3b is discussed in Table 2 as the gamma acquirer. However, the steps from FIG. 3b may use similar messages and routing as shown in FIG. 2b . Unlike FIG. 2b , the POS device 40 initiates the process of FIG. 3b . The steps shown in FIG. 3b transmit similar data as the step described for FIG. 2b .
TABLE 2
Step number Msg Routing Msg Routing
and Name Step Description Info (TO) Info (FROM) Payload
251 - Customer Consumer of Alpha Mobile Mobile WUI
requests a Wallet or Alpha wallet wallet device
Dynamic Token makes a request for a provider
(DT) Dynamic token using a
previously provisioned
Payment Identifier
User selects Payment
Identifier associated
with the underlying
payment method
252 - Dynamic Alpha Wallet sends II: Issuer WUI: PI: Payment
Token (DT) request for Dynamic Identifier Wallet Identifier
request sent to Token to the User Info
Messaging Hub Messaging Hub WPI:
(MH) Wallet
Platform
Info
253 - Dynamic Messaging Hub (MH) II: Issuer WUI: PI: Payment
Token (DT) passes request for Identifier Wallet Identifier
request sent to Dynamic Token (DT) User Info
Beta Issuer to the appropriate Wallet
Issuer. WPI: Platform
Info
254 - Beta issuer Beta issuer generates a WUI: II: Issuer DT: Dynamic
generates Dynamic Token in Wallet User Identifier Token.
Dynamic Token Track 1 or 2 format Info
and sends back to and sends it back to the WPI:
the MH MH (Messaging Hub) Wallet
(Messaging Hub) The Dynamic Token is Platform
in Track 1 or Track 2 Info
format and includes
issuer specific info,
dynamic data and the
last 4 digits of the
underlying payment
type
255 - MH sends MH sends the WUI: II: Issuer DT: Dynamic
the Dynamic Dynamic Token (DT) Wallet User Identifier Token
Token (DT) to the to the Alpha Wallet. Info
Alpha Wallet WPI:
Wallet
Platform
Info
256 - POS Scanner The Alpha Wallet will via scan via scan DT: Dynamic
reads or accepts either display the Token
the DT Dynamic Token as a
QR Code for scanning
by the POS or transmit
the Dynamic Token to
the POS via other
communication
methods.
Other communication
methods may include
NFC, Bluetooth,
Hypersonic or other
communication
technologies
257 - POS sends Once the final II: Issuer MID: DT: Dynamic
final purchase purchase amount is Identifier Merchant ID Token
amount and DT to calculated, the POS as part of
Gamma Acquirer will send the Dynamic the DT
Token ( Track 1 or 2 Dynamic
Data) to its existing Token
acquirer/processor
258 - Gamma The Gamma Acquirer II: Issuer AID: DT: Dynamic
Acquirer sends DT reads the II as part of Identifier Acquirer ID Token
to MH the Dynamic Token as part of MID:
and sends the DT to the DT Merchant ID
the MH Dynamic
Token
259 - MH receives The MH reads the II as II: Issuer AID: DT: Dynamic
DT and routes to part of the Dynamic Identifier Acquirer ID Token
the Beta Issuer Token, recognizes it as as part of MID:
an II and sends the DT the DT Merchant ID
to the Beta Issuer. Dynamic
Token
260 - Beta Issuer Beta issuer matches ACN/UPC:
confirms the DT's the DT to the original Actual Card
validity and PI that was associated Number/
retrieves the actual with the DT and then Underlying
card determines the Payment
number/underlying underlying payment Credential
payment credential credential
261 - Beta Issuer AID: II: Issuer ACN/UPC:
sends the Acquirer ID Identifier Actual Card
ACN/UPC to the MID: Number/
MH Merchant ID Underlying
Payment
Credential
Trace ID: A
subset of the DT
for the
transaction that
is used for issuer
security and
matching
262 - MH Sends MH looks at the AID AID: II: Issuer ACN/UPC:
the ACN/UPC to associated with the Acquirer ID Identifier Actual Card
the Gamma message and sends the MID: Number/
Acquirer along ACN/UPC to the Merchant ID Underlying
with a Trace ID. appropriate acquirer. Payment
Credential
Trace ID: A
subset of the DT
for the
transaction that
is used for issuer
security and
matching
263 - Gamma Gamma Acquirer ACN/UPC:
Acquirer processes payment Actual Card
processes payment using the ACN/UPC Number/
using the via its existing process Underlying
ACN/UPC and includes the Trace Payment
ID for issuer matching Credential
and security. This
results in authorization
and settlement
264 - Gamma Existing process Approve/Decline
Acquirer sends
Approval/Decline
to the POS
265 - POS prints Existing process Approve/Decline
receipt as normal
266 - Gamma Gamma Acquirer II: Issuer AID: Approve/Decline
Acquirer sends sends Identifier Acquirer ID
Approval/Decline Approval/Decline to MID:
to MH MH based upon the II Merchant ID
267 - MH sends MH sends II: Issuer AID: Approve/Decline
Approval/Decline Approval/Decline to Identifier Acquirer ID
to the Alpha the Alpha Wallet based MID:
Wallet upon the II Merchant ID
268 - Alpha Alpha Wallets sends
Wallets sends an an email and push
email and push notification to the
notification to the Alpha Wallet User
Alpha Wallet User
Referring now to FIG. 3a , FIG. 3a is a process implemented by the payment processing system. In the embodiment of FIG. 3a , a code (DT) is generated and displayed by the POS device 40 and optically scanned by the mobile device 1. Such an arrangement avoids the need for the POS device 40 to include a scanner.
Specifically, in the embodiment shown in FIG. 3a , at step 301, the user may select using a mobile device 1 as a payment option at the POS device 40. Upon receiving the user input, the POS device 40 sends a request to the recipient bank system 30, specifically, a request for a numerical code (DT), a QR code or other code as described herein. In response, at step 302, the recipient bank system 30 creates the code (e.g. numerical, barcode, or QR code, etc.). The recipient bank system 30 may send the code to POS device 40 for display on POS terminal screen or printed on a receipt. At step 303, the mobile device 1 may receive the code by using a camera. A user may access the mobile wallet application in the mobile device 1 and request that a payment be made. Upon scanning or taking a picture of the code that is displayed on the POS device 40 at step 303, the mobile device 1 may transmit the code to the mobile wallet bank 10 at step 304. Next, at step 305, the mobile wallet bank computer system 10 sends the code to the messaging hub computer system 20. The code may identify the merchant using merchant identifier and merchant registry information (MRI). The messaging hub computer system 20, at step 306, sends the code to the recipient bank system 30. At step 307, the recipient bank system 30 determines the validity of the code and also determines the whether the codes is expired, not previously used, etc. The recipient bank system 30 accesses the database and determines the merchant identification for the (POS ID and/or MID) POS device 40. The merchant identification is transmitted from the recipient bank system 30 to the messaging hub computer system 20 and the messaging hub computer system 20 transmits the merchant identification to the mobile wallet bank computer system 10. The mobile wallet bank computer system 10 receives the merchant identification and the transaction code.
At step 308, the mobile wallet bank computer system 10 sends the payment information regarding user payment account and any stored merchant loyalty information to the recipient bank system 30 through the messaging hub computer system 20. Next, at step 309, the recipient bank system 30 may transmit the loyalty information to the POS device 40 to be displayed for the user. Next, at step 310, based on the loyalty information, the final transaction amount is determined by the POS device 40 and transmitted to the recipient bank computer system 40. The recipient bank system 30 receives the transaction amount and processes the transaction using the payment information that the recipient bank system 30 received from the mobile wallet bank computer system 10, at step 311. The recipient bank system 30 also determines whether the transaction is approved or denied.
At step 312, the approval or denial is transmitted to the POS device 40. Next, at step 313, the POS device 40 prints a receipt or sends a receipt to the user. Next, at step 314, the recipient bank system 30 sends an approval and/or decline message to the mobile wallet bank 10 via a messaging hub computer system 20. The mobile wallet bank system 10 transmits a notification to the mobile device 110 to inform the mobile device 110 regarding the approval or decline decisions at step 315.
Referring now to FIG. 3b , FIG. 3b is a process implemented by the payment processing system. Table 2 above describes the messages that are transmitted in various steps and the content of the messages. Table 2 refers to the steps from FIG. 2a . However, the steps from FIG. 3b may use similar messages and routing as shown in FIG. 2a . FIG. 3b illustrates a process implemented by the payment processing system of FIG. 1. In the embodiment shown in FIG. 3b , the credit card issuer bank is a separate entity than the mobile wallet application provider. Table 4 below describes the messages that are transmitted in various steps and the content of the messages. The process of FIG. 7 is initiated by the POS device 40 by initiating the transaction request for the code. The steps shown in FIG. 7 transmit similar data as the step described for FIG. 6.
In the embodiments of FIGS. 2a, 2b, 3a and 3b , the recipient bank system 30 receives the credit card number of the user, submits the credit card transaction for approval, and the credit card transaction is processed as a standard four party credit card transaction between a customer, a merchant, an issuing bank and an acquiring bank. The messaging hub computer system 20 operates to communicate information between the mobile wallet bank computer system 10 and the recipient bank computer system 30. Referring now to FIGS. 4 and 5, in other embodiments, a demand deposit account is used as a source of funds and the messaging hub computer system 20 may facilitate processing of the transaction by transmitting information about demand deposit accounts held by the sender and the recipient.
A demand deposit account is an account in which deposits can be “demanded” by an account holder at any time. Funds in a demand deposit account can be withdrawn at any time without any advance notice to the depository or financial institution. For example, many checking and savings accounts are demand deposits and are accessible by the account holder through a variety of banking options, including teller, ATM and online banking. In contrast, a term deposit is a type of account that cannot be accessed for a predetermined period (typically the loan's term). Demand deposit accounts may have features such as no maturity period (or an original maturity of fewer than seven days), payable on demand, may be interest bearing, no limit on the number of withdrawals or transfers an account holder may make, and no eligibility requirements. In some types of transactions using demand deposit accounts, various entities may charge fees, to the user, the merchant or the bank, in order to use the funds in a demand deposit account at a point of sale location. For example, when the user uses a debit card to access their funds, the user may be charged a debit card fee by the bank. In another example, when the user uses a debit card through an open loop payment processor, the merchant and/or the bank may be charged a fee in connection with the transaction. Systems and methods described herein may in some cases reduce the fees charged to the user, the merchant or the bank.
Referring first to FIG. 4, FIG. 4 illustrates another method for completing a transaction that is implemented by the payment processing system of FIG. 1. For purposes of providing an example, it is assumed that the two parties to the transaction in FIG. 4 are a user of mobile wallet application 6 (e.g., consumer) and a merchant. In some embodiments, the merchant may also be using a mobile wallet application that is the same or similar to the mobile wallet application that is being used by the consumer. As mentioned above, it will be appreciated that other types of transactions may be possible.
At step 401, the user may provide input to the POS device 401. For example, a user purchasing merchandise at a merchant location may be at a checkout counter or other type of POS arrangement. The user may be presented with a series of payment options at the POS device 40 (e.g., credit card, debit card, mobile device, and so on). The user then selects a payment type (here, “mobile”) to pay for goods or services, and the POS 40 receives the selection of the payment option.
Next, at step 402, the user may access the mobile wallet application 6 on the mobile device 1 and select a “pay now” or similar option on the mobile device. As previously discussed, the mobile wallet application 6 may also offer the user various payment types (e.g., various credit cards, debit cards, alternative payment type, demand deposit account, bank account, money market account and so on). The user may have pre-specified a default payment type that may be used prior to the transaction being initiated by the POS device 40 or the user reaching the POS device 40. A profile may be stored on the mobile device 1 or the mobile wallet bank computer system 10. The profile may store a priority of payment types, for example, in the most preferred to the least preferred option. In some embodiments, the payment option chosen by the user may be a demand deposit account that is provided by a financial institution. In an example embodiment, the mobile wallet bank may provide the demand deposit account. In another example embodiment, another financial institution (e.g. other bank 1, other bank 2, etc.) provides the demand deposit account. In some embodiments, the mobile wallet bank may store identification information for the demand deposit account, such as but not limited to, the routing number, bank account number and other account identification information. The mobile device 1 may receive the user input and initiate communication with the mobile wallet bank computer system 10.
At step 403, the mobile device 1 may send a request to the mobile wallet bank computer system 10 for a code that may be used to identify the transaction that will occur between the user and the owner of the POS device 40. The message that is transmitted may include information identifying the user (e.g., a device identifier for the mobile device 1, a unique identifier associated with the mobile wallet application 6 when installed by the user, etc.). Information regarding the payment type selected by the user may also be sent. The mobile wallet bank computer system 10 may be configured to receive requests directly from the mobile device 1 for codes and/or other information.
At step 404, the mobile wallet bank computer system 10 may generate a random code or sequential code as described above, e.g., in connection with FIG. 1. In one embodiment, the code may represent a unique identifier for the transaction that is about to be completed between the user and the merchant. In other embodiments, the code may also include a transaction identifier and verification codes that identify the mobile wallet bank computer system 10 to the messaging hub computer system 20 when the code is received by the messaging hub computer system 20. In some embodiments, the mobile wallet bank computer system 10 may generate a code based on a standard that the messaging hub computer system 20 can decode and determine which entity to communicate with next. In some embodiments, the code may represent a coded version of the demand deposit account information (i.e. routing number and account number) that may be decoded by the messaging hub computer system 20 using a key that is embedded within a decodable version of the code.
After receiving the code from the mobile wallet bank computer system 10, the mobile device 1 may process the code using the code processing system 7. In one embodiment, the code may be sent over a wired or wireless link between the mobile device 1 and the mobile wallet bank computer system 10. In one embodiment, to reduce bandwidth requirements and transmission times, the code may be sent as a numeric code and transformed into a QR code for display purposes. In such an embodiment, the code processing system 7 may be configured to convert the code into a displayable image that may be scanned by the POS device 40. In other embodiments, the code may be sent as an image (e.g., QR code or bar code). At step 405, the mobile device 1 may generate a display and the POS device 40 may optically scan the displayed code.
At step 406, after scanning the code from the mobile device 1, the code and a merchant identification number from the POS device 40 is transmitted to the recipient bank computer system 30. At step 407, after receiving the code, the recipient bank computer system 30 may be configured to transmit the code and the merchant identification number to the messaging hub computer system 20. Upon receiving the code, the messaging hub computer system 20 may perform an initial validation of the code and then decode it to determine the banking institution with which it is associated (i.e., to determine which banking institution generated the code). In some embodiments, the code or a portion of the code may be matched with a number that identifies the banking institution (e.g., the last three or four digits may be used to access a lookup table).
Next, at step 408, the code and the merchant identification number is sent to the mobile wallet bank computer system 10. At step 409, the mobile wallet bank computer system 10 confirms the code's validity. Details of the code may be compared against codes that were previously generated by the mobile wallet bank computer system 10 (in this example, the code is the same as the code that was generated in step 404). Additionally, the mobile wallet bank computer system 10 may confirm that the code has not expired. For example, the code that was originally generated at step 404 may expire within a predetermined period of time, such as, 15 minutes, 10 minutes, 5 minutes, 3 minutes or another period of time. The mobile wallet bank computer system 10 maintains a record of the time when each code was generated. When the mobile wallet bank computer system 10 receives the code from the messaging hub computer system 20 or another entity, the mobile wallet bank computer system 10 compares the time the code was generated and the time when the code was received from the messaging hub computer system 20. In some embodiments, the mobile wallet bank computer system 10 provides the time the code was generated to the messaging hub computer system 20 and the messaging hub computer system 20 may perform the time comparison. Also, the mobile wallet bank computer system 10 may confirm that the code has not already been used for another transaction.
At step 410 a, upon verifying the validity of the code, the mobile wallet bank computer system 10 transmits the payment information (e.g. account information) to the messaging hub computer system 20. The payment information may include the routing number and the account number for the demand deposit account to be used for the transaction. Additionally, the mobile wallet bank computer system 10 may send stored merchant loyalty information to the messaging hub computer system 20. In some embodiments, the user account and loyalty information is stored in a database maintained at the messaging hub computer system 20, and the mobile wallet computer system 10 is not accessed by the messaging hub computer system 20 for this information. At step 410 b, the messaging hub computer system 20 may transmit the payment information and the loyalty information to the recipient bank computer system 30.
Next, at step 411, the recipient bank system 30 transmits the loyalty information to the POS device 40. At step 412, the POS device 40 uses the loyalty information to calculate the final transaction amount and transmits the transaction amount to the recipient bank computer system 40. At step 413, upon receiving the transaction amount, the messaging hub computer system 20 triggers the transaction to occur between the user identified or chosen demand deposit account and the recipient bank computer system 30 (e.g., merchant demand deposit account). The messaging hub computer system 20 may receive the purchase amount and the registry information for both the user demand deposit account and the recipient's bank account. The messaging hub computer system 20 may transfer funds from the demand deposit account to the recipient bank account. In another embodiment, the recipient bank system 30 processes the transaction using the payment information received from the messaging hub computer system 20. For example, when the demand deposit account information is received, the recipient bank system 30 may submit the transaction for approval to the ACH processing system to process the transaction between a customer, a merchant, an issuing bank and an acquiring bank.
Next, at step 414, the messaging hub computer system 20 provides an indication whether the transaction is approved or declined to the POS device 40 via recipient bank computer system 30. Next, at step 415, the POS device 40 prints a receipt for the user. As another example, the user may choose via the mobile wallet application 6 to have the receipt sent electronically to the mobile device 1 via the messaging hub computer system 20.
Next, at step 416, the messaging hub computer system 20 sends an indication whether the transaction is approved or declined to the mobile wallet bank computer system 10. At step 417, the mobile wallet bank computer system 10 sends a notification to the mobile wallet application 6. Based on this information, a message may be displayed to the user via the mobile device 1 at the point of sale indicating whether the transaction was approved or declined.
In various embodiments, each message that is transmitted for steps 401 to 417 includes the code to identify the transaction. The banks computer systems 10 and 30 and the messaging hub computer system 20 may receive the sensitive account information (e.g., demand deposit account information) during the various steps discussed herein, however, the POS device 40 or the mobile device 1 need not receive the user's account information. Hence, account security may be enhanced. The messaging hub computer system 20 facilitates a secure transmission of sensitive information and aids the banks by providing a single point of contact. Moreover, the messaging hub computer system 20 creates a messaging format that each banking entity must comply with for transmitting messages.
In the embodiment of FIG. 4, a code is generated on the display of the mobile device 1 and the code is displayed for optical scanning by the POS device 40. Hence, the user presents the mobile device for scanning at the time of sale, creating a user experience for the user that is somewhat similar to presentation of a credit card.
Referring now to FIG. 5, FIG. 5 is a process implemented by the payment processing system 100. In the embodiment of FIG. 5, a code is generated and displayed by the POS device 40 and optically scanned by the mobile device 1. Such an arrangement avoids the need for the POS device 40 to include a scanner.
Specifically, in the embodiment shown in FIG. 5, at step 501, the user may select using a mobile device 1 as a payment option at the POS device 40. Upon receiving the user input, the POS device 40 sends a request to the recipient bank system 30, specifically, a request for a numerical code, a QR code, an RFID code, a near field communication code or other code as described herein. In response, at step 502, the recipient bank system 30 creates the code (e.g. numerical, barcode, or QR code, etc.). The recipient bank system 30 may send the code to POS device 40 for display on POS terminal screen or printed on a receipt. At step 503, the mobile device 1 may receive the code by using a camera. A user may access the mobile wallet application in the mobile device 1 and request that a payment is made. Upon scanning or taking a picture of the code that is displayed on the POS device 40 at step 503, the mobile device 1 may transmit the code to the mobile wallet bank 10 at step 504. Next, at step 505, the mobile wallet bank computer system 10 sends the code to the messaging hub computer system 20. The messaging hub computer system 20, at step 506, sends the code to the recipient bank system 30. At step 507, the recipient bank system 30 determines the validity of the code and also determines the whether the codes is expired, not previously used, etc. The recipient bank system 30 accesses the database and determines the merchant identification for the POS device 40. The merchant identification is transmitted from the recipient bank system 30 to the messaging hub computer system 20 and the messaging hub computer system 20 transmits the merchant identification to the mobile wallet bank computer system 10. The mobile wallet bank computer system 10 receives the merchant identification and the transaction code.
At step 508, the mobile wallet bank computer system 10 sends the payment information regarding user demand deposit account and any stored merchant loyalty information to the messaging hub computer system 20. Next, at step 509, the recipient bank system 30 may transmit the loyalty information to the POS device 40 to be displayed for the user. Next, at step 510, based on the loyalty information, the final transaction amount is determined by the POS device 40 and transmitted to the recipient bank computer system 40. The POS device 40 and the recipient bank computer system 40 may transmit the final transaction amount to the messaging hub computer system 20, at step 510. The messaging hub computer system 20 may process the transaction between the user identified demand deposit account and the merchant demand deposit account after receiving the transaction amount, at step 511. In some embodiments, the messaging hub computer system 20 may receive the funds equaling the transaction amount from the demand deposit account of the user. Next at step 511, the received funds may be transferred to the recipient bank demand deposit account. In another embodiment, the funds may be transferred using an ACH process to the demand deposit account held by the recipient.
At step 512, the messaging hub computer system 20 sends the approval or denial is transmitted to the POS device 40. Next, at step 513, the POS device 40 prints a receipt or sends a receipt to the user. Next, at step 514, the recipient bank system 30 sends an approval and/or decline message to the mobile wallet bank 10 via a messaging hub computer system 20. The mobile wallet bank system 10 transmits a notification to inform the mobile device 1 regarding the approval or denial decisions at step 515.
FIG. 6 illustrates a process implemented by the payment processing system of FIG. 1. In the embodiment shown in FIG. 6, the credit card issuer bank is different than the mobile wallet application provider. In FIGS. 6 and 7, for simplicity mobile device 1 and mobile wallet bank computer system 10 are shown as being combined, but it will be appreciated that they operate in a manner that is similar to FIGS. 4, and 5. Table 3 below describes the messages that are transmitted in various steps and the content of the messages from FIG. 6. FIG. 7 illustrates a process implemented by the payment processing system of FIG. 1. Table 3 refers to the steps from FIG. 6. However, the steps from FIG. 7 may use similar messages and routing as shown in FIG. 6. In the embodiment shown in FIGS. 6 and 7, the credit card issuer bank is a separate entity than the mobile wallet application provider. Unlike FIG. 6, the POS device 40 initiates the process of FIG. 7. The steps shown in FIG. 7 transmit similar data as the step described for FIG. 6. Table 3 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIGS. 6 and 7. The messaging hub that is referred to in Table 3 has the messaging hub computer system 20 from FIGS. 6 and 7. The beta issuer that is referred to in Table 3 may operate or signify the card issuer computer system 50 from FIGS. 6 and 7. The POS scanner referred to in Table 3 is shown in FIGS. 6 and 7 as POS device 40. The recipient bank computer 30 shown in FIGS. 6 and 7 is discussed in Table 3 as the gamma acquirer.
TABLE 3
Msg
Routing
Step number - Msg Routing Info
Step Name Step Description Info (TO) (FROM) Payload
601 - Customer Consumer of Alpha
requests a Wallet or Alpha wallet
Dynamic Token makes a request for a
(DT) Dynamic token using a
previously provisioned
Payment Identifier.
User selects Payment
Identifier associated with
the underlying payment
method.
602 - Dynamic Alpha Wallet sends II: Issuer WUI: PI: Payment
Token (DT) request for Dynamic Identifier Wallet Identifier
request sent to Token to the Messaging User Info
Messaging Hub Hub WPI:
(MH) Wallet
Platform
Info
603 - Dynamic Messaging Hub (MH) II: Issuer WUI: PI: Payment
Token (DT) passes request for Identifier Wallet Identifier
request sent to Dynamic Token (DT) to User Info
Beta Issuer the appropriate Issuer. WPI:
Wallet
Platform
Info
604 - Beta issuer Beta issuer generates a WUI: Wallet II: Issuer DT: Dynamic
generates Dynamic Token in User Info Identifier Token.
Dynamic Token Track 1 or 2 format and WPI: Wallet
and sends back to sends it back to the MH Platform Info
the MH (Messaging Hub)
(Messaging The Dynamic Token is in
Hub) Track 1 or Track 2
format and includes
issuer specific info,
dynamic data and the last
4 digits of the underlying
payment type.
605 - MH sends MH sends the Dynamic WUI: Wallet II: Issuer DT: Dynamic
the Dynamic Token (DT) to the Alpha User Info Identifier Token
Token (DT) to Wallet. WPI: Wallet
the Alpha Wallet Platform Info
606 - POS The Alpha Wallet will via scan via scan DT: Dynamic
Scanner reads or either display the Token
accepts the DT Dynamic Token as a QR
Code for scanning by the
POS or transmit the
Dynamic Token to the
POS via other
communication methods.
Other communication
methods may include
NFC, Bluetooth,
Hypersonic or other
communication
technologies
607 - POS sends Once the final purchase II: Issuer MID: DT: Dynamic
final purchase amount is calculated, the Identifier as Merchant Token
amount and DT POS will send the part of the ID
to Gamma Dynamic Token (Track 1 DT Dynamic
Acquirer or 2 Data) to its existing Token
acquirer/processor
608 - Gamma The Gamma Acquirer II: Issuer AID: DT: Dynamic
Acquirer sends reads the II as part of the Identifier as Acquirer Token
DT to MH Dynamic Token and part of the ID
sends the DT to the MH DT Dynamic MID:
Token Merchant
ID
MRI:
Merchant
Registry
Info
609 - MH The MH reads the II as II: Issuer AID: DT: Dynamic
receives DT and part of the Dynamic Identifier as Acquirer Token
routes to the Beta Token, recognizes it as part of the ID
Issuer an II and sends the DT to DT Dynamic MID:
the Beta Issuer. Token Merchant
ID
610 - Beta Issuer Beta issuer matches the CRI:
confirms the DT to the original PI that Consumer's
DT's validity and was associated with the Registry Info
retrieves the DT and then identifies
Consumer's the Consumer's Registry
Registry Info Info
611 - Beta Issuer AID: II: Issuer CRI:
sends the Acquirer ID Identifier Consumer's
Consumer's MID: Registry Info
Registry Info to Merchant ID
the MH
612 - MH MH triggers money
triggers money movement from the
movement Consumer's DDA to the
Merchant's DDA upon
knowing the Final
Purchase Amount, the
CRI and the MRI. This
is where the money
movement occurs.
613 - MH sends MH sends II AID: MH Approve/Decline
Approval/Decline Approval/Decline to Acquirer ID
to Gamma Gamma Acquirer based MID:
Acquirer upon the AID/ MID. Merchant ID
This results in
authorization and
settlement.
614 - Gamma Gamma Acquirer sends MID: MH Approve/Decline
Acquirer sends Approval/Decline to the Merchant ID
Approval/Decline POS based upon the MID
to the POS
615 - POS prints Approve/Decline
receipt
616 - MH sends MH sends WUI: Wallet MH Approve/Decline
Approval/Decline Approval/Decline to User Info
to Alpha Wallet Alpha Wallet based upon WPI: Wallet
WUI and WPI Platform
Info
617 - Alpha Alpha Wallets sends an
Wallets sends an email and push
email and push notification to the Alpha
notification to the Wallet User
Alpha Wallet
User
FIG. 8 illustrates a process implemented by the payment processing system of FIG. 1 to process a refund transaction between a user and a merchant. In the embodiment shown in FIG. 8, the credit card issuer bank is different than the mobile wallet application provider. Table 4 below describes the messages that are transmitted in various steps and the content of the messages from FIG. 8. Table 4 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIG. 8. The messaging hub that is referred to in Table 4 has the messaging hub computer system 20 from FIG. 8. The beta issuer that is referred to in Table 4 may operate or signify the card issuer computer system 50 from FIG. 8. The POS scanner referred to in Table 4 is shown in FIG. 8 as POS device 40. The recipient bank computer 30 shown in FIG. 8 is discussed in Table 4 as the gamma acquirer.
TABLE 4
Msg
Msg Routing
Routing Info
Step Name Step Description Info (TO) (FROM) Payload
801 - Customer Consumer of Alpha Wallet N/A N/A PUDT
requests a or Alpha wallet identifies a
Previously Used Previously Used Dynamic
Dynamic Token token on the wallet server.
(PUDT) for a
specific
transaction on the
Wallet.
802 - POS Scanner The Alpha Wallet will n/a - via n/a - via PUDT
is set to Refund either display the scan scan
mode and reads or Previously Used Dynamic
accepts the PUDT Token as a QR Code for
scanning by the POS or
transmit the Dynamic
Token to the POS via other
communication methods.
Other communication
methods may include NFC,
Bluetooth, Hypersonic or
other communication
technologies
803 - POS sends POS will send the II: Issuer MID: PUDT
the refund amount Previously Used Dynamic Identifier Merchant
and PUDT to Token ( Track 1 or 2 Data) as part of ID
Gamma Acquirer to its existing the PUDT
acquirer/processor.
This will be flagged as a
refund transaction.
804 - Gamma The Gamma Acquirer reads II: Issuer AID: PUDT
Acquirer sends the II as part of the PUDT Identifier Acquirer
PUDT to CE and sends the PUDT to the as part of ID
CE. the PUDT MID:
This will be flagged as a Dynamic Merchant
refund transaction. Token ID
805 - CE receives The CE reads the II as part II: Issuer AID: PUDT
DT and routes to of the PUDT, recognizes it Identifier Acquirer
the Beta Issuer as a Beta II and sends the as part of ID
PUDT to the Beta Issuer. the PUDT MID:
This will be flagged as a Merchant
refund transaction. ID
806 - Beta Issuer Beta issuer matches the n/a n/a ACN/UPC:
confirms the PUDT to the original PI that Actual Card
PUDT's validity was associated with the Number/
and retrieves the PUDT and then determines Underlying
actual card the underlying payment Payment
number/underlying credential. Credential
payment credential This will be flagged as a
that was used for refund transaction.
the initial
purchase.
807 - Beta Issuer AID: II: Issuer ACN/UPC:
sends the Acquirer ID Identifier Actual Card
ACN/UPC to the MID: Number/
CE Merchant Underlying
ID Payment
Credential
808 - CE Sends the CE looks at the AID AID: II: Issuer ACN/UPC:
ACN/UPC to the associated with the message Acquirer ID Identifier Actual Card
Gamma Acquirer and sends the ACN/UPC to MID: Number/
the appropriate acquirer. Merchant Underlying
ID Payment
Credential
809 - Gamma Gamma Acquirer processes n/a n/a ACN/UPC:
Acquirer a refund using the Actual Card
processes a refund ACN/UPC via its existing Number/
using the process Underlying
ACN/UPC Payment
Credential
810 - Gamma Existing process Approve/Decline
Acquirer sends
Refund
Approve/Decline
to the POS
811 - POS prints Existing process Approve/Decline
receipt as normal
812 - Gamma Gamma Acquirer sends II: Issuer AID: Approve/Decline
Acquirer sends Approval/Decline to CE Identifier Acquirer
Approval/Decline based upon the II ID
to CE MID:
Merchant
ID
813 - CE sends CE sends Approval/Decline II: Issuer AID: Approve/Decline
Approval/Decline to the Alpha Wallet based Identifier Acquirer
to the Alpha upon the II ID
Wallet MID:
Merchant
ID
814 - Alpha Alpha Wallets sends an
Wallets sends an email and push notification
email and push to the Alpha Wallet User
notification to the
Alpha Wallet User
The arrangement shown in FIG. 8 includes mobile device 1, messaging hub 20, recipient bank computer 30, POS device 40, and card issuer computer system 50. At step 801, the mobile device 1 may be operated by a user to request a previously used dynamic token that was used to complete a transaction, e.g., between the user and a recipient merchant. For example, the user may be presented with a display that shows previous transactions that the user of the mobile device 1 has transacted. The user may select one of the previous transactions in order to identify the dynamic token to be requested. In various embodiments, the user may be provided with the ability to search for the transaction, e.g., by searching for the name of the recipient merchant, by searching for transaction amounts within a specified dollar range, by scrolling through a historical list of transactions, or by searching using another criterion. In some embodiments, the previously used dynamic tokens may be stored on the mobile device 1, the mobile wallet bank computer system 10, the messaging hub 20, or in another location. Once the previous transaction is identified, the previously used dynamic token for the identified transaction may be retrieved from the memory of the mobile device 1, storage of the mobile wallet bank computer system 10 or the messaging hub 20, depending on where the dynamic token is stored. In various embodiments, for each previous transaction, if the associated dynamic token is not stored on the mobile device 1 or a cloud based storage that is accessible by the mobile device 1, then the location of the dynamic token is stored on the mobile device 1 or the cloud based storage.
At step 802, when the user requests a refund for a transaction, the POS device 40 may be set to refund mode to read or accept the previously used dynamic token. The mobile device 1 may communicate the previously used dynamic token to the POS device 40. For example, the mobile device 1 may display the previously used dynamic token as a QR code for a scan by the POS device 40 or transmit the dynamic token to the POS device 40 via other means of communications. Such other communication methods may include, for example, near field communication (NFC), Bluetooth, Hypersonic or other communication technologies. The message routing information in step 802 may be the previously used dynamic token being scanned or transmitted by or from the POS scanner 40 or the mobile device 1.
Next, at step 803, the POS device 40 may send the previously used dynamic token to the recipient bank computer 30. The POS device 40 may determine the amount of funds that were transferred using the previously used dynamic token. In some embodiments, determining the amount of funds may include accessing a database using the previously used dynamic token to identify a transaction and retrieving the transaction amount from the database. The transaction amount and the previously used dynamic token may be sent to the recipient bank computer 30 in a message that identifies the transaction as being a refund transaction. The previously used dynamic token may comprise track 1 and track 2 data. The message to the recipient bank computer 30 may include a merchant identifier and an issuer identifier that identifies the issuer of the credit card that was used for the original transaction. In some embodiments, the issuer identifier may be part of the previously used dynamic token.
At step 804, after receiving the previously used dynamic token, the recipient bank computer 30 may send the previously used dynamic token including the issuer identifier to the messaging hub 20. The information that is sent to the messaging hub 20 may include an acquirer identifier and a merchant identifier from the recipient bank computer 30. Providing the acquirer identifier and the merchant identifier allows the messaging hub 20 to identify the recipient bank computer 30 when sending the refund at step 808.
At step 805, the messaging hub 20 receives the previously used dynamic token and routes the previously used dynamic token to the card issuer computer system 50. The messaging hub 20 determines the identity of the card issuer computer system 50. The messaging hub 20 reads a portion of the previously used dynamic token to determine which card issuer computer system 50 should receive the dynamic token. Moreover, the messaging hub 20 may additionally flag the transaction as a refund transaction to the card issuer computer system 50 in one embodiment.
Next, at step 806, the card issuer computer system 50 may confirm the previously used dynamic token's validity and retrieve the actual card number/underlying payment credential that was used for the original purchase transaction. In one embodiment, the card issuer computer system 50 matches the previously used dynamic token to the original payment identifier that was associated with the previously used dynamic token and determines the underlying payment credential. The card issuer computer system 50 may determine the actual card number and/or the underlying payment credentials.
At step 807, after identifying the actual card number or underlying payment credentials, the card issuer computer system 50 sends the actual card number or underlying payment credentials, acquirer identifier, merchant identifier and issuer identifier to the messaging hub 20. The actual card number/underlying payment credential allows the messaging hub 20 or the recipient bank computer 30 to process a refund from the card issuer computer system 50 to the payor of the mobile device 1. The results from step 806 may be sent by the card issuer computer system 50 to the messaging hub 20.
At step 808, the messaging hub 20 may send the actual card number or the payment credentials to the recipient bank computer 30 in order to process a refund using the actual card number or the payment credentials. The messaging hub 20 determines the acquirer identifier associated with the recipient bank computer 30. The messaging hub 20 sends the actual card number or the underlying payment credential to the appropriate acquirer. In some embodiments, the message may be sent to the recipient bank computer 30 to process the refund.
Next, at step 809, the recipient bank computer 30 may process a refund using the actual card number or the underlying payment credentials. In one embodiment, the recipient bank computer 30 may process the refund to the account of the actual card number. In another embodiment, the owner of the mobile wallet or the mobile device 1 may be provided with store credit that will be honored at the POS device 40. In another embodiment, a gift card identifier number may be transmitted to the mobile wallet bank computer 10.
At step 810, the recipient bank computer 30 may send a refund approval/decline to a POS device 40 or other POS computers. At step 811, assuming an approval is sent, a refund receipt may be printed at the POS device 40. In other embodiments, the refund may also be declined for various reasons by the POS device 40. For example, a refund may be declined based on the policies that are specified by the owner of the POS device 40. When the refund is declined a receipt may be printed that informs the payor the reason or reasons for the refund being declined. In other embodiments, the reasons for the refund decision may be sent to the mobile device 1 via the messaging hub 20.
At step 812, the approval/decline decision may be sent to the messaging hub 20 by the recipient bank computer 30. In some embodiments, at step 812 the recipient bank computer 30 includes the issuer identifier, acquirer identifier and the merchant identifier with the approval or decline decision.
At step 813, the approval/decline decision may be received by the messaging hub 20 and the approval/decline decision message may be sent to the mobile wallet bank computer 10. The mobile wallet bank computer system 10 may transmit the decision to the mobile device 1. In some embodiments, the content of the message may include the issuer identifier, acquirer identifier, merchant identifier and the approval/decline decision.
Next at step 814, the software on mobile device 1 or mobile wallet bank computer 10 may send an e-mail or push notification to the mobile wallet application. The approval or decline decision may be stored on the mobile device 1.
In other embodiments, the refund functionality described above in FIG. 8 may also be used to offer refunds for recurring transactions that occur periodically. These transactions can occur using various payment types, such as but not limited to, demand deposit account, debit card, credit card or other forms of payment. For recurring transactions, the system described above may be configured to have a persistent token (e.g. special token or specially flagged token) that does not expire or can be used multiple times. For example, in the case of a recurring cable company bill, the cable company may use the same token on a periodic basis (e.g. monthly, yearly, weekly or quarterly). The merchant (in this example, the cable company) may retain the recurring token and present the same token for funds. In other embodiments, the messages for a persistent token may include a flag during the debit/credit charge that identifies the token as a recurring token.
In other examples, at the end of the recurring transaction relationship, the messaging hub computer system 20 may send a message to the merchant to deactivate the recurring token and discard the token. In other embodiments, the messaging hub computer system 20 may update its storage records such that, when a transaction is initiated using a deactivated recurring token, the messaging hub computer system 20 informs the issuing bank computer system 50 that an attempt to use a deactivated recurring token has been initiated.
The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings. The present embodiments contemplate methods, systems and program products on any machine-readable media for accomplishing its operations. The embodiments may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired system.
As noted above, embodiments within the scope of this disclosure include program products comprising non-transitory machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.
Embodiments have been described in the general context of method steps which may be implemented in one embodiment by a program product including machine-executable instructions, such as program code, for example in the form of program modules executed by machines in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
As previously indicated, embodiments may be practiced in a networked environment using logical connections to one or more remote computers having processors. Those skilled in the art will appreciate that such network computing environments may encompass many types of computers, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and so on. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The system memory may include read only memory (ROM) and random access memory (RAM). The computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer. It should also be noted that the word “terminal” as used herein is intended to encompass computer input and output devices. Input devices, as described herein, include a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. The output devices, as described herein, include a computer monitor, printer, facsimile machine, or other output devices performing a similar function.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the software and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.

Claims (12)

What is claimed is:
1. A computer-implemented method, comprising: transmitting, by a recipient bank computer system to a messaging hub computer system, a refund transaction request received from a mobile wallet bank computer associated with a payor, the refund transaction request regarding a previous transaction between a merchant and the payor, the messaging hub computer system serving as an intermediary between the recipient bank computer system and a card issuer computer system, the refund transaction request comprising (i) a previously used dynamic token to facilitate identification of the card issuer computer system based on a portion of the previously used dynamic token, (ii) a refund transaction amount, and (iii) an indication that the transaction is a refund transaction; responsive to the identification, receiving, by the recipient bank computer system, underlying payment credential information from the card issuer computer system via the messaging hub computer system, the underlying payment credential information retrieved from the card issuer computer system based on the previously used dynamic token, the underlying payment credential information utilized by the recipient bank computer system to facilitate routing of the refund transaction, wherein the underlying payment credential information is associated with an account held by the payor that was used for the previous transaction; and transferring, by the recipient bank computer system, the refund from an account held by the merchant to the account held by the payor identified using the underlying payment credential information.
2. The method of claim 1, further comprising receiving, by the recipient bank computer system, the refund transaction request for the previous transaction from a POS device (Point of Sale), the request comprising the previously used dynamic token, the refund transaction amount, and the indication that the transaction is a refund transaction.
3. The method of claim 1, wherein the underlying payment credentials transmitted to the recipient bank computer comprises an actual card number or the demand deposit account number.
4. The method of claim 1, wherein the underlying payment credential information is received by only the recipient bank computer system.
5. The method of claim 2, wherein the recipient bank computer system transmits an approval for the refund transaction to the POS device.
6. The method of claim 2, further comprising: transmitting, by the recipient bank computer system, loyalty information to the POS device; and receiving, by the recipient bank computer system, a final transaction amount related to the loyalty information from the POS device.
7. The method of claim 2, further comprising: receiving, by the recipient bank computer system, loyalty information and payment information from the messaging hub computer system; transmitting, by the recipient bank computer system, the loyalty information to the POS device; receiving, by the recipient bank computer system, a final transaction amount related to the loyalty information from the POS device; and processing, by the recipient bank computer system, the refund transaction using the payment information received from the messaging hub computer system.
8. The method of claim 2, further comprising providing, by the recipient bank computer system, an indication whether the refund transaction is approved or declined to the POS device.
9. The method of claim 1, further comprising providing, by the recipient bank computer system, an indication whether the refund transaction is approved or declined through the messaging hub computer system.
10. The method of claim 2, further comprising: receiving, by the recipient bank computer system a request for a numerical code from the POS device; creating, by the recipient bank computer system, the numerical code; and sending, by the recipient bank computer system, the numerical code to the POS device.
11. The method of claim 2, further comprising: receiving, by the recipient bank computer system, a numerical code from the messaging hub computer system; determining, by the recipient bank computer system, validity of the numerical code and if the numerical code is expired or has been previously used; determining, by the recipient bank computer system, merchant identification for the POS device; and
transmitting, by the recipient bank computer system, the merchant identification to the messaging hub computer system.
12. The method of claim 1, wherein the request further comprises a merchant identifier and an issuer identifier that identifies an issuer of a credit card that was used for the previous transaction.
US14/030,929 2012-12-17 2013-09-18 Interoperable mobile wallet refund Active 2035-03-03 US9715689B1 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US14/030,929 US9715689B1 (en) 2012-12-17 2013-09-18 Interoperable mobile wallet refund
US15/374,925 US10049355B1 (en) 2012-12-17 2016-12-09 Interoperable mobile wallet refund
US15/423,449 US9972012B1 (en) 2012-12-17 2017-02-02 Interoperable mobile wallet refund
US15/975,478 US10580008B1 (en) 2012-12-17 2018-05-09 Interoperable mobile wallet refund
US16/101,133 US10769621B1 (en) 2012-12-17 2018-08-10 Interoperable mobile wallet refund
US16/806,893 US11361307B1 (en) 2012-12-17 2020-03-02 Interoperable mobile wallet refund
US17/011,902 US11514433B1 (en) 2012-12-17 2020-09-03 Systems and methods for facilitating transactions using codes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261738376P 2012-12-17 2012-12-17
US14/030,929 US9715689B1 (en) 2012-12-17 2013-09-18 Interoperable mobile wallet refund

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/374,925 Division US10049355B1 (en) 2012-12-17 2016-12-09 Interoperable mobile wallet refund
US15/423,449 Division US9972012B1 (en) 2012-12-17 2017-02-02 Interoperable mobile wallet refund

Publications (1)

Publication Number Publication Date
US9715689B1 true US9715689B1 (en) 2017-07-25

Family

ID=59350381

Family Applications (10)

Application Number Title Priority Date Filing Date
US13/831,577 Active US10592888B1 (en) 2012-12-17 2013-03-15 Merchant account transaction processing systems and methods
US14/030,929 Active 2035-03-03 US9715689B1 (en) 2012-12-17 2013-09-18 Interoperable mobile wallet refund
US15/374,925 Active US10049355B1 (en) 2012-12-17 2016-12-09 Interoperable mobile wallet refund
US15/423,449 Active US9972012B1 (en) 2012-12-17 2017-02-02 Interoperable mobile wallet refund
US15/975,478 Active 2034-01-04 US10580008B1 (en) 2012-12-17 2018-05-09 Interoperable mobile wallet refund
US16/101,133 Active 2034-01-09 US10769621B1 (en) 2012-12-17 2018-08-10 Interoperable mobile wallet refund
US16/800,953 Active US11797969B1 (en) 2012-12-17 2020-02-25 Merchant account transaction processing systems and methods
US16/806,893 Active 2033-09-28 US11361307B1 (en) 2012-12-17 2020-03-02 Interoperable mobile wallet refund
US17/011,902 Active 2033-11-28 US11514433B1 (en) 2012-12-17 2020-09-03 Systems and methods for facilitating transactions using codes
US18/382,967 Pending US20240054480A1 (en) 2012-12-17 2023-10-23 Merchant account transaction processing systems and methods

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US13/831,577 Active US10592888B1 (en) 2012-12-17 2013-03-15 Merchant account transaction processing systems and methods

Family Applications After (8)

Application Number Title Priority Date Filing Date
US15/374,925 Active US10049355B1 (en) 2012-12-17 2016-12-09 Interoperable mobile wallet refund
US15/423,449 Active US9972012B1 (en) 2012-12-17 2017-02-02 Interoperable mobile wallet refund
US15/975,478 Active 2034-01-04 US10580008B1 (en) 2012-12-17 2018-05-09 Interoperable mobile wallet refund
US16/101,133 Active 2034-01-09 US10769621B1 (en) 2012-12-17 2018-08-10 Interoperable mobile wallet refund
US16/800,953 Active US11797969B1 (en) 2012-12-17 2020-02-25 Merchant account transaction processing systems and methods
US16/806,893 Active 2033-09-28 US11361307B1 (en) 2012-12-17 2020-03-02 Interoperable mobile wallet refund
US17/011,902 Active 2033-11-28 US11514433B1 (en) 2012-12-17 2020-09-03 Systems and methods for facilitating transactions using codes
US18/382,967 Pending US20240054480A1 (en) 2012-12-17 2023-10-23 Merchant account transaction processing systems and methods

Country Status (1)

Country Link
US (10) US10592888B1 (en)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140351126A1 (en) * 2013-05-22 2014-11-27 Seth Priebatsch Secure synchronization of payment accounts to third-party applications or websites
US20140351132A1 (en) * 2013-05-22 2014-11-27 Google Inc. Returns handling in a prepaid architecture
US20160239837A1 (en) * 2015-02-18 2016-08-18 Apriva, Llc Method and system for facilitating a payment transaction with a mobile payment server
US9870556B2 (en) 2013-05-22 2018-01-16 Google Llc Split tender in a prepaid architecture
US10049352B2 (en) * 2015-02-18 2018-08-14 Apriva, Llc Method and system for processing a mobile payment transaction
US20190057383A1 (en) * 2017-08-17 2019-02-21 Mastercard International Incorporated Method and system for chargeback prevention
US20190108582A1 (en) * 2017-10-09 2019-04-11 Mastercard International Incorporated Systems and methods for refunding qr and other payment system transactions
WO2019107907A1 (en) * 2017-11-30 2019-06-06 삼성전자 주식회사 Electronic device for controlling electronic payment and method therefor
US10325261B2 (en) * 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
US10410194B1 (en) 2015-08-19 2019-09-10 Square, Inc. Customized tipping flow
US10510066B2 (en) * 2018-05-01 2019-12-17 Robert R. Lovett ATM replacement using two mobile devices
US20200234277A1 (en) * 2019-01-22 2020-07-23 Vaughn Dabney Systems and methods for processing encoded symbols to facilitate secured communication between database systems of two entities and to update database tuples associated with the database systems
US20200394323A1 (en) * 2018-03-28 2020-12-17 Visa International Service Association Untethered resource distribution and management
US11049090B2 (en) * 2015-03-11 2021-06-29 Paypal, Inc. NFC application registry for enhanced mobile transactions and payments
US11144895B2 (en) * 2015-05-01 2021-10-12 Pay2Day Solutions, Inc. Methods and systems for message-based bill payment
US11295308B1 (en) * 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US20220343380A1 (en) * 2019-11-07 2022-10-27 Visa International Service Association Seamless interaction processing with data security
US20220351203A1 (en) * 2019-06-21 2022-11-03 Harexinfotech Inc. Payment service system
US11636462B2 (en) 2015-03-20 2023-04-25 Block, Inc. Context-aware peer-to-peer transfers of items

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11488090B2 (en) 2008-02-01 2022-11-01 Mapmyid, Inc. Address exchange systems and methods
US11605045B2 (en) 2012-09-07 2023-03-14 MapMyld, Inc. Address exchange systems and methods
EP4211639A1 (en) * 2020-09-09 2023-07-19 Mapmyid, Inc. Address exchange systems and methods
US11935031B2 (en) * 2020-12-15 2024-03-19 Visa International Service Association Two-dimensional code compatibility system

Citations (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5943423A (en) * 1995-12-15 1999-08-24 Entegrity Solutions Corporation Smart token system for secure electronic transactions and identification
US6173272B1 (en) 1998-04-27 2001-01-09 The Clearing House Service Company L.L.C. Electronic funds transfer method and system and bill presentment method and system
US6327578B1 (en) 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US20020161645A1 (en) 2001-04-10 2002-10-31 Walker Jay S. Method and apparatus for offering forward commitment agreements
US20020194080A1 (en) 2001-06-19 2002-12-19 Ronald Lourie Internet cash card
US20020194128A1 (en) * 2001-06-14 2002-12-19 Michael Maritzen System and method for secure reverse payment
US20030042301A1 (en) * 2001-08-31 2003-03-06 Sanguthevar Rajasekaran Enhancements to multi-party authentication and other protocols
US20040153402A1 (en) * 2001-09-24 2004-08-05 E2Interactive, Inc. D/B/A E2Interactive, Inc. System and method for conducting a refund transaction for a pin-activated account
US20040167854A1 (en) * 2003-02-21 2004-08-26 Knowles W. Jeffrey System and method of currency conversion in financial transaction process
US20050125343A1 (en) 2003-12-03 2005-06-09 Mendelovich Isaac F. Method and apparatus for monetizing personal consumer profiles by aggregating a plurality of consumer credit card accounts into one card
US20060054695A1 (en) 2002-04-23 2006-03-16 Hiroshi Owada Dynamic bar code display apparatus, dynamic bar code generation method, and storage medium generation dynamic bar code
US20060116940A1 (en) 2004-11-30 2006-06-01 Dippold Robert E System and method for order purchasing and fulfillment
US20070033070A1 (en) 2005-07-25 2007-02-08 Beck G D System and method for collecting payments from service recipients
US20070267479A1 (en) * 2006-05-16 2007-11-22 Chockstone, Inc. Systems and methods for implementing parking transactions and other financial transactions
US20070276765A1 (en) * 2004-09-07 2007-11-29 Hazel Patrick K Method and system for secured transactions
US20080183621A1 (en) 2007-01-28 2008-07-31 Evans Steven D Payer direct hub
US20080207203A1 (en) 2007-02-22 2008-08-28 First Data Corporation Enrollment and registration of a device in a mobile commerce system
US20080208744A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Mobile commerce systems and methods
US7433845B1 (en) * 1999-04-13 2008-10-07 Orbis Patents Limited Data structure, method and system for generating person-to-person, person-to-business, business-to-person, and business-to-business financial transactions
US20090048953A1 (en) * 2007-08-16 2009-02-19 Patrick Hazel Metrics systems and methods for token transactions
US7502761B2 (en) 2006-02-06 2009-03-10 Yt Acquisition Corporation Method and system for providing online authentication utilizing biometric data
US20090112747A1 (en) 2007-10-30 2009-04-30 Visa U.S.A. Inc. System and Method For Processing Multiple Methods of Payment
US7543738B1 (en) 2001-07-10 2009-06-09 American Express Travel Related Services Company, Inc. System and method for secure transactions manageable by a transaction account provider
US20100145860A1 (en) 2008-12-08 2010-06-10 Ebay Inc. Unified identity verification
US20100153273A1 (en) 2006-02-08 2010-06-17 Imagineer Software, Inc. Systems for performing transactions at a point-of-sale terminal using mutating identifiers
US20100217710A1 (en) * 2007-04-06 2010-08-26 Nec Corporation Electronic money system and electronic money transaction method
US20100306168A1 (en) 2009-06-01 2010-12-02 Nima Ostad Transaction data capture devices and related methods
US20100312704A1 (en) * 2008-04-08 2010-12-09 Mobidough, Inc Method and Apparatus for On Demand Generation, Use and Transfer of Virtual Financial Instruments
US20110087537A1 (en) * 2008-04-08 2011-04-14 Waleed Hanafi Refund system and method
US20110137797A1 (en) 2008-05-30 2011-06-09 Luc Stals Server Device for Controlling a Transaction, First Entity and Second Entity
US20110161233A1 (en) * 2009-12-30 2011-06-30 First Data Corporation Secure transaction management
US20110191250A1 (en) 1999-08-31 2011-08-04 American Express Travel Related Services Company, Inc. Methods and Apparatus for Conducting Electronic Transactions
US20110258062A1 (en) * 2010-04-15 2011-10-20 Boku, Inc. Systems and Methods to Provide Credits via Mobile Devices
US20110276478A1 (en) 2010-05-06 2011-11-10 Boku, Inc. Systems and Methods to Manage Information
US20120011072A1 (en) * 2006-12-29 2012-01-12 Nokia Corporation Method, System, And Computer Program Product For Facilitating Post-Sale Transactions Using Mobile Devices
US20120035997A1 (en) * 2010-08-04 2012-02-09 Clovr Media, Inc. Consumer offer redemption methods and systems
US20120185322A1 (en) * 2011-01-13 2012-07-19 Mark Shipley System and method for providing a rebate card from a kiosk
US20120203700A1 (en) * 2010-12-10 2012-08-09 Electronic Payment Exchange Tokenized contactless payments for mobile devices
US20120259698A1 (en) 2011-04-11 2012-10-11 Yurow A Pierre Electronic Currency Management System
US20120259782A1 (en) * 2011-04-11 2012-10-11 Ayman Hammad Multiple tokenization for authentication
US20120271660A1 (en) * 2011-03-04 2012-10-25 Harris Theodore D Cloud service facilitator apparatuses, methods and systems
US20120290376A1 (en) 2011-05-09 2012-11-15 Intuit Inc. Processing electronic payment involving mobile communication device
US20120316992A1 (en) * 2011-06-07 2012-12-13 Oborne Timothy W Payment privacy tokenization apparatuses, methods and systems
US20120323786A1 (en) 2011-06-16 2012-12-20 OneID Inc. Method and system for delayed authorization of online transactions
US20130080318A1 (en) * 2008-12-23 2013-03-28 Matthew G. Katz System and method for providing dispute resolution for electronic payment transactions
US8417633B1 (en) * 2004-11-08 2013-04-09 Rockstar Consortium Us Lp Enabling improved protection of consumer information in electronic transactions
US20130103574A1 (en) * 2011-10-19 2013-04-25 First Data Corporation Payment Delegation Transaction Processing
US20130110658A1 (en) * 2011-05-05 2013-05-02 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
US20130151400A1 (en) 2011-12-13 2013-06-13 Oleg Makhotin Integrated mobile trusted service manager
US20130198080A1 (en) * 2012-01-26 2013-08-01 Lisa Anderson System and method of providing tokenization as a service
US20130238492A1 (en) * 2012-03-07 2013-09-12 Clearxchange, Llc System and method for transferring funds
US20130238455A1 (en) * 2010-04-09 2013-09-12 Kevin Laracey Methods and systems for selecting accounts and offers in payment transactions
US20130246259A1 (en) * 2012-03-15 2013-09-19 Firethorn Mobile, Inc. System and method for managing payment in transactions with a pcd
US20130256403A1 (en) * 2012-03-23 2013-10-03 Wendy MacKinnon Keith System and Method for Facilitating Secure Self Payment Transactions of Retail Goods
US20130282588A1 (en) * 2012-04-22 2013-10-24 John Hruska Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System
US20130282589A1 (en) 2012-04-20 2013-10-24 Conductiv Software, Inc. Multi-factor mobile transaction authentication
US20130339253A1 (en) * 2011-08-31 2013-12-19 Dan Moshe Sincai Mobile Device Based Financial Transaction System
US20140006224A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation System for pre-processing sales returns
US20140032419A1 (en) * 2012-07-26 2014-01-30 Lisa Anderson Configurable payment tokens
US20140040148A1 (en) * 2012-07-31 2014-02-06 Mercury Payment Systems, Llc Systems and methods for arbitraged enhanced payment processing
US20140040131A1 (en) * 2012-07-31 2014-02-06 Mark William Andrews Matching refunds to payment instruments employed in a proxy card transaction
US20140114853A1 (en) * 2012-10-22 2014-04-24 Oonetic Online payment system and method according to the mirror authorization server principle
US20140143146A1 (en) * 2012-11-20 2014-05-22 Prakash George PASSANHA Systems and methods for generating and using a token for use in a transaction
US20140164243A1 (en) * 2012-12-07 2014-06-12 Christian Aabye Dynamic Account Identifier With Return Real Account Identifier
US20140344153A1 (en) * 2013-05-15 2014-11-20 Thanigaivel Ashwin Raj Mobile tokenization hub
US20140351070A1 (en) * 2013-05-22 2014-11-27 Cube, Co. Role-based transaction management system for multi-point merchants
US20140351132A1 (en) * 2013-05-22 2014-11-27 Google Inc. Returns handling in a prepaid architecture
US20150026070A1 (en) 2013-07-16 2015-01-22 Mastercard International Incorporated Systems and methods for correlating cardholder identity attributes on a payment card network to determine payment card fraud
US20150032627A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating token attributes associated with a token vault
US20150032622A1 (en) * 2013-07-29 2015-01-29 Mastercard International Incorporated Online credit returns method and apparatus
US9195984B1 (en) * 2011-08-16 2015-11-24 Jpmorgan Chase Bank, N.A. Systems and methods for processing transactions using a wallet
US9355393B2 (en) * 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems

Family Cites Families (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3571383B2 (en) * 1994-10-19 2004-09-29 株式会社日立製作所 IC card, IC card read / write device and electronic wallet system
US7257554B1 (en) * 1999-03-19 2007-08-14 Hewlett-Packard Development Company, L.P. Anonymous purchases while allowing verifiable identities for refunds returned along the paths taken to make the purchases
US6424953B1 (en) * 1999-03-19 2002-07-23 Compaq Computer Corp. Encrypting secrets in a file for an electronic micro-commerce system
US7080037B2 (en) 1999-09-28 2006-07-18 Chameleon Network Inc. Portable electronic authorization system and method
US6246769B1 (en) 2000-02-24 2001-06-12 Michael L. Kohut Authorized user verification by sequential pattern recognition and access code acquisition
US6938019B1 (en) 2000-08-29 2005-08-30 Uzo Chijioke Chukwuemeka Method and apparatus for making secure electronic payments
US20040077332A1 (en) 2002-02-08 2004-04-22 Dafna Ephraim Management of pre-paid billing system for wireless communication
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US20040143550A1 (en) 2002-12-19 2004-07-22 International Business Machines Corporation Cellular electronic wallet device and method
US20040193538A1 (en) 2003-03-31 2004-09-30 Raines Walter L. Receipt processing system and method
US7324976B2 (en) 2004-07-19 2008-01-29 Amazon Technologies, Inc. Automatic authorization of programmatic transactions
GB0503970D0 (en) 2005-02-25 2005-04-06 Firstondemand Ltd Method and apparatus for authentication of invoices
US20070250441A1 (en) 2006-04-25 2007-10-25 Uc Group Limited Systems and methods for determining regulations governing financial transactions conducted over a network
US8032414B2 (en) 2007-06-12 2011-10-04 Gilbarco Inc. System and method for providing receipts, advertising, promotion, loyalty programs, and contests to a consumer via an application-specific user interface on a personal communication device
US8527404B2 (en) 2007-07-19 2013-09-03 First Data Corporation Merchant-initiated adjustments
US20090204530A1 (en) 2008-01-31 2009-08-13 Payscan America, Inc. Bar coded monetary transaction system and method
US20090254479A1 (en) * 2008-04-02 2009-10-08 Pharris Dennis J Transaction server configured to authorize payment transactions using mobile telephone devices
US9195981B2 (en) 2008-10-23 2015-11-24 Ims Health Incorporated System and method for authorizing transactions via mobile devices
US20100125510A1 (en) 2008-11-17 2010-05-20 Smith Steven M System and method of conducting transactions using a mobile wallet system
US8600883B2 (en) 2008-12-02 2013-12-03 Ebay Inc. Mobile barcode generation and payment
US10354321B2 (en) 2009-01-22 2019-07-16 First Data Corporation Processing transactions with an extended application ID and dynamic cryptograms
US20110208600A1 (en) * 2010-02-25 2011-08-25 Seergate Ltd. Point of Sale Payment System and Method
US20110320345A1 (en) * 2010-06-29 2011-12-29 Ebay, Inc. Smart wallet
US8660948B2 (en) 2010-07-02 2014-02-25 Qualcomm Incorporated System and method for managing transactions with a portable computing device
JP5130387B2 (en) 2010-08-26 2013-01-30 東芝テック株式会社 Code reader and product information processing system
EP2437195A1 (en) * 2010-09-10 2012-04-04 Gemalto SA Method of analyzing the behavior of a secure electronic token
US20120084200A1 (en) 2010-10-01 2012-04-05 Michel Triana Systems and methods for completing a financial transaction
US20120109762A1 (en) 2010-11-03 2012-05-03 Verizon Patent And Licensing Inc. Method and apparatus for providing mobile payment through a device user interface
US20120130889A1 (en) 2010-11-19 2012-05-24 Mastercard International Incorporated Financial card method, device and system utilizing bar codes to identify transaction details
TWM410932U (en) 2010-12-13 2011-09-01 Mxtran Inc Mobile device capable of displaying barcode for electronic transaction and integrated circuit film thereof
US9123040B2 (en) 2011-01-21 2015-09-01 Iii Holdings 1, Llc Systems and methods for encoded alias based transactions
US10586227B2 (en) * 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US8616453B2 (en) 2012-02-15 2013-12-31 Mark Itwaru System and method for processing funds transfer between entities based on received optical machine readable image information
WO2012151660A1 (en) 2011-05-11 2012-11-15 Mark Itwaru Mobile image payment system
KR20200138828A (en) 2011-05-31 2020-12-10 블랙호크 네트워크, 아이엔씨. A system for payment via electronic wallet
US10482457B2 (en) * 2011-10-17 2019-11-19 Capital One Services, Llc System and method for token-based payments
US9208488B2 (en) * 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US9361619B2 (en) * 2012-08-06 2016-06-07 Ca, Inc. Secure and convenient mobile authentication techniques
GB2506421A (en) 2012-09-28 2014-04-02 Miura Systems Ltd Electronic receipt
US20140149285A1 (en) * 2012-11-29 2014-05-29 International Business Machines Corporation Effecting payments via mobile phones
US10453042B2 (en) * 2015-11-11 2019-10-22 Quisk, Inc. Token use for transactions in a payment system

Patent Citations (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5943423A (en) * 1995-12-15 1999-08-24 Entegrity Solutions Corporation Smart token system for secure electronic transactions and identification
US6173272B1 (en) 1998-04-27 2001-01-09 The Clearing House Service Company L.L.C. Electronic funds transfer method and system and bill presentment method and system
US6327578B1 (en) 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US7433845B1 (en) * 1999-04-13 2008-10-07 Orbis Patents Limited Data structure, method and system for generating person-to-person, person-to-business, business-to-person, and business-to-business financial transactions
US20110191250A1 (en) 1999-08-31 2011-08-04 American Express Travel Related Services Company, Inc. Methods and Apparatus for Conducting Electronic Transactions
US20020161645A1 (en) 2001-04-10 2002-10-31 Walker Jay S. Method and apparatus for offering forward commitment agreements
US20020194128A1 (en) * 2001-06-14 2002-12-19 Michael Maritzen System and method for secure reverse payment
US20020194080A1 (en) 2001-06-19 2002-12-19 Ronald Lourie Internet cash card
US7543738B1 (en) 2001-07-10 2009-06-09 American Express Travel Related Services Company, Inc. System and method for secure transactions manageable by a transaction account provider
US20030042301A1 (en) * 2001-08-31 2003-03-06 Sanguthevar Rajasekaran Enhancements to multi-party authentication and other protocols
US20040153402A1 (en) * 2001-09-24 2004-08-05 E2Interactive, Inc. D/B/A E2Interactive, Inc. System and method for conducting a refund transaction for a pin-activated account
US20060054695A1 (en) 2002-04-23 2006-03-16 Hiroshi Owada Dynamic bar code display apparatus, dynamic bar code generation method, and storage medium generation dynamic bar code
US20040167854A1 (en) * 2003-02-21 2004-08-26 Knowles W. Jeffrey System and method of currency conversion in financial transaction process
US20050125343A1 (en) 2003-12-03 2005-06-09 Mendelovich Isaac F. Method and apparatus for monetizing personal consumer profiles by aggregating a plurality of consumer credit card accounts into one card
US20070276765A1 (en) * 2004-09-07 2007-11-29 Hazel Patrick K Method and system for secured transactions
US8417633B1 (en) * 2004-11-08 2013-04-09 Rockstar Consortium Us Lp Enabling improved protection of consumer information in electronic transactions
US20060116940A1 (en) 2004-11-30 2006-06-01 Dippold Robert E System and method for order purchasing and fulfillment
US20070033070A1 (en) 2005-07-25 2007-02-08 Beck G D System and method for collecting payments from service recipients
US7502761B2 (en) 2006-02-06 2009-03-10 Yt Acquisition Corporation Method and system for providing online authentication utilizing biometric data
US20100153273A1 (en) 2006-02-08 2010-06-17 Imagineer Software, Inc. Systems for performing transactions at a point-of-sale terminal using mutating identifiers
US20070267479A1 (en) * 2006-05-16 2007-11-22 Chockstone, Inc. Systems and methods for implementing parking transactions and other financial transactions
US20120011072A1 (en) * 2006-12-29 2012-01-12 Nokia Corporation Method, System, And Computer Program Product For Facilitating Post-Sale Transactions Using Mobile Devices
US20080183621A1 (en) 2007-01-28 2008-07-31 Evans Steven D Payer direct hub
US20080207203A1 (en) 2007-02-22 2008-08-28 First Data Corporation Enrollment and registration of a device in a mobile commerce system
US20080208744A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Mobile commerce systems and methods
US20100217710A1 (en) * 2007-04-06 2010-08-26 Nec Corporation Electronic money system and electronic money transaction method
US20090048953A1 (en) * 2007-08-16 2009-02-19 Patrick Hazel Metrics systems and methods for token transactions
US20090112747A1 (en) 2007-10-30 2009-04-30 Visa U.S.A. Inc. System and Method For Processing Multiple Methods of Payment
US20110087537A1 (en) * 2008-04-08 2011-04-14 Waleed Hanafi Refund system and method
US20100312704A1 (en) * 2008-04-08 2010-12-09 Mobidough, Inc Method and Apparatus for On Demand Generation, Use and Transfer of Virtual Financial Instruments
US20110137797A1 (en) 2008-05-30 2011-06-09 Luc Stals Server Device for Controlling a Transaction, First Entity and Second Entity
US20100145860A1 (en) 2008-12-08 2010-06-10 Ebay Inc. Unified identity verification
US20130080318A1 (en) * 2008-12-23 2013-03-28 Matthew G. Katz System and method for providing dispute resolution for electronic payment transactions
US20100306168A1 (en) 2009-06-01 2010-12-02 Nima Ostad Transaction data capture devices and related methods
US20110161233A1 (en) * 2009-12-30 2011-06-30 First Data Corporation Secure transaction management
US20130238455A1 (en) * 2010-04-09 2013-09-12 Kevin Laracey Methods and systems for selecting accounts and offers in payment transactions
US20110258062A1 (en) * 2010-04-15 2011-10-20 Boku, Inc. Systems and Methods to Provide Credits via Mobile Devices
US20110276478A1 (en) 2010-05-06 2011-11-10 Boku, Inc. Systems and Methods to Manage Information
US20120035997A1 (en) * 2010-08-04 2012-02-09 Clovr Media, Inc. Consumer offer redemption methods and systems
US20120203700A1 (en) * 2010-12-10 2012-08-09 Electronic Payment Exchange Tokenized contactless payments for mobile devices
US20120185322A1 (en) * 2011-01-13 2012-07-19 Mark Shipley System and method for providing a rebate card from a kiosk
US20120271660A1 (en) * 2011-03-04 2012-10-25 Harris Theodore D Cloud service facilitator apparatuses, methods and systems
US20120259782A1 (en) * 2011-04-11 2012-10-11 Ayman Hammad Multiple tokenization for authentication
US20120259698A1 (en) 2011-04-11 2012-10-11 Yurow A Pierre Electronic Currency Management System
US20130110658A1 (en) * 2011-05-05 2013-05-02 Transaction Network Services, Inc. Systems and methods for enabling mobile payments
US20120290376A1 (en) 2011-05-09 2012-11-15 Intuit Inc. Processing electronic payment involving mobile communication device
US20120316992A1 (en) * 2011-06-07 2012-12-13 Oborne Timothy W Payment privacy tokenization apparatuses, methods and systems
US20120323786A1 (en) 2011-06-16 2012-12-20 OneID Inc. Method and system for delayed authorization of online transactions
US9195984B1 (en) * 2011-08-16 2015-11-24 Jpmorgan Chase Bank, N.A. Systems and methods for processing transactions using a wallet
US9355393B2 (en) * 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US20130339253A1 (en) * 2011-08-31 2013-12-19 Dan Moshe Sincai Mobile Device Based Financial Transaction System
US20130103574A1 (en) * 2011-10-19 2013-04-25 First Data Corporation Payment Delegation Transaction Processing
US20130151400A1 (en) 2011-12-13 2013-06-13 Oleg Makhotin Integrated mobile trusted service manager
US20130198080A1 (en) * 2012-01-26 2013-08-01 Lisa Anderson System and method of providing tokenization as a service
US20130238492A1 (en) * 2012-03-07 2013-09-12 Clearxchange, Llc System and method for transferring funds
US20130246259A1 (en) * 2012-03-15 2013-09-19 Firethorn Mobile, Inc. System and method for managing payment in transactions with a pcd
US20130256403A1 (en) * 2012-03-23 2013-10-03 Wendy MacKinnon Keith System and Method for Facilitating Secure Self Payment Transactions of Retail Goods
US20130282589A1 (en) 2012-04-20 2013-10-24 Conductiv Software, Inc. Multi-factor mobile transaction authentication
US20130282588A1 (en) * 2012-04-22 2013-10-24 John Hruska Consumer, Merchant and Mobile Device Specific, Real-Time Dynamic Tokenization Activation within a Secure Mobile-Wallet Financial Transaction System
US20140006224A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation System for pre-processing sales returns
US20140032419A1 (en) * 2012-07-26 2014-01-30 Lisa Anderson Configurable payment tokens
US20140040148A1 (en) * 2012-07-31 2014-02-06 Mercury Payment Systems, Llc Systems and methods for arbitraged enhanced payment processing
US20140040131A1 (en) * 2012-07-31 2014-02-06 Mark William Andrews Matching refunds to payment instruments employed in a proxy card transaction
US20140114853A1 (en) * 2012-10-22 2014-04-24 Oonetic Online payment system and method according to the mirror authorization server principle
US20140143146A1 (en) * 2012-11-20 2014-05-22 Prakash George PASSANHA Systems and methods for generating and using a token for use in a transaction
US20140164243A1 (en) * 2012-12-07 2014-06-12 Christian Aabye Dynamic Account Identifier With Return Real Account Identifier
US20140344153A1 (en) * 2013-05-15 2014-11-20 Thanigaivel Ashwin Raj Mobile tokenization hub
US20140351070A1 (en) * 2013-05-22 2014-11-27 Cube, Co. Role-based transaction management system for multi-point merchants
US20140351132A1 (en) * 2013-05-22 2014-11-27 Google Inc. Returns handling in a prepaid architecture
US20150026070A1 (en) 2013-07-16 2015-01-22 Mastercard International Incorporated Systems and methods for correlating cardholder identity attributes on a payment card network to determine payment card fraud
US20150032627A1 (en) * 2013-07-24 2015-01-29 Matthew Dill Systems and methods for communicating token attributes associated with a token vault
US20150032622A1 (en) * 2013-07-29 2015-01-29 Mastercard International Incorporated Online credit returns method and apparatus

Non-Patent Citations (13)

* Cited by examiner, † Cited by third party
Title
Non-Final Office Action for U.S. Appl. No. 13/831,577 dated Dec. 18, 2015, 15 pages.
Office Action on U.S. Appl. No. 13/831,299 Dated May 19, 2014, 41 pages.
Office Action on U.S. Appl. No. 13/831,299, dated Sep. 23, 2015, 54 pages.
Office Action on U.S. Appl. No. 13/831,326, dated Aug. 7, 2014, 30 pages.
Office Action on U.S. Appl. No. 13/831,326, dated Oct. 6, 2015, 49 pages.
Office Action on U.S. Appl. No. 13/831,546, dated Aug. 6, 2014, 34 pages.
Office Action on U.S. Appl. No. 13/831,546, dated Oct. 6, 2015, 63 pages.
Office Action on U.S. Appl. No. 13/831,556 Dated Jun. 18, 2014, 50 pages.
Office Action on U.S. Appl. No. 13/831,556, dated Sep. 25, 2015, 69 pages.
Office Action on U.S. Appl. No. 13/831,577, dated Aug. 19, 2014, 11 pages.
Office Action on U.S. Appl. No. 13/831,602, dated Sep. 28, 2015, 49 pages.
Office Action on U.S. Appl. No. 3/831,577, mail date Jan. 3, 2014, 8 pages.
Office Action U.S. Appl. No. 13/831,602, dated Aug. 11, 2014, 35 pages.

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140351126A1 (en) * 2013-05-22 2014-11-27 Seth Priebatsch Secure synchronization of payment accounts to third-party applications or websites
US20140351132A1 (en) * 2013-05-22 2014-11-27 Google Inc. Returns handling in a prepaid architecture
US10592884B2 (en) 2013-05-22 2020-03-17 Google Llc Split tender in a prepaid architecture
US9870556B2 (en) 2013-05-22 2018-01-16 Google Llc Split tender in a prepaid architecture
US10147112B2 (en) 2013-05-22 2018-12-04 Google Llc Delayed processing window in a prepaid architecture
US11295308B1 (en) * 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US11816666B2 (en) 2014-10-29 2023-11-14 The Clearing House Payments Company L.L.C. Secure payment processing
US10325261B2 (en) * 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
US20210256522A1 (en) * 2014-11-25 2021-08-19 Visa International Service Association System communications with non-sensitive identifiers
US10990977B2 (en) 2014-11-25 2021-04-27 Visa International Service Association System communications with non-sensitive identifiers
US10049352B2 (en) * 2015-02-18 2018-08-14 Apriva, Llc Method and system for processing a mobile payment transaction
US20160239837A1 (en) * 2015-02-18 2016-08-18 Apriva, Llc Method and system for facilitating a payment transaction with a mobile payment server
US11049090B2 (en) * 2015-03-11 2021-06-29 Paypal, Inc. NFC application registry for enhanced mobile transactions and payments
US11803834B2 (en) 2015-03-11 2023-10-31 Paypal, Inc. Providing enhanced merchant experiences in mobile transactions
US11636462B2 (en) 2015-03-20 2023-04-25 Block, Inc. Context-aware peer-to-peer transfers of items
US11734659B2 (en) 2015-05-01 2023-08-22 Pay2Day Solutions, Inc. Message-based bill payment
US11144895B2 (en) * 2015-05-01 2021-10-12 Pay2Day Solutions, Inc. Methods and systems for message-based bill payment
US11915216B2 (en) 2015-08-19 2024-02-27 Block, Inc. Dynamically determining a customized transaction flow
US10410194B1 (en) 2015-08-19 2019-09-10 Square, Inc. Customized tipping flow
US11301825B2 (en) 2015-08-19 2022-04-12 Block, Inc. Customized transaction flow
US20190057383A1 (en) * 2017-08-17 2019-02-21 Mastercard International Incorporated Method and system for chargeback prevention
WO2019074685A1 (en) * 2017-10-09 2019-04-18 Mastercard International Incorporated Systems and methods for refunding qr and other payment system transactions
US20190108582A1 (en) * 2017-10-09 2019-04-11 Mastercard International Incorporated Systems and methods for refunding qr and other payment system transactions
US11232456B2 (en) * 2017-11-30 2022-01-25 Samsung Electronics Co., Ltd. Electronic device for controlling electronic payment and method therefor
WO2019107907A1 (en) * 2017-11-30 2019-06-06 삼성전자 주식회사 Electronic device for controlling electronic payment and method therefor
US20200394323A1 (en) * 2018-03-28 2020-12-17 Visa International Service Association Untethered resource distribution and management
US11853441B2 (en) * 2018-03-28 2023-12-26 Visa International Service Association Untethered resource distribution and management
US10510066B2 (en) * 2018-05-01 2019-12-17 Robert R. Lovett ATM replacement using two mobile devices
US20200234277A1 (en) * 2019-01-22 2020-07-23 Vaughn Dabney Systems and methods for processing encoded symbols to facilitate secured communication between database systems of two entities and to update database tuples associated with the database systems
US11853995B2 (en) * 2019-01-22 2023-12-26 Vaughn Dabney Systems and methods for processing encoded symbols to facilitate secured communication between database systems of two entities and to update database tuples associated with the database systems
US20220351203A1 (en) * 2019-06-21 2022-11-03 Harexinfotech Inc. Payment service system
US20220343380A1 (en) * 2019-11-07 2022-10-27 Visa International Service Association Seamless interaction processing with data security

Also Published As

Publication number Publication date
US10580008B1 (en) 2020-03-03
US11514433B1 (en) 2022-11-29
US9972012B1 (en) 2018-05-15
US11361307B1 (en) 2022-06-14
US10049355B1 (en) 2018-08-14
US20240054480A1 (en) 2024-02-15
US10769621B1 (en) 2020-09-08
US11797969B1 (en) 2023-10-24
US10592888B1 (en) 2020-03-17

Similar Documents

Publication Publication Date Title
US11514433B1 (en) Systems and methods for facilitating transactions using codes
US11868974B2 (en) Systems, methods, and computer program products providing push payments
US11694192B1 (en) System and method for interoperable mobile wallet
CA2896755C (en) Systems and methods for providing secure data transmission between networked computing systems
US10909528B1 (en) Multi channel purchasing for interoperable mobile wallet
US20120267432A1 (en) Secure payments with global mobile virtual wallet
US20140067677A1 (en) Secure payment system
US20130151358A1 (en) Network-accessible Point-of-sale Device Instance
CA2899319A1 (en) Integrated transaction and account system
JP2015516631A (en) Method and system for secure mobile payment
US10713679B1 (en) Offline payment processing
US20220245625A1 (en) Scan to pay payment mode of a digital asset payment network
US20130013502A1 (en) Facilitation of Transactions Using a Transaction Code
AU2017295314A1 (en) Payment system
US10387886B2 (en) Secure transaction processing in a communication system
US20230128929A1 (en) Customizable digital asset-based interaction preferences
EP3818681A1 (en) Real time interaction processing system and method
US20230056521A1 (en) Online systems using currency at access device
WO2018049320A1 (en) Electronic exchange unit management
WO2014063192A1 (en) Mobile payments

Legal Events

Date Code Title Description
AS Assignment

Owner name: WELLS FARGO BANK, N.A., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ELLIS, STEPHEN M;KENNEDY, MICHAEL J;KURANI, ASHISH BHOOPEN;AND OTHERS;SIGNING DATES FROM 20131104 TO 20131211;REEL/FRAME:032239/0588

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4