Automated transaction processing type determination

Abstract

A method is disclosed. The method includes receiving from a user device of a user, a first plurality of transaction requests and correspondingly processing a first plurality of transactions of a first transaction type using a receiver credential. The method further includes analyzing data associated with the first plurality of transactions of the first transaction type, and automatically determining that the receiver credential is capable of being used to conduct transactions of a second type. The method includes receiving, from the user device of the user, a second plurality of transaction requests and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential.

Description

AUTOMATED TRANSACTION PROCESSING TYPE DETERMINATIONCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This is a PCT application, which claims priority to U.S. Provisional Application No. 63 / 604,735 filed on November 30, 2023, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] User computing devices such as PCs, tablets, and smartphones have NFC communication hardware, which can be used to communicate with contactless devices such as contactless phones and cards. As a result, the use of NFC-enabled devices to send and receive values such as transaction values in real time has become increasingly common among casual and established receivers. An established receiver (e.g., an established resource provider) may be one that has been vetted by an entity (e.g., an acquirer) to ensure that the receiver is authentic and legitimate. The vetting process can be extensive. After vetting, the entity can hold a record such as an account for the established receiver. A casual receiver (e.g., a casual receiver such as a casual merchant), on the other hand, has not been vetted by an entity in the same manner as an established receiver.

[0003] Because casual receivers have not been vetted in the manner that established receivers have been vetted, their transactions do not have the same types of protections and advantages that are provided to established receivers. It would be desirable to provide such protections and advantages to such casual receivers.

[0004] Embodiments of the invention address these and other problems individually and collectively.SUMMARY

[0005] One embodiment includes a method comprising: receiving, by a server computer from a user device of a user, a first plurality of transaction requests and correspondingly processing a first plurality of transactions of a first transaction type using a receiver credential; analyzing, by the server computer, data associated with the first plurality of transactions of the first transaction type; responsive to analyzing the first plurality of transactions of the first transaction type, automatically determining, by the server computer, that the receiver credential is capable of being used to conduct transactions of a second type; and receiving, by the server computer from the user device of the user, a second plurality of transaction requests and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential.

[0006] Another embodiment of the invention includes a server computer comprising: a processor; and a computer readable medium comprising code, executable by the processor for implementing a method comprising: receiving a first plurality of transaction requests comprising a receiver credential and correspondingly processing a first plurality of transactions of a first transaction type using the receiver credential; analyzing data associated with the first plurality of transactions of the first transaction type; responsive to analyzing the first plurality of transactions of the first transaction type, automatically determining that the receiver credential is capable of being used to conduct transactions of a second transaction type; and receiving a second plurality of transaction requests comprising the receiver credential and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential.

[0007] These and other embodiments are described in further detail below.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 shows a block diagram of a system and an overlaid method for processing a first transaction type initiated by a receiver.

[0009] FIG. 2 shows a block diagram of a system and an overlaid method for changing processing associated with a first transaction type to a second transaction type.

[0010] FIG. 3 shows a block diagram of a system and an overlaid method for processing a second transaction type initiated by a receiver

[0011] FIG. 4A shows a block diagram of a system and an overlaid method for processing a first transaction type initiated by a sender.

[0012] FIG. 4B shows a block diagram of a system and an overlaid method for processing a second transaction type initiated by a sender.

[0013] FIG. 5 shows a block diagram of an exemplary acceptance server.

[0014] FIG. 6 shows a block diagram of an exemplary receiver user device.

[0015] FIG. 7 shows a block diagram of an exemplary sender portable device.DETAILED DESCRIPTION

[0016] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0017] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc. A “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.

[0018] An "acquirer" may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer.”

[0019] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.

[0020] An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentialsstored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0021] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0022] A “user device” may be any suitable device that a user can interact with (e.g., a payment card or mobile phone). User devices may be in any suitable form. Some examples of user devices include cards (e.g., payment cards such as credit, debit, or prepaid cards) with magnetic stripes or contactless elements (e.g., including contactless chips and antennas), cellular phones, PDAs, personal computers (PCs), tablet computers, and the like. In some embodiments, where a user device is a mobile device, the mobile device may include a display, a memory, a processor, a computer-readable medium, and any other suitable component.

[0023] A “processing network” may include data processing subsystems, networks, and operations. In embodiments of the invention, a processing network may be used to support and deliver authorization services, exception file services, and clearing and settlement services. A processing network may be a payment processing network able to transmit and receive financial system transaction messages (e.g., ISO 8583 messages), and process original credit and debit card transactions. An exemplary payment processing system may include VisaNet™. Payment processing systems such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions.

[0024] A “portable device” may be a device that can be easily carried. A portable device may be a payment device which comprises a substrate such as a paper or plastic card, and information that is printed, embossed, encoded, or otherwise included at or near a surface of an object. A payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or a person. Suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and / or pocket (e.g., pocket- sized). Example payment devices may include smart cards, magnetic stripe cards, keychain devices (such as the Speedpass™ commercially available from ExxonMobil Corp.), etc. Other examples of payment devices include payment cards, smart media, transponders, and the like. If the payment device is in the form of a debit, credit, or smartcard, the payment device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.

[0025] An “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a transaction processing computer and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CW (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0026] An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval -- transaction was approved; Decline -- transaction was not approved; or Call Center -- response pending more information, merchant must callthe toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.

[0027] A “clearing and settlement process” may include a process of reconciling a transaction. A clearing process is a process of exchanging financial details between an acquirer and an issuer to facilitate posting to a party's account and reconciliation of the party's settlement position. Settlement involves the delivery of funds from one party to another.

[0028] A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0029] A “processor” may include a device that processes something. In some embodiments, a processor can include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, AMD Ryzen, AMD Threadripper, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).

[0030] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computerreadable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0031] One embodiment includes a method. The method includes receiving, by a server computer such an acceptance server computer from a user device of a user, a first plurality of transaction requests and correspondingly processing a first plurality of transactions of a first transaction type using a receiver credential. The method also includes analyzing data associated with the first plurality of transactions of the first transaction type, and responsive to analyzing the first plurality of transactions of the first transaction type, automatically determining that the receiver credential is capable of being used to conduct transactions of a second type. The method also includes receiving, by the server computer from the user device of the user, a second plurality of transaction requests and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential.

[0032] A first transaction type can be a type of transaction that provides fewer protections and advantages to a receiver, while a second transaction type can be a type of transaction that provides more protections and advantages. For example, a server computer that processes a transaction of the second transaction type may perform extensive data security analyses (e.g., fraud or data compromise analyses) on the transaction. The server computer may process a transaction of the first type without such extensive data security analyses that would be provided to transactions of the second type.

[0033] In an example, a first transaction type may enable delivery of funds from a sender to a receiver using a pull transfer message (e.g., an account funding transaction (AFT) message) and a push transfer message (e.g., an original credit transaction (OCT) message. The receiver can accept funds to a receiver account by linking a receiver credential to an acceptance application on their user device (e.g., a mobile phone). The receiver does not need to go through an extensive onboarding process (e.g., merchant underwriting) to begin conducting transactions, which makes the first transaction type initially convenient.

[0034] However, the first transaction type may not be suitable for receivers who frequently conduct many transactions. There may not be support for chargeback or disputes, and it may be limited to domestic transactions with certain processing networks. Moreover, there may be transaction limits such as a maximum total transaction amount per month or a maximum number of transactions per day that restrict the ability for the receivers to conduct transactions. In additional, certain technological tools that would be available to transactions of the second type may not be available for transactions of the first type.

[0035] A second transaction type may use existing transmission protocols associated with transaction messages such as ISO 8583 transaction messages. The second transaction processing method may remove transaction limitations and expand acceptance to all account types, supporting all major networks and cross- border transactions. It may use card present rails and support chargebacks and disputes to accommodate increased risks that come with high transaction volumes and acceptance to all account types. Certain technological tools can be available for transactions of the second type, but may not be available for transactions of the first type.

[0036] In existing methods, the second transaction type requires receivers to participate in a thorough onboarding process to open a record (e.g., account) with an entity (e.g., an acquirer) that operates a transport computer. The onboarding process can be difficult and cumbersome, and can deter some receivers from participating in it. As a result, such receivers may only be able to conduct transactions of the first transaction type. However, with embodiments, a receiver can eliminate the need for a traditional onboarding process if the receiver’s transaction activity becomes sufficiently high over a predetermined period of time. Embodiments of the disclosure can monitor a receiver’s transactions and, when necessary, automatically invite the receiver to change their ability to conduct their transactions from the first type to the second type.

[0037] FIG. 1 shows a block diagram of a system and an overlaid method for processing a first transaction type. A transaction between a sender 103 and a receiver 101 can be conducted using a sender portable device 105 and a receiver user device 102. The receiver user device 102 can communicate with the senderportable device 105 via NFC or other short range communication protocol. The transaction may involve transferring funds from a sender account managed by a first authorizing entity computer 110 to a receiver account managed by a second authorizing entity computer 112. An acceptance application 102A enables the receiver user device 102 to communicate with an acceptance server 104. The acceptance server 104 may additionally be in operable communication with a processing network computer 106 and a gateway 109. The processing network computer 106 can be in communication with the acceptance server 104, the gateway 109, the first authorizing entity computer 10, and the second authorizing entity computer 112.

[0038] Prior to conducting the first type of transaction, the receiver 101 can enroll with the acceptance server 104 via an acceptance application 102A on the receiver user device 102. The receiver 101 can download the acceptance application 102A from the acceptance server 104 onto the receiver user device 102. The receiver 101 can then enter a receiver credential (e.g., a primary account number of PAN) into the acceptance application 102A and it can be stored in the acceptance application 102A or on the acceptance server 104. During enrollment, the receiver credential may be used to link a receiver account issued and / or managed by the second authorizing entity computer 112 to the acceptance application 102A. In some embodiments, the acceptance application 102A may tokenize the receiver credential to form a token such as a payment token. During enrollment, the receiver 101 may choose to conduct a transaction of the first transaction type because the receiver does not want to participate in an extensive onboarding process.

[0039] During the transaction, the receiver user device 102 obtains a sender credential from the sender 103. For example, the sender 103 may wish to transfer one hundred dollars to the receiver 101. The sender 103, after reviewing the amount to transfer on the acceptance application 102A, can interact (e.g., tap) the sender portable device 105 with the receiver user device 102. The sender credential is then passed from the sender portable device 105 to the receiver user device 102. The acceptance application 102A, in communication with the acceptance server 104, reviews the sender and receiver activity, and determines if the transaction is within limits of the first transaction type. For example, the acceptance application 102A mayonly allow for the processing of transactions under a certain limit such as under one thousand dollars.

[0040] More specifically, at step S102, the receiver 101 may request funds of a transaction amount from the sender 103 in a transaction. The receiver 101 may use the acceptance application 102A on the receiver user device 102 (e.g., a mobile phone) to conduct the transaction. The receiver 101 can input the transaction amount into the acceptance application 102A, which can then prompt the sender 103 to provide a sender credential to fund the transaction amount.

[0041] At step S104, a sender credential, which identifies the sender account, is transmitted to the receiver user device 102. For example, the sender 103 may tap the sender portable device 105 on the receiver user device 102, and the receiver user device 102 may obtain a sender credential from the sender portable device 105 through contactless interaction (e.g., NFC, Bluetooth™, RFID) or a contact interaction. In some embodiments, the acceptance application 102A may also obtain other data including a cryptogram such as a CW, CVV2, dCVV or dCW2 value, an expiration date, etc.

[0042] At step S106, the acceptance application 102A submits a transaction request message with transaction information to the acceptance server 104. The transaction information may include at least the sender credential, receiver credential, the amount for the transaction, and optionally the cryptogram. In some embodiments, the transaction request message may include an identifier for the receiver user device 102 and / or the instance of the acceptance application 102A on the receiver user device 102. The transaction request message may indicate that the transaction is a first transaction type. For example, the transaction request message can indicate that the transaction type is an AFT / OCT (original credit transaction) transaction type.

[0043] At step S108, the acceptance server 104 may optionally forward transaction information to the processing network computer 106 for verification. The processing network computer 118 can verify the transaction request message by validating credentials and also the cryptogram (if it was included).

[0044] At step S110, the acceptance server 104 may check information associated with the receiver 101 to confirm that the transaction should be processedaccording to the first transaction type. Transactions processed as the first transaction type may not include support chargebacks or disputes, so the acceptance server 104 may consider a number of risk factors and specifications prior to processing the transaction according to the first transaction type. The acceptance server 104 can check account data and historical data associated with the receiver credential, and compare it to one or more thresholds to confirm that the present transaction is within limits of the first transaction type. For example, if the transaction frequency of transactions conducted using the receiver credential over a recent predetermined period of time is below a transaction frequency threshold and the amount of the transaction is below a transaction amount threshold, the acceptance server 104 may continue to process the transaction as the first transaction type. If the account data and historical data associated with the receiver credential is approaching or exceeds the one or more thresholds, the acceptance server 104 may invite the receiver 101 to onboard with an entity (e.g., an acquirer) that operates a transport computer at a later time (see method described with respect to FIG. 2)

[0045] In some embodiments, the acceptance server 104 may additionally check information associated with the sender prior to processing the transaction. Because transactions of the first type may not support chargeback or disputes, and the receiver 101 has not completed a thorough onboarding to ensure they are legitimate, transactions of the first type may expose the sender 103 to some degree of risk. With this in mind, the sender 103 and / or the first authorizing entity computer 110 can set a maximum value for transactions of the first type to limit exposure to risk. For example, the sender 103 may limit the number of transactions of the first type that can be conducted with the sender credential to ten transactions a week. In another example, the sender 103 can limit the monthly amount for transactions of the first type to be $500. The acceptance server 104 can check the transaction activity of the sender credential against the limits set by the sender 103 and / or the first authorizing entity computer 110.

[0046] If the acceptance server 104 determines that the transaction will exceed the limits set by the sender 103, the acceptance server 104 may notify both the receiver 101 and the sender 103 that the transaction cannot be processed. The acceptance server 104 may notify the sender 103 and the receiver 101 that the transaction exceeds the sender’s limits. In some embodiments, the acceptanceserver 104 can request that the receiver 101 change the processing of its transactions to a second transaction type, which is more secure in order to proceed with the transaction. In some embodiments, the sender 103 may communicate with the first authorizing entity computer 110 to update their limits for transactions of the first type (e.g., via a first authorizing entity application), and the first authorizing entity computer 110 can contact the acceptance server 104 (e.g., via an API) to update the limits. If the transaction does not exceed the limits set on the sender credential, the acceptance server 104 may continue to process the transaction.

[0047] At step S112, the acceptance server 104 submits a pull transfer message to the gateway 109 comprising the sender credential. In some embodiments, the acceptance server 104 can use API messaging (e.g., Funds Transfer API) to submit a pull transfer message comprising the sender credential and the amount for the transaction, as well as a pull transfer indicator. One example of a pull transfer message may be an AFT message. An AFT (Account Funding Transaction) can be a transaction designed to supply funds to another account such as a credit, prepaid, debit, ATM card or on-line account. The AFT eventually can result in a debit to the sender's account. For example, the acceptance server 104 can call an AFT API associated with the gateway 109 to request funds from the first authorizing entity computer 110 account of the sender 103. The gateway 109 may reply to confirm receipt of the pull transfer message.

[0048] In steps S114 and S116, after receiving the pull transfer message from the acceptance server 104, the gateway 109 can call the processing network computer 106 to route the transaction to the first authorizing entity computer 110. The gateway 109 can forward the transaction information to the processing network computer 106 and the processing network computer 106 can send the amount for the transaction and the sender credential to the first authorizing entity computer 110. The first authorizing entity computer 110 can deduct the amount for the transaction from the sender’s account, and then confirm receipt with the processing network computer 106 by transmitting a pull transfer response message.

[0049] In step S118, the acceptance server 104 transmits a push transfer message comprising the receiver credential and the amount for the transaction to thegateway 109. The push transfer message may request that the amount for the transaction be posted to the account of the receiver 101 .

[0050] An example of a push transfer message may be an OCT (Original Credit Transaction) message. When used in the context of money transfer from a sender user to a receiver user, the OCT is the transaction used to deliver funds to the receiver account. A special indicator identifies an OCT to the second authorizing entity computer 112 associated with the receiver user. It is separate from, and takes place after, the AFT. This timing is to ensure that the value for the interaction is secured before value is sent to the recipient.

[0051] In steps S120 and S122, the gateway 109 can call the processing network computer 106 to route the transaction to the second authorizing entity computer 112. The second authorizing entity computer 112 can credit the amount for the transaction to the account of the receiver 101 .

[0052] At a later time (e.g., at the end of the day), the actual movement of funds can occur. Pursuant to the AFT message, funds in the transaction amount can be pulled from an account of the sender 103 managed by the first authorizing entity computer 110 to an intermediate account at an intermediate service provider (e.g., an intermediate bank). Pursuant to the OCT message, funds in the transaction amount can be pushed from the intermediate account to the account of the receiver at the second authorizing entity computer 112.

[0053] As shown above, the first transaction type does not require that the receiver 101 onboard with a transport computer. Thus, the above process may be initially suitable for a receiver such as a new resource provider or a casual seller because they can begin conducting transactions while bypassing thorough onboarding. However, there may be a number of drawbacks to the first transaction type which may compound risk over time if there is a high transaction frequency. For example, transactions of a first transaction type may not support chargebacks or disputes, so it may not be possible to reconcile fraudulent transactions. If the receiver 101 continues to use transactions of the first transaction type they may continue to expose themselves to increased risk. Another disadvantage is that the first transaction type may use AFT messaging, which relies on specialized programming. Consequently, transactions of the first transaction type may berestricted to a specific set of domestic authorizing entities which have integrated with the AFT messaging protocol. This limits opportunities for the receiver 101 to conduct transactions with senders that have international authorizing entities.

[0054] If the receiver 101 routinely conducts transactions of the first transaction type, the acceptance server 104 may suggest the receiver 101 onboard with an entity so that transactions of the second transaction type (e.g., at the end of the day) can be conducted. For example, at step S110, the acceptance server 104 may determine that the receiver 101 is approaching one or more thresholds for conducting transactions of the first transaction type. Then, the acceptance server 104 can initiate a rapid onboarding process for the receiver 101 to change transaction processing of transactions conducted by the receiver 101 from the first transaction type to the second transaction type.

[0055] FIG. 2 shows a block diagram and an overlaid a method to change the processing of transactions conducted by a receiver from a first transaction type to a second transaction type. FIG. 2 shows a receiver 101 , a receiver user device 102 comprising an acceptance application 102A, an acceptance server 104, and a transport computer 111. The receiver user device 102 can be in communication with the acceptance server 104, and the acceptance server 104 can be on communication with the transport computer 111.

[0056] The second transaction type can involve routing messages via the transport computer 111 , and does not require a specialized messaging protocol such as the AFT I OCT messaging protocol noted above. Other advantages of the second transaction type relative to the first transaction type are described above.

[0057] The acceptance server 104 may invite the receiver 101 to change the processing of its transactions to a second transaction type after the receiver 101 conducts a plurality of transactions of the first transaction type (e.g., the method shown in FIG. 1). Traditionally, the second transaction type requires a thorough onboarding process with an entity, which can deter the receiver from onboarding. However, with embodiments of the invention, when the receiver conducts the plurality of transactions of the first transaction type and no fraudulent or problematic transactions are present, the conventional onboarding process with an entity such an acquirer can be eliminated or reduced in scope. For example, if all of thetransactions involving the receiver 101 conducted within a pre-determined period of time were not fraudulent and not problematic, this transaction history can serve as evidence that the receiver 101 is an authentic and legitimate receiver, and is not a fraudulent or problematic entity.

[0058] Prior to step S201 , the acceptance server 104 may receive a first plurality of transaction requests comprising the receiver credential of the receiver 101. The first plurality of transaction requests may be for transactions that the receiver 101 conducted over a period of time for various amounts with various senders, and can additionally comprise one or more sender credentials and a plurality of transaction amounts. The acceptance server 104 may correspondingly process a first plurality of transactions of the first type as described above with reference to FIG. 1. The acceptance server 104 may analyze data associated with the first plurality of transactions of the first transaction type and determine that the receiver credential is capable of being used to conduct transactions of the second transaction type. For example, as described in step S110 of FIG. 1 , the acceptance server 104 may determine that transactions involving the receiver credential are approaching a transaction frequency limit associated with the first type of transaction.

[0059] In step S201 , if the acceptance server 104 determines that the receiver 101 is approaching the transaction limits for the first transaction type (e.g., at step S110 in FIG. 1 ), the acceptance server 104 may invite the receiver 101 to complete a rapid onboarding with the transport computer 111. For example, the acceptance server 104 may launch a notification on the acceptance application 102A which presents the receiver 101 with a rapid onboarding process with the transport computer 111.

[0060] In step S202, the receiver 101 can accept the request for rapid onboarding via the acceptance application 102A, and provide onboarding information (e.g., resource provider registration information, photo identification). The onboarding information may be minimal since the acceptance server 104 already has transaction history of the receiver 101. For example, in a conventional onboarding process, a credit or transaction history of the receiver 101 may be requested by the entity performing the onboarding. However, such information would not be needed in therapid onboarding according to embodiments of the invention. In step S203, the acceptance application 102A can transmit the onboarding information input by the receiver 101 to the acceptance server 104.

[0061] At step S204, the acceptance server 104 transmits to the transport computer 111 a request with sufficient information to onboard the receiver 101. The transport computer 111 can register the receiver 101 immediately such that the next transactions the receiver 101 conducts are processed as transactions of the second transaction type. For example, the acceptance server 104 may later receive a second plurality of transaction requests comprising the receiver credential, and corresponding process a second plurality of transactions of the second transaction type.

[0062] FIG. 3 shows a block diagram of a system and a method for processing a transaction of a second transaction type. FIG. 3 shows a receiver user device 102 accepting a credential from a sender portable device 105. FIG. 3 illustrates a receiver user device 102 of a receiver 101 , an acceptance application 102A installed on the receiver user device 102 and managed by an acceptance server 104, a sender portable device 105 of a sender 103, a first authorizing entity computer 110 associated with a first authorizing entity (e.g., a first issuer) that issued and / or manages a first user account of the sender 103, a transport computer 111 (operated, for example, by an acquirer), a processing network computer 106 (operated, for example, by a payment processor), and a second authorizing entity computer 112 associated with a second authorizing entity that issued and / or manages a receiver account of the receiver 101 .

[0063] Similar to FIG. 1 , the transaction may involve transferring funds from the sender account managed by the first authorizing entity computer 110 to the receiver account managed by the second authorizing entity computer (not shown). The acceptance server 104, the acceptance application 102A, and the processing network computer 106 may be similar to FIG. 1. However, unlike the first transaction type described in FIG. 1 , the second transaction type in FIG. 3 may involve a transport computer 111. The acceptance server 104 can change the transaction mode of the receiver 101 so that the receiver can conduct transactions of the second transaction type.

[0064] Steps S302-S306 may be similar to steps S102-S104. In steps S302 and S304, the receiver 101 inputs the amount for the transaction to the acceptance application 102A on the receiver user device 102 and the receiver user device 102 obtains the sender credential from the sender portable device 105. In step S306, the acceptance application 102A submits a second transaction request message with the receiver credential, the sender credential, the amount for the transaction, and optionally the cryptogram to the acceptance server 104.

[0065] In step S308, the acceptance server 104 can determine that the transaction is of the second transaction type. For example, the second transaction request message may comprise an indicator that the transaction is the second transaction type, or the acceptance server 104 may use the receiver credential to look up whether or not the transactions conducted by the receiver 101 are to be processed as transactions of the second transaction type. The acceptance server 104 can generate an authorization request message such as an ISO 8583 message and can transmit the authorization request message to the transport computer 111. The authorization request message may comprise the sender’s credential, an identifier for the transport computer and / or the account at the transport computer (e.g., an acquirer BIN), a cryptogram, and a transaction amount.

[0066] In steps S310 and S312, the transport computer 111 transmits the authorization request message to the processing network computer 106. The processing network computer 106 then routes the authorization request message to the first authorizing entity computer 110 for approval, and the first authorizing entity computer 110 may reply with an authorization decision in an authorization response message. The authorization response message may be transmitted from the first authorizing entity computer 110 to the processing network computer 106 to the transport computer 111. The funds may be held in an account managed by the transport computer 111.

[0067] In step S314, at the end of the day or any other suitable period of time, the processing network computer 106 may facilitate a clearing and settlement process between the first authorizing entity computer 110 and the transport computer 111. The funds associated with the transaction can be held on an account for the receiver managed by the transport computer 111.

[0068] In some embodiments, a transaction can be initiated via a sender user device. FIG. 4A shows a block diagram of a system and an overlaid method. In the method, messaging is initiated using a sender user device, and a transaction of the first type is conducted. In this example, the receiver 101 can present a receiver credential (e.g., a QR code) to an acceptance application 402A on the sender user device 402. The acceptance application 402A can obtain the credential (e.g., scan the QR code) using the sender user device 402 to initiate a transaction. Unlike the method described in FIG. 1 , a receiver user device of the receiver 101 is not needed to accept payment. FIG. 4A shows an acceptance server 104 in communication with the sender user device 402, a gateway 109, a processing network computer 106, a first authorizing entity computer 110, and a second authorizing entity computer 112.

[0069] In step S402, the sender can initiate a transaction and input to the acceptance application 102A an amount for the transaction. The sender 103 can select a sender credential, or the acceptance application 204A may retrieve the sender credential from storage if it was previously provided.

[0070] In step S404, the acceptance application 102A may prompt the receiver 101 for a receiver credential. The receiver 101 can then present a receiver credential to the sender user device 402. The sender 103 can use the acceptance application 402A on the sender user device 402 to obtain capture the receiver credential. For example, the receiver 101 can present a QR code encoding the receiver credential to the sender 103. The sender 103 can then scan the QR code using the sender user device 402. The acceptance application 402A may launch a checkout page comprising transaction details such as the amount for the transaction.

[0071] In step S406, the sender 103 can confirm the transaction details via the acceptance application 402A, and the acceptance application 402A can transmit the sender credential, the receiver credential, and the amount for the transaction to the acceptance server 104.

[0072] Steps S408-S422 may be similar to steps S108-S122 of FIG. 1 , and the processing steps associated with transactions of the first type are incorporated herein. If the acceptance server 104 determines that the receiver credential can be used to conduct transactions of a second type, the acceptance server 104 may later invite the receiver 101 via a receiver user device (not shown) to change theprocessing of its transactions to the second transaction type, as described above with reference to FIG. 2. In some embodiments, a notification may be sent to the sender user device 402.

[0073] It is apparent that transactions of the second type can be conducted with the sender user device 402, using steps S402, S404, and S406, after the acceptance server 104 determines that the processing of the transactions conducted using the receiver credential can be changed so that they are transactions of the second type. This method is illustrated in FIG. 4B.

[0074] FIG. 4B shows a block diagram of a system and an overlaid method for conducting a transaction of the second type initiated using a sender user device. FIG. 4B shows an acceptance server 104 in communication with the sender user device 402, a transport computer 111 , a processing network computer 106, a first authorizing entity computer 110, and a second authorizing entity computer 112.

[0075] Steps S452-S456 may be similar to S402-S406 of FIG. 4A. Similar to FIG. 4A, the receiver 101 can present a receiver credential (e.g., a QR code) to an acceptance application 402A on the sender user device 402, and the acceptance application 402A can obtain the credential (e.g., scan the QR code) using the sender user device 402. The acceptance application 204A can transmit a sender credential, the receiver credential, and an amount for the transaction to the acceptance server 104.

[0076] Steps S458-S464 may be similar to S308-S314 of FIG. 3. Upon receiving the sender credential, the receiver credential and an amount for the transaction, the acceptance server 104 determines that the transaction is the second transaction type, and initiates the transaction accordingly.

[0077] FIG. 5 illustrates a block diagram of an acceptance server 500 according to embodiments. The acceptance server 500 may be associated with an acceptance application on a receiver user device. The acceptance server 500 may comprise a processor 502, which may be coupled to a computer readable medium 504, data storage 506, and a network interface 508. The data storage 506 may contain transaction data such as account identifiers, tokens and / or credentials, as well as mappings between the transaction data and communication device identifiers such as phone numbers, IP addresses, etc.

[0078] The computer readable medium 504 may comprise executable code for performing a method comprising receiving a first plurality of transaction requests comprising a receiver credential and correspondingly processing a first plurality of transactions of a first transaction type using the receiver credential; analyzing data associated with the first plurality of transactions of the first transaction type; responsive to analyzing the first plurality of transactions of the first transaction type, automatically determining that the receiver credential is capable of being used to conduct transactions of a second transaction type; and receiving a second plurality of transaction requests comprising the receiver credential and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential. .

[0079] The computer readable medium 504 may comprise a number of software modules including a communication module 504A, an activity monitoring module 504B, a user upgrade module 504C, and a transaction routing module 504D.

[0080] The communication module 504A may comprise code that causes the processor 502 to generate, forward, reformat, and receive messages, and / or otherwise communicate with other entities. For example, the communication module 504A can comprise code that enables the processor 502 to receive transaction request messages from an acceptance application on a user device and transmit transaction data and values to a gateway computer and / or a transport computer.

[0081] The activity monitoring module 504B can comprise code that causes the processor 502 to check that the activity of a sender and a receiver is within transaction limits (e.g., limits for transactions of the first type). The activity monitoring module 504B may comprise code that causes the processor 502 to analyze past transactions of the sender credential and receiver credential and determine information such as transaction frequency, average transaction amount, etc.

[0082] The user upgrade module 504C can comprise code that causes the processor 502 to invite a receiver to upgrade from a first transaction type to a second transaction type. The user upgrade module 504C, in conjunction with the processor 502, may utilize past transaction data of the receiver to upgrade the receiver and facilitate the onboarding of the receiver to enable the second transaction type.

[0083] The transaction routing module 504D can comprise code that causes the processor 502 to route transactions accordingly. Transactions may be the first type of transaction or the second type of transaction. For example, to route transactions of the first type, the transaction routing module 504D, in conjunction with the processor 502, may generate and transmit pull transfer messages and push transfer messages, or authorization request messages.

[0084] FIG. 6 is a block diagram illustrating an example receiver user device 600. The receiver user device 600 can be a mobile device (e.g., mobile phone) with an acceptance application 604. The receiver user device 600 may include device hardware 608 coupled to a system memory 602.

[0085] Device hardware 608 may include a processor 610, input elements 612, a short range antenna 614, a user interface 616, output elements 618, and a long range antenna 620. Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. The processor 610 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and / or microcontrollers), and is used to control the operation of the receiver user device 600. The processor 610 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 602, and can maintain multiple concurrently executing programs or processes.

[0086] The long range antenna 620 may include one or more RF transceivers and / or connectors that can be used by receiver user device 600 to communicate with other devices and / or to connect with external networks. The input and output elements 618, 618 allow a user to interact with and invoke the functionalities of the receiver user device 600. The short range antenna 614 may be configured to communicate with external devices through a short range communication medium (e.g. using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 620 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0087] The system memory 602 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories(e.g. DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 602 may also store an acceptance application 604 and / or an operating system 606. The acceptance application 604 may include instructions or code implementing an acceptance application 604 for accepting a sender credential and initiating the transfer of funds from a sender to a recipient. The acceptance application 604 may also include code, executable by the processor 610, for communicating with an acceptance server.

[0088] FIG. 7 shows an example portable device 700 in the form of a card. The portable device 700 comprises a substrate 700A such as a plastic substrate. A contactless element interface 700B for interfacing with a data access or data transfer device may be on or embedded within the substrate 700A. The contactless element interface 700B may include a chip and may include the capability to communicate and transfer data using near field communications (NFC) technology or other short range communications technology. The portable device 700 may be issued to a user by an authorizing entity.

[0089] The portable device 700 may also include a memory 700C, which may store user information such as an account number, expiration date, and a user name. In some cases, the memory 700C may include a secure element, and / or may also store information such as access data such as a sender credential (e.g., a sender PAN) or a receiver credential (e.g., a receiver PAN). Information in the memory 700C can be transmitted by the portable device 700 to another device such as a user device using the contactless element interface 700B. Information may also be printed or embossed on the substrate 700A. The substrate 700A may also have a magnetic stripe 700D on it.

[0090] Embodiments of the invention provide a number of advantages. For example, a casual receiver can have their transactions quickly changed from being processed as transactions of a first type to transactions of a second type, where the transactions of the second type have greater functionality than the transactions of the first type. The change can occur without requiring the receiver to go through a lengthy onboarding process.

[0091] Any of the software components or functions described in this application may be implemented as software code to be executed by a processorusing any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include 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 compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0092] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0093] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0094] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0095] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:1 . A method comprising: receiving, by a server computer, a first plurality of transaction requests comprising a receiver credential and correspondingly processing a first plurality of transactions of a first transaction type using the receiver credential; analyzing, by the server computer, data associated with the first plurality of transactions of the first transaction type; responsive to analyzing the first plurality of transactions of the first transaction type, automatically determining, by the server computer, that the receiver credential is capable of being used to conduct transactions of a second transaction type; and receiving, by the server computer, a second plurality of transaction requests comprising the receiver credential and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential.

2. The method of claim 1 , wherein prior to receiving the second plurality of transaction requests, the server computer uses the first plurality of transactions to facilitate an onboarding between a receiver of the receiver credential and a transport computer.

3. The method of claim 1 , wherein the first plurality of transaction requests further comprises one or more sender credentials and a plurality of values for the first plurality of transactions.

4. The method of claim 3, wherein processing the first plurality of transactions comprises: transmitting a plurality of pull transfer messages comprising the one or more sender credentials to a gateway; and transmitting a plurality of push transfer messages comprising the receiver credential to the gateway.

5. The method of claim 1 , wherein processing the second plurality of transactions of the second transaction type using the receiver credential comprises transmitting a plurality of authorization request messages respective to the second plurality of transactions to a transport computer.

6. The method of claim 1 , wherein the analyzing, by the server computer, data associated with the first plurality of transactions of the first transaction type comprises determining that transactions associated with the receiver credential exceed a transaction frequency limit over a predetermined period of time.

7. The method of claim 1 , wherein the analyzing, by the server computer, data associated with the first plurality of transactions of the first transaction type comprises determining that a transaction in the first plurality of transactions associated with a sender credential exceeds a transaction limit set by a sender associated with the sender credential.

8. The method of claim 1 , wherein the first plurality of transaction requests is received from a receiver user device.

9. The method of claim 1 , wherein the first plurality of transaction requests is received from a sender user device.

10. The method of claim 1 , wherein the first transaction type lacks dispute processing capabilities.

11. A server computer comprising: a processor; and a computer readable medium comprising code, executable by the processor for implementing a method comprising: receiving a first plurality of transaction requests comprising a receiver credential and correspondingly processing a first plurality of transactions of a first transaction type using the receiver credential; analyzing data associated with the first plurality of transactions of the first transaction type; responsive to analyzing the first plurality of transactions of the first transaction type, automatically determining that the receiver credential is capable of being used to conduct transactions of a second transaction type; andreceiving a second plurality of transaction requests comprising the receiver credential and correspondingly processing a second plurality of transactions of the second transaction type using the receiver credential.

12. The server computer of claim 11 , wherein the method further comprises: prior to receiving the second plurality of transaction requests, using the first plurality of transactions to facilitate an onboarding between a receiver of the receiver credential and a transport computer.

13. The server computer of claim 11 , wherein the first plurality of transaction requests further comprises one or more sender credentials and a plurality of values for the first plurality of transactions.

14. The server computer of claim 13, wherein processing the first plurality of transactions comprises: transmitting a plurality of pull transfer messages comprising the one or more sender credentials to a gateway; and transmitting a plurality of push transfer messages comprising the receiver credential to the gateway.

15. The server computer of claim 11 , wherein processing the second plurality of transactions of the second transaction type using the receiver credential comprises transmitting a plurality of authorization request messages respective to the second plurality of transactions to a transport computer.

16. The server computer of claim 11 wherein analyzing data associated with the first plurality of transactions of the first transaction type comprises determining that one or more transactions involving a sender credential in one or more of the first plurality of transactions exceeds a transaction limit set by a sender associated with the sender credential.

17. The server computer of claim 11 wherein the first plurality of transaction requests are received from a receiver user device.

18. The server computer of claim 11 wherein the first plurality of transaction requests are received from a sender user device.

19. The server computer of claim 11 wherein the first transaction type is limited to domestic transactions and uses an API associated with a gateway computer.

20. The server computer of claim 11 , wherein the first transaction type does not have chargeback or dispute capabilities.

Images