Patent Publication Number: US-9846861-B2

Title: Upstream and downstream data conversion

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Application No. 61/675,746, filed Jul. 25, 2012, entitled “Upstream and Downstream Data Conversion,” which is hereby incorporated by reference in its entirety for all purposes. 
    
    
     BACKGROUND 
     Embodiments of the invention improve upon existing security systems and methods. In some existing security systems and methods, entities can use tokens instead of real account numbers to conduct payment transactions. A token can be a substitute for the real account number. For example, once a merchant receives a real account number identifier from a consumer, the merchant can submit the real account number to a tokenization service system and can subsequently receive a token in return. The merchant can use the token to process the consumer&#39;s order for goods instead of the real account number, and may store the token in a database. By using and storing the token and by not storing or using the real account number, data security is improved. That is, if the token is somehow obtained by an unauthorized person, it will be useless. 
     When a merchant accepts an order from another upstream merchant, the upstream merchant may only use real account numbers and not tokens. The upstream merchant may also store the real account number in its system and refer to the order using the real account number, instead of the token. However, when the merchant accepts the order from the upstream merchant in a business transaction, the merchant has trouble getting paid by the upstream merchant, because the upstream merchant does not wish to receive or store real account numbers. It would rather store tokens. 
     It would be desirable to provide for a system and method that can provide data security and efficient payment transactions to those entities that wish to use tokens, while allowing them to receive and make payments to entities that wish to use real account numbers to process payments, rather than tokens. 
     Embodiments of the invention address this and other problems, individually and collectively. 
     SUMMARY 
     Embodiments of the invention relate to providing a token broker to assist upstream trading partners, downstream trading partners, and merchant ordering systems communicate during an order or payment process using one or more order messages (e.g., a first, second, third, and fourth order message). 
     One embodiment of the invention is directed to a method that can receive, at a broker computer, an order message comprising an order and an account token, initiate a detokenization process to detokenize the account token and to form an account identifier, generate a subsequent order message with the order and account identifier, and transmit the subsequent order message to a downstream trading partner computer wherein the downstream trading partner computer initiates a payment transaction. The order may be a second order. The payment transaction may be a second payment transaction and the account token may be a second token. The order message may be a third order message and the subsequent order message may be a fourth order message. The method may also comprise receiving a first order message comprising a first order and the account identifier from an upstream trading partner computer, initiating a tokenization process to tokenize the account identifier and to form a second account token, generating a second order message with the first order and the second account token, and transmitting the second order message to a merchant ordering system wherein the merchant ordering system initiates a first payment transaction. The third order message may be received after the first order message. The account identifier may be decrypted. The method may further comprise, after forming the account identifier, encrypting the account identifier. The account identifier may be a primary account number. The broker computer may receive the third order message via a hosted webpage. 
     Another embodiment of the invention is directed to a method that may comprise generating, at a merchant ordering system, an order message comprising an order and an account token, and transmitting, to a broker computer, the order message, wherein the broker computer initiates a detokenization process to detokenize the account token and to form an account identifier, wherein the broker computer generates a subsequent order message with the order and account identifier, wherein the broker computer transmits the subsequent order message to a downstream trading partner computer, and wherein the downstream trading partner computer initiates a payment transaction. 
     Another embodiment of the invention is directed to an apparatus comprising a computer coupled to a database, wherein the computer comprises a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method. The method may comprise receiving, at a broker computer, an order message comprising an order and an account token, initiating a detokenization process to detokenize the account token and to form an account identifier, generating a subsequent order message with the order and account identifier, and transmitting the subsequent order message to a downstream trading partner computer wherein the downstream trading partner computer initiates a payment transaction. 
     Another embodiment of the invention is directed to an apparatus comprising a computer coupled to a database, wherein the computer comprises a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method. The method may comprise generating, at a merchant ordering system, an order message comprising an order and an account token, and transmitting, to a broker computer, the order message, wherein the broker computer initiates a detokenization process to detokenize the account token and to form an account identifier, wherein the broker computer generates a subsequent order message with the order and account identifier, wherein the broker computer transmits the subsequent order message to a downstream trading partner computer, and wherein the downstream trading partner computer initiates a payment transaction. 
     These and other embodiments of the invention are described in further detail below with reference to the Figures and the Detailed Description. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows a block diagram of a system according to an embodiment of the invention. 
         FIG. 2  shows a block diagram of a system with a hosted IFRAME according to an embodiment of the invention. 
         FIG. 3  shows a block diagram of a broker system and tokenization service system according to an embodiment of the invention. 
         FIG. 4  shows sample data contained in the order database according to an embodiment of the invention. 
         FIG. 5  shows an example of a first order message transmitted between an upstream trading partner and a broker system according to an embodiment of the invention. 
         FIG. 6  shows an example of a second order message transmitted between a broker system and a merchant ordering system according to an embodiment of the invention. 
         FIG. 7  shows an example of a reply message transmitted from a merchant ordering system according to an embodiment of the invention. 
         FIG. 8  is an illustration of a merchant page used by an upstream trading partner to submit an order according to an embodiment of the invention. 
         FIG. 9  is an illustration of a hosted IFRAME used by an upstream trading partner to submit an order according to an embodiment of the invention. 
         FIG. 10  shows examples of subsystems or components. 
         FIG. 11  shows a block diagram of a transaction processing system that may be used with some embodiments of the present invention. 
     
    
    
     DETAILED DESCRIPTION 
     Prior to discussing the specific embodiments of the invention, a further description of some terms may be helpful for a better understanding of embodiments of the invention. 
     A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. 
     A “merchant ordering system” may include one or more server computers that can process orders for merchants. 
     A “trading partner system” may include a server computer used by an entity that can interact with a merchant ordering system, either directly or through an intermediary. A trading partner system may be operated by an upstream or a downstream merchant (relative to another merchant). It can provide (e.g., transmit) or receive orders, tokens, and/or account identifiers to another merchant. 
     An “upstream trading partner” may include an entity that places orders for goods or services with a merchant. The upstream trading partner may operate an upstream trading partner system, which may comprise one or more computer apparatuses. 
     A “downstream trading partner” may include an entity that accepts orders for goods or services from a merchant. The upstream trading partner may operate an upstream trading partner system, which may comprise one or more computer apparatuses. 
     There are several situations where an upstream trading partner, merchant, and downstream trading partner may interact with each other. For example, the merchant may be a telecommunications company and an upstream trading partner may be a telemarketing company that wants to pay the telecommunications company to activate telephone lines. In this example, the upstream trading partner&#39;s system can electronically transmit an order to the merchant ordering system for the new telephone lines. A downstream trading partner may be a contractor that installs the telephone lines. In this case, the merchant can pay the downstream trading partner to install the telephone lines. The merchant can send an order via the merchant ordering system to the downstream trading partner system. 
     As another illustration, a merchant may be a billing consolidator and an upstream trading partner can provide several bills to the merchant to consolidate and/or settle. The upstream trading partner can provide funds to the merchant to pay one or more downstream trading partners on behalf of the upstream trading partner. These payments could be for goods or services provided by the downstream trading partner to the upstream trading partner. 
     As yet another illustration, an upstream trading partner may be a reseller in direct contact with a consumer. For example, the upstream trading partner may purchase goods or services from a downstream trading partner with the intention of reselling them to the consumer rather than consuming or using them. Once the upstream trading partner sells the good or service to the consumer, the upstream trading partner can submit the consumer&#39;s order, via the merchant ordering system, to a downstream trading partner who may have originally offered the good or service. 
     A “tokenization service system” may include a server computer that can convert an account identifier into an account token and an account token into an account identifier. In some embodiments, the tokenization service system can accept an account token from a broker system and send the corresponding account identifier back to the broker system, and vice-versa. 
     A “token” may include a substitute for a real account identifier. It may have any suitable form. For example, it may comprise a string of alphanumeric characters of any suitable length. In some cases, the token may have the same number of characters as a real account identifier. 
     A “broker system” can include a server computer that provides an interface for receiving and transmitting order messages. The broker system may be used by several systems, including a merchant ordering system, a trading partner system, and a tokenization service system. The broker system can facilitate the interactions between these systems. For example, the broker system may receive an order message with an account identifier from an upstream trading partner system and transmit a different order message with an account token to a merchant ordering system. In another example, the broker system may receive an order message with an account token from the merchant ordering system and transmit a different order message with an account identifier to a downstream trading partner system. The broker system can include a broker computer and a plurality of databases and modules. 
     A “hosted IFRAME” may include a website that can allow the creator to display a personalized webpage without designing, generating, or hosting the webpage on their own. 
     Embodiments of the invention are directed to assisting a merchant interact with its trading partners and other entities, even when the entities have not implemented tokenization in their systems. Specifically, embodiments of the invention provide a broker system. The broker system can assist the merchant ordering system with transmitting and receiving orders for goods and services using account tokens instead of account identifiers. The broker system can exchange the account identifiers with account tokens, and vice versa, using tokenization. 
     The merchant ordering system may process the order for the upstream trading partner and submit the order to a downstream trading partner by transmitting an order message. When the downstream trading partner also does not use tokens, the downstream trading partner system accepts orders that include confidential account identifiers, because the downstream trading partner may need to use the confidential account identifier in other processing (e.g., to submit a payment transaction). Thus, in order to interact with the downstream trading partner that does not utilize tokens, the merchant ordering system may store the confidential account identifiers to identify the order in its interactions with the downstream trading partner. In this instance, the upstream trading partner system, downstream trading partner system, and the merchant ordering system use account identifiers to track the order through the respective systems. The confidential account identifier may be stored in these systems at least during the order process and thus all three systems could be vulnerable to security breaches. 
     Comparatively, as advantageously shown in an embodiment of the invention, a broker system can be implemented to assist with interactions between the upstream trading partner system, downstream trading partner system, and the merchant ordering system. In the cases where one or more of the entities use confidential account identifiers instead of tokens, the broker system can help solve the disconnect between the entities that use tokens and the entities who use confidential account identifiers instead of tokens. 
     In an embodiment, the upstream trading partner system may initiate an order for goods or services with a merchant ordering system. In this illustration, the upstream trading partner system may not recognize tokens and might transmit an order message with a confidential account identifier. The broker system can accept the order on behalf of the merchant ordering system. The broker system or tokenization service system can convert the confidential account identifier to an account token and provide the account token to the merchant ordering system. The merchant ordering system may store the token as the primary means of identifying an order message. The merchant ordering system may process the order for the upstream trading partner and submit the order to a downstream trading partner. When the downstream trading partner also does not recognize tokens, the merchant ordering system may transmit the order with the account token to the broker system. The broker system or tokenization service system can convert the account token into a confidential account identifier and provide the order with the confidential account identifier to the downstream trading partner system as a different order message. In this instance, the upstream trading partner system and downstream trading partner system use account identifiers to track the order instead of tokens. However, by using the broker system or tokenization service system and not using account identifiers, the merchant ordering system helps to protect the consumer&#39;s confidential information by using tokens. 
     Advantageously, the merchant ordering system may be PCI compliant. The Payment Card Industry (“PCI”) Data Security Standard includes suggestions for a baseline of technical and operational requirements designed to protect customers&#39; payment data. Particularly, when merchants do business with upstream trading partners (e.g., an entity who pays the merchant) and downstream trading partners (e.g., an entity being paid by the merchant), PCI standards encourage the merchants and trading partners to implement data security in the entities&#39; networks, including firewall configurations, passwords, suggested encryption standards, access rights, etc. 
     In another embodiment, the upstream trading partner may be holding payment information on behalf of a third party and the merchant ordering system may be a procurement card program, like the U.S. General Services Administration (GSA) program. The broker system can step in for the merchant to receive an order message for a new account. The broker system can tokenize the account identifier in the order message and forward the order message with a token to the billing consolidator merchant. The merchant may keep several million procurement cards under management in their procurement system as tokens. When the merchant needs to fulfill and order related to one of the tokens, the merchant ordering system can send the order message to the broker system. The broker system can convert the token to an account identifier and send the account identifier and order to the downstream trading partner for order fulfillment. When a tokenization system is not implemented, the merchant ordering system would hold a customer&#39;s account identifier (e.g., 16-digit primary account number) in order to purchase buy goods and services. 
     Embodiments of the invention have a number of advantages. The systems and methods according to embodiments of the invention can improve security and help protect the consumer payment information. For example, when a merchant stores tokens, but the upstream and/or downstream trading partner stores confidential information, the use of tokens at the merchant could improve the security with at least one entity in the transaction process. Additionally, embodiments of the invention facilitate transmissions and data exchanges between different systems as well. In some embodiments, the broker system can convert the tokens back to confidential account numbers for a downstream trading partner. Another advantage of the processes may allow the trading partners to continue to submit the account identifiers to the payment transaction process without amending their internal systems. A merchant may not need to store confidential information in its system simply to do business with an upstream trading partner who stores the confidential information instead of tokens. Systems and methods could allow entities to transmit information without substantially changing the entities&#39; internal systems. Further, a merchant may remain PCI-compliant without jeopardizing its business relationship with non-compliant trading partners. Embodiments of the invention are more secure and efficient than conventional systems. 
     Generally, embodiments relate to apparatuses, systems, and methods of implementing a broker system to exchange account identifiers for account tokens, and vice versa. In particular, some embodiments may provide decryption and tokenization services in association with a payment transaction. 
     I. Exemplary Systems of Upstream and Downstream Data Conversion 
       FIG. 1  shows a block diagram of a system according to an embodiment of the invention. The system  100  may contain an upstream trading partner system  110 , broker system  120 , tokenization service system  130 , merchant ordering system  140 , and downstream trading partner system  150 . The broker system  120  serves as a central hub, which connects the upstream trading partner system  110 , the merchant ordering system  140 , the downstream trading partner system  150 , and the tokenization service system  130 . 
     In an embodiment, the broker system  120  may be associated with a merchant associated with the merchant ordering system  140 . The merchant ordering system  140  may register with the broker system  120 . 
     A method for token exchange involving an upstream merchant can be now be described. 
     At step  1 , the broker system  120  may receive an order message from an upstream trading partner system  110 . The broker system  120  may be located (in an operational sense) between the upstream trading partner system  110 , tokenization service system  130 , merchant ordering system  140 , and/or downstream trading partner system  150 . The broker system  120  may include data processing subsystems, networks, and operations used to support and deliver tokenized account identifiers, confidential account identifiers, and other order information between the entities. The broker system  120  may be used to help exchange orders or other information between entities when some of the entities use tokens and others use confidential information to identify the order. 
     The broker system  120  may provide a host server page (e.g., hosted webpage) or a batch file system. The broker system  120  can also encrypt and decrypt data, in addition to forwarding or receiving tokens or confidential account identifiers with any computer or system. 
     The broker system  120  can serve as a proxy for the merchant ordering system to accept orders from the upstream trading partner system  110 . These orders may include confidential account identifiers. The broker system  120  can forward the orders with a confidential account identifier to the tokenization service system  130 , which can store the confidential account identifiers and generate tokens. The tokenization service system  130  can return the order with the token to the broker system  120 . 
     In an embodiment, the broker system  120  receives a first order message comprising the order and account identifier from an upstream trading partner system  110 . In some embodiments, the first order message may be received before the third order message, as explained below in relation to step  1 ′. 
     At step  2 , the tokenization service system  130  receives a confidential account identifier (e.g., primary account number) from the broker system  120  that may have originated with the upstream trading partner  110 . The tokenization service system  130  receives the confidential account identifier, and then subsequently provides the account token that relates to the confidential account identifier to the broker system  120 . 
     At step  3 , the broker system  120  can transmit a tokenized order to the merchant ordering system  140  on behalf of the upstream trading partner  110 . The merchant ordering system  140  can process the order using the tokenized order information. The merchant ordering system  140  may not need to interact with or store the confidential account identifier because the broker system  120  or tokenization service system  130  stores the confidential account identifier. 
     In an embodiment, a second order message may be generated with the order and the account token. The second order message can be transmitted to a merchant ordering system to initiate a payment transaction. 
     In some embodiments, the broker system  120  may provide a hosted webpage for the merchant ordering system  140 . The merchant ordering system  140  may transmit order messages to the broker system  120  via the webpage. For example, the broker system  120  can host the webpage to receive the third order message, which may include an order and an account token. 
     After the merchant associated with the merchant ordering system  140  has registered with a broker system  120 , the merchant ordering system  140  can accept order messages that contain an order and a token from the broker system. The merchant ordering system  140  can also send order messages that contain orders and tokens to the broker system  120  so that the broker system  120  can forward the information to other entities, including an upstream trading partner, tokenization service, and downstream trading partner. 
     The broker system  120  may also keep track of the tokens (e.g., in a database). The broker system may also provide the information that the entities exchanged to the merchant ordering system  140  and trading partner systems. This may allow the entities to generate reports through the broker system  120  (e.g., by querying the information stored in the database). 
     At any step in the process, one or more systems may submit a reply message. The reply message  180  may comprise information related to the order, a confirmation of a successful order, or other information known in the art. In an embodiment, a merchant ordering system  140  transmits a reply message  180  to a broker system  120 , which forwards the message to an upstream trading partner system  110  without substantial processing. An exemplary reply message is provided in  FIG. 7 . 
     A tokenization process involving a downstream merchant can now be described. 
     At step  1 ′, the broker system  120  may receive a third order message from a merchant ordering system  140 . In an embodiment, the third order message may be received after the first order message. 
     The third order message  160  may comprise an order and a token. In an embodiment, a merchant ordering system  140  transmits a third order message  160  to a broker system  120 . An exemplary third order message is provided in  FIG. 6 . 
     At step  2 ′, the tokenization service system  130  can accept the token from the broker system  120  and provide the confidential account identifier that relates to the account token to the broker system  120 . 
     At step  3 ′, the broker system  120  can transmit a fourth order message to the downstream trading partner system  150  or another entity, especially when the entity does not store or process orders with account tokens. 
     The fourth order message  170  may comprise an order and an account identifier. In an embodiment, a broker system  120  transmits a fourth order message  170  to a downstream trading partner system  150 . An exemplary fourth order message is provided in  FIG. 5 . 
     The broker system  120  can also provide an intermediary device or system (e.g., proxy) to interact with the downstream trading partner system  150  in an Internet based environment. As with upstream trading partners, the broker system  120  can either provide a new system or integrate the system with an existing merchant ordering system API. This allows the downstream trading partner system  150  to interact with the broker system, but not implement substantial alterations to its processing. The broker system  120  can step in for the merchant ordering system and provide a confidential account identifier to the downstream trading partner system  150 . Thus, the merchant ordering system  140  can initialize a payment with a token, the broker system can interact with the tokenization service system  130  to de-tokenize the token, and the broker system  120  can provide the de-tokenized order to the downstream trading partner system  150  for order and payment processing. The hosted web page may be a web-service API, HOP, SOP, batch file, or other similar system. In an embodiment, the tokenization service system  130  may be provided with payment services. 
       FIG. 2  shows a block diagram of a system with a hosted IFRAME according to an embodiment of the invention. The system  200  may include an upstream trading partner system  210  or customer  211  that submits an order message to a broker system  220 . 
     At step  21 , the broker system  220  can accept the order message through a hosted IFRAME. The order message may comprise an order and confidential account identifier. The hosted, embeddable IFRAME may also translate data as is it transferred between entities. 
     At step  22 , the broker system  220  can transmit the account identifier (e.g., primary account number) to a tokenization service system  230  so that the tokenization service system can convert the account identifier to an account token. The tokenization service system can transmit the token back to the broker system  220 . 
     At step  23 , the broker system  220  can transmit the order message to the merchant ordering system  240 . The order message may comprise an order and account token. The broker system  220  can also interact with the merchant ordering system through the hosted IFRAME. The hosted IFRAME can interact with the trading partners and customers to accept orders that use confidential account identifiers, tokenize the confidential account identifier contained in the order, and display the orders for the merchant ordering system. The broker system can also provide a hosted web page to the merchant ordering system customer service representatives. The hosted webpage can accept tokens and display the confidential account identifier or other payment information. 
     The broker system  220  may also implement a transaction decision engine in order to accept payment requests from the merchant ordering system&#39;s proxy. In an embodiment, the transaction decision engine can invoke the tokenization service to tokenize/de-tokenize payment data. The transaction decision engine may invoke an appropriate endpoint for order processing, so that the orders from the upstream trading partner systems can be routed to the merchant ordering system using the merchant ordering system API. Also, the orders that come from the merchant ordering system  240  can be routed to a downstream trading partner system (not shown in  FIG. 2 ) using the downstream trading partner API. Further, the orders that originate with the hosted IFRAME can be sent to the merchant ordering system  240  for processing. The transaction decision engine may also translate data formats as data is transmitted between entities. 
     In one embodiment of the invention, the broker system can post payment with the token to the merchant ordering system  240 . In another embodiment, a merchant ordering system customer service representative can enter an order with the token into the broker system&#39;s hosted webpage. The broker system  220  may call or send a request to the tokenization service system  230  to retrieve the confidential account identifier. The tokenization service system  230  can return the confidential account identifier to the broker system  220 . The broker system  220  can display the order with the confidential account identifier to the merchant ordering system&#39;s customer service representative. The merchant ordering system customer service representative can then enter the order into the merchant ordering system or other order processing system. 
       FIG. 3  shows a block diagram of a broker system  305  and tokenization service system  355  according to an embodiment of the invention. The two components may form a subsystem  300 . The broker system  305  can be coupled with and in operative communication with the tokenization service system  355 . In other embodiments, the tokenization service system  355  can be implemented as one or more modules or databases within the broker system  305 . 
     The broker system  305  can contain a broker computer  310 . The broker computer  310  can comprise a processor  312  and a computer readable medium  314  coupled to the processor  312 . The computer readable medium  314  can comprise code executable by the processor for implementing a method comprising receiving an order message (e.g., a third order message) comprising an order and an account token, initiating a detokenization process to detokenize the account token and to form an account identifier, generating a fourth order message with the order and account identifier, and transmitting the fourth order message to a downstream trading partner computer. 
     The broker computer  310  can include an input/output interface  311 , processor  312 , and computer readable medium  314 . The computer readable medium  314  may store computer code for a plurality of modules. An input/output interface  311  can be coupled to the processor  363  as well. This may be used to as an interface to receive and/or transmit data. It may comprise any suitable hardware or software 
     The processor  312  may be configured to execute the code stored in the computer readable medium  314  to implement the various methods described herein. The computer readable medium  314  can embodied by one or more memory devices, and may comprise an operating system, and several software modules. Examples of modules may include a registration module  315 , reporting module  320 , hosted payment module  325 , IFRAME services provider module  330 , processing module  335 , and transaction decision module  340 . 
     The processing module  335  may be implemented to process an order message for the broker system  305 . The processing module  335  can process order messages, and may the parse the information in them and store the data associated with them in appropriate databases. For example, the processing module  335  can receive an order message from an upstream trading partner, parse the message, extract the order information from the order message, and add information from the order message to the order database  350 . The processing module  335 , working with the processor  312 , may also transmit an account identifier to a tokenization service system  355  to initiate a tokenization process. 
     The registration module  315  can manage registration information about a merchant ordering system (e.g., name, IP address) by adding, deleting, or updating information about the merchants in the registration database  345 . The registration database  345  can maintain and store information about merchants, trading partners, or relevant entities and systems. 
     The broker system  305  can also contain an order database  350 . The broker computer  310  may be coupled to the order database  350 . The order database may maintain and store orders, account tokens and account identifiers. In some embodiments, the processing module  335  may extract information from an order message and add the order information to the order database  350 . Also, the data contained in the order database can be used by the reporting module  320  to generate reports. Examples of the data contained in the order database can be found in  FIG. 4 . 
     The reporting module  320  can process data in the order database  350  and provide reports to entities, including the merchant ordering system. For example, the merchant may want a list of all orders that were received from an upstream trading partner in the month of September. The reporting module could query the order database, generate a report that summarized the data retrieved from the order database, and provide the report to the processing module. The processing module  335 , working with the processor  312 , may then transmit the report to the merchant order system via a network. 
     The transaction decision module  340 , working with the processor  312 , can help initiate a payment transaction and manage the transaction. In an embodiment, the transaction decision module  340  can accept payment requests from various services coupled to the broker system  305 . The transaction decision module  340  can invoke the tokenization service system  355  to initiate tokenization or detokenization of payment data. 
     The hosted payment module  325  can manage information received through a hosted order page (HOP) or a silent order page (SOP) that allows the secure transmission of account identifiers and other confidential payment information. An example of a hosted order page is provided in  FIG. 9 . 
     When a hosted IFRAME is used, the IFRAME services provider module  330  can process and manage information received through a hosted IFRAME that allows the secure transmission of account identifiers and other confidential payment information. A hosted IFRAME can be implemented in a similar way to a hosted order page, as provided in  FIG. 9 . 
     The tokenization service system  355  can comprise a tokenization computer  360  and correlation database  365 . The tokenization computer  360  may be coupled to the correlation database  365 . 
     The tokenization computer  360  can receive instructions from a broker system  305  or other system to tokenize an account identifier. The tokenization computer  360  may comprise an input/output interface  361 , a processor  363 , and a computer readable medium  364 . In an embodiment, the computer readable medium  364  may be coupled to the processor  363  and the computer readable medium  364  can comprise code executable by the processor  363  for implementing the methods described herein. It should be appreciated that the tokenization computer  360  can create a unique token for each account stored in the correlation database  365 , with one token for an account number used with a particular merchant. 
     In an embodiment, one token can be shared for the purposes of a particular trading partner network between the upstream trading partner system, merchant ordering system, and downstream trading partner system. Thus, when an account identifier arrives at the tokenization service system  355  for a particular merchant, the tokenization computer  360  can determine if an account token exists for the method of payment and the tokenization. 
     The correlation database  365  can map a token with an account identifier. The token may be retrieved from the correlation database  365  by the tokenization computer  360  and transmitted to the broker system  305 . The tokens may be sent from the tokenization service system  355  to the broker system  305  according to any means known to those having ordinary skill in the art. 
       FIG. 4  shows sample data contained in an order database according to an embodiment of the invention. The order database  410  may comprise several tables or sections, including an order table  420 , account identifier table  430 , and account token table  440 . The order database  410  can be implemented in other variations of databases and is not necessarily limited to an, e.g., relational database. 
     The order table  420  can include data relating to information contained in orders. For example, the order table can include a customer number as a unique identifier for a particular customer in the order database, which may be similar to a primary key. As shown in rows  421  and  422 , the customer number would be “SMITH-J-1000.” The order table  420  can also contain particular information about the order, including item numbers, description of the items in an order, quantity of each item purchased, price, or total cost. For example, as shown in row  421 , the order table  420  can comprise a customer number (“SMITH-J-1000”), item (“TEL-1000”), description (“Establish Telephone Lines”), quantity (“5”), price (“1000.00”), and total cost (“5000.00”). In another example, as shown in row  422 , the order table  420  can include a customer number (“SMITH-J-1000”), item (“POL-1000”), description (“Establish Telephone Pole”), quantity (“1”), price (“1000.00”), and total cost (“1000.00”). 
     The account identifier table  430  may also include the primary key that correlates an entry in the account identifier table with an entry in the order table  420  and account token table  440 . The account identifier table  430  can contain information related to an account identifier, including an expiration date, CVV, and the like. For example, as shown in row  431 , the account identifier table  430  can comprise a customer number (“SMITH-J-1000”), account identifier (“4147 2900 0001 1000”), expiration date (“08/2013”), and CVV (“123”). 
     The account token table  440  can contain information related to an account token and primary key information. When the account token is first used in an order with a merchant, the account token may be generated by the tokenization service system  355 , transmitted to the order database  410  via the broker system  305 , and stored in the order database  410 . When another order message is received that includes the same account identifier correlated to the account token, the broker system may not need to request a new token from the tokenization service system. Instead, the broker system can query the order database  410  using the account identifier or other information that correlates to the token in order to retrieve the token. For example, as shown in row  441 , the account token table  440  may include a customer number (“SMITH-J-1000”), parties involved (“John Smith, Inc.; Merchant; Installer”); and the token associated with the parties (“1234ABCD9876DCBA1234ABCD9876DCBA1234-ABCD9876DCBA”). 
       FIG. 5  shows an example of a first order message transmitted between an upstream trading partner and a broker system according to an embodiment of the invention. In an embodiment,  FIG. 5  may also include an example of a fourth order message transmitted between a broker system and a downstream trading partner. The first order message  500  may include an order  510  and an account identifier  560 . The order  510  may include information relevant to identifying an order. For example, the order  510  can include a customer&#39;s name  520 , order date  530 , items to be ordered  540  and the total cost for the order  550 . 
     The first order message  500  may also contain an account identifier  560 . The account identifier can identify the true account number or other confidential information. The downstream trading partner, for example, can use the account identifier to initiate a payment transaction for goods and services. 
       FIG. 6  shows an example of a second order message transmitted between a broker system and a merchant ordering system according to an embodiment of the invention. In an embodiment,  FIG. 6  may also include an example of a third order message transmitted between a merchant ordering system and a broker system. The second order message  600  may include an order  610  and an account token  660 . The order  510  may be substantially similar to the order in the first order message  500  and comprise substantially similar information. For example, the order  610  can consist of a customer&#39;s name  620 , order date  630 , items to be ordered  640  and the total cost for the order  650 . 
     The second order message  600  may also contain an account token  660 . The account token can mask the true account identifier. The merchant, for example, can use the account token to process the order for goods and services without using the actual account number. 
       FIG. 7  shows an example of a reply message transmitted from a merchant ordering system according to an embodiment of the invention. In an embodiment, the reply message  700  originates from the merchant ordering system and is transmitted to the broker system, which acts as a pass through or proxy service to send the reply message to the upstream trading partner system. 
     II. Exemplary Methods of Upstream and Downstream Data Conversion 
       FIG. 8  is an illustration of a merchant page used by an upstream trading partner to submit an order according to an embodiment of the invention. The method may begin when a customer  805  places an order with an upstream trading partner. The upstream trading partner  810 , via an upstream trading partner system  810 ( a ), can access a merchant web page via a merchant web server  820 . While visiting the merchant page  830 , the upstream trading partner can view the details for a particular item. For example, as illustrated in  FIG. 8 , the upstream trading partner may view the details of establishing new telephone lines. Further, while visiting the merchant page, the upstream trading partner may select the “Add to Cart” button  840  to add an item to its electronic shopping cart on behalf of the customer  805 . 
       FIG. 9  is an illustration of a hosted IFRAME used by an upstream trading partner to submit an order according to an embodiment of the invention. The method may begin when a customer  905  places an order with an upstream trading partner. The upstream trading partner  910 , via an upstream trading partner system  910 ( a ), can access a merchant web page via a merchant web server  920 . While visiting the merchant page  930 , the upstream trading partner can provide confidential information  940 . For example, the confidential information may include the consumer&#39;s payment details associated with the order, including an account identifier, billing information, etc. The hosted web page may transmit the order and account identifier to the broker system for processing. 
     Further details regarding a standard HOP or SOP that could be incorporated into the above-described system can be found in U.S. patent application Ser. Nos. 13/549,187 and 13/559,250, which are herein incorporated by reference in their entirety for all purposes. 
     III. Exemplary Computer Apparatus 
     The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described Figures, including any servers or databases, may use any suitable number of subsystems to facilitate the functions described herein. Examples of such subsystems or components are shown in  FIG. 10 . The subsystems shown in  FIG. 10  are interconnected via a system bus  1045 . Additional subsystems such as a printer  1044 , keyboard  1048 , fixed disk  1049  (or other memory comprising computer readable media), monitor  1046 , which is coupled to display adapter  1082 , and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller  1041  (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as serial port  1084 . For example, serial port  1084  or external interface  1081  can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor  1043  to communicate with each subsystem and to control the execution of instructions from system memory  1042  or the fixed disk  1049 , as well as the exchange of information between subsystems. The system memory  1042  and/or the fixed disk  1049  may embody a computer readable medium. 
       FIG. 11  is a block diagram illustrating a transaction processing system  10  that may be used with some embodiments of the present invention. 
       FIG. 11  illustrates the primary functional elements that are typically involved in processing a payment transaction and in the authorization process for such a transaction. As shown in  FIG. 11 , in a typical payment transaction, a consumer wishing to purchase a good or service from a merchant uses a payment device  20  to provide payment transaction data that may be used as part of a consumer authentication or transaction authorization process. Payment device  20  may be a debit card, credit card, smart card, mobile device containing a contactless chip, computer, or other suitable form of device. 
     The portable payment device is presented to a mobile payment acceptance device  22  of a merchant  24 . For example, the acceptance device  22  could be a device reader or point of sale (POS) terminal  22  which is able to access data stored on or within the payment device. In embodiments, the portable payment device communicates account/payment information to the merchant  24  via a “card not present” transaction over a communications network, such as a cellular network, the Internet, etc. The account data (as well as any required consumer data) is communicated to the merchant  24  and ultimately to an merchant service provider  26  (such as AUTHORIZE.NET). As part of the authentication or authorization process performed by the service provider, the service provider  26  may access database  28 , which typically stores data regarding the customer/consumer/user (as the result of a registration process with the merchant, for example), the consumer&#39;s payment device, and the consumer&#39;s transaction history with the merchant. The database  28  may also include information about the merchant  24 , such as a list of the merchant&#39;s approved mobile payment acceptances device  22 . For example, upon receiving information about the payment device  20  from the merchant&#39;s mobile payment acceptance device  22 , the service provider  26  may extract information that identifies the mobile payment acceptance device  22  and validate that information against a list of approved mobile payment acceptance devices. The service provider  26  typically communicates with acquirer  30  (which manages the merchant&#39;s accounts) as part of the overall authentication or authorization process. The service provider  26  and/or acquirer  30  provide data to payment processing network  34 , which, among other functions, participates in the clearance and settlement processes that are part of the overall transaction processing. 
     Communication and data transfer between service provider  26  and payment processing network  34  is typically by means of an intermediary, such as acquirer  30 . As part of the consumer authentication or transaction authorization process, payment processing network  34  may access account database  36 , which typically contains information regarding the consumer&#39;s account payment history, chargeback or transaction dispute history, creditworthiness, etc. Payment processing network  34  communicates with issuer  38  as part of the authentication or authorization process, where issuer  38  is the entity that issued the payment device to the consumer and manages the consumer&#39;s account. Customer or consumer account data is typically stored in customer/consumer database  40  which may be accessed by Issuer  38  as part of the authentication, authorization or account management processes. Note that instead of, or in addition to being stored in account database  36 , consumer account data may be included in, or otherwise part of customer/consumer database  40 . 
     According to an embodiment, in standard operation, an authorization request message is created by the mobile payment acceptance device  22  during a consumer purchase of a good or service using a portable payment device. In some embodiments, the mobile payment acceptance device  22  of the merchant  24  may be a wireless phone or personal digital assistant that incorporates a contactless card or chip or payment acceptance application. The authorization request message is typically sent from the payment application of the mobile payment acceptance device  22  to the service provider  26 , and then to the merchant&#39;s acquirer  30 , to a payment processing network  34 , and then to an issuer  38 . An authorization request message can include a request for authorization to conduct an electronic payment transaction and data relevant to determining if the request should be granted as well as device identification information related to the mobile payment acceptance device  22 , which the service provider  26  validates against the list of approved mobile payment acceptance devices  22 . For example, it may include one or more of an account holder&#39;s payment account number, currency code, sale amount, merchant transaction stamp, acceptor city, acceptor state/country, etc. An authorization request message may be protected using a secure encryption method (e.g., 128-bit SSL or equivalent) in order to prevent unauthorized access to account or transaction data. 
     After the issuer receives the authorization request message, the issuer determines if the transaction should be authorized and sends an authorization response message back to the payment processing network to indicate whether or not the current transaction is authorized. The payment processing system then forwards the authorization response message to the acquirer. The acquirer then sends the response message to the service provider  26 , which then sends the response message to the merchant&#39;s mobile payment acceptance device  22 . The merchant is thus made aware of whether the issuer has authorized the transaction, and hence whether the transaction can be completed. 
     At a later time, a clearance and settlement process may be conducted by elements of a payment/transaction processing system. A clearance process involves exchanging financial details between an acquirer and an issuer to facilitate posting a transaction to a consumer&#39;s account and reconciling the consumer&#39;s settlement position. Clearance and settlement can occur simultaneously or as separate processes. 
     Payment processing network  34  may include a server computer. A server computer is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a web server. Payment processing network  34  may use any suitable combination of wired or wireless networks, including the Internet, to permit communication and data transfer between network elements. Among other functions, payment processing network  34  may be responsible for ensuring that a consumer is authorized to conduct a transaction (via an authentication process), confirm the identity of a party to a transaction (e.g., via receipt of a personal identification number), confirm a sufficient balance or credit line to permit a purchase, or reconcile the amount of a purchase with the consumer&#39;s account (via entering a record of the transaction amount, date, etc.). 
     The payment device  20  may take one of many suitable forms. As mentioned above, the portable payment device can be a mobile device that incorporates a contactless element such as a chip for storing payment information (e.g., a BIN number, account number, etc.) and a near field communications (NFC) data transfer element such as an antenna, a light emitting diode, a laser, etc. The portable payment device may also include a keychain device (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. The device containing the contactless card or chip, or other data storage element may be a cellular (mobile) phone, personal digital assistant (PDA), pager, transponder, or the like. The portable payment device may also incorporate the ability to perform debit functions (e.g., a debit card), credit functions (e.g., a credit card), or stored value functions (e.g., a stored value or prepaid card). 
     Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network. 
     The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention. 
     In embodiments, any of the entities described herein may be embodied by a computer that performs any or all of the functions and steps disclosed. 
     One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention. 
     A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. 
     The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents. 
     All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.