WO2010096245A2

WO2010096245A2 - Secure representation of payment information

Info

Publication number: WO2010096245A2
Application number: PCT/US2010/022170
Authority: WO
Inventors: Tseryeng Lin
Original assignee: Tseryeng Lin
Priority date: 2009-02-17
Filing date: 2010-01-27
Publication date: 2010-08-26
Also published as: WO2010096245A3

Abstract

A payment service provider of an apparatus in an example provides a secure representation of payment information of a customer for employment by a merchant to engage in a transaction with the customer upon receipt by the merchant of the secure representation and without receipt by the merchant of the payment information.

Description

SECURE REPRESENTATION OF PAYMENT INFORMATION DESCRIPTION OF THE DRAWINGS

[0001] Features of exemplary implementations of the invention will become apparent from the description, the claims, and the accompanying drawings in which:

[0002] FIG. 1 is a representation of an implementation of an apparatus that comprises a customer, a merchant, a payment service provider, a financial network, and a plurality of links.

[0003] FIG. 2 is a representation of an exemplary interaction flow such as for a secure payment transaction through employment of an implementation of the apparatus of FIG. 1.

[0004] FIGS. 3 and 4 are representations of an exemplary logic flow such as for a secure payment transaction through employment of an implementation of the apparatus of FIG. 1.

[0005] FIGS. 5 through 8 are representations of exemplary views displayed to the customer in connection with a checkout of the merchant and a securer of the payment service provider of an implementation of the apparatus of FIG. 1.

[0006] FIG. 9 is a representation of exemplary data transformation for encryption in a secure payment transaction of the apparatus of FIG. 1.

[0007] FIG. 10 is a representation of exemplary data transformation for tokenization in a secure payment transaction of the apparatus of FIG. 1.

[0008] FIG. 1 1 is a representation of exemplary merchant profile maintained by the payment service provider of an implementation of the apparatus of FIG. 1. DETAILED DESCRIPTION

[0009] In conducting payment transactions online, it may be desirable to protect customers' payment information. A relatively large infrastructure exists for financial transactions with a large number of participants. A customer may bear undesirable risk when sending sensitive payment information, such as the customer's credit card number, to a merchant's online system such as on the Internet. The risk may result from the handling of the sensitive payment information by the merchant and/or by an unverified level of data security on the hardware/software of the merchant's system.

[0010] A merchant^'s system in a previous design may have depended on software, hardware, and internal staff policy to protect the customer's sensitive payment information. A breach of security and compromise of the payment information may harm the customer and the merchant. Financial damage to the customer from the breach may take time and effort to repair and/or address. The breach may expose the merchant to liability and negative publicity.

[0011] Following reported data security breaches of high profile online stores, the electronic commerce industry established a payment data security standard known as PCI DSS (Payment Card Industry Data Security Standard; URL: HTTP Secure World Wide Web pcisecuritystandards.org/security _standards/pci_dss.shtml). PCI DSS may be understood to place responsibility on merchants for perpetual costs of implementation, maintenance, and audit for data security. PCI DSS may be further understood to not guarantee impenetrability of the merchant's system.

[Θ012] In an exemplary operation under PCI DSS, a customer submits completely clear text payment information from the customer's credit card to a merchant. The merchant receives the completely clear text payment information and places the completely clear text payment information on the merchant's transaction equipment. The merchant submits the completely clear text payment information to a payment service provider (PSP; URL: HTTP en.wikipedia.org/wiki/Payment__service_provider), to request authorization for the transaction. [0013] The payment industry in one approach following PCl DSS employs tokenization (URLs: HTTP en.wikipedia.org/wiki/rokenization and World Wide Web merchantaccountguide.com/merchanl-accoυnt-news/how-tokenization-works.php) to replace sensitive data with identification symbols. Upon authorization, the payment service provider returns a token to the merchant, instead of the credit card number, along with an authorization code for the transaction. The token is considered safe to store on the merchant's system. The merchant replaces the clear text payment information with the token. Since the clear text payment information has been received by the merchant initially in an example the burden lies upon the merchant to provide certification and/or audits by a third party to ascertain that the clear text payment information has been properly guarded and/or disposed of within the merchant^'s system.

[0014] It may be noted that the tokenization within merchant's system occurs after the initialization where the merchant receives the clear text payment information from the customer and communicates the clear text payment information to the payment service provider. The merchant's initialization of receiving the clear text payment information from the customer makes the merchant undesirably responsible for PCI-DSS Compliance. It may be further noted that the tokenizalion of the payment information is initiated by the merchant and performed after authorization is obtained from the payment service provider. Such an approach in the payment industry may be viewed as merchant- initiated, post-authorization tokenization.

[0015] It may be desirable to promote a reduction in effort and/or resources asked of merchants to implement and/or maintain PCI-DSS Compliance on their online stores. It may be desirable to promote a reduction in direct and/or collateral damage that may result in an event of compromise of data security in the merchant^'s system. It may be desirable to promote a reduction in availability of customer payment information in the merchant's system. It may be desirable to reduce general usability of payment information to a third party beyond execution of a transaction authorized by the customer. It may be desirable to promote a reduction of changes and/or additional development, entities, administration, accommodation, and/or maintenance for infrastructure, computing devices, and/or communication employed that correspond to a desirable level of security. It may be desirable to promote reduction of potential points of failure in security and/or transaction execution. It may be desirable to promote reliability and/or security of transactions such as by entities participating in the transactions. It may be desirable to promote reduction of number of entities actively involved in security such as among the entities participating in the transactions. It may be desirable to promote reduction of behavioral changes asked of participants, such as the customer, merchant, and/or payment service provider involved in the transaction to promote increased security. It may be desirable to provide and/or promote exclusion of the merchant from receipt and/or access to the customer's payment information. It may be desirable to allow a customer to engage in a transaction with a merchant without giving the merchant the customer's payment information in a plain, clear, and/or readily usable form. It may be desirable to employ customer-initiated and/or pre-authorization secureness, for example, tokenization and/or encryption.

[0016] An exemplary implementation guides a customer to generate a secure representation of the customer's payment information through employment of the payment service provider employable with the merchant to perform payment processing. The secure representation in an example comprises an encrypted and/or tokenized representation of the customer's payment information. The secure representation in an example is limited to the target merchant's system, for example, in service as a payment instrument. For example, the secure representation in an example is unusable as a payment instrument on a merchant system other than the merchant system targeted upon generation of the secure representation. In a further example, the customer may selectively set one or more limitations and/or restrictions, for example, a time limitation such as expiry and/or a quantity limitation such as maximum authorizable payment amount. For example, the customer may set expiry limitations upon generation of the secure representation such that presentation of the secure representation to the target merchant after the set expiry will be declined by the payment service provider.

[0017] Turning to FIG. 1 , an implementation of an apparatus 100 comprises one or more customers such as customer 120, one or more merchants such as merchant 140, one or more payment service providers such as payment service provider 160, one or more financial networks such as financial network 180, and/or one or more corresponding links such as one or more of links 102, 106, 108, and/or 110. The customer 120, the merchant 140, the payment service provider 160, and/or the financial network 180 in an example comprise a corresponding one or more of an interface, messaging entity, and/or communicator, an online system, an information repository and/or processor, and/or an instruction and/or selection medium, for example, coupled with and/or on behalf of one or more of a business entity and/or one or more users and/or humans. The customer 120, the merchant 140, the payment service provider 160. and/or the financial network 180 in an example comprise exemplary instances among a plurality of available instances of the customer 120, the merchant 140, the payment service provider 1.60, and/or the financial network 180 in the apparatus 100. The links 102, 106, 108, 110 in an example comprise communication passages, pathways, and/or connections such as one or more electronic, mechanical, hardware, optical, wireline, computer software, and/or wireless links, for example, as part or coupled with one or more of an online system, a telephone network, a local area network (LAN), a wide area network (WAN), the Internet, a wireless network, and/or a cloud computing system.

[0018] The customer 120 in an example represents a customer boundary. The customer 120 in an example comprises one or more sessions 122, 124, payment information 126, and secure representation 128. The payment information 126 represents one or more payment instruments such as credit card information, bank checking account information, and/or account login and password, for example, for third party payment entities such as PayPal™ (URL: HTTP Secure World Wide Web paypal.com). The sessions 122 and 124 in an example comprise one or more of a user interface, a web browser, a communication, a computer, a smart phone, a mobile computing, and/or a PC (personal computer) session. The sessions 122, 124 in an example employ respective browser sessions. In another example, the sessions 122, 124 employ a single browser session such as through employment of an inline frame, for example, the HTML iframe tag (URL: HTTP en.wikipedia.org/wiki/IFrame#Frames).

[0019] The customer 120 in an example employs first and second isolated and/or secure communication sessions as the sessions 122, 124, respectively. A first isolated and secure communication session as the session 122 in an example employs a first domain such as an Internet domain name of the merchant 140. A second isolated and secure communication session as the session 124 in an example employs a second domain such as an Internet domain name of the payment service provider 160. Isolated and secure communication sessions on respective domains in an example as the sessions 122, 124 may communicate and/or transfer data and/or information, for example, through employment oi~ a copy and/or paste function and/or a cross-domain communication function, technique, and/or activity as selected, directed, operated, controlled, and/or guided by the customer 120,

[0020] The secure representation 128 in an example is based on the payment information 126. Payment information 126 of the customer 120 in an example is secured, for example, by tokenization and/or encryption, rather than provide the payment information 126 directly to the merchant 140. Payment information 126 of the customer 120 in an example is replaced with the secure representation 128 for presentation to the merchant 140 in place of the payment information 126. The secure representation 128 in an example serves as a payment instrument from the customer 120 to the merchant 140. Additional discussion of the secure representation 128 is presented herein.

[0021] The merchant 140 in an example represents a merchant boundary. The customer 120 and the merchant 140 in an example employ the link 102 for communication. The merchant 140 in an example comprises a checkout 142, a merchant identification 144, a payment request 146, and a database 148. The checkout 142 in an example comprises a payment processing location of the merchant 140. The checkout 142 in an example comprises and/or presents one or more of a computing, imaging, and/or interactive interface, form, screen, and/or display 500 (FIG. 5) such as for selection, engagement, and/or transaction between the customer 120 and the merchant 140. The session 122 in an example serves to connect the customer 120 to the merchant 140 for a potential transaction. The session 124 in an example serves to send and/or provide the secure representation 128 to the checkout 142. The merchant identification 144 in an example comprises a unique text string assigned by the payment service provider 160 (FIG. 1 1). Upon receipt of the secure representation 128 in an example the checkout 142 creates the payment request 146. The payment request 146 in an example comprises a merchant identification 144 of the merchant 140 requesting payment, the secure representation 128, and the requesting authorization amount, for example, of the information 501 (FIG. 5). Upon authorization, the checkout 142 in an example stores the secure representation 128 safely in the database 148. The checkout 142 in an example serves to cause the secure representation 128 to be associated, connected, and/or aligned with the particular customer 120, for example, profile data of the customer 120. The storage of the secure representation 128 in the database 148 in an example serves to facilitate future transactions between the customer 120 and the merchant 140, for example, promoting reduction, avoidance, and/or obviation of repetition in entry of information and/or data by the customer 120 at the checkout 142.

[0022] The payment service provider 160 in an example comprises and/or may present one or more of a computing, imaging, and/or interactive interface, form, screen, and/or display 600 (FIG. 6) such as for selection, engagement, and/or authorization between the customer 120 and the payment service provider 160, for example, in connection with a transaction between the customer 120 and the merchant 140. The payment service provider 160 in an example comprises a securer 162, a security processor 164, and one or more cipher keys 166 associated with the profile of each merchant 140. FIG. 11 illustrates an exemplary association of merchant ID 144 and cipher key 166 with a particular merchant 140. The cipher key 166 in an example comprises a cipher key, for example, a cipher key that is unique in the apparatus 100. Each cipher key of a plurality of cipher keys 166 in an example is unique for a respective merchant 140 of a plurality of merchants 140. For example, a message encrypted with a particular cipher key as a first cipher key 166 cannot be decrypted using another cipher key as a second cipher key 166 such as in communication among the customer 120, the merchant 140, the payment service provider 160, and/or the financial network 180. The securer 162 in an example encapsulates and/or transforms the payment information 126 of customer 120 and/or additional restrictions into a secured representation 128. The securer 162 in an example associates the secure representation 128 with the merchant 140 and returns the secure representation 128 to customer 120 for presentation to the merchant 140 as a payment instrument. The checkout 142 in an example employs the secure representation 128 to create the payment request 146. The security processor 164 can make security determinations such as merchant mismatch and/or violation of the additional payment restrictions. The security processor 164 in an example employs the information 501 (FIG. 5) from the payment request 146 to determine if the associated and/or indicated merchant 140 of the secure representation 128 matches the merchant 140 payment requesting. In a further example, the security processor 164 employs the information 501 (FIG. 5) from the payment request 146 to determine occurrence of violation of any payment restrictions that the customer 120 may have set.

[0023] The securer 162 and the security processor 164 in an example employ encryption, for example, through pre-association of a profile of the merchant 140 with the cipher key 166. The securer 162 in an example employs the cipher key 166 of the target merchant, the payment information 126, and additional payment restrictions set by customer 120 to create and/or generate the secure representation 128. The securer 162 in an example creates and/or generates merchant specific secure payment information as the secure representation 128. The security processor 164 employs the payment requesting merchant's cipher key 166 and the secure representation 128 to make the security determinations.

[0024] The securer 162 and the security processor 164 in an example employ tokenization. The securer 162 in an example stores information such as a 1002 (FIG. 10) that comprises the payment information 126, additional payment restrictions 605 (FIG. 6) such as "Encryption Expires" field 606 and/or "Maximum Amount" field 607, and merchant identification 144 of the target merchant. The securer 162 employs the information in an example to create, generate, and/or return the secure representation 128, for example, a token and/or identifier associated with the stored information 1002. . The security processor 164 employs the secure representation 128 to retrieve the information 1002, for example, to make the security determinations. Additional discussion of the securer 162. security processor 164, and the secure representation 128 is presented herein. [0025] The customer 120 and the merchant 140 in an example employ the link 102 for communication. The customer 120 and the payment service provider 160 in an example employ the link 106 for communication. The communication links 102 and 106 are established as secured isolated channels such that the communication occurring within one link cannot be observed or accessed by another. The merchant 140 creates a payment request 144 using the secure representation 128 submitted by customer 120, and sends the payment request 144 to the payment service provider 160 thru link 108 for processing, and awaits for an approval or decline response from the payment service provider 160.

[0026] The financial network 180 in an example serves to process and/or settle financial transactions, for example, on a wide scale. The payment service provider 160 and the financial network 180 in an example employ the link 1 10 for communication. The financial network 180 comprises a system of financial entities that communicate to manage the processing, clearing, and settlement of payment transactions. The financial network 1 80 in an example employs relatively strict security in communication and/or relatively complex protocols, for example, that may vary with payment types. The merchants 140 in an example rely on payment service providers 160 as intermediaries to the financial network 180. In another example, the merchants Ϊ40 perform direct communication with the financial network 160 such as to perform one or more communications otherwise performable by the payment service providers 160 as intermediaries to the financial network 180.

[0027] An illustrative description of an exemplary operation of encryption in connection with the secure representation 128 is presented, for explanatory purposes. Turning to FIGS. 2 and 3, in an exemplary logic flow 300 at STEP 301, the customer 120 in an example approaches the merchant 140 for a potential transaction, for example, through employment of the session 122. The customer 120 in an example enters a website and/or online system of the merchant 140, for example, through employment of the session 122. The customer 120 in an example employs the session 122 to browse and/or search one or more items offered by the merchant 140. At STEP 302 in an example the customer 120 through employment of the session 122 decides to pursue committing capital to a transaction such as a purchase of an item offered for sale by the merchant 140. Referring Io FIGS, 1 through 3 and 5, at STEP 303 in an example the customer 120 employs the session 122 to reach and/or arrive at the checkout 142.

[0028] Referring to FIG. 5, the display 500 of the checkout 142 in an example comprises and/or presents information 501 and/or one or more fields 502. The information 501 in an example comprises descriptive, order, price, and/or labeling details, for example, identification of the merchant 140, stage heading of the checkout 142, and/or item and/or payment source option listing for the customer 120. The fields 502 in an example comprise payment execution facilitators such as a securer selector 503, an insertion box 504 for the secure representation 128, and/or a submission selector 506. The customer 120 in an example employs the securer selector 503 and the insertion box 504 in connection with the secure representation 128. The securer selector 503 in an example serves to allow and/or select employment of encryption of the payment information 120 by the payment service provider 160 into the secure representation 128 such as for return of the secure representation 128 to the merchant 140, for example, as input to the insertion box 504. The customer 120 in an example employs the session 122 to access the securer selector 503 at the checkout 142 and employs the session 124 to obtain secure representation 128 from the securer 162 at the payment service provider 160 for return to the merchant 140 and input to the insertion box 504 at the checkout 142.

[0029] The checkout 142 in an example presents the securer selector 503 and the insertion box 504 to the customer 120, where a previous approach may have had the customer 120 proceed to direct insertion of the payment information 126 at the merchant 140 such as credit card information of the customer 120. In a previous approach, the customer 120 otherwise may expect to enter the payment information 126 such as credit card information upon accessing the checkout 142. In an exemplary contrast at STEP 303, the checkout 142 in an example displays the securer selector 503 such as a link activator, the insertion box 504 for the secure representation 128. and the submission selector 506.

[0030] The securer selector 503 in an example comprises a merchant identification 144 of the particular merchant 140 issued by payment provider 160, for example, among a plurality of merchants 140 that employs payment service provider 160 for online payment processing. Merchant identification 144 (FIG. 11) of the particular merchant 340 in an example of the securer selector 503 comprises data, for example, a string of alpha-numeric text, employable by the payment service provider 160 for identification of the particular merchant 140 among a plurality of merchants 140 that employ payment service provider 160. The securer selector 503 comprises an identification of the particular merchant 140 for transmission and/or sharing with the payment service provider 160 at STEP 304 in an example upon activation and/or invocation by the customer 120, for example, to create and/or generate the secure information 128. The securer selector 503 at STEP 304 in an example upon activation and/or invocation by the customer 120 during employment of the session 120 employs and/or starts a separate communication session as the session 124.

[0031] The session 124 in an example accesses, engages, communicates, and/or connects with the securer 162 of the payment sendee provider 160. Upon access to the securer 162 in the session 124 in an example the securer 162 identifies the target merchant 140 from the merchant identification 144 embedded in the requesting URL and the payment service provider 160 presents the display 600 to the customer 120. Referring to FIGS. 3 and 6, the display 600 of the payment service provider 160 at STEP 304 in an example comprises and/or presents information 601 and/or one or more field groups 602.

[0032] The information 601 in an example comprises descriptive, order, and/or labeling details, for example, identification of the payment service provider 160, identification of the target merchant 140, stage heading of the securer 162, and/or item and/or payment source option listing for the customer 120. The field groups 602 in an example comprise a payment type selector 603 a field group 604 for the corresponding payment type selected, for example, for credit card payment. The information in an example comprises the card number, card expiration date, and card security code. Additional restrictions 605 in an example serve to allow customer 120 to further limit the authorization of payment information of the customer 120. The ''Encryption Expires^"' field as an example of an additional restriction 605 may serve to set an expiry to the secure representation 128. For example, presenting the secure representation 128 to the payment service provider 160 after the valid period would result in a declined response. Referring to FIG. 7, the display 600 is employable with an e-commerce business allowing payments and money transfers to be made through the Internet. For example, the display 600 is employable with an e-commerce business such as offered under the trade identifier PayPal® (HTTP en.wikipedia.org/wiki/Pay_Pal).

[0033] Upon submission of the requested fields on a form as the display 600 at STEP 306 by the customer 120, the securer 162 receives the information comprising the target merchant identification 144, the payment information 126, and the additional restriction directives set by fields 605 in form 600 to create or generate a secure representation 128. The securer 162. in an example, at STEP 306 employs encryption technology to create the secure representation 128. The securer 162 retrieves a cipher key 166 associated with the target merchant and employs the cipher key 166 to encrypt the payment information 126 and additional restrictions from fields 605 into a secure representation 128.

[0034] Referring to FIG. 9, an exemplary data transformation of the encryption process. The clear text information 902 represents the payment information 126 and additional restrictions 605 submitted from form 600. Encrypting the clear text information 902 using the cipher key 166 associated with merchant 140 generates the secure representation 128. The same cipher key 166 can be used to decrypt the secure representation 128 and retrieve the clear text information 902 for processing at later stage.

[Θ03S] Referring to FIG. 3 and FIG. 8, the generated secure representation 128 from session 124 is transferred into the insertion box 504 from session 122. The transfer of the secure representation 128 can be accomplished by either a manual copy-and-paste procedure performed by the customer 120, or automatically by employing the cross- domain communication programming technique (URLshttp://msdn.microsoft.com/en- us/architecture/bb735305.aspx). Isolated and secure communication sessions on respective domains as the sessions 122, 124 in an example employ cross-domain communication. A cross-domain communication approach in an example provides for data that is transfcrrable between the sessions 122, 124 from one session can be transferred to another isolated communication session programmatically. Cross-domain communication with the sessions 122, 124 in an example allows convenient and secure transfer of the secure representation 128. generated by the securer 162 in session 124, to the insertion box 504 in session 122. For example, cross-domain communication with the sessions 122, 124 may serve to obviate a previous need for manual copy and pasting by the user, while maintaining desirable and/or appropriate security/privacy principles in networked communication.

[0036] At STEP 308, the customer 120 submits the secure representation 128 displayed in insertion box 504 to checkout 142 as payment instrument for processing. At STEP 310, upon receiving the secure representation 128, the merchant 140 in an example creates a payment request 146 that comprises the merchant identification 144 of the payment requesting merchant, the secure representation 128, and the payment amount requested. The merchant 140 then sends the payment request 146 to payment service provider 160 for an approval or decline response.

[0037] After the payment request 146 is received by the payment service provider 160, the payment request 146 can be examined by the security processor 164 to make the following security determinations. The security processor 164 can determine whether the secure representation 128 is intended for the payment requesting merchant. The security processor 164 can further determine if any of the additional payment restrictions 605 set by the customer 328 is violated. Based on these determinations the security processor can reasonably decline the payment request 146 to the merchant 140 along with explanations.

[0038] FIG. 4 represents an exemplary process flow of the security processor 164. At STEP 402, the security processor 164 retrieves the cipher key 166 associated with the payment requesting merchant 140 (FIG. 11) to decrypt the secure representation 128 in the payment request 146. If the decryption process fails this generally indicates either the secure representation 128 has been tampered with or the cipher key 166 is incorrect, inferring that the secure representation 128 was originally created for another target merchant, and the processing can be directed to STEP 404 to decline the payment request 146. If the decryption succeeds the original payment information 126 and additional restrictions 605 are retrieved. At STEP 406, the security processor 164 directs processing to STEP 404 if any of the additional restrictions 605, such as the expiry and maximum allowed payment amount for the transaction, were violated; otherwise the security processor 164 returns payment information 126 for further processing within payment service provider 160.

[0039] An illustrative description of an exemplary operation of the tokenization implementation of the apparatus 100 is presented, for explanatory purposes. The tokenization implementation in an example differs from the encryption implementation in the generation of the secure representation 128 and the retrieval of the payment information 126 and additional restrictions 605 from the secure representation 128. The details of the tokenization implementation in contrast with the encryption implementation of the apparatus 100 are presented herein.

[0040] Referring to the STEP 308 in FIQ. 3, FlG. 6, in an exemplary operation of tokenization in connection with the secure representation 128, upon receiving the submitted payment information 126 and additional restrictions 605 from the display 600, the securer 162 stores the submitted information along with the identification of the target merchant, for example, in a secured format in payment service provider 160, employing the current tokenization practice in the industry and creates and/or associates a token as secure representation 128. FIG. 10 illustrates an exemplary structure of the tokenization. The information tuplet 1002 comprises the submitted payment information 126 and additional restrictions 605 as information 902 and the target merchant identification 144, and is associated to a generated or reused token to be provided to customer 120 as secure representation 128 to present to merchant 140.

[0041] Referring to FIG. 4 and FIG. 10, in an exemplary operation of tokenization in connection with the secure representation 128, at STEP 402, the security processor 164 employs the secure representation 128 from payment request 146 to retrieve the information tuplet 1002 comprising payment information 126, the additional restrictions 605, and identification of the target merchant 1004. The security processor 164 directs processing to STEP 404 to decline the payment request 146 if the merchant identification 1004 of the target merchant does not match that of the payment requesting merchant in the payment request 146. At STEP 408, the security processor 164 directs processing to STEP 404 if any of the additional restrictions 605 were violated; otherwise the security processor 364 returns payment information 126 for further processing by the payment service provider 160.

[0042] The STEP 202 of FIG. 2 illustrates when the customer 120 attempts to submit the secure representation 128 generated originally for the target merchant 140, to another merchant 140, with both merchants employing payment processing services from the same payment service provider 160, the payment request 146 generated by the other merchant 140 will be declined by the security processor 164 when the processing reaches STEP 402 of FIG. 4 where it can be determined that the identification of the other payment requesting merchant 140 such as through employment of the cipher key 166 fails to match the identification of the target merchant 140 associated originally with the secure representation 128

[0043] During the whole payment transaction process in an example al no time did the merchant 140 receive the clear text payment information 126 of customer 120, thus the encrypled/tokenized merchant specific secure representation 128 encapsulating the payment information 126 can be safely stored on the merchant's database 148 with reduced risk.

[0044] In accepting customer payments, the merchants may be shielded from the knowledge of the actual payment information 126. In a further example, the merchant specific secure payment information 128 generated has limited usefulness compared to the actual payment information. It may be desirable to promote a reduction in direct and/or collateral damage that may result if the merchant stores customer payment information in the merchant's system and the data security in the merchant^'s system were compromised. The compromised merchant specific secure payment information in an example can be used desirably only on the targeted merchant's system and within the restrictions set by the original customer 120. [0045J The customer 120 in an example can further restrict the utility of the payment information that the customer 120 furnishes to merchants 140. The customer 120 in an example can set an expiry and/or maximum total amount that the customer 120 allows for a particular merchant 140 to process with his payment information 126.

J0046J The merchant 140 safely stores customer payment information 126 with the customer's profile into the database 148 within the system of merchant 140 as a convenience feature to save data re-entry efforts on the customer's future transactions without increased security risk.

[0047] An exemplary implementation employs pre-authorization secureness. The customer's payment information 126 in an example is tokenized or encrypted before the information enters the merchant's system In contrast to the industry practice of "Merchant-Initiated/Post-Authorization Tokenization" an exemplary approach may be viewed as a "Customer-lnitiated/Pre-Aυthorization Encryption/Tokenization" in which the payment information is encapsulated in encrypted and/or tokenized form before it entered into merchant's system. The cost of implementing the encryption/tokenization in an example is shifted to the payment service provider 160 from the merchant 140. Exemplary payment service providers 160 may allocate budget and/or apply expertise for PCI-Compliance, for example, reducing and/or avoiding the merchant 140 from responsibility of PCI-Compliance. The customer 120 in an example is made aware of and participates in the encryption/tokenization to obtain the secure representation 128. Confidence in payment transaction may be promoted. The customer 120 in an example is allowed to inject additional restrictions in the payment authorization to further limit the utility of the encrypted/tokenized payment information 128.

[0048] A payment service provider in an example provides a secure representation of payment information of a customer for employment by a merchant to engage in a transaction with the customer upon receipt by the merchant of the secure representation and without receipt by the merchant of the payment information.

[0049] An implementation of the apparatus 100 may comprise a plurality of components such as one or more of electronic components, chemical components, organic components, mechanical components, hardware components, optical components, and/or computer software components. A number of such components may be combined or divided in an implementation of the apparatus 100. One or more components of an implementation of the apparatus 100 and/or one pail thereof may comprise one or more of a computing, communication, interactive, and/or imaging device, interface, computer, and/or machine. One or more components of an implementation of the apparatus 100 and/or one parts thereof may serve to allow selection, employment, channeling, processing, analysis, communication, and/or transformation of electrical signals and/or between and/or among physical, logical, transitional, transitory, persistent, and/or electrical signals, inputs, outputs, measurements, and/or representations.

[0050] In one or more exemplary implementations, a plurality of instances of a particular component may be present in the apparatus 100. In one or more exemplary implementations, one or more features described herein in connection with one or more components and/or one or more parts thereof may be applicable and/or extendible analogously to one or more other instances of the particular component and/or other components in the apparatus 100. In one or more exemplary implementations, one or more features described herein in connection with one or more components and/or one or more parts thereof may be omitted from or modified in one or more other instances of the particular component and/or other components in the apparatus 100. An exemplary technical effect is one or more exemplary and/or desirable functions, approaches, and/or procedures. An exemplary component of an implementation of the apparatus 100 may employ and/or comprise a set and/or series of computer instructions written in or implemented with any of a number of programming languages, as will be appreciated by those skilled in the art. An implementation of the apparatus 100 may comprise any (e.g., horizontal, oblique, angled, or vertical) orientation, with the description and figures herein illustrating an exemplary orientation of an exemplary implementation of the apparatus 100, for explanatory purposes.

[0051] An implementation of the apparatus 100 may encompass an article and/or an article of manufacture. The article may comprise one or more computer-readable signal- bearing media. The article may comprise means and/or instructions in the one or more media for one or more exemplary and/or desirable functions, approaches, and/or procedures.

)52] An implementation of the apparatus 100 may employ one or more computer readable signal bearing media. A computer-readable signal-bearing medium may store software, firmware and/or assembly language for performing one or more portions of one or more implementations. An example of a computer-readable signal bearing medium for an implementation of the apparatus 100 may comprise a memory and/or recordable data storage medium. A computer-readable signal-bearing medium for an implementation of the apparatus 100 in an example may comprise one or more of a magnetic, electrical, optical, biological, chemical, and/or atomic data storage medium. For example, an implementation of the computer-readable signal-bearing medium may comprise one or more floppy discs, magnetic tapes, CDs (compact discs), DVDs (digital video discs), hard drives, portable drives, backup drives, thumb drives, and/or electronic memory. In another example, an implementation of the computer-readable signal- bearing medium may comprise a modulated carrier signal transmitted over a network comprising or coupled with an implementation of the apparatus 100, for instance, one or more of an online system, a telephone network, a local area network (LAN), a wide area network (WAN), the Internet, and/or a wireless network. A computer- readable signal- bearing medium in an example may comprise a physical computer medium and/or computer-readable signal-bearing tangible medium.

[0053] The steps or operations described herein are examples. There may be variations to these steps or operations without departing from the spirit of the invention. For example, the steps may be performed in a differing order, or steps may be added, deleted, or modified.

[0054] Although exemplary implementation of the invention has been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions, and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.

Claims

CLAIMS What is claimed is:

1. An apparatus, comprising: a payment service provider that provides a secure representation of payment information of a customer for employment by a merchant to engage in a transaction with the customer upon receipt by the merchant of the secure representation and without receipt by the merchant of the payment information.