WO2017160877A1

WO2017160877A1 - Technical architecture supporting tokenized payments

Info

Publication number: WO2017160877A1
Application number: PCT/US2017/022362
Authority: WO
Inventors: Michael A. Liberty; Mike Love; Randall Dion Lund; Brent Charles Cerrato; Jaaemin LIM; Daemon KWON; Steve BACASTOW
Original assignee: Mozido Inc
Current assignee: Fintiv Inc
Priority date: 2016-03-14
Filing date: 2017-03-14
Publication date: 2017-09-21
Anticipated expiration: 2018-09-14

Abstract

Host card emulation transaction processing networks are described. In one scenario, a host card emulation transaction processing network is provided which includes the following: a trusted service manager which provisions a physical secure element application to a mobile device, a token service provider which tokenizes and de-tokenizes a primary account number with cryptographic validation, and also interfaces with a payment network to authorize transactions. The host card emulation transaction processing network further includes a key management system which securely generates, stores, distributes and deletes cryptographic key values and attributes, a credential management system which manages mobile payment applications and delivers payment credentials to the mobile payment applications, a payment acquirer which includes an interface between a merchant and the payment network, where the interface provides authorization, clearing or settlement, and a payment network which includes a transaction processing platform, the transaction processing platform being configured to process tokenized payments.

Description

TECHNICAL ARCHITECTURE SUPPORTING TOKENIZED PAYMENTS

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Patent Application Ser. No. 15/088,808, titled "Technical Architecture Supporting Tokenized Payments," filed April 1, 2016, which claims priority to and the benefit of U.S. Provisional Application Ser. No. 62/307,712, titled "Host Card Emulation Transaction Processing," filed on March 14, 2016. All of the aforementioned are incorporated by reference herein in their entirety.

BACKGROUND

[0002] Near field communication (NFC) payments involve the provisioning of payment credentials from a smart phone to a point of sale (POS) device using standard protocols such as International Standards Organization (ISO) 14443. This mobile payment method has had limited success due to the cost and security requirements related to personalization of the secure element in the smart phone which requires specialized Trusted Service Manager (TSM) software using global platform specifications.

[0003] An alternate method for provisioning credentials to smart phones is the Host Card Emulation (HCE) method. HCE overcomes some of the limitations associated with the TSM because it does not require a payment credential to be provisioned into a secure element within a smart phone. Instead, a surrogate payment credential is provisioned to the memory of the phone. This surrogate 'tokenized' credential is transmitted to the POS device of the merchant using the prevailing NFC communication protocol and application protocol data unit (APDU) sequence. Once accepted by the POS device the surrogate mobile credential is transmitted to a payment processor or an intermediary token service provider where it is translated to the payment credential of the issuing entity (e.g. Visa, MasterCard, other). The translated payment credential is then sent to the issuer for authentication.

[0004] The major payment schemes (Visa and MasterCard) have each created commercialized offerings related to HCE centric mobile payments. These offerings are often referred to as tokenization offerings. With tokenization schemes, a single use key (SUK) and/or a limited use key (LUK) are transmitted to the mobile device along with a Tokenized PAN (tPAN). It is therefore an advantage over traditional secure element centric mobile payments because there is no requirement to gain access to the secure element of the smart phone.

BRIEF SUMMARY

[0005] Embodiments described herein are directed to host card emulation transaction processing networks and to methods for implementation thereof. In one embodiment, a host card emulation transaction processing network is provided which includes the following: a trusted service manager (TSM) which provisions a physical secure element application to a mobile device, a token service provider which tokenizes and de-tokenizes a primary account number (PAN) with cryptographic validation, and also interfaces with a payment network to authorize transactions.

[0006] The host card emulation transaction processing network further includes a key management system which securely generates, stores, distributes and deletes cryptographic key values and attributes, a credential management system which manages mobile payment applications and delivers payment credentials to the mobile payment applications, a payment acquirer which includes an interface between a merchant and the payment network, where the interface provides authorization, clearing or settlement, and a payment network which includes a transaction processing platform, the transaction processing platform being configured to process tokenized payments.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0008] Additional features and advantages will be set forth in the description which follows, and in part will be apparent to one of ordinary skill in the art from the description, or may be learned by the practice of the teachings herein. Features and advantages of embodiments described herein may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the embodiments described herein will become more fully apparent from the following description and appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] To further clarify the above and other features of the embodiments described herein, a more particular description will be rendered by reference to the appended drawings. It is appreciated that these drawings depict only examples of the embodiments described herein and are therefore not to be considered limiting of its scope. The embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0010] Figure 1 illustrates a computer architecture in which embodiments described herein may operate including processing transactions.

[0011] Figure 2 illustrates a process flow performed within a technical architecture that processes tokenized payments.

[0012] Figure 3 illustrates a technical architecture for processing tokenized payments.

[0013] Figure 4 illustrates an example process flow performed within a technical architecture that processes tokenized payments.

DETAILED DESCRIPTION

[0014] Embodiments described herein are directed to host card emulation transaction processing networks and to methods for implementation thereof. In one embodiment, a host card emulation transaction processing network is provided which includes the following: a trusted service manager (TSM) which provisions a physical secure element application to a mobile device, a token service provider which tokenizes and de-tokenizes a primary account number (PAN) with cryptographic validation, and further interfaces with a payment network to authorize transactions.

[0015] The host card emulation transaction processing network further includes a key management system which securely generates, stores, distributes and deletes cryptographic key values and attributes, a credential management system which manages mobile payment applications and delivers payment credentials to the mobile payment applications, a payment acquirer which includes an interface between a merchant and the payment network, where the interface provides authorization, clearing or settlement, and a payment network which includes a transaction processing platform, where the transaction processing platform is configured to process tokenized payments. [0016] Embodiments described herein may implement various types of computing systems. These computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be mobile phones, electronic appliances, laptop computers, tablet computers, wearable devices, desktop computers, mainframes, and the like. As used herein, the term "computing system" includes any device, system, or combination thereof that includes at least one processor, and a physical and tangible computer-readable memory capable of having thereon computer-executable instructions that are executable by the processor. A computing system may be distributed over a network environment and may include multiple constituent computing systems.

[0017] A computing system typically includes at least one processing unit and memory. The memory may be physical system memory, which may be volatile, nonvolatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage such as physical storage media or physical storage devices. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.

[0018] As used herein, the term "executable module" or "executable component" can refer to software objects, routines, methods, or similar computer-executable instructions that may be executed on the computing system. The different components, modules, engines, and services described herein may be implemented as objects or processes that execute on the computing system (e.g., as separate threads).

[0019] As described herein, a computing system may also contain communication channels that allow the computing system to communicate with other message processors over a wired or wireless network. Such communication channels may include hardware-based receivers, transmitters or transceivers, which are configured to receive data, transmit data or perform both.

[0020] Embodiments described herein also include physical computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available physical media that can be accessed by a general-purpose or special-purpose computing system.

[0021] Computer storage media are physical hardware storage media that store computer-executable instructions and/or data structures. Physical hardware storage media include computer hardware, such as RAM, ROM, EEPROM, solid state drives ("SSDs"), flash memory, phase-change memory ("PCM"), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer- executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computing system to implement the disclosed functionality of the embodiments described herein. The data structures may include primitive types (e.g. character, double, floating-point), composite types (e.g. array, record, union, etc.), abstract data types (e.g. container, list, set, stack, tree, etc.), hashes, graphs or other any other types of data structures.

[0022] As used herein, computer-executable instructions comprise instructions and data which, when executed at one or more processors, cause a general-purpose computing system, special-purpose computing system, or special-purpose processing device to perform a certain function or group of functions. Computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.

[0023] Those skilled in the art will appreciate that the principles described herein may be practiced in network computing environments with many types of computing system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. The embodiments herein may also be practiced in distributed system environments where local and remote computing systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. As such, in a distributed system environment, a computing system may include a plurality of constituent computing systems. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0024] Those skilled in the art will also appreciate that the embodiments herein may be practiced in a cloud computing environment. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations. In this description and the following claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

[0025] Still further, system architectures described herein can include a plurality of independent components that each contribute to the functionality of the system as a whole. This modularity allows for increased flexibility when approaching issues of platform scalability and, to this end, provides a variety of advantages. System complexity and growth can be managed more easily through the use of smaller-scale parts with limited functional scope. Platform fault tolerance is enhanced through the use of these loosely coupled modules. Individual components can be grown incrementally as business needs dictate. Modular development also translates to decreased time to market for new functionality. New functionality can be added or subtracted without impacting the core system.

[0026] Figure 1 illustrates an example system architecture for a transaction processing platform. This transaction processing platform may be referred to as a transaction processor, a mobile wallet platform, or a "Moteaf platform" herein. Integration tier 101 is configured to manage and maintain the integrity of financial transactions including mobile wallet sessions. Integration tier 101 can also include a communication (e.g., Web services) API and/or other communication mechanisms to accept messages from channels 111. Other mechanisms include, but are not limited to: International Standards Organization ("ISO") 8583 for Point of Sale ("POS") and Automated Teller Machines ("ATM") devices and Advanced Message Queuing Protocol ("AMQP") for queue based interfaces. Each of channels 111 can be integrated to one or more mechanisms for sending messages to integration tier 101. Notification services 102 is configured to send various notifications through different notification channels 112, such as, for example, Short Message Peer-to-Peer ("SSMP") for Short Messaging Service ("SMS") and Simple Mail Transfer Protocol ("SMTP") for emails. Notification services 102 can be configured through a web services API.

[0027] Service connectors 103 are a set of connectors configure to connect to 3rd party systems 113. Each connector can be a separate module intended to integrate an external service to the system architecture. Business process services 104 are configured to implement business workflows, including executing financial transactions, auditing financial transactions, invoking third-party services, handling errors, and logging platform objects. Payment handler 105 is configured to wrap APIs of different payment processors, such as, for example, banking accounts, credit/debit cards or processor 121. Payment handler 105 exposes a common API to facilitate interactions with many different kinds of payment processors. Security services 106 are configured to perform subscriber authentication. Authorization services 107 are configured to perform client authorization, such as, for example, using a database- based Access Control List ("ACL") table.

[0028] Database 108 is configured to manage customer accounts (e.g., storing customer accounts and properties), manage company accounts (e.g., storing company accounts and properties), manage transaction histories (e.g., storing financial transaction details), store customer profiles, storing dictionaries used by the mobile wallet platform, such as, for example, countries, currencies, etc., and managing money containers. Rules engine 109 is configured to gather financial transaction statistics and uses the statistics to provide transaction properties, such as, for example, fees and bonuses. Rules engine 109 is also configured to enforce business constraints, such as, for example, transactions and platform license constraints.

[0029] Name matching engine 110 is configured to match different objects according to specified configuration rules. Matching engine 110 can be used to find similarities between names, addresses, etc. Transaction processor 121 is configured to manage financial accounts and transactions. The transaction processor 121 can be used to hold, load, withdraw and deposit funds to mobile wallet accounts. Transaction processor 121 can also be used as a common interface to a third party processor system. When used as a common interface, financial operations may be delegated to the external processor. A Clearing House subsystem of transaction processor 121 can be used to exchange the financial information with a bank.

[0030] Components of a mobile wallet platform can be connected to one another over (or be part of) a system bus and/or a network. Networks can include a Local Area Network ("LAN"), a Wide Area Network ("WAN"), and even the Internet. Accordingly, components of the mobile wallet platform can be "in the cloud". As such, mobile wallet platform components as well as any other connected computer systems and their components, can create message related data and exchange message related data (e.g., Internet Protocol ("IP") datagrams and other higher layer protocols that utilize IP datagrams, such as, Transmission Control Protocol ("TCP"), Hypertext Transfer Protocol ("HTTP"), Simple Mail Transfer Protocol ("SMTP"), etc.) over the system bus and/or network.

[0031] The components depicted in Figure 1 can interoperate to provide a number of financial and other services including but not limited to enrolling a customer for a mobile wallet, adding a stored value account (either hosted by a mobile wallet platform or a third party), adding a bank or credit union account to a mobile wallet, adding a debit or credit card account to a mobile wallet, depositing funds in a mobile wallet, withdrawing funds from a mobile wallet, paying bills from a mobile wallet, topping up a prepaid mobile account through a mobile wallet, transferring funds through a mobile wallet (nationally or internationally), making in-store purchases using a mobile wallet, making tokenized payments, and various other tasks as described herein below.

[0032] Embodiments described herein provide customers, through the use of their mobile phone, a mobile wallet application allowing them to check-in, receive offers, load cash, and make payments. In some cases, the mobile wallet application may be specific to a certain restaurant, store or other place of business. For example, in the Figures and in the description below, a restaurant is used as an example point of sale, although substantially any place of business or other establishment may be used. The application may run on any of a wide variety of existing and future mobile phones, tablets, wearable devices, laptops or other computer systems. Many different security measures may be implemented for each user's account, including specific login IDs and passwords, two-factor authentication, biometric credentials or other security measures.

[0033] The user may also be asked to create a Personal Identification Number (PIN) or other authentication credential in order to authorize certain transactions. Transactions made through the application (or "app" herein) that require a credit card are secured by requiring a PIN, a security code on the back of a credit card, or other credential. These two numbers are not saved and, at least in some embodiments, will be requested each transaction to confirm the credit card transaction.

[0034] Cashiers may also be able to make transactions through WiFi communications with the customer's mobile application. These transactions can include mobile payments, redeeming coupons, and/or claiming loyalty rewards. Cashiers may also be able to cancel transactions and make refunds, all using a tablet or other electronic device. [0035] In order to navigate and perform functions within the mobile wallet application, a user such as a cashier, manager or end user first logs in to a monetary transaction system (e.g. the transaction processing system of Figure 1). Logging into the mobile wallet platform may involve a mobile number and a password. In addition, a PIN or other credential may be required to complete any financial transaction.

[0036] At least in some embodiments, no transaction fees are involved for any of the transactions performed. In other cases, transaction fees may be implemented on a per-transaction basis. Users may be able to add more money to their account if they don't have enough to cover a transaction. User's credit card information is typically not stored on their phone; however, users will have the option to save the credit card information to their mobile wallet account if desired. In this case, the card information is securely stored on a remote cloud server and a tokenized value is returned to the phone and associated with the payment account number. Users can top off their store- specific accounts using MasterCard, Visa, American Express, Discover or other credit or debit cards. The funding account may be a stored value account similar to a gift card.

[0037] Users can earn rewards each time they make a purchase, or redeem a coupon. Rewards may be cashed in immediately, or the user may accumulate their rewards (e.g. loyalty points) and use them at a different time. In some cases, users may receive rewards simply for checking in at a store. Coupons may be provided by the headquarters or by the stores themselves, and may be updated over time. Reward points are earned when users make purchases or redeem coupons or check in to a location.

[0038] Some embodiments may also implement special types of offer points or other offers that are automatically downloaded to a user's mobile wallet application. Redemption rules may also be presented alongside the rewards or offers. Once a user has authenticated to their mobile wallet application, the user's available offers will be displayed from their favorite local and national stores. Offers may be updated each time the user logs in.

[0039] In some cases, stores may allow redemption of multiple coupons during the same visit, while other stores may only allow one coupon per visit. Each store may implement its own policies for coupon/reward redemption. In some embodiments, the store-specific mobile wallet application may provide a map that shows the location of nearby stores, and may further show the locations of stores that allow payment by mobile wallet. The store-specific mobile wallet application thus allows users to pay for items or services sold by the store, view the user's current store-specific account balance, receive promotional coupons from their favorite stores, cash in mobile coupons, recharge their account using credit or debit cards, find a retailer's closest store on a map, top up the user's stored value account (SVA) with that retailer, pay for items or services using their SVA account, apply coupons, offers, points, rewards or other promotions to their purchase to lower the purchase price, or perform other tasks.

[0040] Such embodiments allow customer-to-merchant payments by means of a mobile device. The transaction may be initialized by the customer's geo-targeted check-in into the store. Indeed, as will be further described below, a user may check in to a certain store location simply by opening their store-specific (or generic) mobile wallet application within a specified geographic area around the store. By checking in, the customer allows the cashiers to select the customer and bill them for any provided goods or services. The user can confirm payment from their SVA, and their SVA will be debited for the indicated amount. As customers purchase items through their mobile wallet application, they may receive loyalty points from a certain store, or points that transfer to other national chain stores of the same brand (or the same family of brands).

[0041] The technical architectures described herein (e.g. in Figures 1 and 3) may provide a variety of different features, including any one or more of the following: managing and operating mobile payment services, managing multiple issuers and external system interfaces, provisioning and managing of card account data on a mobile device, data preparation for the personalization of payment applications, life cycle management of profiles, accounts, and end-users, etc. The mobile payment services may include account provisioning and de-provisioning, replenishment, suspend/resume, get transaction log, end-user registration, mobile device change, reporting of a lost or stolen device, recovery or factory reset of a mobile device, profile registration, approval, update, delete, suspend, resume, key generation, derivation, rotation, and deletion for payment applications, mobile payment application (i.e. software development kit (SDK)) management, Rule-Based Access Control (RBAC), supporting rule and workflow engines, provide a flexible configuration environment, provide support for various payment channels including near-field communication (NFC), barcode, quick response (QR) code, Bluetooth radio services, etc.

[0042] The technical architectures described herein may also provide a general reporting tool. This general reporting tool may provide quick and simple service onboarding, resulting in a solution that is quicker to market. The technical architectures support event-based end-user lifecycle management, which provides automatic reaction for end-user lifecycle notifications. Based on the notification type and the reason code, an issuer portal can request an NFC service or notify a portal user of the recommended action to perform based on the received notification. Using a template service provided by the technical architecture, the issuer or issuer administrator may register and deploy a new service with only a few service parameters.

[0043] In one embodiment, as illustrated in Figure 2, there may be six participants: a payment account issuer 201, a token service provider (TSP) 202, the MoTeaf platform of Figure 1 as a transaction processing platform 203, a third party token platform 204 comprised of a Credential Management System (CMS), a subscriber's mobile device 205, and a merchant terminal 206. The participants may be configured to operate together to perform the following sequence: In Step 1, the payment account issuer 201 transmits to the TSP 202 a message comprising: a customer master key (e.g. 'CMK' which also can also denote a Card Master Key which is associated with the issuer PAN), a primary account number (PAN) and various detailed information about the transaction (noted as "CMK+PAN+details" herein). In Step 2, the TSP creates a message including a tokenized PAN (tPAN) and a user key (CUK), noted as "tPAN+CUK." In Step 3, the TSP 202 transmits to the CMS of the token platform 204 a message comprising the tPAN+CUK.

[0044] In Step 4, the CMS of the token platform 204 derives the tPAN+LUK. In Step 5, the transaction processing platform transmits to the mobile device 205 a message comprising the tPAN+LUK. In Step 6, the mobile device stores the tPAN+LUK. In Step 7, the mobile device transmits to the terminal 206 an instruction to initiate the APDU sequence (e.g. a tap). In Step 8, the terminal 206 transmits to the mobile device an APDU sequence response. In Step 9, the subscriber device 205 derives the tPAN+cryptokey. In Step 10, the mobile device 205 transmits to the terminal 206 a message comprising the tPAN+cryptokey+details. In Step 11, the terminal 206 transmits to the MoTeaf platform a message including the tPAN+cryptokey+details (via the acquirer). In Step 12, the Moteaf platform 203 transmits the tPAN+cryptokey+details to the TSP. In Step 13, the TSP 202 decrypts and derives the issuer PAN. In Step 14, the TSP 202 transmits to the issuer PAN+details through the MoTeaf platform 203.

[0045] Figure 3 illustrates a host card emulation transaction processing network 300 that includes some or all of the following components: a trusted service manager (TSM) 308 that is operable to perform secure element and secure domain management and secure element life-cycle management services, a token service provider 310 operable for tokenization and de-tokenization of primary card account numbers (PAN) and associated cryptogram validation, a credential management system 309 operable for remote management of mobile payment applications (e.g. 304), delivery of payment credentials to mobile payment applications, and associated encryption key management, and an account enablement system 307 operable for new cardholder on-boarding, cardholder identification and verification, and payment account digitization.

[0046] The host card emulation transaction processing network 300 may also include a terminal that includes a point of sale device 313 located at a merchant, a mobile device 301 which further includes a mobile wallet application 302, a secure element 303, and a mobile payment application 304, where the mobile payment application manages end-user card account data and secure communication sessions from the mobile device. The network 300 further includes a mobile wallet application 302 operable to provide a human user interface for the purpose of selecting digitized payment cards for payments, a key management system 311 that is operable to generate, store, distribute, and delete cryptographic keys and their associated attributes, a synchronization server 312 that supports request-response functions between the various elements of the network 300, and a payment acquirer 314 operable to serve as the interface between the point of sale device 313 and a payment network 315.

[0047] Still further, the host card emulation transaction processing network 300 may include a payment credential issuer 318 which further includes an authorization system 316 and a customer information system 317, where the payment credential issuer is operable to create and revoke payment account numbers, an issuer portal 306 that is operable as a web-based management portal 306 for administrators of the payment credential issuer, a mobile wallet server or platform 305 operable to perform life cycle management related to mobile payment applications 304 and associated configurations of mobile payment applications, and a payment network 315 operable to transport payment authorization messages between the acquirer 314 and a trusted service provider 310.

[0048] In some cases, the payment network 315 of the host card emulation transaction processing network 300 and the mobile wallet platform 305 each include a transaction processing platform. This transaction processing platform may be the same as or similar to the transaction processing platform 100 of Figure 1 (i.e. the Moteaf platform). This transaction processing platform 100 may include one or more of the following components: an integration tier 101 configured to manage mobile wallet sessions and maintain the integrity of financial transactions, where the integration tier 101 also includes a communication API and other communication mechanisms to accept messages from channels 111, a notification service 102 configured to send notifications through different notification channels including short message peer-to-peer, short-message services and simple mail transfer protocol emails.

[0049] The transaction processing platform 100, which may be part of the transaction processing network 300 and/or the mobile wallet platform 305, may further include service connectors 103 configured to connect to third party systems, where each connector is deployed as a separate module intended to integrate an external service to the system architecture, business process services 104 configured to implement business workflows, including executing financial transactions, auditing financial transactions, invoking third-party services, handling errors, and logging platform objects, a payment handler 105 configured to wrap APIs of different payment processors including banking accounts, credit and debit cards or processors, where the payment handler 105 exposes a common API to facilitate interactions with many different kinds of payment processors.

[0050] The transaction processing platform 100 may also include security services 106 configured to perform subscriber authentication, authorization services 107 configured to perform client authorization using a database-based access control list table, a database 108 configured to manage customer accounts, manage company accounts, manage transaction histories, store financial transaction details, store customer profiles, store dictionaries used by the transaction processing platform including countries and currencies, and manage money containers, a rules engine 109 configured to gather financial transaction statistics and use the gathered statistics to provide transaction properties including fees and bonuses, where the rules engine also enforces business constraints including transaction and platform license constraints.

[0051] The TSM (308) may request provisioning of credentials to a secure element using connection Ά'. Account enablement system (307) is operable to send secure element credentials to TSM (308) using connection 'Β'. Using this method, the tPAN may be securely stored in the secure element of the mobile device. This embodiment thereby provides enhanced security over the tPAN.

[0052] The Token service provider (310) can receive notifications from the payment application (304) via the credential management system (309) using connections 'L' and 'F' . The token service provider (310) can send a response message to the payment application (304) using connections Έ' and 'L' . The notification request and response may be part of a life cycle management request.

[0053] Connector 'G' is a connector between the account enablement system (307) and the token service provider (310) to facilitate card specification change notifications such as a new card or lost card notification. The token service provider (310) can receive the lost card and new card notification message from the account enablement system (307) and update the token service provider database to reflect this change notification. A transaction received by the token service provider (310) after a card has been disabled will be rejected during the de-tokenization process.

[0054] The TSM (308) is operable to securely provision credentials to the secure element (303) using connector 'FT . The credentials may be one or more of an issuer card number, a tokenized credential, or an alternate credential such as a loyalty system credential. It is thus an advantage of this architecture to include a TSM for the purpose of provisioning a payment or non-payment credential to the secure element or memory of the mobile device. The loyalty credential can be transmitted from the secure element or a memory of the mobile device to the POS device during the APDU sequence and associated with the tPAN of the user. As a result, this architecture can facilitate a persistent loyalty credential of the user, which can be associated with the tokenized PAN.

[0055] The loyalty credential may also be stored in the token service provider (310) and associated with the tPAN during payment transactions. In this alternate embodiment, during payment processing, the token service provider can derive the loyalty credential using the tPAN, and further associate the loyalty credential with the issuer PAN. A single loyalty credential of the user may be associated with multiple tPANs associated with the user. It is thus an advantage of the technical architecture described herein to allow a persistent loyalty credential to be stored on the mobile device and to be transmitted with each payment transaction or, instead, to store the persistent loyalty credential within the token service provider. In both scenarios, the payment transaction details (e.g. merchant, products, amounts) can be associated with a tokenized payment transaction of the user wherein the user can earn benefits when an associated tPAN is used.

[0056] In another embodiment, the user's persistent loyalty credential can be stored in both the mobile device and within the TSP. Using this method, the TSP can compare the loyalty credential that is transmitted from the mobile device and included within the payment transaction to the previously stored persistent loyalty credential on the TSP. If there is a match between the persistent loyalty credential that is transmitted from the mobile device and the persistent loyalty credential that is stored on the TSP and associated with the tPAN included in the payment transaction, the user can earn an additional benefit for the payment transaction. It is thus an advantage of this method to encourage the user to use the mobile device disclosed herein that includes a mobile wallet and mobile payment application and further includes a persistent loyalty credential of the user for making payment transactions using a tokenized credential.

[0057] In this embodiment, the mobile device can transmit the persistent loyalty credential within the ISO 8583 payment transaction (using Figure 3, connector Q). Or, if the POS application included in the POS Device (Figure 3, 313) does not support the additional data element, the mobile device is operable to transmit the persistent loyalty credential using an alternate connector. The alternate connector may be one of the previously described connectors in Figure 3 including connectors L, H, J, and M. It is thus an advantage of this embodiment to provide multiple methods for transmitting the persistent loyalty credential of the user during a payment transaction and wherein the TSP can associate the persistent loyalty credential of the user with the payment transaction during de-tokenization and wherein the user can earn an additional benefit when the persistent loyalty credential transmitted from the mobile device matches the persistent loyalty credential stored on the TSP and associated with one or more tPANs of the user. [0058] The TSP (310) is further operable to aggregate loyalty transaction data across merchants and tPANs. A consumer may have multiple tPANs, where each tPAN is associated with a different issuer PAN. A first tPAN may be associated with, for example, a MasterCard™ account of the user and a second tPAN may be associated with a VISA™ account of the user. A single persistent loyalty credential may be associated with the first tPAN and the second tPAN. It is therefore an advantage of the transaction processing platform described herein to allow users to aggregate loyalty points for tokenized payment transactions even if the tPANs are associated with multiple issuer PANs.

[0059] Connection 'J' is used for a card enrollment notification message from the account enablement system (307) to the wallet (302) instantiated within the mobile device (301). Connection 'K' is used to receive card personalization data from the customer information system (317) of the issuer (318). Connection 'M' facilitates enrollment and life cycle management functions of the wallet (302) instantiated within the mobile device (301). Connection 'N' is used by the third-party wallet server (305) to facilitate know-your-customer (KYC) validation with the customer information system (317) of the issuer (318).

[0060] Connections Ό' and 'P' are the administrative interfaces that connect the issuer portal (306) to the account enablement system (307). Connection 'Q' depicts the flow of the tPAN from the mobile device (301) through the POS (313) to the acquirer (314). Connection 'R' depicts the flow of the tPAN from the acquirer (314) to the payment network (315). Connections 'Q' and 'R' can be used to send other required and optional data elements from the mobile device (301) and the POS (313). An optional data element may be the persistent loyalty credential of the user. Required data elements may include common data elements used by the payment processor and associated with a payment transaction of an ISO 8583 or other standardized payment transaction format.

[0061] Connection T is a unique connection of the tokenized payment architecture. For example, non-tokenized payment credentials are forwarded by the payment network (315) to the authorization system (316) of the issuer using connection ' S' . Alternatively, tokenized payment credentials, such as the tPAN or other surrogate payment credentials, are first be translated into the payment credential of the issuer. Connection T facilitates the transmission of the surrogate tPAN to the token service provider (310). Token service provider (310) can use a database table to associate the tPAN with the issuer PAN. Or, in another embodiment, the token service provider (310) can compute the issuer PAN using the tPAN. In this manner, an embodiment is provided that protects the issuer PAN from unauthorized disclosure. After the issuer PAN has been determined by the token service provider (310), the issuer PAN is returned to the payment network (315) using connection .

[0062] The transaction processing platform 100 may further include one or more storage media having stored computer-executable instructions which, when executed by at least one processor, implement a system for processing a tokenized mobile payment transaction. The system for processing a tokenized mobile payment transaction may perform the following steps to process a tokenized mobile payment transaction: 1. the payment credential issuer (e.g. 318) transmitting to the token service provider (TSP) a message including: customer master key (CMK)+PAN+details relating to the customer payment account ("account details" or "details" herein), 2. responsive to the message from the payment credential issuer, the TSP 308 creating a message including the tPAN+LUK (or SUK), 3. the TSP transmitting to the credential management system of the same token platform (or a third-party token platform) a message including the tPAN+LUK (or SUK), 4. the credential management system of the token platform (e.g. 309) transmitting to the mobile device (e.g. 301) a message including the tPAN+LUK (or SUK), 6. the mobile device 301 storing the tPAN+LUK (or SUK), 7. the mobile device transmitting to the terminal (313) an instruction to initiate an APDU sequence, 8. the terminal transmitting to the mobile device an APDU sequence response, and 9. the subscriber mobile using one of the LUK or SUK, deriving the tPAN+cryptokey from additional data included in the APDU response.

[0063] The steps performed by the system for processing a tokenized mobile payment further include 10. the mobile device 301 transmitting to the terminal a message including the tPAN+cryptokey+details, where the message is transmitted to the payment acquirer 314, 11. the payment acquirer 314 transmitting to the transaction processing platform 100 included within the payment network 315 a message inlcuding: tPAN+cryptokey+details, where the message is received by an API of the integration tier of the transaction processing platform 100 and is further processed by a payment handler of the transaction processing platform, 12. the transaction processing platform transmitting the tPAN+cryptokey+details message to the token service provider (310), where the message is transmitted using an API of the integration tier 101 and a service connector 103 of the transaction processing platform, 13. the token service provider (310) decrypting the message and deriving the issuer PAN, and 14. the token service provider transmitting to the transaction processing platform a message including: PAN+details, where the message is received by an API of the integration tier of the transaction processing platform, and is further processed by a payment handler of the transaction processing platform 100. Step 15 includes the transaction processing platform transmitting a message to the credential issuer including the PAN+details, where the message is transmitted using an API of the integration tier 101 and a service connector 103 of the transaction processing platform.

[0064] In one specific embodiment, a host card emulation transaction processing network 300 includes at least some of the elements shown in Figure 3. The host card emulation transaction processing network 300 includes a TSM 308 which provisions a physical secure element application 303 to a mobile device 301, a token service provider 310 which tokenizes and de-tokenizes a PAN with cryptographic validation, and further interfaces with a payment network 315 to authorize transactions. The host card emulation transaction processing network 300 further includes a key management system 311 which securely generates, stores, distributes and deletes cryptographic key values and attributes, a credential management system 309 which manages mobile payment applications (e.g. 304) and delivers payment credentials to the mobile payment applications 304. In some cases, this may include delivering card profiles and/or sets of cryptographic keys.

[0065] The host card emulation transaction processing network 300 may further include a payment acquirer 314 which has an interface between a merchant and the payment network 315. The interface provides authorization, clearing and/or settlement within the payment network 315, which itself includes a transaction processing platform (e.g. the Moteaf platform 100 of Figure 1), where the transaction processing platform is configured to process tokenized payments. The host card emulation transaction processing network 300 may further include a point of sale device 313 which accepts payment for items or services as part of a transaction, and a mobile device 301 which includes a mobile payment application 304 and a secure element 303 for securely receiving, storing and processing secure transaction information. [0066] The host card emulation transaction processing network 300 may further include a payment credential issuer (e.g. 318) which includes an authorization system 316 configured to authorize user-initiated transactions, and a user/customer information system 317 configured to manage and store user information. The network 300 may also include a mobile wallet platform 305 configured to provide a user interface on the mobile device that enables users to select and use digitized credit or debit cards for payment.

[0067] The trusted service manager 308 of the host card emulation transaction processing network 300 may be configured to provide security domain management and secure-element-based near-field communication (NFC) lifecycle management, thereby facilitating NFC payments within the network. The token service provider 310 may be configured to generate a token that includes a surrogate PAN value that is used in place of an account PAN in payment transactions. This surrogate PAN allows transactions to be processed using the PAN without directly transmitting the PAN. Tokenization of the PAN may include replacing a cardholder account PAN with a tokenized PAN that comprises a surrogate value that is used in place of the cardholder account PAN in payment transactions. De-tokenizing the PAN may include mapping the tokenized PAN back to its underlying cardholder account PAN by reference to a token store managed by the token service provider 310. The de-tokenization may be performed using the same token service provider 310 that was used for tokenization of the PAN.

[0068] As mentioned above, and in this embodiment, the transaction processing platform 100 configured to process tokenized payments may include any or all of the following components: an integration tier 101 configured to manage mobile wallet sessions and maintain the integrity of financial transactions, the integration tier also including a communication application programming interface (API) and other communication mechanisms to accept messages from channels 111, a notification service 102 configured to send notifications 112 through different notification channels including short message peer-to-peer, short-message services and simple mail transfer protocol emails, and a service connector 103 configured to connect to third party systems 113. Each service connector 103 may be deployed as a separate module intended to integrate an external service to at least a portion of system architecture. The transaction processing platform 100 also includes a business process service 104 configured to implement business workflows, including executing financial transactions, auditing financial transactions, invoking third-party services, handling errors, or logging platform objects.

[0069] The transaction processing platform 100 further includes a payment handler 105 configured to wrap APIs of different payment processors 121 including banking accounts, credit and debit cards or processors. The payment handler exposes a common API to facilitate interactions with many different kinds of payment processors. The transaction processing platform 100 may also include a security service 106 configured to perform subscriber authentication, an authorization service 107 configured to perform client authorization using a database-based access control list table, a database 108 configured to manage customer accounts, manage company accounts manage transaction histories, store financial transaction details, store customer profiles, store dictionaries used by the transaction processing platform including countries and currencies, or manage money containers, and a rules engine 109 configured to gather financial transaction statistics and use the gathered statistics to provide transaction properties including fees and bonuses. The rules engine may be further configured to enforce business constraints including transaction and platform license constraints.

[0070] In one embodiment, the host card emulation transaction processing network further 300 includes one or more storage media having stored computer- executable instructions which, when executed by the at least one processor, implement a method for processing a tokenized mobile payment transaction. This method includes: a payment credential issuer (318) transmitting to the account enablement system (307) a message including a customer master key (CMK), the PAN, and one or more associated details. Responsive to the message from the payment credential issuer, the account enablement system (307) sends a message including the issuer PAN and details to the credential management system (e.g. 309). A tPAN and a LUK (or SUK) are derived by the credential management system 309. The credential management system 309 transmits to a mobile device 301 a message including the tPAN+LUK (or SUK). A point of sale terminal 313 transmits to the mobile device an application protocol data unit (APDU) sequence response, and then the payment acquirer 314 transmits to the transaction processing platform included within the payment network a message comprising: tPAN+cryptokey+details.

[0071] The method for processing a tokenized mobile payment transaction further includes an API of the integration tier 101 of the transaction processing platform 100 receiving the message and passing the message to the payment handler 105 of the transaction processing platform for processing. The transaction processing platform transmits the tPAN+cryptokey+details message to the token service provider 310, where the message is transmitted using an API of the integration tier and a service connector 103 of the transaction processing platform. The token service provider decrypts the message and derives the issuer PAN. The token service provider then transmits to the transaction processing platform a message including the issuer PAN+details, where the message is received by an API of the integration tier 101 of the transaction processing platform 100 and is further processed by a payment handler 105 of the transaction processing platform. The transaction processing platform 100 then transmits a message to the credential issuer including the PAN+details. The message is transmitted using an API of the integration tier and a service connector of the transaction processing platform.

[0072] In the host card emulation transaction processing network, the mobile device stores the tPAN+LUK, transmits to the terminal 313 an instruction to initiate an APDU sequence, derives the tPAN+cryptokey from the APDU response, and transmits to the POS a message comprising the tPAN+cryptokey+details. The message is then transmitted to the payment acquirer and the tokenized mobile payment transaction is processed.

[0073] Turning now to Figure 4, a host card emulation transaction processing network payment process is described, with at least some components that are similar to or the same as those in Figure 3. For instance, Figure 4 includes a customer 401, a mobile wallet client application 402, a payment software application 403 which refers to a payment application or payment network that is running the application, a mobile wallet server 404, a credentials management system 405, an account establishment system 406, a token service provider 407 and an issuer system 408. Each of these components may work together to perform a method for provisioning an account and using that account to process a payment.

[0074] The host card emulation transaction processing network may perform the following steps related to the provisioning of a payment account: 1. the payment credential issuer 408 requests load personalization data including a wallet ID, service ID, service version and personalization data request sent to the account enablement system (e.g. using issuer portal 306) (410), 2. the account enablement system 406 generates a token message including a token type, original PAN, original PAN expire date, tPAN, token expire date, card master key (CMK), and account parameters, where the message is sent to the token service provider 407. The account enablement system 406 checks eligibility for the customer (410.1), and the eligibility information is sent to the issuer 408 (410.2). The account enablement system 406 further looks up a standard identifier representation (SIR) for the customer 401 (410.3). If the SIR is found, it is returned and if not, one is generated (410.4). The SIR is then provided to the issuer 408 (410.5). The issuer then provides the personalized data for the customer to the account enablement system 406 (411).

[0075] The steps performed by the host card emulation transaction processing network further include: 3. the token service provider 407 generates the tokenized PAN in accordance with a request (412). At step 4, the tokenized PAN is then returned to the account enablement system (413) and stored (414). At step, 5. the account enablement system 406 sends a notification message to the mobile wallet platform 404 (415), and 6. the mobile wallet platform sends a push message to the mobile wallet application 402 instantiated within a mobile device of the customer 401 (416). The push message may be delivered using an API of the integration tier 101 and notification services 102 of the of the transaction processing platform 100.

[0076] Step 7 includes the payment credential issuer 408 sending an activation code to the mobile wallet application instantiated within the mobile device (418). In step 8, a consumer 401 responding to the activation code (419), causes the mobile wallet application 402 to provision a payment account to the payment application instantiated within the mobile device (420), 9. the payment application creates a secure session with the credentials management system using the wallet ID, SIR, operation code, and activation code (421), 10. the credentials management system 405 verifies the activation code (421.1), 11. the credentials management system 405 generates a secure session ID (421.2) and sends it to the payment application (421.3), 12. the credentials management system 405 thus establishes a secure communication session with the payment application instantiated within the mobile device using the secure session ID (421), and 13. the payment application decrypts the session ID (422), where the session ID is decrypted using a key included in the mobile device.

[0077] Step 14 includes the payment application 403 generating an authentication code and MS key (423), 15. the payment application sending an authentication message to the credentials management system 405 (424), where the message includes a wallet ID and authentication code. 16. The credentials management system 405 verifies the authentication code (424.1), 17. the credentials management system 405 generates an MS key (424.2), 18. the credentials management system 405 sends a "get personalization data" message to the account enablement system 406 (425), where the message includes the wallet ID and SIR. Step 19 includes the account enablement system 406 retrieving the personalization data associated with the request (425.1), step 20 includes the account enablement system 406 sending the personalization data to the credentials management system 405 (425.2), step 21 includes the credentials management system 405 using the secure session to provision the personalization data to the payment application (424.3), and step 22 includes the payment application 403 decrypting the provisioning data using the MS key (426).

[0078] Step 23 includes the payment application 403 saving the personal data to a memory of the mobile device (427), step 24 includes the payment application 403 re- encrypting the provisional data with the MS key and a counter (428), step 25 includes the payment application 403 sending an activation proof message to the credentials management system 405 (429), where the message includes the wallet ID and proof of the original request. Step 26 includes the credentials management system 405 notifying the account enablement system 406 that the account is successfully provisioned (430), where the message includes the change of state and SIR. In step 27, the account enablement system 406 updates the state of the successfully provisioned credential (430.1), in step 28, the account enablement system 406 sends a notification message to the token service provider 407 (430.2), where the message includes the new state, SIR, and additional data. In step 29, the account enablement system 406 sends a notification message to the mobile wallet system (431), where the message includes the new state of the credential and the wallet ID.

[0079] Step 30 includes the account enablement system 406 sending a notification message to the payment credential issuer 408 (432), where the message includes the SIR, operation type, and state. Step 31 includes the credentials management system 405 generating a single use key (SUK) or limited use key (LUK) associated with the payment credential (433), step 32 includes the credentials management system 405 sending a provisioning message to the payment application instantiated within the mobile device (434), where the message includes the limited use key or the single use key. Optionally, the payment application 403 may save the LUK and/or the SUK (435) and may further request activation proof of the credentials management system 405 (436). The credentials management system 405 may then update the keys (436.1), and notify the account enablement system 406 of the key state (436.2), whereupon the account enablement system 406 notifies the token service provider 407 of any key state changes (436.3). The credential management system 405 then generates a LUK and/or SUK (436.4) and sends encrypted key information or an end of session indication to the payment application 403 (437).

[0080] Next, step 33 includes the payment application 403 notifying the mobile wallet application instantiated within the mobile device regarding the account state change (438), where the message includes an account reference ID, and in step 34, the mobile wallet application displays a message to the consumer that a new account has been provisioned (439). If the customer is successfully provisioned, the customer can make payments through the POS with the cloud-based payment account of the mobile client. Payment accounts created in this manner may be managed by the system, including the lifecycle of the account and account parameters.

[0081] In some cases, an enrollment request may be denied by the issuer 408. The issuer 408 may inform the mobile wallet server 404 that the return value is denied. The mobile wallet server 404 returns the request denial to the mobile wallet client application 402. If the mobile wallet client application 402 which is requested to provision a card product does not exist, (i.e. provisioning of an invalid mobile client is requested), the issuer 408 receives an error notification of the invalid client access.

[0082] In one specific embodiment, a host card emulation transaction (HCET) processing platform is provided (e.g. platform 300 of Figure 3). In this embodiment, the HCET 300 includes a processor, a receiver that receives a temporary personal account number (tPAN) and a limited use key (LUK) or a single use key (SUK), a storing module for storing the tPAN and LUK or SUK, an application protocol data unit (APDU) initiating module that initiates an APDU sequence with a point of sale (POS) terminal, a deriving module that derives a combination tPAN and cryptographic key, and a transmitter that transmits the derived combination tPAN and cryptographic key to the POS. In such cases, the tPAN and cryptographic key and one or more details are sent to a credential management system of a third party token platform where the cryptographic key is decrypted and the issuer's PAN is identified. This HCET platform, like the other platforms described above, may be used to provision customer payment accounts and process tokenized payments between customers and merchants. [0083] In one specific embodiment the TSM (e.g. 308 of Figure 3) transmits a persistent loyalty credential of the user to the secure element of the mobile device. The credential management system (e.g. 307 of Figure 3) also transmits the persistent loyalty credential of the user to the TSP (e.g. 310 of Figure 3). The TSP associates the persistent loyalty credential of the user with the tPAN and stores the associated information for use in subsequent payment transactions.

[0084] In one specific embodiment, the user's persistent loyalty credential can be stored in both the mobile device and within the TSP. Using this method, the TSP can compare the loyalty credential that is transmitted from the mobile device and included in the payment transaction to the previously stored persistent loyalty credential on the TSP. If there is a match between the persistent loyalty credential that is transmitted from the mobile device and the persistent loyalty credential that is stored on the TSP and is associated with the tPAN included in the payment transaction, the user can earn an additional benefit for the payment transaction. It is thus an advantage of this method to encourage the user to use the mobile device disclosed herein that includes a mobile wallet and mobile payment application, and further includes a persistent loyalty credential of the user for making payment transactions using a tokenized credential.

[0085] The concepts and features described herein may be embodied in other specific forms without departing from their spirit or descriptive characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the disclosure is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

CLAIMS We claim:

1. A host card emulation transaction processing network, comprising the following components:

a trusted service manager (TSM) which provisions a physical secure element application to a mobile device;

a token service provider which tokenizes and de-tokenizes a primary account number (PAN) with cryptographic validation, and further interfaces with a payment network to authorize transactions;

a key management system which securely generates, stores, distributes and deletes cryptographic key values and attributes;

a credential management system which manages mobile payment applications and delivers payment credentials to the mobile payment applications;

a payment acquirer which includes an interface between a merchant and the payment network, the interface providing at least one of authorization, clearing or settlement; and

the payment network which includes a transaction processing platform, the transaction processing platform being configured to process tokenized payments.

2. The host card emulation transaction processing network of claim 1, further comprising:

a point of sale device which accepts payment for items or services as part of the transaction; and

the mobile device which includes a mobile payment application and a secure element for securely processing transaction information.

3. The host card emulation transaction processing network of claim 1, further comprising:

a payment credential issuer which includes an authorization system configured to authorize user-initiated transactions, and a user information system configured to manage and store user information; and

a mobile wallet platform configured to provide a user interface on the mobile device that enables users to select and use digitized cards for payment.

4. The host card emulation transaction processing network of claim 1, wherein the trusted service manager is further configured to provide security domain management and secure-element-based near-field communication lifecycle management.

5. The host card emulation transaction processing network of claim 1, wherein the token service provider generates a token that comprises a surrogate PAN value that is used in place of an account PAN in payment transactions.

6. The host card emulation transaction processing network of claim 1, wherein tokenization of the PAN comprises replacing a cardholder account PAN with a tokenized PAN that comprises a surrogate value that is used in place of the cardholder account PAN in payment transactions.

7. The host card emulation transaction processing network of claim 6, further comprising de-tokenizing the PAN, wherein de-tokenization comprises mapping the tokenized PAN back to its underlying cardholder account PAN by reference to a token store managed by the token service provider.

8. The host card emulation transaction processing network of claim 7, wherein de-tokenization is performed using the same token service provider that was used for tokenization of the PAN.

9. The host card emulation transaction processing network of claim 1, wherein the transaction processing platform configured to process tokenized payments further comprises:

an integration tier configured to manage mobile wallet sessions and maintain the integrity of financial transactions, the integration tier also including a communication application programming interface (API) and other communication mechanisms to accept messages from channels;

a notification service configured to send notifications through different notification channels including short message peer-to-peer, short-message services and simple mail transfer protocol emails;

a service connector configured to connect to third party systems, wherein each connector is deployed as a separate module intended to integrate an external service to at least a portion of system architecture;

a business process service configured to implement business workflows, including at least one of executing financial transactions, auditing financial transactions, invoking third-party services, handling errors, or logging platform objects;

a payment handler configured to wrap APIs of different payment processors including banking accounts, credit and debit cards or processors, the payment handler exposing a common API to facilitate interactions with many different kinds of payment processors;

a security service configured to perform subscriber authentication; an authorization service configured to perform client authorization using a database-based access control list table;

a database configured to manage customer accounts, manage company accounts manage transaction histories, store financial transaction details, store customer profiles, store dictionaries used by the transaction processing platform including countries and currencies, or manage money containers; and a rules engine configured to gather financial transaction statistics and use the gathered statistics to provide transaction properties including fees and bonuses, the rules engine being further configured to enforce business constraints including transaction and platform license constraints.

10. The host card emulation transaction processing network of claim 9, further comprising one or more storage media having stored computer-executable instructions which, when executed by the at least one processor, implement a method for processing a tokenized mobile payment transaction, the method comprising:

a payment credential issuer transmitting to the token service provider a message comprising: a customer master key (CMK), the PAN, and one or more associated details;

responsive to the message from the payment credential issuer, the token service provider creating a message comprising a tPAN and a user key (CUK);

the token service provider transmitting to the token service provider a message comprising the tPAN+CUK;

the token service provider deriving the tPAN+ limited use key (LUK); the token service provider transmitting to a mobile device a message comprising the tPAN+LUK;

a point of sale (POS) device transmitting to the mobile device: an application protocol data unit (APDU) sequence response; the payment acquirer transmitting to the transaction processing platform included in the payment network a message comprising: tPAN+Cryptokey+Details;

an API of the integration tier of the transaction processing platform receiving the message and passing the message to the payment handler of the transaction processing platform for processing;

the transaction processing platform transmitting the tPAN+Cryptokey+Details message to the token service provider, the message being transmitted using an API of the integration tier and a service connector of the transaction processing platform;

the token service provider decrypting the message and deriving the issuer PAN;

the token service provider transmitting to the transaction processing platform a message comprised of the PAN+details, the message being received by an API of the integration tier of the transaction processing platform and further processed by a payment handler of the transaction processing platform; and

the transaction processing platform transmitting a message to the credential issuer comprised of the PAN+Details, the message being transmitted using an API of the integration tier and a service connector of the transaction processing platform.

11. The host card emulation transaction processing network of claim 10, wherein the mobile device stores the tPAN+LUK, transmits to the terminal an instruction to initiate an APDU sequence, derives the tPAN+cryptokey from the APDU response, and transmits to the POS a message comprising the tPAN+Cryptokey+details, the message being transmitted to the payment acquirer.

12. A host card emulation transaction processing network, comprising the following:

a trusted service manager (TSM) which provides a physical secure element for a mobile device;

a token service provider which tokenizes and de-tokenizes a card primary account number (PAN) with cryptographic validation, and further interfaces with an issuer or payment processor to authorize a transaction; a credential management system which manages mobile payment applications and delivers payment credentials to the mobile payment applications;

an account enablement system which is configured to onboard cardholders, digitize cards and identify and verify cardholders;

a terminal comprising a point of sale device;

a plurality of mobile devices, wherein each mobile device includes a mobile wallet application, a secure element, and a payment application;

a plurality of mobile device users;

a payment acquirer which includes an interface between a merchant and a payment network, the interface providing authorization, clearing and settlement;

a payment credential issuer which facilitates communication between a user and an issuer; and

13. The host card emulation transaction processing network of claim 12, wherein the host card emulation transaction processing network is configured to perform the following steps related to the provisioning of a payment account:

the payment credential issuer requesting load personalization data using a wallet ID, service ID, service version and personalization data, the request being sent to the account enablement system;

the account enablement system generating a token message comprised of a token type, an original PAN, an original PAN expire date, a tokenized PAN (tPAN), a token expire date, a card master key (CMK), and one or more account parameters, the message being sent to the token service provider; the token service provider generating the tPAN in accordance with the request;

the token service provider returning the tPAN to the account enablement system;

the account enablement system generating and storing personalization data;

the account enablement system sending a notification message to the mobile wallet platform;

the payment credential issuer sending an activation code to the mobile wallet application instantiated within the mobile device; the credentials management system verifying the activation code; the credentials management system generating a secure session ID; the credentials management system establishing a secure communication session with the payment application instantiated within the mobile device using the secure session ID;

the credentials management system verifying the authentication code; the credentials management system generating an MS key;

the credentials management system sending a get personalization data message to the account enablement system, the message including the wallet ID and service ID;

the account enablement system retrieving the personalization data associated with the request;

the account enablement system sending the personalization data to the credentials management system;

the credentials management system using the secure session to provision the personalization data to the payment application;

the credentials management system notifying the account enablement system that the account is successfully provisioned, the message including the change of state and service ID;

the account enablement system updating the state of the successfully provisioned credential;

the account enablement system sending a notification message to the token service provider, the message including the new state and service ID; the account enablement system sending a notification message to the mobile wallet system, the message including the new state of the credential and the wallet ID;

the account enablement system sending a notification message to the payment credential issuer, the message including the service ID, operation type, and state;

the credentials management system generating one of a single use key

(SUK) or a limited use key (LUK) associated with the payment credential; and the credentials management system sending a provisioning message to the payment application included in the mobile device, the message including one of the LUK or the SUK.

14. The host card emulation transaction processing network of claim 13, further comprising:

a consumer responding to the activation code, causing the mobile wallet application to provision a payment account to the payment application included in the mobile device;

the mobile wallet platform sending a push message to the mobile wallet application included in the mobile device, the push message being delivered using an API of the integration tier and notification services of the of the transaction processing platform; and

the mobile wallet application displaying a message to the consumer that a new account has been provisioned.

15. The host card emulation transaction processing network of claim 14, further comprising:

a payment application creating a secure session with the credentials management system using the wallet ID, service ID, operation code, and activation code;

the payment application decrypting the session ID using a key stored within the mobile device;

the payment application generating an authentication code and master service (MS) key;

the payment application sending an authentication message to the credentials management system, the message including a wallet ID and authentication code;

the payment application decrypting the provisioning data using the MS key;

the payment application saving the personal data to a memory of the mobile device;

the payment application re-encrypting the provisional data with the MS key and a counter;

the payment application sending an activation proof message to the credentials management system, the message including the wallet ID and proof of the original request; and the payment application notifying the mobile wallet application instantiated the mobile device regarding the account state change, the message including an account reference ID.

16. The host card emulation transaction processing network of claim 13, wherein an enrollment request is received from at least one of the plurality of mobile device users, and wherein the enrollment request is denied by the issuer.

17. The host card emulation transaction processing network of claim 16, further comprising the issuer generating a return value for the denied enrollment request, and sending the return value to the mobile wallet platform, whereupon the mobile wallet platform sends the return value to the mobile wallet application.

18. The host card emulation transaction processing network of claim 12, further comprising, wherein the mobile wallet platform further comprises:

a security service configured to perform subscriber authentication; an authorization service configured to perform client authorization using a database-based access control list table; a database configured to manage customer accounts, manage company accounts manage transaction histories, store financial transaction details, store customer profiles, store dictionaries used by the transaction processing platform including countries and currencies, or manage money containers; and a rules engine configured to gather financial transaction statistics and use the gathered statistics to provide transaction properties including fees and bonuses, the rules engine being further configured to enforce business constraints including transaction and platform license constraints.

19. One or more storage media having stored thereon computer-executable instructions which, when executed by at least one processor, implement a method for processing a tokenized mobile payment transaction, the method comprising:

a payment credential issuer transmitting to a token service provider (TSP) a message comprising: a customer master key (CMK), a PAN, and one or more associated details;

responsive to the message from the payment credential issuer, the token service provider creating a message comprising a tokenized PAN (tPAN) and a LUK (or SUK);

the TSP transmitting to a credentials management system of a third party token provider a message comprising the tPAN+CUK;

the third party token platform deriving the tPAN+ LUK (or SUK); the token service provider transmitting to a mobile device a message comprising the tPAN+LUK (or SUK);

a point of sale (POS) device transmitting to a mobile device an application protocol data unit (APDU) sequence response;

a payment acquirer transmitting to a transaction processing platform included in a payment network a message comprising: tPAN+Cryptokey+Details, wherein the details are further comprised of a persistent loyalty credential of the user;

an API of an integration tier of the transaction processing platform receiving the message and passing the message to a payment handler of the transaction processing platform for processing;

the TSP decrypting the message and deriving an issuer PAN;

the TSP transmitting to the transaction processing platform a message comprised of the PAN+details, the message being received by an API of the integration tier of the transaction processing platform and further processed by a payment handler of the transaction processing platform; and

20. The method of claim 19, wherein the mobile device performs the following:

stores the tPAN+LUK;

stores a persistent loyalty credential of the user in the secure element;

transmits to the terminal an instruction to initiate an APDU sequence;

derives the tPAN+cryptokey from the APDU response; and

transmits to the POS a message comprising the tPAN+Cryptokey+details, the message being transmitted to the payment acquirer and including the persistent loyalty credential of the user.

21. The method of claim 19, wherein the TSP compares a loyalty credential that is transmitted from the mobile device and included in the payment transaction to a previously stored persistent loyalty credential on the TSP, and wherein, if there is a match between the persistent loyalty credential that is transmitted from the mobile device and the persistent loyalty credential that is stored on the TSP and is associated with the tPAN included in the payment transaction, the user earns an specified benefit for the payment transaction.