+

WO2017039999A1 - Sécurisation de traitement de vente par correspondance/vente téléphonique - Google Patents

Sécurisation de traitement de vente par correspondance/vente téléphonique Download PDF

Info

Publication number
WO2017039999A1
WO2017039999A1 PCT/US2016/046721 US2016046721W WO2017039999A1 WO 2017039999 A1 WO2017039999 A1 WO 2017039999A1 US 2016046721 W US2016046721 W US 2016046721W WO 2017039999 A1 WO2017039999 A1 WO 2017039999A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
merchant
account holder
processor
data corresponding
Prior art date
Application number
PCT/US2016/046721
Other languages
English (en)
Inventor
Sebastien SLATTER
Michael COWEN
Original Assignee
Mastercard International Incorporated
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mastercard International Incorporated filed Critical Mastercard International Incorporated
Publication of WO2017039999A1 publication Critical patent/WO2017039999A1/fr

Links

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
    • 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/08—Payment architectures
    • G06Q20/16—Payments settled via telecommunication systems
    • 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
    • G06Q20/3821—Electronic credentials

Definitions

  • the present disclosure relates to methods of securing and processing mail order/telephone order (MO/TO) transactions, computer-readable media for storing instructions which, when executed, cause a processor to implement such methods, and computer systems in which such methods are implemented.
  • MO/TO mail order/telephone order
  • CNP transactions are payment card transactions made without a payment (e.g. debit or credit) card being physically present at a merchant point of sale (POS).
  • CNP transactions include mail order transactions and telephone order transactions, collectively known as MO/TO transactions.
  • an account holder To make a MO/TO transaction, an account holder must provide a merchant with certain payment credentials, usually details present on their payment card such as the card number, the name of the account holder, the card expiry date and a security code (e.g. card verification value, CVV, or card security code, CSC).
  • a security code e.g. card verification value, CVV, or card security code, CSC.
  • MO/TO Mail Order/Telephone Order
  • said method being performed by a MO/TO merchant-facing application running on a processor of a merchant computing device and comprising: receiving a MO/TO transaction request, comprising data corresponding to a token, from a merchant; and responsive thereto, initiating obtaining payment credentials using said data.
  • the method could further comprise initiating validation of said credentials to authorise and complete said transaction.
  • the method could further comprise, subsequent to said authorisation, receiving a transaction approval.
  • the method could further comprise, responsive thereto, providing said merchant with a transaction confirmation.
  • Said obtaining could comprise matching the data corresponding to token to data corresponding to the credentials.
  • the data corresponding to the credentials could be stored by said payment application or an entity in communication with it
  • Said matching could comprise searching for die data corresponding to the token, or a code derived therefrom, according to a predetermined algorithm, in a look-up table comprising pairs of linked token data and credential data.
  • Said obtaining could comprise operating on the data corresponding to the token according to a predetermined decoding algorithm to output data corresponding to the credentials.
  • Said transaction request could further comprise a timestamp. Both the data corresponding to token and said timestamp could be input to said decoding algorithm.
  • Said obtaining could comprise checking that the token is not present on a list of previously used tokens.
  • a computer-readable medium storing computer-executable instructions that, when performed by a processor, cause said processor to perform the method of the first aspect.
  • a method of securing a Mail Order/Telephone Order (MO/TO) transaction being performed by a ⁇ /T ⁇ account holder-facing application running on a processor of an account holder computing device and comprising: receiving a MO/TO token request from an account holder, and responsive thereto, obtaining data corresponding to a token for use in a MO/TO transaction request to be provided to a merchant having access to a merchant-facing application corresponding to said account holder-facing application, said merchant-facing application being configured to initiate obtaining payment credentials using said data corresponding to the token.
  • MO/TO Mail Order/Telephone Order
  • the method could further comprise, prior to said obtaining, verifying said account holder's identity.
  • Said obtaining could comprise operating on data corresponding to a stored account identifier for an account held by said account holder according to a predetermined algorithm.
  • Said operating could further comprise inputting data corresponding to a current time value to said algorithm.
  • Said merchant-facing application could be configured to subsequently perform the method of the first aspect.
  • a computer-readable medium storing computer-executable instructions that, when performed by a processor, cause said processor to perform the method of the third aspect.
  • a computer system comprising a processor and a memory, said memory storing computer-executable instructions that, when performed by said processor, cause said processor to perform the method of either of the first or third aspects.
  • FIG 1 illustrates an example MO/TO system
  • Figure 2 illustrates an example MO/TO transaction process flow
  • Figure 3A illustrates a method of processing a MO/TO transaction performed by a MO/TO merchant-facing application
  • Figure 3B illustrates a method of securing a MO/TO transaction performed by a MO/TO account holder-facing application
  • Figure 4 illustrates an example computing system which could be used to perform either or both of the methods of Figures 3 A and 3B.
  • the token used need not be as long as conventional card payment credentials (16 digit card number, 4 digit expiry date, 3 digit CVV or CSC and the account holder's name). The likelihood of the account holder making errors when providing information necessary to complete the transaction, and the time taken to provide the information, can therefore be reduced.
  • the token could be a single use token generated by a MO/TO account holder-facing application in response to a request made by the account holder each time they wish to make a MO/TO transaction.
  • Such an account-holder facing application could comprise further functionality, for example it could be an electronic wallet application such as MasterPass®, Apple PayTM or Samsung Pay®.
  • the account holder-facing application could generate a unique token according to a predetermined algorithm with inputs of one or more of the payment credentials (or other details of the account or account holder, e.g. an account nickname specified by the account holder) and a timestamp, e.g. of the time the account holder-facing application receives a token request
  • the token could for example be generated by performing a mathematical operation on the payment credentials and the time, to encrypt the payment credentials, and appending or otherwise incorporating the timestamp to act as a decoding key.
  • the algorithm used to encrypt the payment credentials could be time-varying, e.g.
  • the timestamp could be appended to or otherwise incorporated into the token to inform the merchant-facing application which version of the algorithm to use.
  • the token could then be further encrypted.
  • the payment credentials would thus be encoded in such a way that only a processor running a corresponding secret decoding algorithm could extract them from the token.
  • the merchant-facing application would run such a decoding algorithm.
  • the token need not comprise the payment credentials at all, whether in an encrypted or otherwise modified form.
  • the merchant-facing application could have read-access to a database/correspondence table in which each set of payment credentials is stored in association with one or more corresponding tokens.
  • Such read-access could be direct access or access provided by an application programming interface (API).
  • API application programming interface
  • the merchant-facing application (or the API) could then look up each received token in the table to obtain the corresponding payment credentials and process the transaction request using mem.
  • Such a table could be stored on a server in communication with one or both of the merchant-facing and account holder-facing applications. If an API is used, the server and API could be controlled by the same entity.
  • Such an arrangement could be adapted to incorporate single use tokens if the token stored in the table can be over-written once per transaction request. If the merchant-facing application (or API) has write-access to the table, over-writing or deletion of a token in the table could be performed by the merchant-facing application following matching of a received token to the token in the table. Alternatively or additionally, over-writing could be performed by the account holder-facing application, if it has write-access to the table (or writing if a token has not been generated for an account previously or the previous token has been deleted). This could be done in response to receipt of a request to generate a new token.
  • Deleting/over-writing ensures only one record's worth of memory space is used for each account
  • a list of used tokens could be maintained to which the merchant-facing application refers on receipt of a token. If the received token is found on the list, the transaction is declined.
  • Additional security could be provided by the account holder-facing application encrypting the token before sending it to the merchant-facing application, which men decrypts it.
  • Verification of the account holder's identity could also be completed by means of a log-on process for the account holder-facing application which must be successfully completed in order for a token to be generated.
  • the account holder-facing application could be a digital wallet application e.g. storing details of various debit and/or credit and/or prepaid and/or currency and/or loyalty accounts.
  • the account holder may be required to select an account from a plurality of accounts stored in the digital wallet either before requesting a token or as part of the token request process.
  • Figure 1 illustrates a system 100 in which the methods described herein can be used.
  • An account holder 110 holds an account with issuer bank 120.
  • Issuer 120 is part of a payment association which uses payment network 130.
  • Merchant 140 has an account with acquirer bank 150.
  • Acquirer 150 is also part of the payment association that uses payment network 130.
  • Merchant 140's relationship with acquirer 150 could optionally be through a payment service provider (PSP) 155.
  • PSP payment service provider
  • Account holder 110 communicates with a customer service agent 151 of merchant 140 via postal or telephone network 160 to make transactions which are processed via acquirer 150, payment network 130 and issuer 120.
  • Account holder 110 can communicate with an account holder-racing application 171 through a user interface (UI) of a computing device, such as a smartphone, tablet, laptop or desktop personal computer (PC) 170.
  • UI user interface
  • merchant 140 can communicate with a merchant-facing application 181 through a UI of a computing device 180.
  • a token server 190 may be capable of communicating with one or more of account holder-racing application 171, merchant-facing application 181 and payment network 130. Such communication can for example be via the internet or other wired (e.g. telephone) or wireless (e.g. cellular) network.
  • FIG. 2 illustrates an example tokenised MO/TO transaction procedure 200.
  • account holder 210 initiates the order process, e.g. by telephoning a merchant call centre.
  • merchant customer service agent 241 e.g. a call centre operative
  • requests a token from the account holder e.g. a token from the account holder.
  • the account holder requests a token from account holder-facing application 271 through a UI of a user device on which the account holder-facing application is running (e.g. a touchscreen, keypad, mouse or microphone with voice recognition system of a smartphone, tablet, laptop or desktop PC).
  • a user device on which the account holder-facing application is running e.g. a touchscreen, keypad, mouse or microphone with voice recognition system of a smartphone, tablet, laptop or desktop PC.
  • This step may optionally also comprise the account holder logging into the account holder-facing application to verify their identity.
  • the account holder-facing application obtains a token and provides it to the account holder by means of a user interface of the user device (which may be the same as the input user interface e.g. a touchscreen, or different e.g. a speaker).
  • a user interface of the user device which may be the same as the input user interface e.g. a touchscreen, or different e.g. a speaker.
  • the account holder-facing application could obtain the token.
  • the token could be stored in a memory of the computing device accessible to the account holder-racing application, so that the token can be obtained by retrieving it from that memory.
  • the account holder-facing application could generate the token, e.g. according to a predetermined algorithm.
  • a token server could similarly either retrieve the token from memory or generate it on request, then return the token to the account holder-facing application.
  • the account holder provides the token to the customer service agent, e.g. by reading it over the telephone or typing it using their telephone keypad.
  • the customer service agent passes the token to merchant-facing application 281, e.g. by typing it in as the account holder reads it to mem.
  • the merchant-facing application uses the token to obtain and validate payment credentials, e.g. by searching a look-up table stored on a token server for the token (or having an API do this) and passing payment credentials stored with the token in the table to a payment network as part of a transaction request (again, the API could handle this part).
  • step 207 could proceed as follows.
  • the merchant-facing application could pass the token to the token server for verification.
  • the token server could, in response to verifying the token, deliver payment credentials to the merchant-facing application.
  • the merchant-facing application could men transmit a transaction request comprising the payment credentials and details of the transaction to the PSP in the same manner a merchant normally would in the absence of the merchant-facing application and tokenisation.
  • the PSP could then forward this to the issuer via the acquirer and payment network as normal. If the issuer approves the transaction then the approval is passed back to the merchant-facing application via the payment network, acquirer and PSP.
  • the merchant-facing application reports completion of the transaction to the customer service agent, e.g. through an on-screen message, and at 209 the customer service agent confirms this to the account holder.
  • a receipt for the transaction is to be issued, this can be done manually by the customer service agent via post or email.
  • the merchant- facing application could automatically initiate transmission of a receipt. This could be done via email if the account holder's email address has been obtained, or if the merchant-facing and account holder-facing applications can communicate (e.g. via a token server), the merchant-facing application could pass receipt data to the account holder-facing application, which could then present an electronic receipt to the account holder.
  • Figure 3A illustrates a method 310 of processing a MO/TO transaction performed by a MO/TO merchant-facing application.
  • the merchant-facing application receives a MO/TO transaction request, comprising a token, from a merchant. Responsive thereto, at 312, the merchant-facing application initiates obtaining payment credentials using said token.
  • Figure 3B illustrates a method 320 of securing a MO/TO transaction performed by a MO/TO account holder-facing application.
  • the account holder-facing application receives a MO/TO token request from an account holder.
  • the account holder-facing application obtains a token for use in a MO/TO transaction request to be provided to a merchant having access to a merchant-facing application corresponding to said account holder-facing application.
  • Figure 4 illustrates an example computing system 400 which could be used to perform either or both of methods 310 and 320.
  • a processor 410 which could comprise multiple processors, possibly in different locations, in communication with one another, is connected to a memory 420, which could comprise multiple memories, possibly in different locations, in communication with one another.
  • Memory 420 stores computer-executable instructions which, when executed by processor 410, cause it to perform one or both of methods 310 and 320.
  • the methods described herein may be encoded as executable instructions embodied in a generator readable medium, including, without limitation, non-transitory generator-readable storage, a storage device, and/or a memory device. Such instructions, when executed by a processor (or one or more generators, processors, and/or other devices) cause the processor (the one or more generators, processors, and/or other devices) to perform at least a portion of the methods described herein.
  • a non-transitory generator-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, compact discs (CDs), digital versatile discs (DVDs), or other media that are capable of storing code and/or data.
  • the methods and processes can also be partially or fully embodied in hardware modules or apparatuses or firmware, so that when the hardware modules or apparatuses are activated, they perform the associated methods and processes.
  • the methods and processes can be embodied using a combination of code, data, and hardware modules or apparatuses.
  • processing systems, environments, and/or configurations that may be suitable for use with the embodiments described herein include, but are not limited to, embedded generator devices, personal generators, server generators (specific or cloud (virtual) servers), hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minigenerators, mainframe generators, distributed generating environments that include any of the above systems or devices, and the like.
  • Hardware modules or apparatuses described in mis disclosure include, but are not limited to, application-specific integrated circuits (ASICs), field- programmable gate arrays (FPGAs), dedicated or shared processors, and/or other hardware modules or apparatuses.
  • ASICs application-specific integrated circuits
  • FPGAs field- programmable gate arrays
  • dedicated or shared processors and/or other hardware modules or apparatuses.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Selon un aspect, la présente invention concerne un procédé de sécurisation d'une transaction de vente par correspondance/vente téléphonique (MO/TO). Ledit procédé est réalisé par une application, destinée à un titulaire de compte MO/TO, s'exécutant sur un processeur d'un dispositif informatique du titulaire de compte et comprend : la réception d'une demande de jeton MO/TO depuis un titulaire de compte ; et en réponse à la demande, l'acquisition de données correspondant à un jeton à utiliser dans une demande de transaction MO/TO à fournir à un marchand ayant accès à une application, destinée au marchand, correspondant à ladite application destinée au titulaire de compte. Selon un autre aspect, la présente invention concerne un procédé de traitement d'une transaction MO/TO, ledit procédé étant réalisé par une application, destinée au marchand MO/TO, s'exécutant sur un processeur d'un dispositif informatique du marchand et comprenant : la réception d'une demande de transaction MO/TO, comprenant des données correspondant à un jeton, en provenance d'un marchand ; et en réponse à la demande, lancer l'acquisition de justificatifs de paiement à l'aide dudit jeton. Selon d'autres aspects, la présente invention concerne en outre des supports lisibles par ordinateur stockant des instructions, exécutables par ordinateur, qui, lorsqu'elles sont réalisées par un processeur, amènent ledit processeur à réaliser le procédé de l'un ou l'autre des aspects précédents.
PCT/US2016/046721 2015-08-28 2016-08-12 Sécurisation de traitement de vente par correspondance/vente téléphonique WO2017039999A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP15130593 2015-08-28
EP1513059.3 2015-08-28

Publications (1)

Publication Number Publication Date
WO2017039999A1 true WO2017039999A1 (fr) 2017-03-09

Family

ID=58187908

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/046721 WO2017039999A1 (fr) 2015-08-28 2016-08-12 Sécurisation de traitement de vente par correspondance/vente téléphonique

Country Status (1)

Country Link
WO (1) WO2017039999A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008025037A2 (fr) * 2006-08-25 2008-02-28 Amazon Technologies, Inc. Utilisation de jetons de phrases dans des transactions
WO2015001468A1 (fr) * 2013-07-02 2015-01-08 Visa International Service Association Carte de paiement comprenant une interface utilisateur destinée à être utilisée avec un terminal d'acceptation de carte de paiement
US20150170148A1 (en) * 2013-12-16 2015-06-18 Seth Priebatsch Real-time transaction validity verification using behavioral and transactional metadata

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008025037A2 (fr) * 2006-08-25 2008-02-28 Amazon Technologies, Inc. Utilisation de jetons de phrases dans des transactions
WO2015001468A1 (fr) * 2013-07-02 2015-01-08 Visa International Service Association Carte de paiement comprenant une interface utilisateur destinée à être utilisée avec un terminal d'acceptation de carte de paiement
US20150170148A1 (en) * 2013-12-16 2015-06-18 Seth Priebatsch Real-time transaction validity verification using behavioral and transactional metadata

Similar Documents

Publication Publication Date Title
US11978051B2 (en) Authenticating remote transactions using a mobile device
US11429959B2 (en) Multi-approval system using M of N keys to generate a transaction address
US11876911B2 (en) Blockchain based alias interaction processing
CN113344570B (zh) 传输和处理交易消息的方法及数据处理装置
CN104603809B (zh) 在移动设备上使用虚拟卡促进交易的系统和方法
US11238445B2 (en) Primary account number (PAN) length issuer identifier in payment account number data field of a transaction authorization request message
US20160217461A1 (en) Transaction utilizing anonymized user data
US20160224977A1 (en) Token check offline
US20160027017A1 (en) Method and system for using dynamic cvv in qr code payments
US12284285B2 (en) Efficient token provisioning system and method
US12003500B2 (en) Token processing system and method
US20210192521A1 (en) Systems and methods for distributed identity verification during a transaction
US11935023B2 (en) Extended-length payment account issuer identification numbers
US11716200B2 (en) Techniques for performing secure operations
WO2021155150A1 (fr) Amélioration de l'authentification sécurisée 3d d'utilisateur pour des transactions en ligne
US11823140B2 (en) Server and method for sending a transaction receipt via a push notification
US20170061431A1 (en) Systems and Methods of Securing MO/TO Processing
WO2017039999A1 (fr) Sécurisation de traitement de vente par correspondance/vente téléphonique
US20240348444A1 (en) Secure interaction using uni-directional data correlation tokens
WO2015118388A1 (fr) Système et procédé pour une transaction de paiement électronique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16842548

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16842548

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载