Confirmation procedure for transmitting messages to connectable processing terminals of point-of-sale devices

Abstract

A system and method are provided for a confirmation process for transmitting messages to a connectable processing terminal of a point-of-sale (POS) device. Users can transact with merchants at a POS device, such as purchasing items from a merchant at a physical store location, and using the POS device's payment terminal. An online transaction processor can provide a confirmation process to determine whether the payment terminal is online and receiving communications, allowing the user to view transaction details and complete the transaction processing. This can be achieved by locating the payment terminal's previous connection to the transaction processor via a cloud computing system and transmitting a confirmation request through that connection. If the payment terminal responds with confirmation, the transaction processor can then notify the POS device that data processing is possible.

Description

Technical Field

[0001] This application generally relates to point-of-sale (POS) devices and connectable terminal devices, and more specifically to a process for confirming the online status and message sending / receiving capabilities of a terminal device when a POS device requests it. Background Technology

[0002] Users can utilize online transaction processors to process payments between different entities through device applications and digital accounts. These online transaction processors can also provide customers and merchants with software and hardware for face-to-face transaction processing and use at merchant locations. For example, mobile applications and / or payment cards can be offered to customers, while merchants can utilize payment processing terminals, software applications, and / or software development kits (SDKs) used with POS devices to process payments through the transaction processor's transaction processing and payment network, servers, etc. These payment terminals and other physical devices that can connect to POS devices can include components and modules for local wireless data exchange and transaction processing, as well as card readers (e.g., NFC, EMV chips, and / or magnetic stripe readers).

[0003] However, using these terminal devices requires them to be powered on, have power, be online, and / or connected to a POS device for data exchange. If a terminal device is out of power or unable to connect to the network (directly or via the POS or other devices), the payment terminal may become unusable. In conventional computing systems and architectures, there is currently no process to ensure that payment terminals previously connected to a POS device remain online and available to process data from customers. Therefore, a merchant may initiate data processing requiring the use of a terminal device with the POS device, but the terminal device may not be receiving messages from the POS device and / or the backend data processing server. This results in interrupted data transmission and lost messages and communications, preventing transactions from being made or completed. Therefore, it is desirable for online transaction processors to provide merchants with real-time monitoring of the payment terminal's status and capabilities to efficiently process messages and data without losing message transmission. Attached Figure Description

[0004] Figure 1 This is a block diagram of a networking system suitable for implementing the processes described herein, according to an embodiment; Figures 2A to 2C This is an exemplary system environment in which different devices and servers interact to provide a confirmation process for message transmission, reception, and message processing, according to the embodiments; Figure 3 This is an exemplary illustration of an exchange of application programming interface (API) calls and message transmissions for a terminal device to confirm message transmission with a backend server to notify a POS or other device of the terminal device's status, according to an embodiment. Figure 4This is a flowchart illustrating an exemplary process for confirming message transmission to a connectable processing terminal of a POS device according to an embodiment; and Figure 5 It is adapted to implement according to the embodiments. Figure 1 A block diagram of a computer system containing one or more components.

[0005] The embodiments and advantages of this disclosure can be best understood by referring to the following detailed description. It should be understood that the same reference numerals are used in one or more drawings to identify the same elements, and the illustrations are for illustrating embodiments of this disclosure and not for limiting it. Detailed Implementation

[0006] A method is provided for an acknowledgment process for transmitting messages to a connectable processing terminal of a POS device. A system suitable for implementing the methods of this disclosure is also provided.

[0007] Users can utilize digital accounts, payment cards, and / or other funding sources to process payments for online transaction processors or other entities on the network via a payment and / or transaction processor network. Transaction processors may include integration with electronic payment networks (e.g., for payment cards, tokens, etc.), allowing data exchange and communication with merchant POS devices and the transaction processor and / or the merchant's payment terminal devices. Furthermore, transaction processors and networks can provide and / or utilize data communication and back-end processing server equipment that facilitates interaction with front-end merchants, POS and / or payment terminal processing devices that process transactions, including face-to-face transactions at merchant locations via payment cards and / or contactless payments. Contactless payments include Near Field Communication (NFC), Radio Frequency Identification (RFID) field and communication, Bluetooth or WiFi communication, infrared scanners and / or communication, EMV chip readers, magnetic stripe and / or analog readers, and other face-to-face and local data transmissions.

[0008] However, for customers and merchants to utilize this payment mechanism and network, payment terminal devices need to be powered on, online, and connected to the network and / or POS device to facilitate data transmission and communication. Typically, merchants may charge and turn on their devices at the start of the day or when replacing them with new or fully charged devices. Terminal devices may initially connect to the network and / or POS device, but may subsequently lose signal reception, connectivity, and / or power. When this occurs, the merchant using the device may be unaware of the problem and may therefore continue to use their POS device for data processing as if the terminal device were still online and receiving messages. This results in lost messages, wasted time when the terminal device reconnects, and / or customer frustration and wasted time (when the data entered into the terminal device is not sent, received, and processed by the POS device and / or back-end processor server).

[0009] Therefore, the transaction processor can implement a confirmation process in which, upon receiving a request to use a payment terminal device, one or more backend servers initiate a process for receiving confirmation from the payment terminal device. This process can utilize a previously established connection identifier (ID) and a connection established with the terminal device, which was established upon the initial use of the terminal device and / or during a single usage session, for example, through a bidirectional connection established using a cloud computing system associated with the transaction processor. This bidirectional connection can correspond to WebSocket (e.g., a full-duplex bidirectional connection protocol) or other connection protocols that provide bidirectional, full-duplex, or two-way communication over a single Transmission Control Protocol (TCP) connection or other similar connection. Therefore, bidirectional connections can be used in certain cloud computing environments, etc., to provide bidirectional communication between devices, servers, etc.

[0010] The connection and connection ID can be used to identify the network address or other endpoint ID used to communicate with the terminal device, so that a confirmation request or other confirmation message can be sent to the terminal device. When sending this message, a new ID, such as a context ID, can be specifically created for the POS device's request and / or confirmation request, and this ID can be stored so that the state of the terminal device can be determined later for the specific context in which the terminal device is being used. The context ID can be stored in a database, data repository or data lake, centralized or distributed data repository, cache, cloud storage system (e.g., DynamoDB for Amazon Web Services (AWS)®), or a similar data storage system accessible to the transaction processor. The transaction processor can then listen to, monitor, poll, and / or check the database to determine if the terminal device has responded, and then use that response to determine and notify the POS device of the terminal device's state.

[0011] For example, a user may wish to purchase items at a physical merchant location via face-to-face transactions, which can be facilitated by the merchant using POS devices and connectable payment terminal devices (e.g., card readers, EMV chip or magnetic stripe scanners, NFC readers / transceivers, QR code scanners, devices for interacting with mobile smartphones and applications, etc.). Selecting one or more items in a face-to-face transaction at a physical merchant location may require the user's payment tool for electronic transaction processing, which can be provided via payment cards and / or short-range wireless communication (e.g., contactless payments via NFC, RFID, etc.). In some embodiments, a user may use a digital wallet to pay for one or more transactions, the digital wallet being set up and configured to utilize contactless payment terminals and devices with a payment network, wherein the digital wallet includes an account with an online service provider or other transaction processor. A digital account with a service provider can be established by providing account details (e.g., login name, password (or other authentication credentials such as biometric fingerprints, retinal scans, etc.) and other account creation details). Account creation details may include identity information used to establish the account, such as the user's personal information, the entity's business or merchant information, or other types of identity information, including name, address, and / or other information. However, payment cards may also include a chip and / or embedded / encoded data linked to the account, including tokens or data used for token generation, etc.

[0012] When creating an account for payment and transaction processing, users may also be required to provide financial information, including digital account (e.g., credit / debit card) information, bank account information, gift card information, benefits / rewards, and / or financial investments. Account creation can also be used to establish account funds and / or value, such as by transferring funds to the account and / or establishing credit lines and corresponding credit value available for use by the account and / or card. Service providers may provide computing services to send, store, and receive funds, process financial instruments, and / or provide transaction history. Service providers may also provide data tokenization for transaction processing. Service providers' applications or websites, such as PayPal® or other online payment providers, may provide payment and other transaction processing services. Furthermore, digital accounts can be utilized through one or more mobile applications or other software applications for mobile devices.

[0013] To process and / or pay transactions (e.g., transferring or paying funds to another user, merchant, or other entity), a user may provide a digital account or source of funds at the POS device, where data from a mobile application or payment card may be read, entered, or otherwise fed into the payment terminal device, which interacts with the POS device to facilitate payment processing. For example, for face-to-face payments via contactless payment terminals and payment cards or mobile devices, identifiers and / or digital tokens or other data may authorize and / or authenticate the user's use of their digital wallet and / or payment tools (e.g., accounts with online transaction processors, credit limits with credit card providers, etc.). Data may be stored and / or transmitted by one or more storage media and / or wireless transceivers, such as NFC / RFID components, key cards, passive or active antennas, magnetic stripes or EMV chips, displayable codes or data, etc.

[0014] Payment terminal devices and other similar terminal devices may correspond to handheld and / or small device holders on which customers can view certain transaction data, make selections (e.g., confirm the transaction amount, enter loyalty information or coupons, etc.), and enter payment data, such as digital tokens, payment card chips / magnetic stripes, etc. These terminals provide customers with information from the merchant's POS device, allowing customers and merchants to conveniently view data between the two interacting devices, and further providing customers with autonomy or confidentiality when entering certain data (e.g., personal data such as phone numbers for loyalty accounts, PINs, etc.), which may be necessary for transaction processing confirmation, authentication, and / or security. Furthermore, these devices allow secure reading of payment data and its transmission to the transaction processor's backend server and / or processor for payment processing.

[0015] During the initial startup and / or use of a payment terminal device, the device can connect to the backend of a transaction processor via cloud infrastructure and / or systems, such as through a bidirectional connection or similar auxiliary connection using a cloud system (e.g., AWS) used by the transaction processor. The transaction processor can use the cloud system to manage numerous different bidirectional connections with merchant POS devices and payment terminal devices, and store and manage data during interactions with these devices. In this regard, establishing this connection generates a connection ID for the bidirectional connection established using the cloud system. This connection ID can be stored in an accessible database and used to identify the connection and / or the network address of the terminal device used for communication transmission. Therefore, from the initial network connection, handshake, and connection establishment, the connection ID can be used to identify the device and the corresponding connection to that device.

[0016] Therefore, when a merchant or other entity wishing to use the terminal device initiates a request to use it (through a bidirectional connection in a cloud computing environment, such as through a merchant's POS device), a request can be sent from that POS or other device to a transaction processor (e.g., via the Internet or other networks between devices). This request may correspond to a transaction processing request, such as an API call and / or request with a data payload including transaction data of the transaction being processed at the POS device. The transaction processor or other online service provider may receive the request and create an ID, such as a "context" ID, that uniquely identifies the request and the specific context of the API call and request. This context ID may be stored in a database along with the transaction data or other data payload of the request, the POS device ID, the merchant ID, and / or other data. For example, for a specific transaction, a unique context ID (e.g., a generic or globally unique ID (UUID or GUID)) that uniquely identifies that specific transaction to the transaction processor may be created and provided to other devices to associate further interactions with that transaction. In other embodiments, other types of computational activity and / or interaction may be identified by the context ID, such as messages requiring read receipts or acknowledgments, firmware update requests, and / or statuses.

[0017] The transaction processor can then create a message and / or an acknowledgment request for the message / communication to be transmitted to the payment terminal device. This can be generated using a context ID and can include the context ID along with a request or command / procedure that causes the terminal device to respond to the transaction processor with an acknowledgment of receipt of the request and / or message. The request and / or message can be transmitted to the terminal device using a previously established connection (e.g., a bidirectional connection) currently open with the terminal device in a cloud computing environment, which can be identified using a connection ID. For example, the connection ID is used to obtain a network address and is used to transmit the request / message to and communicate with the terminal device. Therefore, the request / message can be transmitted to the terminal device via a connection previously established using the connection ID and a corresponding network address generated from the connection establishment and stored in a database.

[0018] While transmitting messages, the transaction processor may further establish, create, initiate, or otherwise initiate processes for listening to, polling, tracking, inspecting, and / or monitoring incoming messages, events, etc., from the terminal device. Monitoring and determining whether a message / event has been received or detected may be limited to a period of time, after which the transaction processor may determine that the terminal device is unresponsive and therefore has a problem (e.g., no power, no connection, no internet, damaged, or disabled, etc.). Therefore, incoming messages or events may correspond to acknowledgments, which subsequently indicate that the terminal device is online and / or receiving and acknowledging messages and requests, thereby identifying the terminal device as "online," "ready," or "available." However, if no acknowledgment is received at the end of the time period, the terminal device may be identified as unacknowledged and therefore "offline," "unknown," or "unavailable."

[0019] Therefore, a request / message from the transaction processor can cause the payment terminal device (if received) to respond with a message and / or acknowledgment (e.g., via an API call) confirming receipt of the request / message from the transaction processor, thereby indicating that the terminal device is online and available to receive and / or process data. If received, the terminal device can then respond with an acknowledgment and a context ID, which can be provided via a connectivity and cloud computing system. When an acknowledgment is received, it can be stored (e.g., in a database, cloud storage, cache, etc.) and associated with the context ID to record the acknowledgment. The acknowledgment process can be monitored, periodically polled, or otherwise checked in a database, data store, cache, or other storage, which includes tables for the context ID and received messages, acknowledgments, and / or activities using the context ID. Monitoring, polling, or other checks can be performed using lookups or queries on the context ID to determine if an acknowledgment has been received and stored. If so, the transaction processor can then use the context ID to respond to the POS device to inform the terminal device that it is online, or otherwise notify and / or update the POS device on the terminal device's online and available status. However, if no confirmation is received by the end of the time period, the transaction processor may notify, update, and / or provide the POS device with the status of the terminal device when the time period expires, specifying the terminal device as offline or unavailable.

[0020] In the aforementioned process, environment, and computing and communication architecture, payment terminal devices (such as card readers or device readers) are pinged and checked for availability to process electronic transactions for face-to-face transactions at the POS device. Therefore, when a transaction is entered and / or initiated at the POS device, the POS device can receive status updates and / or notifications regarding the availability and connectivity of the terminal device. This allows the POS device to rely on the terminal device to receive payment data and details from customers or other users opposite the merchant at the POS device during a transaction, for example, by allowing users to enter and read payment cards, scan mobile smartphones and / or connect to a mobile phone to receive / exchange payment data or tokens, or otherwise allow the entry of payment data. Furthermore, once online and available, the POS device can provide users with information and payment processing flows, which can be used to display the total transaction amount and / or items, request users to enter payment instruments and / or loyalty data and coupons, and / or provide users with transaction processing results. However, if detected as unavailable or offline, the merchant can subsequently rotate to a new terminal device connected to the POS device to reduce time and errors during data processing at the terminal and / or with the user, thereby ensuring message exchange.

[0021] In other embodiments, the aforementioned process can also be used in other environments and for other devices and systems that require status checks and updates, as well as confirmation of availability and / or message reception and acknowledgment. For example, a similar process can be used by a device requiring a firmware update, which may be initiated by another device and requires a backend service provider and / or firmware update service to perform the update. For example, in such an embodiment, a payment terminal device may correspond to the same or other auxiliary device (e.g., a mobile smartphone, device accessories (e.g., headphones, smartwatches, etc.), a local router, etc.) requiring a firmware update. Another primary device (e.g., the user's or merchant's main computing device (e.g., a POS device, desktop computer, mobile smartphone, etc.)) may initiate a firmware update, but may need to determine that the auxiliary device is online and available, and confirm that the firmware update has been completed.

[0022] Therefore, the process of obtaining confirmation and tracking the status of auxiliary devices can be used similarly. This can also be used in messaging systems that require or provide confirmation of messages that have been transmitted between devices and / or facilitated by a backend server. In such embodiments, the messaging system can be used for emergency messaging services that allow identification of device availability and confirmation that messages have been received, and can also be used for messaging between devices and users who may wish to obtain confirmation of message reception.

[0023] In this way, transaction processors or other service providers can check and ensure device connectivity and availability, making message sending and receiving and data processing more reliable with fewer interruptions and data loss. This ensures message and data exchange, enabling data processing with fewer errors and the possibility of lost data and / or input. Furthermore, these operations provide a faster and more efficient way to detect device availability and online status, allowing customers, merchants, and other users or entities to ensure device reliability during data processing. Therefore, the system provides a coordinated and efficient way of transmitting and exchanging messages to confirm message reception and device status, thereby improving the electronic processing of transactions.

[0024] Figure 1 This is a block diagram of a networking system 100 suitable for implementing the processes described herein, according to embodiments. As shown, system 100 may include or implement multiple devices, servers, and / or software components that operate to perform various methods according to the described embodiments. Exemplary devices and servers may include devices, standalone and enterprise-class servers running operating systems such as MICROSOFT® OS, UNIX® OS, LINUX® OS, or other suitable device- and / or server-based OSs. It will be understood that... Figure 1 The devices and / or servers shown may be deployed in other ways, and the operations performed and / or services provided by such devices and / or servers may be combined or separated for a given embodiment, and may be performed by more or fewer devices and / or servers. One or more devices and / or servers may be operated and / or maintained by the same or different entities.

[0025] System 100 includes a point of sale (POS) 110, a reader 120, and a transaction processor 130 communicating via a network 150. The POS 110 can be used by a merchant or merchant employee to initiate a transaction and process payment for that transaction using the reader 120, which facilitates transaction review and acceptance, as well as payment data input by customers or other users. In this regard, as a transaction is processed, the transaction data is provided to the transaction processor 130 via a transaction network (which is accessible via network 150). The POS 110 can utilize a digital wallet provided by the reader 120 to process transactions via payment cards, mobile devices, contactless payment systems, etc., through the reader 120, face-to-face and / or via wireless communication and communication protocols. The transaction processor 130 can provide a process for identifying whether the reader 120 is online or offline, which can be used to provide status information to the POS 110.

[0026] POS 110, reader 120, and transaction processor 130 may each include one or more processors, memory, and other appropriate components for executing instructions (such as program code and / or data stored on one or more computer-readable media) to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer-readable media within and / or external to various components of system 100 and / or accessible via network 150 in memory or data storage devices.

[0027] POS 110 can be implemented using any suitable hardware and software, and is configured to communicate wired and / or wirelessly with user devices (e.g., mobile smartphones, wearable devices, tablets, personal computers, etc.), payment terminals including reader 120, contactless payment transceivers and devices, and / or transaction processor 130 to process transactions. POS 110 may correspond to a merchant processing payments and sales through an executable software application that can utilize a payment network associated with transaction processor 130. In various embodiments, POS 110 may be implemented as a specific merchant cash register and / or payment processing device, a personal computer (PC), a smartphone, a laptop / tablet, a watch with suitable computer hardware resources, other types of wearable computing devices, and / or other types of computing devices capable of sending and / or receiving data. Although only one computing device is shown, multiple computing devices can operate similarly.

[0028] Figure 1 The POS 110 includes a sales application 112 and a network interface component 118. The sales application 112 may correspond to an executable process, procedure, and / or an application with associated hardware. In other embodiments, the POS 110 may include other or different modules (as needed) with dedicated hardware and / or software.

[0029] Sales application 112 may correspond to one or more processes that execute the software modules and associated components of POS 110 to provide merchants with features, services, and other operations for processing transactions at merchant locations (e.g., physical stores, retail locations, etc.), using reader 120 to facilitate customer interaction, and using transaction processor 130 to process payments. In this regard, sales application 112 may correspond to dedicated software used by users of POS 110, which can be used to provide a convenient interface for entering transaction data and requesting transaction processing. In some embodiments, sales application 112 may provide a browser process and / or correspond to a browser application that can access websites or applications (e.g., mobile applications, rich internet applications, or resident software applications) that can display one or more user interfaces that allow transaction processing and interaction with the computing services of reader 120 and transaction processor 130. Therefore, sales application 112 may correspond to a general-purpose browser application configured to acquire, present, and communicate information via the Internet (e.g., utilizing resources on the World Wide Web) or a private network. However, in other embodiments, the sales application 112 may include a dedicated application corresponding to a merchant, reader 120, transaction processor 130, or other entity, which may similarly provide such an interface to utilize the transaction processing services through reader 120 and transaction processor 130.

[0030] Sales application 112 may be associated with merchant account information, financial information, and / or transaction history including receipt data. When sales application 112 is used in conjunction with transaction processor 130, sales application 112 may request processing of transaction 113, such as a payment request and / or data transfer of payment data facilitated by reader 120 for payment processing. For example, a payment request for transaction 113 generated by POS 110, or other interactions may correspond to using sales application 112 to request, establish, and / or process transactions for payment. When transaction 113 is generated, a request may be sent to transaction processor 130 to determine status 146, “wake up,” activate, connect, and / or push or provide transaction data to reader 120. Therefore, transaction processor 130 may respond with context ID 144, which uniquely identifies the context of transaction 113 and / or the interaction, to process transaction 113 and determine the status of reader 120 during payment processing.

[0031] Transaction processor 130 can then perform operations and messaging to determine the status of reader 120, as discussed herein. POS 110 may include a list of connected devices 114, which identify reader 120 as connected. Once the status 146 of reader 120 is determined, it can be provided to POS 110 and viewed through sales application 112. If it is determined that reader 120 is online and available for payment processing, the customer can provide payment data 115 through reader 120. For example, a payment card can be read or scanned, or a token can be transmitted wirelessly, such as via short-range wireless communication to reader 120 using a contactless payment protocol. Sales application 112 can use payment data 115 to process transaction 113 with transaction processor 130, and can return a result 116 of payment and transaction processing, such as whether the payment was approved or rejected for transaction 113. Subsequently, sales application 112 can be used to view the result 116 of transaction processing through one or more interfaces, as well as to print it on a receipt, transmit it to another device including reader 120, etc.

[0032] In various embodiments, POS 110 includes other applications, such as those that may be desired in a particular embodiment, to provide features to POS 110. For example, other applications may include security applications for implementing client security features, programmatic client applications for interacting with appropriate APIs via network 150, or other types of applications. Other applications may also include email, SMS, voice, and instant messaging (IM) applications that allow users to send and receive emails, phone calls, texts, and other notifications via network 150. In various embodiments, other applications may include financial applications, such as banking applications.

[0033] Other applications may include location detection applications for determining location, such as maps, compasses, and / or GPS applications, which may include a dedicated GPS receiver for determining the location information of the POS 110. Other applications may include device interface applications and other display modules that can receive input from and / or output information to the user. For example, other applications may include software programs executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user. Other applications may therefore utilize components of the POS 110, such as display devices and other output devices capable of displaying information to the user, including speakers.

[0034] POS 110 may further include databases, caches, etc., stored on transient and / or non-transient storage of POS 110, or may utilize cloud-based storage, server databases or caches, or other internal or external data storage systems, which can store various applications and data and be used during the execution of various modules of POS 110. The database may include, for example, identifiers such as operating system registry entries, cookies associated with sales application 112 and / or other applications, identifiers associated with the hardware of POS 110, or other suitable identifiers, such as identifiers used for payment / user / device authentication or identification, which may be transmitted to transaction processor 130 to identify the user / POS 110.

[0035] POS 110 includes at least one network interface component 118 adapted to communicate with reader 120, transaction processor 130, and / or other devices and servers via network 150. In various embodiments, network interface component 118 may include a DSL (e.g., Digital Subscriber Line) modem, PSTN (Public Switched Telephone Network) modem, Ethernet device, broadband device, 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.

[0036] The reader 120 can be implemented using any suitable hardware and software, configured for wired and / or wireless communication with a user device, and may be connected to or connectable to merchant devices, including POS devices such as POS 110 and cash registers, for processing transactions. The reader 120 can be used by merchants and / or merchant employees processing payments and sales at physical merchant locations. In various embodiments, the reader 120 can be implemented as a personal computer (PC), a payment terminal device with payment processing components, a smartphone, a laptop / tablet, a watch with suitable computer hardware resources, other types of wearable computing devices, and / or other types of computing devices capable of sending and / or receiving data. Although only one device is shown, multiple devices can operate similarly.

[0037] Figure 1 The reader 120 includes a reader application 122 and a network interface component 128. The reader application 122 may correspond to an executable process, procedure, and / or application with associated hardware. In other embodiments, the reader 120 may include other or different modules (as needed) with dedicated hardware and / or software.

[0038] Reader application 122 may correspond to one or more processes for executing software modules and associated components of reader 120 to provide features, services, and other operations for payment processing via network 150 to POS 110 and transaction processor 130. Transaction and payment processing may include receiving payment data 115, etc., from customers and other users, which is used to process transaction 113 and / or other transactions directly with POS 110 and / or via network 150 to transaction processor 130. In this respect, reader application 122 may correspond to dedicated software that displays one or more user interfaces to customers and other users, allowing input of data for payment processing. Reader application 122 may include payment operations that can be used to process payments with users. For example, payment operations may be used to receive transactions for the purchase of one or more goods or services (e.g., data for transaction 113) and present such data to customers or other users. In this respect, transaction data may correspond to transaction details that are presented for review and / or approval, for example, where POS 110 may provide information about transaction 113 to reader 120 directly or via network 150. In some embodiments, reader application 122 may also facilitate data input for transaction 113, such as receiving item or service input and selection via item scanning, menu or interface selection and input, receiving transactions or orders from another device or server, etc. Payment operations may further request payment for the transaction, which may be provided using cash and merchant input, checks and merchant input and / or check readers, payment cards or gift cards using card readers (e.g., magnetic stripe readers, EMV or RFID chip readers, etc.), and / or contactless payment terminals and components for mobile application payments from mobile devices (e.g., via NFC, RFID, QR code scanning, etc.). Reader application 122 may process transaction and / or payment requests using payment data from one or more contactless payment devices, terminals, transceivers, etc., and merchant inputs (e.g., cash or check transactions). Payment operations for inputting, receiving, and processing transaction and payment data may utilize terminal components, short-range transceivers, and / or network interface components 128. Subsequently, the reader application 122 can be used to view the results of transaction processing through one or more interfaces, which may include receipts or other transaction history.

[0039] To determine the status of reader 120, such as whether reader 120 is active, functioning properly, powered on, online, and / or available for transaction and payment processing, transaction processor 130 may implement a confirmation process that requires confirmation of requests or other messages sent by transaction processor 130 to reader 120. For example, reader application 122 may initially establish connection 123, which may correspond to one or more connections established upon activation, startup, and / or use, facilitating data processing of transaction and / or customer payment data by reader 120 in conjunction with POS 110 and / or other devices. Connection 123 may correspond to a bidirectional connection established via a cloud computing system or environment, and corresponds to a bidirectional interactive communication session between a client (e.g., an application or browser, such as reader application 122) and a server (e.g., a backend AWS server or other cloud-based server), established via a handshake and negotiated connection protocol for message requests and responses. The cloud computing environment may be provided and / or utilized by the transaction processor 130 for communicating with the reader 120 and other readers, payment terminal devices, etc., for connection creation, maintenance and logging, including storing and maintaining various connection IDs to identify connections established with different terminal devices, etc. through the cloud computing environment.

[0040] Therefore, connection 123 includes server connection data 124, which may correspond to a connection, communication channel, bidirectional messaging process, etc., connecting reader 120 to transaction processor 130 and / or applications and servers in the cloud computing environment used by transaction processor 130. When a request for confirmation or other message is sent to reader 120 to identify the state 146 of reader 120 during transaction processing 113, context ID 144 may be received along with the request. If reader 120 is active, online, and available, confirmation 125 may be generated, which may be transmitted back to transaction processor 130 for processing. This process then allows POS 110 to continue transaction processing, where payment data 115 can be processed using payment processing component 126.

[0041] In various embodiments, reader 120 includes other applications, such as those that may be desired in a particular embodiment, to provide features to reader 120. For example, other applications may include security applications for implementing client security features, procedural client applications for interacting with appropriate application programming interfaces (APIs) via network 150, or other types of applications. In various embodiments, other applications may include financial applications, such as banking applications for payment processing. Other applications may include device interface applications and other display modules that can receive input from and / or output information to a user. For example, other applications may include software programs executable by a processor, including a graphical user interface (GUI) configured to provide an interface to a user. Other applications may therefore utilize terminal components of reader 120, such as display devices and other output devices capable of displaying information to a user, including speakers.

[0042] The payment processing component 126 of reader 120 can be used to provide additional functionality and assist in transaction and payment processing, as well as to provide digital receipts, including local transmission of digital receipts via short-range wireless communication without using or requiring a contact identifier from the user. In this regard, payment processing component 126 may include a data reader, barcode scanner, transceiver, etc., which can be configured to read data from payment cards, gift cards, mobile devices, key cards, etc. Data read from such devices may include payment data; therefore, the data reader may include a magnetic stripe reader, EMV chip reader, NFC card or key card device reader, etc. Payment processing component 126 further includes a display configured to output and display data to users and / or merchants. The display can be used during transaction processing to display transaction processing inputs, results, etc. This may include transaction details for review and confirmation, payment data input prompts, etc. In this regard, payment processing component 126 further includes input components, such as buttons, keyboards, mice, touchscreen interfaces, etc., which enable the aforementioned inputs and selections.

[0043] The reader 120 includes a short-range transceiver adapted to communicate with the POS 110 and / or other nearby devices, transceivers, and / or components via short-range wireless signal transmission and communication, including NFC communication, RFID communication, Bluetooth, WiFi, infrared scanners, and / or communicators. In various embodiments, the short-range transceiver may correspond to microwave, RF, infrared, Bluetooth, and NFC devices and components. The reader 120 may also communicate with and / or read data from quick-response (QR) codes, barcodes, and other scannable and / or readable codes for short-range wireless data exchange, which may utilize display components, cameras, infrared scanners, etc. The reader 120 further includes at least one network interface component 128 adapted to communicate with the POS 110, transaction processor 130, and / or other devices and servers via a network 150. In various embodiments, the network interface component 128 may include a WiFi component, 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.

[0044] Transaction processor 130 may be maintained, for example, by an online service provider, which provides processes for processing transaction payments to provide services to merchants, users, and accounts, as well as providing additional computing services. In this regard, transaction processor 130 includes one or more processing applications that can be configured to interact with POS 110, reader 120, and / or another device / server to facilitate communication and transactions between users. Transaction processor 130 may be maintained by or include another type of platform or service provider, such as a transaction processor from PAYPAL® Inc. of San Jose, California, USA. Although transaction processor 130 and reader 120 are discussed as separate devices and servers, in some embodiments, one or more of the described processes may be provided by other devices or servers, or by the same device or server.

[0045] Figure 1 The transaction processor 130 includes a reader connectivity platform 140, a transaction processing application 132, a database 134, and a network interface component 138. The reader connectivity platform 140 and the transaction processing application 132 may correspond to executable processes, procedures, and / or applications with associated hardware. In other embodiments, the transaction processor 130 may include other or different modules (as needed) with dedicated hardware and / or software.

[0046] The reader connectivity platform 140 may correspond to one or more processes for executing modules of the transaction processor 130 and associated dedicated hardware to facilitate connectivity between readers and other terminal devices, thereby determining which readers are available to process transactions for items at the POS 110 and / or other devices for merchants and merchant locations. In this regard, the reader connectivity platform 140 may correspond to dedicated hardware and / or software used by merchants and provided by the transaction processor 130 and / or other service providers for determining the status of readers 120 and / or other terminal devices. The reader connectivity platform 140 can therefore monitor the status of readers 141, which may include readers 120 and correspond to those readers that may be connected to and / or can be connected to different POS devices and are connected or can be connected to the transaction processor 130 via a network or internet connection (e.g., via bidirectional connectivity on a cloud computing system and environment).

[0047] Initially, when reader 120 is powered on and / or used to connect to POS 110 and / or process transactions with POS 110, reader connection platform 140 may establish connection ID 142 to uniquely identify reader 120 and the connection established with reader 120. This ID may include and / or correspond to a network address used for communicating with the reader through the connection. This connection may correspond to a bidirectional connection established on AWS, etc., and connection ID 142 may identify this connection. Furthermore, connection ID 142 and / or this connection may facilitate communication between POS 110 and reader 120, for example for transaction processing, by routing communication on network 150 using WebSocket or other connections, which allows data to be populated onto reader 120 for transaction 113, and further allows reader 120 to receive payment data 115 and provide it to transaction processor 130 for processing transaction 113. Connection ID 142 can be stored in a database, such as database 134, or a cloud storage database, server database or cache, or other internal or external data storage system, which can then be accessed and used for later communication with reader 120. Subsequently, when a POS transaction request 143 for transaction 113 is received from POS 110, reader connection platform 140 can generate a context ID 144 to uniquely identify the interaction and the context of the request from POS 110. Context ID 144 can therefore be linked to POS 110 and transaction 114 for use in POS transaction request 143.

[0048] The reader connection platform 140 can then determine the status 146 of the reader 120, such as offline and unavailable or online and available, for receiving and processing payment data 115. In this regard, a message 145 can be generated to probe for confirmation requests or send messages to the reader 120 to send back messages or other confirmations indicating that the reader 120 is online and available. The message 145 can thus identify the reader 120 and include a context ID 144 so that received confirmation is tracked along with the POS transaction request 143 and identifies the status 146 of the reader 120 to the POS 110 when processing transaction 113. The message 145 can be transmitted to the reader 120, for example, by using the connection ID 142 to look up or determine the reader 120's network address and / or connection to the transaction processor 130 via network 150 and / or cloud computing environment. The context ID 144 can also be stored in a cloud-based storage database 134 for tracking the message 145 and processing transaction 113, and for determining whether the reader 120 confirms the message 145.

[0049] Processes, operations, or polling events can be set and established such that the reader connection platform 140 can wait for an acknowledgment 125 from the reader 120 for a period of time. For example, when the reader 120 responds with an acknowledgment 125, the acknowledgment 125 can be sent via the connection to a cloud computing system, where a cloud processor can process and store the acknowledgment associated with context ID 144. Therefore, the process can monitor acknowledgments 125 from the reader 120, which may include polling, listening, and / or checking the acknowledgments 125 already stored and / or processed in the corresponding database associated with context ID 144. If an acknowledgment is received within the time period, status 146 can be updated to reflect that the reader 120 is online and / or available. However, if the time period expires and an acknowledgment is not received and / or detected as stored associated with context ID 144, status 146 may reflect that message 145 was not acknowledged and the reader 120 is offline and / or unavailable. Examples of such identifiers, components, and operations for determining reader availability will be referenced below. Figures 2A to 4 Further discussion.

[0050] Transaction processing application 132 may correspond to one or more processes for executing modules of transaction processor 130 and associated dedicated hardware to process transaction 113 and / or provide another service to customers, merchants, and / or other end users and entities of transaction processor 130. In this respect, transaction processing application 132 may correspond to dedicated hardware and / or software used by transaction processor 130 for providing computing services to users, which may include electronic transaction processing and / or other computing services, such as services associated with determining the status of payment terminal devices. In some embodiments, transaction processing application 132 may be used by users to establish user and / or payment accounts and digital wallets, which can be used to process transactions. Accounts can be accessed and / or used through one or more instances of web browser applications and / or dedicated software applications, and participate in the computing services provided by transaction processing application 132. Transaction processing application 132 may also, or alternatively, correspond to messaging, social networking, media publishing or sharing, microblogging, data browsing and searching, online shopping, and other services available through transaction processor 130.

[0051] Transaction processing application 132 may receive transaction data for transaction 113 processed using an account accessible via POS 110 and / or other devices or servers. Transaction processing application 132 may determine whether transaction 113 complies with spending limits, rules, permissions, risks, etc., used to process transaction 113. If so, the transaction may be approved or authorized. However, if the transaction does not comply with spending limits or exceeds the risks used to approve electronic transaction processing and / or credit / balance limits, transaction processing application 132 may refuse transaction processing or instruct a back-end credit processor to refuse processing the transaction. Transaction 113 may be processed using payment data 115, and a result 116 may be provided based on this processing. Furthermore, transaction processing application 132 may transmit a message including the result 116 to POS 110 and / or another device to notify the user of the approval or rejection of transaction 113.

[0052] In various embodiments, additional applications may be required in certain embodiments to provide features to the transaction processor 130. For example, other applications may include security applications for implementing server-side security features, programmatic client applications for interacting with appropriate application programming interfaces (APIs) via network 150, or other types of applications. Other applications may comprise software programs executable by the processor, including graphical user interfaces (GUIs) configured to provide an interface to a user when the user accesses the transaction processor 130 via one or more of the POS 110, wherein the user or other users can interact with the GUI to more easily view and communicate information. In various embodiments, other applications may include additional connectivity and / or communication applications that can be used to communicate information via network 150.

[0053] In addition, transaction processor 130 includes or has access to database 134 or other types of data storage systems and / or components. Database 134 may correspond to a single or distributed database, cloud-based storage, cache, or other internal or external data storage system. Database 134 may store various identifiers associated with POS 110. Database 134 may also store account data, including payment instruments and authentication credentials, as well as transaction processing history and data of processed transactions. Database 134 may store received data associated with users, such as transaction data used for electronic transaction processing. Furthermore, database 134 may be used to store reader IDs 136, such as connection and context IDs. Although database 134 is described as an internal database, cache, or other data storage system, database 134 may also be accessible from external and / or cloud-based systems. Therefore, in some embodiments, database 134 may be provided by another platform and accessible to store and look up connection and context IDs, such as cloud-based data storage systems (e.g., data lakes or repositories, where data may be streamed, stored, and / or processed for use by different customers, tenants, and other associated entities of a cloud computing system).

[0054] In various embodiments, the transaction processor 130 includes at least one network interface component 138 adapted to communicate with the POS 110, reader 120, and / or another device / server via the network 150. In various embodiments, the network interface component 138 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 (RF), and infrared (IR) communication devices.

[0055] Network 150 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network 150 may include the Internet or one or more intranets, terrestrial networks, wireless networks, and / or other suitable types of networks. Thus, network 150 may correspond to a small-scale communication network, such as a private or local area network, or a larger-scale network, such as a wide area network or the Internet, accessible by various components of system 100.

[0056] Figures 2A to 2C These are exemplary system environments 200a-200c, which are based on different devices and servers interacting to provide a confirmation process for message transmission, reception, and message processing. Figures 2A to 2C System environments 200a-200c correspond to the operational flow and data communication between devices, servers, and systems when interacting to detect the status of a terminal device being requested to process data by the primary device. (See reference...) Figure 1The system 100 discusses the interaction between the POS 110, the reader 120, and / or the transaction processor 130.

[0057] exist Figure 2A In system environment 200a, an interaction for detecting the availability of a payment terminal device (e.g., reader 120) during payment processing (e.g., processing a transaction for a fee using payment data entered at the terminal device). Starting at interaction 1, POS 110 requests a fee from the reader service POS API 202, which may correspond to a publicly exposed API of a service provider (e.g., a transaction processor). For example, when processing a transaction, POS 110 may utilize the reader service POS API 202 to exchange API calls to the transaction processor, which is necessary for processing transactions using electronic transaction processing services provided by reader 120 and the transaction processor (e.g., different applications, decision-making and / or microservices, artificial intelligence (AI) models and engines, including machine learning (ML) models and / or neural networks (NN)). The reader service POS API 202 may correspond to a GraphQL API (e.g., an API encoded using GraphQL as a data query and manipulation language), which may utilize GraphQL to exchange API calls. This allows API requests and other query calls to the Reader Service POS API 202 to utilize GraphQL, which allows POS 110 and / or other devices to specify the data returned from the Reader Service POS API 202. However, other syntaxes and languages ​​are also available for the Reader Service POS API 202.

[0058] At interaction 2, an unconfirmed context is created in cloud computing environment 204, such as in database 206, which may have a copy 208 generated in the cloud and / or in the transaction processor when utilizing cloud computing environment 204. The unconfirmed context may correspond to a context ID specifically identifying interaction 1, the requested charge, and / or the corresponding transaction. A context ID may be generated and stored in database 206 and / or copy 208 to track transaction processing and specifically to track whether reader 120 identifies itself as online (or in other ways indicating a good working status and availability) in response to a confirmation request. Database 206 and / or copy 208 may correspond to Amazon DynamoDB®, such as AWS available for cloud computing environment 204, for example, for NoSQL databases and key-value data stores. However, other databases and database types may also be used.

[0059] At interaction 3, a confirmation request is sent from the Reader Service POS API 202 to the Reader 120, which may correspond to a request to display a charge on the Reader 120 (e.g., initiating transaction processing by displaying the charge amount, item, transaction information, etc.). This request and / or charge can be sent by looking up a previous WebSocket or other connection, for example, by using a connection ID previously used to establish and / or create a connection, which is stored by the Reader Service POS API 202 when the Reader 120 connects to the Reader Service POS API 202, for example, by using a cloud computing environment 204. Therefore, the connection ID can be stored in a database 206 and / or a copy 208, which allows for looking up previously established bidirectional connections, etc., during the wake-up, connection, activation, and / or use of the Reader 120 and POS 110.

[0060] The request and / or charge may be accompanied by a context ID and may request and / or require reader 120 to respond with confirmation, thereby confirming availability. Simultaneously and / or over a period of time, at interaction 4, reader service POS API 202 may establish a confirmation process for detecting confirmations from reader 120. This process may correspond to a process in which reader service POS API 202 polls, monitors, checks, and / or listens for confirmations from reader 120, which may therefore be created or initiated at reader service POS API 202 and / or with cloud computing environment 204.

[0061] At interaction 5, reader 120 can receive a charge display request and / or confirmation request with a context ID, and can perform actions to display a charge screen and / or interface with transaction details to the customer or other user. This provides the total charge amount for the transaction and instructions on how to conduct the transaction. Reader 120 can further respond with a confirmation of the context ID to reader service reader API 210 at interaction 6. This API may correspond to another API of the transaction processor or other service provider, configured to interface with readers and other payment terminal devices and exchange API calls for status determination. This could also be a GraphQL API or an API constructed using another query language for querying and / or calling. Therefore, confirmation can be provided to reader service reader API 210 to identify reader 120 as online and available for processing charges and transactions using payment instruments. Reader 120 can then be used to read payment instrument 212 for charging and transaction processing.

[0062] At interaction 7, the Reader Service Reader API 210 can store confirmations from Reader 120 in database 206 and / or copy 208 of the cloud computing environment 204, and associate them with a context ID, for example, by writing the confirmation to the corresponding database with the context ID. Therefore, during interaction 8, polling events or other confirmation processes performed by the Reader Service POS API 202 can return a positive result by monitoring, polling, or listening for confirmations received associated with the context ID within a time period (e.g., by detecting confirmations stored for the context ID). The Reader Service POS API 202 can thus receive the confirmed context, which can indicate that Reader 120 is online. At interaction 9, the Reader Service POS API 202 then responds to POS 110 with the confirmed context, for example, by responding to POS 110 with a status update or notification indicating that Reader 120 is online. This confirmed context to POS 110 can include a context ID so that POS 110 can use the context ID to track billing and transaction processing.

[0063] exist Figure 2B In system environment 200b, an interaction for detecting the availability of a firmware update performed by an auxiliary device (e.g., reader 120) based on a request from a primary device is illustrated. The interaction in system environment 200b can be performed similarly to the interaction in system environment 200a, but is related to performing a firmware update at reader 120 or other auxiliary devices upon request from POS 110 or other primary devices. Therefore, calls to similar GraphQL APIs, DynamoDB, cloud computing environments, and / or exchanges, or other similar embodiments of such APIs, databases, and API calls, can be used. The interaction in system environment 200b can be used to enable the primary device to detect when a firmware update has actually started and / or when a firmware update is completed on the auxiliary device, which is normally unknown or opaque. Therefore, during a regular firmware update process, the primary device may not know when the auxiliary device has updated and new firmware is available. In contrast, the interaction in system environment 200b facilitates this determination and information acquisition by the primary device to allow continued use based on the state of the auxiliary device. In system environment 200b, the main device can correspond to POS 110, and the auxiliary device can correspond to reader 120.

[0064] In system environment 200b, POS 110 requests a firmware update for reader 120 at interaction 11, for example, in a manner similar to requesting payment at reader 120. Therefore, the reader service POS API 202 can be invoked via API calls and exposed public APIs, which allows devices to invoke such services and systems to determine status and perform a firmware update for reader 120. In this regard, reader service POS API 202 creates an unconfirmed context at interaction 12 using database 206 and / or copy 208, for example, by creating and / or storing a context ID for the firmware update in database 206 and / or copy 208 in cloud computing environment 204. In a similar manner, the Reader Service POS API 202 further requests a firmware update with a context ID from the Reader 120 at Interaction 13. This causes the Reader Service POS API 202 to create and / or initiate a confirmation process at Interaction 14 for polling or otherwise monitoring and inspecting the cloud computing environment 204 (and specifically monitoring and inspecting the database 206 and / or replica 208) and the corresponding confirmation.

[0065] At interaction 15, reader 120 initiates or sets out a firmware update, thereby confirming that reader 120 is online, active, and performing a firmware update, ensuring that the firmware update will continue. In response to initiating and / or performing a firmware update, reader 120 provides context confirmation to reader service reader API 210, for example by responding with an confirmation and a context ID, so that at interaction 17, reader service reader API 210 provides the updated context state (e.g., firmware update has started and / or is in progress) to cloud computing environment 204 for storage by database 206 and / or replica 208.

[0066] At interaction 18, the Reader Service POS API 202 can then detect that an acknowledgment for the context ID has been received, and thus determine that Reader 120 is updating its firmware. Subsequently, at interaction 19, the Reader Service POS API 202 can notify POS 110 that the firmware update is in progress, thus the status of Reader 120 is "updating," indicating that Reader 120 is temporarily unavailable during the update. At interaction 20, Reader 120 can complete the firmware update and respond to the Reader Service Reader API 210 with an "update complete" status. The update status of Reader 120 can be accompanied by the context ID for status tracking, which allows the Reader Service Reader API 210 to provide the updated context status to the cloud computing environment 204 at interaction 21 for association with the context ID and storage in database 206 and / or copy 208. This allows the Reader Service POS API 202 to receive a new status for the Reader 120 from the confirmation process at interaction 22, indicating that the Reader 120 has completed the update and is online or available again, and has been updated. At interaction 23, the Reader Service POS API 202 then responds to POS 110 with the new status of the Reader 120, such as the firmware being updated and the Reader 120 being online or available.

[0067] exist Figure 2C In system environment 200c, an interaction is illustrated for detecting message reception by a receiving device (e.g., reader 120) when a message is sent by a sender device (e.g., POS 110) using a service provider server (e.g., transaction processor 130). System environment 200c illustrates an interaction executable so that a first device receives the status and acknowledgment (e.g., receiving a read receipt) of the sent message. This can be used for communication and / or messaging systems between users, as well as urgent or other device-to-device interactions requiring message acknowledgment. Therefore, system environment 200c includes a first device 240 and a second device 250, wherein the first device 240 may correspond to POS 110 and the second device 250 may correspond to reader 120.

[0068] In system environment 200c, first device 240 includes interface 242 at which a message 243 is input and transmitted to second device 250, the message including message content 244 (e.g., "Is this device online?"). The message 243 may be transmitted at interaction 31 to connectivity service provider 260, such as transaction processor 130 facilitating communication using a cloud computing environment. Connectivity service provider 260 may then transmit message content 244 and other message data of the message 243 to second device 250 at interaction 32. This may include establishing a context ID in a database and an acknowledgment process for detecting when confirmation of receipt of the message 243 from second device 250.

[0069] The second device 250 includes an interface 252 for displaying received messages, such as a received message 253 corresponding to a sent message 243 from the interface 242 of the first device 240. Interface 252 can be used to read message content 244, which may similarly display "Is this device online?", and allows input of a response 254. By receiving and / or displaying the message content 244 in the received message 253, and by inputting a response 254, the second device 250 can provide an acknowledgment with a context ID to the connectivity service provider 260 at interaction 33. This can be stored in a database along with the context ID, allowing the connectivity service provider 260's acknowledgment process to recognize the acknowledgment and respond to the first device 240 at interaction 34, acknowledging that the sent message 243 has been received by the second device 250 and that the message content 244 has been populated in interface 252 along with the received message 253. Therefore, at interaction 34, status 245 can be updated to online, and a read receipt 246 can indicate that the message content 244 has been read. At interaction 35, the second device 250 can provide a response 254, for example, to the connectivity service provider 260 via a bidirectional connection 255, which can also assist in direct data transmission via a device-to-device connection 256 when the device activity and status have been confirmed.

[0070] Figure 3 This is an exemplary illustration 300 showing an exchange API call and message transmission between a terminal device and a backend server to confirm message transmission in order to notify a POS or other device of the status of the terminal device, according to an embodiment. Figure 3 The diagram 300 includes representations of API calls, data processing events, and / or other messages and data processing exchanged between devices, services, and databases, which can be used to identify Figure 1 The state of reader 120 in system 100. In this regard, such interactions may be performed by POS 110 and reader 120 with reader service 302 and database 304, which may correspond to transaction processor 130 and / or the cloud environment and / or system used by transaction processor 130, which have been discussed with reference to system 100.

[0071] Figure 300 illustrates in more detail the process by which reader 120 acknowledges requests and / or messages from transaction processor 130. Initially, when a transaction occurs, POS 110 may communicate with reader service 302 at interaction 41, whereby a charge for the transaction may be requested from reader 120. For example, once a transaction is generated at POS 110, POS 110 may request reader 120 to charge the customer and receive / process the payment data entered by the customer at reader 120. Reader service 302 may correspond to applications, computing services, and / or components, including those associated with a corresponding cloud computing environment, which may manage different readers, payment terminal devices, and / or other devices configured to interact with POS 110 and / or similar devices, for example, to facilitate data processing and / or message exchange. In this regard, reader service 302 may be provided by transaction processor 130 and / or in a cloud environment, and may further utilize database 304 to store connection IDs, context IDs, and acknowledgment messages and responses during the determination of the status of different readers and terminal devices.

[0072] At interaction 42, the unconfirmed context of the reader charge requested by the POS device is generated by the reader service 302 and stored by the database 304. The unconfirmed context may correspond to a context ID that has not yet received a confirmation response from the reader 120 and is stored while awaiting such a response so that it can be polled when determining the status of the reader 120. At interaction 43, a request or other message is transmitted from the reader service 302 to the reader 120, which in some embodiments may include a request for the reader 120 to initiate a charge and request payment from the customer. This request may include a command or operation that, when the reader 120 is online, receives the request, and / or is available, causes the reader 120 to respond with a confirmation, which may be stored by the database 304.

[0073] In this regard, a polling event or other monitoring for confirmation process 306 is initiated and established at interaction 44, wherein a loop or other periodic / continuous process is executed to check for confirmation in database 304. In this regard, at substantially the same time or during this process, reader 120 may respond and confirm the context ID to reader service 302 via a bidirectional connection or similar means at interaction 45. This may occur within the time period of confirmation process 306, allowing confirmation process 306 to detect the confirmation, which can identify reader 120 as online and available. However, if reader 120 is offline, interaction 45 may not occur, and therefore the time period of confirmation process 306 for checking for confirmation at interaction 44 may end without a confirmation being detected, which may cause reader service 302 to notify POS 110 that reader 120 is offline and / or unavailable. Therefore, interaction 46 may occur after interaction 45, wherein confirmation process 306 reliably identifies reader service 302's confirmation of the context ID from database 304.

[0074] Therefore, state update 308 may depend on whether an acknowledgment is detected during interaction 44 from acknowledgment process 306, for example, if interaction 45 occurs and reader 120 responds and acknowledges the context ID. Thus, in interaction 47a during state update 308, if interaction 45 occurs and acknowledgment process 306 detects acknowledgment of the context ID in database 304, reader service 302 may transmit a successful acknowledgment to POS 110 and thus transmit the available status of reader 120. However, if interaction 45 does not occur, interaction 47b occurs during state update 308, where POS 110 is notified by reader service 302 of an unacknowledged context ID and reader 120 goes offline.

[0075] Figure 4 This is a flowchart 400 illustrating an exemplary process for confirming message transmission to a connectable processing terminal of a POS device according to an embodiment. Note that one or more steps, processes, and methods described herein in flowchart 400 may be omitted, performed in a different order, or combined as needed or desired.

[0076] At step 402, a request to process a transaction at the POS device using a payment terminal device is received. For example, a merchant may input transaction data for the transaction into the POS device, and / or a customer or other user may use the POS device to provide items and / or input data (e.g., by scanning an item, entering an item code or identifier, selecting an item from a menu, etc.). Once a transaction is created, the POS device may initiate transaction and payment processing so that payment for the transaction can be received and the transaction can be approved, or conversely, the transaction can be rejected if payment is not processed. This causes the POS device to communicate with the transaction processor and initiate the process using a payment terminal device, such as a reader that can scan or read data from payment cards and / or mobile smartphones.

[0077] At step 404, the payment terminal device's WebSocket address or similar network and / or device address is retrieved from the previous connection using the payment terminal device's connection ID and previous connection. The payment terminal device may have a separate internet connection to the transaction processor, which may be assisted by a cloud computing system and processor, for example, by connecting to the transaction processor via a bidirectional connection using AWS, etc. Such a connection may result in the generation of a connection ID, which can uniquely identify the bidirectional connection, for example by identifying the connection and / or the payment terminal device's network address (e.g., a WebSocket address).

[0078] At step 406, a context ID is generated for the transaction and sent to the payment terminal device along with a confirmation request message. To uniquely identify the transaction, the confirmation message from the payment terminal device, and the confirmation of being online and / or available to process the transaction, a specific ID is generated to uniquely identify such data and requests. The context ID can therefore be used to track interactions and to track whether the payment terminal device is online and available when confirmation of a request from the transaction processor is received via a connection (e.g., a bidirectional connection, which may use a connection ID for transmission). The context ID can be stored in a database, such as a database associated with a cloud computing environment that facilitates connections between the transaction processor and / or the payment terminal device via cloud networks and systems. Thereafter, messages and / or requests can be created to cause the payment terminal device to confirm the message / request and respond in association with the context ID.

[0079] At step 408, the context ID is polled in the database to obtain confirmation from the payment terminal device. A polling, monitoring, listening, and / or tracking process can be created, initiated, and / or started when a message / request for confirmation is transmitted, which can be used to check the context ID in the database to determine if confirmation has been received. This process can continuously check for confirmation over a period of time or at periodic intervals, and can be initiated by a service provider with a cloud computing system. At step 410, it is determined whether confirmation has been received. This can be achieved by monitoring and / or polling the database to obtain a response.

[0080] At step 412, if no response and confirmation are received, the payment terminal device is identified as offline, and the POS device is notified of this status. In this regard, if no confirmation is received and detected by the end of the time period (e.g., stored in a database and / or associated with a context ID), the payment terminal device may be identified as offline and unavailable. Therefore, the transaction processor can determine that the payment terminal device is offline or otherwise unavailable and notify the POS device accordingly so that a different payment terminal device can be used to process payment data and other information with the customer.

[0081] At step 414, if a response and confirmation are received, the payment terminal device is identified as online, and the POS device is notified of this status, and the context ID is transmitted to the POS device. In this regard, if an acknowledgment of the transmitted message is detected in the database and / or associated with the context ID during the time period used for polling events and / or processes, the payment terminal device can be identified as online and available to the POS device. The transaction processor can then notify the POS device of the context ID so that the context ID can subsequently be used to track the processing of the transaction. At step 416, the transaction can be processed, for example, by using input from the payment terminal device. Thus, the transaction can be processed using input payment data (e.g., a scanned card or received token), which can be associated with the context ID now available to both the POS device and the payment terminal device, so that data can be correlated and tracked during processing.

[0082] Figure 5 It is suitable for implementation Figure 1 A block diagram of a computer system 500 comprising one or more components, according to one embodiment. In various embodiments, the communication device may include a personal computing device (e.g., a smartphone, tablet, personal computer, laptop, wearable computing device, such as glasses or a watch, Bluetooth device, key card, badge, etc.) capable of communicating with a network. Service providers may utilize network computing devices (e.g., web servers) capable of communicating with a network. It should be understood that each device used by the user and the service provider may be implemented as the computer system 500 described below.

[0083] Computer system 500 includes bus 502 or other communication mechanisms for transmitting information, data, signals, and information between various components of computer system 500. Components include input / output (I / O) components 504 that process user actions, such as keypad / keyboard selection keys, selecting one or more buttons, images, or links, and / or moving one or more images, and sending corresponding signals to bus 502. I / O component 504 may also include output components, such as display 511 and cursor control 513 (e.g., keyboard, keypad, mouse, etc.). Optional audio / video I / O components 505 may also be included to allow the user to input information using voice by converting audio signals. Audio / video I / O component 505 allows the user to hear audio. Transceiver or network interface 506 transmits and receives signals between computer system 500 and other devices (e.g., another communication device, service device, or service provider server) via network 150. In one embodiment, the transmission is wireless, but other transmission media and methods may also be suitable. One or more processors 512 (which may be a microcontroller, digital signal processor (DSP), or other processing components) process these various signals, for example, for display on computer system 500 or for transmission to other devices via communication link 518. Processor 512 may also control the transmission of information (such as cookies or IP addresses) to other devices.

[0084] The computer system 500 also includes a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and / or a disk drive 517. The computer system 500 performs a specific operation by executing one or more sequences of instructions contained in the system memory component 514 via a processor 512 and other components. The logic may be encoded in a computer-readable medium, which may refer to any medium involved in providing instructions to the processor 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 include optical discs or magnetic disks, volatile media include dynamic memory, such as the system memory component 514, and transmission media include coaxial cables, copper wires, and optical fibers, including conductors containing bus 502. In one embodiment, the logic is encoded in a non-transitory computer-readable medium. In one example, the transmission medium may take the form of sound waves or light waves, such as those generated during radio wave, optical, and infrared data communications.

[0085] Some common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, any other optical media, punched cards, paper tapes, any other physical media with a perforated pattern, RAM, PROMs, EEPROMs, FLASH-EEPROMs, any other memory chips or cassette tapes, or any other media from which a computer is adapted to read.

[0086] In various embodiments of this disclosure, the execution of a sequence of instructions to practice this disclosure may be performed by a computer system 500. In various other embodiments of this disclosure, multiple computer systems 500 coupled to a network (e.g., a LAN, WLAN, PTSN, and / or various other wired or wireless networks, including telecommunications, mobile, and cellular telephone networks) via a communication link 518 may collaboratively execute a sequence of instructions to practice this disclosure.

[0087] Where applicable, the various embodiments provided in this disclosure may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, the various hardware and / or software components described herein may be combined into composite components including software, hardware, and / or both, without departing from the spirit of this disclosure. Where applicable, the various hardware and / or software components described herein may be separated into sub-components including software, hardware, or both, without departing from the scope of this disclosure. Furthermore, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0088] The software according to this disclosure, such as program code and / or data, may be stored on one or more computer-readable media. It is also contemplated that the software identified herein may be implemented using one or more general-purpose or special-purpose computers and / or computer systems, networked and / or otherwise. Where applicable, the order of the various steps described herein may be changed, combined into compound steps, and / or separated into sub-steps to provide the features described herein.

[0089] The foregoing disclosure is not intended to limit this disclosure to the precise form or particular field of use disclosed. Therefore, it is conceivable that various alternative embodiments and / or modifications (whether expressly described or implied herein) are possible based on the teachings of this disclosure. Having thus described embodiments of this disclosure, those skilled in the art will recognize that changes in form and detail may be made without departing from the scope of this disclosure. Therefore, this disclosure is defined solely by the claims.

Claims

1. A system comprising: Non-transitory memory; as well as One or more hardware processors are coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations, said operations including: Receive a request from a point-of-sale (POS) device to process a transaction from the POS device, wherein the transaction is being processed at the POS device using a payment terminal device that can be connected to the POS device; The network address of the payment terminal device is determined using the connection identifier (ID) associated with the payment terminal device; The network address is used to transmit a message to the payment terminal device, wherein the message includes a context ID associated with the transaction, the context ID being stored in a database accessible to at least the system and the payment terminal device, and wherein the message requests a confirmation message from the payment terminal device, the confirmation message responding to the message and indicating that the payment terminal device is online and connected to the POS device; A confirmation process is established, wherein the confirmation process polls the database to obtain a confirmation message from the payment terminal device for the context ID; The database is polled within a time period using the confirmation process and the context ID to obtain the confirmation message; and Based on whether a confirmation message for the context ID is received within the stated time period, the POS device is notified of the status of the payment terminal device.

2. The system according to claim 1, wherein, Prior to the notification, the operation also includes: Based on the polling, it is determined that the payment terminal device did not provide the confirmation message and the context ID during the time period; and The status is updated to indicate to the POS device that the payment terminal device is offline and unavailable to process the transaction.

3. The system according to claim 1, wherein, Prior to the notification, the operation also includes: Based on the polling, the confirmation message and the context ID are received within the stated time period; and The status is updated to indicate to the POS device that the payment terminal device is online and to use the payment terminal device to process the transaction.

4. The system according to claim 3, wherein, Before transmitting the message, the operation further includes: The context ID is generated for the transaction based on at least one of the request or the payment terminal device. Furthermore, after notifying the POS device of the status, the operation further includes: The context ID, along with the transaction processing result, is returned to the POS device.

5. The system according to claim 4, wherein, The context ID is returned after the system processes the transaction and generates the processing result, and wherein the context ID associates the transaction with transaction processing events between the system, the POS device, and the payment terminal device stored in the database.

6. The system according to claim 1, wherein, The connection ID is established when the payment terminal device connects to the POS device and when the payment terminal device establishes a bidirectional connection with the system, and wherein the network address includes a WebSocket address associated with the bidirectional connection between the payment terminal device and the system.

7. The system according to claim 6, wherein, The bidirectional connection is established and managed using an on-demand cloud computing platform, and the database includes a NoSQL database associated with the on-demand cloud computing platform and using the GraphQL API.

8. The system according to claim 1, wherein, The time period is based on a set number of polling events, each of the set number of polling events is executed at a set time interval, and the polling in the time period ends after the last polling event in the set number of polling events.

9. The system according to claim 1, wherein, The confirmation message is required before the transaction is processed via the payment terminal device, and the processing of the transaction utilizes the context ID to associate the data received by the payment terminal device with the data received by the POS device.

10. The system of claim 1, wherein the operation further comprises: Receive the confirmation message and the context ID within the stated time period; Upon receiving the confirmation message and the context ID, the terminal management service determines that the firmware update for the payment terminal device is available. The firmware update is performed using the payment terminal device; as well as The following items are used to track the completion of the firmware update: the context ID and the bidirectional connection established using the connection ID.

11. The system of claim 1, wherein the operation further comprises: The POS device initiates a customized prompting process on the payment terminal device based on the stated status. The status of the payment terminal device is tracked during the customized prompting process using a bidirectional connection associated with the connection ID. as well as The status of the payment terminal device on the POS device is automatically updated during the customized prompting process.

12. A method comprising: Receive a connection request from the point of sale (POS) device to the payment terminal device for processing a transaction at the POS device using payment data input to the payment terminal device; Obtain the connection identifier (ID) and the network address of the connection established with the payment terminal device using the connection ID; The network address is used to probe the payment terminal device with a confirmation request message, wherein the confirmation request message includes a context ID associated with the transaction and requests the payment terminal device to respond with a confirmation message, the confirmation message indicating that the payment terminal device is online and can connect to the POS device; Initiate a confirmation process that monitors confirmation messages from the payment terminal device; The confirmation process is used to monitor the database over a time period to obtain confirmation messages associated with the context ID; as well as The status of the payment terminal device is provided based on whether the confirmation message is received within the time period, wherein the status indicates whether the payment terminal device is online and can connect to the POS device.

13. The method according to claim 12, wherein, The status indicates whether the payment terminal device is online and capable of processing charges for the transaction from the POS device.

14. The method according to claim 13, wherein, The charge is based on the transaction being received along with the connection request, and wherein the payment data is input at the payment terminal device for the transaction processor to process the charge.

15. The method according to claim 12, wherein, The connection request is received from the POS device based on the POS device's request to perform a firmware update on the payment terminal device.

16. The method according to claim 15, wherein, The confirmation message indicates that the firmware update has begun at the payment terminal device, and the method further includes: The confirmation process is used to monitor the database during the time period to obtain another confirmation message indicating that the firmware update has been completed; and The status is updated based on whether the other confirmation message is received within the stated time period.

17. A method comprising: The service provider receives a request from the first device for the status of the second device, wherein the status indicates whether the second device is online and can be connected by the first device for message exchange; Determine the network address of the second device; The network address is used to transmit a first message to the second device, wherein the first message includes a context ID associated with the request, the context ID being stored in a database accessible to at least the service provider and the first device, and wherein the first message requests confirmation from the second device, the confirmation responding to the first message and indicating that the second device is online; An authentication process is established with the service provider, which checks for an authentication for the context ID from the second device within a time period; as well as Based on whether an acknowledgment for the context ID is received within the time period, the status of the second device is notified to the first device.

18. The method according to claim 17, wherein, The request for the status is received along with a second message, which is specified for the application on the second message and includes a message content requesting confirmation of receipt of the second message, wherein the first message is transmitted in response to receiving the second message.

19. The method according to claim 18, wherein, The confirmation is requested based on either a read receipt request or an urgent message sending / receiving request.

20. The method of claim 17, wherein, The request is received based on a firmware update for the second device, and the confirmation includes an indication of whether the firmware update was initiated or completed on the second device.

Images