Method for providing data security using one-way tokens

Abstract

A new processing method is disclosed. The processing method includes receiving, by a server computer from a first authorization computer, an update request message for an interaction between two users. The update can be a transfer of an interaction value from a first user to a second user and can include interaction details such as the interaction value and a one-way token. The server computer can parse the update request message to determine the one-way token and can determine a second account of the second user from the token. The server computer can determine a second authorization computer associated with the second account and can modify the update request message to include a second user account identifier and a value adjustment based on a calculated interaction velocity. The server computer can forward the update request message to the second authorization computer for updating the account accordingly.

Description

[0001] This application is a continuation-in-part of International Application No. PCT / US2018 / 021526, International Filing Date March 8, 2018, entitled "Method for Providing Data Security Using One-Way Token," which entered the National Stage on March 8, 2018, as U.S. Patent Application No. 15 / 921, 89, which claims priority to U.S. Provisional Patent Application No. 62 / 485, 1 1 1, filed April 10, 2017, the contents of which are incorporated herein by reference in their entirety.

[0002] Related Applications

[0003] None. BACKGROUND

[0004] Conventional systems can transfer values from one user to another. For example, in a conventional system for processing payments, a first user such as a cardholder can wish to transfer purchase funds to a second user such as a merchant. However, before this transfer can be made, the second user needs to register with an acquirer. The acquirer can set up an account for the second user and can verify the authenticity of the second user. This process is both cumbersome and complex and can be off-putting to some people from using traditional payment networks for value transfers.

[0005] There is a need for improvements in conventional payment processes such as those described above.

[0006] Embodiments individually and collectively address these and other issues. SUMMARY

[0007] Embodiments can describe a method for updating an account of an interacting user, in which a server computer can receive an update request message from a first authorization computer, the update request message being for an interaction between a first user and a second user. The interaction request can be to transfer an interaction value from the first user to the second user and can include interaction details such as the interaction value and a one-way token. The server computer can parse the update request message to determine the one-way token contained therein and can determine a second account of the second user from the token. The server computer can then determine a second authorization computer associated with the second account and can modify the update request message to include a second user account identifier. The server computer can forward the update request message to the second authorization computer so that the second user account can be updated.

[0008] Another embodiment of the invention can include a server computer comprising: a processor; a network interface; and a computer readable medium comprising instructions executable by the processor. The instructions can be in the form of code, the instructions comprising a method comprising: receiving, from a first authorization computer via the network interface, an update request message, the update request message comprising an interaction request for an interaction between a first user and a second user, the interaction request comprising interaction details, the interaction details comprising a one-way token and an interaction value, the interaction transferring the interaction value from the first user to the second user; parsing the update request message to determine the one-way token; determining, from the one-way token, a second user account identifier of a second account of the second user; replacing the one-way token in the interaction details with the second user account identifier so as to include the second user account identifier in the update request message; determining a second authorization computer associated with the second user account identifier; sending the update request message to the second authorization computer; and receiving an update response message from the second authorization computer, wherein the second authorization computer updates the second account of the second user based on the interaction details.

[0009] Further details regarding embodiments of the invention can be found in the detailed description and figures described herein. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 A system for updating account data of an interacting user according to an embodiment is shown.

[0011] Figure 2 A server computer for facilitating updates between authorization computers in an embodiment is shown.

[0012] Figure 3 A process for registering with a system using a credential device in an embodiment is shown.

[0013] Figure 4 A process for transferring funds to a payment card account using an issuer application according to an embodiment is shown.

[0014] Figure 5 A process for transferring funds to a payment card account using a payment processor according to an embodiment is shown. DETAILED DESCRIPTION

[0015] TERMINOLOGY

[0016] A "user" can refer to an individual. A user of a particular device or system can be an individual that operates the device and / or in accordance with a particular system implementation. For example, a user of a mobile phone can be the owner of the phone. As another example, a user of a payment system can be a consumer that uses the payment system for transactions.

[0017] An “entity” can refer to a distinct participant or a group of participants. For example, an entity can be a business entity, such as a company or a bank, or can be a government entity.

[0018] A “computing device” can refer to a device for performing calculations, i.e., a means for performing tasks according to instructions. In the context of a computer network, a computing device can be any electronic machine capable of receiving and processing instructions. The instructions are typically in the form of a “computer-readable medium,” which can encompass computer code. Computing devices are often “mobile” devices that users can easily carry on their person and perform everyday tasks, such as making a phone call, accessing the Internet, determining their location, and / or recording events through pictures, videos, and / or audio recordings.

[0019] An “application” or “mobile application,” commonly referred to as an “app,” can refer to a computer program for performing a specified task. An application can be pre-installed or downloaded onto a device and stored in memory. When an application is launched on a device, it can provide a user with the option to select a function or “feature,” which can cause the device to perform different commands based on user input. For example, an application can be a camera app that activates the camera function of a mobile phone and takes a picture when instructed by a user. As another example, an application can be a payment app that transfers assets between a user and / or an entity by updating an account ledger.

[0020] A “credential” can refer to an element used to prove identity or ownership. For example, a credential can include a username and / or password. Credentials are often used in computer networks as a means of associating a digital identity with a human identity. In the context of a payment network, a credential can be an account identifier, such as a payment card number, a routing number, a bank account number, etc.

[0021] A “credential device” can refer to an object that conveys one or more credentials. For example, a credential device can be a smaller object that houses a memory storage device with a credential in digital form, such as a credential card that contains a magnetic stripe or a memory chip. In other examples, a credential device can simply be an object that has a credential printed, embossed, or engraved on it, which can be conveyed with the aid of a scanner or other optical device. Credential devices are often portable, so that a user can easily carry a credential in their pocket, wallet, bag, or hand.

[0022] A "token" can refer to an exchangeable element. For example, a token can be a data element that can be exchanged for something of value, such as a coupon code or a single-use access code. In some cases, a token can act as a substitute for a credential when used for a specific purpose. As a simple example, a game token can act as an access credential for starting a game. As a more advanced example, a payment token can act as a value transfer limited to a specific payment context. In this way, a token can be used to authenticate an access proof or an authorization proof without requiring an identity proof or an ownership proof.

[0023] In some embodiments, a token can also include a substitute identifier for some information. For example, a token can include a string of alphanumeric characters that can be used as a substitute for an original account identifier. In some cases, a token can be a payment token that can include an identifier for a payment account that is a substitute for an actual account identifier, such as a primary account number (PAN). For example, a token "4900 00000000 0001" can be used in place of a PAN "4147 0900 0000 1234." In some embodiments, a token can be "reserved format" and can have a numeric format that conforms to an account identifier used in existing processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, a token can be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction. A token can also be used to represent an original credential in other systems that typically provide the original credential. In some embodiments, a token value can be generated such that a recovery of an original PAN or other account identifier cannot be derived from the token value by computation. In some embodiments, a token can be an email ID or mobile phone number, an alias, or an assigned "tag."

[0024] "Account information" can refer to any information associated with a user account. Such information can be directly related to an account or can be derived from information related to an account. Examples of account information can include an account identifier, a user name, a password, user information (e.g., name, age, email address, shipping address, etc.). In some cases, account information can also be referred to as payment account information, card account information, etc., and can be associated with a payment device (e.g., a payment card). For example, account information can include a PAN (primary account number or "account number"), a user name, an expiration date, a CVV (card verification value), a dCVV (dynamic card verification value), a CVV2 (card verification value 2), a CVC3 card verification value, etc. A CVV2 is generally understood to be a static verification value associated with a payment device. A CVV2 value is generally visible to a user (e.g., a user), while a CVV and dCVV value are generally embedded in memory or authorization request messages and are not readily known to a user (but they are known to an issuer and a payment processor).

[0025] A "resource providing entity" can be an entity that can make a resource available to a user. A resource providing entity can also be referred to as a resource provider. Examples of resource providing entities include resource providers, vendors, suppliers, owners, traders, wallet providers, service providers, and the like. In some embodiments, such entities can be a single individual, a small group of individuals, or a larger group of individuals (e.g., a company). A resource providing entity can be associated with one or more physical locations (e.g., a supermarket, a mall, a store, and the like) and online platforms (e.g., an e-commerce website, an online company, and the like). In some embodiments, a resource providing entity can make physical items (e.g., goods, products, and the like) available to a user. In other embodiments, a resource providing entity can make digital resources (e.g., electronic documents, electronic files, and the like) available to a user. In other embodiments, a resource providing entity can manage access to certain resources by a user. In some embodiments, a resource can be a service (e.g., a digital wallet service).

[0026] An "access request" can refer to a request to access a resource. A resource can be a physical resource (e.g., a good), a digital resource (e.g., an electronic document, electronic data, and the like), or a service. In some cases, an access request can be submitted by transmitting an access request message that includes access request data. Typically, a device associated with a requester can transmit an access request message to a device associated with a resource provider.

[0027] "Access request data" can refer to any information about or related to an access request. Access request data can include information that can be used to process and / or validate an access request. For example, access request data can include details associated with an entity involved in processing an access request (e.g., a resource provider computer, a processor server computer, an authorization computer, and the like), such as an entity identifier (e.g., a name, and the like), location information associated with the entity, and information indicating an entity type (e.g., a category code). Exemplary access request data can include information indicating an access request amount, an access request location, a received resource (e.g., a product, a document, and the like), information about a received resource (e.g., a size, an amount, a type, and the like), resource providing entity data (e.g., resource provider data, document owner data, and the like), user data, a date and time of an access request, information for a method used to make an access request (e.g., contactless, non-contact, and the like), and other related information. Access request data can also be referred to as access request information, transaction data, transaction information, and the like.

[0028] A "one-way token" can refer to a token that has been assigned a direction of exchange. For example, a one-way game token can be a token that starts a game for player 2 but not player 1. As another example, in a payment transaction, a one-way token can be a store-only token that can act as a substitute for a payee account credential but not as a substitute for a payer credential.

[0029] An "interaction" can refer to an action between a user and / or an entity. For example, an interaction can be a face-to-face encounter and / or an exchange of information, data, or value.

[0030] An "interaction request" can refer to a request for an interaction, for example, in the context of a controlled task that requires authorization. In some embodiments, an interaction request can be an "access request." In the context of a computer network, an interaction request often relates to authorization to access a database or to process data stored therein. For example, in a social network, an interaction request can be a friend request that, when authorized, grants access to profile data. As another example, in a payment network, an interaction request can be a request to conduct a transaction, and the request, when authorized, can grant an update to an account ledger.

[0031] An "interaction value" can refer to a quantity assigned to an interaction. For example, an interaction within a service application can be assigned a quality rating, for example, "five stars." In another example, an interaction within a social network can be assigned an interaction value of '1' to indicate a "favorable / liked interaction," or an interaction value of '0' to indicate an "unfavorable / disliked interaction." In yet another example, an interaction within a payment network can be assigned a monetary amount that can reflect a transfer amount during the interaction, for example, a transaction amount and / or a fee.

[0032] An "interaction velocity" can refer to a rate of interaction by a user or an entity. For example, an interaction velocity can be an average quantity of interactions per day or a total interaction value received per day.

[0033] An "update request message" can refer to a message that requests an update. In a computer network, the requested update can be an update to data stored in a database. For example, in a payment network, a database of account balances can be requested for update during a payment transaction within the network.

[0034] An "update response message" can refer to a message that responds to an update request. For example, an update response message can convey a confirmation or a denial of the requested update.

[0035] An "authorization computer" can refer to a computer that authorizes a request. For example, an authorization computer can be an access control device or an access control server. In a computer network, an authorization computer is often a server computer that authorizes data access by verifying digital identities and / or permissions. For example, in a payment network, an authorization computer can be a server computer of a bank that authorizes updates to an account ledger based on verification of payment credentials and / or account balances. An authorization computer is often associated with an "issuer" or "issuing entity," which can be a bank that issues payment accounts and their credentials to users as a means of sending funds. For example, an issuing bank can be a bank that issues a debit card to a consumer so that they can transfer funds to a receiving bank in a payment transaction.

[0036] A "server computer" can be a powerful computer or cluster of computers. For example, a server computer can be a large mainframe, a minicomputer cluster, or a cluster of servers working together as a unit. In one example, a server computer can be a database server coupled to a Web server.

[0037] As previously mentioned, due to the nature of payment card networks, accepting card payments as a small merchant (i.e., an individual seller associated with small transactions) is largely viewed as impractical. Embodiments describe a method for enabling small merchant transactions using existing payment card infrastructure and in a manner that is convenient to the consumer. Embodiments allow any cardholder to become a small merchant and accept payments from other cardholders by means of a mere token that can initiate a "push payment" to a payee debit card account, such as a refund or credit push, or other similar fund transfer to a payee's issued financial account.

[0038] In one embodiment, a user can be provided with a mobile device application that can allow the user to register as a small merchant or send payments to a small merchant registered within the system. To register as a merchant (e.g., a second user), the user can use the mobile device application to provide and generate their own merchant data, which can include card information, merchant name, merchant category, and merchant location, as well as set any notification settings in the application. Upon receiving the merchant data, a server computer can generate a mere token (e.g., a unique string) and can associate the mere token with the merchant data provided in the registration record. An acknowledgement can then be sent to the registered user in which the user is provided with a machine-readable code (e.g., a QR code) that conveys the mere token information. The QR code can be displayed from the registered user's mobile device so that a potential customer can use a camera on their smartphone to scan the code and initiate a payment.

[0039] When a registered user now prepared to accept payment from a customer (e.g., a first user) in a transaction for goods or services has been established in the system as a small merchant, the customer can launch a mobile device application on their smartphone and use the provided camera interface to scan the small merchant's QR code. Upon scanning the QR code, the customer's smartphone can communicate the underlying persistent token to the customer's issuing bank along with the customer's payment information and the transaction amount. In one embodiment, the customer's payment information can be retrieved from within their mobile device, such as from a provided device application or other mobile application stored on the customer's device. The customer's issuing bank can receive the transaction information and initiate a funds transfer with the processing server computer of the system. The processing server computer can then receive the persistent token and query the associated merchant data (which can be second user data), including the card information registered by the small merchant. In one embodiment, the server computer can also record each transaction and associated transaction amount, which can then be used to determine speed-based merchant fees (e.g., fees associated with higher transaction volume merchants that place greater stress on the system). The server computer can then replace the persistent token with the small merchant payment card information at the time of the funds transfer and subtract any associated fees from the transfer amount. The funds transfer is then forwarded to the small merchant's issuing bank, such that the issuing bank can update its ledger accordingly.

[0040] Figure 1 A system for updating account data of interacting users according to an embodiment is shown. The system 100 can include a plurality of interacting users, including a first user 101 and a second user 102. The system 100 can further include a first user device 121 of the first user 101 and similarly a second user device 122 of the second user 102. The first user device 121 and the second user device 122 can be any computing device capable of transmitting and receiving data. For example, the user devices can be smartphones, tablets, wearable devices, handheld assistants, portable gaming devices, laptops, computers, etc. The system 100 can additionally include a first authorized computer 131 capable of accessing and updating a first account database 131A, and a second authorized computer 132 capable of accessing and updating a second account database 132A. The system 100 can further include a processing server computer 140 for processing interaction data and capable of accessing and updating a token database 140A. It should be understood that the system 100 can include one or more channels for data transmission between computing devices, such as any number of suitable cellular, internet protocol, and / or ISO 8583 networks. It should further be understood that although the system 100 is shown to include two interacting users, the system 100 can support the processing of multiple interactions at the same time, and the individual computing devices and databases shown can be implemented as multiple computing devices for performing the same functions. Figure 1 The system is shown to include only two interacting users, but the system 100 can support the processing of multiple interactions at the same time, and the individual computing devices and databases shown can be implemented as multiple computing devices for performing the same functions.

[0041] According to embodiments, the second user device 122 can include a one-way token. In one embodiment, as described in further detail below, the one-way token can be provided to the second user 102 during a registration process by the processing server computer 140. The one-way token can be used by the second user 102 to receive an interaction value from the first user 101 and can be used to provide the interaction value to an account associated with the second user's credentials, such as the second user credentials 112. For example, the one-way token can be a passcode associated with a payment card number of the user to which funds can be allocated during a transaction. The second user credentials 112 can include an account identifier, which can be a unique string of characters, such as a debit card number or a primary account number (PAN). The one-way token itself can be a unique string of numbers in the same data format as the second user credentials 112. For example, the one-way token can be a 16-digit number that can be processed by the first authorization computer 131 and the authorization computer 132 as if it were a normal payment card number. In one embodiment, the one-way token information can be communicated via a machine-readable code (e.g., a QR code or other optical label) that can be stored by the second user device 122. The second user device 122 can then send / display the machine-readable code so that another user device can obtain the underlying one-way token during an interaction, for example, by using a camera or other optical scanner.

[0042] In embodiments, the second user 102 can be a user who wishes to receive an interaction value from the first user 101, such as in the context of receiving funds allocated for a payment. For example, the second user 102 can be a seller of goods and the first user 101 can be a potential customer. To transfer the interaction value to the second user 102, the first user 101 can exchange interaction data with the second user device 122 of the second user 102 using the first user device 121. In embodiments, the interaction can be initiated when the first user 101 uses the first user device 121 to obtain the one-way token from the second user device 122. For example, the transaction can be initiated when the first user 101 uses a camera interface of the first user device 121 to scan the passcode information from a QR code on the second user device 122. This can be done from an application on the first user device 121, such as a mobile banking application or a payment application. Within the application, the first user can also input additional interaction details or transaction details, including the interaction value, such as a transaction amount associated with the interaction. In one embodiment, initiating the transaction within the application can also generate a timestamp and / or a transaction identifier (i.e., transaction ID) that can be included in the interaction details.

[0043] The interaction details can further include first user credentials 111 used to determine account data in the first account database 131 A associated with the first user 101. The first user credentials 111 can be manually entered (e.g., typed or scanned payment card information) by the first user 101, or can be retrieved from memory of the first user device 121. In one embodiment, the first user credentials 111 can include an account identifier that can be used by the first authorization computer 131 to query the first account database 131 A to find account data for the first user 101. For example, the account identifier can be a 16-digit primary account number that links to an amount of funds allocated to the first user 101, as well as a transaction history. In embodiments, the first authorization computer 131 can be able to authorize updates to the first account database 131 A requested by the first user 101. For example, the first authorization computer 131 can be a server computer of an issuing bank that can authorize or deny requested changes to a user account balance during a requested transaction and / or funds transfer.

[0044] Upon obtaining the one-way token from the second user device 122, the first user 101 can submit an update request message to the first authorization computer 131 that includes the interaction details of the requested update to the account data of the first user 101. The message can include the interaction value, the first user credentials 111, and the one-way token obtained from the second user device 122. For example, the update request message can include a transaction amount, payment card information of the first user 101, and the only token of the second user 102. Upon receiving the update request message, the first authorization computer 131 can validate the first user credentials 111 by comparing the first user credentials 111 to records stored in the first account database 131 A, and determine whether the account data of the first user credentials 111 exists based on a match. The first authorization computer 131 can further determine whether the requested update can be authorized. This can entail comparing the interaction value to a total allocated value linked to the account of the first user 101 in the first user account database 131 A, and then determining whether the total allocated value exceeds the interaction value to be transferred to the second user 102 during the interaction. In other words, the first authorization computer 131 can determine whether the account of the first user 101 has been allocated sufficient funds to pay for the transaction amount. If the total allocated value of the first user 101 is greater than the interaction value, the authorization computer 131 can determine a positive authorization result (i.e., 'approved'), and can proceed to process the requested update. It should be understood that the first authorization computer 131 can apply any number of additional authentication and / or risk assessment processes in determining the authorization result, and the processing server computer 140 and / or the second authorization computer 132 can further subject the update request message to additional authentication and / or risk assessment processes later in the update process.

[0045] Once the first authorization computer 131 has approved the requested update, the first authorization computer 131 can then submit an update to the first user's 101 account in the first account database 131 A based on the interaction value and forward the update request message to the processing server computer 140. For example, the first authorization computer 131 can submit a portion of the funds equal to the given transaction amount specified in the transaction details. In one embodiment, the first authorization computer 131 can include the authorization result in the update request message prior to forwarding.

[0046] The processing server computer 140 can then receive the update request message and can identify the one-way token contained therein. The processing server computer 140 can then compare the one-way token to the records stored in the token database 140A. In one embodiment, the processing server computer can further update the interaction velocity linked to the one-way token in the token database 140A using the interaction details, for example by evaluating the interaction timestamps, interaction counter, and interaction value linked to the one-way token and calculating the interaction volume or total interaction value over time. For example, the processing server computer 140 can calculate a daily transaction rate based on the previously recorded transactions linked to the only remaining token of the second user 102. In other examples, the average number of transactions per day, the average number of transactions per week, the total transaction amount per day, the total transaction amount per week, per month, etc. can be included.

[0047] In one embodiment, the interaction velocity can be used by the processing server computer 140 to alter the interaction value, for example to reduce the transaction amount contained in the update request message. For example, the processing server computer 140 can identify one or more predetermined interaction velocity limits, which can act as a threshold for deducting one or more transaction fees. The transaction fees can then be allocated between the first authorization computer 131, the processing server computer 140, and / or the second authorization computer 132 as payment for maintaining the network and processing the transaction. As an example, for interaction velocities above $50 per day, the processing server computer 140 can deduct 0.05% of the transaction amount, while for interaction velocities below $50 per day, only 0.01% of the transaction amount is deducted. It should be understood that the system 100 can establish any number of fee structures, which can be based on the availability and / or demand for processing resources required to securely process the interaction data. The interaction velocity can also be used to determine whether to block the completion of the transaction based on the previously set velocity threshold.

[0048] In embodiments, the processing server computer 140 can replace the nonce token in the update request message with an account identifier associated with the second user credential 112 and can submit the update request message to the identified second authorization computer 132. The second authorization computer 132 can receive the update request message and, upon verifying the included account identifier associated with the second user credential 112, can update the second account database 132A based on the interaction details contained in the message. For example, the second authorization computer 132 can query the second account database 132A for the account identified by the primary account number of the second user 102 and can then update its account with the transaction amount (i.e., add the transaction amount to its account balance, less any fees computed by the processing server computer 140).

[0049] Upon determining the account identifier associated with the nonce token, the processing server computer 140 can identify an authorization computer associated with the account identifier, such as the second authorization computer 132. For example, the first four digits of the primary account number can identify a particular authorization entity to which the processing server computer 140 can forward the update request message, such that the second authorization computer 132 can update the account ledger of the second user 102 according to the transaction details.

[0050] In embodiments, the processing server computer 140 can replace the nonce token in the update request message with an account identifier associated with the second user credential 112 and can submit the update request message to the identified second authorization computer 132. The second authorization computer 132 can receive the update request message and, upon verifying the included account identifier associated with the second user credential 112, can update the second account database 132A based on the interaction details contained in the message. For example, the second authorization computer 132 can query the second account database 132A for the account identified by the primary account number of the second user 102 and can then update its account with the transaction amount (i.e., add the transaction amount to its account balance, less any fees computed by the processing server computer 140).

[0051] Upon updating the second account database 132A, the second authorization computer 132 can send an update response message to the processing server computer 140 to confirm that the appropriate changes have been made. The processing server computer 140 can receive the update response message and can forward the update response message with the confirmation to the first authorization computer 131. The processing server computer 140 can further send a confirmation notification to the second user device 122 that the update has been processed according to the received interaction details. In one embodiment, the confirmation notification can be sent directly from the second authorization computer 132 to the second user device 122. In embodiments, the first authorization computer 131 can receive the update response message and the confirmation provided with it from the processing server computer 140 and can then perform the previously submitted update on the first account database 131A. Upon performing the update, the first authorization computer 131 can then send a confirmation notification to the first user device 121 that the requested update has been made and thus the transaction was successfully processed.

[0052] As can be seen from the foregoing Figure 1 description, the system 100 allows for processing interactions between a first user and a second user. This is accomplished by updating a first account database and a second account database by a first authorization computer and a second authorization computer, respectively. The update is initiated by transmitting a one-way token associated with a record in a token database. Further, an interaction value of the interaction can be adjusted between the authorization computers by a processing server computer based on a speed of the interaction associated with the one-way token. When applied to a payment network, this can allow for reduced fees and reduced disincentives for small transactions.

[0053] Figure 2 A server computer for facilitating updates between authorization computers in an embodiment is shown. In embodiments, the server computer 200 can correspond to the processing server computer 140 of Figure 1 The server computer 200 can include a processor 210 for executing instructions. For example, the processor 210 can include any number of CPUs and / or GPUs for executing computer code for performing functions or tasks. The server computer 200 can further include a network interface 220 for receiving and transmitting data messages over a network. For example, the network interface can include any hardware interface or network socket for connecting to a network having a particular communication protocol.

[0054] The server computer 200 can further include a computer-readable medium 230 that stores instructions that can be executed by the processor 210 to perform tasks. For example, the computer-readable medium 230 can include one or more memories that store data, such as random access memory (RAM), dynamic random access memory (DRAM), and / or direct access medium. The instructions of the computer-readable medium 230 can be stored in the form of code modules. The modules can include an update message processing module 230A, an authorized entity determination module 230B, a velocity calculation module 230C, an interaction value adjustment module 230D, a communication module 230E, an authentication module 230F, a token management module 230G, and a registration module 230H. The server computer 200 can further access one or more external data storage devices and / or databases, such as a token database 200A.

[0055] The update message processing module 230A can include code for reading and modifying data in update request messages and update response messages. This can include code for receiving an update request message from an authorization computer and identifying interaction details contained therein. In embodiments, identifying interaction details can include determining a one-way token stored in the interaction details. The code can further include instructions for receiving an update response message from an authorization computer and identifying information stored therein. For example, the code can include receiving a confirmation notification that can be forwarded to a user associated with the authorization computer.

[0056] The authorized entity determination module 230B can include code for determining one or more authorization computers from data in an update message. This can include instructions for identifying an account identifier and determining an authorization computer associated with the account identifier. For example, the account identifier can be an account number associated with a particular account issuer having one or more authorization computers to which the update message can be routed.

[0057] The velocity calculation module 230C can include code for calculating an interaction velocity associated with a one-way token received in an update message. The calculation of the interaction velocity can be based on records stored in the token database 200A. For example, the velocity calculation module 230C can include instructions for determining an amount of interactions performed through a one-way token during a predefined time period (e.g., a day or a week) using a transaction history linked to the one-way token, and / or can determine a total transaction amount received through the one-way token during the time period.

[0058] The interaction value adjustment module 230D can include code for determining and performing interaction value adjustments for received update messages for interaction data. In embodiments, the interaction value adjustment can be determined based on an interaction speed associated with a one-way token in an interaction. In one embodiment, the interaction value adjustment module 230D can include instructions for determining a pre-established speed limit, making a first interaction value adjustment when the interaction speed is below the speed limit, and making a second interaction value adjustment when the interaction speed is above the speed limit.

[0059] The communication module 230E can include code for generating, formatting, and reformatting data messages received through the network interface 220. For example, the communication module 230E can include code for generating and formatting ISO 8583 messages that convey financial transaction information and authorization codes.

[0060] The authentication module 230F can include code for performing one or more authentication processes. For example, the authentication module 230F can include code for performing one or more risk analysis and credential verification processes.

[0061] The token management module 230G can include code for determining and replacing tokens received in data messages. This can include code for identifying a one-way token in a data message, querying a token database for account information linked to the one-way token, and replacing the one-way token in the data message with an account identifier associated with the one-way token based on the queried account information.

[0062] The registration module 230H can include code for performing a user registration process. This can include code for receiving registration data, storing the registration data in a database, generating a one-way token for association with the registration data, storing the one-way token in the database, linking the one-way token to the registration data and / or account data in the database, and sending a confirmation message to a user and / or an authorized entity associated with the account data containing the registration data and the one-way token.

[0063] Figure 3 A process for registering with a system using a credential device in embodiments is shown. The illustrated registration process 300 can be used to register in the system 100 of Figure 1 to accept interaction values. For example, the registration process can be used to register as a small merchant that accepts payment card account payments. In one embodiment, the registration process 300 can be performed by a second user 102 of the system 100 of Figure 1

[0064] ​At step 1, the recipient (payee) can enter their credentials and registration information into their device. In one embodiment, the registration information can include an alias, location, and user type. For example, the recipient can enter a merchant name, merchant location, and merchant category code (MCC) that can identify the user as a small business. In one embodiment, the recipient’s credentials can include an account identifier, such as a primary account number of the recipient’s payment card account. In one embodiment, the registration information and credentials can be entered into the device using a user interface of a mobile application provided by an authorizing entity or payment solution provider. In another embodiment, the credentials can be retrieved by the mobile application from an allocated portion of memory in the device or from another stored application.

[0065] At step 2, the recipient sends the registration information to an authorizing computer associated with the recipient. In one embodiment, the authorizing computer can be identified based on the account identifier entered by the user. For example, the mobile application can route a data message (e.g., a registration request message) to an authorizing computer of an issuing entity associated with the recipient’s payment account number. The authorizing computer can be a server computer that can access recipient account data stored in an account database. For example, the authorizing computer can be one of several computers of an issuer bank system that maintains a user account ledger. In one embodiment, the registration data message can include a tag or other indicator that can be associated with the registration data.

[0066] At step 3, the authorizing computer stores a record of the recipient’s registration information and associates the information with the recipient in the account database. For example, the authorizing computer can link the recipient’s registration tag to their account identifier / payment card account.

[0067] At step 4, the authorizing computer can generate a registration API call containing the recipient’s registration information and account identifier and send it to a processing server computer. For example, the recipient’s issuer can use an API provided by a card payment processor, allowing the issuer to register the recipient into the system.

[0068] At step 5, the processing server computer can receive the API call and generate a one-way token to be associated with the recipient’s registration information and account identifier. For example, the card payment processor can receive the registration API call and then can create a just-in-time token that stores and links to the recipient’s registration tag, payment card number, and merchant information in a token database.

[0069] At step 6, the processing server computer can generate a registration response message including the one-way token and send it to the authorizing computer. For example, the card payment processor can send a response to the recipient’s issuer confirming that the recipient was successfully registered and communicating the just-in-time token for the recipient.

[0070] At step 7, the authorization computer can forward the registration response to the recipient. For example, the recipient’s issuer can transmit the registration response over the communication channel established between the authorization computer and the recipient’s device. The recipient’s device can then process the registration response by means of the stored mobile application. This can include communicating a registration confirmation to the recipient (e.g., displaying a message), storing the one-way token on the device, generating a machine-readable code containing the one-way token information, and displaying the machine-readable code (e.g., a QR code) to the recipient. The recipient can then use the one-way token to receive funds to its payment card account, for example by allowing a sender of the funds to scan the QR code to initiate a transaction process. Examples of embodied transaction processes are described below.

[0071] Figure 4 A process for transferring funds to a payment card account using an issuer application is shown according to an embodiment. In an embodiment, the shown entities can represent the system 100 of Figure 1 , and the devices, computers, and servers / server computers can correspond to the devices, computers, server computers, and databases shown in Figure 1 . The process can include interactions between a first user 101 as a payor / sender and a second user 102 as a payee / recipient. According to the description provided herein, the interactions can be processed as sequences of database updates between the issuing entities for each user.

[0072] Reference is made to Figure 4At step 1, the interaction is initiated by the sender using their device to obtain one-way token information from the receiver's device. For example, a payor can initiate a transaction or funds transfer by scanning a QR code displayed by a payee device. This can be done using a mobile application provided by the payee's issuer. For example, a mobile banking application can be installed on the sender's mobile device and can include an interface for activating the device's camera functionality and processing machine-readable optical labels captured / scanned by the camera when the label is placed in the field of view. The machine-readable optical label can be a QR code containing only the one-way token information. Upon processing the QR code and retrieving the one-way token contained therein, the issuer application can initiate an update request using the sender's credentials and interaction details. For example, the issuer application can generate an update request message containing bits allocated for each data element related to the transaction (e.g., sender information, receiver token, amount, time, etc.). The credentials can be accessed by the issuer application from memory and / or manually entered by the sender. In embodiments, the credentials can include an account identifier for the sender's account from which the interaction value can be deducted. For example, a payment credential can include a primary account number associated with payment card account data maintained by the issuer, such as historical transaction data, etc. The transaction details can include the transaction amount, transaction timestamp, and / or transaction ID / interaction identifier, as well as the one-way token information obtained from the receiver's device. In embodiments, portions of the transaction details can be generated by the issuer application, such as the timestamp and interaction identifier. The update request can then be sent by the issuer application to an authorizing computer capable of updating the sender's account records.

[0073] At step 2, the authorizing computer associated with the sender's account receives the update request and initiates an update process within the system. For example, the authorizing computer can access an account database storing the sender's account data and can submit an update to the database reflecting the received transaction details (e.g., deducting the transaction amount from the user's account and linking the deduction to the timestamp and / or transaction ID). Upon submitting the update entry in the database, the authorizing computer can seek verification / authorization of the update from other relevant parties in the interaction processing system. For example, an OCT push payment or other suitable funds transfer can be initiated through the intermediary payment processing provider / card payment processor and the authorizing computer of the payment recipient's account issuer. In embodiments, this can involve forwarding the update request message and the information contained therein to a processing server computer of the card payment processor.

[0074] An OCT (Original Credit Transaction) is generally a clearing and settlement credit transaction designed for commercial applications, such as commercial transfers or business-to-consumer disbursements. When used in the context of a transfer of the present invention, an OCT is a transaction used to deliver funds to a recipient account.

[0075] The OCT amount is the amount agreed upon by the sender and the service provider in the agreed currency. If the recipient's billing currency is different from the agreed currency at the time of the transaction, a currency conversion can be performed on the OCT and the exact amount to be credited to the recipient's account at the time of the transaction will not be known. In some cases, in order to avoid confusion in determining the exact credit amount in the recipient's account, the currency conversion can be performed by the sending client prior to submitting the transaction to the payment processing computer in cases where a cross currency transaction is being performed. In some embodiments, the OCT carries only the recipient's account number and no information about the sender. A special indicator identifies the OCT as being for the recipient's issuing bank. As in a normal purchase transaction, the conversion can flow from the submitting acquirer to the recipient's issuer. Settlement can be performed within a few days.

[0076] At step 3, the processing server computer receives the update request message and modifies it based on the one-way token record. In embodiments, the modification can include parsing the update request message to determine the one-way token, replacing the one-way token in the interaction details with the second user account identifier, and adjusting the interaction value in the update request message based on the calculated interaction velocity. For example, the processing server computer can query the token database for a record linked to the one-way token, which can include the recipient's merchant data and payment card account number (account identifier). The processing server computer can then use historical records such as the one-way token record to calculate the associated transaction velocity, for example by using the timestamp and transaction amount to calculate the daily transaction amount received per day. The associated transaction velocity can be compared to a threshold value for performing the interaction value adjustment, for example a minimum / maximum value for applying different transaction value reductions and / or reallocations. The processing server computer can then modify the update request message by replacing the one-way token with the recipient's payment card number and adjusting the interaction value accordingly. The processing server computer can further update the one-way token record in the token database to reflect the current transaction.

[0077] At step 4, the processing server computer sends the modified update request message to an authorization computer (second authorization computer) associated with the recipient’s account, as identified by the second user account identifier determined in step 3. For example, the processing server computer can compare the recipient’s transaction details (e.g., account number and location) to a directory of routing addresses associated with authorization computers acting as nodes in the payment system. In embodiments, the second authorization computer can be a server computer of the recipient’s issuing bank, which can have access to the recipient’s payment account records. The second authorization computer can receive the update request message, update the recipient’s account according to the interaction details contained therein, and can generate an update response message. For example, the second authorization computer can update the recipient’s account balance in an account database and add the transaction details to the recipient’s transaction history. In one embodiment, the update response message can include merchant data or label information associated with the one-way token used for the transaction, including the merchant name, merchant location, and / or merchant category code (MCC). The merchant data and / or label information can include registered merchant information associated with the recipient during the registration process, such as the process described in Figure 3 Step 3.

[0078] At step 5, the second authorization computer sends a notification to the recipient that the account update has been made and the interaction has been processed. For example, the second authorization computer can identify a device associated with the second user’s account, such as by querying a device or application identifier linked to the recipient’s merchant label, and can then send a notification with the transaction details and update to the recipient’s device. In one embodiment, the recipient can receive the notification on their device from an issuer application, which can be the same or similar application used by the sender, and also can be the application that enabled the sender to display / send the one-way token at the time of initiating the interaction. In embodiments, the issuer application can be the same application used by the recipient in the registration process 300 described. Figure 3

[0079] At step 6, the second authorization computer can send the update response message generated in step 4 to the processing server computer for forwarding to the sender’s authorization computer (first authorization computer). The first authorization computer can receive the update response message and can perform the committed update. For example, the first authorization computer can reduce the sender’s account balance according to the original pending transaction amount. In one embodiment, the update can include adding the merchant data to the transaction details, so that the sender can view and verify the merchant information in their transaction history at a later point in time.

[0080] ​At step 7, the first authorization computer sends a notification to the sender that the update has been made and the interaction has been processed. For example, the first authorization computer can send a confirmation notification with the transaction details to the issuer application on the sender device. In other embodiments, similar interaction processes can occur on a third-party application, such as a card payment provider or digital wallet provider, as described below.

[0081] Figure 5 A process for transferring funds to a payment card account using a payment processor application is shown, according to an embodiment. In embodiments, the process shown can correspond to the process involving the same parties as Figure 4 The process in Figure 5 In the process in Figure 4 In the embodiment in

[0082] At step 1, the payor / sender initiates a transaction after scanning the merchant information of the recipient. For example, the payor can scan a QR code displayed on the recipient’s mobile device, which can send a signal to the payor’s device to request a transfer of funds according to an agreed-upon transaction amount.

[0083] At step 2, the sender’s issuer receives the transaction information and sends a funds transfer to a processing server computer. For example, the sender’s issuer can commit or allocate a portion of funds to pay for the transaction amount and can notify an intermediary payment processor to push the allocated funds to another issuer bank’s ledger.

[0084] At step 3, the processing server computer retrieves an account identifier linked to a one-way token included in the transaction information. For example, the merchant tag information can be queried using the only token transferred via the recipient’s merchant QR code. The merchant tag information can be associated with the recipient’s registered information in a token database, such as the recipient’s payment card number (PAN), registered merchant name, merchant location, and merchant category code, and transaction history. The processing server computer can then modify the funds transfer according to a predetermined fee calculation that corresponds to a set transaction velocity limit associated with the recipient’s varying daily transaction volume, daily value transfer, or other interaction frequency-based metric.

[0085] At step 4, the processing server computer can then forward the funds transfer with the updated transaction information to the recipient’s issuer. The funds transfer can include the recipient’s merchant information (i.e., payment card number, merchant name, location, MCC, etc.) and the transaction amount with the fee calculation.

[0086] At step 5, the recipient's issuer updates the account database, including updating the recipient's account data. For example, the recipient's bank can add the reduced transaction amount to its account balance, and can update its own allocated deposit account for collection of its apportioned computing fee.

[0087] At step 6, the recipient's issuer sends a response message to the processing server computer, which can also initiate a notification to the recipient that the transaction has been successfully processed. For example, the recipient's issuer can initiate an API call to the processing server computer, which can forward a confirmation of the processed payment to the recipient using the provided digital wallet or other third-party payment application.

[0088] At step 7, the processing server computer forwards the response message to the sender's issuer. For example, the processing server computer can confirm with the sender's issuer that the funds have been successfully transferred, and the sender's issuer can update its ledger accordingly.

[0089] At step 8, the sender's issuer sends a notification to the sender that the transaction has been successfully processed. For example, the sender can send a confirmation notification to the sender's device via the payment application used to initiate the transaction.

[0090] Embodiments provide several technical advantages. Embodiments allow computers in a payment processing network to assess the impact of a particular recipient node on network traffic, and can charge variable network fees accordingly, thus enabling small businesses and small transactions to be accepted within the network. Furthermore, embodiments provide a unidirectional (e.g., only store) token that is only valid for a value transfer in a single direction, thus allowing a user to receive digital funds to their payment card account without exposing their payment card number or the opportunity for others (e.g., hackers or criminals) to take out funds using the token. Thus, a user can easily receive payments to their existing payment card account in a secure and efficient manner.

[0091] Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer readable medium such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium can reside on or within a single computational device, and can be present on or within different computational devices in a system or network.

[0092] While certain exemplary embodiments have been described and shown in detail, it is understood that the application is not limited in scope by the embodiments described and shown, and that the application is not limited in scope by any of the specific arrangements described and shown, but rather, the application is limited in scope only by the claims, and that changes can be made in the embodiments described and shown without departing from the scope of the application.

[0093] As used herein, unless expressly stated to the contrary, use of "a" or "an" or "the" is intended to mean "one or more."

Claims

1. A method comprising: receiving, by a second authorization computer from a processing server computer, a modified update request message comprising an adjusted interaction value and interaction details for a transaction, wherein the processing server computer is programmed to: receive, from a first authorization computer, an initial update request message comprising an interaction request for an interaction between a first user and a second user, the interaction request comprising a one-way token and an interaction value, the interaction transferring value from the first user to the second user, parsing the initial update request message to determine the one-way token, determining an interaction velocity of the one-way token using a history associated with the one-way token in a token database to calculate a total interaction value over a period of time, adjusting the interaction value based on the interaction velocity, determining a second user account identifier for a second account of the second user from the one-way token, replacing the one-way token with the second user account identifier so as to include the second user account identifier and the adjusted interaction value in the modified update request message, determining a routing address associated with the second authorization computer in a directory of routing addresses, the second authorization computer being associated with the second user account identifier, and sending the modified update request message to the routing address associated with the second authorization computer; updating, by the second authorization computer, an account balance of the second user in an account database using the adjusted interaction value; sending, by the second authorization computer, a notification to a second user device that the update to the account balance of the second user has been made and that the transaction has been made; and sending, by the second authorization computer, an update response message to the processing server computer.

2. The method of claim 1, wherein the one-way token has a same data format as the second user account identifier.

3. The method of claim 1, wherein the interaction details comprise a timestamp and a transaction identifier.

4. The method of claim 1, wherein the processing server computer is further programmed to transmit the update response message to the first authorization computer.

5. The method of claim 1, wherein the first authorization computer submits an update to a first account of the first user based on the interaction value and the one-way token prior to the processing server computer receiving the initial update request message, and wherein the first authorization computer performs the submitted update after the processing server computer receives the update response message.

6. The method of claim 1, wherein the processing server computer is further programmed to: receive a registration request message comprising the second user account identifier and second user data; generate the one-way token; associate the one-way token with the second user account identifier; and send a registration response message comprising the one-way token to the second user device of the second user. ​ ​ 7. The method of claim 1, wherein the update response message includes second user data associated with the second user.

8. A system comprising: one or more processors; and one or more computer-readable media comprising instructions executable by the processors to implement a method comprising: receiving, from a processing server computer, a modified update request message comprising an adjusted interaction value and interaction details for a transaction, wherein the processing server computer is programmed to: receive, from a first authorization computer, an initial update request message comprising an interaction request for an interaction between a first user and a second user, the interaction request comprising a one-way token and an interaction value, the interaction transferring value from the first user to the second user, parsing the initial update request message to determine the one-way token, determining an interaction velocity of the one-way token using a history associated with the one-way token in a token database to calculate a total interaction value over a period of time, adjusting the interaction value based on the interaction velocity, determining a second user account identifier for a second account of the second user from the one-way token, replacing the one-way token with the second user account identifier so as to include the second user account identifier and the adjusted interaction value in the modified update request message, determining a routing address associated with a second authorization computer in a routing address directory, the second authorization computer associated with the second user account identifier, and sending the modified update request message to the routing address associated with the second authorization computer; updating an account balance of the second user in an account database using the adjusted interaction value; sending a notification to a second user device that the update to the account balance of the second user has been made and that the transaction has been made; and sending an update response message to the processing server computer.

9. The system of claim 8, wherein the one-way token has a same data format as the second user account identifier.

10. The system of claim 8, wherein the interaction details comprise a timestamp and a transaction identifier.

11. The system of claim 8, wherein the processing server computer further communicates the update response message to the first authorization computer.

12. The system of claim 8, wherein the first authorization computer submits an update to a first account of the first user based on the one-way token and the interaction value prior to the processing server computer receiving the initial update request message, and wherein the first authorization computer performs the submitted update after the processing server computer receives the update response message.

13. The system of claim 8, wherein the processing server computer further receives a registration request message comprising the second user account identifier and second user data; generates the one-way token; ​ associating the one-way token with the second user account identifier; and sending a registration response message including the one-way token to the second user device of the second user.

14. The system of claim 8, wherein the update response message includes second user data associated with the second user.

15. A first authorizing entity computer, the first authorizing entity computer comprising: a processor; and a computer readable medium comprising code, executable by the processor, to implement a method comprising: receiving, from a first user device, an update request message including interaction details, the interaction details including a first user account identifier, an interaction value, and a one-way token received from a second user device, submitting a database entry of a first account database to an update of a first account identified by the first user account identifier; communicating the update request message to a server computer, wherein the server computer adjusts the interaction value in the update request message based on an interaction velocity determined for the one-way token, and wherein an authorizing computer updates a second account database based on the adjusted interaction value, the interaction velocity determined using a history associated with the one-way token from a token database to calculate a total interaction value over a period of time; receiving an update response message from the server computer; performing the update to the first account; and sending a confirmation message to the first user device.

16. The first authorizing entity computer of claim 15, wherein the update request message is generated by a first mobile application stored on the first user device, and wherein the update response message is forwarded to a second mobile application stored on the second user device.

17. The first authorizing entity computer of claim 15, wherein the first authorizing entity computer is an issuer computer.

18. The first authorizing entity computer of claim 15, wherein the first user device and the second user device are mobile phones.

19. The first authorizing entity computer of claim 15, wherein the first user account identifier and second user account identifier are payment account identifiers.

20. The first authorizing entity computer of claim 15, wherein the interaction value is a transaction amount.

Images