CROSS-REFERENCE TO RELATED APPLICATIONSThis application is a continuation of U.S. patent application Ser. No. 16/391,164, filed Apr. 22, 2019, which is a continuation of U.S. patent application Ser. No. 14/453,361, filed Aug. 6, 2014, now U.S. Pat. No. 10,271,161, which is incorporated herein by reference in its entirety.
TECHNICAL FIELDThe present application generally relates to merchant item and service return processing using wireless beacons and more specifically to establishing a wireless beacon at a merchant location used to return purchased items and/or services to assist and streamline a return of the purchased items and/or services.
BACKGROUNDMerchants may offer return and service processes at specific areas at merchant locations. The processes may assist a user in returning, refunding, and/or exchanging purchased items and/or services. For example, a user unhappy with a certain product may return the product or exchange the product. However, often the return process takes a significant amount of time to locate a similar item and provide the item to the user. Moreover, refunds for purchased items/services may require user financial information to be input and a receipt to be presented. This often becomes an issue for users who have lost or destroyed the receipt or users who have received the item/service as a gift. Additionally, merchants may also be victims of fraud where other users may shoplift an item and attempt a return and refund without a receipt. Thus, if the user requests cash or refuses to provide identification information, the user may not be entered in a database enabling the merchant to identify the user as a common returner that may assist the merchant in preventing fraud.
BRIEF DESCRIPTION OF THE DRAWINGSFIG.1 is a block diagram of a networked system suitable for implementing the processes described herein, according to an embodiment;
FIG.2 is an exemplary environment displaying users checking in to a merchant return line through a wireless beacon located at the merchant return line, according to an embodiment;
FIG.3 is an exemplary system environment showing a user interface of a merchant device displaying receipts and transaction histories for users checked-in to a merchant return line through a wireless beacon, according to an embodiment;
FIG.4 is a flowchart of an exemplary process for merchant item and service return processing using wireless beacons, according to an embodiment; and
FIG.5 is a block diagram of a computer system suitable for implementing one or more components inFIG.1, according to an embodiment.
Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.
DETAILED DESCRIPTIONProvided are methods that provide merchant item and service return processing using wireless beacons. Systems suitable for practicing methods of the present disclosure are also provided.
Various merchant locations may provide short range wireless communications with a device, such as through beacons using Bluetooth Low Energy (BLE), LTE Direct, or other communication protocol. These beacons may be set up at a merchant location, such as at or nearby a merchant return, exchange, and/or customer service line. The beacons may communicate with devices in possession of users to alert the users of check-in services offered through their device. The beacons may provide additional functionality, such as establishing a connection with a merchant device or server to complete transactions, including return, refund, and/or delivery services for items and/or services purchased by the users with the merchant. The beacons may communicate with the users' devices directly, including information stored in the beacons. The beacons may also provide communication with a device attached to, or in communication with, the beacon, such as the device/server of a merchant.
A merchant may sell items and/or services to users online, through phone communications, or at merchant locations. The merchant may further provide for returns, refunds, and/or exchanges of purchased items/services at a merchant location through processes available at one of the merchant locations. For example, a merchant may provide a service desk at a merchant location where a user may bring purchased items to be refunded, fixed, exchanged, or otherwise returned. The merchant may offer check-in services through one or more short range wireless beacons established at or nearby a return line, desk, station, or other return processing area at the merchant location. These beacons at the merchant location may utilize short range wireless communications to communicate with a device in possession of the user. The beacons may employ Bluetooth Low Energy (BLE), LTE Direct, or another communication protocol to emit a communication signal receivable by the user's device. The communication may include an identifier for the beacon, the user, the merchant, and/or a payment provider administering the beacons.
The user's device may be set up to passively monitor for BLE communications. When the device detects the signal and verifies the one or more identifiers, both the device and the beacon may ramp up in power and establish a connection, where the connection may further enable the device to communicate with the merchant and/or a payment provider offering payment services between the merchant and the user. The beacon may be connected to a networked device at the merchant location, or the beacon may include network functionality to communicate with other devices and/or servers, such as a server for the merchant or the payment provider. Thus, the beacon enables the user's device to establish a connection, communicate check-in information (e.g., an identifier for the user), and/or complete a check-in with the merchant location's return processing area. The check-in may be completed automatically when the user's device is in range of the beacon, or may be completed after prompting the user to check-in when the user's device is in range of the beacon.
Once the merchant has established at least one wireless beacon at or nearby the return processing area, the wireless beacon(s) may connect to the user's device when the device is in proximity to the wireless beacon(s). For example, a wireless beacon may broadcast an identifier, which, when received, may initiate a check-in for a device within an area around the wireless beacon. Thus, as the user's device enters that area, the device may connect to the wireless beacon and/or initiate the connection and check-in process. The wireless beacon(s) may be range limited to correspond to the merchant return processing area, such as by limiting the signal strength of the beacon and/or utilizing the physical boundaries of the merchant location
Once the user's device connects to the beacon, various transactions may be initiated, accessed, and/or completed through the user's device and/or a merchant device receiving a notification that the user has checked in through their user device. For example, once the user's device connects to the beacon, the check-in information and/or identifier used to connect to the beacon by the user device may be used to look up receipts and transaction histories for the user. Thus, past receipts and transactions between the merchant and the user may be determined based on the connection between the user device and the wireless beacon. The past receipts may be recalled from a database available with the merchant or from a database for the payment provider that provides financial transaction processing and payment on behalf of the user to the merchant. The past receipts may be communicated and presented to a merchant representative at the return processing area with user information for the user (e.g., a name, identifier, address, financial information, item/service purchased in the receipt, picture of the user, etc.) so that the merchant representative may identify the user in a line at or approaching the return processing area. Additionally, the receipt may be utilized to initiate and process a return, refund, exchange, service/fix, etc., for the user of the purchased item(s)/service(s). The receipt and/or transaction history for the user may also be presented to the user, such as on a user device and/or a merchant device (e.g., a POS unit or kiosk having a computing device) so that the return process may be automated without the need to a merchant representative.
Additional information may also be determined using the check-in information and/or identifier, such as a transaction history of the user with the merchant (e.g., all past transactions), shared accounts by multiple users, fraud information available with the merchant, payment provider, or other entity, and/or past behavior of the user. The transaction history for the user may be utilized to determine a history of the user with the merchant. Thus, the transaction history may include amounts spent, purchase histories, and/or loyalty rewards that may assist the merchant in providing additional or VIP services to certain users. For example, certain users may be given a personalized merchant representative to handle their return, or may be entitled to skip a line at the return processing area based on their valued customer status. The transaction history may also be used to determine financial instruments of the user that may receive a refund of a purchase price for the returned item(s)/service(s). A loyalty account/status of the user may be affected by the return, such as offering additional benefits to entice the user to further purchase with the merchant or revoking loyalty rewards earned by the purchase that is returned.
A transaction history for the user may also be pulled to determine if the user is a frequent return and require photo identification for the user. For example, if the user has frequently returned items without receipts or has returned multiple quantities of one item using one receipt or no receipts, the merchant may determine the user is exhibiting fraudulent behavior and require additional security measures. In other embodiments, other wireless beacons or devices at the merchant location may determine if a user was recently in an area of the merchant location that the returned item/service is found, thus potentially indicating fraudulent activity. If the user has previously committed fraudulent behavior with the merchant or another entity, the merchant may be informed about the fraudulent behavior and take appropriate actions. Moreover, the payment provider or other entity may include transaction history information for past purchases and returns by the user that may assist the merchant in identifying fraudulent behavior. The user may be assigned a ranking or other score that determines how fraudulent the behavior is of the user, thus enabling the merchant to make a determination of whether to accept a return, refund, or exchange of an item/service.
The user may also utilize one or more shared payment instruments to purchase items from the merchant. Credit cards and/or payment accounts may be shared between a family (e.g., a husband and wife having the same credit card number), or two or more payment instruments may be determined to be shared based on co-locating or co-spending habits of the payment instruments. In other embodiments, signatures and/or pictures associated with the account may be stored by the merchant when the user purchases an item/service with the merchant, or they may be stored with the payment instrument when the payment instrument is established. Thus, if the user is returning an item paid for and signed by another user sharing a user account recalled through the check-in information or identifier, the merchant may determine that the user knows or otherwise is trusted by the other user and issue a refund based on the stored information about the shared accounts. Based on the degree of trust between the two users, the merchant may determine a trustworthiness score to the returning user, allowing that user to return items for other users only if trusted by the merchant. For example, two users sharing a payment instrument may entitle either user to return items for the other user, while two payment instruments that frequently co-locate may only allow some return or none.
Past behavior of the user may also be pulled and presented to the merchant and/or merchant representative when the user arrives at the return processing area. In various embodiments, a user may be returning a vehicle or other item that is rented by the user with the merchant. The vehicle or returned item may include various processing components that may accrue information for the usage of the item, for example, mileage, fuel level, uses, damage, etc. The information may be transmitted to the merchant when the user checks-in to the return processing area and a bill for the user's use of the rented item may reflect the information about the usage of the rented item. The user may be informed about the usage information and the cost for usage on the user's device and may complete a transaction for the usage using the device.
FIG.1 is a block diagram of anetworked system100 suitable for implementing the processes described herein, according to an embodiment. As shown,system100 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary device and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable device and/or server based OS. It can be appreciated that the devices and/or servers illustrated inFIG.1 may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities.
System100 includes auser102, a merchant employee104 auser device110, amerchant location130 and awireless beacon132, amerchant device140, andpayment provider server170 in communication over anetwork180.User102, such as a consumer, may visitmerchant location130 to engage in one or more returns of items/services the user has previously purchased.Wireless beacons130 may connect withuser device110 to find receipts and transaction histories foruser102. The receipts and/or transaction histories may be presented to merchant employee104 onmerchant device140. Additionally,payment provider server170 may provide payment services, receipts and transaction histories storage, and recall of those receipts and transaction histories for transactions betweenuser device110 andmerchant device140.
User device110,wireless beacon132,merchant device140, andpayment provider server170 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components ofsystem100, and/or accessible overnetwork180.
User device110 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication withwireless beacon132,merchant device140, and/orpayment provider server170. For example, in one embodiment,user device110 may be implemented as a personal computer (PC), a smart phone, laptop computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS ®), or other wearable computing device, a computing device mounted within a vehicle (e.g., a console or heads up display computing device in a vehicle), and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a user device is shown, the user device may be managed or controlled by any suitable processing device. Although only one user device is shown, a plurality of user devices may function similarly.
User device110 ofFIG.1 contains a check-inapplication112, awallet application120,other applications114, adatabase116, and acommunication module118. Check-inapplication112,wallet application120, andother applications114 may correspond to processes, procedures, and/or applications executable by a hardware processor, for example, a software program. In other embodiments,user device110 may include additional or different software as required.
Check-inapplication112 may be used byuser102 ofuser device110 to establish a connection withwireless beacon132, including a check-in withmerchant location130. Check-inapplication112 may correspond to a specific application utilized byuser device110 withwireless beacon132 and/ormerchant device140 to complete a check-in. The check-in withmerchant device140 may correspond to a process to log in to a user account ofuser102 with merchant device140 (orpayment provider server170 ifpayment provider server170 provides check-in services for merchant location130). In other embodiments, the check-in may provide and/or verify the identity ofuser102, including transmission of an identifier foruser102 and/oruser device110. The check-in may be completed overnetwork180 withmerchant device140. In such embodiments, check-inapplication112 may correspond more generally to a browser application configured to communicate withmerchant device140 over a network connection (e.g., over a connection with network180).
In various embodiments, check-inapplication112 may also receive short range wireless communications fromwireless beacon132 at a location and transmit information towireless beacon132, including check-in information for a check-in process with merchant device140 (orpayment provider server170 ifpayment provider server170 provides check-in services for merchant location130) that associatesuser102 withwireless beacon132. For example,wireless beacon132 may be located at or nearby a return processing area (e.g., a service desk, return line, etc.) wherewireless beacon132 is set up to communicate withuser device110 whenuser device110 is in proximity towireless beacon132. Thus,wireless beacon132 may be range limited to connect only with devices (e.g., user device110) within a specified area, such as a radius aroundwireless beacon132, a distance away fromwireless beacon132, and/or a signal direction forwireless beacon132. Based on the proximity for connection towireless beacon132, check-inapplication112 may transmit information towireless beacon132 whenuser102 isnearby wireless beacon132, enablingmerchant device140 to determine thatuser102 is located in proximity to wireless beacon132 (and thus may retrieve receipt, transaction histories, or other information corresponding to user102).
Check-inapplication112 may execute in the background of an operating system ofuser device110 and be configured to establish connections, usingcommunication module118 ofuser device110, withwireless beacon132. The connection may be established with or without user input fromuser102. For example,wireless beacon132 may broadcast a token, such as a universally unique identifier (UUID), for reception by check-inapplication112, as will be explained in more detail herein. Check-inapplication112 may utilizecommunication module118 ofuser device110 to receive the token fromwireless beacon132. If check-inapplication112 acknowledges the UUID as identifyingwireless beacon132,merchant device140, and/or payment provider server170 (e.g., if check-inapplication112 determines the UUID corresponds to a request to establish a communication channel and/or process and complete a check-in), check-inapplication112 may transmit an identifier corresponding touser102 and/oruser device110 back towireless beacon132. Check-inapplication112 may utilizecommunication module118 ofuser device110 to communicate with wireless beacon132 (e.g., over near field communication, Bluetooth, Bluetooth Low Energy, radio, infrared, LTE Direct, or other communication protocol). The identifier fromuser device110 may include, be transmitted with, concatenated with, or otherwise bundled with the identifier received fromwireless beacon132. In other embodiments, different information may be transmitted towireless beacon132, such as an identifier foruser102, a name or other personal information foruser102, an identifier used to recall or determine receipts, transaction histories, and/or information foruser102, or other identifying information. Thus, the information transmitted towireless beacon132 does not need to be utilized to process and/or complete a check-in withmerchant device140 in all embodiments.
Once a connection is established withwireless beacon132,user device110 may be checked-in withmerchant device140 ifuser102 has not previously been checked-in. The check-in process may then associateuser102 withwireless beacon132 used to connect touser device110. For example,wireless beacon132 may previous be registered as located at or nearby a return processing area ofmerchant location130. Thus,merchant device140 is informed thatuser102 is attempting to return, refund, exchange, fix, or otherwise service previous item(s)/service(s) purchased byuser102. As previously discussed, in other embodiments, a check-in need not be processed and/or completed toassociate user102 with the drive through. Thus, other connections and data transfers towireless beacon132 may be sufficient toassociate user102 with the return processing area
Wallet application120 may be used, for example, to provide a convenient interface to permituser102 to select payment options and provide payment for items and/or services. For example,wallet application120 may be implemented as an application having a user interface enabling the user to enter payment options for storage byuser device110, provide payment to merchant device140 (e.g., usingpayment provider server170 in various embodiments), and complete a transaction for the items and/or services. In this regard,wallet application120 may correspond to an application that may provide an interface whereuser102 may enter and view information.User102 may utilizewallet application120 to generate a payment request for the items and/or services to be purchased byuser102. The payment request may instructpayment provider server170 to provide payment tomerchant device140. Additionally, the payment request may include identification of a payment instrument thatuser102 wishes to utilize to provide payment for the item(s)/service(s).Wallet application120 may provide payment for items using a user account with the payment provider, such aspayment provider server170.Wallet application120 may also provide payment through a payment card or bank account, and may further include cross-linking, allowinguser102 to identify a user account through an identifier for a separate user account (e.g. identifying a user account through a debit card account number and vice versa).Wallet application120 may correspond to a dedicated application for payment provider server170 (e.g., a specific device application) or may correspond to a browser application configured to view information available over the Internet or access a website corresponding topayment provider server170.
In certain embodiments,wallet application120 may be utilized to prepopulate a return order form whenuser102 purchases one or more items/services from a merchant corresponding tomerchant device140. For example, a user may purchase an item with the merchant (e.g., during a first visit atmerchant location130 and from merchant employee104) and utilizeuser device110 to pay for the item.User102 may further utilizeuser device110 to scan the item or may enter information for the item towallet application120. The information for the item (e.g., bar code, stock number/inventory information, price, condition, etc.) may be utilized with merchant return information (e.g., terms for return, time limits for returning items/services, etc.) to prepopulate a return form that may be transmitted tomerchant device140 and/or stored byuser device110. Thus, whenuser device110 later connects towireless beacons132,user102 and/or merchant employee104 may view the prepopulated return order form.User102 and/or merchant employee104 may then initiate a partial or complete return using the prepopulated return order form or may take additional actions, as will be discussed in more detail herein.
Wallet application120 may also store and/or access information about loyalty accounts, receipts, transaction histories, prepopulated return forms, or other information corresponding to items or services purchased from a merchant corresponding tomerchant device140. For example,wallet application120 may further include options to store receipts for purchased items and transaction histories with one or more merchants for later use, or may access such information from another source, such asmerchant device140 and/orpayment provider server170. Information stored bywallet application120 may be transmitted tomerchant device140 when check-inapplication112 forms a connection withwireless beacon132. Thus,wallet application120 providesinformation enabling user102 to provide proof of purchase tomerchant device140 and otherinformation assisting user102 in performing a return of the purchased item(s)/service(s). However, in other embodiments, check-in information, an identifier, or other identification information may be transmitted by check-inapplication112 and/orwallet application120 tomerchant device140 enablingmerchant device140 to recall the aforementioned loyalty, receipt, transaction history, and/or prepopulated return form information.
In various embodiments, one or more features of check-inapplication112 andwallet application120 may be incorporated in the same application so as to provide their respective features in one application.
User device110 includesother applications114 as may be desired in particular embodiments to provide features touser device110. For example,other applications114 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) overnetwork180, or other types of applications.Other applications114 may also include email, texting, voice and IM applications that allow a user to send and receive emails, calls, texts, and other notifications throughnetwork180. In various embodiments,other applications114 may include financial applications, such as banking, online payments, money transfer, or other applications associated withpayment provider server170.Other applications114 may include browser, social networking, and/or mapping applications, which may also be used in conjunction with check-inapplication112 and/orwallet application120.Other applications114 may contain software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.
User device110 may further includedatabase116 which may include, for example, identifiers such as operating system registry entries, cookies associated with check-inapplication112,wallet application120, and/orother applications114, identifiers associated with hardware ofuser device110, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. Identifiers indatabase116 may be used by a payment/credit provider, such aspayment provider server170, to associateuser device110 with a particular account maintained by the payment/credit provider.Database116 may include user device tokens and/or encryption keys, including an encryption key ofwireless beacon132,merchant device140, and/orpayment provider server170.Database116 may include identifying information for tokens enabling check-inapplication112 to identifywireless beacon132,merchant device140, and/orpayment provider server170 when receiving a corresponding check-in token. In various embodiments,database116 may store information used bywallet application120, such as receipts, transaction histories, loyalty account information, and/or prepopulated return order forms, which may be transmitted tomerchant device140 whenuser device110 connects towireless beacons132.
User device110 includes at least onecommunication module118 adapted to communicate withwireless beacon132,merchant device140, and/orpayment provider server170. In various embodiments,communication module118 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.Communication module118 may communicate directly withwireless beacon132 using short range communications, such as Bluetooth Low Energy, LTE Direct, WiFi, radio frequency, infrared, Bluetooth, and near field communications.
Merchant location130 may be implemented as a physical location corresponding to a merchant where the merchant offers returns for purchased items and/or services, such as a merchant storefront, a retail location, a service/return location/department, a car or other rented item return location, etc. In this regard,merchant location130 includeswireless beacons132 and connectivity tomerchant device140 utilized by merchant employee104. In various embodiments, merchant employee104 andmerchant device140 may be located atmerchant location130. However, in other embodiments, merchant employee104 andmerchant device140 may be remote frommerchant location130, for example, wheremerchant location130 may correspond to a rental vehicle return area at an airport configured to automate rental vehicle returns. Although only one merchant location is shown, a plurality of merchant locations may offer return services for use withmerchant device140 when returning purchased item(s)/service(s).
Merchant location130 may include physical structures, boundaries, and/or other necessary infrastructure to establish a return processing area withinmerchant location130. In this respect,merchant location130 may include lines, lanes, or other infrastructure whereuser102 may enter to initiate a return process. The return process may correspond to a process to exchange, refund, fix, service, or otherwise return one or more items and/or services purchased byuser102 from the merchant corresponding tomerchant location130/merchant device140. For example, a return processing area atmerchant location130 may correspond to a service desk at a retail store, a rental vehicle or other rental item return area, a refund/exchange counter at a merchant storefront, etc.Merchant location130 may only offer the return processing area atmerchant location130. However, in other embodiments,merchant location130 may include additional features and options foruser102 atmerchant location130, such as shopping and purchasing options, maintenance options, etc. Thus,merchant location130 may correspond to a larger merchant storefront or other location where the merchant corresponding tomerchant location130/merchant device140 may offer items and/or services for sale touser102. In this regard,merchant location130 may include further wireless beacons in addition towireless beacons132 that may track information for user102 (e.g., visited sub-locations within merchant location130), assistuser102 in checking in tomerchant location130, and/or provide payment processing touser102.
Merchant location130 ofFIG.1 includeswireless beacon132 established at the return processing area ofmerchant location130.Wireless beacon132 may include hardware and software necessary to execute the processes and functions as described below. In other embodiments,merchant location130 may include additional hardware and/or software as required to process the above and below described features offered bymerchant location130.
Wireless beacon132 may be maintained, for example, by a merchant corresponding tomerchant location130/merchant device140 and/orpayment provider server170.Wireless beacon132 may be implemented using any appropriate hardware and software configured for wireless communication withuser device110. For example, in one embodiment,wireless beacon132 may be implemented as a dongle device including a hardware processor and a communication module, for example, connected to device at the location of merchant employee104.Wireless beacon132 may also be implemented as devices incorporated within a personal computer (PC), a smart phone, laptop computer, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®.Wireless beacon132 may also act as a stand-alone device including a processor, communication module, and/or network interface component configured to communicate withuser device110 and/orpayment provider server170. Althoughwireless beacon132 is described singly, a plurality of wireless beacons may be set up at or nearby a return processing area for merchant location130 (e.g., at an entrance to the return processing area, in a line of the return processing area, and/or at a service desk of the return processing area).Wireless beacon132 may be limited, either by signal range or physical boundaries, tomerchant location130 and/or the return processing area. In embodiments where merchant employee104 andmerchant device140 are located atmerchant location130,wireless beacon132 may be located at or nearby merchant employee104 assisting the return processing area.
Wireless beacon132 ofFIG.1 contains processes, procedures, and/or applications executable by a hardware processor, for example, a software program, configured to interact withuser device110,merchant device140, and/orpayment provider server170. Thus, regardless of the implementation ofwireless beacon132 as discussed above,wireless beacon132 may utilize a connection/check-in process and include or be connected to a communication module. In other embodiments,wireless beacon132 may include additional or different hardware and software as required.
Wireless beacon132 may include an application for transmitting requests to establish a connection between a device (e.g., user device110) andwireless beacon132. The requests may be unique towireless beacon132, thereby identifyingwireless beacon132.Wireless beacon132 may utilize short range wireless communications ofwireless beacon132 to transmit the requests to establish a connection, including an identifier such as a Universally Unique Identifier (UUID). Ifuser device110 receives a request to establish the connection withwireless beacon132 and responds with an identifier foruser102/user device110 (potentially including the UUID and other information necessary to effectuate a check-in for user102),wireless beacon132 to ramp up in power and create a connection betweenuser device110 andwireless beacon132.
Wireless beacon132 may transmit the request to establish the connection withwireless beacon132 as a short range wireless communication (e.g. a BLE protocol communication) including a “wake up” process for check-inapplication112 ofuser device110 and/or a token forwireless beacon132 transmitting the request. In other embodiments, the request and/or connection may utilize near field communication, radio communication, infrared communication, or Bluetooth communication. Additionally, althoughwireless beacon132 may utilize BLE protocol communications to effectuate an “always on” type service where the UUID and “wake up” process are transmitted continuously, other communication protocols used to provide an “always on” service may include QUALCOMM® LTE Direct or similar device-to-device communication technology. BLE and LTE Direct may both be utilized to provide discovery of nearby devices to wireless beacon132 (e.g., user device110) and establishment of a connection for data transfers. In other embodiments,wireless beacon132 may correspond to other devices, such as WiFi capable devices, near field communication devices, etc.
The request may be specific touser device110 by including information that is specific touser102, such as a name, identifier, or user device identifier. The information specific touser102 may be determined from a user account ofuser102 or other information previously provided tomerchant device140 and/or payment provider server170 (e.g., an identifier foruser102 provided tomerchant device140 and/orpayment provider server170, a receipt for purchased item(s)/service(s), transaction histories foruser102, a prepopulated return order form, and/or information pulled from the aforementioned sources). Thus, in certain embodiments,only user device110 will pick up and authenticate the request, for example, ifuser102 has previously performed a transaction with the merchant corresponding tomerchant location130/merchant device140. For example,user102 may have generated a receipt or a transaction history with the merchant, or may create a prepopulated return order form for a purchase with the merchant.
Afterwireless beacon132 receives an identifier fromuser device110,wireless beacon132 may determineuser102 is in proximity towireless beacon132.Wireless beacon132 may pass the identifier (and any other device's identifiers where applicable) tomerchant device140 and/orpayment provider server170 to associate user102 (and the other users where applicable) with thewireless beacon132. By associatinguser102 withwireless beacon132,merchant device140 and/orpayment provider server170 may determine user102 (and the other users where applicable) is located at the return processing area ofmerchant location130 and may wish to initiate a return.
Wireless beacon132 may utilize a communication module to pass the identifier tomerchant device140, which may then pass the identifier topayment provider server170. However, in other embodiments,wireless beacon132 may utilize a network connection ofwireless beacon132 to pass the identifier topayment provider server170 directly. Thus,wireless beacon132 includes a communication module adapted to communicate withuser device110,merchant device140, and/orpayment provider server170. The communication module may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices. The communication module ofwireless beacon132 may also communicate withuser device110 and/ormerchant device140 using short range communications, such as Bluetooth Low Energy, LTE Direct, WiFi, radio frequency, infrared, Bluetooth, and near field communications.
Merchant device140 may correspond to a device used by merchant employee104 to provide return processing for previously purchased items and/or services byuser102. Thus,merchant device140 may be located locally tomerchant location130 or may also function remotely tomerchant location130 and interact withuser device110 overnetwork180. In various embodiments,merchant device140 may also be utilized to first view, process, and complete financial transactions withuser device110 for the items and/orservices user102 wishes to purchase.Merchant device140 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication withuser device110,wireless beacon132, and/orpayment provider server170. For example,merchant device140 may be implemented as a personal computer (PC), a smart phone, laptop computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS ®), other type of wearable computing device, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a merchant device is shown, the merchant device may be managed or controlled by any suitable processing device. Although only one merchant device is shown, a plurality of merchant devices may function similarly. Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference tomerchant device140 may be included in payment provider server170 (e.g., check-inapplication142 where check-in services are offered touser102 through payment provider server170), and vice versa.
Merchant device140 ofFIG.1 contains a check-inapplication142,merchant applications150, returnsapplication160,other applications144, adatabase146, and acommunication module148. Check-inapplication142,merchant applications150, returnsapplication160, andother applications144 may correspond to processes, procedures, and/or applications executable by a hardware processor, for example, a software program. In other embodiments,merchant device140 may include additional or different software as required.
Check-inapplication142 may correspond to processes to complete check-in withuser device110 for merchant location130 (e.g., with one or more ofwireless beacon132 established at or nearby an return processing area at merchant location130). Thus, check-inapplication142 may correspond to the merchant device side application configured to receive check-in information fromuser device110 and complete the check-in. The check-in request may include log in information for a user account with the merchant corresponding tomerchant location130/merchant device140 or an account withpayment provider server170 and thus complete the check-in withuser102 by verifying the account information. For example, the check-in information may include an identifier or other account information for a user/payment account ofuser102. However, in embodiments where a user account has not been previously established byuser102, check-inapplication142 may receive otherinformation identifying user102, including a user name/identifier, user device identifier, an identifier for an account with another server, or other information. Such information may also be used to identify past transactions ofuser102 with the merchant, such as receipts, transaction histories, and/or prepopulated return order forms. The check-in information may also be utilized to determine loyalty rewards foruser102 or access benefits foruser102.
Merchant applications150 may provide information for available items and/or services touser102, complete purchases of items and/or services byuser102, and generate receipts and transaction histories foruser102.Merchant applications150 may correspond to one or more applications configured to process and/or complete transactions for items and/or services sold by the merchant corresponding tomerchant location130/merchant device140 touser102, generate receipts and transaction histories for the item(s)/service(s), and/or provide loyalty account services and benefits touser102.Merchant applications150 may therefore provide a convenient interface to permit the merchant and/or a merchant employee to view selected item/service information and complete a transaction for the items/services (e.g., receive payment for the items/services). The transaction may be for item(s)/service(s) sold by the merchant, for rental agreements on return of a rented item byuser102, etc. Once the transaction is approved, merchant application152 may be utilized to request and process a payment for the items/service, for example, usingpayment provider server170. In other embodiments, the merchant may also receive physical payment instruments, such as cash and/or payment cards fromuser102. Thus, merchant applications152 may also be utilized to run payment cards, complete cash transactions, and/or otherwise complete payment for the order. Once payment for the order is complete, merchant application152 may be configured to generate a receipt and create, update, and/or process a transaction history foruser102. A receipt may document a single transaction by the user with the merchant, such as a sale of one or more items and/or services. The transaction history may include some or all receipts or other documentation of past transactions byuser102 with the merchant. The transaction history may be provided touser device110 and/orpayment provider server170. Once a transaction is processed usingmerchant application150,user102 may create a prepopulated return order form using information from merchant applications150 (e.g., the receipt for the transaction and/or a transaction history) withwallet application120, as previously discussed. Thus,merchant applications150 may receive the prepopulated return order form fromuser device110 and store the form todatabase146.
In various embodiments,merchant applications150 may include inventory processing and availability information applications configured to access and/or determine inventory level or availability for items and/or services offered by the merchant corresponding tomerchant location130/merchant device140. For example,merchant applications150 may access information fromdatabase146 or another source having an inventory level for an item sold by the merchant. The inventory level or availability information may assist merchant employee104 in selling the items/services initially touser102. Additionally, the inventory level/availability information may also be utilized by merchant employee104 when offering an exchange, refund, fix, servicing, or other return of a purchase byuser102, for example, to locate a replacement item or for providing repair of a broken item.Merchant applications150 may also include courier or delivery information enabling merchant employee104 to deliver a replacement product.
Additionally,merchant applications150 may be utilized to establish and maintain a loyalty account foruser102. Loyalty account information may include benefits and/or rewards foruser102 based onuser102′s past transactions with the merchant corresponding tomerchant location130/merchant device140. Utilizing the transaction history and/or the loyalty account,user102 may be offered upgraded service during a return process, such as for a loyal customer. The loyalty account and/or transaction histories may offeruser102 additional benefits when purchasing an item, such as a2 for1 sale,50% off price, etc. In other embodiments,merchant applications150 may also include discount offer applications that may generate and provide discount offers touser102. Information about benefits offered touser102 may be utilized byreturns application160 during processing of a return.
Once a connection is established and/or a check-in is completed betweenuser device110 andwireless beacon132, returnsapplication160 may be utilized to transmit and receive information betweenuser device110 andmerchant device140. For example, returnsapplication160 may receive check-in information or an identifier foruser102 and retrieve stored information foruser102 using the check-in information or identifier. Such information may be located withuser device110,database146,payment provider server170, and/or another source. Retrieved information may include receipts, transaction histories, loyalty status or preferred customer information (e.g., information enabling merchant employee104 to determine whether to extend preferred customer benefits to user102), and/or prepopulated return order forms.
Receipts and/or transaction histories may be presented to merchant employee104 onmerchant device140. Additionally, identification information foruser102 may be presented with the receipts and/or transaction histories. Identification information may include a name, identifier, picture, or other information foruser102 that may assist merchant employee104 in identifyinguser102. The receipts and/or transaction histories may display the items and/or services purchased byuser102 so that merchant employee104 may view the item(s)/service(s) and initiate a return. The receipts and/or transaction histories may also be transmitted touser device110 so thatuser102 may make a selection of one or more of the receipts for use in processing the return of the purchased item(s)/service(s).
Selection of a receipt or other purchased item/service in a transaction history byuser102 and/or merchant employee104 may initiate a return process withmerchant device140. Merchant employee104 may enter information (e.g., using an input device such as a keyboard, bar code scanner, or other device) tomerchant device140 when receiving the returned item(s)/service(s). In other embodiments, merchant employee104 is not required anduser102 may scan or enter information for the returned item(s)/service(s) and place any returned purchases at a designated area in the return processing area ofmerchant location130. Thus, utilizinguser device110 withwireless beacons132, the return process for item(s)/service(s) may be automated atmerchant location130 withmerchant device140.
User102 may return the item(s)/service(s) in exchange for another item/service. Thus, returnsapplication160 may receive inventory and/or availability information for replacement item(s)/service(s) frommerchant applications150 and display the availability and where the item(s)/service(s) are available to merchant employee104, which may be transmitted touser device110 for display touser102. If the return of the purchase is for a fix or servicing of the item (e.g., a broken electronic), returnsapplication160 may determine an amount of time until the item will be available and where/when the item may be fixed/serviced. The fixing/servicing information may be displayed to merchant employee104 and/or transmitted touser device110 for display touser102.
In other embodiments,user102 may request a refund of money or store credit. Thus, returnsapplication160 may initiate a refund by crediting some amount (e.g., purchase price, current price, or a devalued price based on the condition of the returned purchase) to a payment instrument ofuser102. Additionally,user102 may utilize a benefit, discount, or loyalty reward during purchase of item(s)/service(s). Thus, returnsapplication160 may determine a proper amount for a return based on the purchase price of the item(s)/service(s) byuser102. The payment instrument may be determined using the receipt and/or transaction histories ofuser102. Additionally, payment instruments and/or payment accounts for user102 (e.g., used byuser102, shared byuser102, etc.) may be determined using the receipts and/or transaction history, and payment for the return may be instituted with a different account as request byuser102.
In various embodiments,user102 may attempt to return an item and/or service that was purchased by another user who shares a payment instrument withuser102. For example, a husband may attempt to return a purchase that a wife made using a shared credit card or payment account. Thus, ifuser102 shares an account with another party, or co-locates/transacts with another account, the shared or corresponding account may be determined and a refund may be initiated with the shared/corresponding account. This enablesuser102 to make returns for parties that share an account or utilize an account with user102 (e.g., a family member, business employee, etc.).Returns application160 may determine that the two parties share an account based on images and/or signatures shared in the account. In certain embodiments, the payment instrument may not be directly shared, however, two payment instruments, one foruser102 and another for a second user, may frequently co-locate or transact together. For example, two payment accounts withpayment provider server170 may frequently spend at the same location and/or at or around the same time at the same location. In other embodiments, the two payment accounts may frequently transfer money between them. Thus, returnsapplication160 may trust or accept a return from theuser102 for an item/service purchased by the second user's account based on the aforementioned information. A trust score may be established to determine the reliability of such a return. For example, one transfer between the two accounts may be insufficient to build a high enough trust score, while multiple transfers may be sufficient. Such information on co-locating and/or transactions between accounts may be received from a credit/debit card company and/orpayment provider server170.
In various embodiments, returnsapplication160 may process a return of a purchase with a loyalty account of preferred customer status foruser102. Ifuser102 is returning an item or service thatuser102 received loyalty benefits for purchasing, returnsapplication160 may revoke or reduce the loyalty benefits originally conferred touser102. However, in other embodiments, returnsapplication160 may provide additional benefits or loyalty rewards touser102 when item(s)/service(s) are returned to incentivizeuser102 to return and/or perform additional purchases with the merchant.
Returns application160 may also display and/or process loyalty accounts, preferred customer status, and/or transaction histories to assist merchant employee104 in determining whether to provide preferred or VIP assistance touser102 during a return processing. For example, merchant employee104 or returnsapplication160 may determineuser102 is a frequent shopper with the merchant corresponding tomerchant location130/merchant device140. In other embodiments,user102 may sign up for or purchase a VIP assistance package with the merchant. Thus, whenuser device110 connects and/or checks-in withwireless beacon132, returnsapplication160 may display the preferred/VIP customer information to merchant employee104 so that additional assistance may be provided to user102 (e.g., bypassing a line, providing a separate line, etc.). The additional assistance may also be transmitted touser device110, such as instructinguser102 to bypass a line, providing a separate line foruser102, showing information for a merchant representative (e.g., merchant employee104) sent directly touser102, etc. The merchant representative sent touser102 may also be informed to assistuser102 directly.
Returns application160 may also display the transaction histories and/or previous behavior ofuser102 to assist merchant employee104 in detecting fraudulent behavior and fraudulent returns byuser102. Ifuser102 is a frequent returner, or is returning multiple quantities of a specific item with a single or no receipt, returnsapplication160 may populate the potentially fraudulent activity and alert merchant employee104. Additionally, returnsapplication160 may require additional security information if fraudulent behavior is detected, such as personal information and identification (e.g., a driver license). Fraudulent activity may be detected based on the return byuser102, such as ifuser102 has never previously generated a receipt for an item/service user102 is attempting to return. Thus, if the transaction history determined usingreturns application160 after receiving check-in information or an identifier fromwireless beacon132 does not have a previous purchase transaction for the item(s)/service(s),user102 may have shoplifted or stolen the item(s)/service(s). In other embodiments,user102 may attempt a return for a purchase that has already been returned. Thus, the transaction history may include information showing that the item(s)/service(s)user102 is returning may be shoplifted/stolen becauseuser102 has previously returned the purchase.
In other embodiments, behavior ofuser102 prior to the return may be utilized to detect fraudulent activity. For example, additional wireless beacons may be established throughoutmerchant location130 wheremerchant location130 corresponds to a retail location whereuser102 may purchase items and/or services. Thus, ifuser102 is previously determined to be in an area ofmerchant location130 having the item(s)/service(s) thatuser102 is attempting to return, returnsapplication160 may alert merchant employee104 thatuser102 may have shoplifted/stolen the item(s)/service(s). In other embodiments,merchant device140,payment provider170, and/or another entity may have information about past fraudulent behavior ofuser102. Thus, returnsapplication160 may alert merchant employee104 thatuser102 has a history of fraudulent behavior.
As previously discussed,user102 may prepopulate a return order form usingwallet application120 after entering or scanning information for a purchase. Onceuser102 has generated a prepopulated return order form, the form may be transmitted tomerchant device140 for storage or held byuser device110. Thus, whenuser device110 connects towireless beacons132, the prepopulated return order form may be presented to merchant employee104 inreturns application160. Merchant employee104 may then utilizereturns application160 to accept the form in total (e.g., no scanning of items required), partially accept the form for only the item(s)/service(s)user102 wishes to return (e.g., through scanning the returned item(s)/service(s)), or deny the RMA and then manually scan of each of the returned item(s)/services. Thus, in cases of frequent purchases byuser102,user102 may scan the returned item(s)/service(s) and identify which transaction from a retrieved list of transactions that contain the returned item(s)/service(s) (e.g., using user device110). Additionally, returnsapplication160 may overrideuser102′s selections based on store policy (e.g., a return policy limit, a time limit of validity of the prepopulated return order form, etc.). Merchant employee104 may then utilizereturns application160 to cancel the override or manually change the transaction that the item(s)/service(s) are related to (lowest sale price, most recent purchase date, promotional/discount related purchases, etc.).
As previously discussed, the return byuser102 may also be a return of a rental item, such as a rental vehicle. Thus, returnsapplication160 may receive information corresponding to the use of the rental item byuser102.Returns application160 may utilize the usage information withmerchant applications150 to generate a sales transaction covering the usage of the rental item byuser102. The usage of the rental item may be received from input by merchant employee104. However, the rental item may also include processing components that accrue and determine the usage of the rental item and transmit that usage tomerchant device140 for processing byreturns application160. The sales transaction may be transmitted touser device110.Returns application160 may process the return of the rental item by indicating the rental item has been returned, is available for further rental, or required maintenance, review, cleaning, etc.
Merchant device140 includesother applications144 as may be desired in particular embodiments to provide features tomerchant device140. For example,other applications144 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) overnetwork180, or other types of applications. In various embodiments,other applications144 may include financial applications, such as banking, online payments, money transfer, or other applications associated withpayment provider server170.Other applications144 may contain other software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.
Merchant device140 may further includedatabase146 which may include, for example, identifiers such as operating system registry entries, cookies associated with check-inapplication142,merchant applications150, and/orother applications144, identifiers associated with hardware ofmerchant device140, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. In one embodiment, identifiers indatabase146 may be used bypayment provider server170 toassociate merchant device140 with a particular account maintained bypayment provider server170.Database146 may also storeuser102′s information, including check-in information, an identifier, etc., foruser102, and any other users associated withuser102 while ordering withuser102.Database146 may include receipts for purchases byuser102 and transaction histories for purchased items byuser102 to present proof of purchase. Information indatabase146 may include information used bymerchant applications150 and/or returnsapplication160 to process a transaction, initiate and process a return for a purchase, detect fraudulent behavior, and/or provide preferred/VIP customer assistance.
Merchant device140 includes at least onecommunication module148 adapted to communicate withuser device110,wireless beacon132, and/orpayment provider server170. In various embodiments,communication module148 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.Communication module148 may communicate directly withwireless beacon132 using short range communications, such as Bluetooth Low Energy, LTE Direct, radio frequency, infrared, Bluetooth, and near field communications.
Payment provider server170 may be maintained, for example, by an online payment service provider, which may provide payment services and/or processing for financial transactions on behalf of a user. In this regard,payment provider server170 includes one or more processing applications which may be configured to interact withuser device110,wireless beacon132, and/ormerchant device140 to facilitate payment for a transaction. In one example,payment provider server170 may be provided by PAYPAL®, Inc. of San Jose, Calif., USA. However, in other embodiments,payment provider server170 may be maintained by or include a credit provider, financial services provider, financial data provider, and/or other service provider, which may provide payment services touser102 and/or merchant employee104. Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference topayment provider server170 may be included inmerchant device140, and vice versa.
Payment provider server170 ofFIG.1 includes a transaction processing application172,other applications174, adatabase176, and anetwork interface component178. Transaction processing application172 andother applications174 may correspond to processes, procedures, and/or applications executable by a hardware processor, for example, a software program. In other embodiments,payment provider server170 may include additional or different software as required, such as a check-in application as discussed in reference tomerchant device140, where such check-in processes and features are instead provided bypayment provider server170.
Transaction processing application172 may be configured to receive information from and/or transmit information touser device110 and/ormerchant device140 for processing and completion of financial transactions. Transaction processing application172 may include one or more applications to process financial transaction information fromuser102 and merchant employee104 by receiving a request to complete a transaction for items and/or services offered by merchant employee104. The request may correspond to a payment fromuser102 to merchant employee104. The payment may include a user account identifier or other payment information (e.g. a credit/debit card or checking account) foruser102 and a receiving account for the merchant corresponding tomerchant location130/merchant device140. Additionally, the payment may include a payment amount and terms of payment. Transaction processing application172 may complete the transaction by providing payment to the merchant through the merchant's account/payment information. Additionally, transaction processing application172 may provide receipts touser device110 and/ormerchant device140 for completion and documentation of the financial transaction. Transaction histories documents part or all of transactions betweenuser102 and the merchant may be provided touser device110 and/ormerchant device130 by transaction processing application172. The transaction history may include payments for item(s)/service(s), credit extensions by the merchant touser102, returns of purchases byuser102 to the merchant, loyalty rewards and benefit usage byuser102 with the merchant, and/or fraudulent behavior ofuser102 with the merchant and/or other merchants. For example, receipts and transaction histories may be provided touser device110 and/ormerchant device140 to allow for merchant employee104 to view a payment transaction and determine a past history of transactions betweenuser102 and the merchant.
In various embodiments,payment provider server170 includesother applications174 as may be desired in particular embodiments to provide features topayment provider server170. For example,other applications174 may include security applications for implementing server-side security features, programmatic server applications for interfacing with appropriate application programming interfaces (APIs) overnetwork180, or other types of applications.Other applications174 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user.
Additionally,payment provider server170 includesdatabase176. As previously discussed,user102 and/or the merchant corresponding tomerchant location130/merchant device140 may establish one or more payment accounts withpayment provider server170. User accounts indatabase176 may include merchant/user information, such as name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data.User102 and/or the merchant may link to their respective payment accounts through a user, merchant, and/or device identifier. Thus, when an identifier is transmitted topayment provider server170, e.g. fromuser device110 and/ormerchant device140, a payment account belonging touser102 and/or the merchant may be found. In other embodiments,user102 and/or merchant employee104 may not have previously established a payment account and may provide other financial information topayment provider server170 to complete financial transactions, as previously discussed.Database176 may further include additional information received fromuser device110 and/ormerchant device140, such as check-in information and identifiers and/or and transaction information (e.g., receipts, transaction histories, loyalty benefits, and/or fraudulent behavior) foruser102 and the merchant.
In various embodiments,payment provider server170 includes at least onenetwork interface component178 adapted to communicateuser device110,wireless beacon132, and/ormerchant device140 overnetwork180. In various embodiments,network interface component178 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices.
Network180 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments,network180 may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus,network180 may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components ofsystem100.
FIG.2 is an exemplary environment displaying users checking in to a merchant return line or area through a wireless beacon located at or near the merchant return line, according to an embodiment.Environment200 ofFIG.2 includes auser202ahaving adevice210a,auser202bhaving adevice210b,and auser202chaving a device210c,all corresponding generally touser102 anduser device110, respectively, ofFIG.1. Additionally,environment200 includes awireless beacon232 and amerchant device240 corresponding generally towireless beacon132 andmerchant device140, respectively, ofFIG.1.
Environment200 may correspond to a merchant location, such asmerchant location130 ofFIG.1, where a user may return purchased items and/or services to a merchant corresponding to the merchant location. However, in other embodiments,environment200 may also correspond to a sub-location or area of a larger merchant location where a user returned or returns the purchased item(s)/service(s). Thus,environment200 includes areturn desk290, amerchant inventory292, and areturn line294. Located nearreturn line294 iswireless beacon232 configured to connect to one or more ofuser device210a,210b,and210c.Thus, whenusers202a,202b,and202carrive at ornear return line294 withuser devices210a,210b,and210c,respectively,user devices210a,210b,and210cmay connect and/or check-in towireless beacon232 to alertmerchant employee204 throughmerchant device240 thatusers202a,202b,and202care in ornear return line294.
Oncemerchant employee204 is alerted thatusers202a,202b,and202care in ornear return line294,merchant employee204 may view user information and initiate a return process usingmerchant device240.Merchant employee204 may utilize the user information to determineuser202cis at or near the front of the line, and view additional information foruser202c,such as receipts, transaction histories, loyalty accounts or preferred customer status, fraudulent behavior, and/or prepopulated return order forms.User202cmay also perform a “wave” or alert function with user device210cto alertmerchant employee204 thatuser202cis at or near the front ofreturn line294. Oncemerchant employee204 pulls up the user and return information foruser202c,merchant employee204 may begin the return process and process a return of a purchase.
User202cbrings anitem206cwith them to return tomerchant employee204.Merchant employee204 may scanitem206cor input information foritem206cto determine the correct receipt foritem206cthatuser202cwishes to return. In other embodiments,user202cmay utilize user device210cto scan them item or may select the receipt corresponding toitem206cfrom a list of receipts presented on user device210c.Merchant employee may also usemerchant device240 to view the inventory and/or availability of item(s)/service(s) available inmerchant inventory292 to replace, service, and/orfix item206c.Thus,merchant employee204 may perform refunds, or may offer exchanges, servicing, and/or repair usingmerchant inventory292.
Asuser202aarrives at or near return line,user202amay be alerted thatuser device210ahas connected towireless beacon232 and may view options for returning items and/or services. Thus,users202aand202bmay utilizeuser devices210aand210b,respectively, to view receipts, prepopulated return order forms, and transaction histories for anitem206aand anitem206bthatuser202aanduser202b,respectively, wishes to return. Thus, prior to arriving atreturn desk290,users202aand202bmay select one or more items and/or services to return and begin accepting conditions for return, prices for return, or return order forms foritems206aand206b.Whereuser202aand/oruser202bhas established a prepopulated return order form for a purchase ofitems206aand/or206b,user202aand/oruser202bmay review the return order form, insure the accuracy of the form, and select which item(s)/service(s) for the form are to be returned. Wherereturn desk290 is fully or partially automated,users202a,202b,and/or202cmay process and/or complete the return request usinguser devices210a,210, and210c,respectively.
FIG.3 is an exemplary system environment showing a user interface of a merchant device displaying receipts and transaction histories for users checked-in to or near a merchant return line through a wireless beacon, according to an embodiment. Environment300 ofFIG.3 includes a device310, awireless beacons332, and amerchant device340 corresponding generally touser device110,wireless beacon132, andmerchant device140, respectively, ofFIG.1.
User device310 displays a wallet application interface320 corresponding generally to the processes and features described in reference towallet application120 ofFIG.1. Wallet application interface320 may display information and process used by a user (not shown) of user device310 while returning a purchase of items and/or services. Thus, wallet application interface320 includesreceipts322, user accounts324, transaction histories326, and prepopulated return forms328. Wallet application interface may display information generally or after connecting towireless beacon332.Receipts322 may be utilized by the user to view previous receipts for purchases of item(s) and/or service(s), and the receipts may be based on the identifier used by user device310 while connecting towireless beacons332. Additionally, the receipts may correspond to user accounts324, such as payment accounts or financial instruments used by the user to pay for purchases. User accounts324 may include shared accounts as well, which may be used bymerchant device340 to determine if the user is returning an item for another user. The user may view transaction histories326 that may assist the user in identifying purchases for return. Moreover, prepopulated return forms328 may also be used to determine if the user has previously generated a return form when the user completes a purchase of item(s)/service(s). The forms under prepopulated return forms328 may display information entered by the user and may be transmitted tomerchant device340.
Additionally,merchant device340 displays a returns application interface360 and a merchant applications interface350 corresponding generally to the processes and features described in reference toreturns application160 andmerchant applications150, respectively, ofFIG.1. Returns application interface360 may display information for use in initiating and processing a return by one or more users. Thus, when a device, such as user device310, connects and/or checks-in usingwireless beacon332, returns application interface360 may display information for users wishing to perform a return. Returns application interface360 includes users362 having a user A364aand a user B364b.User A364aand user B364bmay correspond to check-in information and/or an identifier for two users, a user A and a user B. Thus, in addition to the check-in information/identifier, user A364aalso shows a user history366aand receipts368a.User history366amay include a transaction history, loyalty/preferred customer benefits, and/or user behaviors, such as fraudulent behaviors, that the merchant employee (not shown) corresponding tomerchant device340 may utilize during a return process for the user A. Receipts368amay include receipts for purchases by user A, and may be utilized to initiate and process a return. Similarly, a user history366band receipts368bmay display similar information for the user B. Thus, user A364aand user B364bmay also include further information, such as prepopulated return forms, rental item return prices and transactions, etc.
Merchant applications interface350 may be utilized to assist the merchant corresponding tomerchant device340 in locating information for use in completing a refund, exchange, service, or repair of an item/service returned by the user corresponding to user device310. Merchant applications interface350 includes inventory information352 and courier information358. Inventory information352 may be utilized to determine if the merchant may exchange, service, or fix an item. Thus, inventory information352 includesitems354 and locations356.Items354 may include information of available items and/or available services, such as a stock number, delivery date, etc. Locations356 may display location information foritems354 to assist the merchant in locating the items. Moreover, in certain embodiments, the merchant may provide delivery or courier services for an exchanged, serviced, or fixed item. Thus, courier information358 may be utilized to assist the merchant in provide for delivery or courier services of the item to the user.
FIG.4 is a flowchart of an exemplary process for merchant item and service return processing using wireless beacons, according to an embodiment. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.
Atstep402, check-in information for a user is accessed when a user device for the user connects to a wireless beacon established at a merchant location for a merchant. The user device and the wireless beacon may connect using one of near field communication, radio communication, infrared communication, Bluetooth communication, Bluetooth Low Energy (BLE) communication, WiFi communication, and LTE Direct communication. In other embodiments, the check-in information may be accessed based on a connection between the user device and the wireless beacon. The merchant location may correspond to a return processing area or location, a merchant storefront, a retail location, a rental item location and/or rental item return location, or other physical place the user may return an item and/or service.
A receipt is accessed using the check-in information, atstep404, wherein the receipt comprises a transaction with the merchant. The transaction may comprise a first item or a first service sale by the merchant, such as to the user or to another user with a shared or linked account with the user. Thus, in certain embodiments where the receipt is a transaction with the merchant by another user, account information of the first user may be determined using the check-in information and the user may be associated with the other user using the account information. The account information may comprise one of a payment account with a payment provider, a credit account with the merchant, a credit or debit card, or a bank account. The account information may be linked between the two users using co-locating and/or transactions shared or processed between the two accounts. For example, the account information may comprise a first account for the user having a transaction history with a second account for the other user. Additionally, the account information may comprise an account shared by the first user and the second user. Thus, a relationship between the user and the other user may be determined and communicated to a merchant representative.
Atstep406, the receipt is communicated to a merchant representative at the merchant location. For example, the receipt may be transmitted to a merchant device for the merchant representative. In addition to the receipt, a user profile for the user may be determined using the receipt. The user profile may further be determined after accessing a transaction history of purchases by the user with the merchant, a transaction history of returns by the user with the merchant, and/or other receipts by the user with the merchant. The user profile may be used to determine fraudulent history. For example, the receipt, the transaction histories, and/or the user profile may be utilized to determine whether the user is exhibiting fraudulent behavior or a likelihood of fraudulent action by the first user.
The merchant may determine a second item or a second service for replacement of the first item or the first service in the receipt. The information for the second item/service may be communicated to the merchant representative, including a location, cost, delivery time, and/or inventory level/availability. The merchant may also offer courier services for delivery of the second item/service.
FIG.5 is a block diagram of a computer system suitable for implementing one or more components inFIG.1, according to an embodiment. In various embodiments, the user device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and service providers may be implemented ascomputer system500 in a manner as follows.
Computer system500 includes a bus502 or other communication mechanism for communicating information data, signals, and information between various components ofcomputer system500. Components include an input/output (I/O)component504 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus502. I/O component504 may also include an output component, such as adisplay511 and a cursor control513 (such as a keyboard, keypad, mouse, etc.). An optional audio input/output component505 may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component505 may allow the user to hear audio. A transceiver ornetwork interface506 transmits and receives signals betweencomputer system500 and other devices, such as another user device, service device, or a service provider server vianetwork180. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One ormore processors512, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display oncomputer system500 or transmission to other devices via acommunication link518. Processor(s)512 may also control transmission of information, such as cookies or IP addresses, to other devices.
Components ofcomputer system500 also include a system memory component514 (e.g., RAM), a static storage component516 (e.g., ROM), and/or adisk drive517.Computer system500 performs specific operations by processor(s)512 and other components by executing one or more sequences of instructions contained insystem memory component514. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s)512 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such assystem memory component514, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus502. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.
Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.
In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed bycomputer system500. In various other embodiments of the present disclosure, a plurality ofcomputer systems500 coupled bycommunication link518 to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.
Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.
Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims.