US20170169426A1 - Dynamic security code authorization verification service - Google Patents
Dynamic security code authorization verification service Download PDFInfo
- Publication number
- US20170169426A1 US20170169426A1 US15/007,837 US201615007837A US2017169426A1 US 20170169426 A1 US20170169426 A1 US 20170169426A1 US 201615007837 A US201615007837 A US 201615007837A US 2017169426 A1 US2017169426 A1 US 2017169426A1
- Authority
- US
- United States
- Prior art keywords
- security code
- dynamic security
- authorization request
- request message
- transaction authorization
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 84
- 238000012795 verification Methods 0.000 title claims abstract description 48
- 238000000034 method Methods 0.000 claims abstract description 54
- 230000008569 process Effects 0.000 claims abstract description 34
- 238000004891 communication Methods 0.000 claims description 13
- 230000004044 response Effects 0.000 claims description 10
- 230000006870 function Effects 0.000 claims description 9
- 230000015654 memory Effects 0.000 claims description 7
- 230000003068 static effect Effects 0.000 claims description 5
- 238000010200 validation analysis Methods 0.000 description 42
- 238000012545 processing Methods 0.000 description 28
- 238000010586 diagram Methods 0.000 description 7
- 230000000694 effects Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000004540 process dynamic Methods 0.000 description 1
- 230000004224 protection Effects 0.000 description 1
- 230000008929 regeneration Effects 0.000 description 1
- 238000011069 regeneration method Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/405—Establishing or using transaction specific rules
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
Definitions
- FIG. 1 is a block diagram of a conventional payment system 100 as it may operate in connection with an online purchase transaction.
- the system 100 includes an e-commerce server computer 102 that may be operated by or on behalf of an online merchant to permit online shopping transactions.
- the e-commerce server computer 102 may host a shopping website, sometimes referred to as an “online store”.
- a customer 103 who operates a customer device 104 may access the shopping website by communicating over the Internet 105 with the e-commerce server computer 102 .
- the customer device 104 may be, for example, a personal computer or notebook computer that runs a browser program, a tablet computer or smartphone that runs a mobile browser and/or a suitable app, etc.
- the customer 103 may refer to a payment card 106 issued to the customer 103 in connection with the payment account to be used for the current online purchase transaction.
- the e-commerce server computer 102 may transmit a transaction authorization request message (sometimes simply referred to as an “authorization request”) to the merchant's acquirer financial institution (“acquirer” or “transaction acquirer”), indicated by reference numeral 110 .
- the acquirer 110 may route the authorization request via a payment network 112 to a server computer 114 operated by the issuer of the payment account that corresponds to the payment card 106 and the payment account number provided by the customer as part of the checkout process for the online purchase transaction.
- the authorization response generated by the issuer server computer 114 may be routed back to the acquirer 110 via the payment network 112 .
- the acquirer 110 may confirm to the merchant (i.e., to the e-commerce server computer 102 ) that the transaction has been approved.
- the customer may enter payment related information such as the customer's name as it appears on the payment account, the PAN (primary account number) that identifies the payment account, and the current expiration date for the account.
- the customer may—in many cases—be prompted to enter a three or four digit security code that typically is printed on the rear face (on the signature slip) of the payment card.
- Common names for such a code include “CVC” (card verification code) and “CVV” (card verification value). All of these items of information may be included in the authorization request.
- the payment network 112 may be, for example, the well-known Banknet® system operated by MasterCard International Incorporated, which is the assignee hereof.
- the components of the system 100 as depicted in FIG. 1 are only those that are needed for processing a single transaction.
- online shopping and payment systems may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment account issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their e-commerce servers.
- the system may also include a very large number of customers/online shoppers, who hold payment accounts that they use for their online shopping activities.
- elements of the system 100 e.g., acquirers, the payment network, payment account issuers
- FIG. 1 is a block diagram that illustrates a conventional system that handles online purchase transactions.
- FIG. 2 is a block diagram of salient portions of a payment system according to some embodiments.
- FIGS. 3 and 4 are block diagram representations of computers that may serve as components of the system shown in FIG. 2 .
- FIG. 5 is a flow chart that illustrates aspects of the present disclosure.
- a service may be provided to detect authorization requests that contain dynamic security codes.
- the service also incorporates verification of the dynamic security code included in the authorization request, and adding to the authorization request an indication of the result of the verification process.
- the authorization request, including the dynamic security code verification result may then be routed to the account issuer for approval (if appropriate) of the authorization request.
- FIG. 2 is a block diagram of salient portions of a payment system 200 provided according to some embodiments.
- the representation of the payment system 200 as shown in FIG. 2 assumes in addition that other aspects of the payment system (that were seen in FIG. 1 ) are also present but not shown in FIG. 2 .
- the representation in FIG. 2 assumes that a merchant e-commerce server 102 ( FIG. 1 ) has generated and sent to the transaction acquirer 110 ( FIG. 2 and FIG. 1 ) an authorization request that corresponds to an online purchase transaction performed via the e-commerce website hosted by the e-commerce server.
- a customer 103 FIG. 1
- FIG. 1 performed the online purchase transaction using a customer device 104 ( FIG.
- a payment card 106 ( FIG. 1 ); a further assumption is that the payment card was of a commercially available type that is an IC (integrated circuit) card that generates and displays a time-varying dynamic security code.
- a further assumption is that the currently displayed value of the dynamic security code was read by the customer, entered by the customer as part of the payment information solicited by the e-commerce website, and included in the authorization request message generated by the e-commerce server and transmitted to the acquirer 110 .
- a further assumption may be that the authorization request message is in a standard format for such messages and includes a PAN (primary account number) that identifies the payment account designated by the customer for use in the current purchase transaction.
- PAN primary account number
- the payment system 200 as shown in FIG. 2 includes a proxy computer 202 that performs on-behalf and/or stand-in processes—i.e., functions that might otherwise need to be performed by the account issuers.
- the payment system 200 further includes a dynamic validation service module 204 and a payment network processing computer 206 .
- Dotted line box 208 which encompasses the proxy computer 202 , the dynamic validation service module 204 and the payment network processing computer 206 , is intended to imply that all three of the latter system components may be operated by the operator of a payment network, the main functions of which may be implemented by the payment network processing computer 206 .
- the payment network processing computer 206 may be seen as a modified analog of the payment network 112 referred to above in connection with FIG. 1 .
- the payment network processing computer 206 may receive authorization requests from acquirers (such as the acquirer 110 shown in FIG. 2 ). The payment network processing computer 206 may forward the authorization requests to the proxy computer 202 , which may detect authorization requests that contain dynamic security codes, and forward those codes for validation by the dynamic validation service module 204 . The dynamic validation service module 204 may perform a verification process with respect to the dynamic security codes and provide the results of the verification process to the proxy computer 202 .
- the proxy computer 202 may append the verification process results to the authorization requests and transmit them to the payment network processing computer 206 , which may route the authorization requests to account issuers, such as the issuer 114 a shown in FIG. 2 (block 114 a should also be understood to represent a computer operated by or for the issuer). Authorization responses from the issuers may be routed back to the acquirers via the payment network processing computer 206 .
- the system components shown in FIG. 2 are only those that may be required to handle a single transaction.
- the payment system 200 may handle numerous transactions, including simultaneous transactions.
- one or more components of the payment system 200 may handle in-store purchase transactions and/or other types of transactions in addition to online purchase transactions.
- any two or more of the proxy computer 202 , the dynamic validation service module 204 , and/or the payment network processing computer 206 may be constituted by components of an interrelated and/or integrated computer system and/or may be housed together in a single data center.
- FIG. 3 is a block diagram representation of an embodiment of the dynamic validation service module 204 .
- the dynamic validation service module 204 may be implemented using a software and/or hardware module solution that is commercially available from a supplier of the above-mentioned IC payment cards with dynamic security code features.
- the dynamic validation service module 204 may be embodied in a hardware security module (HSM).
- HSM hardware security module
- the dynamic validation service module 204 may be constituted at least in part by typical server computer hardware, but may be controlled by software to cause it to function as described herein. Suitable security measures may be applied to the dynamic validation service module 204 .
- the dynamic validation service module 204 may include a processor 300 operatively coupled to a communication device 301 , a storage device 304 , an input device 306 and an output device 308 .
- the communication device 301 , the storage device 304 , the input device 306 and the output device 308 may all be in communication with the processor 300 .
- the processor 300 may be constituted by one or more processors.
- the processor 300 may operate to execute processor-executable steps, contained in program instructions described below, so as to control the dynamic validation service module 204 to provide desired functionality.
- Communication device 301 may be used to facilitate communication with, for example, other devices (such as the proxy computer 202 and the payment network processing computer 206 ).
- communication device 301 may comprise numerous communication ports (not separately shown), to allow the dynamic validation service module 204 to receive and process numerous simultaneous dynamic security code validation requests.
- Input device 306 may comprise one or more of any type of peripheral device typically used to input data into a computer.
- the input device 306 may include a keyboard and a mouse.
- Output device 308 may comprise, for example, a display and/or a printer. (In some embodiments, input/output functions relative to the dynamic validation service module 204 may be handled via an associated computer such as the proxy computer 202 .)
- Storage device 304 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.
- magnetic storage devices e.g., hard disk drives
- optical storage devices such as CDs and/or DVDs
- semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory.
- RAM Random Access Memory
- ROM Read Only Memory
- Storage device 304 stores one or more programs for controlling processor 300 .
- the programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the dynamic validation service module 204 , executed by the processor 300 to cause the dynamic validation service module 204 to function as described herein.
- the programs may include one or more conventional operating systems (not shown) or kernels that control the processor 300 so as to manage and coordinate activities and sharing of resources in the dynamic validation service module 204 , and to serve as a host for application programs (described below) that run on the dynamic validation service module 204 .
- the programs stored in the storage device 304 may also include a validation request handling program 310 that controls the processor 300 to enable the dynamic validation service module 204 to handle and process dynamic security code validation requests.
- the storage device 304 may also store, and the dynamic validation service module 204 may also execute, other programs, which are not shown.
- programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by the dynamic validation service module 204 .
- the other programs may also include, e.g., device drivers, database management programs, etc.
- the storage device 304 may also store an account database 312 that is referenced by the validation request handling program 310 in connection with performing a verification process with respect to dynamic security codes received by the dynamic validation service module 204 from the proxy computer 202 .
- FIG. 4 is a block diagram of an embodiment of the proxy computer 202 .
- the proxy computer 202 may, for example, resemble the hardware architecture and components described above in connection with FIG. 3 . However, the proxy computer 202 may be programmed differently from the dynamic validation service module 204 so as to provide different functionality.
- the proxy computer 202 may include a processor 400 , a communication device 401 , a storage device 404 , an input device 406 and an output device 408 .
- the communication device 401 , the storage device 404 , the input device 406 and the output device 408 may all be in communication with the processor 400 .
- FIG. 3 may, in some embodiments, also be applicable to the like-named components shown in FIG. 4 .
- Storage device 404 stores one or more programs for controlling processor 400 .
- the programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the proxy computer 202 , executed by the processor 400 to cause the proxy computer 202 to function as described herein.
- the programs may include one or more conventional operating systems (not shown) that control the processor 400 so as to manage and coordinate activities and sharing of resources in the proxy computer 202 , and to serve as a host for application programs (described below) that run on the proxy computer 202 .
- the storage device 404 may store a transaction handling program 410 that handles receipt, processing and transmission of messages related to payment account transactions.
- the transaction handling program 410 may implement functionality of the proxy computer 202 as described herein and in accordance with some embodiments.
- the storage device 404 may also store software 412 that serves as an interface between the proxy computer 202 and the dynamic validation service module 204 .
- the storage device 404 may also store, and the proxy computer 202 may also execute, other programs, which are not shown.
- programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by the proxy computer 202 .
- the other programs may also include, e.g., device drivers, database management programs, etc.
- the storage device 404 may also store one or more databases (reference numeral 414 ) required for operation of the proxy computer 202 .
- the payment network processing computer 206 may have the same type of hardware architecture and/or components as the computing device described above in connection with FIG. 3 .
- the payment network processing computer 206 may be programmed to perform conventional functions of a payment network as well as additional functions in accordance with aspects of the present disclosure and as described herein.
- the issuer computer 114 a may also have the same type of hardware architecture and/or components as described above in connection with FIG. 3 , and may be programmed to provide functionality as described herein.
- FIG. 5 is a flow chart that illustrates aspects of the present disclosure, including operations performed individually and/or cooperatively by the proxy computer 202 , dynamic validation service module 204 and the payment network processing computer 206 .
- the payment network processing computer 206 may receive an authorization request message from an acquirer 110 , and may forward the authorization request message to the proxy computer 202 .
- the processing by the proxy computer 202 may include a decision block 504 .
- the proxy computer 202 may determine whether the authorization request received at 502 contains a dynamic security code. In some embodiments, for example, the proxy computer 202 may make this determination based on the PAN included in the authorization request. (It will be recalled that the PAN identifies the payment account designated by the customer for use in the transaction represented by the authorization request.) In particular, the proxy computer 202 may determine whether the PAN falls within one or more ranges of account numbers that have been indicated by the respective account issuers as being associated with payment accounts for which dynamic security code features were implemented (i.e., accounts for which the issued payment cards embody a dynamic security code feature).
- Block 506 represents handling and processing the authorization request on the assumption that it contains a static rather than dynamic security code. This may result in the authorization request being handled and processed in a conventional manner.
- decision block 504 if a positive determination is made at that decision block (i.e., if the authorization request is determined to include a dynamic security code), then the process of FIG. 5 may advance from decision block 504 to block 508 .
- the proxy computer 202 may generate and transmit a request for verification of the dynamic security code.
- the request may be transmitted from the proxy computer 202 to the dynamic validation service module 204 and may be received by the dynamic validation service module 204 .
- the request may include, for example, the dynamic security code value to be verified and the PAN that was included in the authorization request received at 502 .
- Block 510 includes a dynamic security code verification process, which may be performed by the dynamic validation service module 204 .
- the verification process may involve duplicating the process performed in the payment card to generate the dynamic security code and comparing the result of the code generation process performed by the dynamic validation service module 204 with the received dynamic security code value to confirm that the two match.
- the verification process may be a cryptographic process and may involve use of one or more cryptographic keys.
- the required inputs to the code generation process performed by the dynamic validation service module 204 may be available in the account database 312 depicted in FIG. 3 , and may be indexed by the PAN for the relevant payment account.
- the required inputs may include one or more cryptographic keys that may be stored in the entry for the relevant account in the account database 312 .
- the notional match for the received dynamic security code, with the former having been generated in the dynamic validation service module 204 may be referred to as a “parallel-generated dynamic security code”, given that the generation process in the dynamic validation service module 204 is parallel to the code generation process performed in the payment card.
- the account issuer may select the time-frame and/or circumstances under which the payment cards generate new values of the dynamic security code. For example, in some embodiments, the payment cards for a given account issuer (or class of accounts) may generate a new code value every hour, or at some other regular interval.
- the corresponding data entry in the account database 312 may point to data that identifies the code regeneration pattern for the payment card in question and/or may point to a suitable algorithm/process to duplicate the card-based code generation.
- the dynamic validation service module 204 may compare current, immediately preceding, and/or immediately succeeding parallel-generated code values with the dynamic security code as received in the verification request received at 508 . It will be understood that the immediately preceding parallel-generated code value may be adjacent the current parallel-generated code value in a sequence of parallel-generated code values for the relevant payment account, and similarly the current parallel-generated code value may be adjacent the succeeding parallel-generated code value in the sequence of parallel-generated code values for the relevant payment account.
- the software and/or hardware required to parallel-generate the dynamic security code in the dynamic validation service module 204 may be commercially available from, and may be obtained from, the supplier of the card blanks that incorporate the dynamic security code features, and which correspond to the payment account in question or the corresponding group of payment cards.
- a number of different dynamic security code generation and verification algorithms may be commercially available for use in connection with the payment system 200 .
- the verification process may have a number of different outcomes, such as “successful”, “invalid”, “timed out”, or “inconclusive”. The last may occur, for example, if the PAN submitted with the verification request is not found in the account database 312 .
- the dynamic validation service module 204 may pass the result of the verification process to the proxy computer 202 .
- Block 512 may follow block 510 in the process of FIG. 5 .
- the process of block 512 may be performed by the proxy computer 202 .
- the proxy computer 202 may add the result of the verification process (or an indicator therefor, which may also be considered the result) to the authorization request for the transaction for which dynamic security code verification was requested at 508 .
- the proxy computer 202 may transmit the authorization request to the payment network processing computer 206 , which may route the authorization request—including the verification result—to the issuer 114 a ( FIG. 2 ).
- the authorization request as transmitted by the payment network processing computer 206 to the issuer, may also include a static security code that the issuer had previously assigned of record to the payment account in question.
- the proxy computer 202 may have inserted the static security code into the authorization request before transmitting it to the issuer.
- the authorization request, as transmitted by the payment network processing computer 206 to the issuer may not include the dynamic security code value that was contained in the authorization request when it was received at 502 .
- the authorization request, as transmitted by the payment network processing computer 206 to the issuer may include an indication that a dynamic security code verification has been performed with respect to the authorization request.
- the process of FIG. 5 may have a lapse of time (represented at 516 ) after block 514 while the issuer processes the authorization request. In some embodiments, the lapse of time may typically be rather brief. Thereafter, the payment network processing computer 206 may receive the authorization response from the issuer 114 a , as indicated by block 518 . Then—as indicated at block 520 —the payment network processing computer 206 may route the authorization request to the acquirer 110 ( FIG. 2 ). In some embodiments, it may be necessary or desirable for the dynamic verification results to be stripped from the authorization response before it is sent to the acquirer. If so, this may be done at the proxy computer 202 or the payment network processing computer 206 .
- the issuer 114 a may receive (from the payment network processing computer 206 ) an authorization request that is different from a conventional authorization request.
- the authorization request may include a result of a dynamic security code verification process (the “verification result”).
- the issuer computer 114 a may be programmed to consider the verification result in determining whether or not to approve the authorization request. It may well be the case that a “successful” verification result will increase the likelihood that the issuer 114 a will approve the authorization request, and that an “invalid” verification result will decrease the likelihood that the issuer will approve the authorization request.
- the issuer computer 114 a may be programmed to approve high value transactions only if the verification result is “successful”. In another example, the issuer computer 114 a may be programmed to approve low value transactions (assuming the account is in good standing, etc.) even if the verification result is “invalid” or “inconclusive”. It may be up to the issuer to decide how it will act in various kinds of situations on the basis of the various possible verification results.
- the proxy computer 202 may perform so-called “stand-in” services, in which the proxy computer 202 may decide to approve or decline the transaction—based on one or more rules pre-determined by the account issuer—in cases where no authorization response is received from the issuer.
- the rule(s) may provide that the proxy computer 202 is to make the decision on the transaction based at least in part on the dynamic security code verification result generated with respect to the corresponding authorization request.
- dynamic security code verification service As described herein, an account issuer's adoption of dynamic security code payment cards may be highly streamlined, since little change in infrastructure may be required for the issuer apart from a modest amount of programming of its computer that handles authorization requests. With this service, the issuer is immediately compatible with all online merchants and does not need to install platform-specific hardware or software. At the same time, the issuer may benefit by the improved protections against fraudulent transactions supported by use of dynamic security codes.
- merchants may not need to change their systems at all, or only to a limited extent, and may also benefit from reduced risk of fraudulent transactions. For cardholders also, little in the way of adaptation may be required, and enhanced security may be provided.
- the proxy computer 202 may detect that an incoming authorization request includes a dynamic security code by comparing a PAN included in the authorization request with relevant ranges of account numbers.
- one or more other processes may be employed to detect that the incoming authorization request includes a dynamic security code.
- the incoming authorization request may carry an indicator that shows that the security code contained within the authorization request is dynamic, and the proxy computer 202 may read the indicator.
- card-on-file transactions submitted by merchants may include a previously verified dynamic security code, and in such cases, and in some embodiments, the system 200 would not re-verify the dynamic security code.
- the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
- processor should be understood to encompass a single processor or two or more processors in communication with each other.
- memory should be understood to encompass a single memory or storage device or two or more memories or storage devices.
- a “server” includes a computer device or system that responds to numerous requests for service from other devices.
- the term “payment card system account” includes a credit card account, a deposit account that the account holder may access using a debit card, a prepaid card account, or any other type of account from which payment transactions may be consummated.
- the terms “payment card system account” and “payment card account” and “payment account” are used interchangeably herein.
- the term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions.
- the term “payment card” includes a credit card, debit card, prepaid card, or other type of payment instrument, whether an actual physical card or virtual.
- the term “payment card system” refers to a system for handling purchase transactions and related transactions.
- An example of such a system is the one operated by MasterCard International Incorporated, the assignee of the present disclosure.
- the term “payment card system” may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- This application claims the benefit of U.S. Provisional Patent Application No. 62/265,020 filed on Dec. 9, 2015, the contents of which are hereby incorporated by reference for all purposes.
- Payment accounts are in widespread use for both in-store and online purchase transactions.
FIG. 1 is a block diagram of aconventional payment system 100 as it may operate in connection with an online purchase transaction. - The
system 100 includes ane-commerce server computer 102 that may be operated by or on behalf of an online merchant to permit online shopping transactions. For this purpose, as is well known, thee-commerce server computer 102 may host a shopping website, sometimes referred to as an “online store”. Acustomer 103 who operates acustomer device 104 may access the shopping website by communicating over the Internet 105 with thee-commerce server computer 102. As is very well-known to those who are skilled in the art, thecustomer device 104 may be, for example, a personal computer or notebook computer that runs a browser program, a tablet computer or smartphone that runs a mobile browser and/or a suitable app, etc. In entering payment information into a page served by thee-commerce server computer 102 to thecustomer device 104, thecustomer 103 may refer to apayment card 106 issued to thecustomer 103 in connection with the payment account to be used for the current online purchase transaction. - In connection with the online purchase transaction, the
e-commerce server computer 102 may transmit a transaction authorization request message (sometimes simply referred to as an “authorization request”) to the merchant's acquirer financial institution (“acquirer” or “transaction acquirer”), indicated byreference numeral 110. Theacquirer 110 may route the authorization request via apayment network 112 to aserver computer 114 operated by the issuer of the payment account that corresponds to thepayment card 106 and the payment account number provided by the customer as part of the checkout process for the online purchase transaction. Also, the authorization response generated by theissuer server computer 114 may be routed back to theacquirer 110 via thepayment network 112. Theacquirer 110 may confirm to the merchant (i.e., to the e-commerce server computer 102) that the transaction has been approved. - As is familiar to those who engage in online purchase transactions, during the checkout phase of the transaction the customer may enter payment related information such as the customer's name as it appears on the payment account, the PAN (primary account number) that identifies the payment account, and the current expiration date for the account. In addition, the customer may—in many cases—be prompted to enter a three or four digit security code that typically is printed on the rear face (on the signature slip) of the payment card. Common names for such a code include “CVC” (card verification code) and “CVV” (card verification value). All of these items of information may be included in the authorization request.
- Referring again to
FIG. 1 , thepayment network 112 may be, for example, the well-known Banknet® system operated by MasterCard International Incorporated, which is the assignee hereof. - The components of the
system 100 as depicted inFIG. 1 are only those that are needed for processing a single transaction. Those who are skilled in the art will recognize that in the real world, online shopping and payment systems may process many purchase transactions (including simultaneous transactions) and may include a considerable number of payment account issuers and their computers, a considerable number of acquirers and their computers, and numerous merchants and their e-commerce servers. The system may also include a very large number of customers/online shoppers, who hold payment accounts that they use for their online shopping activities. It is also well known that elements of the system 100 (e.g., acquirers, the payment network, payment account issuers) may play similar roles in connection with in-store purchase transactions and in other types of transactions. - Resuming the above discussion of the security code printed on the card, it has been proposed, for purposes of deterring and/or preventing fraudulent transactions, to enhance the security code feature. For example, in U.S. Pat. No. 8,919,643 and U.S. Patent publication no. 2012/0153028, it has been proposed that processing capability on the payment card (i.e., where the payment card is embodied as an IC card) be utilized to dynamically vary the security code, and to display the current value of the dynamic security code on a display element included in the payment card. However, verification of dynamic security codes may place a significant burden on the card/account issuer, thereby making it unattractive or uneconomic to incorporate dynamic security codes in an issuer's payment account practices.
- Features and advantages of some embodiments of the present disclosure, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the disclosure taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
-
FIG. 1 is a block diagram that illustrates a conventional system that handles online purchase transactions. -
FIG. 2 is a block diagram of salient portions of a payment system according to some embodiments. -
FIGS. 3 and 4 are block diagram representations of computers that may serve as components of the system shown inFIG. 2 . -
FIG. 5 is a flow chart that illustrates aspects of the present disclosure. - In general, and for the purpose of introducing concepts of embodiments of the present disclosure, a service may be provided to detect authorization requests that contain dynamic security codes. The service also incorporates verification of the dynamic security code included in the authorization request, and adding to the authorization request an indication of the result of the verification process. The authorization request, including the dynamic security code verification result, may then be routed to the account issuer for approval (if appropriate) of the authorization request.
-
FIG. 2 is a block diagram of salient portions of apayment system 200 provided according to some embodiments. The representation of thepayment system 200 as shown inFIG. 2 assumes in addition that other aspects of the payment system (that were seen inFIG. 1 ) are also present but not shown inFIG. 2 . For example, the representation inFIG. 2 assumes that a merchant e-commerce server 102 (FIG. 1 ) has generated and sent to the transaction acquirer 110 (FIG. 2 andFIG. 1 ) an authorization request that corresponds to an online purchase transaction performed via the e-commerce website hosted by the e-commerce server. It will further be appreciated that, in such a circumstance, a customer 103 (FIG. 1 ) performed the online purchase transaction using a customer device 104 (FIG. 1 ) that accessed the e-commerce server and the merchant's website via the internet 105 (FIG. 1 ). It will further be assumed, for present purposes, that the customer visually referred to a payment card 106 (FIG. 1 ); a further assumption is that the payment card was of a commercially available type that is an IC (integrated circuit) card that generates and displays a time-varying dynamic security code. A further assumption is that the currently displayed value of the dynamic security code was read by the customer, entered by the customer as part of the payment information solicited by the e-commerce website, and included in the authorization request message generated by the e-commerce server and transmitted to theacquirer 110. A further assumption may be that the authorization request message is in a standard format for such messages and includes a PAN (primary account number) that identifies the payment account designated by the customer for use in the current purchase transaction. - In addition to the
acquirer 110, thepayment system 200 as shown inFIG. 2 includes aproxy computer 202 that performs on-behalf and/or stand-in processes—i.e., functions that might otherwise need to be performed by the account issuers. Thepayment system 200 further includes a dynamicvalidation service module 204 and a paymentnetwork processing computer 206. Dottedline box 208, which encompasses theproxy computer 202, the dynamicvalidation service module 204 and the paymentnetwork processing computer 206, is intended to imply that all three of the latter system components may be operated by the operator of a payment network, the main functions of which may be implemented by the paymentnetwork processing computer 206. Thus the paymentnetwork processing computer 206 may be seen as a modified analog of thepayment network 112 referred to above in connection withFIG. 1 . - Further details of the functionality provided by the
proxy computer 202, the dynamicvalidation service module 204 and the paymentnetwork processing computer 206 will be described below. In terms of a brief overview, the paymentnetwork processing computer 206 may receive authorization requests from acquirers (such as theacquirer 110 shown inFIG. 2 ). The paymentnetwork processing computer 206 may forward the authorization requests to theproxy computer 202, which may detect authorization requests that contain dynamic security codes, and forward those codes for validation by the dynamicvalidation service module 204. The dynamicvalidation service module 204 may perform a verification process with respect to the dynamic security codes and provide the results of the verification process to theproxy computer 202. Theproxy computer 202 may append the verification process results to the authorization requests and transmit them to the paymentnetwork processing computer 206, which may route the authorization requests to account issuers, such as theissuer 114 a shown inFIG. 2 (block 114 a should also be understood to represent a computer operated by or for the issuer). Authorization responses from the issuers may be routed back to the acquirers via the paymentnetwork processing computer 206. - As was the case in the payment system depiction of
FIG. 1 , the system components shown inFIG. 2 are only those that may be required to handle a single transaction. For example, there may be a considerable number of transaction acquirers and account issuers in a practical embodiment of thepayment system 200. Thepayment system 200, in a practical embodiment, may handle numerous transactions, including simultaneous transactions. Moreover, one or more components of thepayment system 200 may handle in-store purchase transactions and/or other types of transactions in addition to online purchase transactions. - In some embodiments, any two or more of the
proxy computer 202, the dynamicvalidation service module 204, and/or the paymentnetwork processing computer 206 may be constituted by components of an interrelated and/or integrated computer system and/or may be housed together in a single data center. -
FIG. 3 is a block diagram representation of an embodiment of the dynamicvalidation service module 204. - In some embodiments, the dynamic
validation service module 204 may be implemented using a software and/or hardware module solution that is commercially available from a supplier of the above-mentioned IC payment cards with dynamic security code features. In some embodiments, the dynamicvalidation service module 204 may be embodied in a hardware security module (HSM). In some embodiments the dynamicvalidation service module 204 may be constituted at least in part by typical server computer hardware, but may be controlled by software to cause it to function as described herein. Suitable security measures may be applied to the dynamicvalidation service module 204. - The dynamic
validation service module 204 may include aprocessor 300 operatively coupled to acommunication device 301, astorage device 304, aninput device 306 and anoutput device 308. Thecommunication device 301, thestorage device 304, theinput device 306 and theoutput device 308 may all be in communication with theprocessor 300. - The
processor 300 may be constituted by one or more processors. Theprocessor 300 may operate to execute processor-executable steps, contained in program instructions described below, so as to control the dynamicvalidation service module 204 to provide desired functionality. -
Communication device 301 may be used to facilitate communication with, for example, other devices (such as theproxy computer 202 and the payment network processing computer 206). For example,communication device 301 may comprise numerous communication ports (not separately shown), to allow the dynamicvalidation service module 204 to receive and process numerous simultaneous dynamic security code validation requests. -
Input device 306 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, theinput device 306 may include a keyboard and a mouse.Output device 308 may comprise, for example, a display and/or a printer. (In some embodiments, input/output functions relative to the dynamicvalidation service module 204 may be handled via an associated computer such as theproxy computer 202.) -
Storage device 304 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory. -
Storage device 304 stores one or more programs for controllingprocessor 300. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the dynamicvalidation service module 204, executed by theprocessor 300 to cause the dynamicvalidation service module 204 to function as described herein. - The programs may include one or more conventional operating systems (not shown) or kernels that control the
processor 300 so as to manage and coordinate activities and sharing of resources in the dynamicvalidation service module 204, and to serve as a host for application programs (described below) that run on the dynamicvalidation service module 204. - The programs stored in the
storage device 304 may also include a validationrequest handling program 310 that controls theprocessor 300 to enable the dynamicvalidation service module 204 to handle and process dynamic security code validation requests. - The
storage device 304 may also store, and the dynamicvalidation service module 204 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by the dynamicvalidation service module 204. The other programs may also include, e.g., device drivers, database management programs, etc. - The
storage device 304 may also store anaccount database 312 that is referenced by the validationrequest handling program 310 in connection with performing a verification process with respect to dynamic security codes received by the dynamicvalidation service module 204 from theproxy computer 202. -
FIG. 4 is a block diagram of an embodiment of theproxy computer 202. - In its hardware architecture and components, the
proxy computer 202 may, for example, resemble the hardware architecture and components described above in connection withFIG. 3 . However, theproxy computer 202 may be programmed differently from the dynamicvalidation service module 204 so as to provide different functionality. - Returning again to the hardware aspects of the
proxy computer 202, it may include aprocessor 400, acommunication device 401, astorage device 404, aninput device 406 and anoutput device 408. Thecommunication device 401, thestorage device 404, theinput device 406 and theoutput device 408 may all be in communication with theprocessor 400. - The above descriptions of the hardware components shown in
FIG. 3 may, in some embodiments, also be applicable to the like-named components shown inFIG. 4 . -
Storage device 404 stores one or more programs for controllingprocessor 400. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of theproxy computer 202, executed by theprocessor 400 to cause theproxy computer 202 to function as described herein. - The programs may include one or more conventional operating systems (not shown) that control the
processor 400 so as to manage and coordinate activities and sharing of resources in theproxy computer 202, and to serve as a host for application programs (described below) that run on theproxy computer 202. - The
storage device 404 may store atransaction handling program 410 that handles receipt, processing and transmission of messages related to payment account transactions. Thetransaction handling program 410 may implement functionality of theproxy computer 202 as described herein and in accordance with some embodiments. - The
storage device 404 may also storesoftware 412 that serves as an interface between theproxy computer 202 and the dynamicvalidation service module 204. - The
storage device 404 may also store, and theproxy computer 202 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by theproxy computer 202. The other programs may also include, e.g., device drivers, database management programs, etc. - The
storage device 404 may also store one or more databases (reference numeral 414) required for operation of theproxy computer 202. - The payment
network processing computer 206 may have the same type of hardware architecture and/or components as the computing device described above in connection withFIG. 3 . In addition, the paymentnetwork processing computer 206 may be programmed to perform conventional functions of a payment network as well as additional functions in accordance with aspects of the present disclosure and as described herein. - The
issuer computer 114 a may also have the same type of hardware architecture and/or components as described above in connection withFIG. 3 , and may be programmed to provide functionality as described herein. -
FIG. 5 is a flow chart that illustrates aspects of the present disclosure, including operations performed individually and/or cooperatively by theproxy computer 202, dynamicvalidation service module 204 and the paymentnetwork processing computer 206. - As indicated at 502 in
FIG. 5 , the paymentnetwork processing computer 206 may receive an authorization request message from anacquirer 110, and may forward the authorization request message to theproxy computer 202. - The processing by the
proxy computer 202 may include adecision block 504. At thedecision block 504, theproxy computer 202 may determine whether the authorization request received at 502 contains a dynamic security code. In some embodiments, for example, theproxy computer 202 may make this determination based on the PAN included in the authorization request. (It will be recalled that the PAN identifies the payment account designated by the customer for use in the transaction represented by the authorization request.) In particular, theproxy computer 202 may determine whether the PAN falls within one or more ranges of account numbers that have been indicated by the respective account issuers as being associated with payment accounts for which dynamic security code features were implemented (i.e., accounts for which the issued payment cards embody a dynamic security code feature). The determination may be made, for example, with reference to one or more of thedatabases 414 depicted inFIG. 4 . If a negative determination is made at 504 (i.e., if it is determined that the authorization request does not include a dynamic security code), then block 506 may followdecision block 504 in the process ofFIG. 5 .Block 506 represents handling and processing the authorization request on the assumption that it contains a static rather than dynamic security code. This may result in the authorization request being handled and processed in a conventional manner. - Considering decision block 504 again, if a positive determination is made at that decision block (i.e., if the authorization request is determined to include a dynamic security code), then the process of
FIG. 5 may advance fromdecision block 504 to block 508. - At
block 508, theproxy computer 202 many generate and transmit a request for verification of the dynamic security code. The request may be transmitted from theproxy computer 202 to the dynamicvalidation service module 204 and may be received by the dynamicvalidation service module 204. The request may include, for example, the dynamic security code value to be verified and the PAN that was included in the authorization request received at 502. - Following
block 508 isblock 510.Block 510 includes a dynamic security code verification process, which may be performed by the dynamicvalidation service module 204. In some embodiments, the verification process may involve duplicating the process performed in the payment card to generate the dynamic security code and comparing the result of the code generation process performed by the dynamicvalidation service module 204 with the received dynamic security code value to confirm that the two match. The verification process may be a cryptographic process and may involve use of one or more cryptographic keys. In some embodiments, the required inputs to the code generation process performed by the dynamicvalidation service module 204 may be available in theaccount database 312 depicted inFIG. 3 , and may be indexed by the PAN for the relevant payment account. The required inputs may include one or more cryptographic keys that may be stored in the entry for the relevant account in theaccount database 312. The notional match for the received dynamic security code, with the former having been generated in the dynamicvalidation service module 204, may be referred to as a “parallel-generated dynamic security code”, given that the generation process in the dynamicvalidation service module 204 is parallel to the code generation process performed in the payment card. - In some embodiments, the account issuer may select the time-frame and/or circumstances under which the payment cards generate new values of the dynamic security code. For example, in some embodiments, the payment cards for a given account issuer (or class of accounts) may generate a new code value every hour, or at some other regular interval. The corresponding data entry in the
account database 312 may point to data that identifies the code regeneration pattern for the payment card in question and/or may point to a suitable algorithm/process to duplicate the card-based code generation. In some embodiments, to deal with issues of time drift, latency in receiving the authorization and/or validation requests, etc., the dynamicvalidation service module 204 may compare current, immediately preceding, and/or immediately succeeding parallel-generated code values with the dynamic security code as received in the verification request received at 508. It will be understood that the immediately preceding parallel-generated code value may be adjacent the current parallel-generated code value in a sequence of parallel-generated code values for the relevant payment account, and similarly the current parallel-generated code value may be adjacent the succeeding parallel-generated code value in the sequence of parallel-generated code values for the relevant payment account. - In some embodiments, the software and/or hardware required to parallel-generate the dynamic security code in the dynamic
validation service module 204 may be commercially available from, and may be obtained from, the supplier of the card blanks that incorporate the dynamic security code features, and which correspond to the payment account in question or the corresponding group of payment cards. - A number of different dynamic security code generation and verification algorithms may be commercially available for use in connection with the
payment system 200. - The verification process may have a number of different outcomes, such as “successful”, “invalid”, “timed out”, or “inconclusive”. The last may occur, for example, if the PAN submitted with the verification request is not found in the
account database 312. The dynamicvalidation service module 204 may pass the result of the verification process to theproxy computer 202. -
Block 512 may follow block 510 in the process ofFIG. 5 . The process ofblock 512 may be performed by theproxy computer 202. At 512, theproxy computer 202 may add the result of the verification process (or an indicator therefor, which may also be considered the result) to the authorization request for the transaction for which dynamic security code verification was requested at 508. Then, at 514, theproxy computer 202 may transmit the authorization request to the paymentnetwork processing computer 206, which may route the authorization request—including the verification result—to theissuer 114 a (FIG. 2 ). In some embodiments, the authorization request, as transmitted by the paymentnetwork processing computer 206 to the issuer, may also include a static security code that the issuer had previously assigned of record to the payment account in question. Theproxy computer 202 may have inserted the static security code into the authorization request before transmitting it to the issuer. In some embodiments, the authorization request, as transmitted by the paymentnetwork processing computer 206 to the issuer, may not include the dynamic security code value that was contained in the authorization request when it was received at 502. In some embodiments, the authorization request, as transmitted by the paymentnetwork processing computer 206 to the issuer, may include an indication that a dynamic security code verification has been performed with respect to the authorization request. - In some embodiments, the process of
FIG. 5 may have a lapse of time (represented at 516) afterblock 514 while the issuer processes the authorization request. In some embodiments, the lapse of time may typically be rather brief. Thereafter, the paymentnetwork processing computer 206 may receive the authorization response from theissuer 114 a, as indicated byblock 518. Then—as indicated atblock 520—the paymentnetwork processing computer 206 may route the authorization request to the acquirer 110 (FIG. 2 ). In some embodiments, it may be necessary or desirable for the dynamic verification results to be stripped from the authorization response before it is sent to the acquirer. If so, this may be done at theproxy computer 202 or the paymentnetwork processing computer 206. - One implication of the foregoing is that the
issuer 114 a may receive (from the payment network processing computer 206) an authorization request that is different from a conventional authorization request. The difference may lie in that, in accordance with the present disclosure, the authorization request may include a result of a dynamic security code verification process (the “verification result”). Accordingly, theissuer computer 114 a may be programmed to consider the verification result in determining whether or not to approve the authorization request. It may well be the case that a “successful” verification result will increase the likelihood that theissuer 114 a will approve the authorization request, and that an “invalid” verification result will decrease the likelihood that the issuer will approve the authorization request. For example, theissuer computer 114 a may be programmed to approve high value transactions only if the verification result is “successful”. In another example, theissuer computer 114 a may be programmed to approve low value transactions (assuming the account is in good standing, etc.) even if the verification result is “invalid” or “inconclusive”. It may be up to the issuer to decide how it will act in various kinds of situations on the basis of the various possible verification results. - In some embodiments, the
proxy computer 202 may perform so-called “stand-in” services, in which theproxy computer 202 may decide to approve or decline the transaction—based on one or more rules pre-determined by the account issuer—in cases where no authorization response is received from the issuer. In some embodiments, the rule(s) may provide that theproxy computer 202 is to make the decision on the transaction based at least in part on the dynamic security code verification result generated with respect to the corresponding authorization request. - With a dynamic security code verification service as described herein, an account issuer's adoption of dynamic security code payment cards may be highly streamlined, since little change in infrastructure may be required for the issuer apart from a modest amount of programming of its computer that handles authorization requests. With this service, the issuer is immediately compatible with all online merchants and does not need to install platform-specific hardware or software. At the same time, the issuer may benefit by the improved protections against fraudulent transactions supported by use of dynamic security codes.
- By the same token, merchants may not need to change their systems at all, or only to a limited extent, and may also benefit from reduced risk of fraudulent transactions. For cardholders also, little in the way of adaptation may be required, and enhanced security may be provided.
- In embodiments described above, the
proxy computer 202 may detect that an incoming authorization request includes a dynamic security code by comparing a PAN included in the authorization request with relevant ranges of account numbers. However, in alternative embodiments, one or more other processes may be employed to detect that the incoming authorization request includes a dynamic security code. For example, in some embodiments, the incoming authorization request may carry an indicator that shows that the security code contained within the authorization request is dynamic, and theproxy computer 202 may read the indicator. - In some embodiments, card-on-file transactions submitted by merchants may include a previously verified dynamic security code, and in such cases, and in some embodiments, the
system 200 would not re-verify the dynamic security code. - As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
- As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.
- As used herein and in the appended claims, the term “memory” should be understood to encompass a single memory or storage device or two or more memories or storage devices.
- As used herein and in the appended claims, a “server” includes a computer device or system that responds to numerous requests for service from other devices.
- The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method steps may be performed in any order that is practicable, including simultaneous performance of steps.
- As used herein and in the appended claims, the term “payment card system account” includes a credit card account, a deposit account that the account holder may access using a debit card, a prepaid card account, or any other type of account from which payment transactions may be consummated. The terms “payment card system account” and “payment card account” and “payment account” are used interchangeably herein. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions. The term “payment card” includes a credit card, debit card, prepaid card, or other type of payment instrument, whether an actual physical card or virtual.
- As used herein and in the appended claims, the term “payment card system” refers to a system for handling purchase transactions and related transactions. An example of such a system is the one operated by MasterCard International Incorporated, the assignee of the present disclosure. In some embodiments, the term “payment card system” may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses and/or other organizations.
- Although the present disclosure has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the disclosure as set forth in the appended claims.
Claims (20)
Priority Applications (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/007,837 US20170169426A1 (en) | 2015-12-09 | 2016-01-27 | Dynamic security code authorization verification service |
PCT/US2016/065045 WO2017100144A1 (en) | 2015-12-09 | 2016-12-06 | Dynamic security code authorization verification service |
SG11201804606WA SG11201804606WA (en) | 2015-12-09 | 2016-12-06 | Dynamic security code authorization verification service |
AU2016367101A AU2016367101A1 (en) | 2015-12-09 | 2016-12-06 | Dynamic security code authorization verification service |
CA3007949A CA3007949C (en) | 2015-12-09 | 2016-12-06 | Dynamic security code authorization verification service |
CN201680072226.XA CN108369705A (en) | 2015-12-09 | 2016-12-06 | Dynamic security encodes authority checking service |
US16/995,374 US11341494B2 (en) | 2015-12-09 | 2020-08-17 | Dynamic security code authorization verification service |
US17/750,974 US20220277303A1 (en) | 2015-12-09 | 2022-05-23 | Dynamic security code authorization verification service |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201562265020P | 2015-12-09 | 2015-12-09 | |
US15/007,837 US20170169426A1 (en) | 2015-12-09 | 2016-01-27 | Dynamic security code authorization verification service |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/995,374 Continuation US11341494B2 (en) | 2015-12-09 | 2020-08-17 | Dynamic security code authorization verification service |
Publications (1)
Publication Number | Publication Date |
---|---|
US20170169426A1 true US20170169426A1 (en) | 2017-06-15 |
Family
ID=57680529
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/007,837 Abandoned US20170169426A1 (en) | 2015-12-09 | 2016-01-27 | Dynamic security code authorization verification service |
US16/995,374 Active US11341494B2 (en) | 2015-12-09 | 2020-08-17 | Dynamic security code authorization verification service |
US17/750,974 Pending US20220277303A1 (en) | 2015-12-09 | 2022-05-23 | Dynamic security code authorization verification service |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/995,374 Active US11341494B2 (en) | 2015-12-09 | 2020-08-17 | Dynamic security code authorization verification service |
US17/750,974 Pending US20220277303A1 (en) | 2015-12-09 | 2022-05-23 | Dynamic security code authorization verification service |
Country Status (6)
Country | Link |
---|---|
US (3) | US20170169426A1 (en) |
CN (1) | CN108369705A (en) |
AU (1) | AU2016367101A1 (en) |
CA (1) | CA3007949C (en) |
SG (1) | SG11201804606WA (en) |
WO (1) | WO2017100144A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200143381A1 (en) * | 2018-11-06 | 2020-05-07 | Paypal, Inc. | System and Method for Obtaining a Temporary CVV using Tokenization Rails |
US11580558B2 (en) * | 2020-02-07 | 2023-02-14 | Focus Universal Inc. | Dynamic anti-counterfeit system and method |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170169426A1 (en) * | 2015-12-09 | 2017-06-15 | Mastercard International Incorporated | Dynamic security code authorization verification service |
US11514452B2 (en) * | 2018-03-30 | 2022-11-29 | Block, Inc. | Multi-device point-of-sale system having multiple merchant-facing devices |
CA3062211A1 (en) * | 2018-11-26 | 2020-05-26 | Mir Limited | Dynamic verification method and system for card transactions |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7793851B2 (en) * | 2005-05-09 | 2010-09-14 | Dynamics Inc. | Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card |
US7835988B2 (en) * | 2007-06-05 | 2010-11-16 | Mastercard International, Inc. | Methods and apparatus for preventing fraud in payment processing transactions |
US7849014B2 (en) * | 2007-08-29 | 2010-12-07 | American Express Travel Related Services Company, Inc. | System and method for facilitating a financial transaction with a dynamically generated identifier |
EP2245583A1 (en) * | 2008-01-04 | 2010-11-03 | M2 International Ltd. | Dynamic card verification value |
US20100036741A1 (en) * | 2008-08-04 | 2010-02-11 | Marc Cleven | Application currency code for dynamic currency conversion transactions with contactless consumer transaction payment device |
US20110060640A1 (en) * | 2009-09-04 | 2011-03-10 | American Express Travel Related Services Co., Inc. | System, method and apparatus for providing messages to a transaction instrument |
WO2014093390A1 (en) * | 2012-12-10 | 2014-06-19 | Visa International Service Association | Authenticating remote transactions using a mobile device |
CA2908875A1 (en) * | 2013-04-12 | 2014-10-16 | Mastercard International Incorporated | Analytics rules engine for payment processing system |
CA2918066A1 (en) * | 2013-07-15 | 2015-01-22 | Visa International Service Association | Secure remote payment transaction processing |
US20150161612A1 (en) * | 2013-12-05 | 2015-06-11 | Mastercard International Incorporated | Method and system for network based dynamic cvc authentication |
CN104915832B (en) * | 2015-06-25 | 2019-05-14 | 中国工商银行股份有限公司 | Mobile payment, verification method and its device and system |
US20170169426A1 (en) * | 2015-12-09 | 2017-06-15 | Mastercard International Incorporated | Dynamic security code authorization verification service |
-
2016
- 2016-01-27 US US15/007,837 patent/US20170169426A1/en not_active Abandoned
- 2016-12-06 WO PCT/US2016/065045 patent/WO2017100144A1/en active Application Filing
- 2016-12-06 SG SG11201804606WA patent/SG11201804606WA/en unknown
- 2016-12-06 CA CA3007949A patent/CA3007949C/en active Active
- 2016-12-06 AU AU2016367101A patent/AU2016367101A1/en not_active Abandoned
- 2016-12-06 CN CN201680072226.XA patent/CN108369705A/en active Pending
-
2020
- 2020-08-17 US US16/995,374 patent/US11341494B2/en active Active
-
2022
- 2022-05-23 US US17/750,974 patent/US20220277303A1/en active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200143381A1 (en) * | 2018-11-06 | 2020-05-07 | Paypal, Inc. | System and Method for Obtaining a Temporary CVV using Tokenization Rails |
US11580558B2 (en) * | 2020-02-07 | 2023-02-14 | Focus Universal Inc. | Dynamic anti-counterfeit system and method |
US20230186322A1 (en) * | 2020-02-07 | 2023-06-15 | Focus Universal Inc. | Dynamic anti-counterfeit system and method |
Also Published As
Publication number | Publication date |
---|---|
US20220277303A1 (en) | 2022-09-01 |
US20200380515A1 (en) | 2020-12-03 |
CN108369705A (en) | 2018-08-03 |
SG11201804606WA (en) | 2018-06-28 |
AU2016367101A1 (en) | 2018-06-14 |
US11341494B2 (en) | 2022-05-24 |
CA3007949A1 (en) | 2017-06-15 |
CA3007949C (en) | 2020-12-15 |
WO2017100144A1 (en) | 2017-06-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11341494B2 (en) | Dynamic security code authorization verification service | |
CA3008396C (en) | Browser extension for limited-use secure token payment | |
US20170364918A1 (en) | Systems and methods for budget, financial account alerts management, remedial action controls and fraud monitoring | |
US20170295155A1 (en) | Tokenization of co-network accounts | |
US20180276656A1 (en) | Instant issuance of virtual payment account card to digital wallet | |
CN112368730A (en) | Secure remote transaction framework using dynamic secure checkout elements | |
US10796311B2 (en) | Authentication using transaction history | |
US20220036347A1 (en) | Payment transaction process employing dynamic account expiry and dynamic token verification code | |
US20160232525A1 (en) | Online form fill for tokenized credentials | |
CN108292376B (en) | Method and apparatus for cross-card authentication using wallet transaction authentication history | |
US20190095922A1 (en) | Cooperative fraud-detection processing | |
US20190012645A1 (en) | System and methods for accepting dual function payment credential | |
US20160140557A1 (en) | E-commerce based payment system with authentication of electronic invoices | |
US20170308900A1 (en) | System and method for scoring cross border transactions | |
US10924477B2 (en) | System and methods for client identification and verification | |
WO2019125617A1 (en) | Payment systems and methods with card-on-file tokenization | |
US20160210608A1 (en) | Merchant interface for transaction-related services | |
EP3743869A1 (en) | Provisioning of payment acceptance to payment account holders | |
US20220044251A1 (en) | Systems and methods for use in identifying network interactions | |
AU2017381404A1 (en) | A transaction processing system and method | |
US20200097931A1 (en) | Payment transaction process employing invoice token | |
US20200118125A1 (en) | Token-based payment transaction authorized at payment gateway | |
US20190205880A1 (en) | Systems and methods for validating payment transactions |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MASTERCARD INTERNATIONAL INCORPORATED, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WARNER, MARIBETH SEVIGNY;KAULBACH, PETE;DUNNELL, ROBERT C;AND OTHERS;SIGNING DATES FROM 20151209 TO 20151216;REEL/FRAME:037599/0432 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: ADVISORY ACTION MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: NOTICE OF APPEAL FILED |
|
STCV | Information on status: appeal procedure |
Free format text: APPEAL BRIEF (OR SUPPLEMENTAL BRIEF) ENTERED AND FORWARDED TO EXAMINER |
|
STCV | Information on status: appeal procedure |
Free format text: EXAMINER'S ANSWER TO APPEAL BRIEF MAILED |
|
STCV | Information on status: appeal procedure |
Free format text: ON APPEAL -- AWAITING DECISION BY THE BOARD OF APPEALS |
|
STCV | Information on status: appeal procedure |
Free format text: BOARD OF APPEALS DECISION RENDERED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |