Integrated platform using hub computer

Abstract

A method is disclosed. The method includes receiving, by a hub computer from different verifier systems, interaction data for a plurality of interactions performed by a user in a trip from an initial location to an end location at different times during the trip at different verifier devices in the different verifier systems. The method includes generating an authorization request message, and transmitting the authorization request message to an authorization entity computer, the authorization request message including values associated with a plurality of interactions. The authorization entity computer approves or rejects the authorization request message and then generates an authorization response message. The method includes receiving, by the hub computer, an authorization response message.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a PCT application, which claims the benefit of and priority to U.S. Provisional Application No. 63 / 346,051, filed on May 26, 2023, the entire contents of which are incorporated herein by reference. Background Art

[0003] Transportation operators that provide different transportation services to people usually operate independently, and each operator has its own system. For example, a user may need to purchase separate tickets at different locations to make a single trip from an initial location to a final location using different modes of transportation. Each transportation operator has its own independent payment system and will need to process payments for its services independently of other transportation operators. In addition, users will be charged multiple times by different transportation operators. This type of processing scheme is repetitive and cumbersome, and is not very convenient for transportation system operators and their system users.

[0004] Additionally, some transportation operators use account-based ticketing services. In some cases, credentials such as a credit or debit card number may be used as a way to access transportation sites and pay for tickets on the transportation system. While this is convenient, the credentials are sensitive information that needs to be protected when used by the transportation operator and the account-based ticketing service. This can be particularly difficult when the transportation operator is run by a different organization than the account-based ticketing service.

[0005] Even if a combined system (e.g., a transportation system and an account-based ticketing service) could be modified to protect credentials, it would be difficult to provide such protection when new transportation operators and new account-based ticketing services are added. Each new transportation operator and new account-based ticketing service would need to be specifically updated with such protection mechanisms. This could be laborious and could hinder scalability.

[0006] Embodiments of the present disclosure address this and other problems, individually and collectively. Summary of the invention

[0007] One embodiment includes a method, comprising: receiving, through a central computer, interaction data of multiple interactions performed by a user at different times during a journey, at different authenticator devices in different authenticator systems, and in a journey from an initial location to an end location; generating, through the central computer, an authorization request message, the authorization request message including values ​​associated with the interaction data of the multiple interactions; transmitting, through the central computer, the authorization request message to an authorization entity computer, wherein the authorization entity computer approves or rejects the authorization request message and then generates an authorization response message; and receiving, through the central computer, the authorization response message.

[0008] Another embodiment includes a hub computer comprising: a processor; and a computer-readable medium comprising code capable of being executed by the processor to perform operations comprising: receiving interaction data of multiple interactions performed by a user at different times during a journey, at different validator devices in different validator systems, and in a journey from an initial location to an end location from different validator systems; generating an authorization request message comprising values ​​associated with the interaction data of the multiple interactions; transmitting the authorization request message to an authorization entity computer, wherein the authorization entity computer approves or denies the authorization request message and then generates an authorization response message; and receiving the authorization response message.

[0009] Another embodiment of the present invention includes a hub computer, comprising: one or more processors; and one or more memory devices, the one or more memory devices including a first set of APIs (application programming interfaces) and a second set of APIs, the first set of APIs being configured to receive interaction data from an authenticator system that interacts with a user device, the authenticator system being operated by different authenticators, and the second set of APIs being configured to receive data from different service provider computers managed by different service providers; a token processing module; and an interaction processing module.

[0010] A better understanding of the nature and advantages of embodiments of the present invention may be obtained by reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 A block diagram of a system according to an embodiment is shown.

[0012] Figure 2 Another block diagram of a system according to an embodiment is shown.

[0013] Figure 3 A flow chart illustrating the process that may occur after a user interacts his user device with an authenticator device in an authenticator system operated by an authenticator.

[0014] Figure 4 A flow chart for executing a journey cycle end process is shown.

[0015] Figure 5 A flow chart for adding a user to a deny list is shown.

[0016] Figure 6 A flow chart for managing operator-initiated debt is shown.

[0017] Figure 7 A flow chart illustrating another process that may occur after a user interacts their user device with an authenticator device in an authenticator system operated by an authenticator.

[0018] Figure 8 A flow chart for performing another journey session end process is shown.

[0019] Fig. 9 A flow chart of another process for adding a user to a deny list is shown.

[0020] Fig.10 A flow chart illustrating another process for managing operator-initiated debt. DETAILED DESCRIPTION

[0021] Before discussing the embodiments of the present disclosure, some terms may be described in further detail.

[0022] A "user" may include an individual. In some embodiments, a user may be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user may also be referred to as a cardholder, account holder, or consumer.

[0023] A "user device" may be a device operated by a user. Examples of user devices may include mobile phones, smart phones, cards, personal digital assistants (PDAs), laptop computers, desktop computers, server computers, thin client devices, tablet PCs, and the like. In addition, the user device may be any type of wearable technology device, such as a watch, earphones, rings, bracelets, glasses, and the like. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, and the like. The user input obtained by the input sensor may come from a variety of data input types, including but not limited to audio data, visual data, or biometric data. The user device may include any electronic device that can be operated by a user, and the electronic device may also provide remote communication capabilities with a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, a wireless data network (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (such as the Internet or a private network). The user device may also be a payment device such as a credit card, debit card, or prepaid card.

[0024] A "payment device" may include any suitable device that can be used to conduct a financial transaction (e.g., provide payment credentials to a merchant). A payment device may be a software object, a hardware object, or a physical object. As an example of a physical object, a payment device may include a substrate (e.g., a paper or plastic card), and information printed, embossed, encoded, or otherwise included at or near the surface of the object. A hardware object may involve a circuit system (e.g., a permanent voltage value), while a software object may involve non-permanent data stored on a device. A payment device may be associated with a value such as a monetary value, a discount, or store credit, and a payment device may be associated with an entity such as a bank, a merchant, a payment processing network, or an individual. A payment device may be used to conduct a payment transaction. Suitable payment devices may be handheld and compact so that they can fit into a user's wallet and / or pocket (e.g., may be pocket-sized). Exemplary payment devices may include smart cards, magnetic stripe cards, key chain devices (e.g., Speedpass available from Exxon-Mobil Corporation), and other devices. TM ) etc. If the payment device is in the form of a debit card, credit card or smart card, the payment device may also optionally have features such as a magnetic stripe. Such devices may operate in contact or contactless mode. In some embodiments, a mobile communication device may act as a payment device (e.g., the mobile communication device may store and be able to send payment credentials for a transaction).

[0025] An "application" may be computer code or other data stored on a computer-readable medium (eg, a memory element or a secure element) that may be executed by a processor to perform tasks.

[0026] A "key" may include a piece of information used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm may be an encryption algorithm that transforms original data into an alternative representation, or a decryption algorithm that transforms encrypted information back into the original data. Examples of cryptographic algorithms may include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0027] A "public key" may include an encryption key that may be openly and publicly shared. A public key may be designed to be shared and may be configured so that any information encrypted with the public key can only be decrypted using the private key associated with the public key (i.e., a public / private key pair).

[0028] A "private key" may include any cryptographic key that may be protected and secure. A private key may be securely stored at an entity and may be used to decrypt any information that has been encrypted using the associated public key of a public / private key pair associated with the private key.

[0029] A "public / private key pair" may refer to a pair of associated cryptographic keys generated by an entity. The public key may be used for public functions, such as encrypting a message to be sent to an entity, or for verifying a digital signature that should be made by an entity. On the other hand, the private key may be used for private functions, such as decrypting a received message or applying a digital signature. In some embodiments, the public key may be authorized by a subject known as a certificate authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key may typically be kept in a secure storage medium, and will typically be known only to the entity. The public and private keys may be in any suitable format, including formats based on Rivest-Shamir-Adleman (RSA) or elliptic curve cryptography (ECC).

[0030] A "digital signature" may include an electronic signature for a message. A digital signature may be a digital data value, an alphanumeric data value, or any other type of data. In some embodiments, a digital signature may be a unique data value generated from a message (or data packet) and a private key using a cryptographic algorithm. In some embodiments, a verification algorithm using a public key may be used to verify the signature. A digital signature may be used to prove the authenticity of the sender.

[0031] "Interaction" may include a mutual action or influence. "Interaction" may include a communication, contact, or exchange between parties, devices, and / or entities. Exemplary interactions include a transaction between two parties and an exchange of data between two devices.

[0032] A "credential" may include any evidence of an authority, right, or privilege. For example, an access credential may include permission to access certain tangible or intangible assets, such as buildings or files. Examples of credentials may include a password, passcode, or confidential message.

[0033] "Payment credentials" may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be directly related to the account, or may be derived from information related to the account. Examples of account information may include PAN (primary account number or "account number"), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and the like. CVV2 is generally understood to be a static verification value associated with a payment device. The CVV2 value is generally visible to the user (e.g., consumer), while the CVV and dCVV values ​​are generally embedded in a memory or authorization request message, which is not easily known to the user (although they are known to the issuer and payment processor). A payment credential may be any information that identifies a payment account or is associated with a payment account. A payment credential may be provided to make a payment from a payment account. A payment credential may also include a username, expiration date, a gift card number or code, and any other suitable information.

[0034] A "token" may be a substitute value for some other data, such as a credential or other interaction data. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens, such as payment tokens, data that can be used to access a secure system or location, etc.

[0035] A "payment token" may include an identifier for a payment account that is a replacement for an account identifier, such as a primary account number (PAN) and / or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a replacement for an original account identifier. For example, the token "4900 0000 0000 0001" may be used in place of the PAN "4147 0900 00001234". In some embodiments, the token may be "format-retained" and may have a digital format that conforms to account identifiers used in existing transaction processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token may be used in place of a PAN to initiate, authorize, process, or settle a payment transaction, or to represent an original credential in other systems where the original credential would normally be provided. In some embodiments, a token value may be generated such that recovery of the original PAN or other account identifier from the token value may not be computationally possible. In addition, in some embodiments, the token format may be configured to allow an entity receiving the token to identify it as a token and to identify the entity that issued the token.

[0036] "Tokenization" is the process of replacing data with substitute data. For example, a payment account identifier (e.g., a primary account number (PAN)) can be tokenized by replacing the primary account identifier with a substitute symbol (e.g., a token) that can be associated with the payment account identifier. In addition, tokenization can be applied to any other information that can be replaced with a substitute value (i.e., a token). Tokenization improves transaction efficiency and security.

[0037] A "token service computer" may include a system that services tokens or wallet account identifiers. In some embodiments, a token service computer may facilitate the request, determination (e.g., generation) and / or issuance of tokens, and the maintenance of an established mapping of tokens to primary account numbers (PANs), and either or both of these may be linked to a wallet account identifier in a repository (e.g., a token library). In some embodiments, a token service computer may establish a token assurance level for a given token to indicate a confidence level in the binding of a token or wallet account identifier to a PAN. The token service computer may include or communicate with a token library that stores generated tokens or wallet account identifiers. The token service computer may support token processing for payment transactions submitted using a token or wallet account identifier by de-tokenizing the token or parsing the wallet account identifier to obtain the actual PAN.

[0038] A "token request message" may be an electronic message for requesting a token. The token request message may include information that may be used to identify a payment account or digital wallet, and / or information for generating a payment token. For example, the token request message may include payment credentials, mobile communication device identification information (e.g., a telephone number or MSISDN), a digital wallet account identifier, information identifying a token service provider, a merchant identifier, a ciphertext, and / or any other suitable information. The information included in the token request message may be encrypted (e.g., using an issuer-specific key). In some embodiments, the token request message may include a flag or other indicator specifying that the message is a token request message.

[0039] A "token response message" may be a message in response to a token request. A token response message may include an indication that the token request has been approved or denied. A token response message may also include a payment token, mobile communication device identification information (e.g., a phone number or MSISDN), a digital wallet account identifier, information identifying a token service provider, a merchant identifier, a ciphertext, and / or any other suitable information. The information included in the token response message may be encrypted (e.g., using an issuer-specific key). In some embodiments, a token response message may include a flag or other indicator specifying that the message is a token response message.

[0040] An "authorization request message" may be a message requesting permission to interact. For example, an authorization request message may include an electronic message sent to a payment processing network and / or an issuer of a payment card to request authorization for a transaction. According to some embodiments, the authorization request message may comply with (International Organization for Standardization) ISO 8583, which is a standard for systems for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include a primary account number associated with the payment device or payment account, or a wallet account identifier associated with the payment account number. The authorization request message may also include additional data elements corresponding to "identification information", including, by way of example only: service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., and any other information that can be used to determine whether to identify and / or authorize the transaction.

[0041] An "authorization response message" may be an electronic message reply to an authorization request message. In some embodiments, the authorization response message may be generated by the issuing financial institution or a payment processing network. By way of example only, the authorization response message may include one or more of the following status indicators: approved - the transaction is approved; rejected - the transaction is not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns to the merchant's access device (e.g., POS device) in response to the authorization request message in the electronic message (directly or through the payment processing network) indicating that the transaction is approved. The code may serve as evidence of authorization. As described above, in some embodiments, the payment processing network may generate or forward an authorization response message to the merchant.

[0042] A "processor" may include a device that processes something. In some embodiments, a processor may include any suitable one or more data computing devices. A processor may include one or more microprocessors that work together to achieve the desired functionality. A processor may include a CPU that includes at least one high-speed data processor that is sufficient to execute program components for executing user and / or system generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processors; Intel's Celeron, Itanium, Pentium, Xeon, and / or Xscale; and / or similar processors.

[0043] "Memory" may be any suitable device or devices that can store electronic data. Suitable memory may include non-transitory computer-readable media that stores instructions executable by a processor to implement a desired method. Examples of memory may include one or more memory chips, disk drives, etc. Such memory may operate using any suitable electrical, optical, and / or magnetic modes of operation.

[0044] A "server computer" may include a powerful computer or cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a Web server. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0045] An "authorized entity" may be an entity that authorizes a request. Examples of authorized entities may be issuers, government agencies, document repositories, access administrators, etc. An authorized entity may operate an authorized entity computer.

[0046] An "issuer" may refer to a commercial entity (e.g., a bank) that issues and optionally maintains a user account. An issuer may also issue payment credentials to a consumer that are stored on a user device such as a cell phone, smart card, tablet computer, or laptop computer.

[0047] An "acquirer" may generally be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities may perform the functions of both an issuer and an acquirer. Some embodiments may encompass such a single entity, issuer-acquirer. An acquirer may operate an acquirer computer, which may also be generally referred to as a "shipping computer."

[0048] Embodiments of the present invention use an integrated platform including a hub computer (e.g., a ticketing hub) to integrate processing functions (e.g., payment processing functions) of different transportation systems operated by different transportation operators. The platform can provide public services such as payment and tokenization services for different transportation systems. The integrated platform can allow different transportation operators to merge EMV (Europay-MasterCard-Visa) and non-EMV transportation payment schemes. In some embodiments, users can use payment devices such as EMV (Europay, MasterCard, Visa) credit cards or debit cards to pay for tickets for transportation services of different transportation operators. Credit cards or debit cards can also be used as admission ticket devices.

[0049] In some embodiments, the platform may include a hub computer (e.g., a ticketing hub) that includes an open API that includes a first set of APIs, a second set of APIs, and a third set of APIs. For example, the first set of APIs, the second set of APIs, and the third set of APIs may be a set of user service APIs, a set of ABT (account-based ticketing) service APIs, and a set of validator service APIs. By using multiple sets of APIs, new services can be easily integrated into the hub computer.

[0050] In some embodiments, the hub computer receives interaction data for multiple interactions performed by a user in a journey from an initial location to an end location from different validator systems. Different interactions may involve interactions between a user device of a user and different validator devices in different validator systems at different times during the journey. For example, the different validation systems used by a user during a journey may include transportation systems, such as a rail system and a bus system. A user may travel from an initial location to an end location using a train on a rail system and a bus on a bus system.

[0051] The interaction data received by the hub computer may include the following data: data including credentials, tokens or encrypted versions thereof and authenticator data. The authenticator data may be received from the authenticator system and may include detailed information about a specific leg of the journey that the user is experiencing. For example, authenticator data from a train system for a train that the user is riding on one leg of the journey may include an identifier of the train system, the start and end times of the train, the start and end locations of the train, etc. Each time the user enters a transportation system and each time the user leaves a transportation system, the user may be required to interact their user device with an authenticator device (e.g., an entry gate and an exit gate) to inform the system how and when the user uses each transportation system.

[0052] After the hub computer obtains the interaction data from different validator systems, the hub computer can generate an authorization request message, which includes a value associated with the interaction data of multiple interactions. The authorization request message can then be transmitted to the authorized entity computer. For example, the interaction data from different validator systems can include a value associated with the user using different validator systems. For example, a user can take a train on a train system, and it may cost twenty dollars to take a train. The user can also take a bus on a bus system, and the bus ride may cost ten dollars. The user can use a credit or debit device to access both the train system and the bus system. For example, the user can tap a credit or debit device at the entrance gate and exit gate in the train system and at the entrance and exit points of the bus. Once the user has completed his multi-stage journey, the hub computer can generate an authorization request message, which includes a total cost of thirty dollars for the entire journey. In some embodiments, the hub computer can apply a cross-operator cap (for example, twenty-five dollars in the above example) to the total fare. Then, the hub computer can transmit the authorization request message to the authorized entity computer that manages the account associated with the credit or debit device.

[0053] After the authorization entity computer receives the authorization request message, the authorization entity computer approves or denies the authorization response message and then generates an authorization response message. The hub computer then receives the authorization response message and can provide notification of the received authorization response message to different authenticator systems.

[0054] At a later time, a clearing and settlement process may be performed between the authorization entity computer, the processing network computer, and the validator system or a shipping computer (e.g., an acquirer computer) associated with the validator system. During this process, actual funds associated with different amounts owed by different validators operating different validator systems may be transferred from the authorization entity computer to the different validator systems (or a payment service provider or acquirer operating on behalf of the validators operating the validator systems).

[0055] Figure 1 is a high-level block diagram illustrating a system according to an embodiment. Figure 1 A hub computer 10 is shown, which may be a ticketing hub computer. The hub computer 10 may be a server computer and may include one or more computing devices that work together to perform the functions described herein. In some cases, the hub computer 10 may be a communication hub between multiple validator systems 26A, 26B, 26C, multiple service provider computers 20A, 20B, and one or more user interaction service systems 30.

[0056] The hub computer 140 may also communicate with the authorization entity computer 70 via the gateway 40, the shipping computer 50, and the processing computer 60. The gateway 40 may be a payment gateway and may be operated by a payment service provider (e.g., a PSP) or other entity. In some cases, the functions performed by the gateway 40 itself may be part of the hub computer 10. The shipping computer 50 may be operated by an acquirer, and the authorization entity computer 70 may be operated by an issuer.

[0057] The service provider computers 20A, 20B may perform services for the validator systems 26A, 26B, 26C, such as summarizing fare calculations for multiple journey segments for a user, pricing journey costs using the validator systems 26A, 26B, 26C. In some embodiments, the service provider computers 20A, 20B may be account-based ticket fare engines that receive details of interaction data from various validator systems 26A, 26B, 26C. The interaction data may be created in response to a user using a user device at each of the validator systems 26A, 26B, 26C. The interaction data from each validator system 26A, 26B, 26C may be used to construct a single amount or single fare to be charged to the user. The service provider computers in the service provider computers 20A, 20B may also monitor the balance owed by the user, and may make decisions about adding or removing users from a rejection or approval list.

[0058] The validator system 26A, 26B, 26C can be a system operated by a validator. The validator can operate a transportation system, such as a railway system, a bus system, a ship system, an aircraft system, etc. Each validator system 26A, 26B, 26C can operate multiple validator devices. Examples of validator devices can include gates or readers that can grant or deny physical access to users of the transportation system using the validator. Each validator system 26A, 26B, 26C can also include one or more validator servers. The validator server can collect and process transactions from the validator device.

[0059] The processing network computer 60 may reside in a payment processing network that may include data processing subsystems, networks, and operations for supporting and delivering authorization services, exception file services, and clearing and settlement services. Exemplary payment processing networks may include VisaNet TM For example, VisaNet TM VisaNet is a payment processing network that processes credit card transactions, debit card transactions and other types of commercial transactions. TM , in particular, including the VIP system (Visa Integrated Payment System) that processes authorization requests and the Base II system that performs clearing and settlement services. The payment processing network may use any suitable wired or wireless network, including the Internet.

[0060] Figure 1Components (e.g., computers) in the systems of any of the following figures may be in operative communication with each other via any suitable communication medium 150. Suitable examples of communication medium 150 may be any one and / or combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operating mission as an Internet node (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, the Wireless Application Protocol (WAP); I-mode, etc.), etc. Figure 1 Messages between computers, networks, and devices may be transmitted using secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); and Hypertext Transfer Protocol Secure (HTTPS).

[0061] Figure 2 A block diagram showing the core functions of a system according to an embodiment of the present invention is shown. The core functions may be embodied by computer software and / or hardware.

[0062] Figure 2 A hub computer 111 (e.g., a ticket hub) is shown that communicates with a validator service API 108, an account-based ticket (ABT) service API 112, and a user service API 124. The hub computer 111 can be part of an integrated platform that integrates various service provider computers and validator systems. The validator service API 108 can be a first set of APIs, the ABT service API 112 can be a second set of APIs, and the user service API 124 can be a third set of APIs. In some embodiments, the APIs 108, 112, and 124 can be part of the hub computer 111.

[0063] The system may also include a plurality of user devices 102 that may be used by a user who uses a transportation service operated by a validator (e.g., a transportation operator) operating the validator system. Example user devices include a mobile device 102A (e.g., a mobile phone), an EMV card / wearable device 102B, and / or a smart card 102C. In some cases, the user devices 102 may communicate via a short-range communication protocol such as NFC (near field communication). They may be tapped to a validator device 104 (or otherwise interacted with) to access a transportation system operated by a validator. The validator system may include a validator server and a validator device.

[0064] The validator device 104 may be a device that a user may interact with in an attempt to use a transportation service provided by the validator. Examples of validator devices may include ticket gates, bus ticket machines, etc. The validator device 104 may be operably connected to a validator backend 106 that includes a validator server. The validator server may collect and process transactions from one or more validator devices 104 at a location, and may manage communications between the validator devices 104 and the hub computer 111.

[0065] In some embodiments, a user may tap a user device 102 (e.g., a credit card) to a validator device 104 (e.g., a ticket gate) to access transportation services provided by the validator system. When the user device 102 and the validator device 104 communicate with each other, the user device 102 may transmit credentials (e.g., a PAN) and a digital signature to the validator device 104. Before allowing the user of the user device 102 to access transportation services associated with the validator system, the validator device 104 may perform a verification process, such as an offline authentication process. In the offline authentication process, the validator device 104 may have a public key to verify the digital signature from the user device 102. The verification of the digital signature may ensure that the user device 102 is authentic.

[0066] The authenticator service API 108 may provide an interface between the authenticator backend 106 and the hub computer 111. The authenticator service API 108 may provide an interface for the hub computer 111 to receive interaction data (e.g., encrypted credentials and authenticator data) from the authenticator backend 106. The authenticator service API 108 may allow the authenticator backend 106 to provide an updated deny list to the list processing module 120A.

[0067] The hub computer 111 may include a processor 123 and several software modules located on one or more computer readable media. The software modules may include but are not limited to a security zone 115, such as a PCI (Payment Card Industry) zone, a processing platform 120 (e.g., an EMV platform), and an internal solution platform 126.

[0068] The security zone 115 may include a tokenization service module 110 and a payment service module 114. In some embodiments, the tokenization service module 114 may have the same Figures 3 to 6The payment service module 114 may be generally referred to as an "interaction processing module" as described above. In some embodiments, the payment service module 114 may be generally referred to as an "interaction processing module". The security zone 115 may be implemented using secure software or hardware (e.g., an HSM or hardware security module). In some embodiments, the tokenization service module 110 may obtain a token associated with a credential received from the authenticator backend 106 via the authenticator service API 108. If the token is not found, the tokenization service module 110 may obtain (e.g., generate or retrieve) a new token for the credential. In some embodiments, when determining the payment amount, the payment service module 114 may provide an authorization request message to the shipping computer 118. The shipping computer 118 may be operated by the acquirer using a payment gateway 116.

[0069] The payment amount may be determined by one or more of the ABT / fare engines 112A, 112B, 112C using the ABT (Account Based Transaction) service API 112, or may be determined by the payment service module 114. In some cases, if the authorization request message fails, the token used in the authorization request message may be added to a deny list by the hub computer 111 along with the payment amount (liability) that the token did not authorize.

[0070] The processing platform 120 may include modules for list processing 120A, touch processing 120B, digital tickets (VDT) 120C, debt recovery 120D, and fraud management 120E. The list processing module 120A can manage a reject list. The reject list can be a list of tokens or credentials that may not be used to conduct future transactions because they are inactive or suspected to be fraudulent or stolen. The touch processing module 120B can send tokens and interaction data (e.g., touch data) received from the validator service API 108 to the ABT service API 112.

[0071] The internal solution platform 126 may include modules for transaction management 126A, card management 126B, and product management 126C.

[0072] In some embodiments, upon receiving the token and interaction data (e.g., tap data), the ABT service API 112 may distribute one or both of them to the appropriate ABT / fare engine (112A, 112B, 112C). For example, in some cases, the interaction data may come from a validator system such as a bus system, and the token and interaction data may be sent to an APT service / fare engine associated with a bus system to calculate the cost of riding the bus. In some embodiments, a single ABT / fare engine or a single service provider computer may receive interaction data from multiple validator systems via the hub computer 204 at different times during a user's journey. A single ABT / fare engine or a single service provider computer may track data associated with the journey, and may calculate a total payment amount, and send it to the payment service module 114 after the user has completed their journey. Thus, in embodiments of the present invention, different transaction amounts for different transportation operators may be aggregated into a single amount, and the single amount may be submitted in an authorization request message for authorization.

[0073] The payment service module 114 may initiate the processing and generation of the authorization request message by generating and transmitting the authorization request message to the payment gateway 116 which is in communication with the shipping computer, which in turn is in communication with the processing network computer and the authorization entity computer (see Figure 1 ). In other embodiments, the payment service module 114 can provide data for creating an authorization request message to the payment gateway 116, and the payment gateway 116 can generate the authorization request message and transmit the authorization request message to the authorization entity computer via the shipping computer 118 and the processing network computer. In some embodiments, the functionality of the payment gateway 116 can be in the payment service module 114.

[0074] User services 122 may include a user service portal 122A, a user portal 122B, a user application 122C, and a user management module 122D. The user service portal 122A may be a portal typically operated by a customer service agent. The user service portal 122A may typically receive support phone calls from users and use the user service portal 122A to respond to inquiries and make changes. The user portal 122B may be a portal that a user may log in to and interact with a solution. The user application 122C may be an application on a user device of a user that receives services.

[0075] The user service API 124 may provide an interface between the user service 122 and the hub computer 111. The user service API 124 may send user requests from the user service 122 to the hub computer 111 to modify or refund their trip. Upon receiving the request, the hub computer 111 may use the internal solution platform 126 to process the request.

[0076] In some embodiments, the hub computer 111 includes a processor 123 and a computer-readable medium. The computer-readable medium includes code that can be executed by the processor to perform operations including: receiving interaction data of multiple interactions performed by a user at different times during a journey, at different validator devices in different validator systems, and in a journey from an initial location to an end location from different validator systems; generating an authorization request message, the authorization request message including a value associated with the interaction data of the multiple interactions; transmitting the authorization request message to an authorization entity computer, wherein the authorization entity computer approves or denies the authorization request message and then generates an authorization response message; and receiving the authorization response message.

[0077] Figure 3 206 (e.g., a token service computer), a payment gateway 208, and an ABT service 210 (which may be software facilitated or operated by a service provider computer). In some embodiments, the token computer 206 may correspond to Figure 2 The tokenization service module 110 in , and the payment gateway 208 may correspond to Figure 2 The payment service module 114 and / or payment gateway 116 in.

[0078] Before a user conducts a transaction with the authenticator system 202, the hub computer 204 (or token computer 206) and the authenticator system 202 may establish a cryptographic key pair to secure communications therebetween. In some embodiments, the authenticator system 202 (e.g., an authenticator device or an authenticator server) may encrypt credentials received from a user device before they are transmitted to the hub computer 204. Each authenticator system 202 that interacts with the hub computer 204 may have a separate cryptographic key pair so that communications between the hub computer 204 (or a token computer associated with the hub computer) and the corresponding authenticator system are secure. The cryptographic key pair may be a symmetric key pair or an asymmetric key pair.

[0079] In with Figure 3During the association process, a user may tap or otherwise interact a user device, such as a payment card (e.g., an EMV card), with an authenticator device (e.g., a train station gate) in the authenticator system 202. During the interaction, the authenticator device may receive credentials, such as a primary account number (PAN), and other information including one or more of an expiration date, a CVV (card verification value), a digital signature, and a password. The authenticator device may then provide the user device data including the credentials and other data related to the user device interaction with the authenticator device to an authenticator server in the authenticator system, or to the hub computer 204. The data related to the user device interaction may include information such as the location of the authenticator device (e.g., the Times Square subway station), an identifier of the authenticator device, and the time when the authenticator device received the credentials from the user device. The data related to the user device interaction and the credentials may be part of the "interaction data" (or alternatively, "tap data" in the case of using NFC communication) used for user device interaction with the authenticator device in the authenticator system 202.

[0080] In step S212, after receiving the credential from the user device, the authenticator device or authenticator server in the authenticator system 202 may encrypt the credential with a first key (e.g., a symmetric key or a public key) of a cryptographic key pair, and send the encrypted credential (e.g., ePAN) and other interaction data to the hub computer 204. Examples of other interaction data may include operator information, such as authenticator device ID and / or authenticator system ID, time, location. In some embodiments, the interaction data may also include one or more of encrypted credentials, plaintext data (e.g., plaintext EMV data), hashed credentials (e.g., hashed PAN), digital signatures, and interaction identifiers (e.g., tap UIDs). Other examples of interaction data may include transportation modes (e.g., bus, rail), destinations, tap types (e.g., entry, exit, inspection, etc.), etc. Although Figure 2 Not shown, the hub computer 204 may receive the encrypted credentials using a first set of APIs.

[0081] In step S214, after receiving the interaction data from the authenticator system 202, the hub computer 204 may request an existing token for encrypted credentials by sending the encrypted credentials to the token computer 206. The token computer 206 may be part of the hub computer 204 or may be located external to the hub computer 204.

[0082] In step S216, the token computer 206 may decrypt the encrypted credential using the second key of the cryptographic key pair. Once decrypted, the token computer 206 may exchange (e.g., determine) an existing token for the credential. If the token exists, the token is sent back to the hub computer 204. If the token does not exist, the token computer 206 notifies the hub computer 204 that the token does not exist. In some embodiments, the token computer 206 may be referred to as a token service computer or a tokenization service module and may maintain a database with mappings between credentials (e.g., PAN) and tokens.

[0083] In step S218 , if a token does not exist, the hub computer 204 requests a new token for encrypting the credential from the token computer 206 .

[0084] In step S220 , upon receiving the request, the token computer 206 may use the second key (associated with the first key) to decrypt the encrypted credential, obtain the token of the credential, and send the token to the hub computer 204 .

[0085] In step S222, once the hub computer 204 obtains the token, the hub computer 204 forwards the token and the interaction data to the ABT service 210 for processing.

[0086] In step S224, the ABT service receives the token and the interaction data and checks whether the token is in a rejection list. The ABT service 210 may be a module implemented on a service provider computer. The service provider computer may have a rejection list (and / or an approval list) of tokens that are not approved for transactions. They may not be approved for transactions for a variety of reasons. For example, the credentials associated with the token may be suspected of being obtained fraudulently, or the credentials may be associated with an overdrawn or suspended account.

[0087] In step S226, if the token is in the rejection list, similar to reference Figure 6 Describes the process of starting the module for managing debt.

[0088] If the token is not in the rejection list, the token is analyzed to determine whether the token has been used recently. In step S228, if the token has not been used recently, the ABT service 210 sends an account verification request (AVR) or a pre-authorization request with the token to the hub computer 204. The account verification request can be a request to an authorized entity computer to verify that the account associated with the credential associated with the token is reputable and valid. The pre-authorization request message can request pre-authorization to be sufficient to pay for a predetermined amount of a current or future journey on a transportation system associated with the authenticator system 202. For example, if the most expensive journey on the transportation system costs one hundred dollars, the pre-authorization request message can request authorization to reserve one hundred dollars on the user's account. When the user completes his journey segment on the transportation service associated with the authenticator system 202, the reservation can be released, and the journey fee can be settled for the actual amount of the journey segment.

[0089] In step S230 , the hub computer 204 then generates an AVR request message or a pre-authorization request message including the token and sends it to the token computer 206 .

[0090] In step S232 , the token computer 206 sends the received AVR request message or pre-authorization request message having the credential instead of the token to the payment gateway 208 .

[0091] In step S234, the payment gateway may process the AVR or pre-authorization request message and notify the ABT service 210 if the ABT service 210 successfully processes the request. Figure 3 Not shown, but Figure 1 ) processes the AVR or pre-authorization request message with the authorization entity computer associated with the token. In some embodiments, the acquirer may hold an account associated with the operator operating the hub computer 204 or an account associated with the transportation operator operating the verification system 202.

[0092] In step S236, if the AVR or pre-authorization request message is unsuccessful or not approved, the ABT service 210 may request that the token be added to a deny list of the hub computer 204. In step S238, the hub computer 204 adds the token to the deny list.

[0093] In step S240, if the token has been used recently or the request has been successfully processed, the ABT service 210 can process the interaction data with the appropriate ABT / fare engine. For example, the ABT service 210 and the ABT / fare engine can provide the amount of a leg of the user's journey to the hub computer 204. Alternatively or additionally, this can track the costs of all users who use different validator systems during the user's journey, and the total cost of the journey can be determined. In some embodiments, the total cost can be provided to the hub computer 204.

[0094] Figure 3 The process shown in can be performed by each validator system as the user interacts with it during multiple segments of the user's journey from the initial location to the final location. Once the user has completed a journey on different transportation systems associated with different validator systems, a single authorization process can be performed for the user and their journey on the different transportation systems. The hub computer can receive interaction data from different validator systems for multiple interactions performed by the user at different times during the journey, at different validator devices in different validator systems, in the journey from the initial location to the final location.

[0095] Figure 4 A flow chart is shown for performing an end of trip session processing for a user who has completed multiple trips with multiple authenticator systems associated. The end of trip session processing can be a batch process during which the ABT service 210 can determine the payment amount for each account in the scheme and take the required payments.

[0096] In step S312, at the end of the trip, the ABT service 210 may determine the total payment amount for the tokens used for the trip. Figure 3 In the method of , the total amount can be determined by adding the fares collected by the ABT / fare engine from different validator systems.

[0097] In steps S314 and S316, the ABT service 210 may send a payment authorization request with the token to the hub computer 204. In step S318, the hub computer 204 may then generate and / or send a payment authorization request message with the token to the token computer 206, which may retrieve the credentials associated with the token. The token computer 206 may then send the payment authorization request message including the credentials to the payment gateway 208 (e.g., using Figure 2 The secure payment service module 114 in the system).

[0098] In step S320, the payment gateway 208 may continue the payment authorization process and may obtain the payment authorization and notify the ABT service 210. In some embodiments, the payment gateway 208 (or Figure 2The secure payment service module 114 in the payment processing network (e.g., the payment processing network) can generate (or forward) an authorization request message with the total amount and the credential, and can send it to the authorization entity computer via the transportation computer (e.g., the acquirer computer) and the processing network computer (e.g., a computer in the payment processing network). The value in the authorization request message can be based on the sum of the values ​​associated with the different authenticator systems. The hub computer 204 or the service provider computer determines (e.g., calculates) the value based on the values ​​associated with the different authenticator systems.

[0099] After authorizing the authorization request message, the authorization entity computer may generate an authorization response message and transmit the authorization response message back to the hub computer 204 via the transport computer and the processing network computer.

[0100] In step S322 , if the payment authorization is successful by the payment gateway 208 , the ABT service 210 may transmit a transaction settlement request including the token to the hub computer 204 .

[0101] In steps S324 and S326, the hub computer 204 may then send a transaction clearing request to the token computer 206, which may look up the credentials associated with the token. The token computer 206 may send the transaction clearing request to the payment gateway 208.

[0102] In step S328, the payment gateway 208 may clear the transaction using the credentials and may notify the ABT service 210 that the transaction has been cleared. The payment gateway 208 may clear the transaction by initiating the transmission of clearing and settlement communications between the shipping computer, the authorized entity computer associated with the user's credentials, and the processing network computer. In some embodiments, actual funds may be transferred from the authorized entity computer to the shipping computer via the processing network computer. The shipping computer may be an acquirer computer that may hold an account associated with the hub computer 204 or an account associated with a validator. In some embodiments, funds for the user's journey are transferred to an account of the hub computer 111. The hub computer may then transfer funds for corresponding segments of the user's journey to accounts associated with different validators.

[0103] In step S330, if the payment authorization is unsuccessful, the ABT service 210 may provide a request to add the token to a deny list to the hub computer 204. Then, in step S332, the hub computer 204 may add the token to the deny list.

[0104] Figure 5 A detailed flow chart for adding a token to a deny list is shown.

[0105] In step S412 , upon receiving the request to add a token to the deny list, the hub computer 204 may attempt to find the token in the deny list.

[0106] In step S414 , if the token is not found in the deny list, the hub computer 204 may attempt to look up the hashed credentials associated with the token.

[0107] In step S416 , if the hashed credential is not found, the hub computer 204 may send a request to the token computer 206 to generate a hashed credential for the token.

[0108] In step S418 , the token computer 206 may determine the credentials associated with the token. In step S420 , the token computer 206 may hash the credentials to generate a hashed credential and send the hashed credential to the hub computer 204 .

[0109] In step S422, the hub computer 204 may store the hashed credentials with the token.

[0110] In step S424 , the hub computer 204 may add the token and hashed credentials to a deny list.

[0111] In step S426, the hub computer 204 may notify the validator system 202 of the updated deny list. In step S428, the validator system 202 may receive an updated deny list notification with the updated deny list. In step S430, the validator system 202 may provide a request for a deny list update to the hub computer 204.

[0112] Figure 6 A flow chart for managing debts initiated by an operator is shown. These are debts collected by the operator from users of tokens that are not authorized. The ABT service 210, the hub computer 204, the token computer 206, the payment gateway 208, and the mobile application 209 can be in operative communication with each other. The ABT service 210 can use a second set of APIs, the hub computer 204 can include a hub computer, and the token computer 206 can include a token service computer.

[0113] In step S512, the ABT service 210 may perform an automated attempt at debt recovery for the previously failed authorization. In step S514, if re-authorization is allowed, the ABT service 210 may resubmit the payment authorization request to the hub computer 204.

[0114] In steps S516 and S518, the hub computer may resubmit the payment authorization request message with the token to the token computer 206. Then, the token computer 206 may resubmit the payment authorization request with the credentials corresponding to the token to the payment gateway 206.

[0115] In step S520, the payment gateway may generate an authorization request message (similar to Figure 4 320 in the example above).

[0116] In step S524 , if the payment is successfully authorized, the ABT service 210 may update the account associated with the token for which the payment is successfully authorized.

[0117] In step S526, the ABT service 210 may provide a request to remove the token from the deny list to the hub computer 204. In response to this request, in step S528, the hub computer 204 may remove the token from the deny list.

[0118] In step S530 , if the debt is zero, then the original authorization that was initially denied is revoked because there is no debt that the ABT service 210 can charge to the user's account. An authorization revocation request can be sent from the ABT service 210 to the hub computer 204 .

[0119] In steps S532 and S534, the hub computer 204 may send an authorization request message with the token to the token computer 206. The token computer 206 may then send an authorization revocation request message with the credential to the payment gateway 208.

[0120] In step S536, the payment gateway may revoke the authorization and notify the ABT service 210 of the revocation.

[0121] In step S544, the ABT service 210 may submit a transaction clearing request with the token to the hub computer 204. In steps S546 and S548, the hub computer 204 may send the transaction clearing request to the token computer 206, and the token computer 206 may determine the credentials associated with the token. The token computer 206 may send the transaction clearing request with the credentials to the payment gateway 208. In step S550, the payment gateway 208 may clear the transaction with the credentials and notify the ABT service to clear the transaction. Steps S544, S546, S548, and S550 may be similar to Figure 4 S322, S324, S326 and S328.

[0122] In steps S538 and S540, the ABT service 210 may provide notification of successful debt collection to the hub computer 204, and the hub computer 204 may notify the mobile application 209. In step S542, the mobile application may manage token notifications (eg, emails, text messages, etc.) sent to the user.

[0123] Figure 7 2 shows a flow chart after a user device interacts with a validator device in a validator system 202. The validator system 202 may be in operative communication with a hub computer 204, a token computer 206 (e.g., a token service computer or a token vault computer), and a payment gateway 208, and an ABT service 210 (which may be software facilitated or operated by a service provider computer). In some embodiments, the token computer 206 may correspond to Figure 2 The tokenization service module 110 in , and the payment gateway 208 may correspond to Figure 2 The payment service module 114 and / or payment gateway 116 in.

[0124] like Figure 3 In the embodiment of Figure 7 In the example embodiment, before a user conducts a transaction with the authenticator system 202, the hub computer 204 (or token computer 206) and the authenticator system 202 can establish a cryptographic key pair to ensure communication between them. In some embodiments, the authenticator system 202 (e.g., an authenticator device or an authenticator server) can encrypt the credentials received from the user device and the authenticator data received from the authenticator system 202 before the credentials are transmitted to the hub computer 204. Each authenticator system 202 that interacts with the hub computer 204 can have a separate cryptographic key pair so that the communication between the hub computer 204 (or a token computer associated with the hub computer) and the corresponding authenticator system is secure. The cryptographic key pair can be a symmetric key pair or an asymmetric key pair.

[0125] In with Figure 7During the association process, a user may tap or otherwise interact a user device (e.g., a payment card (e.g., an EMV card)) with an authentication device (e.g., a train station gate) in the authentication system 202. During the interaction, the authenticator device may receive credentials, such as a primary account number (PAN), and other information including one or more of an expiration date, a CVV (card verification value), a digital signature, and a password. The authenticator device may then provide the user device data including the credentials and other data related to the user device interaction with the authenticator device (e.g., authenticator data) to an authenticator server in the authenticator system, or to the hub computer 204. The data related to the user device interaction may include information such as the location of the authenticator device (e.g., the Times Square subway station), an identifier of the authenticator device, and the time when the authenticator device received the credentials from the user device. The data related to the user device interaction and the credentials may be part of the "interaction data" (or alternatively, "tap data" in the case of using NFC communication) used to perform the user device interaction with the authenticator device in the authentication system 202.

[0126] In step S712, after receiving the credential from the user device, the authenticator device or authenticator server in the authenticator system 202 may encrypt the credential with a first key (e.g., a symmetric key or a public key) of the cryptographic key pair and send the encrypted credential (e.g., ePAN) and other interaction data (e.g., authenticator data) to the hub computer 204. Examples of other interaction data may include operator information or authenticator data, such as authenticator device ID and / or authenticator system ID, time, location). In some embodiments, the interaction data may also include one or more of an encrypted credential, plaintext data (e.g., plaintext EMV data), a hashed credential (e.g., a hashed PAN), a digital signature, and an interaction identifier (e.g., a tap UID). Other examples of interaction data may include transportation mode (e.g., bus, rail), destination, tap type (e.g., entry, exit, inspection, etc.), etc.

[0127] In step S714, after receiving the interaction data from the authenticator system 202, the hub computer 204 may request an existing payment token for the encrypted credential by sending the encrypted credential to the token computer 206. The token computer 206 may be part of the hub computer 204 or may be external to the hub computer 204.

[0128] In step S716, the token computer 206 may decrypt the encrypted credentials and any other interaction data (e.g., authenticator data) using the second key of the cryptographic key pair. Once decrypted, the token computer 206 may determine (e.g., exchange) a payment token for the credentials and provide it to the hub computer 204. If a payment token exists, the payment token is sent back to the hub computer 204. If a payment token does not exist, the token computer 206 notifies the hub computer 204 that a payment token does not exist and that it may generate a token for the hub computer. In some embodiments, the token computer 206 may be referred to as a token service computer or a tokenization service module and may maintain a database having a mapping between interaction data (e.g., PAN) and tokens.

[0129] In step S718, the hub computer 204 may also request an interaction data token (e.g., a touch data token) for various elements of the interaction data (e.g., touch data). For example, the interaction data token may be a string representing a collection of interaction data including credential and authenticator data (e.g., time of current trip, name of transportation system, etc.).

[0130] Although steps S714 and S718 are shown as separate steps, in some embodiments they may be combined into a single request.

[0131] In step S720 , the token computer 206 may obtain (eg, generate or retrieve) tokenized interaction data (eg, an interaction data token) and may send it to the hub computer 204 .

[0132] In step S722, the hub computer 204 can locate the user account associated with the credential, and can then store the payment token and the interaction data token along with the user account data. The user account can be managed by the hub computer and can have an account identifier associated with it. If the account identifier is not found, an account identifier can be created for the user. Note that in some embodiments, an account identifier is created for each credential used by the user. For example, if a user uses two different payment cards to access different transportation systems that communicate with the hub computer 204, the hub computer 204 can maintain two different accounts for the user with two different account identifiers.

[0133] The hub computer 204 can then determine whether the voucher is on the rejection list. If so, a debt management process can be performed, such as Fig.10 Describe the debt management process.

[0134] If the credential is not on the deny list, another decision may be made as to whether the credential was recently received by the hub computer 204. If the credential has not been received recently (e.g., within the past few days, a week or two weeks, or a month), an account verification process or pre-authorization request process may be performed as in steps S730 and S732. Figure 3 Further details on these processes are described in . If the account verification process and / or the pre-authorization request process is unsuccessful, then in step S738, the credential may be added to a deny list and the same may be performed. Fig. 9 Associated processing (described below).

[0135] If the credentials have been recently received by the hub computer 204, or if the account verification process and / or pre-authorization request process was successful, then in step S739, the hub computer 204 may send the user account identifier and interaction data (e.g., authenticator data) to the ABT service 210 for processing, the interaction data including data related to the user journey segment. In step S740, the interaction data may be used by the ABT service 210 to determine the appropriate (multiple) fares, and this may be stored with the user account identifier and interaction data. In step S742, the ABT service 210 may send an interaction data confirmation, and may be received and processed by the hub computer 204 in step S744.

[0136] Figure 7 The process shown in can be performed by each validator system as the user interacts with it during multiple segments of the user's journey from an initial location to a final location. Once a user has completed a journey on different transportation systems associated with different validator systems, a single authorization process can be performed for the user and their journey on the different transportation systems. The hub computer can receive interaction data from different validator systems for multiple interactions performed by the user at different times during the journey, at different validator devices in different validator systems, in the journey from the initial location to the final location.

[0137] Figure 8 A flow chart of performing a journey period end process for a user who has completed multiple journeys associated with multiple validator systems according to another embodiment is shown. The journey period end process can be a batch process during which the ABT service 210 can determine the payment amount for each account in the scheme and obtain the required payment.

[0138] At the end of the journey, the ABT service 210 may determine the total payment amount of the tokens used for the journey in step S812. Figure 7 In the method of , the total amount can be determined by adding the fares collected by the ABT / fare engine from different validation systems.

[0139] In step S814, the ABT service may send a payment request to the hub computer 204. The payment request may include at least an account identifier (the account identifier received in step S739) and a total amount, as well as other interaction data such as an interaction identifier.

[0140] In step S816, the hub computer 204 can determine the user's account based on the account identifier. Once the account is determined, the hub computer 204 can retrieve the payment token and any other data required to conduct the payment transaction (e.g., CVV value, expiration date, identifier of the authenticator, etc.). It can then generate an authorization request message including the payment token, the total amount, and any other relevant information and transmit it to the token computer 206.

[0141] Token computer 206, which can retrieve the credentials associated with the payment token and send a payment authorization request including the credentials to a payment gateway (e.g., using Figure 2 The secure payment service module 114 in the system).

[0142] The payment gateway 208 can continue the payment authorization process and can obtain authorization for the payment. Figure 2 The secure payment service module 114 in the hub computer 204 may generate (if it is not generated by the hub computer 204) an authorization request message with the total amount and the credential, and may transmit it to the authorization entity computer via a shipping computer (e.g., an acquirer computer) and a processing network computer (e.g., a computer in a payment processing network). The value in the authorization request message may be based on the sum of the values ​​associated with the different authenticator systems. The hub computer 204 or the service provider computer determines (e.g., calculates) the value based on the values ​​associated with the different authenticator systems.

[0143] After authorizing the authorization request message, the authorization entity computer may generate an authorization response message and transmit the authorization response message back to the payment gateway via the shipping computer and the processing network computer.

[0144] In step S832, if the payment authorization process is unsuccessful, then the credential and / or token may be added to a deny list in step S834. In step S834, the hub computer 204 may also check the liability and threshold rules and may make a decision as to whether the transaction may be cleared. If so, then in steps S836 and S838, the hub computer 204 and token computer 206 may request shared liability transaction capture.

[0145] In step S840, after successful transaction authorization in step S816 or if the transaction cannot be cleared, the result is returned. The result is then reported by the hub computer 204 to the ABT service 210.

[0146] As mentioned above, the clearing and settlement process can occur at a later time.

[0147] Fig. 9 Another flow diagram for adding a token to a deny list is shown.

[0148] In step 912 , upon receiving a request to add a token or credential to a deny list, the hub computer 204 may attempt to find the token or credential in the deny list.

[0149] In step 914, if the token or credential is not found in the deny list, the hub computer 204 may request hashed credentials (e.g., hashed PAN) from the token computer 206, and in step S916, the token computer 206 may return the hashed credentials to the hub computer 204. The hub computer 204 may then store the hashed credentials with the token and the user account identifier.

[0150] In step S918 , the hub computer 204 may add the user account including the token and hashed credentials to a deny list.

[0151] In step S926, the hub computer 204 may notify the validator system 202 to update the deny list. In step S928, the validator system 202 may receive the updated deny list notification. In step S930, the validator system 202 may provide a request to update the deny list.

[0152] Fig.10 Another flow chart for managing operator-initiated debts is shown. These are debts collected by the operator from transactions made by users for which authorization failed.

[0153] In step S1002, the hub computer 204 may look up failed payments for resubmission.

[0154] In steps S1016 , S1018 , and S1020 , the hub computer 204 may resubmit the payment authorization request to the token computer 206 , and the token computer 206 may resubmit the payment authorization request to the payment gateway 206 .

[0155] In step S1022, the hub computer 204 may record the details of the last payment attempt.

[0156] In step S1028 , if the payment is successfully authorized, the hub computer 204 may remove the token from the reject list.

[0157] In steps S1030, S1032 and S1034, if the debt is zero, the original authorization that was initially rejected is revoked because there is no debt to be charged to the user's account. The hub computer 204 can send an authorization revocation request to the token computer 206, and the token computer 206 can send the authorization revocation request to the payment gateway 208.

[0158] In step S1036, the hub computer 210 may notify the ABT service 210 of the revocation. In step S1044, the ABT service 1044 may update the user's account with an indication of successful debt recovery.

[0159] In step S1038, the hub computer 204 may submit a transaction clearing request with the token to the token computer 206, which may determine the credentials associated with the token. In step S1040, the token computer 206 may send the transaction clearing request with the credentials to the payment gateway 208, which may clear the transaction in step S1042.

[0160] Embodiments of the present invention have many technical advantages. For example, in the above method, a single authorization request message can be used to charge a user for multiple journeys on different validator systems. By doing so, the user only sees a single amount for the multiple journeys, rather than multiple charges for multiple segments of the journey. This reduces the number of messages and processing systems relative to conventional transportation ticketing and payment systems.

[0161] In addition, as will be apparent from the above description, embodiments of the present invention allow for standard interfaces for different authenticator systems, different service provider systems, and different user service systems (e.g., customer service systems). This makes it easy to integrate new authenticator systems with the hub computer. No major infrastructure changes are required before a new entity can be integrated into the hub computer.

[0162] In other words, one advantage of the embodiment is that by creating an integrated platform connecting all operator systems, users can use EMV cards to pay fares for all operator systems with the integrated platform. Another advantage of this embodiment is that both EMV and non-EMV ticketing systems are supported in a single integrated platform, thereby reducing the complexity of the payment system.

[0163] In addition, as will be explained above, each validator system can still maintain its own rejection list, which can be updated in real time when communicating with the hub computer. This can also be done while protecting sensitive credentials associated with the user (e.g., payment account number), and the validator system and service provider will not be within the scope of PCI (Payment Card Industry) compliance. Specific encryption and tokenization processes can be used to provide such advantages. Note that in the above process flow, the validator does not retain the plaintext credentials, but encrypts the credentials after receiving the credentials, and the encrypted credentials are transmitted to a secure environment in the hub computer. Tokens can be used to subsequently process transactions for user journey segments, thereby further protecting the plaintext credentials. Tokens, hashed versions of credentials, and non-sensitive account identifiers can be used by validator systems and service provider computers to request authorization, clearing, perform account verification checks, update rejection lists, etc. Therefore, journeys involving multiple validators and separate ticketing service providers can be conducted efficiently and securely.

[0164] Any software component or function described in this application can be implemented as a software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, and suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or a digital versatile disk (DVD), flash memory, etc. The computer-readable medium can be any combination of such storage devices or transmission devices.

[0165] Such programs can also be encoded and transmitted using carrier signals suitable for transmitting via wired networks, optical networks and / or wireless networks that meet multiple protocols, including the Internet. Therefore, the computer-readable medium according to an embodiment of the present invention can be created using data signals encoded with such programs. The computer-readable medium encoded with program code can be encapsulated with compatible devices or (for example, downloaded via the Internet) provided separately from other devices. Any such computer-readable medium can reside on or within a single computer product (for example, hard disk drive, CD or entire computer system), and can be present on or within different computer products in a system or network. The computer system can include a monitor, a printer, or other suitable displays for providing any result mentioned herein to the user.

[0166] The above description is illustrative rather than restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims together with their full scope or equivalents.

[0167] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0168] As used herein, the use of "a," "an," or "the" is intended to mean "at least one" unless clearly indicated to the contrary.

Claims

1. A method comprising: receiving, by the hub computer, from different validator systems, interaction data for a plurality of interactions performed by a user at different times during a journey, at different validator devices in said different validator systems, in said journey from an initial location to an end location; generating, by the central computer, an authorization request message, the authorization request message including a value associated with the interaction data of the plurality of interactions; transmitting the authorization request message to an authorization entity computer through the central computer, wherein the authorization entity computer approves or denies the authorization request message and then generates an authorization response message; as well as The authorization response message is received through the central computer.

2. The method according to claim 1, wherein the hub computer is a ticketing hub computer. 3 . The method of claim 1 , wherein the different validator systems are different transportation systems, each transportation system comprising at least one validator server and a plurality of validator devices. 4 . The method of claim 1 , wherein the value in the authorization request message comprises a sum based on values ​​associated with the different authenticator systems.

5. The method of claim 1, wherein the different validator systems are different transportation systems, each transportation system comprising at least one validator server and a plurality of validator devices, each validator device comprising an NFC reader.

6. The method of claim 1, wherein the interaction data comprises encrypted credentials and authenticator data, and wherein the method further comprises: decrypting the encrypted credential to obtain a credential; as well as The credentials are exchanged for a token.

7. The method according to claim 6, further comprising: Prior to transmitting the authorization request message, a pre-authorization process or an account verification request process is performed by the central computer using the token.

8. A method according to claim 6, wherein the value in the authorization request message includes a sum of values ​​associated with the different authenticator systems, and wherein the hub computer or a service provider computer communicating with the hub computer calculates the value based on the values ​​associated with the different authenticator systems.

9. A method according to claim 1, wherein the hub computer includes a first set of APIs (application programming interfaces) and a second set of APIs, the first set of APIs being configured to receive data from the different verification systems, and the second set of APIs being configured to receive data from different service provider computers managed by different service providers.

10. The method of claim 1, wherein the user uses a user device to interact with the different validator devices located at the different validator systems during the journey. The method of claim 10 , wherein the user device is a phone or a card. The method of claim 11 , wherein the user device includes a credential.

13. The method of claim 12, wherein the different authenticator systems respectively communicate with the hub computer using different cryptographic key pairs, wherein the different cryptographic key pairs are used to encrypt and decrypt the credentials.

14. The user device of claim 13, wherein the user device further comprises an RFID chip.

15. A central computer, comprising: processor; as well as A computer readable medium comprising code executable by the processor to perform operations comprising: receiving, from different validator systems, interaction data for a plurality of interactions performed by a user at different times during a journey, at different validator devices in said different validator systems, in said journey from an initial location to a final location; generating an authorization request message, the authorization request message comprising a value associated with the interaction data for the plurality of interactions; and transmitting the authorization request message to an authorization entity computer, wherein the authorization entity computer approves or denies the authorization request message and then generates an authorization response message; and The authorization response message is received.

16. A central computer, comprising: one or more processors; as well as one or more memory devices, the one or more memory devices comprising a first set of APIs (application programming interfaces) configured to receive data from an authenticator system interacting with a user device, the authenticator system being operated by a different authenticator, and a second set of APIs configured to receive data from a different service provider computer managed by a different service provider; Token processing module; as well as Interaction processing module.

17. The hub computer of claim 16, wherein the one or more memory devices include code executable by the one or more processors to perform operations comprising: receiving, via an API in the first API, encrypted credentials; providing the encrypted credential to a token service computer; A token is received from the token service computer. transmitting the token to a service provider computer in the different service provider computers via an API in the second set of APIs; receiving a request for a pre-authorized transaction or an account verification request from the service provider computer via the API in the second set of APIs; as well as The service provider computer is notified that the pre-authorization transaction or the account verification request was successful.

18. The hub computer of claim 17, wherein the encrypted credential is an encrypted credential, the operations further comprising: The request for the pre-authorized transaction or the account verification request is transmitted to an authorization entity computer associated with the credential.

19. The hub computer of claim 17, wherein different cryptographic key pairs are associated with the hub computer and different authenticator systems, wherein the hub computer includes a memory that stores a key associated with each key pair for each authenticator system.

20. The hub computer according to claim 17, wherein the interaction processing module is located in a secure environment on the hub computer.

Images