US20220005047A1 - Proof-of-age verification in mobile payments - Google Patents
Proof-of-age verification in mobile payments Download PDFInfo
- Publication number
- US20220005047A1 US20220005047A1 US17/363,468 US202117363468A US2022005047A1 US 20220005047 A1 US20220005047 A1 US 20220005047A1 US 202117363468 A US202117363468 A US 202117363468A US 2022005047 A1 US2022005047 A1 US 2022005047A1
- Authority
- US
- United States
- Prior art keywords
- age
- request
- mobile device
- data
- application
- 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.)
- Granted
Links
- 238000012795 verification Methods 0.000 title claims abstract description 84
- 230000004044 response Effects 0.000 claims abstract description 48
- 238000013475 authorization Methods 0.000 claims abstract description 38
- 238000000034 method Methods 0.000 claims abstract description 28
- 230000000977 initiatory effect Effects 0.000 claims abstract description 9
- 238000004891 communication Methods 0.000 claims description 13
- 230000008569 process Effects 0.000 claims description 12
- 238000012545 processing Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000013507 mapping Methods 0.000 description 6
- 238000012790 confirmation Methods 0.000 description 5
- 230000007423 decrease Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- LFQSCWFLJHTTHZ-UHFFFAOYSA-N Ethanol Chemical compound CCO LFQSCWFLJHTTHZ-UHFFFAOYSA-N 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 230000001815 facial effect Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 241000208125 Nicotiana Species 0.000 description 1
- 235000002637 Nicotiana tabacum Nutrition 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000003542 behavioural effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 230000002207 retinal effect Effects 0.000 description 1
- 235000019505 tobacco product Nutrition 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000010200 validation analysis 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0607—Regulated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- 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/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- 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/20—Point-of-sale [POS] network systems
- G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3223—Realising banking transactions through M-devices
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/326—Payment applications installed on the mobile devices
-
- 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
-
- 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
-
- 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
-
- 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/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- 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
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/0009—Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
- G07G1/00—Cash registers
- G07G1/12—Cash registers electronically operated
- G07G1/14—Systems including one or more distant stations co-operating with a central processing unit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
Definitions
- the present disclosure relates to proof-of-age verification in mobile payments conducted at point-of-sale terminals.
- the consumer will present a government issued identity document such as a driver's license, national identity card, or passport, to verify their age at the point of sale.
- a government issued identity document such as a driver's license, national identity card, or passport
- the merchant typically does not have any capability to confirm the authenticity of the identity document, particularly in the case of driver's licenses, fraudulent instances of which can readily be obtained via channels such as the dark web.
- the present disclosure relates to an age verification method performed at a mobile device.
- a request for a payment credential is received from a point-of-sale terminal.
- the request includes a data element indicative of age requirement data.
- An identity of a user of the mobile device is verified using at least one sensor.
- Responsive to said verifying an age verification request to a digital identity application is initiated by a digital wallet application executing on the mobile device.
- the age verification request includes the age requirement data.
- a response message is generated.
- the response message includes a response from the digital identity application to the age verification request.
- the response message and the payment credential for initiation of a transaction authorization request is transmitted to the point-of-sale terminal.
- the age requirement data includes a minimum age for purchase of a product.
- the age requirement data may include a maximum age of updating of age credentials stored by the digital identity application.
- the response from the digital identity application includes an indication as to whether the age requirement is met.
- the response from the digital identity application comprises a date of birth of the user.
- the request for the payment credential may be an EMV GENERATE AC command, for example.
- the mobile device transmits, to the point-of-sale terminal, a Card Risk Management Data Object List (CDOL).
- CDOL Card Risk Management Data Object List
- one of the objects in the CDOL specifies a format for the age requirement data.
- the present disclosure also relates to a mobile device configured to perform an age verification process.
- a near field communication (NFC) interface receives, from a point-of-sale terminal, a request for a payment credential.
- the request includes a data element indicative of age requirement data.
- At least one sensor captures biometric data from a user.
- a biometric authentication module verifies an identity of the user using the biometric data.
- a digital wallet application initiates an age verification request to a digital identity application in response to the verification.
- the age verification request includes the age requirement data.
- a response message is generated that includes a response from the digital identity application to the age verification request.
- the response message and the payment credential for initiation of a transaction authorization request are transmitted to the point-of-sale terminal.
- the present disclosure further relates to a mobile device comprising at least one processor in communication with computer-readable storage, the computer-readable storage having instructions stored thereon for causing the at least one processor to perform a method as disclosed herein.
- the present disclosure further relates to a computer-readable storage medium having stored thereon machine-readable instructions for causing at least one processor to perform a method as disclosed herein.
- FIG. 1 is an architecture diagram of an example system for proof-of-age verification
- FIG. 2 is a swim lane diagram of an example process for proof-of-age verification.
- FIG. 3 is an architecture diagram of an example mobile device configured to perform steps of a proof-of-age verification process.
- Embodiments of the present invention generally relate to methods and systems for automated age verification during transactions carried out at point-of-sale terminals.
- FIG. 1 is a block diagram illustrating a system 100 in which teachings of the present disclosure may be applied.
- An individual user and/or cardholder or consumer is indicated by reference numeral 102 in FIG. 1 .
- Many of the users 102 habitually carry with them mobile devices 104 , such as smartphones, tablet computers, or the like, which are configured for entering mobile payment transactions.
- the consumer's mobile device 104 (such as an iPhoneTM or AndroidTM device) typically includes components such as a microphone, speaker, touchscreen, digital camera and/or a biometric sensor (such as a fingerprint scanner, not shown).
- the mobile device 104 includes a mobile/digital wallet application 330 ( FIG. 3 ) which may include a software development kit (SDK) 331 .
- SDK 331 is used to facilitate communications between the digital wallet and the wallet service provider 112 and/or issuer FI 114 and/or token service provider 130 , as well as for performing payment card, transaction, fraud and digital wallet management functions, and the like.
- the consumer's mobile device 104 includes software instructions (such as implemented in the digital wallet application 330 ) configured to obtain digital identity information for use in age verification during purchase transactions.
- the mobile digital wallet application 330 may be configured to receive from a merchant terminal 124 , a request for age verification, and to initiate a request for age verification to another application such as a digital identity application 332 (also referred to herein as an electronic identity (E-ID) application) executing on the mobile device 104 , or to an external digital identity service (not shown) that implements a digital identity application.
- E-ID electronic identity
- the received digital identity information may then be incorporated into transaction data that is sent to the merchant terminal 124 .
- the merchant terminal 124 then forms a transaction request that is sent to an acquirer system 134 for forwarding to a payment network 132 for further transaction processing with relation to payment for goods and/or services, which will be further explained below.
- the mobile device 104 is configured for communications with a wallet server/computer 112 (which may be owned and/or operated by an issuer FI, or an entity such as a Wallet Service Provider (WSP), or a payment processing entity such as Mastercard International Incorporated).
- a wallet server/computer 112 which may be owned and/or operated by an issuer FI, or an entity such as a Wallet Service Provider (WSP), or a payment processing entity such as Mastercard International Incorporated.
- WSP Wallet Service Provider
- the communications between the user's mobile device 104 and the wallet server 112 may occur through use of a private network or a public network and/or combinations thereof, for example, by using the Internet (not shown in FIG. 1 ).
- the wallet server 112 is in turn configured for communications with an issuer system 114 (which may be associated with, for example, a bank which issues payment card accounts to consumers or users).
- the wallet server 112 may transmit mobile device provisioning requests for tokenization and/or digitization, user and/or mobile device authentication requests, wallet and/or card management requests, and/or notification data to the issuer system 114 and may receive responses to such requests and/or data.
- the issuer system 114 may provide additional data and or information such as wallet life cycle data, card management data, and/or user data updates to the wallet server 112 .
- the issuer system 114 may also be configured for providing card management services, authentication and/or access to a customer service representative for customer support regarding the wallet. It should be understood that, in practical digital identity systems 100 a plurality of issuer systems 114 may be included.
- the age verification system architecture 100 includes a token service system 130 , which functions as a trusted service provider (TSP) and may include a token vault (not shown).
- the token service system 130 is operable to provide a plurality of on-behalf-of (OBO) services, including digitization and tokenization services to requestors, which replaces payment card account numbers with tokens and places these into digital web wallet or mobile wallet environments.
- token requestors may include payment card account issuers (which include issuer financial institutions, such as banks), card-on-file merchants, acquirer financial institutions, original equipment manufacturer (OEM) device manufacturers and digital wallet providers.
- each such token requestor is required to register with the token service system 130 before requesting use of the token service, which includes mapping tokens to card numbers during a purchase transaction in a secure manner (typically by using cryptograms).
- the token service system 130 enables connected devices to make purchases in-store, in-app and/or online (via the Internet).
- the token service system 130 may perform such functions as operating and maintaining the token vault (which stores token data, including token requester credentials and/or payment account data associated with the tokens), generating, and issuing or provisioning tokens, assuring security and proper controls, and registering token requestors.
- the token service system 130 may be configured to generate and provide an EMV-like version of the user's payment card account number.
- EMV Europay, Mastercard, Visa
- the terminal 124 may transmit merchant information (e.g., merchant name, merchant ID, transaction ID, nonce), as well as transaction information (for example, the transaction amount, currency and a transaction timestamp), and a cryptogram generated either by the device or by the cloud (retrieved from the wallet server) would be utilized in the purchase transaction.
- the token service system 130 would perform cryptogram validation and de-tokenization before the purchase transaction is authorized by the issuer 114 . Once the issuer 114 authorizes the transaction, a response is transmitted back to the payment network 132 , which then sends the response to token service system 130 for token mapping. The token service system 130 completes token mapping and sends the authorization response and/or financial transaction in tokenized form to the payment network 132 . The payment network 132 then forwards the response back to the acquirer system 134 , which then sends it to the POS terminal 124 to complete the transaction.
- the token service system 130 is operably connected to the wallet server 112 , the issuer system 114 , and to a payment network 132 .
- the payment network 132 which may be the well-known Banknet® system operated by Mastercard International Incorporated, is operably connected to the acquirer system 134 and to the issuer system 114 .
- the acquirer system 134 is associated with the financial institution (the merchant FI) that provides banking services to the merchant, and functions to receive and to route payment transaction authorization requests that originate from the merchant terminal 124 .
- issuer FI computers typically represent banks or other financial institutions that provide banking services to users or consumers in addition to issuing payment accounts (for example, credit card accounts and/or debit card accounts) to the cardholders or users 102 .
- Such a practical system will also include a plurality of consumers and their associated mobile devices, as well as a plurality of merchants and their associated merchant mobile devices, POS terminals, merchant servers, and merchant acquirer FIs.
- the token service system 130 provides tokenization and/or digitization services and/or token updates to the wallet server 112 , may also provide identification and verification services, customer services and notifications to the issuer system 114 , and may also provide tokenization, transaction history and notification services to the payment network 132 .
- Communication between the mobile device 104 and the terminal 124 may take place substantially in accordance with the EMV Contactless Specification. However, unlike a standard EMV contactless transaction, one or more additional data objects may be exchanged between the mobile device 104 and the terminal 124 .
- the CDOL card data object list
- the CDOL may include age verification data comprising an age verification data object.
- the terminal 124 may initiate an EMV transaction, and (among other standard contactless EMV transaction steps) send a GENERATE AC command to the mobile device 104 .
- Mobile device 104 (for example, via digital wallet application 330 ) then generates, as part of card action analysis, a CDOL that comprises the age verification data object as well as a plurality of other data objects that are requested from a terminal in a standard EMV transaction, such as transaction-specific information including transaction amount, a transaction identifier, and a timestamp.
- the presence of the age verification data object prompts the digital wallet application 330 to initiate the age verification request as discussed above.
- An example method 200 of age verification performed between a mobile device 104 and a terminal 124 will now be described with reference to FIG. 2 .
- a transaction amount is entered at the terminal 124 .
- This may be done directly using a keypad of the terminal 124 , or via a point of sale (POS) system (not shown) with which the terminal is operatively coupled.
- POS point of sale
- a number of items for purchase may be entered at the POS system (e.g., by way of a barcode scanner, or manually by the merchant) and a total amount transmitted to the terminal 124 as the transaction amount.
- At least one age verification criterion is entered at the terminal 124 .
- this can be performed manually at terminal 124 .
- the terminal 124 may be configured to prompt the merchant to enter, using a keypad thereof, the age verification criterion. In some embodiments, this may simply be a yes/no indication as to whether age verification is required (for example, because the user or cardholder is seeking to purchase alcohol or tobacco products).
- the age verification criterion may be a minimum age to be enabled to purchase the product (for example, 18 years old).
- both a minimum age of the cardholder, and a time limit within which the cardholder's age was last authenticated by the cardholder's issuer may be entered as age verification criteria.
- the merchant may enter “18” for the minimum age and “3” (indicating months) for the time limit when prompted by terminal 124 .
- any or all of these criteria may be transmitted to the terminal 124 by the POS system, as for the transaction amount.
- the POS system may automatically detect, based on the items scanned or otherwise entered into the system for purchase, whether any of those items has an age restriction associated with it, and automatically send age verification criteria to the terminal 124 with the transaction amount.
- the merchant (manually, or via the POS system) may specify a transaction amount of zero. In these embodiments, no payment transaction occurs; rather, the payments system infrastructure (acquirer 134 , payment network 132 , and issuer 114 , together with any other devices with which they communicate during ordinary processing of payment transactions) is used for age verification alone. In this way, the merchant can verify the cardholder's age before any age-restricted items are scanned, for example.
- the terminal 124 is in polling mode, i.e., in a state of readiness to receive card data, for example via NFC communication with a payment-enabled contactless device such as mobile device 104 .
- the cardholder or user 102 readies mobile device 104 for a contactless transaction by activating digital wallet application 330 .
- digital wallet application 330 may be configured to require on-device cardholder verification, e.g., the entry of a mobile PIN (mPIN) or biometric data (e.g., a fingerprint, retinal scan, or facial scan), to unlock payment credentials stored in connection with digital wallet application 330 for use.
- mPIN mobile PIN
- biometric data e.g., a fingerprint, retinal scan, or facial scan
- mobile device 104 and terminal 124 exchange a number of application protocol units (APDUs), in accordance with the EMV Contactless Specification and with ISO/IEC 7816-4.
- APDUs application protocol units
- the majority of these APDUs are conventional in nature.
- the terminal 124 sends, at step 208 , a request to mobile device 104 for card data, with age verification data comprising the age verification criterion or criteria included in the request.
- the request may be a GENERATE AC command APDU based on a CDOL that includes the age verification data object encoding the age verification criterion/criteria.
- mobile device 104 receives the request including the age verification data, and this is processed by digital wallet application 330 .
- Digital wallet application 330 on detection of the age verification data in the request data, initiates an age verification request to digital identity application 332 .
- the CDOL may include optional/proprietary fields which can include the data in a byte to indicate age verification.
- the byte structure may be of the form 00 00 0000 where the first two bits indicate whether only age verification is requested, or actual date of birth is requested; the next two bits indicate the assurance level required for age (for example, how many Identity Verification Providers, such as identity document issuers, have validated the user's age on the digital identity application); and the last four bits indicate the freshness of data (i.e., how long ago the last age verification was performed by the digital identity application).
- digital identity application 332 may require the user 102 to perform an additional verification step (e.g., by entry of an mPIN or biometric data) to grant access to the user 102 's identification data stored on the mobile device 104 .
- an additional verification step e.g., by entry of an mPIN or biometric data
- digital identity application 332 continues to process the age verification request from the digital wallet application 330 by retrieving identification data for user 102 .
- Retrieval of the identification data may be implemented in many different ways, depending on the specific digital identity application 332 .
- the identification data may be stored on a secure element (SE) 322 ( FIG. 3 ) of the mobile device 104 , or in a secure area of a memory 304 of mobile device 104 that is only accessible by the digital identity application 332 .
- the identification data may be securely stored on a remote server with which digital identity application 332 communicates.
- the identification data may include a current age or a date of birth of user 102 , for example.
- digital identity application 332 may simply return to digital wallet application 330 , an indication that the identification data satisfy each of the age verification criteria in the age verification request. For example, if the retrieved value of the current age of the user 102 is equal to or greater than an age threshold in the request, a binary flag may be set to a value of 1 in the response sent to the digital wallet application 330 .
- a retrieved value of a “freshness” indicator such as a timestamp of the last update to the identification data on the mobile device 104
- a threshold specified in one of the age verification criteria e.g., last update within 3 months of the age verification request
- a binary flag for that criterion may be set to a value of 1 in the response sent to the digital wallet application 330 .
- the digital identity application 332 can provide the requested age verification without sending any personally identifiable information (PII) to the digital wallet application 330 , such that no PII is transmitted to terminal 124 and thus not shared with the merchant.
- PII personally identifiable information
- digital identity application 332 may return the retrieved identification data to the digital wallet application 330 , for inclusion in a transaction authorization request message that will be processed by issuer system 114 (or by an issuer processor acting on behalf of issuer system 114 ). Issuer system 114 may then compare the identification data in the transaction authorization request message to the corresponding identification data in its records and use the result of the comparison as part of its authorization decision, as will be discussed further below.
- digital wallet application 330 generates an application cryptogram in accordance with standard EMV protocols. This may be done on the device itself, or may, for example, be done at wallet server 112 on request by the digital wallet application 330 .
- mobile device 104 via digital wallet application 330 , transmits a response message to terminal 124 that includes the cryptogram and transaction data.
- the transaction data may include transaction amount, transaction time, a device PAN (DPAN) of a payment card digitized in the digital wallet application 330 (i.e., a tokenized version of the real PAN of the payment card), and age verification results (such as values of binary flags as mentioned above) or identification data received from digital identity application 332 .
- DPAN device PAN
- age verification results such as values of binary flags as mentioned above
- terminal 124 sends the response message to the payment network 132 for processing. This is done via acquirer system 134 which generates a tokenized purchase transaction authentication request and transmits it to the payment network 132 .
- the request is tokenized in that payment card data, such as the PAN, is not transmitted as part of the request; only proxy values, such as then DPAN in place of the real PAN, are transmitted.
- the transaction authentication request may be formatted as an ISO 8583 or ISO 20022 transaction message, for example.
- the age verification results and/or identification data may be encoded in a reserved data element of the ISO message, for example DE 48 or DE 55 of an ISO 8583 message. For example, a positive indication that the user 102 meets the age requirement specified by terminal 124 (a binary ‘1’ or other value indicating success) may be encoded in the reserved data element, without transmitting any personal information of the user 102 .
- the payment network 132 transmits the tokenized purchase transaction authentication request to the token service system 130 , which validates the application cryptogram for the purchase transaction.
- the token service system 130 next transmits a push notification directly to a Remote Notification Service (RNS)/Transaction Detail Service (TDS).
- RNS/TDS then transmits the push notification to the consumer's mobile device 104 (which has an active mobile wallet application and has Internet and/or wireless connectivity), which includes a request for consent from the consumer to the purchase transaction.
- the confirmation message is received by the consumer's mobile device 104 and displayed on a display component for the user to consider, which consent must be provided within a certain amount of time or else the transaction authorization process will terminate.
- the consumer's mobile device would require wireless connectivity (for example, Internet and/or Bluetooth connectivity, or the like).
- the transaction confirmation message may include details of the transaction, such as the time of purchase, the merchant's name, location data, name/display of item(s) being purchased, the transaction amount and currency, the payment method used, and a card image.
- the consumer may also be prompted to also enter a CVM on the mobile device (DLA) or mobile wallet application (mobile/wallet PIN, biometrics, etc.), which may occur for example, when velocity checks were not passed, and/or when a CVM was not entered by the consumer via the mobile wallet application prior to performing a tap at step 204 , and/or when the transaction is a high value transaction, and/or the number of transactions without CVM entry exceeded a certain limit.
- DLA mobile device
- mobile wallet application mobile/wallet PIN, biometrics, etc.
- the transaction confirmation message may also provide the consumer with the option to cancel the transaction (for example, a “Cancel” radio button may be provided which the consumer may select to end the process, or a “Back” button may be provided for the consumer to re-start or end the process).
- the push notification may be transmitted by the token service system 130 via the payment network 132 to an RNS, and then to the consumer's mobile device 104 .
- the token service system 130 When the user confirms the transaction (for example, by pressing a “Confirm” radio button appearing on the display screen, and/or by entering CVM), then a confirmation message is transmitted to the token service system 130 along with the CVM data, and the token service system 130 validates the application cryptogram that may contain CVM data, and performs token mapping. Next the token service system 130 transmits the de-tokenized, verified purchase authentication request to the payment network 132 , which then transmits the de-tokenized, verified purchase transaction authorization request to the issuer system 114 for purchase transaction authorization processing (financial approval).
- the issuer system 114 processes the purchase transaction authorization request and applies authorization logic to determine whether or not to authorise the transaction.
- the authorization logic may include standard checks such as whether the consumer's payment account is in good standing and has an adequate credit line and may also take into account risk-related factors such as transaction velocity, transaction size, and the like.
- the authorization logic also includes an age verification check.
- the age verification check may comprise determining if the transaction authorization request originates from a digital wallet application, if so, whether a digital identity application 332 executing on the same mobile device has already conducted age verification, and what the results of that age verification were.
- the age verification check may comprise determining whether a field of the transaction authorization message, such as DE 48 or DE 55, contains a date of birth or age that can be checked against that which is on record at issuer system 114 for the consumer's payment account.
- the issuer system 114 transmits a de-tokenized authorization response message, indicating approval, to the payment network 132 .
- the payment network 132 receives it, and then transmits the de-tokenized authorization response message to the token service system 130 , which performs token mapping, and then transmits the tokenized authorization response to the payment network 132 .
- the payment network then transmits the tokenized authorization response to the acquirer system 134 , which in turn transmits the tokenized authorization response to the merchant terminal 124 at step 222 of FIG. 2 .
- an authorization message is displayed at step 224 for the benefit of a store clerk or cashier (and the consumer) and the process ends.
- the payment network 132 also transmits the transaction result to an RNS/TDS.
- the RNS/TDS then generates and transmits (step 226 ) a transaction result message to the consumer's mobile device 104 , where it is displayed (step 228 ) for the consumer.
- the consumer receives an acknowledgement/confirmation message via the digital wallet application 330 , which may be transmitted from an issuer RNS, wallet service provider RNS, third party RNS, or TDS (which is an RNS managed by the token service system 130 ) after the transaction has been authorized (or declined), and assuming that internet and/or wireless connectivity exists.
- the issuer system 114 transmits a de-tokenized authorization response message, indicating that the request has been declined, together with a decline code, to the payment network 132 .
- the payment network 132 transmits the de-tokenized authorization response message to the token service system 130 , which performs token mapping, and then transmits the tokenized authorization response to the payment network 132 .
- the payment network then transmits the tokenized authorization response to the acquirer system 134 , which in turn transmits the tokenized authorization response to the merchant terminal 124 at step 222 of FIG. 2 .
- the decline code is displayed on terminal 124 (at step 224 ).
- the terminal 124 may indicate this.
- the payment network 132 may also transmit to an RNS/TDS, a decline message, and a decline code to the mobile device 104 .
- FIG. 3 is a block diagram showing an exemplary architecture of a mobile device 104 suitable for carrying out embodiments of the present disclosure.
- the mobile device 104 may be a mobile computer device such as a smart phone, a tablet, a personal data assistant (PDA), a palm-top computer, and multimedia Internet enabled cellular telephones.
- PDA personal data assistant
- FIG. 3 is a block diagram showing an exemplary architecture of a mobile device 104 suitable for carrying out embodiments of the present disclosure.
- the mobile device 104 may be a mobile computer device such as a smart phone, a tablet, a personal data assistant (PDA), a palm-top computer, and multimedia Internet enabled cellular telephones.
- PDA personal data assistant
- the mobile device 104 includes the following components in electronic communication via a bus 306 : a display 302 ; non-volatile (non-transitory) memory 304 ; random access memory (“RAM”) 308 ; N processing components 310 ; a transceiver component 312 that includes N transceivers; user controls 314 ; an NFC controller 320 ; a secure element 322 ; one or more biometric sensors 324 ; and at least one camera 325 .
- a bus 306 a display 302 ; non-volatile (non-transitory) memory 304 ; random access memory (“RAM”) 308 ; N processing components 310 ; a transceiver component 312 that includes N transceivers; user controls 314 ; an NFC controller 320 ; a secure element 322 ; one or more biometric sensors 324 ; and at least one camera 325 .
- FIG. 3 is not intended to be a hardware diagram. Thus, many of the components depicted in FIG. 3 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference to FIG. 3 .
- the display 302 generally operates to provide a presentation of content to a user and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector, and OLED displays).
- displays e.g., CRT, LCD, HDMI, micro-projector, and OLED displays.
- non-volatile data storage 304 functions to store (e.g., persistently store) data and executable code.
- the non-volatile memory 304 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation components, known to those of ordinary skill in the art, which are not depicted nor described for simplicity.
- the non-volatile memory 304 may contain a digital wallet application 330 (which itself comprises an SDK 331 as mentioned above), a digital identity (or E-ID) application 332 , a cryptographic module 334 , and a biometric authentication module 336 .
- the cryptographic module 334 may be used by digital wallet application 330 during payment and non-payment transactions, for example conducted at terminals 124 .
- cryptographic module 334 may comprise executable code implementing various cryptographic algorithms for key generation, encryption, and decryption of data, for example for generating nonce values and cryptograms for transaction authorization requests as described above.
- cryptographic module 334 may be stored in, and execute on, the SE 322 , and/or may enable digital wallet application 330 and/or digital identity application 332 to access secure data stored on SE 322 .
- the biometric authentication module 336 is configured to receive biometric data captured from user 102 by one or more sensors of the mobile device 104 , generate a biometric template from the biometric data, and compare the biometric data to a stored biometric template to authenticate the user 102 .
- a “sensor” may be one or more of the biometric sensors 324 , such as a fingerprint sensor, or may be camera 325 , or another component such as a microphone (not shown).
- a “sensor” may also include an input device of the mobile device 104 , such as display 302 (where the display 302 is a touch-screen display).
- the biometric data may comprise fingerprint data, facial scan or iris scan data, voiceprint data, and/or behavioural data inferred from the interaction of user 102 with mobile device 104 (e.g., the manner in which user 102 enters keystrokes or other inputs on a virtual keyboard display on display 302 ). Capture of the biometric data may be initiated by the biometric authentication module 336 itself. For example, another application executing on mobile device 104 , such as a mobile banking application, may invoke the biometric authentication module 336 , which then prompts the user 102 to scan their finger or face, or to speak a passphrase, such that the biometric authentication module 336 can generate the biometric template.
- a mobile banking application may invoke the biometric authentication module 336 , which then prompts the user 102 to scan their finger or face, or to speak a passphrase, such that the biometric authentication module 336 can generate the biometric template.
- the non-volatile memory 304 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from the non-volatile memory 304 , the executable code in the non-volatile memory 304 is typically loaded into RAM 308 and executed by one or more of the N processing components 310 .
- the N processing components 310 in connection with RAM 308 generally operate to execute the instructions stored in non-volatile memory 304 .
- the N processing components 310 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components.
- the transceiver component 312 includes N transceiver chains, which may be used for communicating with external devices via wireless networks.
- Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme.
- each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS network), and other types of communication networks.
- the mobile device 104 can execute mobile applications, such as digital wallet application 330 .
- the digital wallet application 330 may be accessed by a computing device such as mobile device 104 , or a wearable device such as a smartwatch.
- FIG. 3 is merely exemplary and in one or more exemplary embodiments, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be transmitted or stored as one or more instructions or code encoded on a non-transitory computer-readable medium 804 .
- Non-transitory computer-readable medium 804 includes both computer storage medium and communication medium including any medium that facilitates transfer of a computer program from one place to another.
- a storage medium may be any available medium that can be accessed by a computer.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Development Economics (AREA)
- Economics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Marketing (AREA)
- Databases & Information Systems (AREA)
- Medical Informatics (AREA)
- Biomedical Technology (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- This application claims priority to Singapore Patent Application No. 10202006403Y, filed Jul. 2, 2020, entitled “Proof-of-Age Verification in Mobile Payments”, the entirety of which is incorporated herein by reference.
- The present disclosure relates to proof-of-age verification in mobile payments conducted at point-of-sale terminals.
- It is usual for access to certain products, such as alcohol and tobacco, to be restricted according to age. This places the onus on merchants who sell such products to ensure that customers meet the age requirement. Age verification checks are typically done manually by the merchant.
- In most cases, the consumer will present a government issued identity document such as a driver's license, national identity card, or passport, to verify their age at the point of sale. The merchant typically does not have any capability to confirm the authenticity of the identity document, particularly in the case of driver's licenses, fraudulent instances of which can readily be obtained via channels such as the dark web.
- To address the problem of identity theft, online verification systems have been developed. However, these are expensive and generally inaccessible to most merchants.
- It would be desirable to address one or more of the above difficulties, or at least to provide a useful alternative.
- The present disclosure relates to an age verification method performed at a mobile device. A request for a payment credential is received from a point-of-sale terminal. The request includes a data element indicative of age requirement data. An identity of a user of the mobile device is verified using at least one sensor. Responsive to said verifying, an age verification request to a digital identity application is initiated by a digital wallet application executing on the mobile device. The age verification request includes the age requirement data. A response message is generated. The response message includes a response from the digital identity application to the age verification request. The response message and the payment credential for initiation of a transaction authorization request is transmitted to the point-of-sale terminal.
- The age requirement data, in some examples, includes a minimum age for purchase of a product. The age requirement data may include a maximum age of updating of age credentials stored by the digital identity application. In some examples, the response from the digital identity application includes an indication as to whether the age requirement is met. In other examples, the response from the digital identity application comprises a date of birth of the user. The request for the payment credential may be an EMV GENERATE AC command, for example.
- In some examples, the mobile device transmits, to the point-of-sale terminal, a Card Risk Management Data Object List (CDOL). In these examples, one of the objects in the CDOL specifies a format for the age requirement data.
- The present disclosure also relates to a mobile device configured to perform an age verification process. A near field communication (NFC) interface receives, from a point-of-sale terminal, a request for a payment credential. The request includes a data element indicative of age requirement data. At least one sensor captures biometric data from a user. A biometric authentication module verifies an identity of the user using the biometric data. A digital wallet application initiates an age verification request to a digital identity application in response to the verification. The age verification request includes the age requirement data. A response message is generated that includes a response from the digital identity application to the age verification request. The response message and the payment credential for initiation of a transaction authorization request are transmitted to the point-of-sale terminal.
- The present disclosure further relates to a mobile device comprising at least one processor in communication with computer-readable storage, the computer-readable storage having instructions stored thereon for causing the at least one processor to perform a method as disclosed herein.
- The present disclosure further relates to a computer-readable storage medium having stored thereon machine-readable instructions for causing at least one processor to perform a method as disclosed herein.
- Embodiments of the present invention will now be described, by way of non-limiting example, with reference to the drawings in which:
-
FIG. 1 is an architecture diagram of an example system for proof-of-age verification; -
FIG. 2 is a swim lane diagram of an example process for proof-of-age verification; and -
FIG. 3 is an architecture diagram of an example mobile device configured to perform steps of a proof-of-age verification process. - Embodiments of the present invention generally relate to methods and systems for automated age verification during transactions carried out at point-of-sale terminals.
-
FIG. 1 is a block diagram illustrating asystem 100 in which teachings of the present disclosure may be applied. An individual user and/or cardholder or consumer is indicated byreference numeral 102 inFIG. 1 . Many of theusers 102 habitually carry with themmobile devices 104, such as smartphones, tablet computers, or the like, which are configured for entering mobile payment transactions. The consumer's mobile device 104 (such as an iPhone™ or Android™ device) typically includes components such as a microphone, speaker, touchscreen, digital camera and/or a biometric sensor (such as a fingerprint scanner, not shown). Themobile device 104 includes a mobile/digital wallet application 330 (FIG. 3 ) which may include a software development kit (SDK) 331. TheSDK 331 is used to facilitate communications between the digital wallet and thewallet service provider 112 and/or issuer FI 114 and/ortoken service provider 130, as well as for performing payment card, transaction, fraud and digital wallet management functions, and the like. - In some implementations, the consumer's
mobile device 104 includes software instructions (such as implemented in the digital wallet application 330) configured to obtain digital identity information for use in age verification during purchase transactions. For example, the mobiledigital wallet application 330 may be configured to receive from amerchant terminal 124, a request for age verification, and to initiate a request for age verification to another application such as a digital identity application 332 (also referred to herein as an electronic identity (E-ID) application) executing on themobile device 104, or to an external digital identity service (not shown) that implements a digital identity application. The received digital identity information may then be incorporated into transaction data that is sent to themerchant terminal 124. Themerchant terminal 124 then forms a transaction request that is sent to anacquirer system 134 for forwarding to apayment network 132 for further transaction processing with relation to payment for goods and/or services, which will be further explained below. - The
mobile device 104 is configured for communications with a wallet server/computer 112 (which may be owned and/or operated by an issuer FI, or an entity such as a Wallet Service Provider (WSP), or a payment processing entity such as Mastercard International Incorporated). In some implementations, the communications between the user'smobile device 104 and thewallet server 112 may occur through use of a private network or a public network and/or combinations thereof, for example, by using the Internet (not shown inFIG. 1 ). As shown, thewallet server 112 is in turn configured for communications with an issuer system 114 (which may be associated with, for example, a bank which issues payment card accounts to consumers or users). Thewallet server 112 may transmit mobile device provisioning requests for tokenization and/or digitization, user and/or mobile device authentication requests, wallet and/or card management requests, and/or notification data to theissuer system 114 and may receive responses to such requests and/or data. In addition, theissuer system 114 may provide additional data and or information such as wallet life cycle data, card management data, and/or user data updates to thewallet server 112. Theissuer system 114 may also be configured for providing card management services, authentication and/or access to a customer service representative for customer support regarding the wallet. It should be understood that, in practical digital identity systems 100 a plurality ofissuer systems 114 may be included. - The age
verification system architecture 100 includes atoken service system 130, which functions as a trusted service provider (TSP) and may include a token vault (not shown). Thetoken service system 130 is operable to provide a plurality of on-behalf-of (OBO) services, including digitization and tokenization services to requestors, which replaces payment card account numbers with tokens and places these into digital web wallet or mobile wallet environments. In accordance with a Payment Token Interoperability Standard, token requestors may include payment card account issuers (which include issuer financial institutions, such as banks), card-on-file merchants, acquirer financial institutions, original equipment manufacturer (OEM) device manufacturers and digital wallet providers. In some embodiments, each such token requestor is required to register with thetoken service system 130 before requesting use of the token service, which includes mapping tokens to card numbers during a purchase transaction in a secure manner (typically by using cryptograms). Thus, thetoken service system 130 enables connected devices to make purchases in-store, in-app and/or online (via the Internet). In addition, as a provider of tokens, thetoken service system 130 may perform such functions as operating and maintaining the token vault (which stores token data, including token requester credentials and/or payment account data associated with the tokens), generating, and issuing or provisioning tokens, assuring security and proper controls, and registering token requestors. - In addition, in some embodiments, during the tokenization process the
token service system 130 may be configured to generate and provide an EMV-like version of the user's payment card account number. (“EMV” stands for Europay, Mastercard, Visa, and denotes a global standard for chip-based debit card account and credit card account transactions that ensures security and global acceptance of such accounts.) For example, in a contactless transaction conducted atterminal 124, the terminal 124 may transmit merchant information (e.g., merchant name, merchant ID, transaction ID, nonce), as well as transaction information (for example, the transaction amount, currency and a transaction timestamp), and a cryptogram generated either by the device or by the cloud (retrieved from the wallet server) would be utilized in the purchase transaction. Thetoken service system 130 would perform cryptogram validation and de-tokenization before the purchase transaction is authorized by theissuer 114. Once theissuer 114 authorizes the transaction, a response is transmitted back to thepayment network 132, which then sends the response totoken service system 130 for token mapping. Thetoken service system 130 completes token mapping and sends the authorization response and/or financial transaction in tokenized form to thepayment network 132. Thepayment network 132 then forwards the response back to theacquirer system 134, which then sends it to thePOS terminal 124 to complete the transaction. - The
token service system 130 is operably connected to thewallet server 112, theissuer system 114, and to apayment network 132. Thepayment network 132, which may be the well-known Banknet® system operated by Mastercard International Incorporated, is operably connected to theacquirer system 134 and to theissuer system 114. Theacquirer system 134 is associated with the financial institution (the merchant FI) that provides banking services to the merchant, and functions to receive and to route payment transaction authorization requests that originate from themerchant terminal 124. - As mentioned earlier, in a practical age verification system, there will be a plurality of issuer FI computers that typically represent banks or other financial institutions that provide banking services to users or consumers in addition to issuing payment accounts (for example, credit card accounts and/or debit card accounts) to the cardholders or
users 102. Such a practical system will also include a plurality of consumers and their associated mobile devices, as well as a plurality of merchants and their associated merchant mobile devices, POS terminals, merchant servers, and merchant acquirer FIs. - As mentioned above, the
token service system 130 provides tokenization and/or digitization services and/or token updates to thewallet server 112, may also provide identification and verification services, customer services and notifications to theissuer system 114, and may also provide tokenization, transaction history and notification services to thepayment network 132. - Communication between the
mobile device 104 and the terminal 124 may take place substantially in accordance with the EMV Contactless Specification. However, unlike a standard EMV contactless transaction, one or more additional data objects may be exchanged between themobile device 104 and the terminal 124. - For example, in some embodiments, the CDOL (card data object list), that indicates a list of data to be delivered in the context of an EMV transaction, may include age verification data comprising an age verification data object. The terminal 124 may initiate an EMV transaction, and (among other standard contactless EMV transaction steps) send a GENERATE AC command to the
mobile device 104. Mobile device 104 (for example, via digital wallet application 330) then generates, as part of card action analysis, a CDOL that comprises the age verification data object as well as a plurality of other data objects that are requested from a terminal in a standard EMV transaction, such as transaction-specific information including transaction amount, a transaction identifier, and a timestamp. The presence of the age verification data object prompts thedigital wallet application 330 to initiate the age verification request as discussed above. - An
example method 200 of age verification performed between amobile device 104 and a terminal 124 will now be described with reference toFIG. 2 . - In a
first step 202 of themethod 200, a transaction amount is entered at the terminal 124. This may be done directly using a keypad of the terminal 124, or via a point of sale (POS) system (not shown) with which the terminal is operatively coupled. For example, a number of items for purchase may be entered at the POS system (e.g., by way of a barcode scanner, or manually by the merchant) and a total amount transmitted to the terminal 124 as the transaction amount. - Also, as part of
step 202, at least one age verification criterion is entered at the terminal 124. Again, this can be performed manually atterminal 124. For example, the terminal 124 may be configured to prompt the merchant to enter, using a keypad thereof, the age verification criterion. In some embodiments, this may simply be a yes/no indication as to whether age verification is required (for example, because the user or cardholder is seeking to purchase alcohol or tobacco products). In other embodiments, the age verification criterion may be a minimum age to be enabled to purchase the product (for example, 18 years old). In further embodiments, both a minimum age of the cardholder, and a time limit within which the cardholder's age was last authenticated by the cardholder's issuer, may be entered as age verification criteria. For example, the merchant may enter “18” for the minimum age and “3” (indicating months) for the time limit when prompted byterminal 124. Alternatively, any or all of these criteria may be transmitted to the terminal 124 by the POS system, as for the transaction amount. For example, the POS system may automatically detect, based on the items scanned or otherwise entered into the system for purchase, whether any of those items has an age restriction associated with it, and automatically send age verification criteria to the terminal 124 with the transaction amount. - In some embodiments, the merchant (manually, or via the POS system) may specify a transaction amount of zero. In these embodiments, no payment transaction occurs; rather, the payments system infrastructure (
acquirer 134,payment network 132, andissuer 114, together with any other devices with which they communicate during ordinary processing of payment transactions) is used for age verification alone. In this way, the merchant can verify the cardholder's age before any age-restricted items are scanned, for example. - After
step 202, the terminal 124 is in polling mode, i.e., in a state of readiness to receive card data, for example via NFC communication with a payment-enabled contactless device such asmobile device 104. To this end, atstep 204, the cardholder oruser 102 readiesmobile device 104 for a contactless transaction by activatingdigital wallet application 330. Typically,digital wallet application 330 may be configured to require on-device cardholder verification, e.g., the entry of a mobile PIN (mPIN) or biometric data (e.g., a fingerprint, retinal scan, or facial scan), to unlock payment credentials stored in connection withdigital wallet application 330 for use. Once thedigital wallet application 330 is active and cardholder verification is completed, the cardholder oruser 102 bringsmobile device 104 into the vicinity of terminal 124 (referred to herein as a “tap” interaction). - At
step 206,mobile device 104 and terminal 124 exchange a number of application protocol units (APDUs), in accordance with the EMV Contactless Specification and with ISO/IEC 7816-4. The majority of these APDUs are conventional in nature. However, once standard operations such as application selection and requesting of get processing options have been performed, the terminal 124 sends, atstep 208, a request tomobile device 104 for card data, with age verification data comprising the age verification criterion or criteria included in the request. For example, the request may be a GENERATE AC command APDU based on a CDOL that includes the age verification data object encoding the age verification criterion/criteria. - At
step 210,mobile device 104 receives the request including the age verification data, and this is processed bydigital wallet application 330.Digital wallet application 330, on detection of the age verification data in the request data, initiates an age verification request todigital identity application 332. In some examples, the CDOL may include optional/proprietary fields which can include the data in a byte to indicate age verification. For example, the byte structure may be of the form 00 00 0000 where the first two bits indicate whether only age verification is requested, or actual date of birth is requested; the next two bits indicate the assurance level required for age (for example, how many Identity Verification Providers, such as identity document issuers, have validated the user's age on the digital identity application); and the last four bits indicate the freshness of data (i.e., how long ago the last age verification was performed by the digital identity application). - Optionally, at
step 212,digital identity application 332 may require theuser 102 to perform an additional verification step (e.g., by entry of an mPIN or biometric data) to grant access to theuser 102's identification data stored on themobile device 104. - Once verification is successfully performed by
user 102 atstep 214, or if additional user verification is not performed,digital identity application 332 continues to process the age verification request from thedigital wallet application 330 by retrieving identification data foruser 102. Retrieval of the identification data may be implemented in many different ways, depending on the specificdigital identity application 332. For example, the identification data may be stored on a secure element (SE) 322 (FIG. 3 ) of themobile device 104, or in a secure area of amemory 304 ofmobile device 104 that is only accessible by thedigital identity application 332. In other examples, the identification data may be securely stored on a remote server with whichdigital identity application 332 communicates. The identification data may include a current age or a date of birth ofuser 102, for example. - As part of
step 210,digital identity application 332 may simply return todigital wallet application 330, an indication that the identification data satisfy each of the age verification criteria in the age verification request. For example, if the retrieved value of the current age of theuser 102 is equal to or greater than an age threshold in the request, a binary flag may be set to a value of 1 in the response sent to thedigital wallet application 330. In another example, if a retrieved value of a “freshness” indicator, such as a timestamp of the last update to the identification data on themobile device 104, is less than a threshold specified in one of the age verification criteria (e.g., last update within 3 months of the age verification request), a binary flag for that criterion may be set to a value of 1 in the response sent to thedigital wallet application 330. In this way, thedigital identity application 332 can provide the requested age verification without sending any personally identifiable information (PII) to thedigital wallet application 330, such that no PII is transmitted toterminal 124 and thus not shared with the merchant. - In some embodiments, as part of
step 210,digital identity application 332 may return the retrieved identification data to thedigital wallet application 330, for inclusion in a transaction authorization request message that will be processed by issuer system 114 (or by an issuer processor acting on behalf of issuer system 114).Issuer system 114 may then compare the identification data in the transaction authorization request message to the corresponding identification data in its records and use the result of the comparison as part of its authorization decision, as will be discussed further below. - At
step 216,digital wallet application 330 generates an application cryptogram in accordance with standard EMV protocols. This may be done on the device itself, or may, for example, be done atwallet server 112 on request by thedigital wallet application 330. - At
step 218,mobile device 104, viadigital wallet application 330, transmits a response message to terminal 124 that includes the cryptogram and transaction data. The transaction data may include transaction amount, transaction time, a device PAN (DPAN) of a payment card digitized in the digital wallet application 330 (i.e., a tokenized version of the real PAN of the payment card), and age verification results (such as values of binary flags as mentioned above) or identification data received fromdigital identity application 332. - At
step 220, terminal 124 sends the response message to thepayment network 132 for processing. This is done viaacquirer system 134 which generates a tokenized purchase transaction authentication request and transmits it to thepayment network 132. The request is tokenized in that payment card data, such as the PAN, is not transmitted as part of the request; only proxy values, such as then DPAN in place of the real PAN, are transmitted. The transaction authentication request may be formatted as an ISO 8583 or ISO 20022 transaction message, for example. In some embodiments, the age verification results and/or identification data may be encoded in a reserved data element of the ISO message, for example DE 48 or DE 55 of an ISO 8583 message. For example, a positive indication that theuser 102 meets the age requirement specified by terminal 124 (a binary ‘1’ or other value indicating success) may be encoded in the reserved data element, without transmitting any personal information of theuser 102. - Next the
payment network 132 transmits the tokenized purchase transaction authentication request to thetoken service system 130, which validates the application cryptogram for the purchase transaction. In some implementations, thetoken service system 130 next transmits a push notification directly to a Remote Notification Service (RNS)/Transaction Detail Service (TDS). The RNS/TDS then transmits the push notification to the consumer's mobile device 104 (which has an active mobile wallet application and has Internet and/or wireless connectivity), which includes a request for consent from the consumer to the purchase transaction. The confirmation message is received by the consumer'smobile device 104 and displayed on a display component for the user to consider, which consent must be provided within a certain amount of time or else the transaction authorization process will terminate. It should be understood that, in embodiments where the Wallet Service Provider of, for example, an X-Pay wallet is transmitting the push notification, the consumer's mobile device would require wireless connectivity (for example, Internet and/or Bluetooth connectivity, or the like). - The transaction confirmation message may include details of the transaction, such as the time of purchase, the merchant's name, location data, name/display of item(s) being purchased, the transaction amount and currency, the payment method used, and a card image. At this point in the process, the consumer may also be prompted to also enter a CVM on the mobile device (DLA) or mobile wallet application (mobile/wallet PIN, biometrics, etc.), which may occur for example, when velocity checks were not passed, and/or when a CVM was not entered by the consumer via the mobile wallet application prior to performing a tap at
step 204, and/or when the transaction is a high value transaction, and/or the number of transactions without CVM entry exceeded a certain limit. In some implementations, the transaction confirmation message may also provide the consumer with the option to cancel the transaction (for example, a “Cancel” radio button may be provided which the consumer may select to end the process, or a “Back” button may be provided for the consumer to re-start or end the process). In some implementations, the push notification may be transmitted by thetoken service system 130 via thepayment network 132 to an RNS, and then to the consumer'smobile device 104. - When the user confirms the transaction (for example, by pressing a “Confirm” radio button appearing on the display screen, and/or by entering CVM), then a confirmation message is transmitted to the
token service system 130 along with the CVM data, and thetoken service system 130 validates the application cryptogram that may contain CVM data, and performs token mapping. Next thetoken service system 130 transmits the de-tokenized, verified purchase authentication request to thepayment network 132, which then transmits the de-tokenized, verified purchase transaction authorization request to theissuer system 114 for purchase transaction authorization processing (financial approval). - Thus, the
issuer system 114 processes the purchase transaction authorization request and applies authorization logic to determine whether or not to authorise the transaction. The authorization logic may include standard checks such as whether the consumer's payment account is in good standing and has an adequate credit line and may also take into account risk-related factors such as transaction velocity, transaction size, and the like. Importantly, in at least some of the presently disclosed embodiments, the authorization logic also includes an age verification check. The age verification check may comprise determining if the transaction authorization request originates from a digital wallet application, if so, whether adigital identity application 332 executing on the same mobile device has already conducted age verification, and what the results of that age verification were. Alternatively, the age verification check may comprise determining whether a field of the transaction authorization message, such as DE 48 or DE 55, contains a date of birth or age that can be checked against that which is on record atissuer system 114 for the consumer's payment account. - If the authorization logic indicates that all checks are passed and that the transaction authorization request should be approved, the
issuer system 114 transmits a de-tokenized authorization response message, indicating approval, to thepayment network 132. Thepayment network 132 receives it, and then transmits the de-tokenized authorization response message to thetoken service system 130, which performs token mapping, and then transmits the tokenized authorization response to thepayment network 132. The payment network then transmits the tokenized authorization response to theacquirer system 134, which in turn transmits the tokenized authorization response to themerchant terminal 124 atstep 222 ofFIG. 2 . When themerchant terminal 124 receives the tokenized authorization response, in some embodiments an authorization message is displayed atstep 224 for the benefit of a store clerk or cashier (and the consumer) and the process ends. - In some embodiments the
payment network 132 also transmits the transaction result to an RNS/TDS. The RNS/TDS then generates and transmits (step 226) a transaction result message to the consumer'smobile device 104, where it is displayed (step 228) for the consumer. Thus, in some embodiments the consumer receives an acknowledgement/confirmation message via thedigital wallet application 330, which may be transmitted from an issuer RNS, wallet service provider RNS, third party RNS, or TDS (which is an RNS managed by the token service system 130) after the transaction has been authorized (or declined), and assuming that internet and/or wireless connectivity exists. - If the authorization logic applied by
issuer system 114 indicates that the transaction authorization request should not be approved, theissuer system 114 transmits a de-tokenized authorization response message, indicating that the request has been declined, together with a decline code, to thepayment network 132. As before, thepayment network 132 transmits the de-tokenized authorization response message to thetoken service system 130, which performs token mapping, and then transmits the tokenized authorization response to thepayment network 132. The payment network then transmits the tokenized authorization response to theacquirer system 134, which in turn transmits the tokenized authorization response to themerchant terminal 124 atstep 222 ofFIG. 2 . When themerchant terminal 124 receives the tokenized authorization response, the decline code is displayed on terminal 124 (at step 224). For example, if the decline code indicates that the age verification checks were unsuccessful, the terminal 124 may indicate this. In some embodiments, as before, thepayment network 132 may also transmit to an RNS/TDS, a decline message, and a decline code to themobile device 104. -
FIG. 3 is a block diagram showing an exemplary architecture of amobile device 104 suitable for carrying out embodiments of the present disclosure. Themobile device 104 may be a mobile computer device such as a smart phone, a tablet, a personal data assistant (PDA), a palm-top computer, and multimedia Internet enabled cellular telephones. - As shown, the
mobile device 104 includes the following components in electronic communication via a bus 306: adisplay 302; non-volatile (non-transitory)memory 304; random access memory (“RAM”) 308;N processing components 310; atransceiver component 312 that includes N transceivers; user controls 314; anNFC controller 320; asecure element 322; one or morebiometric sensors 324; and at least onecamera 325. - Although the components depicted in
FIG. 3 represent physical components,FIG. 3 is not intended to be a hardware diagram. Thus, many of the components depicted inFIG. 3 may be realized by common constructs or distributed among additional physical components. Moreover, it is certainly contemplated that other existing and yet-to-be developed physical components and architectures may be utilized to implement the functional components described with reference toFIG. 3 . - The
display 302 generally operates to provide a presentation of content to a user and may be realized by any of a variety of displays (e.g., CRT, LCD, HDMI, micro-projector, and OLED displays). - In general, the non-volatile data storage 304 (also referred to as non-volatile memory) functions to store (e.g., persistently store) data and executable code.
- In some embodiments for example, the
non-volatile memory 304 includes bootloader code, modem software, operating system code, file system code, and code to facilitate the implementation components, known to those of ordinary skill in the art, which are not depicted nor described for simplicity. For example, thenon-volatile memory 304 may contain a digital wallet application 330 (which itself comprises anSDK 331 as mentioned above), a digital identity (or E-ID)application 332, acryptographic module 334, and abiometric authentication module 336. - The
cryptographic module 334 may be used bydigital wallet application 330 during payment and non-payment transactions, for example conducted atterminals 124. To this end,cryptographic module 334 may comprise executable code implementing various cryptographic algorithms for key generation, encryption, and decryption of data, for example for generating nonce values and cryptograms for transaction authorization requests as described above. - In some embodiments,
cryptographic module 334 may be stored in, and execute on, theSE 322, and/or may enabledigital wallet application 330 and/ordigital identity application 332 to access secure data stored onSE 322. - The
biometric authentication module 336 is configured to receive biometric data captured fromuser 102 by one or more sensors of themobile device 104, generate a biometric template from the biometric data, and compare the biometric data to a stored biometric template to authenticate theuser 102. To this end, a “sensor” may be one or more of thebiometric sensors 324, such as a fingerprint sensor, or may becamera 325, or another component such as a microphone (not shown). A “sensor” may also include an input device of themobile device 104, such as display 302 (where thedisplay 302 is a touch-screen display). - The biometric data may comprise fingerprint data, facial scan or iris scan data, voiceprint data, and/or behavioural data inferred from the interaction of
user 102 with mobile device 104 (e.g., the manner in whichuser 102 enters keystrokes or other inputs on a virtual keyboard display on display 302). Capture of the biometric data may be initiated by thebiometric authentication module 336 itself. For example, another application executing onmobile device 104, such as a mobile banking application, may invoke thebiometric authentication module 336, which then prompts theuser 102 to scan their finger or face, or to speak a passphrase, such that thebiometric authentication module 336 can generate the biometric template. - In many implementations, the
non-volatile memory 304 is realized by flash memory (e.g., NAND or ONENAND memory), but it is certainly contemplated that other memory types may be utilized as well. Although it may be possible to execute the code from thenon-volatile memory 304, the executable code in thenon-volatile memory 304 is typically loaded intoRAM 308 and executed by one or more of theN processing components 310. - The
N processing components 310 in connection withRAM 308 generally operate to execute the instructions stored innon-volatile memory 304. As one of ordinarily skill in the art will appreciate, theN processing components 310 may include a video processor, modem processor, DSP, graphics processing unit (GPU), and other processing components. - The
transceiver component 312 includes N transceiver chains, which may be used for communicating with external devices via wireless networks. Each of the N transceiver chains may represent a transceiver associated with a particular communication scheme. For example, each transceiver may correspond to protocols that are specific to local area networks, cellular networks (e.g., a CDMA network, a GPRS network, a UMTS network), and other types of communication networks. - The
mobile device 104 can execute mobile applications, such asdigital wallet application 330. Thedigital wallet application 330 may be accessed by a computing device such asmobile device 104, or a wearable device such as a smartwatch. - It should be recognized that
FIG. 3 is merely exemplary and in one or more exemplary embodiments, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be transmitted or stored as one or more instructions or code encoded on a non-transitory computer-readable medium 804. Non-transitory computer-readable medium 804 includes both computer storage medium and communication medium including any medium that facilitates transfer of a computer program from one place to another. A storage medium may be any available medium that can be accessed by a computer. - It will be appreciated that many further modifications and permutations of various aspects of the described embodiments are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.
- Throughout this specification and the claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” and “comprising”, will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.
- The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavor to which this specification relates.
Claims (20)
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SG10202006403Y | 2020-07-02 | ||
SG10202006403Y | 2020-07-02 |
Publications (2)
Publication Number | Publication Date |
---|---|
US20220005047A1 true US20220005047A1 (en) | 2022-01-06 |
US11961079B2 US11961079B2 (en) | 2024-04-16 |
Family
ID=79167041
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/363,468 Active US11961079B2 (en) | 2020-07-02 | 2021-06-30 | Proof-of-age verification in mobile payments |
Country Status (1)
Country | Link |
---|---|
US (1) | US11961079B2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220076251A1 (en) * | 2020-09-08 | 2022-03-10 | Joseph D. Hughes | Payment card enabled distributed digital ledger system to handle security of both crypto and non-crypto transactions |
US20240046272A1 (en) * | 2022-08-08 | 2024-02-08 | Capital One Services, Llc | Systems and methods for bypassing contactless payment transaction limit |
US11924219B1 (en) | 2023-10-11 | 2024-03-05 | KYC AVC UK Ltd. | Age assurance during an interactive query workflow |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180060928A1 (en) * | 2016-08-30 | 2018-03-01 | Ncr Corporation | Pre-verification processing |
US20190258838A1 (en) * | 2013-09-17 | 2019-08-22 | Integrated Solutions International, Inc. | Systems and Methods for Point of Sale Age Verification |
US20200092285A1 (en) * | 2017-03-16 | 2020-03-19 | Age Checked Limited | Secure age verification system |
US20200400441A1 (en) * | 2019-06-20 | 2020-12-24 | Lyft, Inc. | Systems and methods for progressive semantic mapping |
US20210279994A1 (en) * | 2020-03-05 | 2021-09-09 | PayRange Inc. | Controlled dispensing system and method |
US20210357600A1 (en) * | 2013-09-17 | 2021-11-18 | Integrated Solutions International, Llc | Systems and Methods for Point of Sale Age Verification |
US20210390556A1 (en) * | 2020-06-16 | 2021-12-16 | Capital One Services, Llc | Systems and methods for age verification |
US11334931B2 (en) * | 2017-08-08 | 2022-05-17 | Walmart Apollo, Llc | Validating identification of a user for purchase of age-restricted items |
US20220253846A1 (en) * | 2021-02-11 | 2022-08-11 | Ronald Eric Tobb | Age verification system, method and apparatus |
US11443301B1 (en) * | 2016-12-16 | 2022-09-13 | Wells Fargo Bank, N.A. | Sending secure proxy elements with mobile wallets |
US20230322487A1 (en) * | 2020-03-05 | 2023-10-12 | PayRange Inc. | Nfc validation bypass system and method |
Family Cites Families (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040153421A1 (en) * | 2001-09-21 | 2004-08-05 | Timothy Robinson | System and method for biometric authorization of age-restricted transactions conducted at an unattended device |
US8196818B2 (en) * | 2005-07-13 | 2012-06-12 | Mastercard International Incorporated | Apparatus and method for integrated payment and electronic merchandise transfer |
US7512567B2 (en) * | 2006-06-29 | 2009-03-31 | Yt Acquisition Corporation | Method and system for providing biometric authentication at a point-of-sale via a mobile device |
US20080257956A1 (en) * | 2007-04-19 | 2008-10-23 | At&T Knowledge Ventures, L.P. | System for fulfilling purchases |
WO2010127003A1 (en) * | 2009-04-28 | 2010-11-04 | Mastercard International Incorporated | Apparatus, method, and computer program product for encoding enhanced issuer information in a card |
EP2557546A1 (en) * | 2011-08-12 | 2013-02-13 | Oberthur Technologies | Method and secure device for performing a secure transaction with a terminal |
US20150023572A1 (en) * | 2013-07-22 | 2015-01-22 | Rocky Williform | System and methods for providing finger vein authentication and signature for execution of electronic wallet transactions |
US10909539B2 (en) * | 2013-10-29 | 2021-02-02 | Visa International Service Association | Enhancements to transaction processing in a secure environment using a merchant computer |
US10692085B2 (en) * | 2015-02-13 | 2020-06-23 | Yoti Holding Limited | Secure electronic payment |
US10304101B2 (en) * | 2015-02-17 | 2019-05-28 | Mastercard International Incorporated | Age verification through mobile wallet method and apparatus |
US20170255940A1 (en) * | 2016-03-01 | 2017-09-07 | Mastercard International Incorporated | Systems, methods, apparatus, and computer-readable media for age verification |
US20180025348A1 (en) * | 2016-07-23 | 2018-01-25 | Jack Shauh | Method system of online payment using mobile device and contactless emv card |
US10057061B1 (en) * | 2016-09-13 | 2018-08-21 | Wells Fargo Bank, N.A. | Secure digital communications |
EP3340143A1 (en) * | 2016-12-22 | 2018-06-27 | Mastercard International Incorporated | Configuring a transaction device |
-
2021
- 2021-06-30 US US17/363,468 patent/US11961079B2/en active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190258838A1 (en) * | 2013-09-17 | 2019-08-22 | Integrated Solutions International, Inc. | Systems and Methods for Point of Sale Age Verification |
US20210357600A1 (en) * | 2013-09-17 | 2021-11-18 | Integrated Solutions International, Llc | Systems and Methods for Point of Sale Age Verification |
US20180060928A1 (en) * | 2016-08-30 | 2018-03-01 | Ncr Corporation | Pre-verification processing |
US11443301B1 (en) * | 2016-12-16 | 2022-09-13 | Wells Fargo Bank, N.A. | Sending secure proxy elements with mobile wallets |
US20200092285A1 (en) * | 2017-03-16 | 2020-03-19 | Age Checked Limited | Secure age verification system |
US11334931B2 (en) * | 2017-08-08 | 2022-05-17 | Walmart Apollo, Llc | Validating identification of a user for purchase of age-restricted items |
US20200400441A1 (en) * | 2019-06-20 | 2020-12-24 | Lyft, Inc. | Systems and methods for progressive semantic mapping |
US20210279994A1 (en) * | 2020-03-05 | 2021-09-09 | PayRange Inc. | Controlled dispensing system and method |
US20230322487A1 (en) * | 2020-03-05 | 2023-10-12 | PayRange Inc. | Nfc validation bypass system and method |
US20210390556A1 (en) * | 2020-06-16 | 2021-12-16 | Capital One Services, Llc | Systems and methods for age verification |
US20220253846A1 (en) * | 2021-02-11 | 2022-08-11 | Ronald Eric Tobb | Age verification system, method and apparatus |
Non-Patent Citations (1)
Title |
---|
Iqbal, Sarwat, et al. "A novel mobile wallet model for elderly using fingerprint as authentication factor." IEEE Access 8 (2020): 177405-177423. (Year: 2020) * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220076251A1 (en) * | 2020-09-08 | 2022-03-10 | Joseph D. Hughes | Payment card enabled distributed digital ledger system to handle security of both crypto and non-crypto transactions |
US20240046272A1 (en) * | 2022-08-08 | 2024-02-08 | Capital One Services, Llc | Systems and methods for bypassing contactless payment transaction limit |
US11924219B1 (en) | 2023-10-11 | 2024-03-05 | KYC AVC UK Ltd. | Age assurance during an interactive query workflow |
Also Published As
Publication number | Publication date |
---|---|
US11961079B2 (en) | 2024-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2332092B1 (en) | Apparatus and method for preventing unauthorized access to payment application installed in contactless payment device | |
US11961079B2 (en) | Proof-of-age verification in mobile payments | |
CN116233836A (en) | Method and system for relay attack detection | |
US20240078304A1 (en) | Mobile user authentication system and method | |
US20210241266A1 (en) | Enhancing 3d secure user authentication for online transactions | |
US11481766B2 (en) | Method for payment authorization on offline mobile devices with irreversibility assurance | |
US20220291979A1 (en) | Mobile application integration | |
US11449866B2 (en) | Online authentication | |
US11748738B2 (en) | Portable device loading mechanism for account access | |
EP4020360A1 (en) | Secure contactless credential exchange | |
US12003500B2 (en) | Token processing system and method | |
US11711217B2 (en) | Token processing with selective de-tokenization for proximity based access device interactions | |
US11973871B2 (en) | Domain validations using verification values | |
AU2016253607B2 (en) | Apparatus and method for preventing unauthorized access to application installed in a device | |
AU2015202512B2 (en) | Apparatus and method for preventing unauthorized access to application installed in mobile device | |
US20210090061A1 (en) | Systems and methods for device-present electronic commerce transaction checkout | |
CN114600142A (en) | Combined token and value evaluation process |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MASTERCARD ASIA/PACIFIC PTE. LTD., SINGAPORE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MAHESHWARI, RAJAT;FORTIN, FREDERIC;SHARMA, PRASHANT;SIGNING DATES FROM 20200626 TO 20200629;REEL/FRAME:056718/0969 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |