TECHNICAL FIELD

[0001] Various aspects of this disclosure relate to methods and devices for detecting a merchant from a payment transaction between a payor and a payee.

BACKGROUND

[0002] A merchant starting a new business may fraudulently masquerade as a regular (non-merchant) user, and may accept peer-to-peer (P2P) payments via a quick response (QR) code associated with his or her personal account. The merchant may do this to avoid fees and commissions that are incurred by onboarding onto a payment service’s merchant platform, and/or to skip time-consuming Know Your Customer processes that may delay his or her venture. Also, the merchant may be trying to gauge interest before registering a full merchant account. Further, P2P payments via the QR code may be a convenient payment method for the merchant, unlike payments via a credit or debit card that may require a point-of-sale machine with associated onboarding actions required to be carried out with the merchant’s acquirer.

[0003] Existing solutions to the above problem may rely on location to detect a merchant fraudulently accepting P2P payments. However, a location of a mobile merchant operating, for example, a pop-up store or a food truck may not correspond to any known commercial location that may be associated with a base of commercial operations, as the location of the mobile merchant may keep changing, bypassing automated checks reliant on a fixed location. Thus, location-based solutions alone may be ineffective at detecting a merchant fraudulently masquerading as a regular user.

SUMMARY

[0004] Various embodiments concern a method for detecting a merchant from a payment transaction between a payor and a payee, the method including receiving, by a payment server of a payment service, from a payor device of the payor, one or more tags of one or more objects in a payment transaction environment in one or more images that is captured as part of the payment transaction, obtaining, by the payment server, payee transaction data of one or more payment transactions of the payee, and receiving, by the payment server, a payee location of the one or more payment transactions of the payee. The method further includes determining, by the payment server, whether the payee is the merchant, based on the received one or more tags, the obtained payee transaction data and the received payee location, and based on the payee being determined to be the merchant, sending, by the payment server, to a payee device of the payee, payment service information for the payee to register on and/or use the payment service as the merchant.

[0005] The method may further include receiving, by the payment server, from the payor device, a payor input indicating whether the payee is the merchant. [0006] The determining whether the payee is the merchant may include determining, by the payment server, whether the payee is the merchant, further based on the received payor input indicating whether the payee is the merchant.

[0007] The payee transaction data may include a volume, a frequency and a value of each of the one or more transactions of the payee.

[0008] The determining whether the payee is the merchant may include, based on an amount of the received one or more tags that are related to the merchant being greater than or equal to a predetermined amount, determining, by the payment server, that the payee is the merchant.

[0009] The determining whether the payee is the merchant may include, based on the obtained payee transaction data being heterogeneous, determining, by the payment server, that the payee is not the merchant.

[0010] The determining whether the payee is the merchant may include, based on the received payee location of the one or more transactions of the payee being the same, determining, by the payment server, that the payee is the merchant.

[0011] The method may further include determining, by the payment server, a merchant category of the payee determined to be the merchant, based on the received one or more tags, the obtained payee transaction data and the received payee location. [0012] The payment service information may include instructions and one or more incentives for the payee to register on and/or use the payment service as the merchant.

[0013] The one or more incentives may include an offer to promote the merchant on the payment service, and an offer to provide discounts to consumers of the merchant on the payment service, in exchange for the payee registering on and/or using the payment service as the merchant and accepting favourable commission terms for the payment service.

[0014] The method may further include receiving, by the payor device, a payor input for starting the payment transaction, based on the payor input for starting the payment transaction being received, capturing, by the payor device, the image including the payment transaction environment, and generating, by the payor device, the one or more tags of the one or more objects in the payment transaction environment in the captured image. The method may further include sending, by the payor device, the generated tags to the payment server.

[0015] The method may further include, based on the payor input for starting the payment transaction being received, outputting, by the payor device, a question asking whether the payee is the merchant.

[0016] The method may further include receiving, by the payor device, in response to the output question, a payor input indicating whether the payee is the merchant.

[0017] The method may further include sending, by the payor device, to the payment server, the payor input indicating whether the payee is the merchant.

[0018] The image may be captured while scanning for a QR code in the payment transaction environment, and may include the QR code.

[0019] The method may further include removing, by the payor device, from the generated tags, banned tags that are not sent to the payment server.

[0020] The sending the generated tags may include sending, by the payor device, to the payment server, the generated tags from which the banned tags are removed. [0021 ] A server may be configured to perform the method.

[0022] A computer program element may include program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method.

[0023] A computer-readable medium may include program instructions, which, when executed by one or more processors, cause the one or more processors to perform the method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The invention will be better understood with reference to the detailed description when considered in conjunction with the non-limiting examples and the accompanying drawings, in which:

[0025] [Fig. 1] shows a diagram of a system for detecting a merchant from a payment transaction between a payor and a payee, according to embodiments;

[0026] [Fig. 2] shows a block diagram of a payor device in the system of [Fig. 1];

[0027] [Fig. 3] shows a block diagram of a payment server in the system of [Fig. 1];

[0028] [Fig. 4] shows a flow diagram of a method for detecting a merchant from a payment transaction between a payor and a payee, the method being performed a payor device, according to embodiments; and [0029] [Fig. 5] shows a flow diagram of a method for detecting a merchant from a payment transaction between a payor and a payee, the method being performed a payment server, according to embodiments.

DETAILED DESCRIPTION

[0030] The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure. Other embodiments may be utilized and structural, and logical changes may be made without departing from the scope of the disclosure. The various embodiments are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0031] The embodiments described in the context of one of the devices or methods are analogously valid for the other devices or methods. Similarly, the embodiments described in the context of a device are analogously valid for a vehicle or a method, and vice-versa.

[0032] Features that are described in the context of an embodiment may correspondingly be applicable to the same or similar features in the other embodiments. Features that are described in the context of an embodiment may correspondingly be applicable to the other embodiments, even if not explicitly described in these other embodiments. Furthermore, additions and/or combinations and/or alternatives as described for a feature in the context of an embodiment may correspondingly be applicable to the same or similar feature in the other embodiments. [0033] In the context of the various embodiments, the articles “a”, “an” and “the” as used with regard to a feature or element include a reference to one or more of the features or elements.

[0034] As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

[0035] In the following, the embodiments will be described in detail.

[0036] [Fig. 1 ] shows a diagram of a system 100 for detecting a merchant from a payment transaction between a payor and a payee, according to embodiments.

[0037] Referring to [Fig. 1], the system 100 includes a payor device 105 of the payor, a payee device 110 of the payee, a network 115, a payment source 120 and a payment server 125 providing a payment service.

[0038] Each of the payor device 105 and the payee device 110 may include, e.g., a smartphone and/or a personal computer. Each of the payment source 120 and the payment server 125 may include a server computer or an arrangement of server computers. The payor device 105, the payee device 110, the payment source 120 and the payment server 125 are connected by the network 115, typically, the Internet, which may be implemented by an arrangement of communication networks, e.g., a radio access network, a backhaul network, a backbone network, etc.

[0039] The payor device 105 may contact the payee device 110 to make the payment transaction between the payor and the payee for a good or service provided by the payor. The payor device 105 and the payee device 110 may use the digital payment service for convenience (rather than, for example, perform a cash transfer via a bank of the payor), and the payor device 105 therefore sends a request to the payment server 125 to perform the payment transaction, e.g., via a payment application installed in the payor device 105 and hosted by the payment server 125.

[0040] However, the payment transaction may be a P2P payment transaction between two regular users instead of a payment transaction between a consumer and a merchant (e.g., an operator of a retail business or a storekeeper) using a payment service’s merchant platform. As discussed above, the payee may be a merchant who fraudulently requests the P2P payment transaction, e.g., to avoid fees and commissions that are incurred by onboarding onto the payment service’s merchant platform.

[0041 ] To combat merchant fraud, in the P2P payment transaction, the payor is requested to use a camera of the payor device 105 to capture an image 106 of a QR code 107 of the payee, the image 106 possibly including one or more objects in an environment of the payment transaction, such as, e.g., a store sign 108. The payor device 105 then uses captured image 106 of the QR code 107 to generate and send the request to the payment server 125 to perform the payment transaction between the payor and the payee. In some embodiments, the image 106 may include multiple images that may be arranged sequentially, or a video data file comprising multiple image frames.

[0042] The payment server 125 then contacts the payment source 120 (e.g., a bank at which the payor has an account) to settle the payment transaction (e.g., to have money transferred from the account of the payor to an account of the payee, which the payee may have at some bank or with the digital payment service). Ideally, the payment transaction may be successfully settled, and in response, the payment server 125 informs the payee that the payment transaction is settled. The payee may then typically provide or ship the goods or provide the service. Payment for the service or goods (such as, e.g., a cab ride or a pizza delivery) may also be settled after provision of the service or goods.

[0043] The embodiments described herein include the payment service detecting whether the payee of the P2P payment transaction is a merchant not registered on and/or using the payment service’s merchant platform, allowing the payment service to onboard such a merchant before a competitor does. The detection is performed based on a combination of a location of the payee, transaction data and/or usage patterns of the payee and object detection via the payor device 105 of the payor.

[0044] The object detection via the payor device 105 may be performed before and after the payor uses the camera of the payor device 105 to capture the image 106 of the QR code 107 of the payee. In detail, the object detection generates tags of the objects (e.g., merchandise being sold and the store sign 108) in a scene or the environment surrounding the QR code 107 and included in the captured image 106. If these tags are consistently the same (e.g., if “food” is generated for the payee for all transactions), the payee is likely to be a street food vendor.

[0045] Advantageously, combining the object detection with parameters like the location and usage patterns of the payee may make the embodiments described herein more robust and accurate than existing solutions, while avoiding collection of personal information captured by the camera. That is, privacy of the personal information may be maintained because only the generated tags are sent to the payment service, not the captured image 106. [0046] Also, by identifying merchants, the payment service may obtain the following competitive advantages. For example, the payment service may be able to figure out up-and-coming merchants and onboard them to its platform before competitors. In another example, the payment service may be able to negotiate favourable commission terms with the merchants in exchange for promoting them and driving consumers to them via offers and discounts.

[0047] [Fig. 2] shows a block diagram of the payor device 105 in the system 100 of [Fig. 1].

[0048] Referring to [Fig. 2], the payor device 105 includes a user interface 205, a processor 210, a sensor 215, a memory 220, a communication interface 225 and an object detector 230.

[0049] The user interface 205 may include, e.g., a touchscreen of the smartphone, and/or a display, a mouse and a keyboard of the personal computer. The user interface 205 may receive, from the payor, a payor input for executing the payment application.

[0050] The processor 210 may include one or more of a central processing unit (CPU), a graphics processor unit (GPU), an accelerated processing unit (APU), a many integrated core (MIC), a field-programmable gate array (FPGA), and/or a digital signal processor (DSP). The processor 210 may be a general-purpose controller performing control of any one or any combination of other components of the payor device 105, and/or performing an operation or data processing relating to communication. The processor 210 may execute one or more programs stored in the memory 220. [0051 ] The memory 220 may include a volatile and/or non-volatile memory. The memory 220 stores information, such as one or more of commands, data, programs (one or more instructions), applications, etc., which are related to at least one other component of the payor device 105 and for driving and controlling the payor device 105. For example, commands and/or data may formulate an operating system (OS). The information stored in the memory 220 may be executed by the processor 210. The memory 220 may further store information that is executed by the processor 210 to perform functions and operations described with respect to [Figs. 1 , 2 and 4].

[0052] Based on receiving, from the user interface 205, the payor input for executing the payment application, the processor 210 may obtain, from the memory 220, payment application data of the payment application, and may execute the payment application, based on the obtained payment application data. The user interface 205 receives, from the payor, a payor input for starting the payment transaction between the payor and the payee, which may be input into the executed payment application.

[0053] The sensor 215 may include, e.g., a camera configured to capture an image, a microphone configured to record ambient sound and/or any other sensor configured to sense one or more features of an environment of the payor device 105. [0054] Based on receiving, from the user interface 205, the payor input for starting the payment transaction, the processor 210 controls the sensor 215 to capture the image 106 of the QR code 107 and/or the payment transaction environment surrounding the QR code 107, as shown in [Fig. 1]. The payment transaction environment may include the one or more objects, such as, e.g., the store sign 108 of [Fig. 1 ]. In embodiments, the image 106 may be captured before or after the QR code 107 is captured, and thus, the image 106 may include only the payment transaction environment. Also, consumers may be reluctant to take photos of a QR code and/or a payment transaction environment, but may be incentivized to do so via reward points.

[0055] In embodiments, based on receiving, from the user interface 205, the payor input for starting the payment transaction, the processor 210 may control the sensor 215 to record ambient sound and/or to sense one or more features of the payment transaction environment.

[0056] Based on receiving the captured image 106 (the recorded ambient sound and/or the sensed features) from the sensor 215, the object detector 230 generates the tags of the objects in the payment transaction environment. The tags may include words describing the objects. For example, the word “food” may describe the store sign 108. The object detector 230 may include and/or use at least one among various image recognition software and/or neural networks, such as, e.g., a fast region-based convolutional neural network (R-CNN) and a faster R-CNN.

[0057] Based on the payor input for starting the payment transaction being received from the user interface 205, the processor 210 may further control the user interface 205 to output, to the payor, a question asking whether the payee is a merchant (or whether the payment transaction is for goods or services). The question may be output as, e.g., text displayed on the display and/or the touchscreen. The user interface 205 may then receive, from the payor, in response to the output question, a payor input indicating whether the payee is a merchant (or whether the payment transaction is for goods or services). The payor input may be input as, e.g., text typed into a text box displayed on the display and/or the touchscreen. [0058] The communication interface 225 may serve as a hardware and/or software interface that can, for example, transfer commands and/or data between the payor device 105 and/or external devices and the other components of the payor device 105. The communication interface 225 may further set up communication between the payor device 105 and the external devices, such as the payment server 125 of [Fig. 1]. The communication interface 225 may be connected with the network 115 of [Fig. 1] through wireless or wired communication architecture to communicate with the external devices. The communication interface 225 may be a wired or wireless transceiver or any other component for transmitting and receiving signals.

[0059] The communication interface 225 may receive the generated tags from the object detector 230, and may receive the payor input indicating whether the payee is a merchant from the user interface 205 and/or the processor 210. The processor 210 may control the communication interface 225 to send, to the payment server 125, the received tags and/or payor input indicating whether the payee is a merchant. The communication interface 225 and/or the processor 210 may maintain a list of banned tags (e.g., a name of a family member or friend) that are not sent to the payment server 125 to ensure stricter privacy protections. The communication interface 225 and/or the processor 210 may remove the banned tags from the received tags before sending, to the payment server 125, the received tags from which the banned tags are removed. [0060] [Fig. 3] shows a block diagram of the payment server 125 in the system 100 of [Fig. 1],

[0061] Referring to [Fig. 3], the payment server 125 includes a payor interface 305, a processor 310, a payment source interface 315, a memory 320, a payee interface 325 and a location service interface 330. [0062] Each of the payor interface 305, the payment source interface 315, the payee interface 325 and the location service interface 330 may serve as a hardware and/or software interface that can, for example, transfer commands and/or data between the payment server 125 and/or external devices and other components of the payment server 125. Each of the interfaces 305, 315, 325 and 330 may further set up communication between the payment server 125 and the external devices, such as the payor device 105 of [Fig. 1]. Each of the interfaces 305, 315, 325 and 330 may be connected with the network 115 of [Fig. 1] through wireless or wired communication architecture to communicate with the external devices. Each of the interfaces 305, 315, 325 and 330 may be a wired or wireless transceiver or any other component for transmitting and receiving signals.

[0063] The payor interface 305 may receive, from the payor device 105, the tags and/or the payor input indicating whether the payee is a merchant.

[0064] The processor 310 may include one or more of a CPU, a GPU, an APU, an MIC, an FPGA, and/or a DSP. The processor 310 may be a general-purpose controller performing control of any one or any combination of other components of the payment server 125, and/or performing an operation or data processing relating to communication. The processor 310 may execute one or more programs stored in the memory 320.

[0065] The processor 310 controls the payment source interface 315 to send, to the payment source 120, payment transaction information for settling the payment transaction. The payment transaction information may include information of the payor, the payee and the goods or services provided by the payee to the payor. [0066] The memory 320 may include a volatile and/or non-volatile memory. The memory 320 stores information, such as one or more of commands, data, programs (one or more instructions), applications, etc., which are related to at least one other component of the payment server 125 and for driving and controlling the payment server 125. For example, commands and/or data may formulate an OS. The information stored in the memory 320 may be executed by the processor 310. The memory 320 may further store information that is executed by the processor 310 to perform functions and operations described with respect to [Figs. 1 , 3 and 5].

[0067] The processor 310 may obtain, from the memory 320, the transaction data and/or usage patterns of the payee. The transaction data and/or usage patterns may include a volume, a frequency and/or a value of each transaction performed by the payee.

[0068] The location service interface 330 may receive the location of the payee from, e.g., a global positioning system (GPS) and/or a location-based service. The payee location may be received for each transaction performed by the payee.

[0069] The processor 310 may determine whether the payee is a merchant that is not registered on and/or using a merchant platform of the payment service, based on the received tags, the received payor input indicating whether the payee is a merchant, the obtained payee transaction data of each payee transaction and/or the received payee location of each payee transaction. The memory 320 may include a machine learning model and/or a neural network, into which the processor 310 may input the above parameters, to output whether the payee is a merchant.

[0070] For example, if an amount of the received tags that are related to a merchant (e.g., “food,” “store,” “clothing”) is greater than or equal to a predetermined amount, then the processor 310 may determine that the payee is a merchant. In another example, if the received payor input indicates that the payee is a merchant, then the processor 310 may determine that the payee is a merchant. In still another example, if the obtained payee transaction data of each payee transaction is heterogeneous (e.g., different or varying), then the processor 310 may determine that the payee is not a merchant. In yet another example, if the received payee location of each payee transaction is the same, then the processor 310 may determine that the payee is a merchant, e.g., a fixed stall.

[0071] Also, the processor 310 may determine a merchant category of the payee determined to be a merchant, based on the received tags, the received payor input indicating whether the payee is a merchant, the obtained payee transaction data of each payee transaction and/or the received payee location of each payee transaction. The merchant category may include a merchant category code (MCC): “food” indicates a food merchant, “clothes/textiles” indicates an apparel merchant, etc. [0072] Based on the payee being determined to be a merchant, the processor 310 controls the payee interface 325 to send, to the payee device 110, information of the payment service. The payment service information may include instructions for the payee to register on and/or use the payment service as a merchant. Also, the payment service information may include one or more incentives for the payee to register on and/or use the payment service as a merchant. These incentives may include an offer to promote the merchant on the merchant platform, and/or may include an offer to provide discounts to consumers of the merchant on the merchant platform, in exchange for the payee registering on and/or using the payment service as a merchant and accepting favourable commission terms for the payment service. [0073] [Fig. 4] shows a flow diagram of a method 400 for detecting a merchant from a payment transaction between a payor and a payee, the method 400 being performed a payor device (e.g., the payor device 105 of [Fig. 2]), according to embodiments.

[0074] Referring to [Fig. 4], in operation 405, the method 400 includes receiving, by the payor device, a payor input for starting the payment transaction.

[0075] In operation 410, the method 400 includes, based on the payor input for starting the payment transaction being received, capturing, by the payor device, an image including a payment transaction environment. The image may be captured while scanning for a QR code in the payment transaction environment, and may include the QR code.

[0076] In operation 415, the method 400 includes generating, by the payor device, one or more tags of one or more objects in the payment transaction environment in the captured image.

[0077] In operation 420, the method 400 includes, based on the payor input for starting the payment transaction being received, outputting, by the payor device, a question asking whether the payee is the merchant.

[0078] In operation 425, the method 400 includes receiving, by the payor device, in response to the output question, a payor input indicating whether the payee is the merchant.

[0079] In operation 430, the method 400 includes sending, by the payor device, the generated tags to a payment server. The method 400 may further include sending, by the payor device, to the payment server, the payor input indicating whether the payee is the merchant. [0080] The method 400 may further include removing, by the payor device, from the generated tags, banned tags that are not sent to the payment server. The sending the generated tags may include sending, by the payor device, to the payment server, the generated tags from which the banned tags are removed.

[0081 ] [Fig. 5] shows a flow diagram of a method 500 for detecting a merchant from a payment transaction between a payor and a payee, the method 500 being performed a payment server (e.g., the payment server 125 of [Fig. 3]), according to embodiments.

[0082] Referring to [Fig. 5], in operation 505, the method 500 includes receiving, by the payment server of a payment service, from a payor device of the payor, one or more tags of one or more objects in a payment transaction environment in an image that is captured as part of the payment transaction. The method 500 may further include receiving, by the payment server, from the payor device, a payor input indicating whether the payee is the merchant. In some embodiments, the image may be captured before or during the payment transaction.

[0083] In operation 510, the method 500 includes obtaining, by the payment server, payee transaction data of one or more payment transactions of the payee. The payee transaction data may include a volume, a frequency and a value of each of the one or more transactions of the payee.

[0084] In operation 515, the method 500 includes receiving, by the payment server, a payee location of the one or more payment transactions of the payee.

[0085] In operation 520, the method 500 includes determining, by the payment server, whether the payee is the merchant, based on the received one or more tags, the obtained payee transaction data and the received payee location. The determining whether the payee is the merchant may include determining, by the payment server, whether the payee is the merchant, further based on the received payor input indicating whether the payee is the merchant. Based on the payee being determined to be the merchant, the method 500 continues in operation 525. Otherwise, the method 500 ends.

[0086] The determining whether the payee is the merchant may include, based on an amount of the received one or more tags that are related to the merchant being greater than or equal to a predetermined amount, determining, by the payment server, that the payee is the merchant. The determining whether the payee is the merchant may include, based on the obtained payee transaction data being heterogeneous, determining, by the payment server, that the payee is not the merchant. The determining whether the payee is the merchant may include, based on the received payee location of the one or more transactions of the payee being the same, determining, by the payment server, that the payee is the merchant.

[0087] In operation 525, the method 500 includes, based on the payee being determined to be the merchant, sending, by the payment server, to a payee device of the payee, payment service information for the payee to register on and/or use the payment service as the merchant. The payment service information may include instructions and one or more incentives for the payee to register on and/or use the payment service as the merchant. The one or more incentives may include an offer to promote the merchant on the payment service, and an offer to provide discounts to consumers of the merchant on the payment service, in exchange for the payee registering on and/or using the payment service as the merchant and accepting favourable commission terms for the payment service. [0088] The method 500 may further include determining, by the payment server, a merchant category of the payee determined to be the merchant, based on the received one or more tags, the obtained payee transaction data and the received payee location.

[0089] The methods described herein may be performed and the various processing or computation units and the devices and computing entities described herein may be implemented by one or more circuits. In an embodiment, a "circuit" may be understood as any kind of a logic implementing entity, which may be hardware, software, firmware, or any combination thereof. Thus, in an embodiment, a "circuit" may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g., a microprocessor. A "circuit" may also be software being implemented or executed by a processor, e.g., any kind of computer program, e.g., a computer program using a virtual machine code. Any other kind of implementation of the respective functions that are described herein may also be understood as a "circuit" in accordance with an alternative embodiment.

[0090] While the disclosure has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes that come within the meaning and range of equivalency of the claims are therefore intended to be embraced.