BACKGROUND OF THE INVENTION

Field of the Invention

[0001] The present disclosure relates to chargeback or pre-processing requests and, in one particular embodiment, to a method, system, and computer program product for processing a chargeback or pre-processing request associated with at least one card-present transaction between a user and at least one merchant.

Description of Related Art

[0002] “Friendly fraud” is defined as chargeback fraud that occurs when a user (e.g., a consumer) makes a purchase from a merchant using their portable financial device (e.g., a credit card), and then requests a chargeback from the issuer after receiving the purchased goods or services. One reason“friendly fraud” occurs is that the user making the chargeback request does not recognize the merchant listed on the user’s statement. This can be because the merchant name listed on the statement is the legal (e.g., corporate) name of the merchant entity, as opposed to its tradename, which is familiar to the user, or the merchant name listed is actually the name of the payment gateway used by the merchant.

[0003] Activities associated with processing chargeback requests are often expensive to the various entities involved in the transaction processing, such as the issuer, acquirer, transaction service provider, and merchant. Therefore, it would be desirable to be able to detect and prevent“friendly fraud” and to reduce processing of chargeback requests associated therewith.

SUMMARY OF THE INVENTION

[0004] Accordingly, and generally, provided is an improved method for processing a chargeback or pre-processing request associated with at least one card-present transaction between a user and at least one merchant.

[0005] According to some non-limiting embodiments or aspects, provided is a computer-implemented method for processing a chargeback request or a pre processing request associated with at least one card-present transaction between a user and at least one merchant, including: receiving, with at least one processor, a request message associated with the at least one card-present transaction, the request message comprising at least one of a chargeback request message and a pre-processing request message and identifying the at least one card-present transaction, the at least one card-present transaction corresponding to transaction data including at least one merchant identifier associated with the at least one merchant and a transaction date; receiving, with at least one processor, user data including at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof; based at least partially on the user data, determining, with at least one processor, at least one alternate merchant identifier corresponding to the at least one merchant identifier; and generating and communicating to a computing device of the user, with at least one processor, a recommendation message including the at least one alternate merchant identifier.

[0006] In some non-limiting embodiments or aspects, the method may include: receiving from the computing device in response to the recommendation message, with at least one processor, a confirmation message associating the at least one merchant identifier with the at least one alternate merchant identifier. The method may include in response to receiving the confirmation message, updating, with at least one processor, an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier. The method may include in response to a second, subsequent request message including the at least one merchant identifier, determining, with at least one processor, the at least one alternate merchant identifier based partially on the association score of the at least one alternate merchant identifier.

[0007] In some non-limiting embodiments or aspects, the method may include receiving from the computing device in response to the recommendation message, with at least one processor, a rejection message disassociating the at least one merchant identifier with the at least one alternate merchant identifier; and in response to the rejection message, initiating, with at least one processor, a fraud response protocol. The method may include in response to receiving the rejection message, updating, with at least one processor, an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier. [0008] In some non-limiting embodiments or aspects, the geolocation data, the beacon connection data, and/or the message data may be stored on a mobile device of the user, where the mobile device is a smartphone. The determining of the at least one alternate merchant identifier may include determining a plurality of alternate merchant identifiers. The at least one merchant identifier may be a name corresponding to a payment gateway associated with the at least one alternate merchant identifier. The method may include communicating, with at least one processor, an update request to a merchant system of the at least one merchant associated with the at least one merchant identifier, the update request including instructions for the merchant system to update the at least one merchant identifier with the at least one alternate merchant identifier. The geolocation data may include a location history of a mobile device of the user on the transaction date.

[0009] In some non-limiting embodiments or aspects, the message data may include data associated with a message communicated to a computing device of the user on the transaction date. The message may include a text message or an email message. The message may include a transaction confirmation message.

[0010] In some non-limiting embodiments or aspects, determining the at least one alternate merchant identifier associated with the at least one merchant identifier may be further based at least partially on crowd-sourced data. The crowd-sourced data may include geolocation data associated with a mobile device of at least one other user at least partially matching the geolocation data associated with a mobile device of the user.

[0011] In some non-limiting embodiments or aspects, the method may further include: based at least partially on the geolocation data, determining, with at least one processor, at least one merchant located in a vicinity visited by the user on the transaction date; communicating, with at least one processor, an inquiry to a computing device associated with the at least one merchant located in the vicinity visited by the user, where the inquiry includes the at least one merchant identifier; receiving from the computing device associated with the at least one merchant located in the vicinity visited by the user, with at least one processor, an answer message, the answer message confirming that the at least one merchant located in the vicinity visited by the user is the merchant associated with the at least one merchant identifier; and based at least partially on the answer message, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0012] In some non-limiting embodiments or aspects, the method may include: receiving, with at least one processor, image data, the image data including an image taken on the transaction date by an image device located near a merchant location located in a vicinity visited by the user on the transaction date based on the geolocation data; and based at least partially on the image data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. The image data may include still photographs and/or video footage. The method may further include: scanning, with at least one processor, the image data using facial recognition software; and identifying a face of the user in the scanned image data using the facial recognition software.

[0013] In some non-limiting embodiments or aspects, the method may include: receiving, with at least one processor, image data, the image data including an image taken on the transaction date by an image device located at a residence of the user; and based at least partially on the image data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. The method may include: scanning, with at least one processor, the image data using optical character recognition (OCR) software; based on the OCR scan, identifying, with at least one processor, an object in the scanned image data associated with at least one good purchased by the user; and based at least partially on the identified object, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. The method may include: scanning, with at least one processor, the image data using optical character recognition (OCR) software; based on the OCR scan, identifying, with at least one processor, a bag in the image data; scanning, with at least one processor, the image of the identified bag using the OCR software; based on the OCR scan of the image of the identified bag, identifying, with at least one processor, a merchant logo on the bag; and based at least partially on the identified merchant logo, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0014] In some non-limiting embodiments or aspects, the method may include: determining, with at least one processor, a merchant category code (MCC) associated with the at least one card-present transaction; determining, with at least one processor, potential merchant locations located in a vicinity visited by the user on the transaction date based on the geolocation data, where the potential merchant locations correspond to the determined MCC; and based at least partially on the determined potential merchant locations, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0015] In some non-limiting embodiments or aspects, the method may include receiving, with at least one processor, digital assistant data from the transaction date and associated with a digital assistant device of the user; and based at least partially on the digital assistant data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. The digital assistant data may include data associated with a product search, a product review, a merchant review, a reminder, or an alarm associated with the digital assistant device.

[0016] In some non-limiting embodiments or aspects, the method may include receiving, with at least one processor, browser history data from the transaction date and associated with a computing device of the user; scanning, with at least one processor, the browser history data; and based at least partially on the scanned browser history data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. The browser history data may include data associated with a product search and/or a product review.

[0017] According to some non-limiting embodiments or aspects, a system for processing a chargeback request or a pre-processing request associated with at least one card-present transaction between a user and at least one merchant includes at least one processor programmed or configured to: receive a request message associated with the at least one card-present transaction, the request message comprising at least one of a chargeback request message and a pre processing request message and identifying the at least one card-present transaction, the at least one card-present transaction corresponding to transaction data including at least one merchant identifier associated with the at least one merchant and a transaction date; receive user data including at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof; based at least partially on the user data, determine at least one alternate merchant identifier corresponding to the at least one merchant identifier; and generate and communicate to a computing device of the user a recommendation message including the at least one alternate merchant identifier.

[0018] According to some non-limiting embodiments or aspects, a computer program product for processing a chargeback request or a pre-processing request associated with at least one card-present transaction between a user and at least one merchant includes at least one non-transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive a request message associated with the at least one card-present transaction, the request message comprising at least one of a chargeback request message and a pre-processing request message and identifying the at least one card-present transaction, the at least one card-present transaction corresponding to transaction data including at least one merchant identifier associated with the at least one merchant and a transaction date; receive user data including at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof; based at least partially on the user data, determine at least one alternate merchant identifier corresponding to the at least one merchant identifier; and generate and communicate to a computing device of the user a recommendation message including the at least one alternate merchant identifier.

[0019] Further embodiments or aspects are set forth in the following numbered clauses:

[0020] Clause 1 : A computer-implemented method for processing a chargeback request or a pre-processing request associated with at least one card-present transaction between a user and at least one merchant, comprising: receiving, with at least one processor, a request message associated with the at least one card- present transaction, the request message comprising at least one of a chargeback request message and a pre-processing request message and identifying the at least one card-present transaction, the at least one card-present transaction corresponding to transaction data comprising at least one merchant identifier associated with the at least one merchant and a transaction date; receiving, with at least one processor, user data comprising at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof; based at least partially on the user data, determining, with at least one processor, at least one alternate merchant identifier corresponding to the at least one merchant identifier; and generating and communicating to a computing device of the user, with at least one processor, a recommendation message comprising the at least one alternate merchant identifier.

[0021] Clause 2: The method of clause 1 , further comprising: receiving from the computing device in response to the recommendation message, with at least one processor, a confirmation message associating the at least one merchant identifier with the at least one alternate merchant identifier.

[0022] Clause 3: The method of clause 1 or 2, further comprising: in response to receiving the confirmation message, updating, with at least one processor, an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier.

[0023] Clause 4: The method of any of clauses 1 -3, further comprising: in response to a subsequent request message comprising the at least one merchant identifier, determining, with at least one processor, the at least one alternate merchant identifier based partially on the association score of the at least one alternate merchant identifier.

[0024] Clause 5: The method of any of clauses 1 -4, further comprising: receiving from the computing device in response to the recommendation message, with at least one processor, a rejection message disassociating the at least one merchant identifier with the at least one alternate merchant identifier; and in response to the rejection message, initiating, with at least one processor, a fraud response protocol.

[0025] Clause 6: The method of any of clauses 1 -5, further comprising: in response to receiving the rejection message, updating, with at least one processor, an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier.

[0026] Clause 7: The method of any of clauses 1 -6, wherein the geolocation data, the beacon connection data, and/or the message data are stored on a mobile device of the user. [0027] Clause 8: The method of any of clauses 1 -7, wherein the determining of the at least one alternate merchant identifier comprises determining a plurality of alternate merchant identifiers.

[0028] Clause 9: The method of any of clauses 1 -8, wherein the at least one merchant identifier comprises an identifier corresponding to a payment gateway associated with the at least one alternate merchant identifier.

[0029] Clause 10: The method of any of clauses 1 -9, further comprising: communicating, with at least one processor, an update request to a merchant system of the at least one merchant associated with the at least one merchant identifier, the update request including instructions for the merchant system to update the at least one merchant identifier with the at least one alternate merchant identifier.

[0030] Clause 1 1 : The method of any of clauses 1 -10, wherein the geolocation data comprises a location history of a mobile device of the user on the transaction date.

[0031] Clause 12: The method of any of clauses 1 -1 1 , wherein the message data comprises data associated with a message communicated to a computing device of the user on the transaction date.

[0032] Clause 13: The method of any of clauses 1 -12, wherein the message comprises a text message or an email message.

[0033] Clause 14: The method of any of clauses 1 -13, wherein the message is a transaction confirmation message.

[0034] Clause 15: The method of any of clauses 1 -14, wherein determining the at least one alternate merchant identifier associated with the at least one merchant identifier is further based at least partially on crowd-sourced data.

[0035] Clause 16: The method of any of clauses 1 -15, wherein the crowd-sourced data comprises geolocation data associated with a mobile device of at least one other user at least partially matching the geolocation data associated with a mobile device of the user.

[0036] Clause 17: The method of any of clauses 1 -16, further comprising: based at least partially on the geolocation data, determining, with at least one processor, at least one merchant located in a vicinity visited by the user on the transaction date; communicating, with at least one processor, an inquiry to a computing device associated with the at least one merchant located in the vicinity visited by the user, wherein the inquiry comprises the at least one merchant identifier; receiving from the computing device associated with the at least one merchant located in the vicinity visited by the user, with at least one processor, an answer message, the answer message confirming that the at least one merchant located in the vicinity visited by the user is the merchant associated with the at least one merchant identifier; and based at least partially on the answer message, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0037] Clause 18: The method of any of clauses 1 -17, further comprising: receiving, with at least one processor, image data, the image data comprising an image taken on the transaction date by an image device located near a merchant location located in a vicinity visited by the user on the transaction date based on the geolocation data; and based at least partially on the image data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0038] Clause 19: The method of any of clauses 1 -18, wherein the image data comprise still photographs and/or video footage.

[0039] Clause 20: The method of any of clauses 1 -19, further comprising: scanning, with at least one processor, the image data using facial recognition software; and identifying a face of the user in the scanned image data using the facial recognition software.

[0040] Clause 21 : The method of any of clauses 1 -20, further comprising: receiving, with at least one processor, image data, the image data comprising an image taken on the transaction date by an image device located at a residence of the user; and based at least partially on the image data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0041] Clause 22: The method of any of clauses 1 -21 , further comprising: scanning, with at least one processor, the image data using optical character recognition (OCR) software; based on the OCR scan, identifying, with at least one processor, an object in the scanned image data associated with at least one good purchased by the user; and based at least partially on the identified object, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. [0042] Clause 23: The method of any of clauses 1 -22, further comprising: scanning, with at least one processor, the image data using optical character recognition (OCR) software; based on the OCR scan, identifying, with at least one processor, a bag in the image data; scanning, with at least one processor, the image of the identified bag using the OCR software; based on the OCR scan of the image of the identified bag, identifying, with at least one processor, a merchant logo on the bag; and based at least partially on the identified merchant logo, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0043] Clause 24: The method of any of clauses 1 -23, further comprising: determining, with at least one processor, a merchant category code (MCC) associated with the at least one card-present transaction; determining, with at least one processor, potential merchant locations located in a vicinity visited by the user on the transaction date based on the geolocation data, wherein the potential merchant locations correspond to the determined MCC; and based at least partially on the determined potential merchant locations, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0044] Clause 25: The method of any of clauses 1 -24, further comprising: receiving, with at least one processor, digital assistant data from the transaction date and associated with a digital assistant device of the user; and based at least partially on the digital assistant data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0045] Clause 26: The method of any of clauses 1 -25, wherein the digital assistant data comprises data associated with a product search, a product review, a merchant review, a reminder, or an alarm associated with the digital assistant device.

[0046] Clause 27: The method of any of clauses 1 -26, further comprising: receiving, with at least one processor, browser history data from the transaction date and associated with a computing device of the user; scan, with at least one processor, the browser history data; and based at least partially on the scanned browser history data, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. [0047] Clause 28: The method of any of clauses 1 -27, wherein the browser history data comprises data associated with a product search and/or a product review.

[0048] Clause 29: A system for processing a chargeback request or a pre processing request associated with at least one card-present transaction between a user and at least one merchant, comprising at least one processor programmed or configured to: receive a request message associated with the at least one card- present transaction, the request message comprising at least one of a chargeback request message and a pre-processing request message and identifying the at least one card-present transaction, the at least one card-present transaction corresponding to transaction data comprising at least one merchant identifier associated with the at least one merchant and a transaction date; receive user data comprising at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof; based at least partially on the user data, determine at least one alternate merchant identifier corresponding to the at least one merchant identifier; and generate and communicate to a computing device of the user a recommendation message comprising the at least one alternate merchant identifier.

[0049] Clause 30: The system of clause 29, wherein the at least one processor is further programmed or configured to: receive from the computing device in response to the recommendation message a confirmation message associating the at least one merchant identifier with the at least one alternate merchant identifier.

[0050] Clause 31 : The system of clause 29 or 30, wherein the at least one processor is further programmed or configured to: in response to receiving the confirmation message, update an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier.

[0051] Clause 32: The system of any of clauses 29-31 , wherein the at least one processor is further programmed or configured to: in response to a second, subsequent request message comprising the at least one merchant identifier, determine the at least one alternate merchant identifier based partially on the association score of the at least one alternate merchant identifier.

[0052] Clause 33: The system of any of clauses 29-32, wherein the at least one processor is further programmed or configured to: receive from the computing device in response to the recommendation message a rejection message disassociating the at least one merchant identifier with the at least one alternate merchant identifier; and in response to the rejection message, initiate a fraud response protocol.

[0053] Clause 34: The system of any of clauses 29-33, wherein the at least one processor is further programmed or configured to: in response to receiving the rejection message, update an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier.

[0054] Clause 35: The system of any of clauses 29-34, wherein the geolocation data, the beacon connection data, and/or the message data are stored on a mobile device of the user, wherein the mobile device is a smartphone.

[0055] Clause 36: The system of any of clauses 29-35, wherein the determining of the at least one alternate merchant identifier comprises determining a plurality of alternate merchant identifiers.

[0056] Clause 37: The system of any of clauses 29-36, wherein the at least one merchant identifier is a name corresponding to a payment gateway associated with the at least one alternate merchant identifier.

[0057] Clause 38: The system of any of clauses 29-37, wherein the at least one processor is further programmed or configured to: communicate an update request to a merchant system of the at least one merchant associated with the at least one merchant identifier, the update request including instructions for the merchant system to update the at least one merchant identifier with the at least one alternate merchant identifier.

[0058] Clause 39: The system of any of clauses 29-38, wherein the geolocation data comprises a location history of a mobile device of the user on the transaction date.

[0059] Clause 40: The system of any of clauses 29-39, wherein the message data comprises data associated with a message communicated to a computing device of the user on the transaction date.

[0060] Clause 41 : The system of any of clauses 29-40, wherein the message comprises a text message or an email message.

[0061] Clause 42: The system of any of clauses 29-41 , wherein the message is a transaction confirmation message. [0062] Clause 43: The system of any of clauses 29-42, wherein determining the at least one alternate merchant identifier associated with the at least one merchant identifier is further based at least partially on crowd-sourced data.

[0063] Clause 44: The system of any of clauses 29-43, wherein the crowd- sourced data comprises geolocation data associated with a mobile device of at least one other user at least partially matching the geolocation data associated with a mobile device of the user.

[0064] Clause 45: The system of any of clauses 29-44, wherein the at least one processor is further programmed or configured to: based at least partially on the geolocation data, determine at least one merchant located in a vicinity visited by the user on the transaction date; communicate an inquiry to a computing device associated with the at least one merchant located in the vicinity visited by the user, wherein the inquiry comprises the at least one merchant identifier; receive from the computing device associated with the at least one merchant located in the vicinity visited by the user an answer message, the answer message confirming that the at least one merchant located in the vicinity visited by the user is the merchant associated with the at least one merchant identifier; and based at least partially on the answer message, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0065] Clause 46: The system of any of clauses 29-45, wherein the at least one processor is further programmed or configured to: receive image data, the image data comprising an image taken on the transaction date by an image device located near a merchant location located in a vicinity visited by the user on the transaction date based on the geolocation data; and based at least partially on the image data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0066] Clause 47: The system of any of clauses 29-46, wherein the image data comprise still photographs and/or video footage.

[0067] Clause 48: The system of any of clauses 29-47, wherein the at least one processor is further programmed or configured to: scan the image data using facial recognition software; and identify a face of the user in the scanned image data using the facial recognition software.

[0068] Clause 49: The system of any of clauses 29-48, wherein the at least one processor is further programmed or configured to: receive image data, the image data comprising an image taken on the transaction date by an image device located at a residence of the user; and based at least partially on the image data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0069] Clause 50: The system of any of clauses 29-49, wherein the at least one processor is further programmed or configured to: scan the image data using optical character recognition (OCR) software; based on the OCR scan, identify an object in the scanned image data associated with at least one good purchased by the user; and based at least partially on the identified object, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0070] Clause 51 : The system of any of clauses 29-50, wherein the at least one processor is further programmed or configured to: scan the image data using optical character recognition (OCR) software; based on the OCR scan, identify a bag in the image data; scan the image of the identified bag using the OCR software; based on the OCR scan of the image of the identified bag, identify a merchant logo on the bag; and based at least partially on the identified merchant logo, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0071] Clause 52: The system of any of clauses 29-51 , wherein the at least one processor is further programmed or configured to: determine a merchant category code (MCC) associated with the at least one card-present transaction; determine potential merchant locations located in a vicinity visited by the user on the transaction date based on the geolocation data, wherein the potential merchant locations correspond to the determined MCC; and based at least partially on the determined potential merchant locations, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0072] Clause 53: The system of any of clauses 29-52, wherein the at least one processor is further programmed or configured to: receive digital assistant data from the transaction date and associated with a digital assistant device of the user; and based at least partially on the digital assistant data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0073] Clause 54: The system of any of clauses 29-53, wherein the digital assistant data comprises data associated with a product search, a product review, a merchant review, a reminder, or an alarm associated with the digital assistant device. [0074] Clause 55: The system of any of clauses 29-54, wherein the at least one processor is further programmed or configured to: receive browser history data from the transaction date and associated with a computing device of the user; scan the browser history data; and based at least partially on the scanned browser history data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0075] Clause 56: The system of any of clauses 29-55, wherein the browser history data comprises data associated with a product search and/or a product review.

[0076] Clause 57: A computer program product for processing a chargeback request or a pre-processing request associated with at least one card-present transaction between a user and at least one merchant, the computer program product comprising at least one non-transitory computer-readable medium including one or more instructions that, when executed by at least one processor, cause the at least one processor to: receive a request message associated with the at least one card-present transaction, the request message comprising at least one of a chargeback request message and a pre-processing request message and identifying the at least one card-present transaction, the at least one card-present transaction corresponding to transaction data comprising at least one merchant identifier associated with the at least one merchant and a transaction date; receive user data comprising at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof; based at least partially on the user data, determine at least one alternate merchant identifier corresponding to the at least one merchant identifier; and generate and communicate to a computing device of the user a recommendation message comprising the at least one alternate merchant identifier.

[0077] Clause 58: The computer program product of clause 57, wherein the at least one processor is further programmed or configured to: receive from the computing device in response to the recommendation message a confirmation message associating the at least one merchant identifier with the at least one alternate merchant identifier.

[0078] Clause 59: The computer program product of clause 57 or 58, wherein the at least one processor is further programmed or configured to: in response to receiving the confirmation message, update an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier.

[0079] Clause 60: The computer program product of any of clauses 57-59, wherein the at least one processor is further programmed or configured to: in response to a second, subsequent request message comprising the at least one merchant identifier, determine the at least one alternate merchant identifier based partially on the association score of the at least one alternate merchant identifier.

[0080] Clause 61 : The computer program product of any of clauses 57-60, wherein the at least one processor is further programmed or configured to: receive from the computing device in response to the recommendation message a rejection message disassociating the at least one merchant identifier with the at least one alternate merchant identifier; and in response to the rejection message, initiate a fraud response protocol.

[0081] Clause 62: The computer program product of any of clauses 57-61 , wherein the at least one processor is further programmed or configured to: in response to receiving the rejection message, update an association score of the at least one alternate merchant identifier, the association score indicating the likelihood that the at least one alternate merchant identifier is associated with a merchant identifier.

[0082] Clause 63: The computer program product of any of clauses 57-62, wherein the geolocation data, the beacon connection data, and/or the message data are stored on a mobile device of the user, wherein the mobile device is a smartphone.

[0083] Clause 64: The computer program product of any of clauses 57-63, wherein the determining of the at least one alternate merchant identifier comprises determining a plurality of alternate merchant identifiers.

[0084] Clause 65: The computer program product of any of clauses 57-64, wherein the at least one merchant identifier is a name corresponding to a payment gateway associated with the at least one alternate merchant identifier.

[0085] Clause 66: The computer program product of any of clauses 57-65, wherein the at least one processor is further programmed or configured to: communicate an update request to a merchant system of the at least one merchant associated with the at least one merchant identifier, the update request including instructions for the merchant system to update the at least one merchant identifier with the at least one alternate merchant identifier.

[0086] Clause 67: The computer program product of any of clauses 57-66, wherein the geolocation data comprises a location history of a mobile device of the user on the transaction date.

[0087] Clause 68: The computer program product of any of clauses 57-67, wherein the message data comprises data associated with a message communicated to a computing device of the user on the transaction date.

[0088] Clause 69: The computer program product of any of clauses 57-68, wherein the message comprises a text message or an email message.

[0089] Clause 70: The computer program product of any of clauses 57-69, wherein the message is a transaction confirmation message.

[0090] Clause 71 : The computer program product of any of clauses 57-70, wherein determining the at least one alternate merchant identifier associated with the at least one merchant identifier is further based at least partially on crowd-sourced data.

[0091] Clause 72: The computer program product of any of clauses 57-71 , wherein the crowd-sourced data comprises geolocation data associated with a mobile device of at least one other user at least partially matching the geolocation data associated with a mobile device of the user.

[0092] Clause 73: The computer program product of any of clauses 57-72, wherein the at least one processor is further programmed or configured to: based at least partially on the geolocation data, determine at least one merchant located in a vicinity visited by the user on the transaction date; communicate an inquiry to a computing device associated with the at least one merchant located in the vicinity visited by the user, wherein the inquiry comprises the at least one merchant identifier; receive from the computing device associated with the at least one merchant located in the vicinity visited by the user an answer message, the answer message confirming that the at least one merchant located in the vicinity visited by the user is the merchant associated with the at least one merchant identifier; and based at least partially on the answer message, determining, with at least one processor, the at least one alternate merchant identifier associated with the at least one merchant identifier. [0093] Clause 74: The computer program product of any of clauses 57-73, wherein the at least one processor is further programmed or configured to: receive image data, the image data comprising an image taken on the transaction date by an image device located near a merchant location located in a vicinity visited by the user on the transaction date based on the geolocation data; and based at least partially on the image data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0094] Clause 75: The computer program product of any of clauses 57-74, wherein the image data comprise still photographs and/or video footage.

[0095] Clause 76: The computer program product of any of clauses 57-75, wherein the at least one processor is further programmed or configured to: scan the image data using facial recognition software; and identify a face of the user in the scanned image data using the facial recognition software.

[0096] Clause 77: The computer program product of any of clauses 57-76, wherein the at least one processor is further programmed or configured to: receive image data, the image data comprising an image taken on the transaction date by an image device located at a residence of the user; and based at least partially on the image data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0097] Clause 78: The computer program product of any of clauses 57-77, wherein the at least one processor is further programmed or configured to: scan the image data using optical character recognition (OCR) software; based on the OCR scan, identify an object in the scanned image data associated with at least one good purchased by the user; and based at least partially on the identified object, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[0098] Clause 79: The computer program product of any of clauses 57-78, wherein the at least one processor is further programmed or configured to: scan the image data using optical character recognition (OCR) software; based on the OCR scan, identify a bag in the image data; scan the image of the identified bag using the OCR software; based on the OCR scan of the image of the identified bag, identify a merchant logo on the bag; and based at least partially on the identified merchant logo, determine the at least one alternate merchant identifier associated with the at least one merchant identifier. [0099] Clause 80: The computer program product of any of clauses 57-79, wherein the at least one processor is further programmed or configured to: determine a merchant category code (MCC) associated with the at least one card- present transaction; determine potential merchant locations located in a vicinity visited by the user on the transaction date based on the geolocation data, wherein the potential merchant locations correspond to the determined MCC; and based at least partially on the determined potential merchant locations, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[00100] Clause 81 : The computer program product of any of clauses 57-80, wherein the at least one processor is further programmed or configured to: receive digital assistant data from the transaction date and associated with a digital assistant device of the user; and based at least partially on the digital assistant data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[00101] Clause 82: The computer program product of any of clauses 57-81 , wherein the digital assistant data comprises data associated with a product search, a product review, a merchant review, a reminder, or an alarm associated with the digital assistant device.

[00102] Clause 83: The computer program product of any of clauses 57-82, wherein the at least one processor is further programmed or configured to: receive browser history data from the transaction date and associated with a computing device of the user; scan the browser history data; and based at least partially on the scanned browser history data, determine the at least one alternate merchant identifier associated with the at least one merchant identifier.

[00103] Clause 84: The computer program product of any of clauses 57-83, wherein the browser history data comprises data associated with a product search and/or a product review.

[00104] These and other features and characteristics of the present invention, as well as the methods of operation and functions of the related elements of structures and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention. As used in the specification and the claims, the singular form of “a,”“an,” and“the” include plural referents unless the context clearly dictates otherwise.

BRIEF DESCRIPTION OF THE DRAWINGS

[00105] Additional advantages and details of non-limiting embodiments are explained in greater detail below with reference to the accompanying figures, in which:

[00106] FIG. 1 shows a schematic view of a system for processing a chargeback or pre-processing request according to a non-limiting embodiment or aspect;

[00107] FIG. 2 shows a user statement including at least one unfamiliar merchant name according to a non-limiting embodiment or aspect;

[00108] FIG. 3 shows a graphical user interface displayed in a system for processing a chargeback or pre-processing request according to a non-limiting embodiment or aspect;

[00109] FIG. 4 shows another graphical user interface displayed in a system for processing a chargeback or pre-processing request according to a non-limiting embodiment or aspect;

[00110] FIG. 5 shows database entries of a database including data associated with payment gateways according to a non-limiting embodiment or aspect;

[00111] FIG. 6 shows a database entry associating a business entity with a payment gateway according to a non-limiting embodiment or aspect;

[00112] FIG. 7 shows a user Internet browsing history according to a non-limiting embodiment or aspect;

[00113] FIG. 8 shows a schematic of a map generated based on geolocation data according to a non-limiting embodiment or aspect;

[00114] FIG. 9 shows a schematic of an email message as message data according to a non-limiting embodiment or aspect;

[00115] FIG. 10 shows a schematic view of a system in which a recommendation system uses crowd-sourced data to determine a potential familiar merchant name according to a non-limiting embodiment or aspect; [00116] FIG. 1 1 shows a schematic view of a system in which a recommendation system communicates with a merchant system to determine a potential familiar merchant name according to a non-limiting embodiment or aspect;

[00117] FIG. 12 shows a schematic view of a system in which a recommendation system uses image data to determine a potential familiar merchant name according to a non-limiting embodiment or aspect;

[00118] FIG. 13A shows a schematic view of a system in which a recommendation system uses digital assistant data to determine a potential familiar merchant name according to a non-limiting embodiment or aspect;

[00119] FIG. 13B shows digital assistant device messages according to a non limiting embodiment or aspect;

[00120] FIG. 14 shows a schematic view of a system for updating an unfamiliar merchant name with a familiar merchant name according to a non-limiting embodiment or aspect; and

[00121] FIG. 15 shows a step diagram of a method for processing a chargeback or pre-processing request according to a non-limiting embodiment or aspect.

DESCRIPTION OF THE INVENTION

[00122] For purposes of the description hereinafter, the terms “end,” “upper,” “lower,”“right,”“left,”“vertical,”“horizon tal,”“top,”“bottom,”“lateral,”“longitudinal, ” and derivatives thereof shall relate to the invention as it is oriented in the drawing figures. However, it is to be understood that the invention may assume various alternative variations and step sequences, except where expressly specified to the contrary. It is also to be understood that the specific devices and processes illustrated in the attached drawings, and described in the following specification, are simply exemplary embodiments or aspects of the invention. Hence, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein are not to be considered as limiting.

[00123] As used herein, the terms“communication” and“communicate” may refer to the reception, receipt, transmission, transfer, provision, and/or the like, of information (e.g., data, signals, messages, instructions, commands, and/or the like). For one unit (e.g., a device, a system, a component of a device or system, combinations thereof, and/or the like) to be in communication with another unit means that the one unit is able to directly or indirectly receive information from and/or transmit information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, and/or the like) that is wired and/or wireless in nature. Additionally, two units may be in communication with each other even though the information transmitted may be modified, processed, relayed, and/or routed between the first and second unit. For example, a first unit may be in communication with a second unit even though the first unit passively receives information and does not actively transmit information to the second unit. As another example, a first unit may be in communication with a second unit if at least one intermediary unit (e.g., a third unit located between the first unit and the second unit) processes information received from the first unit and communicates the processed information to the second unit. In some non-limiting embodiments or aspects, a message may refer to a network packet (e.g., a data packet, and/or the like) that includes data. It will be appreciated that numerous other arrangements are possible.

[00124] As used herein, the term“transaction service provider” may refer to an entity that receives transaction authorization requests from merchants or other entities and provides guarantees of payment, in some cases through an agreement between the transaction service provider and an issuer institution. For example, a transaction service provider may include a payment network such as Visa® or any other entity that processes transactions. The term“transaction processing system” may refer to one or more computer systems operated by or on behalf of a transaction service provider, such as a transaction processing server executing one or more software applications. A transaction processing system may include one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of a transaction service provider.

[00125] As used herein, the term“issuer institution” or“issuer” may refer to one or more entities, such as a bank, that provide accounts to customers for conducting transactions {e.g., payment transactions), such as initiating credit and/or debit payments. For example, an issuer institution may provide an account identifier, such as a personal account number (PAN), to a customer that uniquely identifies one or more accounts associated with that customer. The account identifier may be embodied on a portable financial device, such as a physical financial instrument, e.g., a payment card, and/or may be electronic and used for electronic payments. The term“issuer system” refers to one or more computer systems operated by or on behalf of an issuer institution, such as a server computer executing one or more software applications. For example, an issuer system may include one or more authorization servers for authorizing a transaction.

[00126] As used herein, the term“acquirer institution” or“acquirer” may refer to an entity licensed and/or approved by the transaction service provider to originate transactions (e.g., payment transactions) using a portable financial device associated with the transaction service provider. The transactions the acquirer institution may originate may include payment transactions (e.g., purchases, original credit transactions (OCTs), account funding transactions (AFTs), and/or the like). In some non-limiting embodiments or aspects, an acquirer institution may be a financial institution, such as a bank. As used herein, the term“acquirer system” may refer to one or more computer systems, computer devices, software applications, and/or the like operated by or on behalf of an acquirer institution.

[00127] As used herein, the term“account identifier” may include one or more PANs, tokens, or other identifiers associated with a customer account. The term “token” may refer to an identifier that is used as a substitute or replacement identifier for an original account identifier, such as a PAN. Account identifiers may be alphanumeric or any combination of characters and/or symbols. Tokens may be associated with a PAN or other original account identifier in one or more data structures (e.g., one or more databases, and/or the like) such that they may be used to conduct a transaction without directly using the original account identifier. In some examples, an original account identifier, such as a PAN, may be associated with a plurality of tokens for different individuals or purposes.

[00128] As used herein, the term“merchant” may refer to an individual or entity that provides goods and/or services, or access to goods and/or services, to customers based on a transaction, such as a payment transaction. The term “merchant” or“merchant system” may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer executing one or more software applications. A“point-of-sale (POS) system,” as used herein, may refer to one or more computers and/or peripheral devices used by a merchant to engage in payment transactions with customers, including one or more card readers, near-field communication (NFC) receivers, RFID receivers, and/or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, and/or other like devices that can be used to initiate a payment transaction.

[00129] The term“user device,” as used herein, refers to any electronic device that is configured to communicate with one or more remote devices or systems, such as a server. A user device may include a desktop computer, laptop computer, mobile computer (e.g., smartphone), a wearable computer (e.g., a watch, pair of glasses, lens, clothing, and/or the like), a cellular phone, a network-enabled appliance (e.g., a network-enabled television, refrigerator, thermostat, and/or the like), a point of sale (POS) system, and/or any other device, system, and/or software application configured to communicate with a remote device or system.

[00130] As used herein, the term “portable financial device” may refer to a payment card (e.g., a credit or debit card), a gift card, a smartcard, smart media, a payroll card, a healthcare card, a wrist band, a machine-readable medium containing account information, a keychain device or fob, an RFID transponder, a retailer discount or loyalty card, a cellular phone, an electronic wallet mobile application, a personal digital assistant (PDA), a pager, a security card, a computer, an access card, a wireless terminal, a transponder, and/or the like. In some non-limiting embodiments or aspects, the portable financial device may include volatile or non volatile memory to store information (e.g., an account identifier, a name of the account holder, and/or the like).

[00131] As used herein, the term“payment gateway” may refer to an entity and/or a payment processing system operated by or on behalf of such an entity (e.g., a merchant service provider, a payment service provider, a payment facilitator, a payment facilitator that contracts with an acquirer, a payment aggregator, and/or the like), which provides payment services (e.g., transaction service provider payment services, payment processing services, and/or the like) to one or more merchants. The payment services may be associated with the use of portable financial devices managed by a transaction service provider. As used herein, the term“payment gateway system” may refer to one or more computer systems, computer devices, servers, groups of servers, and/or the like, operated by or on behalf of a payment gateway.

[00132] As used herein, the term “card-present transaction” may refer to a payment transaction initiated with a portable financial device in which the cardholder physically presents the portable financial device at the time the payment transaction is initiated with the portable financial device. A non-limiting example of a card- present transaction is a payment transaction initiated at a brick-and-mortar retail store with a physical POS system, during which the cardholder physically presents the portable financial device to the merchant.

[00133] As used herein, the term “card-not-present transaction” or “CNP transaction” may refer to a payment transaction initiated with a portable financial device in which the cardholder does not or cannot physically present the portable financial device at the time the payment transaction is initiated with the portable financial device. Non-limiting examples of CNP transactions include transactions initiated by mail or facsimile or a payment transaction initiated over the telephone or the internet.

[00134] As used herein, the term“server” may refer to or include one or more processors or computers, storage devices, or similar computer arrangements that are operated by or facilitate communication and processing for multiple parties in a network environment, such as the internet, although it will be appreciated that communication may be facilitated over one or more public or private network environments and that various other arrangements are possible. Further, multiple computers, e.g., servers, or other computerized devices, e.g., point-of-sale devices, directly or indirectly communicating in the network environment may constitute a "system," such as a merchant's point-of-sale system. Reference to“a server” or“a processor,” as used herein, may refer to a previously-recited server and/or processor that is recited as performing a previous step or function, a different server and/or processor, and/or a combination of servers and/or processors. For example, as used in the specification and the claims, a first server and/or a first processor that is recited as performing a first step or function may refer to the same or different server and/or a processor recited as performing a second step or function.

[00135] Non-limiting embodiments or aspects of the present invention are directed to a method and system for processing a chargeback or pre-processing request associated with at least one card-present transaction between a user and at least one merchant. Some non-limiting embodiments or aspects allow for entities involved in processing payment transactions and chargeback requests (e.g., issuers, transaction service providers, acquirers, and merchants) to identify and prevent processing of chargeback requests associated with“friendly fraud”. For example, in non-limiting embodiments, processing a chargeback request with user data obtained from a user device allows for improved detection of such “friendly fraud.” Non limiting embodiments or aspects allow for chargeback requests to be entirely pre empted by identifying the potential familiar merchant name via a pre-processing request message, before a chargeback request is ever generated. Non-limiting embodiments or aspects allow for a recommendation to be generated that suggests at least one potential familiar merchant name associated with the unfamiliar merchant name listed on the user’s statement, the unfamiliar merchant name being associated with the chargeback request from the user. Non-limiting embodiment or aspects allow the recommendation to be generated based on user data including, geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof. Non-limiting embodiments or aspects provide for the user to either confirm or reject whether the suggested potential familiar merchant name is the merchant name associated with the unfamiliar merchant name listed on the user’s statement, which allows chargeback requests associated with “friendly fraud” to be identified before processing. Non-limiting embodiments or aspects allow for crowd-sourced data to be utilized to determine the potential familiar merchant name so that previous chargeback messages identifying the same unfamiliar merchant name may be considered when determining the potential familiar merchant name, enhancing efficiency and accuracy of the determination of the potential familiar merchant name. Non-limiting embodiments or aspects also allow for a merchant system to be notified of an unfamiliar merchant name, such that the merchant can update its unfamiliar merchant name with the familiar merchant name. This feature allows future chargeback requests associated with“friendly fraud” to be avoided altogether.

[00136] Referring to FIG. 1 , a system 100 for processing a chargeback or pre processing request according to some non-limiting embodiments or aspects of the present invention is shown. As used herein, a“chargeback” is a return of funds associated with a payment transaction initiated using a portable financial device to a user (e.g., a consumer). In certain examples, the chargeback returns funds to the user’s bank account from the merchant’s bank account. A chargeback may be initiated by a user submitting a chargeback request. The chargeback request may be submitted to an issuer of the portable financial device and/or the financial service provider associated with the portable financial device and identify the specific transaction(s) for which the chargeback is requested. The chargeback request may be submitted for any number of reasons, including a user claim that the transaction is a fraudulent transaction (a transaction that the user did not initiate). Chargeback requests undergo thorough processing, and the merchant may have a chance to dispute the chargeback request by showing that the user did indeed make the purchase (i.e., that the purchase was not a fraudulent purchase). Pre-processing requests may be submitted by a user before a chargeback request is ever submitted and may include an inquiry regarding at least one merchant identifier associated with at least one merchant. In this way, pre-processing requests may allow for a user to identify an unfamiliar merchant identifier before a chargeback request is submitted to pre-empt the entire chargeback request processing. The system 100 shown in FIG. 1 allows for chargeback or pre-processing requests (hereinafter both referred to as “request messages”) associated with“friendly fraud” to be detected and prevented, significantly enhancing the overall efficiency and accuracy associated with processing payment transactions and request messages.

[00137] In some non-limiting embodiments, the request message may be associated with a card-present transaction between a user and at least one merchant.

[00138] With continued reference to FIG. 1 , the system 100 may include a user device 10 associated with a user who initiated the card-present payment transaction with a merchant. The user device 10 may be in communication with a recommendation system 12 operated by or on behalf of the issuer, transaction service provider, acquirer, and/or merchant. The recommendation system 12 may reside on an issuer system or may be a browser extension installed on the user device 10. The recommendation system 12 may be in communication with a recommendation database 14, which may store data associated with unfamiliar merchant names and familiar (e.g., alternate) merchant names (as hereinafter described). The recommendation database 14 may store data associated with payment gateways and merchants associated with the payment gateways (as hereinafter described). The recommendation database 14 may store various association scores (as hereinafter described).

[00139] Referring to FIG. 2, a user statement 16 (e.g., a credit card statement) listing transactions initiated by a user over a time period associated with a portable financial device of the user is shown. The user statement 16 may include any relevant information associated with transactions initiated by the user using the portable financial device. The user statement 16 may, for example, include the date on which the transaction was initiated, a merchant identifier (e.g., such as a merchant name), and the amount of the transaction.

[00140] With continued reference to FIG. 2, the merchant name listed on the user statement 16 may be an unfamiliar merchant name. As used herein, an“unfamiliar merchant name” is a merchant identifier (e.g., a name) associated with the merchant that is different from a tradename of the merchant associated by the user with a particular transaction listed in the user statement such that the user does not associate the unfamiliar merchant name with the particular transaction. Non-limiting examples of unfamiliar merchant names may include legal names of a business entity different from the tradename of the merchant, the name of a payment gateway associated with the merchant different from the tradename of the merchant, the name of an entity known to the user but not associated by the user with the transaction, or any other merchant identifier the user does not associate with the transaction listed in the user’s statement. For example, a user may purchase a wristwatch from Brand X of Company X, and the merchant name shown on the user statement may be Company Y (the unfamiliar merchant name), where Company Y is a parent company of Company X, a fact that is not known to the user. Even though the user is aware of Company X and Company Y, Company Y may be considered an “unfamiliar merchant name” because its presence on the user statement causes the user to not recognize the transaction (because the user does not associate Company Y with the listed transaction and expected Company X to be the merchant listed on the user’s statement). Thus, “unfamiliar merchant name” does not necessarily refer to the user not recognizing the merchant name listed but refers to the user not associating the listed transaction with the listed merchant on the user statement. As used herein, a“familiar merchant name” is a merchant name that is similar to, identical to, inclusive of at least a portion of, or an abbreviation of a tradename of the merchant associated by the user with a particular transaction listed in the user statement such that the user does associate the familiar merchant name with the particular transaction. The familiar merchant name may be an alternate merchant name from the unfamiliar merchant name, and the terms “familiar merchant name” and “alternate merchant name” may be used interchangeably herein. [00141] One non-limiting embodiment of an unfamiliar merchant name 18 shown in FIG. 2 may be a legal identifier (name) of the merchant that is not similar enough to the tradename of the merchant and is therefore not recognizable by the user. Another non-limiting embodiment of an unfamiliar merchant name 20 shown in FIG. 2 may be an identifier (a name) of a payment gateway associated with the merchant (e.g., the user statement 16 lists the payment gateway name instead of the merchant name).

[00142] Referring to FIGS. 1 and 2, the user device 10 may communicate a request message to initiate a chargeback request or pre-processing request, the request message identifying a payment transaction (e.g., a card-present transaction) between the user and a merchant to the recommendation system 12. The request message may request a chargeback associated with the transaction. The request message may include an unfamiliar merchant name associated with the merchant of the transaction (e.g., the name the user does not recognize on the user statement 16).

[00143] With continued reference to FIGS. 1 and 2, the recommendation system 12 may determine a potential familiar merchant name associated with the submitted unfamiliar merchant name in the request message. The recommendation system 12 may determine a potential familiar merchant name for the unfamiliar merchant name by communicating with the recommendation database 14 (and other devices and database as described herein). The recommendation database 14 may include data that associates potential familiar merchant names with unfamiliar merchant names. The recommendation system 12 may determine a potential familiar merchant name based on a match in the recommendation database 14 between the unfamiliar merchant name in the request message and a potential familiar merchant name. This data may include crowd-sourced data that associates potential familiar merchant names with unfamiliar merchant names based on potential familiar merchant name-unfamiliar merchant name associations previous users have identified as correct. The recommendation database 14 may include data regarding payment gateways because unfamiliar merchant names are commonly payment gateways associated with the merchant. The data regarding the payment gateway may include the payment gateway identifier (e.g., a name) and a URL associated with the gateway. The recommendation database 14 may include any other suitable information for determining a potential familiar merchant name associated with an unfamiliar merchant name on the user statement 16.

[00144] The recommendation system 12 may communicate with any other data resource to determine a potential familiar merchant name. For example, the recommendation system 12 may communicate with a website, a remote database (remote from the recommendation system 12), a crowd-sourced database containing crowd-sourced data as previously described, a database local to the user device 10, and/or a database associated with the user. The recommendation system 12 may communicate with any number of data resources to determine the potential familiar merchant name. The recommendation system 12 may determine the potential familiar merchant name using any of the methods hereinafter described or any combination of those methods.

[00145] With continued reference to FIGS. 1 and 2, in response to determining the potential familiar merchant name, the recommendation system 12 may generate and communicate a recommendation message to the user device 10. The recommendation message may include the potential familiar merchant name. The recommendation message may include a plurality of potential familiar merchant names if multiple potential familiar merchant names are possible, and the user may confirm or reject each of the plurality of potential familiar merchant names individually, as described herein.

[00146] With continued reference to FIGS. 1 and 2, the recommendation system 12 may receive a confirmation message from the user device 10 in response to the user device 10 receiving the recommendation message. The confirmation message may associate the unfamiliar merchant name from the request message with the potential familiar merchant name from the recommendation message. In this way, the confirmation message may confirm that the potential familiar merchant name recommended by the recommendation system 12 is associated with the unfamiliar merchant name and that the user indeed initiated the transaction in question. In response to receiving a confirmation message, the recommendation system 12 or an issuer system of the portable financial device may forgo further processing of the request message (e.g., because the user did initiate the transaction and the request message was associated with“friendly fraud” and was not a fraudulent transaction). [00147] With continued reference to FIGS. 1 and 2, the recommendation system 12 may receive a rejection message from the user device 10 in response to the user device 10 receiving the recommendation message. The rejection message may disassociate the unfamiliar merchant name from the request message with the potential familiar merchant name from the recommendation message. In this way, the recommendation message may communicate that the potential familiar merchant name recommended by the recommendation system 12 is not associated with the unfamiliar merchant name and that the user maintains that it did not initiate the transaction in question. In response to receiving a rejection message, the recommendation system 12 or an issuer system of the portable financial device may initiate a fraud response protocol. The fraud response protocol may include further processing the request message. The fraud response protocol may include communicating with the user that the account data associated with the portable financial device may have been fraudulently obtained and used. The fraud response protocol may prevent any further transactions from being initiated by the portable financial device until further fraud investigation is completed.

[00148] Referring to FIG. 3, a non-limiting embodiment of a graphical user interface (GUI) 22 displayed in a system for processing a request message is shown. It will be appreciated that the GUI 22 shown in FIG. 3 is non-limiting, and the user may submit request messages using any suitable GUI. In the example shown in FIG. 3, the user may submit a request message to the recommendation system 12 using the user device 10. The GUI 22 may be accessible to the user via an Internet connection, such that the request message is communicated from the user device 10 to the recommendation system 12 over a secure Internet connection. For example, the request message may be submitted to the recommendation system 12 by the user device 10 accessing a website associated with the recommendation system 12 or accessing a mobile application of the recommendation system 12 on the user device 10 (which may be a mobile phone). The recommendation system 12 may be a browser plug-in to the user device 10.

[00149] With continued reference to FIG. 3, the user may enter the unfamiliar merchant name to a freeform field 24 of the GUI 22. The user may also enter the date of the transaction into a freeform field 26 and may enter any other relevant data required or requested by the GUI 22. The user may submit the request message using a submit button 28. In response to the user clicking the submit button 28 to submit the request message, the recommendation system 12 may determine, generate, and communicate a potential familiar merchant name, and the determined potential familiar merchant name may be displayed in a field 30 of the GUI 22.

[00150] The GUI 22 may also include a confirm button 32 that allows the user device 10 to click to communicate a confirmation message to the recommendation system 12. The GUI 22 may also include a reject button 34 that allows the user device 10 to click to communicate a rejection message to the recommendation system 12.

[00151] Referring to FIG. 4, another non-limiting embodiment of a GUI 33 displayed in a system for processing a request message is shown. As shown in FIG. 4, the GUI 33 may include an upload window 35, which allows the user to upload the user statement 16. The upload window 35 may include a freeform field 36 to allow the user to enter the file location of the user statement 16 to be uploaded. The upload window 35 may additionally or alternatively include a button 38 to allow the user to browse file locations of the user device 10 to identify the user statement 16 to be uploaded. The upload window 35 may include a submit button 40 which, when clicked, causes the selected file of the user statement 16 on the user device 10 to be uploaded and displayed on the GUI 33. It will be appreciated that other formats for uploading user statements 16 may be used. For example, the user may log in to a secure account using the user device 10, which secure account stores user statements 16 of the user for the user to view.

[00152] With continued reference to FIG. 4, the user statement 16 may be displayed on the GUI showing each transaction initiated by the user using the portable financial device during the time period associated with the user statement 16. The GUI 33 may also include a display recommendations feature 42. The display recommendations feature 42 may allow the user to determine whether recommendations for potential familiar merchant names that may be unfamiliar merchant names are to be displayed on the user statement. The display recommendations features 42 may include radio buttons, as shown, or may be activated using other methods, such as a dropdown box. When the display recommendations feature 42 is activated (as shown), a recommended familiar merchant name may be displayed for unfamiliar merchant names. For example, the recommended potential familiar merchant name for unfamiliar merchant name “Payment Gateway 1” is“Home Improvement Store”. The user may indicate which merchant names listed on the user statement 16 are unfamiliar merchant names using any sufficient method, or the recommendation system 12 may determine which merchant names listed on the user statement 16 may be unfamiliar merchant names and display recommendations on those unfamiliar merchant names. The user may indicate which recommendations of potential familiar merchant names are correct or incorrect by communicating a confirmation message or rejection message, as appropriate, as previously described.

[00153] Referring to FIG. 5, database entries of a payment gateway database 46 including data associated with payment gateways is shown. The payment gateway database 46 may be included in the recommendation database 14 or may be a separate database in communication with the recommendation system 12. The payment gateway database 46 may include a list of known payment gateways 48 (e.g., Payment Gateway 1 , Payment Gateway 2, Payment Gateway 3). The payment gateway database 46 may also include a URL 50 associated with each of the known payment gateways. The payment gateway database 46 may also include an association score 52 for each known payment gateway 48.

[00154] The association score 52 may be a score indicating the likelihood that the associated known payment gateway 48 is the unfamiliar merchant name listed on the user statement 16. The association score 52 may be determined based on past data of other users (e.g., crowd-sourced data) that indicates how often the known payment gateway 48 was determined to be the unknown merchant name listed on a user statement 16. The association score 52 may be represented using any suitable method of quantitatively or qualitatively representing how often the known payment gateway 48 was determined to be the unknown merchant name listed on a user statement 16. For example, the association score 52 may be a score out of 100, may be a count of the number of times the known payment gateway was or was not an unknown merchant name, may be a letter grade, and/or the like.

[00155] If the user statement 16 includes an unfamiliar merchant name that matches one of the known payment gateways 48 and the association score 52 for that known payment gateway 48 has a score suitable according to a rules-based protocol, the recommendation system 12 may determine a potential familiar merchant name. A suitable score, for example, may include the association score 52 having at least a certain value out of 100 in order to scan the browser history of the user device 10. [00156] Referring to FIG. 6, a database entry in a business entity database 60 associating a business entity with a payment gateway is shown. The business entity database 60 may be a database of the recommendation database 14 or may be a separate database in communication with the recommendation system 12. The business entity database 60 may include a list of business entities 62, a URL 64 associated with each business entity, a payment gateway 66 associated with each business entity, and an association score associated with each business entity. Other relevant information may be included in the business entity database. For example, the business entity database 60 may include geolocation data of at least one brick-and-mortar location of each business entity 62. The business entity database 60 may include trademark and/or service mark information associated with each business entity 62 in non-limiting embodiments. The business entity database 60 may include at least one merchant category code (MCC) associated with each business entity 62 in non-limiting embodiments.

[00157] With continued reference to FIG. 6, upon the recommendation system 12 receiving the later described user data, the recommendation system 12 may communicate with the recommendation database 14 or other database including the business entity database 60 to determine whether the potential familiar merchant name is included in the business entity table. The recommendation system 12 may search based on at least a portion of the potential familiar merchant name to determine whether the business entity database 60 includes a matching business entity 62 or may search on the entire potential familiar merchant name. For example, the recommendation system 12 may split the potential familiar merchant name into words or special characters or concatenate combinations of words to more accurately determine whether the potential familiar merchant name may be associated with business entity 62 in the business entity database 60.

[00158] The recommendation system 12 may determine whether the potential familiar merchant name matching the business entity 62 is associated with the known payment gateway 48 to determine that the user data indicates potential purchase activity from the potential familiar merchant name. For example, in FIG. 6, the potential familiar merchant name (“Flome Improvement Store”) is associated with Payment Gateway 1 , which in this example is the unfamiliar merchant name listed on the user statement 16. [00159] The recommendation system 12 may also analyze the association score 68 associated with the business entity 62. The association score 68 may indicate the likelihood that the business entity 62 is associated with an unfamiliar merchant name and/or the particular unfamiliar merchant name from the request message. The association score 68 may be based on past data of other users (crowd-sourced data) that indicates how often the potential familiar merchant name was confirmed or rejected to be an unfamiliar merchant name or the particular unfamiliar merchant name in the request message). The association score 68 may be represented using any suitable method of quantitatively or qualitatively representing how often the business entity 62 was determined to be the unfamiliar merchant name (e.g., listed on a user statement 16 and in the request message). For example, the association score 68 may be a score out of 100, may be a count of the number of times the known payment gateway was an unknown merchant name, may be a letter grade, and/or the like.

[00160] If the association score 68 for the potential familiar merchant name is suitable according to a rules-based protocol, the recommendation system 12 may generate and communicate the recommendation message as previously described. A suitable score, for example, may include the association score 68 having at least a certain value out of 100. In some non-limiting embodiments or aspects, the recommendation system 12 may not utilize an association score 68.

[00161] Referring back to FIGS. 5 and 6, in response to receiving the previously described confirmation message and/or rejection message, the recommendation system 12 may suitably update the association scores 52, 68 associated with the known payment gateway 48 and business entity 62, respectively. For example, the confirmation message may cause the recommendation system 12 to update the association score 68 of the business entity to indicate a higher likelihood that the unfamiliar merchant name is associated with the potential familiar merchant name. Conversely, the rejection message may cause the recommendation system 12 to update the association score 68 of the business entity to indicate a lower likelihood that the unfamiliar merchant name is associated with the potential familiar merchant name. The updated association scores may be used for determining potential familiar merchant names for unfamiliar merchant names associated with subsequent request messages (e.g., from the same or different users). [00162] The recommendation processor 12 may receive user data associated with the user initiating the card-present transaction. The user data may include geolocation data, beacon connection data, message data, image data, browser history data, and/or any other data associated with the user and/or a computing device operated by the user. The user data may be stored on a mobile device (e.g., a smartphone), another computing device of the user, or on a remote device or system. This user data may be used by the recommendation system 12 to determine the potential familiar merchant name corresponding to the unfamiliar merchant name. This determination may be made based on the user data and/or any suitable additional data using any sufficient method or system. Several non limiting embodiments as to how user data and/or additional data may be utilized to determine the potential familiar merchant name are hereinafter described.

A. User Browser History

[00163] In some non-limiting embodiments, the recommendation system 12 may receive and utilize browser history data associated with a user device 10 of a user, and may use the browser history data to at least partially determine the potential familiar merchant name.

[00164] Referring to FIG. 7, a browser history 54 including browser data on a user device 10 is shown. The browser history 54 may include a list of websites visited 56 by the user and a date and/or time visited 58 for each website. Other relevant information may be included in the browser history 54 as browser data as required. In some non-limiting embodiments, the user device 10 of which the recommendation system 12 scans the browser history 54 may be the user device which submitted the request message. In some non-limiting embodiments, the user device 10 for which the recommendation system 12 scans the browser history 54 may be a user device associated with the portable financial device and/or associated with the user. The browser history 54 of multiple user devices may be scanned by the recommendation system 12.

[00165] With continued reference to FIG. 7, the recommendation system 12 may scan the browser history 54, which may indicate that the user initiated a card-present purchase at a store location of a potential familiar merchant name associated with the payment gateway (which was determined to be the unfamiliar merchant name). For example, the presence of a URL associated with a merchant in the user’s browser history 54 of websites visited 56 may indicate that the user considerer or made a purchase at the merchant’s brick-and-mortar location via a card-present transaction. The presence of a combination of URLs in the browser history 54 of websites visited 56 may indicate that the user considerer or made a purchase at the merchant’s brick-and-mortar location via a card-present transaction. For example, a browser history 54 in which the user visited a merchant website temporally proximate to a website having mapping capabilities (e.g., to provide directions to a merchant location) may indicate that the user considerer or made a purchase at the merchant’s brick-and-mortar location via a card-present transaction.

[00166] In some non-limiting embodiments, the browser history 54 may additionally or alternatively include data associated with a product search or product review associated with a product and/or service that was part of the card-present transaction or provided by the merchant. The product search or product review in the browser history 54 may include a webpage on the merchant’s website or may be a third-party website offering product information about the product and/or service that was part of the card-present transaction and/or about the merchant of the card- present transaction. The presence of such a product search or product review in the user’s browser history 54 may indicate that the user considerer or made a purchase at the merchant’s brick-and-mortar location via a card-present transaction.

[00167] With continued reference to FIG. 7, the time visited 58 information of the browser history 54 may be utilized to determine the potential familiar merchant name. The user visiting a merchant website or other website associated with the merchant (e.g., a relevant product search or product review website) temporally proximate to the card-present transaction may indicate that the user considerer or made a purchase at the merchant’s brick-and-mortar location via a card-present transaction. Temporally proximate may mean that the user visited the website and made the card-present transaction within a predetermined number of seconds, minutes, hours, or days of each other. In some non-limiting embodiments, the recommendation system 12 may scan the user browser history 54 to determine whether the user visited the merchant website of a potential familiar merchant name on the day the card-present transaction was initiated.

[00168] Therefore, based at least partially on the user browser history 54, the recommendation system 12 may determine the potential familiar merchant name. B. Geolocation of Mobile Device

[00169] Referring to FIG. 8, in some non-limiting embodiments, the recommendation system 12 may receive and utilize geolocation data and/or beacon connection data (hereinafter“geolocation data”) associated with a location history of a mobile device of the user. The location history may be for the date of the transaction (or other time period temporally proximate the card-present transaction). The recommendation system 12 may use geolocation data associated with a location history of a mobile device of the user to at least partially determine the potential familiar merchant name.

[00170] With continued reference to FIG. 8, in some non-limiting embodiments, the recommendation system 12 may receive the geolocation data associated with a location history of a mobile device of the user and create a map 70 based on the geolocation data, such as coordinate data collected by the mobile device during the time period. In other non-limiting embodiments, the geolocation data may be the map 70, such that the recommendation system 12 receives the map 70 from the mobile device of the user or elsewhere. The map 70 may include a route 72 followed by the mobile device during the time period associated with the geolocation data.

[00171] The map 70 may include certain places of interest, such as a residence 74 of the user and various merchant locations 76a-76c. In some examples, the merchant locations on the map 70 may be merchants that the recommendation system 12 determines may be the potential familiar merchant name.

[00172] Based at least partially on the geolocation data, the recommendation system 12 may determine the potential familiar merchant name by analyzing the route 72 on the map 70 as it relates to the various merchant locations 76a-76c. For example, from the map 70 in FIG. 8, it can be determined that the route 72 travels proximate HIS 76a, and the recommendation system 12 may determine that HIS 76a is a potential familiar merchant name based on this data. The geolocation data may further include time data associating when the mobile device was at a particular location on the map 70 and/or for how long the mobile device remained at that location. The mobile device being at a merchant location at the time of the card- present transaction and/or remaining at a merchant location for a predetermined time period may indicate that the merchant is the potential familiar merchant name. [00173] Therefore, based at least partially on geolocation data including location history of a mobile device of the, the recommendation system 12 may determine the potential familiar merchant name.

C. Message Data

[00174] Referring to FIG. 9, in some non-limiting embodiments, the recommendation system 12 may receive and utilize message data associated with a message communicated to the user device 10. By being communicated to the user device 10, the message is sent to or is accessible on or from the user device 10. The message data may be from the date of the transaction (or other time period temporally proximate the card-present transaction). The recommendation system 12 may use this message data to at least partially determine the potential familiar merchant name.

[00175] In some non-limiting embodiments, the message may include a text message or email message sent to or accessible on the user device 10. In some non-limiting embodiments, the message may include a transaction confirmation message sent to or is accessible on or from the user device 10.

[00176] FIG. 9 shows a non-limiting embodiment of a message 80 that may be used as message data for determining the potential familiar merchant name. In this example, the message 80 is an email message that was sent to an email account of the user as a transaction confirmation message, which message 80 is accessible on the user device 10. The message 80 may include transaction details 82 about the card present transaction. Such transaction details 82 may include the date and/or time of the transaction, the transaction total, the payment method, the purchase location, and the like. The message may also include a merchant identifier 84 to identify the merchant from whom the user purchased the goods and/or services.

[00177] The recommendation system 12 may scan the user device 10 for messages 80 received temporally proximate the card-present transaction (e.g., received on the same day) for relevant information as to the potential familiar merchant name. The recommendation system 12 may determine that a merchant communicating a relevant message 80 to the user temporally proximate the card- present transaction is a potential familiar merchant name. The recommendation system 12 may make this determination based on the scan of the contents of the message 80 by performing a keyword or optical character recognition (OCR) search, for example. The recommendation system 12 may search the message 80 based on any suitable parameter, such as based on a date or time of the transaction, the goods and/or service purchased, the total or the transaction, the purchase location, and the like.

[00178] Therefore, based at least partially on message data associated with messages communicated to the user device 10, the recommendation system 12 may determine the potential familiar merchant name.

D. Crowd-sourced Data

[00179] Referring to FIG. 10, in some non-limiting embodiments, the recommendation system 12 may receive and utilize crowd-sourced data and determine the potential familiar merchant name based at least partially on the crowd- sourced data.

[00180] In FIG. 10, one non-limiting embodiment of a system 90 in which crowd- sourced data is utilized by the recommendation system 12 is shown. In the system 90, the recommendation system 12, which is in communication with the recommendation database 14, is also in communication with a plurality of computing devices 92a-92e (e.g., mobile devices) each being a device of a different user.

[00181] Utilizing past request messages from the plurality of computing devices 92a-92e, the recommendation system 12 may have received (and stored in the recommendation database 14) data associated with those request messages listing an unfamiliar merchant name. In some non-limiting embodiments, the recommendation system 12 may have received and stored geolocation data and/or beacon connection data (geolocation data) associated with the plurality of computing devices 92a-92e. Further, the recommendation system 12 may have received and stored recommendation messages communicated to the plurality of computing devices 92a-92e in response to those request messages, as well as confirmation messages and rejection messages received in response to those recommendation messages.

[00182] The recommendation system 12 may analyze this data associated with previous request messages from the plurality of computing devices 92a-92e (e.g., the crowd-sourced data) when receiving a new request message from the user device 10. For example, the recommendation system 12 may determine a potential familiar merchant name based on a confirmation message previously received from the plurality of computing devices 92a-92e which indicated that the potential familiar merchant name was associated with the same unfamiliar merchant name in the new request message from the user device 10. For example, the recommendation system 12 may determine a potential familiar merchant name based on geolocation data (e.g., coordinates collected by the mobile device) from the plurality of computing devices 92a-92e at least partially matching or similar to the geolocation data of the user device 10 (also a mobile device).

[00183] Therefore, based at least partially on the crowd-sourced data, the recommendation system 12 may determine the potential familiar merchant name.

E. Communicating with Merchant Based on Geolocation

[00184] Referring to FIG. 1 1 , in non-limiting embodiments the recommendation system 12 may determine the potential familiar merchant name based on the geolocation data and/or beacon connection data (geolocation data) and an inquiry communication between the recommendation system 12 and at least one merchant system 1 12.

[00185] In the non-limiting embodiment of the system 1 10 shown in FIG. 1 1 , the recommendation system 12 may receive geolocation data (e.g., a location history of a mobile device as previously described) from the user device 10 (the mobile device) in addition to the request message received from the user device 10.

[00186] Based on the geolocation data from the user device 10, the recommendation system 12 may determine at least one merchant having a brick- and-mortar location in the vicinity of the geolocation data (an area presumably visited by the user). For example, and referring back to FIG. 8, the recommendation system 12 may determine at least one merchant within a predetermined distance of the route 72 on the map 70 (the geolocation data) of the user device 10 during a predetermined time period. For example, the predetermined distance may be a distance within a mile of the route 72, and the predetermined time period may be the date on which the card-present transaction associated with the request message was initiated. Other predetermined distances and/or predetermined time periods may be used.

[00187] With continued reference to FIG. 1 1 , in response to determining the merchant in the vicinity of the geolocation data, the recommendation system 12 may communicate an inquiry communication to a merchant system 1 12 operated by or on behalf of the merchant. The inquiry communication may include the unfamiliar merchant name from the request message. The inquiry communication may also include other transaction details associated with the card-present transaction associated with the request message (e.g., date and/or time of the transaction, the transaction total, the payment method, the purchase location, and the like).

[00188] In response to the inquiry communication, the recommendation system 12 may receive an answer message generated and communicated by the merchant system 1 12. The answer message may confirm that the merchant located in the vicinity of the geolocation data is the merchant associated with the unfamiliar merchant name. The answer message may provide further confirmation that the card-present transaction associated with the request message was initiated at the brick-and-mortar location of the merchant. Alternatively, the answer message may deny that the merchant located in the vicinity of the geolocation data is the merchant associated with the unfamiliar merchant name and that the card-present transaction associated with the request message was initiated at the brick-and-mortar location of the merchant. Based at least partially on this answer message, the recommendation system 12 may determine the potential familiar merchant name.

[00189] Therefore, based at least partially on the geolocation data and the inquiry communication to the merchant system 1 12, the recommendation system 12 may determine the potential familiar merchant name.

F. Image Data near Merchant Location

[00190] Referring to FIG. 12, in non-limiting embodiments the recommendation system 12 may determine the potential familiar merchant name based on the image data taken near a merchant location.

[00191] In the non-limiting embodiment of a system 120 shown in FIG. 12, the recommendation system 12 may receive image data from at least one image device 122. The image data may include still photographs and/or video footage taken by the image device. The image device 122 may be located near a merchant location located in a vicinity visited by the user on the transaction date based on the geolocation data.

[00192] Based on the geolocation data and/or beacon connection data from the user device 10, the recommendation system 12 may determine at least one merchant having a brick-and-mortar location in the vicinity of the geolocation data (an area presumably visited by the user). For example, and referring back to FIG. 8, the recommendation system 12 may determine at least one merchant within a predetermined distance of the route 72 on the map 70 (the geolocation data) of the user device 10 during a predetermined time period. For example, the predetermined distance may be a distance within a mile of the route 72, and the predetermined time period may be the date on which the card-present transaction associated with the request message was initiated. Other predetermined distances and/or predetermined time periods may be used.

[00193] Based on the merchants located in the vicinity of the geolocation data, the recommendation system 12 may identify at least one of the image devices 122 is located in the vicinity of the merchant. The vicinity of the merchant may include any distance from the merchant location at which the image device 122 may capture images of the merchant location. In some examples, the image device 122 may be located inside the merchant location (e.g., at the merchant point-of-sale). In some examples, the image device 122 may be located outside and proximate to an entrance of the merchant location.

[00194] The image data communicated to the recommendation system 12 from the image device 122 may include image data captured on the date the card-present transaction was initiated. In some examples, the image data may be captured during and/or after the card-present transaction was initiated. The image data may be captured during and/or in the seconds, minutes, or hours immediately after the card- present transaction was initiated.

[00195] In some non-limiting embodiments, the image data may be processed by the recommendation system 12 to determine the potential familiar merchant name. In some non-limiting embodiments, the image data may be scanned by the recommendation system 12 using a facial recognition software. The recommendation database 14 (or other database in communication with the recommendation system 12) may include image data that includes an image of the face of the user (a user image). The facial recognition software may scan the image data to identify the face of the user based on the stored user image. A match of the user image in the image data received from the image device may indicate that the user was in the vicinity of the merchant proximate the time of the initiation of the card-present transaction and may indicate that the merchant is the potential familiar merchant name.

[00196] In some non-limiting embodiments, after identifying a match of the user image of the user in the image data, the recommendation system may further scan that image using OCR software (or other suitable software). The OCR software may identify an object held by the user in the image data. The recommendation system using the OCR software may determine based on the object that the user is holding an object that matches one of the goods purchased in the card-present transaction. A match of the image of the object with a good purchased in the card-present transaction may indicate that the user was in the vicinity of the merchant proximate the time of the initiation of the card-present transaction and may indicate that the merchant is the potential familiar merchant name.

[00197] In another example, the OCR software (or other suitable software) may identify a bag associated with the user from the image data and further scan the bag. Based on the OCR scan of the bag, the recommendation system 12 may identify a merchant indicia (e.g., a trademark, logo, or other mark associated with the merchant) on the bag. The recommendation database 14 or other database in communication with the recommendation system 12 may have stored merchant indicia associated with merchants, from which the OCR scan of the merchant indicia on the bag may be compared for a match. A match of the image of the merchant indicia on the bag with stored merchant indicia may indicate that the user was in the vicinity of the merchant proximate the time of the initiation of the card-present transaction and may indicate that the merchant is the potential familiar merchant name.

[00198] Therefore, based at least partially on the image data taken by an image device 122 near the merchant location based on the geolocation data, the recommendation system 12 may determine the potential familiar merchant name.

G. Image Data near User Residence

[00199] With continued reference to FIG. 12, in non-limiting embodiments the recommendation system 12 may determine the potential familiar merchant name based on the image data taken near a user residence.

[00200] In the non-limiting embodiment of the system 120 shown in FIG. 12, the recommendation system 12 may receive image data from at least one image device 122. The image data may include still photographs and/or video footage taken by the image device 122. Flowever, in this example the image device 122 may be located near a user residence. For example, the image device 122 may be a residential security camera that is part of and/or in communication with a residential security system installed at the residence of the user.

[00201] The image data communicated to the recommendation system 12 from the image device 122 may include image data captured on the date the card-present transaction was initiated. In some examples, the image data may be captured after the card-present transaction was initiated. The image data may be captured in the seconds, minutes, or hours immediately after the card-present transaction was initiated.

[00202] In some non-limiting embodiments, the image data from the image device 122 at the residence of the user may be scanned using the OCR software as previously described to identify an object the user is holding that matches one of the goods purchased in the card-present transaction or identify a merchant indicia on the bag which matches a stored merchant indicia. A match of the image of the object with a good or service purchased in the card-present transaction may indicate that the user initiated the card-present transaction and may indicate that a specific merchant is the potential familiar merchant name. A match of the image of the merchant indicia on the bag with stored merchant indicia may indicate that the user initiated the card-present transaction and may indicate that the merchant associated with the merchant indicia is the potential familiar merchant name.

[00203] Therefore, based at least partially on the image data taken by an image device 122 near the user residence, the recommendation system 12 may determine the potential familiar merchant name.

H. Using MCC of Merchant

[00204] In non-limiting embodiments the recommendation system 12 may determine the potential familiar merchant name based on merchant category code (MCC) data associated with the card-present transaction.

[00205] Based on the request message, the recommendation system 12 may determine at least one MCC associated with the card-present transaction. Based on the MCC, the recommendation system 12 may determine potential merchant locations located in a vicinity visited by the user on the transaction date (or other relevant time period, such as seconds, hours, and/or minutes proximate the initiation of the card-present transaction) associated with the card-present transaction. The vicinity visited by the user may be determined based on the geolocation data and/or the beacon connection data (geolocation data) as previously described.

[00206] In response to determining the merchant locations in the vicinity visited by the user during the relevant time period, the recommendation system 12 may determine which of those merchants associated with the merchant locations are associated with (e.g., match) the MCC associated with the card-present transaction. A match of the MCC of the merchant potentially visited by the user with MCC associated with the card-present transaction and may indicate that the merchant is the potential familiar merchant name.

[00207] Therefore, based at least partially on the MCC data from the card-present transaction and the geolocation data, the recommendation system 12 may determine the potential familiar merchant name.

I. Digital Assistant Data

[00208] Referring to FIGS. 13A-13B, in non-limiting embodiments the recommendation system 12 may determine the potential familiar merchant name based on digital assistant data.

[00209] In the non-limiting embodiment of the system 130 shown in FIG. 13A, the recommendation system 12 may receive digital assistant data from a digital assistant device 132 of the user. The digital assistant device 132, as used herein, may be a network-enabled information processing system that has the capability to interpret natural language input in spoken and/or textual form to determine a user request and to perform an action based on that determined user request. Non-limiting commercial examples of digital assistant devices 132 include Amazon Echo and Google Flome. The digital assistant device 132 may be located in a space occupied by the user, such as the user residence, a user vehicle, a user workplace, and the like.

[00210] The digital assistant data may constitute the previously-mentioned message data. The digital assistant data may include stored queries made by the user to the digital assistant device 132 (a message communicated from the user to the digital assistant device 132) and responses to those queries made by the digital assistant device 132 (a message communicated from the digital assistant device 132 to the user). A date and/or time may be associated with each query and/or response.

[00211] With continued reference to FIG. 13A, in non-limiting embodiments the recommendation system 12 may receive digital assistant data from the digital assistant device 132. The digital assistant data may be from a predetermined time period, such as the date of the card-present transaction and/or the seconds, minutes, or hours immediately preceding the initiation of the card-present transaction. [00212] FIG. 13B shows non-limiting examples of digital assistant data 134 that may be communicated from the digital assistant device 132 to the recommendation system 12. Examples of user queries 136 are shown, and each of these user queries 136 may be associated with a response (not shown in FIG. 13B), which is also digital assistant data 134. The date and/or time 138 associated with each user query 136 and/or response is also shown in this non-limiting example. Certain queries that may be relevant to the recommendation system’s 12 determination of the potential familiar merchant name may include a query associated with a product search, a product review, a merchant review, directions to a merchant, store hours of a merchant, and the like. Digital assistant data which may also be relevant may include a reminder or an alarm requested by the user in a query to the digital assistant device 132. The alarm or reminder may be associated with the card- present transaction.

[00213] The recommendation system 12 may analyze the received digital assistant data to determine the potential familiar merchant name. The analysis may include a keyword search or other text search relevant to the card-present transaction. For instance, the recommendation system 12 may analyze the digital assistant data for keywords associated with the product purchased, the amount of the purchase, the merchant, and/or other like parameters associated with the card- present transaction.

[00214] Therefore, based at least partially on the digital assistant data, the recommendation system 12 may determine the potential familiar merchant name.

[00215] It will be appreciated that any of the above-described methods to determine the potential familiar merchant may be used by the recommendation system 12 individually or in combination with other methods to ultimately determine the potential familiar merchant identifier. As one non-limiting example, the recommendation system 12 may use both digital assistant data and user browser history to determine the potential familiar merchant name.

[00216] Referring to FIG. 14, a system 200 for updating an unfamiliar merchant name with a familiar merchant name is shown according to a non-limiting embodiment. The recommendation system 212 of FIG. 14 has all of the same features of the previously described recommendation system 12 (FIG. 1 ) and includes the following further features. The recommendation system 212 may periodically communicate with merchant systems to cause merchants to update unfamiliar merchant names based on users finding the unfamiliar merchant name of the merchant on their user statement 16 unfamiliar.

[00217] In non-limiting embodiments, the recommendation system 212 may communicate with an issuer system 214 of the portable financial device of a user to communicate an unfamiliar merchant name for the merchant system 220 to update. It will be appreciated that in some non-limiting embodiments or aspects the recommendation system 212 and the issuer system 214 may be components of the same system operated by or on behalf of the issuer or recommendation system 212 and the issuer system 214 may be separate computer systems. The issuer system 214 may communicate with a transaction processing system 216 operated by or on behalf of a transaction service provider associated with the portable financial device to communicate the unfamiliar merchant name for the merchant system 220 to update. The transaction processing system 216 may communicate with an acquirer system 218 associated with the merchant associated with the unfamiliar merchant name. The acquirer system 218 may communicate with a merchant system 220 associated with the merchant associated with the unfamiliar merchant name. Upon receiving the communication to update the unfamiliar merchant name, the merchant system 220 may be updated to replace the unfamiliar merchant name with a tradename of the merchant which would be recognizable to users. This update may prevent future request messages associated with“friendly fraud” from users because the tradename recognizable to the user would not cause the user to suspect a fraudulent transaction (because the user recognizes the transaction as one that he/she initiated). It will be appreciated that, in some non-limiting embodiments, the recommendation system 212 may communicate directly with the merchant system 220 to communicate an unfamiliar merchant name for the merchant system 220 to update.

[00218] With continued reference to FIG. 14, in some non-limiting embodiments, the recommendation system 212 may communicate with the merchant system 220 to communicate an unfamiliar merchant name for the merchant system 220 to update after a single instance of a user identifying a merchant name as an unfamiliar merchant name. In other non-limiting embodiment, the recommendation system 212 may communicate with the merchant system 220 to communicate an unfamiliar merchant name for the merchant system 220 to update after a plurality of separate users have identified the same merchant name as an unfamiliar merchant name, such that the recommendation system 212 communicates with the merchant system 220 after a predetermined number of users have indicated the merchant name as an unfamiliar merchant name. The recommendation system 212 may communicate with merchant systems 220 that require an unfamiliar merchant name to be updated periodically, such as daily, weekly, monthly, quarterly, and the like. In this way, merchant systems 220 periodically update unfamiliar merchant names identified by users, which reduces future request messages associated with“friendly fraud”.

[00219] Referring to FIG. 15, a method 300 for processing a request message is shown according to a non-limiting embodiment. The method 300 may process request messages associated with card-present transactions. At first step 302, the recommendation system 12 may receive a request message from the user device, and the request message may be associated with the at least one card-present transaction between the user and at least one merchant. The request message may include at least one unfamiliar merchant name associated with the at least one merchant, as identified by the user.

[00220] With continued reference to FIG. 15, at a second step 304, the recommendation system 12 may receive user data comprising at least one of the following: geolocation data, beacon connection data, message data, image data, browser history data, or any combination thereof. At a third step 306, based at least partially on the user data, the recommendation system 12 may determine at least one alternate merchant name corresponding to the at least one unfamiliar merchant name from the request message, as previously described.

[00221] At a fourth step 308, the recommendation system 12 may generate and communicate to the user device a recommendation message including the at least one alternate merchant name.

[00222] Although non-limiting embodiments have been described in detail for the purpose of illustration, it is to be understood that such detail is solely for that purpose and that the embodiments described herein are not limited to the disclosed embodiments, but, on the contrary, are intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.