WO2020086096A1

WO2020086096A1 - P2p using credit card

Info

Publication number: WO2020086096A1
Application number: PCT/US2018/057771
Authority: WO
Inventors: Venkata Naga Pradeep KAJA; Hendy Wong; Sarah Jane GALAMAY; Yuexi Chen; Garth PETERSEN
Original assignee: Visa International Service Association
Priority date: 2018-10-26
Filing date: 2018-10-26
Publication date: 2020-04-30

Abstract

Already processed payments may be split among a group having electronic devices customized with communications and cryptographic capabilities. After a first party makes a payment, the first party shares a payment confirmation with other participants. The other participants may add payment instrument information and an amount via a cryptogram that is sent to a processor. The processor may then identify and modify the original transaction to reduce the original amount by the amount of the other payors. New transactions for each payor are generated and sent to the payors for approval directly to their electronic devices.

Description

P2P USING CREDIT CARD

Background

[0001] The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0002] In some social occasions, such as dining at a restaurant, sharing a bill by requesting separate checks may be inconvenient or even unacceptable. Other times, like contributing to a gift may require one purchaser to be reimbursed for other’s share of the cost. However, after-the-fact repayments to a single purchaser may require more personal information than another participant wants to share, such as bank account information. In other cases, some private person-to-person payments charge additional fees. Further, the person picking up the check may receive reward points for the entire purchase at the expense of those who reimburse the original purchaser.

Summary

[0003] Post-payment adjustment of transaction amounts allows each participant in a group to contribute to a transaction after the original purchase is made without incurring additional fees. Participants do not have to share any personal financial information and are eligible to receive rewards points for the amount they contribute to a

transaction.

Brief Description of the Drawings

[0004] The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0005] Fig. 1 is a prior art process for manually sharing a payment;

[0006] Fig. 2 is a block diagram illustrating a request phase of a split transaction after completion of the payment in accordance with the current disclosure;

[0007] Fig. 3 is a block diagram illustrating a response phase of the split transaction in accordance with the current disclosure;

[0008] Fig. 4 is a block diagram illustrating a confirmation phase of the split transaction in accordance with the current disclosure;

[0009] Fig. 5 is an exemplary user interface for initiating a split transaction after a purchase;

[0010] Fig. 6 is an exemplary user interface for adding participants to a split transaction;

[0011] Fig. 7 is an exemplary user interface for an additional participant contributing to a split transaction;

[0012] Fig. 8 is block diagram illustrating application program interfaces for a processing system associated with splitting a transaction after a purchase;

[0013] Fig. 9 is a block diagram illustrating application program interfaces for a user device application associated with splitting a transaction after a purchase; and

[0014] Fig. 10 is a flow chart of a method of splitting a transaction in accordance with the current disclosure.

Detailed Description

[0015] Fig. 1 illustrates a prior art method of splitting a bill, for example, at a restaurant. A person 102 pays the bill with a financial instrument, which is processed according to standard techniques via a merchant 104, to the merchant’s acquirer 106 who forwards the transaction to a processor 108, such as Visa, which in turn receives an approval (or denial) from an issuer of the user’s financial instrument. The approval may be relayed back through the system to the merchant and ultimately to the user 102. The user 102 may then collect cash from other companions 112, 114, 116. Some other electronic forms of passing cash between users exist, but they require the users to have knowledge of the other’s accounts and to have, in most cases, pre-registered for that payment system. Such a transfer using a third party may require a processing fee for each user. Further, the initial user 102 receives the benefit of whatever reward points may be associated with the original purchase while the other contributors forfeit any reward benefits.

[0016] Fig 2 illustrates a method and system in accordance with the current disclosure that addresses the technological shortcomings of the prior art technique, primarily in the area of security and data confidentiality. A purchaser device 120 may use a payment application 118, such as an enhanced wallet application to make a standard purchase with the merchant 104, which follows the above process to execute a transaction. The processor 108 may have access to an account data store 128 that may be used to confirm payment information as discussed in more detail below. In some embodiments, the payment application 118 may be supported or accessed via an assistant, such as Alexa or Cortana, or via an accessory, such as a smart watch. In these cases, a physical installation of the payment application 118 may not be required.

[0017] An exemplary payment confirmation screen allowing bill sharing is illustrated in Fig. 5. The screen may be displayed at the payment application 118 of the first user device 120. The screen may include a title bar 140 and a location or merchant associated with the current transaction 142. The transaction value amount may be displayed via window 144. In this case, a user of the device 120 may be given an opportunity to split the payment via input window 146. After choosing to share or split the bill, additional choices may be offered as illustrated in Fig. 6.

[0018] Turning briefly to Fig. 6, another exemplary user interface screen of the payment application 118 may be illustrated. The merchant establishment and the total amount may be displayed in a first window 150. The user may then be given an opportunity to split the bill via a drop down box 152 or similar input field. Based on the number of participants selected, the user may be given corresponding fields 154 and 156, or more, in order to enter contact information for the other parties with whom the bill is to be split. In an embodiment, the contact information may be a mobile phone number, an social media account, an email address or other information by which the other user may be contacted. In some embodiments, the user may be allowed to suggest an amount for persons to contribute to the bill via input field 158. In some cases, the recommendation may be individualized per user or may be just a general number sent to all participants. After the contact information is entered, the user may begin the process by selecting the“share” button 160.

[0019] Returning to Fig. 2, a message may be sent to the other user devices 122,

124, 126 regarding sharing the payment. The message may include a transaction identifier that is used by the processor to locate the transaction of interest. The message may also include the total transaction amount, a suggested share amount, or both. The message may be sent via the selected path indicated by the contact information 154, 156. For example, a phone number may cause a text message to be sent while a social media account may cause a private message to be sent to the other participant. Upon receipt of the message, the payment application 118 at the other user devices 122, 124, 126 may be activated. For example, the message received from the first user may include code that directs the contents of its message to the payment application 118 in a manner similar to sending v-card contact information via a text message. That is, the message may include a code snippet that, when received and executed, causes the device 122 to activate its copy of the payment application 118 and transfer the message contents to the payment application 118. In other embodiments, the payment application 118 may be contained entirely in the message so that pre- installation of the payment application 118 is not required.

[0020] Turning briefly to Fig. 7, an exemplary user interface for the payment sharing application on a device 122 of another user is depicted. An application window 162 may show the name of the application. A request window 164 may present transaction information and the request. A payment selection window 168 may allow a user to select a payment instrument or, as illustrated, use a preselected payment instrument. The share amount window 170 may allow a user to see the amount suggested by the purchaser as well as enter either that amount or another amount for sharing. The process may continue using the“send” button 172.

[0021] When the send button is selected, the payment application 118 of device 122 (and other devices correspondingly) may generate a payment bundle that may include the transaction identifier, the original amount, the user share amount, and payment instrument information. In some embodiments, the payment instrument may be an actual personal account number (PAN) while in other embodiments the payment instrument may be in the form of a token. The payment bundle may be encrypted using an appropriate encryption technique such as with a private key in a PKI system or using a symmetric key known to the ultimate recipient.

[0022] Continuing at Fig. 3, the process may continue with the payment bundle or bundles being received. In some embodiments, the payment bundle may be

transmitted to the first user device 120 and forwarded to the processor 108 and more specifically to a processor integration application 130. The processor integration application 130 is discussed in more detail below with respect to Fig. 8. In other embodiments, the respective payment applications 118 of the other user devices 122, 124, 126 may send payment bundles directly to the processor integration application 130. For example, in some cases, a smart watch or digital assistant may send the payment bundle to the first user device 120 via near field communication (tap), at which point the first user device 120 may forward the payment bundle. Because the payment bundle is encrypted, no personal information of the second user is disclosed to the user making the original purchase. In an embodiment, the payment bundle may include the user’s share amount outside the encrypted portion, so that the first user may be able to see the amount contributed by the other participants. In this embodiment, the user device 120 may forward the payment bundle to the processor 108 for additional processing. In another embodiment, some or all of the other user devices 122, 124,

126 may send payment bundles directly to the processor 108, bypassing the first user device 120.

[0023] The payment bundle may be received at the processor 108 either directly or indirectly from the other user devices 122, 124, 126, or however many other devices/users participate in sharing the transaction. In an embodiment, the first user device 120 may forward a number indicating how many other users are participating in the transaction so that processing may be delayed until all the payment bundles are received. The processor integration application 130 may collect the payment bundles, identify the additional participants, and decrypt the payment bundles using information available in the account data store 128. This information may include token references, public keys of users, symmetric keys for users, as well as account and contact information, etc. Once the users are identified, all the expected payment bundles are accounted for, decrypted and checked, and the original transaction information is located, further processing may begin.

[0024] The processing may be implemented via an exemplary transaction split application program interface (API) 186 illustrated in Fig. 8. The API 186 may support interactions with the various payment applications 118 including support for

communication/messaging protocols, identification and customization of messages for platform type and OS version, and development of messages based on transaction split results.

[0025] A search and update tool 184 may support background processing of transactions. For example, when a transaction split request is received the original transaction must be located. In some cases, the transaction may have already been settled 182, meaning that the original purchaser’s issuer account has been debited for the purchase amount. In this case, the transaction will have to be reversed based on the other users payment amounts and the new amount re-transacted. In another case, the transaction may still be pending 180 so that the original purchase amount may simply be changed to the new amount. In either case, new transactions for the other user amounts will be generated by the tool 184 and placed into a normal processing flow. After the proposed new transactions are approved by the user’s respective card issuers 110, confirmation notices may be generated at the transaction split API 186 and sent to the participating devices 120, 122, 124, 126.

[0026] In one embodiment, a confirmation message may be sent to the other devices 122, 124, 126 so that each other user may have a chance to review and approve the charges. When a response to the confirmation message is received, the original transaction may be split with the original transaction amount being reduced by the sum of the other payments. The other payments may be processed accordingly. The original merchant transaction may, in an embodiment, receive updated transactions referencing the original transaction or the additional processing may happen without notifying the original merchant. Each participant, however, may be eligible for reward points based on the newly generated transactions. Fig. 4 illustrates the completed transaction notifications being sent to the participants while various issuers are sent transaction completion information.

[0027] Fig. 9 may illustrate a block diagram illustrating interactions between a user device 120 and the payment application 118. In this exemplary embodiment, the payment application 118 may exist as part of a user wallet application 200. Flowever, in other embodiments, the payment application 118 may stand alone. In some

embodiments, the payment application 118 may exist in the cloud and access may be accomplished via a browser or even via an assistance such as Alexa or Cortana.

[0028] When operating, the payment application 118 may be able to review incoming messages, including text and social media messages to scan for content related to bill splitting. As discussed above, such a review may include identifying and installing code that may execute on the user devices 120, 122, 124, 126 for the purpose of supporting the required user interfaces for bill splitting, both to initiate requests and to respond to requests. In other cases, the message monitoring may extract as little as the

transaction identifier from an incoming message in order to automatically initiate the process of making a split payment. The payment application 118 may also include interfaces to a user’s contact information 204 to aid in addressing a bill split request.

For example, changing focus to the contact input field 154 may initiate access to the user’s contact database 204, allowing selection of known contacts for sending bill split information. The payment application 118 may also need access to the user interface 206 of the device 120, 122 in order to interact with the users of the devices 120, 122. A secure element 119 may support cryptographic operations including key storage, key derivation, signing/signature checking, and encryption/decryption. [0029] Fig. 10 is a flowchart of an exemplary method 240 of performing a split of a completed transaction in accordance with the current disclosure. At block 242, an original transaction with a merchant may be generated associated with a purchase transactions for goods or services. For example, a customer may pay a bill at a restaurant or for a service such as a taxi.

[0030] At block 244, the user may receive the confirmation of the payment for the original transaction for a first value amount at a user device 120. The confirmation may include a payment detail such as a transaction number or confirmation number associated with the payment.

[0031] The user device 120 may display, at block 246, via a payment application 118, an interface that receives a reference that identifies a contact information for a user associated with the other user device. The reference may be a mobile phone number, an email account, a social media account, or another identifier that can be used to uniquely identify another person and may be used to send information to that user.

[0032] Then, at block 248, the payment detail may be shared with one or more other users via respective user devices 122, 124, 126. The payment detail may include the transaction amount, but at a minimum may include the transaction identifier used by a processor 108 to identify the unique transaction associated with payment made at block 242. Sharing the payment detail with the other user device may also include sending a merchant identifier and a suggested second value amount to the other user device 122.

[0033] In an embodiment, the payment detail may be shared via a wide area network such as a cellular text message or social media message. In other embodiments, the payment detail may be shared using a short range network such as WiFi, Bluetooth, or NFC. For example, the corresponding payment applications 118 in the sending device 120 and the receiving device or devices 122, 124, 126 may notify their respective users of incoming messages. In another embodiment, the payment detail may be transmitted via a QR code displayed by the user device 120 and scanned by the other participating devices 122, 124, 126. These same communication methods may be used in the cases when a response is returned to the user device 120. [0034] At block 250, at one or more other user devices 122, 124, 126, responsive to receiving the payment detail/split payment request, a payment application 118 may be launched that supports various functions, including capture of the payment detail sent from the user device 120. The payment application 118 may capture via a user interface 206 a second value amount that the other user is willing to contribute to the purchase. The payment application 118 may also display payment instrument options. The application 118 may then capture a user selection of the payment instrument for use in processing the payment split. The second value amount may be required to be less than the original transaction amount, otherwise an error may be generated downstream. The payment application 118 may, via the secure element 119, perform cryptographic processing of the selected payment instrument, the second value amount, and the payment detail into a cryptogram in a standard format. For example, the cryptogram may follow an EMV format for transaction cryptograms. Once the

cryptogram is generated a payment bundle may be prepared for transmission. The cryptogram, as the name implies, may be encrypted to protect personal and financial instrument information and to ensure use only by an authorized party, such as the processor 108. The payment bundle may include the cryptogram as well as other related information such as addressing information, the transaction identifier for indexing, or an unofficial value amount for use, as discussed above, by the first user device 120 to make an unofficial accounting of the shared expenses.

[0035] At block 252, the payment bundle may be received from the other user device 122. In different embodiments discussed above, the payment bundle may be received at the first user device 120 for forwarding to the processor 108 or may be sent directly to the processor 108. When received at the first user device 120, a local, although unofficial accounting can be made as to the final shared amounts. Some variations for tax round off, etc. may occur after final processing. After receipt by the processor 108, and more specifically at the processor integration application 130, the payment bundle may be decrypted and parsed for processing. The transaction search tool 184 may find the original transaction to confirm the details received. The integration application 130 may then generate new transactions for the added participants using the payment instrument included in the payment bundle and have those transactions authorized at their respective issuers. As discussed above, the processor 130 may have different ways of dealing with the original transaction based on whether it has been cleared or not.

[0036] At block 254, confirmations may be sent to the new participants, via respective devices 122, 124, 126. When the confirmations are returned the final transactions for the new participants may be processed and any award points credited.

[0037] Finally, at block 256, the original payment value may be reduced by the total of the other payment amounts. For example, if only one other user participates in the bill split by contributing a second value amount, the second value amount may reduce the original (first) value amount to generate a third payment value. This is the final amount billed to the original purchaser. A confirmation of the third payment value may be sent to the user device 120. In the case where the original payment has not been settled, the first value amount may simply be reduced before settlement. In the case where the original payment has been settled, the first value amount may be refunded to the user and a new transaction for the third value may be processed. The final, or third, value for the first user may be calculated as the original total amount minus the sum of all the payments made by other participants.

[0038] The technical effect of the described system provides for secure and accurate passing of transaction data and financial instrument data between parties. At no time does the original purchaser have account details of the other participants, even when the secondary transactions pass through the original purchaser’s device 120. A further technical solution is the application program interface allowing the payment application 118 to screen and collect data from other messaging platforms on the devices 122, 124, 126, so that the secondary users do not have to enter a transaction identifier or other information received via the payment split application. This process for screening and identifying information received via text message, social media message, etc., significantly reduces the burden on the user and improves the security and accuracy of the subsequent steps in the process.

[0039] Users and merchants alike benefit from the described system and method. Merchants are not burdened with processing multiple transactions on“separate checks.” Users are able to contribute a fair share to a purchase without overpaying in cash, sharing account details, or incurring a surcharge for making a separate person-to- person payment. Users are further able to capture reward points for transactions in which they did not originally participate.

[0040] The figures depict preferred embodiments for purposes of illustration only.

One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein

[0041] Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be

understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.

Claims

1. A method for split settlement of completed transactions, the method comprising:

receiving a confirmation of a payment for a first value amount at a user device;

sharing a payment detail with another user device;

receiving a payment bundle from the other user device, the payment bundle including a cryptogram containing payment instrument data and a second value amount, the second value amount less than the first value amount;

receiving at a processing system the confirmation of the payment and the payment bundle;

reducing the payment first value amount by the second value amount to generate a third payment value and sending a confirmation of the third payment value to the user device;

creating a new payment transaction using the payment instrument data extracted from the cryptogram for the second value amount; and

sending a confirmation message for the new payment transaction to the other user device, wherein a sum of the second value amount and the third value amount equals the first value.

2. The method of claim 1 , further comprising:

displaying, at the user device via a first application, an interface that receives a reference that identifies a contact information for a user associated with the other user device.

3. The method of claim 2, wherein the reference is one of a mobile phone number, an email account, and a social media account.

4. The method of claim 2, further comprising: displaying, via the first application at the user device, information from the payment bundle.

5. The method of claim 4, further comprising:

sending the payment bundle to the processing system from the user device via the first application.

6. The method of claim 5, wherein the payment bundle is cryptographically signed by the first application.

7. The method of claim 1 , further comprising:

providing, at the other user device, a pay split application supporting: receipt of the payment detail from the user device;

capture of the second value amount;

display of payment instrument options and capture of a user selection of the payment instrument;

cryptographic processing of the payment instrument, the second value amount, and the payment detail into the cryptogram in a standard format; and transmission of the payment bundle to the user device.

8. The method of claim 7, further comprising:

displaying, at the other user device via the pay split application, a confirmation request received from the processing system, the confirmation request for receiving an approval to proceed with the new payment transaction.

9. The method of claim 1 , wherein reducing the payment first value amount comprises changing a value of the first value amount to the third value amount responsive to the payment having not been settled.

10. The method of claim 1 , wherein reducing the payment first value amount comprises refunding the first value amount and entering a new transaction for the third value amount responsive to the payment having been settled.

11. The method of claim 1 , wherein sharing the payment detail with the other user device comprises sending at least one of a transaction identifier, a merchant identifier, and a suggested second value amount to the other user device.

12. The method of claim 11 , wherein sharing the payment detail with the other user device comprises sharing the first value amount with the other user device.

13. The method of claim 1 , further comprising:

processing, via a first application, an original transaction with a merchant prior to receiving the confirmation of the payment.

14. A system for split settlement of completed transactions comprising:

a first user device modified with a first pay split application that operates to:

process an original transaction with a first merchant for a first value amount;

receive a confirmation of the original transaction, the confirmation including a payment detail;

receive a selection of other users with which to split the first value amount of the original transaction; and

send a notification to the selection of other users, the notification including the payment detail;

a second user device operated by one of the selected other users, the second user device modified with a second pay split application that operates to:

receive the payment detail from the first user device; using the payment detail, generate a user screen that receives a selection of payment instrument and a second value amount, the second value amount less than the first value amount;

generate a cryptogram for a second transaction using the selected payment instrument and second value amount;

send the cryptogram via a network; and

receive a confirmation message for the second transaction via the network;

a processing system that processes the original transaction, receives the cryptogram from the second user device and generates the confirmation message that is sent to the second user device, the processing system modified to further:

modify the original transaction to reduce the first value amount by the second value amount; and

generate a new transaction for the merchant of the second value amount using the selected payment instrument.

15. The system of claim 14, wherein the first user device stores a contact information for one or more of the other users.

16. The system of claim 14, wherein the first user device sends the notification directly to one or more of the selected other users via one of a short range wireless connection or a QR code.

17. The system of claim 14, wherein the first user device sends the notification via a cellular network to one or more of the selected other users.

18. The system of claim 14, wherein the first user device sends the notification to one or more of the selected other users via the processing system.

19. A method for intermediate settlement of split transactions comprising: receiving a confirmation of an initial payment for a first value amount at a user device;

sharing a payment detail with at least one other user device; receiving a payment bundle from a respective one of each of the at least one other user device, each payment bundle including a cryptogram containing payment instrument data and a second value amount, the second value amount less than the first value amount;

reducing the payment first value by a sum of the second value amounts to generate a third payment value;

adjusting the initial payment from the first value amount to the third payment value;

sending a confirmation of the third payment value to the user device; creating one or more new payment transactions using the respective payment instrument data from each cryptogram for the respective second value amounts; and

sending a confirmation of the new payment transaction to the other user device, wherein a sum of the second value amounts and the third payment value equals the first value amount.

20. The method of claim 19, wherein receiving the payment bundle from the respective one of the at least one other user device comprises receiving the payment bundle at the user device.