Integrated Global Tokenization System

Abstract

The integrated sales system platform includes point-of-sale applications and middleware for performing global tokenization orchestration, which, combined, provide global tokenization and provisioning operations that are not sensitive to credit card reader devices. Each middleware includes a communication interface corresponding to a specific communication protocol. The middleware receives a token creation request from the point-of-sale application and communicates directly with the interacting point-of-sale payment device via one of the communication protocols to receive the credit card number, securely encrypt it, and then sends that information to a hosted network token provisioning system to request a network token. Upon receiving the network token, the middleware communicates directly with a global merchant tokenization host via one or more protocols to create a merchant-specific token that is returned by the middleware to the point-of-sale client for use as a card-on-file payment method.

Description

Technical Field

[0001] In the secure payment industry, there are two major types of channel categories. The first is considered to be the physical presence of the customer / card at an asset or store. The second is considered to be the absence of the customer / card, which is facilitated easily in a hosted online e-commerce (ecom) or mobile application system. These systems are generally called point of sale (POS) and not only facilitate the creation of items, prices, inventory, and orders for the items the customer purchases, but also must support the execution and recording of payments for each of those orders. Many POS systems must also store credit card accounts and account information for future purchases made by the customer or the seller themselves. Customers in stores are manufactured to present their credit cards to be read by a Point of Interaction (POI) device authenticated to read credit cards via Near Field Communication (NFC) according to the instructions of various international network credit card schemes, insert the credit card into the POI device to communicate with the microchip, swipe it on the POI device via a magnetic stripe reader, or manually enter it using the numeric buttons on the POI device. The POI device securely encrypts the credit card information. The POI device can also be configured to prompt for, securely obtain, encrypt, and provide this information to a software application, which creates a message and communicates that message to a hosted payment platform, also known as a gateway, or directly to the seller's acquiring bank to reconcile the payment from the customer's credit card account to the seller. Some providers supply sellers with Payment Card Industry (PCI) validated Point-to-Point Encryption (P2PE) solutions. This encrypts primary account number (PAN; e.g., credit card number) information with a secure, authenticated POI device that uses complex encryption methods. This can only be decrypted by a certified, secure hardware security module (HSM) in a PCI-validated hosted environment. The payload is encrypted from the moment the card is read over the network until it reaches the hosted platform, ensuring secure payment processing.

[0002] This payment will be adjusted differently for the ecom system and the mobile system. The customer initiates the selection by manually entering their credit card information into the ecom or mobile application, or by using a digital wallet of a previously stored credit card. The ecom or mobile system then composes a message and sends it to the hosted payment platform or acquirer. [Overview of the Initiative]

[0003] According to one embodiment, an integrated sales system platform having integrated global tokenization orchestration middleware includes a workstation that includes one or more processors and a memory system that includes a plurality of instructions executable by the one or more processors to provide point-of-sale (POS) applications and middleware. The middleware source code is configured to be compiled and executed on various workstation operating systems. The middleware may include multiple communication interfaces, each corresponding to one of several communication protocols, and the middleware does not sense POS or point-of-interaction (POI) devices. The workstation is configured to interface with a hosted platform used to perform both payment and global tokenization services inside or outside a restricted jurisdiction for the export and storage of primary account numbers (PANs), as well as a hosted network token provisioning system. The middleware is configured to receive requests from POS applications to obtain a global token from a hosted platform, to receive requests via one of the communication protocols to obtain a global token through a POI device that reads and encrypts credit card data, and to receive requests to obtain a global token, forward the requests to a local host system, and decrypt the encrypted credit card data using a hardware security module that provisions an international credit card scheme network token. Furthermore, the middleware is configured to receive an international credit card scheme network token via one of the communication protocols, to use the international credit card scheme network token to make a request to the hosted platform to provision a merchant-specific global token, and to receive the merchant-specific global token, return the merchant-specific global token to the POS application for storage and future use, and to coordinate future payment authorization transactions via the merchant-specific global token.

[0004] In another embodiment, a computer implementation method for providing a credit card account number linked to a user account within middleware of an integrated sales system platform may include, when requesting a token, using a network token to identify a user account number linked to a credit card account number obtained from a point of interaction (POI) device, and then sending a series of instructions to a hosted platform used for merchant-specific global token provisioning in order to communicate with the platform having the user account and payment information. Furthermore, the computer implementation method may include querying user accounts and payment information to determine, based on the information returned to the hosted platform, whether the user account is eligible to generate and / or redeem units; receiving information from the hosted platform regarding multiple options for generation and / or redemption; and presenting one or more of these options to the customer associated with the credit card account number.

[0005] The computer program product includes a storage medium embodied by computer program instructions, and when the computer program instructions are executed by one or more processors, these one or more processors are instructed to: receive a request from a point-of-sale (POS) application to obtain a global token from a hosted platform; receive a request to obtain a global token via a point-of-interaction (POI) device that reads and encrypts credit card data via one of several communication protocols supported by the middleware; and receive this request to obtain a global token, forward the request to a local host system, and decrypt the encrypted credit card data using a hardware security module that provisions an international credit card scheme network token. When a computer program instruction is executed by one or more processors, it can cause one or more processors to perform the following actions: receive an international credit card scheme network token via one of the communication protocols; use this international credit card scheme network token to make a request to a hosted platform to provision a merchant-specific global token; receive the merchant-specific global token; return the merchant-specific global token to the POS application for storage and future use; and coordinate future payment authorization transactions via the merchant-specific global token.

[0006] The aforementioned features and advantages of this disclosure, as well as other features and advantages, will be readily apparent from the following detailed description in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0007] The subject matter is pointed out and explicitly claimed in the claims at the end of this specification. The aforementioned and other features and advantages of the embodiments of this specification will become apparent from the following detailed description in conjunction with the accompanying drawings. [Figure 1] A diagram showing a system according to one or more embodiments. [Figure 2] A diagram illustrating the process flow of an in-store POS system integrated into middleware within a restricted jurisdiction. [Figure 3] This diagram illustrates the process flow of an in-store POS system integrated into middleware as a PCI-validated P2PE solution. [Figure 4] A diagram illustrating the process flow of an online POS system (ecom or mobile) integrated into middleware within a restricted jurisdiction. [Figure 5] A diagram illustrating the process flow of an online POS system (ecom or mobile) integrated with middleware outside of a restricted jurisdiction. [Figure 6]A diagram illustrating the process flow of a POS system integrated into middleware to process payments using a global token within a restricted jurisdiction. [Figure 7] A diagram illustrating the process flow of an online POS system integrated with middleware that coordinates payments within a restricted jurisdiction. [Figure 8] A diagram illustrating the process flow of an online POS system integrated with middleware that adjusts payments regardless of location. [Figure 9] A diagram illustrating the process flow of a POS system integrated into middleware to coordinate earning or redeeming units linked to a PAN within a restricted jurisdiction. [Figure 10] A diagram illustrating the process flow of an online POS system integrated into middleware to coordinate earning or redeeming units linked to a PAN within a restricted jurisdiction. [Figure 11] A diagram illustrating the process flow of a POS system integrated into middleware to coordinate earning or redemption units linked to a PAN. [Figure 12] A diagram showing the process flow.

[0008] The figures shown herein are illustrative. Many variations exist to the figures and / or actions described herein without departing from the spirit of the described embodiments. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "joined" and its variations describe the existence of a communication path between two elements, and do not imply a direct connection between elements without an intervening element / connection between them. All of these variations are considered part of this specification. [Modes for carrying out the invention]

[0009] The present disclosure relates to a fully integrated omnichannel commerce platform that, in combination, provides a global token solution that does not sense a POS, does not sense a payment device, and does not sense a payment acquirer within payment orchestration, facilitating removal of the seller's system from the PCI scope both when a customer presents payment and when a customer does not present payment, while also complying with various global jurisdiction PAN processing laws and policies for the transmission and storage of such data, including a plurality of computer systems and software. Generally, a payment operation is a mechanism that enables different (e.g., independent, separate) systems that do not communicate or interact to be fully compatible and integrated without extensive onboarding programming. Embodiments disclosed herein can include systems, devices, methods, and / or computer program products for implementing a POS, a POI device, and platform integration (sometimes referred to herein as an integrated sales system).

[0010] To store a credit card at a POS, a seller has two options: store the PAN itself or store a token representing that PAN. Certain PCI - validated index tokens must be used to stay within a reduced PCI security scope. To obtain a token, additional steps and technical integration from the POS to a hosted payment platform, an acquirer, or a separate authentication token provider are required. Credit card issuing banks have partnered with many international card schemes to create and issue seller - specific network tokens. These tokens reduce the PCI scope but are formatted like a PAN, and due to POS constraints that prevent the storage of a PAN, the network tokens do not pass system checks and constraints and prevent the storage of either a PAN or a network token, so they cannot be stored in a system. Therefore, a seller-specific global index token can be used, and a network token and / or PAN are linked to it for payment orchestration. The network token is used to facilitate payments in the same way that a PAN is used globally. In many countries, there are local jurisdictions with laws and regulations governing the transmission and storage of PAN data. In some jurisdictions, for any reason, including performing a payment or storing the PAN in a file for future use, the PAN cannot be transmitted outside that jurisdiction. In some regulations, even if the PAN is entered by the customer himself via ecom POS, the system is not permitted to store the PAN in a file for future use. Worldwide, new legislation and regulations are changing and passing to further restrict the use and storage of PAN information to prevent fraud and misuse of customers' credit card accounts. This limits the ability to store the PAN and create tokens stored in the POS system for future use, substantially increasing complexity, and thereby equally restricting the POS that adjusts payments using that token.

[0011] Various types of user accounts can establish a link between the PAN and the user account to support purchases and other types of transactions. As an example, many loyalty providers can also cooperate with sellers to link the PAN to a specific customer's loyalty account and provide the customer with the ability to earn or redeem loyalty units during that purchase experience when adjusting payments. The issuing bank provides a primary account reference (PAR) linked to the PAN and any device token obtained from a digital wallet (DPAN) or network token the customer may have. Typically, this PAR value is obtained when provisioning network tokens. Using PARs is a common way to identify any tokens present in a file or used in a payment that have the same PAR value (linked to the same PAN) and are linked to a loyalty account. However, using PAR values ​​along with tokens to identify loyalty accounts adds more complexities to data storage, system integration, and communication.

[0012] Therefore, a POS system can coordinate multiple specific integrations and communications to provision network tokens, securely transfer them outside restricted jurisdictions for exchange with PCI-validated globally unique merchant tokens, and store them for future use at the POS. Furthermore, to add a seamless loyalty offering integrated via POS, the complexity of remembering PAR values ​​linked to loyalty accounts and also linked to network tokens, as well as merchant-specific global tokens, also increases.

[0013] There are tens of thousands of POS systems, hundreds of POI device manufacturers, thousands of hosted payment platforms or acquirers, and thousands of loyalty providers (and / or other types of user account support systems). To coordinate and securely tokenize payments and / or loyalty payments, technical software integration is required between all systems and POI devices. This presents significant challenges and limitations for each of the parties involved: merchants, point-of-sale (POS) providers, hosted payment platforms, acquirers, and royalty providers. The software enhancements required to integrate the systems are considerable, even for a single end-to-end system (POS, devices, network token provisioner, payment platform, and loyalty provider). Further described herein is Agnostic Software Middleware "Integrated Global Tokenization Middleware and Platform," which coordinates seamless technical and functional integration across multiple interfaces with multiple protocols to multiple POS, ecom / mobile POS, POI devices, loyalty providers, network token provisioners, and hosted payment platforms. Combined with hosted services, this agnostic middleware, integrated via POS, can seamlessly coordinate global tokenization and linked loyalty across multiple providers. Such a solution could involve integration with multiple network token providers within a jurisdiction to coordinate global tokenization, thereby allowing the National Card Scheme network token to be sent and stored outside the jurisdiction in exchange for a merchant-specific, globally unique PCI-verified index token, which remains within the jurisdiction and is stored in the POS.

[0014] The agnostic middleware solution, with its multiple interfaces and protocols, integrates into any POS system, facilitating agnostic and seamless integration into one of several POI devices supporting multiple protocols and card reading capabilities, one of several network token service providers supporting multiple protocols, and one of several acquirers and / or payment service providers supporting multiple protocols, providing seller-specific global tokenization for payment orchestration, including PCI-validated point-to-point encryption (P2PE) solutions with POI integration. Middleware solutions with integrated hosted platform services can be hosted and located within a restricted data governance jurisdiction ("restricted jurisdiction"), ensuring that PANs are not transmitted or stored outside the restricted jurisdiction and ensuring that vendors comply with laws and regulations for PAN use and storage. The advantage of this solution is that any POS can use one of several protocols and integrate into middleware only within one of several interfaces, which generalizes POS from multiple POI devices, multiple hosted payment platforms and acquisition providers, and multiple network token service providers to obtain global tokens for payment execution globally in any region. The same middleware solution can support multiple credit card input mechanisms, including manual user input and digital wallet integration and communication. The same middleware can also support non-integrated POS orchestration, allowing users (e.g., POS operators) to securely obtain global tokens using a user interface provided with the middleware, receive those tokens, and then manually enter them into the POS system. In all cases, the same middleware can be used to securely execute token decryption requests and obtain underlying network tokens for payment orchestration as an integrated component of one or more of the following: POS / ecom / mobile, POI devices, network service providers, and hosted payment platforms / acquirers.

[0015] To seamlessly enable user account functionality, additional orchestration that leverages PAR values ​​in real time within the payment and tokenization orchestration can increase usefulness for consumers and merchants. Furthermore, by leveraging a hosted platform and middleware, and utilizing one of several integrations into the system, it is possible to provide real-time unit acquisition or redemption linked to the original underlying PAN used for payments from the POS.

[0016] The constraints and burdens on the seller and its sales system relating to complexity, the amount of integration, adequate security, data governance and regulatory compliance, timely activation, and overall technical challenges are significantly reduced or eliminated in accordance with the manner described herein.

[0017] Referring now to Figure 1, an integrated sales system (System 100) for implementing the teachings of this specification is shown. Generally, system 100 processes and manages payments for items, food, and / or services, whether a card is used for payment or if it is entered manually.

[0018] System 100 has a workstation 201. Furthermore, the workstation 201 may be an electronic computer framework comprising, and / or employing, any number and combination of computing devices and networks utilizing various communication technologies, as described herein. Furthermore, Workstation 201 is scalable, expandable, and modular, with the ability to change to different services or to reconfigure certain features independently of others. Furthermore, Workstation 201 includes, but is not limited to, desktop computers, laptop computers, dedicated asset management computer terminals, point-of-sale computers, tablets, smartphones, and / or computers that function as servers hosted in a data center or store. The workstation 201 also includes a system bus 102 that connects the processor 103 to the memory 104 and various other components.

[0019] The processor 103 includes any processing hardware, software, or combination of hardware and software used by the workstation 201, which executes computer-readable program instructions by performing arithmetic operations, logical operations, and / or input / output operations. For example, the processor 103, also called a processing circuit, microprocessor, or computing unit, may include one or more central processing units. The processor 103 includes, but is not limited to, an arithmetic logic unit that performs arithmetic and logical operations, a control unit that extracts, decodes, and executes instructions from memory, and an array unit that utilizes multiple parallel computing elements.

[0020] Memory 104 is an example of a tangible device (e.g., a computer-readable storage medium) that holds and stores computer-readable program instructions (such as computer program products) used by the processor 103 to perform the operations of the embodiments herein. Computer-readable storage media may, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. When used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0021] Memory 104 may also contain various computer system-readable media. Such media may be any accessible and available media, and such media may include both volatile and non-volatile media, and removable and non-removable media. As shown in Figure 1, the memory 104 includes read-only memory (ROM) and random access memory (RAM). The memory may be coupled to the system bus 102 and may include a basic input / output system (BIOS) that controls certain basic functions of the system 100. RAM is read-write memory coupled to the system bus 102 for use by processor 103. The workstation 201 also includes a hard disk 107, which is another example of a tangible device (e.g., a computer-readable storage medium) that holds and stores computer-readable program instructions that can be executed by the processor 103. A non-exhaustive list of more specific examples of computer-readable storage media (i.e., memory 104) includes portable computer diskettes, erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, and any suitable combination thereof. Hard disk 107 stores software 108a and 108b (sometimes commonly referred to as software 108). The software 108 is stored as instructions for execution within the system 100 by the processor 103 (which operates and / or executes processes in conjunction with the operating system, one or more application programs, other program modules, and data 109). Data 109 includes a set of values ​​for qualitative or quantitative variables organized into various data structures to support the operation of software 108 and to be used by the operation of software 108. Software 108 can be run completely on workstation 201, partially on workstation 201, as a standalone software package, partially on workstation 201 and partially on a remote computer or server, or completely on a remote computer or server. Therefore, as configured in Figure 1, the operation of the software 108 and data 109 (e.g., providing device agnostic payment operation) is necessarily rooted in the computing power of the processor 103, workstation 201, and / or components connected thereto, in order to overcome and address the conventional middleware of conventional multi-device POS or point-of-purchase systems described herein. In this regard, the software 108 and data 109 replace conventional middleware and improve the computational operation of the processor 103, workstation 201, and / or components connected thereto, thereby reducing errors and compatibility concerns in conventional multi-device POS or point-of-sale systems (and thereby increasing the efficiency of system 100).

[0022] The system 100 in Figure 1 includes a processor 103, memory 104, hard disk 107, and one or more adapters (e.g., a hard disk controller, a network adapter, a graphics adapter, etc.) that interconnect and support communication between other components of the system 100 (e.g., peripherals and external devices). One or more adapters can connect to one or more I / O buses connected to the system bus 102 via an intermediate bus bridge, and one or more I / O buses can utilize common protocols such as peripheral component interconnection.

[0023] As shown in the figure, the workstation 201 includes a communication adapter 121 and an interface adapter 122. The communication adapter 121 interconnects the workstation 201 with the network 150 of system 100, enabling the workstation to communicate with other systems, devices, data, and software such as the payment gateway 402 and the POS server 199. The interface adapter 122 interconnects the workstation 201 with the POI device 160. This POI device 160 includes a processor 163, memory 164, a reader 166, and a display 167. The processor 163 and memory 164 are similar to the processor 103 and memory 104 described herein. POI devices are PCI-validated devices approved within PCI-validated P2PE solutions. Therefore, the POI device securely reads and encrypts the PAN data in the secure module within the device, coordinated between the reader 166, processor 163, and memory 164. The payment gateway 402, token subsystem 401, HSM 403, hosted system 501, HSM 502, POS server 199, and / or POI device 160 (such as workstation 201) constitute an electronic computer framework that is scalable, expandable, and modular, yet includes and / or employs any number and combination of computing devices and networks that utilize a variety of communication technologies.

[0024] Payment gateway 402 represents a computer system of a payment service provider and / or bank that authorizes direct debit or credit card payment processing for businesses, retailers, vendors, service providers, etc. (either online or in-store). The token subsystem represents a computing service that securely stores PAN data within a PCI DSS (Payment Card Industry Data Security Standard) verified and audited environment, calculates PCI-verified merchant-specific index-style globally unique tokens, and returns those tokens to the requesting system. The POS server 199 provides the system 100 with external processing capabilities, data storage, networking, and a graphical user interface to process payments and perform sales operations for purchasing items, services, etc. POI device 160 is an arbitrary payment terminal that reads and encrypts credit card information. The token subsystem 401 represents a computing service within platform 400 for securely storing PAN and network token data, and then for calculating and returning seller-specific global tokens. A hosted system 501, which has an HSM502, represents a computing service within the system that securely decrypts encrypted PAN and PIN data, stores the PAN, provisions a merchant-specific network token for the international credit card scheme, and returns that token to the requesting system. Furthermore, the hosted system 501 provides additional services specific to network tokenization, which include, but are not limited to, returning a payment account reference (PAR), exchanging a device token for a network token, exchanging a merchant-specific global token for a network token, and returning attributes related to the network token (PAN's BIN (Bank Identification Number), account type (credit, debit), issuing bank information, and card image). The hosted system 501 may also be located within a restricted data governance jurisdiction where PAN data is prohibited from being transmitted over the network to locations outside the jurisdiction and stored outside the jurisdiction. The payment gateway 402, POS server 199, POI device 160, token subsystem 401, and hosted system 501 are distinct (e.g., separate and independent) systems that would not typically communicate or interact without conventional middleware. It should be noted that this presents unique technical compatibility and integration challenges, requiring extensive onboard programming to integrate all systems and subsystems to facilitate payment operations, tokenization, and PAN-linked loyalty. More specifically, each of the payment gateway 402, POS server 199, POI device 160, token subsystem 401, and hosted system 501 may require a separate communication protocol that is incompatible with the communication protocols of the other subsystems. Next, the technical effects and benefits of middleware 250 include providing device-insensitive payment operations, improving the computational operations of processor 103, workstation 201, payment gateway 402, POS server 199, token subsystem 401, hosted system 501, and POI device 160, thereby eliminating concerns and added complexity for software 108 and POS software 200, as well as POS server 199.

[0025] The workstation 201 may be connected to the payment gateway 402, the token subsystem 401, the hosted system 501, and the POS server 199 via any type of network 150, including a local area network (LAN) or wide area network (WAN), the internet, or a virtual private network, or the connection may be made to an external computer (for example, via the internet using an internet service provider). The internal operations of software 108 and data 109 are implemented on network 150 to provide platform as a service, software as a service, and / or infrastructure as a service. Middleware 250 is proprietary software that integrates separate systems to coordinate tokenization and linked loyalty. The reader 166 is a device that interfaces with a payment card to facilitate electronic transfers from that credit card account to the merchant's account (e.g., via tap (near-field communication), insert, swipe, or manual card information entry actions) by reading the credit card PAN and data. The display 167 may include any visual device for providing a user interface, for example, a graphics controller for providing graphics performance (such as displaying and managing a graphic user interface).

[0026] Referring here to Figure 2, a system 1002 is shown for implementing a card presentation payment and tokenization process, fully integrated between POS200, middleware250, POI device160, hosted system501, and platform400. When a credit card is read and encrypted, point-to-point encryption is used to securely transmit a PAN500 or DPAN503 from the entry point to a secure HSM502 within a restricted jurisdiction in exchange for a network token 600 and PAR601, which can then be used to exchange a merchant's global token 700 with platform400, thereby exporting the network token outside the jurisdiction and storing it in platform400 instead of the PAN, noting that platform400 is outside the restricted jurisdiction. System 1002 is an exemplary configuration of System 100 in Figure 1.

[0027] System 1002 has a workstation 201. In Figure 2, the POS200 software resides and runs on workstation 201, which performs the POS functions. The POS200 software communicates with middleware 250 to perform a fully integrated end-to-end process, thereby integrating the POI device 160, the hosted system 501, and the platform 400 together to perform global tokenization and return the results to the POS200 software. The POS200 software sends a message to middleware 250, which then communicates with POI device 160 to prepare it for accepting credit card reading. Customer 10 inserts, taps, or manually enters a credit card, or taps their phone with a digital wallet, for token provisioning. The POI device 160 securely acquires PAN500 or DPAN503, encrypts PAN500 or DPAN503, and provides the encrypted data to middleware 250. The middleware 250 then forms a specific message and communicates it to the hosted system 501 within its jurisdiction. The hosted system 501 uses the hardware security module HSM502 to securely decrypt PAN500 or DPAN503. Next, the hosted system 501 provisions a network token and returns the token 600, PAR601, and additional information to the middleware 250. Next, middleware 250 forms a specific message and communicates with platform 400 to obtain the seller's global tokens. Platform 400 utilizes the token subsystem 401 to securely store network tokens 600 and PAR 601, as well as loyalty accounts if provided by POS, and provision merchant-specific global tokens 700. The global token subsystem 401 returns global token 700 to middleware 250. Next, middleware 250 returns global token 700 to the POS200 software for storage and future use. Hosted systems 501 and HSM502 are located within the restricted jurisdiction if the seller's location is within that jurisdiction, ensuring that PAN500 or DPAN503 are not transported outside that jurisdiction via the network. Under regulation, the seller's unique network tokens 600 and PAR601 are transferred and stored outside the restricted jurisdiction within Platform 400 in order to generate the seller's global token 700.

[0028] Referring here to Figure 3, a fully integrated system 1003 is shown for implementing the card presentation payment and tokenization process, where the POS 200, POI device 160, hosted middleware 250, hosted system 501, and platform 400 are fully integrated, and when a credit card is read and encrypted, point-to-point encryption is used to securely transmit the PAN 500 or DPAN 503 from the entry point to the secure HSM 403 outside the restricted jurisdiction in exchange for the network token 600 and PAR 601, which can then be used with platform 400 to exchange for the merchant's global token 700, thereby storing the network token in place of the PAN. System 1003 is an exemplary configuration of System 100 in Figure 1.

[0029] Furthermore, this system 1003 includes a workstation 201. The POS200 software resides and runs on workstation 201, which performs the POS functions. The POS200 software communicates with middleware 250 to perform a fully integrated end-to-end process, thereby integrating the POI device 160, the hosted system 501, and the platform 400 together to perform global tokenization and return the global token 700 to the POS200 software. The POS200 software sends a message to middleware 250, which then communicates with POI device 160 to prepare it for accepting credit card reading. Customer 10 inserts, taps, or manually enters a credit card, or taps their phone with a digital wallet, for token provisioning. The POI device 160 securely acquires PAN500 or DPAN503, encrypts PAN500 or DPAN503, and provides the encrypted data to middleware 250. The middleware 250 then forms a specific message and communicates it to the platform 400 along with instructions for provisioning encrypted data and network tokens. Platform 400 uses HSM403 to securely decrypt PAN500 or DPAN503 and communicate PAN500 or DPAN503 to the hosted system 501. Next, the hosted system 501 provisions the network tokens and returns its seller-specific network tokens 600 and PAR601, as well as additional information, to the platform 400. Next, the platform 400 utilizes the token subsystem 401 to securely store the network token 600, PAR 601, and loyalty accounts, if provided by POS, and provision the merchant-specific global token 700. The global token subsystem 401 returns global token 700 to platform 400, and platform 400 returns global token 700 to middleware 250. Next, middleware 250 returns global token 700 to the POS200 software for storage and future use. Platform 400 and the hosted system 501 are located outside the restricted jurisdiction.

[0030] Referring here to Figure 4, a system 1004 for implementing online card absence processing for ecom and mobile applications is depicted, which is fully integrated between the POS 200, middleware 250, customer computing device 161 (similar to the workstation 201 described herein), web browser software or mobile application software 162, hosted system 501, and platform 400, and securely transmits PAN 500 or DPAN 503 within a restricted jurisdiction in exchange for network tokens 600 and PAR 601, which are then used with platform 400 to exchange for the seller's global token 700. System 1004 is an exemplary configuration of System 100 in Figure 1.

[0031] Furthermore, this system 1004 includes an application server 101. For brevity, the application server 101 is similar to the workstation 201 as defined herein as a hosted computing system. The POS200 software resides on and runs on the application server 101 that performs the POS functions. The POS200 software may be a web application that interacts with a web browser on the computing device 161, or it may be a server-side application that communicates with a mobile application 162 on the computing device 161 in order to interface with the customer 10. Customer 10 enters their PAN500 or selects a credit card from a digital wallet that generates a DPAN503, which is communicated to the POS200 running on the application server 101 via a web browser or mobile application 162. The POS200 then communicates the PAN500 or DPAN503, and optionally the loyalty account number, to middleware 250, which also runs on application service 101, forming a specific message and communicating it to the hosted system 501 within the jurisdiction. Next, the hosted system 501 provisions a network token and returns the token 600, PAR601, and additional information to the middleware 250. Next, middleware 250 forms a specific message and communicates with platform 400 to obtain the seller's global tokens. Platform 400 utilizes the token subsystem 401 to securely store network tokens 600 and PAR 601, as well as loyalty accounts if provided by POS, and provision merchant-specific global tokens 700. The global token subsystem 401 returns global token 700 to middleware 250. Next, middleware 250 returns global token 700 to the POS200 software for storage and future use. The hosted system 501 is located within the restricted jurisdiction if the seller's location is within that jurisdiction, and ensures that PAN 500 or DPAN 503 are not transported outside that jurisdiction via the network. Network tokens 600 and PAR601 are transferred and stored outside the restricted jurisdiction within Platform 400 to generate the seller's global token 700, ensuring that the seller complies with data management regulations and laws.

[0032] Referring here to Figure 5, a system 1005 is depicted for implementing online card absence processing for ecom and mobile applications, which is fully integrated between POS200, middleware250, customer computing device161, web browser or mobile application162, hosted system501, and platform400, and securely transmits PAN500 or DPAN503 outside restricted jurisdictions in exchange for network tokens600 and PAR601, which are then used with platform400 to exchange for merchant global tokens700. If the PAN is issued by a credit card issuer within a restricted jurisdiction, middleware 250 communicates with the hosted system 501 within that jurisdiction. System 1005 is an exemplary configuration of System 100 in Figure 1.

[0033] System 1005 includes an application server 101. The POS200 software resides on and runs on the application server 101 that performs the POS functions. This POS200 software may be a web application that interacts with a web browser on the computing device 161, or it may be a server-side application that communicates with a mobile application 162 on the computing device 161 in order to interface with the customer 10. Customer 10 enters their PAN500 or selects a credit card from a digital wallet that generates a DPAN503, which is communicated to the POS200 running on the application server 101 via a web browser or mobile application 162. The POS200 then communicates with PAN500 or DPAN503, and optionally with the loyalty account, in this case with middleware 250 hosted outside the application server, which forms a specific message and communicates it to the hosted system 501. Next, the hosted system 501 provisions a network token and returns the token 600, PAR601, and additional information to the middleware 250. Next, middleware 250 forms a specific message and communicates with platform 400 to obtain the seller's global token and send network token 600, PAR601, and loyalty account (if provided by POS200). Platform 400 utilizes the token subsystem 401 to securely store the network token 600, PAR 601, and loyalty accounts if provided by POS, then provisions a merchant-specific global token 700 and returns it to middleware 250, which returns the global token 700 to POS 200 for storage and future use. The hosted system 501 also needs to be located within a restricted jurisdiction if the PAN is issued by a bank within the jurisdiction and regulations prohibit the storage of that PAN outside the jurisdiction. Middleware 250 is configured to communicate with multiple hosted systems 501 in multiple domains.

[0034] Referring to Figure 6, a system 1006 is shown for performing payment orchestration within a store in a restricted jurisdiction, fully integrated between a POS 200, middleware 250, POS server 199, POI device 160, platform 400, payment service provider (PSP) system 300 (typically a payment gateway), and acquirer 203, in order to exchange a global token 700 for a network token 600 in order to facilitate credit card payments. System 1006 is an exemplary configuration of System 100 in Figure 1.

[0035] System 1006 has a workstation 201. The POS200 software resides and runs on workstation 201, which performs the POS functions. The POS200 software communicates with middleware 250 to exchange global token 700 for network token 600. Middleware 250 creates a message and communicates with platform 400 to send global token 700, which then communicates with token subsystem 401 to exchange global token 700 for network token 600. Platform 400 then returns the network token 600 to middleware 250. Depending on the type of PSP integration, either middleware 250 or POS200 then creates a message and communicates the network token 600 to the PSP system 300 to arrange the credit card payment. The PSP system 300 uses the network token 600 to create a message and communicates with the acquirer 203 to adjust the payment. The payment result is returned to POS200 via the chain of components.

[0036] Referring here to Figure 7, a system 1007 is shown for implementing online card absence processing for ecom and mobile applications, fully integrated between a POS 200, middleware 250, customer computing device 161, web browser or mobile application 162, platform 400, payment service provider (PSP) system 300, and acquirer 203, in order to facilitate credit card payments by exchanging global tokens 700 for network tokens 600 from within a restricted jurisdiction. System 1007 is an exemplary configuration of System 100 in Figure 1.

[0037] Furthermore, this system 1007 includes an application server 101. The POS200 software resides on and runs on the application server 101 that performs the POS functions. The POS200 software may be a web application that interacts with a web browser on the computing device 161, or it may be a server-side application that communicates with a mobile application 162 on the computing device 161 in order to interface with the customer 10. Customer 10 initiates a payment request to the POS200 application. The POS200 software communicates with middleware 250 to exchange global token 700 for network token 600. Middleware 250 creates a message and communicates with platform 400 to send global token 700, which then communicates with token subsystem 401 to exchange global token 700 for network token 600. Next, platform 400 returns network token 600 to middleware 250. Next, depending on the type of PSP integration, either middleware 250 or POS200 creates a message and communicates the network token 600 to the PSP system 300 to arrange the credit card payment. The PSP system 300 uses the network token 600 to create a message and communicates with the acquirer 203 to adjust the payment. The payment result is returned to POS200 via the chain of components.

[0038] Referring here to Figure 8, a system 1008 is shown for implementing online card absence processing for ecom and mobile applications, fully integrated between a platform 400 having a POS 200, middleware 250, customer computing device 161, web browser or mobile application 162, payment gateway 402, and acquirer 203, in order to facilitate credit card payments by exchanging global tokens 700 for network tokens 600 outside of restricted jurisdictions. System 1008 is an exemplary configuration of System 100 in Figure 1.

[0039] Furthermore, this system 1008 has an application server 101. The POS200 software resides on and runs on the application server 101 that performs the POS functions. The POS200 software may be a web application that interacts with a web browser on the computing device 161, or it may be a server-side application that communicates with a mobile application 162 on the computing device 161 in order to interface with the customer 10. Customer 10 initiates a payment request to the POS200 application. The POS200 software communicates with middleware 250, which is hosted on an external platform to the application server 101, to execute the payment by sending a global token 700. Middleware 250 creates a message, communicates with platform 400, and sends an instruction to execute a payment using global token 700 and network token 600. Next, platform 400 communicates with payment gateway 402, which then communicates with token subsystem 401 to exchange global token 700 for network token 600. The token subsystem 401 returns the network token 600 to the payment gateway 402, which then creates a message, communicates with the acquirer 203, and sends the network token 600 to execute the credit card payment. The payment result is returned to POS200 via the chain of components.

[0040] Referring here to Figure 9, a system 1009 is shown for implementing fully integrated payment orchestration between a POS 200, middleware 250, POS server 199, POI device 160, platform 400, payment service provider (PSP) system 300, and acquirer 203 for exchanging global tokens 700 for network tokens 600 to facilitate credit card payments and loyalty transactions from within a restricted jurisdiction. System 1009 is an exemplary configuration of System 100 in Figure 1.

[0041] Furthermore, this system 1009 includes a workstation 201. The POS200 software resides and runs on workstation 201, which performs the POS functions. The POS200 software communicates with middleware 250 to exchange global token 700 for network token 600. Middleware 250 creates a message and communicates with platform 400 to send global token 700, which then communicates with token subsystem 401 to exchange global token 700 for network token 600. Platform 400 then returns the network token 600 to middleware 250. Depending on the type of PSP integration, either middleware 250 or POS200 then creates a message and communicates the network token 600 to the PSP system 300 to arrange the credit card payment. The PSP system 300 uses the network token 600 to create a message and communicates with the acquirer 203 to adjust the payment. The result of the payment operation is returned to middleware 250 and / or POS200. Middleware 250, which is also configured to execute loyalty transactions, creates a message, communicates with platform 400, and sends the same global token 700 along with instructions to execute loyalty transactions such as earning points. Platform 400 retrieves the loyalty account from the token subsystem 401 using the global token 700, then creates a message and communicates with the loyalty provider 310 to execute the loyalty transaction. The result of this loyalty transaction is then returned to POS200 via a series of components. A loyalty account must be provided when provisioning global tokens from network tokens prior to a loyalty transaction request.

[0042] Referring here to Figure 10, a system 1010 is shown for implementing online card absence processing for ecom and mobile applications, fully integrated between a POS 200, middleware 250, customer computing device 161, web browser or mobile application 162, platform 400, payment service provider (PSP) system 300, and acquirer 203, in order to facilitate credit card payments by exchanging global tokens 700 and loyalty transactions for network tokens 600 from within a restricted jurisdiction. System 1010 is an exemplary configuration of System 100 in Figure 1.

[0043] Furthermore, this system 1010 includes an application server 101. The POS200 software resides on and runs on the application server 101 that performs the POS functions. The POS200 software may be a web application that interacts with a web browser on the computing device 161, or it may be a server-side application that communicates with a mobile application 162 on the computing device 161 in order to interface with the customer 10. Customer 10 initiates a payment request to the POS200 application. The POS200 software communicates with middleware 250 to exchange global token 700 for network token 600. Middleware 250 creates a message, communicates with platform 400 to send global token 700, and then communicates with token subsystem 401 to exchange global token 700 for network token 600. Next, platform 400 returns network token 600 to middleware 250. Depending on the type of PSP integration, either middleware 250 or POS200 then creates a message and communicates the network token 600 to the PSP system 300 to arrange the credit card payment. The PSP system 300 uses the network token 600 to create a message and communicates with the acquirer 203 to adjust the payment. The result of the payment operation is returned to middleware 250 and / or POS200. Middleware 250, which is also configured to execute loyalty transactions, creates a message, communicates with platform 400, and sends the same global token 700 along with instructions to execute loyalty transactions such as earning points. Platform 400 retrieves the loyalty account from the token subsystem 401 using the global token 700, then creates a message and communicates with the loyalty provider 310 to execute the loyalty transaction. The result of this loyalty transaction is then returned to POS200 via a series of components. A loyalty account must be provided when provisioning global tokens from network tokens prior to a loyalty transaction request.

[0044] Referring to Figure 11, we see a system 1011 for performing card presentation payment and tokenization processes, which is coupled with a fully integrated loyalty transaction between the POS 200, middleware 250, POI device 160, hosted system 501, and platform 400 and acquirer 203. Once the credit card is read and encrypted, it securely transmits PAN 500 or DPAN 503 using PCI-verified P2PE. System 1011 is an exemplary configuration of System 100 in Figure 1.

[0045] Furthermore, this system 1011 includes a workstation 201. The POS200 software combines payment, loyalty, and global tokenization messages into one and sends it to the middleware 250, which then communicates with the POI device 160 to prepare it for accepting credit card readings. Customer 10 inserts, taps, or manually enters a credit card, or taps their phone with a digital wallet, in order to perform a POS200 request. The POI device 160 securely acquires PAN500 or DPAN503, encrypts PAN500 or DPAN503, and provides the encrypted data to middleware 250. Middleware 250 forms a specific message and communicates it to platform 400. Platform 400 utilizes the payment gateway 402 to decode the payload that extracts the PAN500 or DPAN503 from HSM403, then forms a message, communicates with acquirer 203, and sends the PAN500 or DPAN503 to perform the payment. The payment result is returned to the payment gateway 402, and if it is successfully accepted by the acquirer, the payment gateway 402 communicates with the token subsystem 401 to provision the network token 600 and return the seller-specific global token 700. The token subsystem creates a message, communicates with the hosted system 501, and sends PAN500 or DPAN503. The hosted system 501 then provisions a network token 600 and returns the network token 600 and PAR 601 to the token subsystem 401. The token subsystem 401 stores the network token 600 and PAR 601, then generates a global token 700 and returns it to the payment gateway 402, which then returns the payment result and the global token 700 to the middleware 250. Middleware 250, configured for loyalty and having received an initial POS200 message to execute this loyalty, composes a message and sends a loyalty transaction request along with global token 700 to platform 400. Platform 400 creates a message, communicates with the token subsystem, and passes the global token 700. The token subsystem retrieves the PAR value linked to global token 700 from the previously provisioned network token 600, uses the PAR value to look up the loyalty account, and returns the loyalty account to payment gateway 402. The payment gateway then creates a message and communicates the loyalty transaction to the loyalty provider 310 using the loyalty account. The result of the loyalty transaction is returned to middleware 250 via the component chain, which then returns the payment result, global tokens 700, and the loyalty transaction result to POS200. A loyalty account must have been provided in a previous operation when the customer files their credit card within the token subsystem 401 for future use. The PAR value is also provided, stored, and linked to the loyalty account.

[0046] A loyalty account can represent any type of user tracking and association system with secure transaction support. Such user tracking and association systems can manage various types of units associated with user accounts, which can be increased or decreased based on various types of actions.

[0047] Next, referring to Figure 12, a flowchart of Method 800 relating to one embodiment is generally shown. Method 800, in whole or in part, is a computer implementation method carried out, for example, by all or part of the systems shown in Figures 1 to 11.

[0048] In block 802, middleware 250 can receive a request from POS application 200 to obtain a global token from the hosted platform. In block 804, middleware 250 can receive a request via one of several communication protocols supported by middleware 250, read credit card data, and obtain a global token via a POI device that encrypts it. In block 806, middleware 250 receives a request to obtain a global token and forwards the request to a hosted system within the region, and can decrypt encrypted credit card data using a hardware security module that provisions an international credit card scheme network token. In block 808, middleware 250 can receive an International Credit Card Scheme Network token via one of the communication protocols and use the International Credit Card Scheme Network token to make a request to the hosted platform to provision a merchant-specific global token. In block 810, middleware 250 receives a seller-specific global token and returns the seller-specific global token to the POS application 200 for storage and future use, and can coordinate future payment authorization transactions via the seller-specific global token.

[0049] The POS application 200 and middleware 250 can be executed by the workstation 201.

[0050] The workstation 201 is configured to interface with a hosted platform used to perform both payment and global tokenization services inside or outside a restricted jurisdiction for the export and storage of primary account numbers (PANs), as well as a hosted network token provisioning system.

[0051] When a computer program instruction is executed by one or more processors (e.g., processor 103), it can cause one or more processors to perform the following actions: recognize the POI device type, automatically connect and communicate based on the POI device type, initiate commands to accept credit card numbers read or manually entered, receive encrypted credit card numbers from POI device 160 which encrypts credit card numbers within a Payment Card Industry (PCI) verification point-to-point encryption (P2PE) solution, recognize the communication protocol of a hosted network token provisioning system, construct information including the encrypted card number, send the information to the hosted network token provisioning system to decrypt the information, provision network tokens, and then exchange them for merchant-specific global tokens.

[0052] The source code for Middleware 250 is configured to be compiled and executed on various workstation operating systems.

[0053] Middleware 250 can include multiple communication interfaces, each of which corresponds to one of several communication protocols.

[0054] Middleware 250 does not detect POS and POI devices.

[0055] The POS application 200 and middleware 250 can be executed by the application server 101.

[0056] When a computer program instruction is executed by one or more processors (e.g., processor 103), it can cause one or more processors to perform the following actions: when requesting a token, use a network token to identify a user account number linked to a credit card account number obtained from a POI device; then send a series of instructions to a hosted platform used for merchant-specific global token provisioning in order to communicate with the platform that has the user account and payment information; query the user account and payment information and, based on the information returned to the hosted platform, determine whether the user account is eligible to generate and / or redeem a unit; receive information from the hosted platform regarding a series of options for generation and / or redemption; and present one or more of these options to the customer associated with the credit card account number.

[0057] One or more of the options may include displaying the number of units earned for the relevant payment transaction to the customer associated with their credit card account number, such as on display 167.

[0058] One or more of the options may include redeeming or generating units instead of completing a credit card payment, or in addition to a credit card payment.

[0059] When a computer program instruction is executed by one or more processors (e.g., processor 103), it can cause one or more processors to perform the following actions: receive input from a customer; send an issuance or redemption request back to a hosted platform for later communication of the units issuance or redemption to the platform; receive a response returned from the hosted platform; display the number of units issuance or redemption on a POI device; and return the results to a POS application for addition to an order and receipt.

[0060] The processes shown in Figure 12 are not intended to indicate that the operations should be performed in any particular order, or that all of the operations shown in Figure 12 should be included in all cases. Furthermore, the process shown in Figure 12 can include any number of additional actions as appropriate.

[0061] The integrated sales system platform may include a point-of-sale application and global tokenization orchestration middleware for performing global tokenization orchestration, which, combined, provide credit card reader-insensitive global tokenization and provisioning operations, as well as / or credit card-linked loyalty operations. Middleware includes communication interfaces that correspond to specific communication protocols. The middleware receives a token creation request from the point-of-sale application, communicates directly with the point-of-interaction payment device via one of the communication protocols to receive the credit card number, securely encrypts it, and then sends that information to the hosted network token provisioning system to request a network token. Upon receiving this network token, it communicates directly with a global merchant tokenization host via one or more protocols to create a merchant-specific token that is returned to the point-of-sale client by middleware for use as a card-on-file payment method. Through the same protocol, the middleware can also instruct the global token host to retrieve the loyalty account linked to that credit card using the network token and primary account reference value, communicate with a third system to determine loyalty unit accumulation and / or redemption options, and, based on customer input, return that information to the middleware for orchestration of loyalty unit accumulation or redemption of a specific amount. The middleware also includes methods to ensure that merchants comply with all local and regional data management laws by receiving a merchant-specific global token, detoxifying that token using a global merchant tokenization host, then receiving and returning the network token associated with that merchant token so that it can be used for credit card payment authorization from anywhere globally, and transmitting and storing credit card account numbers.

[0062] Within the middleware of an integrated sales system platform, a computer implementation method for providing a credit card account number linked to a loyalty account may include, when requesting a token, using a network token to identify the loyalty account number linked to the credit card account number obtained from the point of interaction (POI) device, and then sending a series of instructions to a hosted loyalty platform used for merchant-specific global token provisioning in order to communicate with the loyalty platform that holds the user account and payment information. Furthermore, the computer implementation method may include querying the loyalty account and payment information to determine, based on the information returned to the hosted platform, whether the loyalty account is eligible to generate and / or redeem loyalty units. Furthermore, the computer implementation method may include receiving information from the hosted platform regarding options for royalty accrual and / or redemption. The computer implementation method may further include presenting the customer associated with the credit card account number with the number of loyalty units automatically earned for the associated payment transaction, or completing the POS order by presenting the customer with the option to redeem or accrue loyalty units instead of completing the credit card payment, or in addition to completing the credit card payment. This can help ensure that merchants comply with all local and regional data management laws when transmitting and storing credit card account numbers while providing secure transactions.

[0063] The computer implementation method may include receiving input from the customer and sending the accrual or redemption request back to the hosted platform for later communication of the royalty units for accrual or redemption to the loyalty platform. Furthermore, the computer implementation method may include receiving responses returned from a hosted platform, displaying the number of loyalty units generated or redeemed on a POI device, and returning the results to a point-of-sale (POS) application for addition to orders and receipts.

[0064] The embodiments disclosed herein are systems, methods, and / or computer program products at any possible level of technical detail of integration. A computer program product includes a computer-readable storage medium having computer-readable program instructions for causing a processor to perform various actions.

[0065] Computer-readable storage media are tangible devices capable of holding and storing instructions for use by instruction execution devices. Computer-readable storage media may, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved raised structures on which instructions are recorded, and any preferred combination of the above. When used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0066] The computer-readable program instructions described herein are downloaded from a computer-readable storage medium to a computing / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and transfers these instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0067] Computer-readable program instructions for performing the operations of this disclosure may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuit networks, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, high-level languages ​​such as Python, C-Sharp (C#), Java, Swift, and Objective-C, and procedural programming languages ​​such as the C programming language or similar programming languages. Computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (for example, via the Internet using an Internet service provider). In some embodiments, an electronic network including, for example, a programmable logic network, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by individualizing the electronic network using state information of computer-readable program instructions in order to carry out embodiments of the present disclosure.

[0068] Embodiments are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block in a flowchart and / or block diagram, as well as combinations of blocks within a flowchart and / or block diagram, are implemented using computer-readable program instructions.

[0069] These computer-readable program instructions can be provided to a computer system processor or other programmable data processing device so that instructions executed via the processor of the computer or other programmable data processing device create means for implementing functions / actions specified in one or more blocks of a flowchart and / or block diagram, thereby generating a machine. Furthermore, these computer-readable program instructions may be stored in a computer-readable storage medium that can instruct a computer, a programmable data processing device, and / or other device to function in a particular way, thereby including articles of a product in which the computer-readable storage medium storing the instructions contains instructions that implement the modes of function / operation specified in one or more blocks of a flowchart and / or block diagram.

[0070] Furthermore, computer-readable program instructions can be loaded onto a computer, other programmable data processing device, or other device to perform a series of operations on the computer, other programmable device, or other device, thereby generating a computer implementation process in which the instructions executed on the computer, other programmable device, or other device implement the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0071] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products in various forms. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction that contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the block may be performed in a different order than that shown in the diagram. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality they contain. It should also be noted that each block in a block diagram and / or flowchart, as well as any combination of blocks within a block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs a specified function or action, or by implementing a combination of dedicated hardware and computer instructions.

[0072] The descriptions of various embodiments are presented for illustrative purposes only and are not intended to be exhaustive or to limit the scope to the embodiments disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best describe the principles of the embodiments, their practical application to the technology found in the market, or technical improvements, or to enable a person skilled in the art to understand the embodiments described herein.

[0073] Various embodiments are described herein with reference to the relevant drawings. Alternative embodiments can be devised without departing from the scope of this disclosure. The following description and diagrams illustrate various connections and positional relationships between elements (e.g., above, below, adjacent, etc.). These connections and / or spatial relationships may be direct or indirect unless otherwise specified, and this disclosure is not intended to limit them in this respect. Therefore, the union of entities can refer to either a direct or indirect union, and the positional relationship between entities can be either a direct or indirect positional relationship. Furthermore, the various tasks and process steps described herein can be incorporated into more comprehensive procedures or processes that have additional steps or functions not described in detail herein.

[0074] The following definitions and abbreviations are used for interpretation of the claims and specification. As used herein, the terms “equipped,” “containing,” “included,” “having,” “having,” “containing,” or “containing,” or any other variation thereof, are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus containing a list of elements is not necessarily limited to those elements alone and may include other elements that are not explicitly listed or that are specific to such composition, mixture, process, method, article, or apparatus.

[0075] In addition, the term “exemplary” is used herein to mean “serving as an example, case, or illustration.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as being preferable or advantageous to any other embodiment or design. The terms "at least one" and "one or more" are understood to include any integer greater than or equal to 1, i.e., 1, 2, 3, 4, etc. The term "multiple" is understood to include any integers greater than or equal to two, i.e., 2, 3, 4, 5, etc. The term "connection" includes both indirect and direct connections.

[0076] The terms “approximately,” “substantially,” and “roughly,” and variations thereof, are intended to include the degree of error associated with the measurement of a particular quantity based on the equipment available at the time of filing this application. For example, "approximately" can include a range of ±8%, 5%, or 2% of a given value.

[0077] For the sake of brevity, prior art techniques relating to the creation and use of embodiments may or may not be described in detail herein. In particular, various forms of computing systems and specific computer programs for implementing the various technical features described herein are well known. Therefore, for the sake of brevity, many details of conventional implementations are either briefly mentioned herein or completely omitted without providing details of well-known systems and / or processes.

[0078] It should be understood that various embodiments and / or parts of embodiments disclosed herein may be combined in combinations different from those specifically presented in the description and accompanying drawings. It should also be understood that, as in the example, some actions or events of any of the processes or methods described herein may be performed in different sequences, added, merged, or completely excluded (for example, not all described actions or events may be necessary to perform this technique). In addition, while certain aspects of this disclosure are described for clarity as being implemented by a single module or unit, it should be understood that the techniques of this disclosure are implemented, for example, by a combination of units or modules associated with a medical device.

[0079] In one or more examples, the described techniques are implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functionality is stored on a computer-readable medium as one or more instructions or codes and executed by a hardware-based processing unit. Computer-readable media include non-temporary computer-readable media corresponding to tangible media such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and are accessed by a computer).

[0080] Instructions are executed by one or more processors, such as digital signal processors (DSPs), graphics processing units (GPUs), microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Therefore, the term “processor” as used herein may refer to any of the aforementioned structures or any other physical structure suitable for implementing the techniques described. Furthermore, this technique is fully implemented in one or more circuits or logic elements.

[0081] While the present invention has been described with reference to several embodiments, those skilled in the art will understand that various modifications can be made and elements can be replaced with equivalents without departing from the scope of the invention. Furthermore, embodiments or parts of embodiments may be combined in whole or in part without departing from the scope of the present invention. In addition, many modifications can be made to adapt the teachings of the present invention to specific situations or materials without departing from the scope of the present invention. Therefore, the present invention is not limited to any particular embodiment disclosed as intended for carrying out the present invention, and is intended to include all embodiments that fall within the scope of the appended claims. Furthermore, unless otherwise specified, the use of terms such as "first," "second," etc., does not indicate any order or importance; rather, terms such as "first," "second," etc., are used to distinguish one element from another.

Claims

1. An integrated sales system platform having integrated global tokenization orchestration middleware, A workstation comprising one or more processors and a memory system including a plurality of instructions executable by the one or more processors to provide point-of-sale (POS) applications and middleware, wherein the source code of the middleware is configured to be compiled and executed on various workstation operating systems, the middleware includes a plurality of communication interfaces, each of which corresponds to one of a plurality of communication protocols, and the middleware does not sense POS and point-of-interaction (POI) devices, the workstation comprising The workstation is configured to interface with a hosted platform used to perform both payment and global tokenization services inside or outside a restricted jurisdiction for the export and storage of primary account numbers (PANs), and a hosted network token provisioning system. The aforementioned middleware, The POS application receives a request to obtain a global token from the hosted platform, To obtain the global token through a POI device that reads and encrypts credit card data, a request is received via one of the communication protocols, The process involves receiving the request to obtain the global token, forwarding the request to a hosted system within the region, and decrypting the encrypted credit card data using a hardware security module that provisions an international credit card scheme network token. Receiving the international credit card scheme network token via one of the aforementioned communication protocols, Using the aforementioned international credit card scheme network token, a request is made to the hosted platform to provision a merchant-specific global token. An integrated sales system platform configured to receive the seller-specific global token, return the seller-specific global token to the POS application for storage and future use, and coordinate future payment authorization transactions via the seller-specific global token.

2. The aforementioned middleware, The system recognizes the POI device type, automatically connects and communicates based on the POI device type, initiates a command to accept a credit card number read or manually entered, and receives the encrypted credit card number from the POI device, which encrypts the credit card number within a Payment Card Industry (PCI) verification point-to-point encryption (P2PE) solution. Recognizing the communication protocol of the hosted network token provisioning system, To construct information including the aforementioned encrypted card number, The integrated sales system platform according to claim 1, further configured to transmit the information to the hosted network token provisioning system to decrypt the information, provision network tokens, and then exchange them for the seller-specific global tokens.

3. A computer implementation method for providing a credit card account number linked to a user account within middleware of an integrated sales system platform, When requesting a token, the network token is used to identify the user account number linked to the credit card account number obtained from the point of interaction (POI) device, and then a series of instructions are sent to a hosted platform used for merchant-specific global token provisioning in order to communicate with the platform that has the user account and payment information. The user account and payment information are queryed, and based on the information returned to the hosted platform, it is determined whether the user account is eligible to generate units and / or redeem units. Receiving information from the aforementioned hosted platform regarding multiple options for accrual and / or reimbursement, A computer implementation method comprising presenting one or more of the above options to a customer associated with the aforementioned credit card account number.

4. The computer implementation method according to claim 3, wherein one or more of the options include presenting to the customer associated with the credit card account number the number of units earned for the associated payment transaction.

5. The computer implementation method according to claim 3, wherein one or more of the options include redeeming or generating a unit instead of completing a credit card payment, or in addition to the credit card payment.

6. Receiving input from the aforementioned customer, Sending the generation or redemption request back to the hosted platform in order to later communicate the generation or redemption unit to the aforementioned platform, Receiving the response returned from the aforementioned hosted platform, The number of units generated or redeemed is displayed on the POI device, The results are returned to the point-of-sale (POS) application for inclusion in the order and receipt, The computer implementation method according to claim 3, further comprising:

7. A computer program product comprising a storage medium embodied by computer program instructions, wherein when the computer program instructions are executed by one or more processors, the one or more processors, Receiving requests from a point-of-sale (POS) application to acquire global tokens from a hosted platform, The middleware receives a request to obtain the global token via a Point of Interaction (POI) device that reads and encrypts credit card data, through one of several communication protocols supported by the middleware. The process involves receiving the request to obtain the global token, forwarding the request to a hosted system within the region, and decrypting the encrypted credit card data using a hardware security module that provisions an international credit card scheme network token. Receiving the international credit card scheme network token via one of the aforementioned communication protocols, Using the aforementioned international credit card scheme network token, a request is made to the hosted platform to provision a merchant-specific global token. Receiving the aforementioned seller-specific global token, A computer program product that causes the POS application to store and use the aforementioned seller-specific global token, and to coordinate future payment authorization transactions via the aforementioned seller-specific global token.

8. The computer program product according to claim 7, wherein the POS application and middleware are executable by a workstation.

9. The computer program product according to claim 8, wherein the workstation is configured to interface with the hosted platform used to perform both payment and global tokenization services inside or outside a restricted jurisdiction for exporting and storing primary account numbers (PANs), and with a hosted network token provisioning system.

10. The system further comprises a computer program product comprising computer program instructions, and when the computer program instructions are executed by one or more processors, the one or more processors The system recognizes the POI device type, automatically connects and communicates based on the POI device type, initiates a command to accept a credit card number read or manually entered, and receives the encrypted credit card number from the POI device, which encrypts the credit card number within a Payment Card Industry (PCI) verification point-to-point encryption (P2PE) solution. Recognizing the communication protocol of the hosted network token provisioning system, To construct information including the aforementioned encrypted card number, The computer program product according to claim 9, which transmits the information to the hosted network token provisioning system to decrypt the information, provision a network token, and then exchange it for the seller-specific global token.

11. The computer program product according to claim 8, wherein the source code of the middleware is configured to be compiled and executed on various workstation operating systems.

12. The computer program product according to claim 8, wherein the middleware comprises a plurality of communication interfaces, and each of the plurality of communication interfaces corresponds to one of the plurality of communication protocols.

13. The computer program product according to claim 12, wherein the middleware does not detect POS and POI devices.

14. The computer program product according to claim 7, wherein the POS application and middleware are executable by an application server.

15. The system further comprises a computer program product comprising computer program instructions, and when the computer program instructions are executed by one or more processors, the one or more processors When requesting a token, the network token is used to identify the user account number linked to the credit card account number obtained from the POI device, and then a series of commands are sent to the hosted platform used for merchant-specific global token provisioning in order to communicate with the platform that has the user account and payment information. The user account and payment information are queryed, and based on the information returned to the hosted platform, it is determined whether the user account is eligible to generate units and / or redeem units. Receiving information from the aforementioned hosted platform regarding multiple options for accrual and / or reimbursement, The computer program product according to claim 7, which causes a customer associated with the aforementioned credit card account number to present one or more of the aforementioned options and to perform the following actions.

16. The computer program product according to claim 15, wherein one or more of the options include presenting to the customer associated with the credit card account number the number of units earned for the associated payment transaction.

17. The computer program product according to claim 15, wherein one or more of the above options include redeeming or generating units instead of completing a credit card payment, or in addition to the credit card payment.

18. The system further comprises a computer program product comprising computer program instructions, and when the computer program instructions are executed by one or more processors, the one or more processors Receiving input from the aforementioned customer, Sending the generation or redemption request back to the hosted platform in order to later communicate the generation or redemption unit to the aforementioned platform, Receiving the response returned from the aforementioned hosted platform, The number of units generated or redeemed is displayed on the POI device, The computer program product according to claim 15, which causes the results to be returned to the POS application for adding to the order and receipt.

Images