U.S. patent application number 13/835088 was filed with the patent office on 2013-11-07 for transaction data tokenization.
This patent application is currently assigned to MASTERCARD INTERNATIONAL INCORPORATED. The applicant listed for this patent is MASTERCARD INTERNATIONAL INCORPORATE. Invention is credited to Daniel Goodman, Obinna Nwokolo.
Application Number | 20130297504 13/835088 |
Document ID | / |
Family ID | 49513382 |
Filed Date | 2013-11-07 |
United States Patent
Application |
20130297504 |
Kind Code |
A1 |
Nwokolo; Obinna ; et
al. |
November 7, 2013 |
TRANSACTION DATA TOKENIZATION
Abstract
A system and method of tokenizing sensitive cardholder payment
information for use in cashless transactions includes receiving a
request to process a cashless transaction between a merchant and a
purchaser using first payment data stored with an electronic wallet
provider on behalf of the purchaser. First payment data is
retrieved from the electronic wallet provider. The first payment
data is tokenized into a payment token, and provided to the
merchant for use in completing the cashless transaction. The
merchant issues a request to process payment for the cashless
transaction using the payment token. The payment token is
detokenized into second payment data, with correspondence between
the first and second payment data being indicative of payment token
authenticity. Payment for the cashless transaction is processed
using the second payment data, and the merchant is provided with a
response indicating either the success or failure of the payment
processing.
Inventors: |
Nwokolo; Obinna; (New York,
NY) ; Goodman; Daniel; (White Plains, NY) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MASTERCARD INTERNATIONAL INCORPORATE |
Purchase |
NY |
US |
|
|
Assignee: |
MASTERCARD INTERNATIONAL
INCORPORATED
Purchase
NY
|
Family ID: |
49513382 |
Appl. No.: |
13/835088 |
Filed: |
March 15, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61642872 |
May 4, 2012 |
|
|
|
Current U.S.
Class: |
705/41 |
Current CPC
Class: |
G06Q 20/36 20130101;
G06Q 20/12 20130101; G06Q 20/385 20130101; G06Q 20/363
20130101 |
Class at
Publication: |
705/41 |
International
Class: |
G06Q 20/36 20120101
G06Q020/36 |
Claims
1. A method of tokenizing sensitive cardholder payment information
for use in cashless transactions, the method comprising: receiving
a request to process a cashless transaction between a merchant and
a purchaser using first payment data stored with an electronic
wallet provider on behalf of the purchaser; retrieving first
payment data from the electronic wallet provider; tokenizing the
first payment data into a payment token; providing the payment
token to the merchant for use in completing the cashless
transaction; receiving, from the merchant, a request to process
payment for the cashless transaction using the payment token;
detokenizing the payment token into second payment data, wherein
correspondence between the first and second payment data is
indicative of the authenticity of the payment token received from
the merchant; processing payment for the cashless transaction using
the second payment data; and providing an response to the merchant
indicating either the success or failure of the payment
processing.
2. The method according to claim 1, further comprising: passing the
payment data to one of a third party tokenizer and a payment
service provider, wherein the third party tokenizer or payment
service provider tokenizes the payment data into a payment token;
provides the payment token to the merchant for use in completing
the cashless transaction; receives, from the merchant, the request
to process payment for the cashless transaction using the payment
token; detokenizes the payment token; processes payment for the
cashless transaction using the payment data; and provides the
response to the merchant indicating either the success or failure
of the payment processing; and receiving from the merchant, the
third party tokenizer, or the payment service provider an
indication of the success or failure of the payment processing.
3. The method according to claim 1, wherein the payment token
further comprises one or more of the following data a transaction
identifier, a name of the cardholder, an address of the cardholder,
a postal code related to the address of the cardholder, an
indicator that the transaction is related to an electronic wallet,
a masked payment card number, a start date related to the payment
card, an expiration date related to the payment card, a brand of
the payment card, and a type of payment card.
4. The method according to claim 1, wherein the payment token is
bound to the received transaction request, whereby the payment
token is valid only under predetermined conditions including one or
more of having been submitted by a predetermined merchant,
requesting payment of a predetermined dollar amount or range of
dollar amounts, and submitted for payment within a predetermined
timeframe.
5. The method according to claim 1, wherein the tokenized payment
data includes a virtual card number.
6. The method according to claim 1, wherein the method is performed
by an operator of a network of wallets, and further the electronic
wallet provider is one of the operator of the network of wallets on
its own behalf, the operator of the network of wallets on behalf of
a third party, and a third party provider of electronic wallet
services.
7. A non-transitory computer readable storage medium embodying
thereon a program of instruction which, when executed by a
processor, cause the processor to carry out a method of tokenizing
sensitive cardholder payment information for use in cashless
transactions, the method comprising: receiving a request to process
a cashless transaction between a merchant and a purchaser using
first payment data stored with an electronic wallet provider on
behalf of the purchaser; retrieving first payment data from the
electronic wallet provider; tokenizing the first payment data into
a payment token; providing the payment token to the merchant for
use in completing the cashless transaction; receiving, from the
merchant, a request to process payment for the cashless transaction
using the payment token; detokenizing the payment token into second
payment data, wherein correspondence between the first and second
payment data is indicative of the authenticity of the payment token
received from the merchant; processing payment for the cashless
transaction using the second payment data; and providing an
response to the merchant indicating either the success or failure
of the payment processing.
8. The medium according to claim 7, wherein the method embodied in
the program of instruction further comprises: passing the payment
data to one of a third party tokenizer and a payment service
provider, wherein the third party tokenizer or payment service
provider tokenizes the payment data into a payment token; provides
the payment token to the merchant for use in completing the
cashless transaction; receives, from the merchant, the request to
process payment for the cashless transaction using the payment
token; detokenizes the payment token; processes payment for the
cashless transaction using the payment data; and provides the
response to the merchant indicating either the success or failure
of the payment processing; and receiving from the merchant, the
third party tokenizer, or the payment service provider an
indication of the success or failure of the payment processing.
9. The medium according to claim 7, wherein according to the method
embodied in the program of instruction, the payment token further
comprises one or more of the following data a transaction
identifier, a name of the cardholder, an address of the cardholder,
a postal code related to the address of the cardholder, an
indicator that the transaction is related to an electronic wallet,
a masked payment card number, a start date related to the payment
card, an expiration date related to the payment card, a brand of
the payment card, and a type of payment card.
10. The medium according to claim 7, wherein according to the
method embodied in the program of instruction, the payment token is
bound to the received transaction request, whereby the payment
token is valid only under predetermined conditions including one or
more of having been submitted by a predetermined merchant,
requesting payment of a predetermined dollar amount or range of
dollar amounts, and submitted for payment within a predetermined
timeframe.
11. The medium according to claim 7, wherein according to the
method embodied in the program of instruction, the tokenized
payment data includes a virtual card number.
12. A system for tokenizing sensitive cardholder payment
information for use in cashless transactions, the system
comprising: a processor; a non-transitory computer readable storage
medium embodying thereon a program of instruction which, when
executed by a processor, cause the processor to carry out a method
of tokenizing sensitive cardholder payment information for use in
cashless transactions, the method comprising receiving a request to
process a cashless transaction between a merchant and a purchaser
using first payment data stored with an electronic wallet provider
on behalf of the purchaser; retrieving first payment data from the
electronic wallet provider; tokenizing the first payment data into
a payment token; providing the payment token to the merchant for
use in completing the cashless transaction; receiving, from the
merchant, a request to process payment for the cashless transaction
using the payment token; detokenizing the payment token into second
payment data, wherein correspondence between the first and second
payment data is indicative of the authenticity of the payment token
received from the merchant; processing payment for the cashless
transaction using the second payment data; and providing an
response to the merchant indicating either the success or failure
of the payment processing.
13. The system according to claim 12, wherein the method embodied
in the program of instruction further comprises: passing the
payment data to one of a third party tokenizer and a payment
service provider, wherein the third party tokenizer or payment
service provider tokenizes the payment data into a payment token;
provides the payment token to the merchant for use in completing
the cashless transaction; receives, from the merchant, the request
to process payment for the cashless transaction using the payment
token; detokenizes the payment token; processes payment for the
cashless transaction using the payment data; and provides the
response to the merchant indicating either the success or failure
of the payment processing; and receiving from the merchant, the
third party tokenizer, or the payment service provider an
indication of the success or failure of the payment processing.
14. The system according to claim 12, wherein according to the
method embodied in the program of instruction the payment token
further comprises one or more of the following data a transaction
identifier, a name of the cardholder, an address of the cardholder,
a postal code related to the address of the cardholder, an
indicator that the transaction is related to an electronic wallet,
a masked payment card number, a start date related to the payment
card, an expiration date related to the payment card, a brand of
the payment card, and a type of payment card.
15. The system according to claim 12, wherein according to the
method embodied in the program of instruction the payment token is
bound to the received transaction request, whereby the payment
token is valid only under predetermined conditions including one or
more of having been submitted by a predetermined merchant,
requesting payment of a predetermined dollar amount or range of
dollar amounts, and submitted for payment within a predetermined
timeframe.
16. The system according to claim 12, wherein according to the
method embodied in the program of instruction the tokenized payment
data includes a virtual card number.
17. The system according to claim 12, operated by an operator of a
network of wallets, and further the electronic wallet provider is
one of the operator of the network of wallets on its own behalf,
the operator of the network of wallets on behalf of a third party,
and a third party provider of electronic wallet services.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the priority benefit under 35 U.S.C.
.sctn.119(e) of prior U.S. Provisional Patent Application Ser. No.
61/642,872 (Attorney Docket No. 1788-96P), entitled "TRANSACTION
DATA TOKENIZATION", filed 4 May 2012 by the present inventive
entity.
[0002] This application is related to non-provisional U.S. Utility
patent application Ser. No. 13/209,312 entitled "MULTI-COMMERCE
CHANNEL WALLETS FOR AUTHENTICATED TRANSACTIONS", and also
International PCT Application Serial No. PCT/US2011/047678 having
the same title, both filed 12 Aug. 2011, both of which in turn
claim the priority benefit of U.S. Provisional Application Ser. No.
61/372,955 filed 12 Aug. 2010 and also of U.S. Provisional
Application Ser. No. 61/468,847 filed 29 Mar. 2011.
[0003] This application is further related to U.S. Utility patent
application Ser. No. 13/746,904 entitled "SYSTEM TO ENABLE A
NETWORK OF WALLETS", filed 22 Jan. 2013 (Attorney Docket No.
1788-82), which in turn claims the priority benefit of U.S.
Provisional Application Ser. No. 61/588,505 (Attorney Docket No.
1788-82P) entitled "SYSTEM TO ENABLE A NETWORK OF WALLETS", filed
19 Jan. 2012; of U.S. Provisional Application Ser. No. 61/642,729
(Attorney Docket No. 1788-82P2), entitled "SYSTEM AND METHOD TO
ENABLE A NETWORK OF DIGITAL WALLETS", filed on 4 May 2012; of U.S.
Provisional Application Ser. No. 61/642,792 (Attorney Docket No.
1788-91P), entitled "REAL-TIME INTERSTITIAL ELECTRONIC WALLET
CREATION", filed on 4 May 2012; and of U.S. Provisional Application
Ser. No. 61/642,799 (Attorney Docket No. 1788-97P), entitled
"INTEGRATION OF A PARTNER HOSTED WALLET WITH A NETWORK OF WALLETS",
filed on 4 May 2012.
[0004] This application is further related to U.S. Provisional
Application Ser. No. 61/642.925 (Attorney Docket No. 1788-95P),
entitled "EUREKA CONVERGED", and filed on 4 May 2012.
[0005] The complete disclosures of all related applications cited
above and any of their corresponding priority applications are
hereby incorporated in their entirety for all purposes by this
reference.
BACKGROUND
[0006] 1. Field of the Disclosure
[0007] The present invention relates to transactions for payment of
goods/services and, more particularly, to a system and method for
tokenization for sensitive or confidential transaction payment
data.
[0008] 2. Brief Discussion of Related Art
[0009] Cashless electronic payment for transaction of goods and
services is become ubiquitous in modern society. In connection with
this, electronic wallets are becoming a more prevalent counterpart
to electronic forms of payment for a wide variety of transactions.
Generally speaking, an electronic wallet is a system by which a
credit card, debit card, pre-paid card, etc., is stored where a
single electronic application which provides access to them,
analogous to the way in which one might store corresponding
physical payment cards in a tangible wallet.
[0010] The disclosure in the application entitled "MULTI-COMMERCE
CHANNEL WALLETS FOR AUTHENTICATED TRANSACTIONS", and also the
related application entitled "SYSTEM AND METHOD TO ENABLE A NETWORK
OF DIGITAL WALLETS", includes a federated network of electronic
wallets. The purchaser may select this network of wallets which
includes partners who are members of the federation, each of whom
provide electronic wallet services. One option presented to the
purchaser may be the option to use an electronic wallet maintained
and provided by the payment processing entity, e.g., MasterCard
International Incorporated (assignee of the instant application),
which is also operating the network of wallets.
[0011] Given the overwhelming volume of transactions consummated
per second, and the necessity that transactions be authorized
expeditiously in order to be an acceptable form of payment for all
parties involved in the transaction, the circumstances naturally
lend themselves to automation of the approval process. However,
without adequate oversight on an individual or per-transaction
basis, and/or without the parties to the transaction being known to
others involved, including the intermediary, the opportunity for
malicious abuse of the payment system require adequate
safeguards.
[0012] A problem presented is where the transaction details
required to consummate a purchaser's transaction may be used
thereafter for malicious purposes, for example if the security of
such data is compromised by a third party, or by another bad actor
with access to cardholder data used during the transaction. A
solution to this problem is required.
SUMMARY OF THE DISCLOSURE
[0013] In order to overcome these and other problems, weaknesses
and/or drawbacks in the present state of the art, provided
according to the instant disclosure is a system and method for
tokenization of sensitive data use in connection with cashless and
electronic transactions.
[0014] More specifically, a method of tokenizing sensitive
cardholder payment information for use in cashless transactions
includes receiving a request to process a cashless transaction
between a merchant and a purchaser using first payment data stored
with an electronic wallet provider on behalf of the purchaser.
First payment data is retrieved from the electronic wallet
provider. The first payment data is tokenized into a payment token,
and provided to the merchant for use in completing the cashless
transaction. The merchant issues a request to process payment for
the cashless transaction using the payment token.
[0015] The payment token is detokenized into second payment data,
where correspondence between the first and second payment data is
indicative of the authenticity of the payment token received from
the merchant. Payment for the cashless transaction is processed
using the second payment data, and the merchant is provided with a
response indicating either the success or failure of the payment
processing.
[0016] In a further embodiment of the present disclosure, the
payment data is passed to one of a third party tokenizer and a
payment service provider, wherein the third party tokenizer or
payment service provider tokenizes the payment data into a payment
token, provides the payment token to the merchant for use in
completing the cashless transaction, receives, from the merchant,
the request to process payment for the cashless transaction using
the payment token, detokenizes the payment token, processes payment
for the cashless transaction using the payment data, and provides
the response to the merchant indicating either the success or
failure of the payment processing. In this embodiment, the third
party tokenizer, or the payment service provider, provides an
indication of the success or failure of the payment processing.
[0017] In a more particular embodiment of the present disclosure,
the payment token further comprises one or more of the following
data: a transaction identifier; a name of the cardholder; an
address of the cardholder; a postal code related to the address of
the cardholder; an indicator that the transaction is related to an
electronic wallet; a masked payment card number; a start date
related to the payment card; an expiration date related to the
payment card; a brand of the payment card; and a type of payment
card. Optionally or additionally, the tokenized payment data may
include a virtual card number.
[0018] In still a further embodiment of the present disclosure, the
payment token is bound to the received transaction request, whereby
the payment token is valid only under predetermined conditions
including one or more of having been submitted by a predetermined
merchant, requesting payment of a predetermined dollar amount or
range of dollar amounts, and submitted for payment within a
predetermined timeframe.
[0019] In still a further embodiment of the present disclosure, the
method is performed by an operator of a network of wallets, and
further the electronic wallet provider is one of the operator of
the network of wallets on its own behalf, the operator of the
network of wallets on behalf of a third party, and a third party
provider of electronic wallet services.
[0020] Further provided according to the present disclosure is an
electronic system for carrying out the foregoing method including a
processor and a non-transitory machine readable recording medium
which embodies thereon a program of instruction. The program of
instruction, when executed by the processor, cause the machine to
carry out the foregoing method in one or more of its embodiments.
Also provided according to the present disclosure is such a
non-transitory machine readable medium.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Some embodiments are illustrated by way of example and not
limitation in the figures of the accompanying drawings, in which
like reference numerals refer to like structures across the several
views, and wherein:
[0022] FIG. 1 is a schematic representation of a
payment/authentication system and method according to a first
embodiment of the present disclosure;
[0023] FIG. 2 is a schematic representation of a
payment/authentication system and method according to a second
embodiment of the present disclosure, including a third-party
tokenization entity;
[0024] FIG. 3 is a schematic representation of a
payment/authentication system and method according to a third
embodiment of the present disclosure, including a third-party
payment service provider performing tokenization; and
[0025] FIG. 4 illustrates schematically a representative computer
according to the present disclosure, operative to implement the
disclosed methods.
DETAILED DESCRIPTION OF THE DISCLOSURE
[0026] Referring now to FIG. 1, illustrated is a sequence of
operations for the tokenization of payment transaction data within
the context of a federated network of wallets, for example as
described according to related application attorney docket nos.
1788-65, 1788-82P, and/or 1788-82P2. In such a scenario, the
operator of the network of wallets is embodied according to
reference 120 of FIG. 1, in this case under the name of PayPass
Online Services (PPOS). Furthermore, represented as entity 140,
PayPass Online Wallet (PPOW), the operator of the network of
wallets is further acting as one of the electronic wallet service
providers within the federation of network wallets.
[0027] Furthermore, in the present embodiment the operator of the
network of wallets is also functioning as payment API provider,
reference 160. Other parties to the transaction are represented as
consumer 180, merchants 200, and payment gateway or acquirer 220.
At the point illustrated in the payments process, it is presumed
that consumer 180 has selected the group of services to be involved
in the transaction with merchant 200. As this process is typically
embodied, for example in an online e-commerce transaction, consumer
180 has placed certain goods or services in an electronic shopping
cart, and has arrived at a checkout page. The consumer will be
presented with options for payment which will include an on-line
checkout button invoking the network of wallets operated by PayPass
online services 120, which the consumer 180 selects at step 1.
[0028] At step 2, the merchant communicates the wallet sign-in
request to PPOS 120 and receives a URL to a wallet sign-in page.
Merchant 200 then redirects the user to the network of wallets
landing page, step 3. The user is given the opportunity to choose
an electronic wallet from among those available, including the
opportunity to create a new wallet. The wallets may include one
operated by PPOW 140 apart from their capacity as the network of
wallets operator, alternately wallets operated by PPOW 140 partners
with partner-branding or skinning, having the partner's look and
feel but operated by wallet provider PPOW 140. Finally, the partner
may provide their own wallet services and substitution for PPOW
140. The purchaser chooses their wallet in step 4, and PPOS 120
redirects the user to their selected wallet in step 5.
[0029] The consumer signs in to their selected wallet in step 6.
They also select from among the payment sources, for example card
accounts, associated with their selected wallet. The purchaser
further selects a shipping address associated with the wallet. The
online wallet provider/PPOW 140 delivers selected card and address
data to the operator of the network of wallets, PPOS 120, in step
7.
[0030] Network operator 120 then saves the selected card details
and uses the card details to generate a payment token which will be
shared with the merchant in order to consummate the transaction in
step 8. The card details delivered from PPOW 140 would generally
include a primary account number (PAN). This sensitive information
is better protected, and further the merchant 200 can be enabled to
complete the transaction without this specific information.
Therefore, the generation of a payment token step 8 would include
the payment token as a programming object or file. The token
generally includes a transaction identifier; a cardholder name;
billing address; postal code; a tokenized PAN reference in
substitution for the PAN; a wallet transaction indicator; a masked
card number representing the selected card from the wallet; a start
date associated with the selected card; an expiration date
associated with the card; the card brand and/or type. At step 9,
PPOS 120 returns a return address and the payment token together to
the merchant 200 in order to finalize the transaction.
[0031] In certain embodiments, the tokenized card reference may
include a virtual card number (VCN). The virtual card number in
substitution for the PAN may provide additional security features.
For example, the VCN may be limited to one or a fixed number of
uses. A one-time use VCN would being applicable for an isolated
transaction. A VCN enabled for repeated use would allowing the
merchant 200 to use of the same payment token and/or VCN. On such
example where this might be beneficial is with recurring fixed
transactions or variable transactions within a predetermined amount
range.
[0032] Moreover, at the point in the transaction where the token is
generated, the full final amount of the transaction may not yet be
known. Options such as shipping address or shipping services may
affect the final cost through surcharges and/or applicable sales
tax. Capping the dollar amount of associated with the payment token
consistent with the legitimate completion of the transaction for
which it is generated provides an additional layer of security. In
addition to capping a dollar amount on the payment token, the
payment token may be bound to the merchant involved in initiating
the corresponding transaction for which it is generated. That is to
say, the particular payment token would not be honored if presented
by some other merchant for authentication. In this way, should the
payment token be compromised or intercepted by a malicious third
party or other bad actor, the payment token would not be useful
with any other merchant.
[0033] Having received the payment token in step 9, the merchant
200 stores the token as step 10, then presents the consumer 180
with any final options (for example shipping services) to complete
the transaction, that being step 11. At step 12, merchant 200
calculates the token total cost in light of the options selected by
the consumer 180, and proceeds to step 13 by submitting the total
cost of the transaction and the payment token for authentication
and payment. The data included at step 13 may include an order ID
reference, the tokenized PAN reference provided with the payment
token from the network operator 120 at step 9, a total transaction
amount, and a currency of the transaction.
[0034] PPOS 120 receives the token and authentication request, and
uses the token to retrieve the card details to process the payment
in step 14. PPOS 120 then submits the authentication using the card
details, including PAN, and a total transaction amount in step 15.
The payment API 160 provided by the network operator takes the
authentication request and passes it to a payment gateway or
acquirer 220 and receives back an authentication response in step
16. The authentication request provided by the payment API 160 will
generally include merchant credentials; the name of the acquiring
bank/payment gateway provider; cardholder name; PAN; wallet
transaction indicator; expiration date of the applicable card; and
billing address associated with the account upon which the card is
drawn.
[0035] Payments API 160 then receives and passes an authentication
response which in turn is passed to PPOS 120 at step 17. PPOS 120,
now with knowledge of the authentication outcome, updates the order
history in step 18, and in turn passes the authentication response
to the merchant 200 in step 19. Presuming the authentication is
affirmative, the merchant 200 confirms the order to the consumer
180, step 20.
[0036] Referring now to FIG. 2, illustrated is an alternative
payment transaction. The steps, features, and parties in common
with FIG. 1 will not be described in great detail where they do not
substantially differ. In the embodiment of FIG. 2 the process and
parties proceeds generally in accordance with the above description
of FIG. 1, up to step 8. As compared with step 8 of FIG. 1,
according to FIG. 2, PPOS 120 effectively outsources the
tokenization and gateway authorization. A third party tokenizer
and/or payment gateway entity 240 performs these functions.
[0037] Tokenizer entity 240 saves the consumer's card choice and
generates a payment token associated with the transaction in step
9. At step 10, the tokenizer entity 240 transmits the payment token
details and shipping address to the merchant 200, providing a
Checkout Resource URL 260. Merchant 200 retrieves the payment token
and shipping address from the Checkout Resource URL 260 in step 11.
The consumer 180 chooses shipping options, upon which the total
cost is computed, at step 12. The merchant 200 then submits the
payment token with total transaction cost information in step 13.
An order ID, the tokenized PAN reference, a transaction total and
currently of transaction may be communicated together. Tokenizer
entity 240 detokenizes the authentication request in step 14 and
submits the authentication request to the payment gateway/acquirer
220 in step 15. The response to tokenizer entity 240 from the
payment gateway/acquirer 220 is transmitted to the merchant 200 in
step 16, then on to the consumer 180 with an order confirmation in
step 17. A post-back message to PPOS 120 is generated at step 18 to
record the outcome of the transaction. In this way, PPOS 120 can
log the transaction outcome as part of a value-added service to
consumer 180, an acquirer and/or issuer, despite being removed from
the authentication process.
[0038] FIG. 3 illustrates still another scenario in which the
merchant 200 contracts with a third party payment service provider
(PSP) 260. The third party PSP 260 stands between the merchant 200
on one side and the PPOS 120 and PPOW 140 on the other. Moreover,
the PSP 260 has agree, accepted and/or audited security processes,
and is a trusted collaborator for handling confidential transaction
information, such as PAN associated with the transactions it
processes.
[0039] In the embodiment of FIG. 3, PSP 260 stands between POS 120
and merchant 200. PSP 260 performs the tokenization at step 11, and
processes the authentication with acquirer 220 in step 18.
Additionally, PSP 260 will provide a postback message in step 21 to
PPOS 120, confirming the outcome of the transaction.
[0040] It will be appreciated by those skilled in the art that the
methods as described above may be operated by a machine operator
having a suitable interface mechanism, and/or more typically in an
automated manner, for example by operation of a network-enabled
computer system including a processor executing a system of
instructions stored on a machine-readable medium, RAM, hard disk
drive, or the like. The instructions will cause the processor to
operate in accordance with the present disclosure.
[0041] Turning then to FIG. 4, illustrated schematically is a
representative computer 616 of the system 600. The computer 616
includes at least a processor or CPU 622 which is operative to act
on a program of instructions stored on a computer-readable medium
624. Execution of the program of instruction causes the processor
622 to carry out, for example, the methods described above
according to the various embodiments. It may further or alternately
be the case that the processor 622 comprises application-specific
circuitry including the operative capability to execute the
prescribed operations integrated therein. The computer 616 will in
many cases includes a network interface 626 for communication with
an external network 612. Optionally or additionally, a data entry
device 628 (e.g., keyboard, mouse, trackball, pointer, etc.)
facilitates human interaction with the server, as does an optional
display 630. In other embodiments, the display 630 and data entry
device 628 are integrated, for example a touch-screen display
having a GUI.
[0042] Variants of the above-disclosed and other features and
functions, or alternatives thereof, may be desirably combined into
many other different systems or applications. Various presently
unforeseen or unanticipated alternatives, modifications,
variations, or improvements therein may be subsequently made by
those skilled in the art which are also intended to be encompassed
by the following claims.
* * * * *