CN115605900A

CN115605900A - Method for ensuring transaction safety of payment card

Info

Publication number: CN115605900A
Application number: CN202180033778.0A
Authority: CN
Inventors: D·A·威廉斯
Original assignee: Dakota Technology Co ltd
Current assignee: Dakota Technology Co ltd
Priority date: 2020-03-10
Filing date: 2021-03-10
Publication date: 2023-01-13
Also published as: BR112022018239A2; EP4118558A4; EP4118558A1; AU2021233841A1; MX2022011100A; CA3170260A1; ZA202211085B; WO2021183688A1

Abstract

The present invention relates to a system for preventing or suppressing payment card fraud. When a payment card transaction is initiated, the card network communicates cardholder identification information to the bank that issued the payment card. The issuing bank generates a random one-time data code (OTDC) upon receiving cardholder identification information. Alternatively, the cardholder may request OTDC by messaging the issuing bank directly or via automated communication between the cardholder's mobile device and the issuing bank. The issuing bank then sends the OTDC to the cardholder, preferably via an encrypted secure transmission. The cardholder provides the OTDC to a merchant. The OTDC is part of the transaction approval criteria of the issuing bank. The transaction should not be approved unless the merchant provides the OTDC to the issuing bank. The OTDC will only apply to the relevant transaction and if it remains unused, it will preferably expire soon after its generation.

Description

Method for ensuring transaction safety of payment card

Priority claim

This application claims the benefit of U.S. provisional patent application No. 62/987,402, filed on 3/10/2020, which is hereby incorporated by reference in its entirety.

Technical Field

The present invention relates generally to secure electronic shopping, and in particular, to secure credit and debit card shopping.

Background

Credit, debit, and prepaid card (collectively "payment card") fraud is a global problem. In 2018, global payment card fraud exceeded 270 billion dollars (USD). Many efforts have been made to deter fraud in this area. One is the EMV or "chip and password" protocol. This is a relatively efficient security system in which a computer chip is embedded in a payment card. When the payment card is placed in the card reader, the system can verify that the payment card is authentic by reading the information on the chip. This makes it much more difficult to create a counterfeit payment card that is available. Unfortunately, the result is that payment card fraud is pushed onto the network. During the years 2015 and 2016, card fraud-where fraudulent cards are physically presented to merchants-has dropped from $ 36 million (USD) to $ 29 million (USD) per year in the united states. Card fraud spikes from $ 34 million (USD) to $ 45.7 million (USD) in the same time period without field. By 2020, card absence fraud is more than 80% more common than card fraud.

One way that payment card companies attempt to combat online and other card fraud not present is to use one-time account numbers. The account number on the payment card typically contains between 13 and 19 digits, and most commonly 15 or 16 digits. The exposure of the account number is a source of payment card fraud. The consumer gives an account number to the sales person via a telephone line or types the account number into a computer system during the shopping. This creates an opportunity for the account number to be revealed either by a person working with the merchant or by a person hacking into the merchant's computer system. To avoid this risk, the consumer may request a one-time payment card number. The payment card company will issue a one-time use 13-digit to 19-digit number that can only be used once. If the number is compromised, this will be irrelevant, since the number cannot be reused. This method is very effective in combating fraud. However, this method is extremely inefficient. Telephone commerce and particularly internet commerce has grown rapidly over the past decade and has seen an outbreak in 2020 in the year of this pandemic. It is impractical for consumers to request a one-time account each time they want to use their payment card for online shopping. The liability policy restrictions that consumers are responsible for only up to $ 50 (USD) in a pirate swipe make consumers less aggressive in obtaining one-time numbers for each transaction. Additionally, the method does not work at all for card-on-field transactions, which typically present a physical payment card with an actual card number. Furthermore, the effort required to obtain a one-time number for each transaction hinders the use of payment cards by consumers. This detracts from the benefits of payment card issuers who want to maximize, rather than block, the use of their cards.

Another method of preventing fraud is transaction monitoring. The card company monitors the shopping behavior of the cardholder. If the purchase made with the card number does not appear to correspond to the cardholder's usual shopping pattern (whether in terms of the location of the card transaction or the amount or nature of the purchase that the card is not in a field transaction), the card company may suspend the transaction, thereby denying permission for the transaction to proceed until the cardholder can be contacted. The card may also be deactivated, thereby shelving validation of transactions conducted by the consumer. The effectiveness of this approach remains questionable, since only extremely thick and unquestionable criminals may trigger the system. In addition, false positives under this approach are highly undesirable from the perspective of the payment card company because they inhibit the use of the card by the consumer.

When fraud is detected, the payment card company will cancel the card number and issue a new payment card with a new account number to the consumer. In addition to the cost of replacement, this also has a negative impact on the payment card issuer because it prevents the consumer from using the payment card when it is replaced. Anything that inhibits cardholders from using their payment cards detracts from the benefits of the payment card issuer. Accordingly, a system and method for preventing payment card fraud is desired.

Objects of the invention

It is an object of the present invention to prevent or inhibit payment card fraud.

It is another object of the present invention to prevent or inhibit card fraud for absent payment cards.

It is yet another object of the present invention to prevent or inhibit card-to-field payment card fraud.

It is yet another object of the present invention to prevent or inhibit payment card fraud without inhibiting the ability of consumers to use their payment cards.

It is yet another object of the present invention to prevent or inhibit payment card fraud without requiring any additional affirmative steps from the consumer during the payment card transaction.

It is yet another object of the present invention to minimize the amount of time a payment card must be deactivated due to suspected fraud or actual fraud.

Disclosure of Invention

A system for preventing or suppressing payment card fraud is disclosed. When a cardholder attempts to use a payment card, the network will communicate cardholder identification information to the bank that issued the payment card. The issuing bank will generate a random one-time data code (OTDC) after receiving cardholder identification information and an indication that the cardholder is attempting to use the card. Alternatively, the cardholder may request the OTDC from the issuing bank by messaging the issuing bank directly or via automated communication between the cardholder's mobile device and the issuing bank. The issuing bank will transmit the OTDC to the cardholder, which transmission may be encrypted and protected. Provision of OTDC is part of the transaction approval criteria of the issuing bank. The cardholder will provide the OTDC to the merchant. If the merchant cannot provide an OTTC that matches the OTTC just generated by the issuing bank, the transaction should not be approved. The OTDC will only apply to the relevant transaction and if it remains unused, it will preferably expire soon after its generation.

Drawings

Fig. 1A is a front view of an exemplary payment card.

Fig. 1B is a rear view of an exemplary payment card.

FIG. 2 is a flow chart illustrating the steps of a preferred embodiment of the fraud prevention system disclosed herein.

Detailed Description

In a standard payment card transaction, when the cardholder 40 presents itself to a merchant (e.g., wal-mart) ^TM Service station, amazon ^TM Or local plumber) presents his or her payment card 20 or card number 30, the transaction is initiated 1. The merchant transmits (at a minimum) 2A the card number 30 (or a code corresponding to the card number 30) and the transaction amount to the merchant bank or its (them) processor (collectively, "merchant bank"), which transmits the card number 30 (or code) to the issuing bank or its (them) processor (collectively, "issuing bank" or "issuing institution bank" 45) via an appropriate card network 80, the card number 30 and card network 80 generally being indicated on the face of the payment card 20. The most common card network is the process MasterCard ^TM Bank net of transactions ^TM And processing Visa ^TM Transacted VisaNet ^TM . The common issuing bank 45 contains Chase ^TM 、CapitalOne ^TM 、Bank of America ^TM And the like. American Express ^TM And Discover ^TM Have their own network; however, in addition to being a network, american Express ^TM And Discover ^TM Or issuing bank 45, to play a dual role in their system. However, conventional banking facilities are not necessary for banks to issue payment cards 20. The issuing bank 45 may be a digital bank. The criteria for becoming the issuing bank 45 will typically be determined by the card network 80.

Historically, cardholder information was included in the magnetic strip 44 on the back of the payment card 20, but most modern payment cards 20 include this information in the EMV chip 90 and/or contactless chip 49 provided as a supplement to the magnetic strip 44. The aforementioned communication typically occurs via a telecommunication system, such as a telephone system or the internet.

The issuing bank 45 determines 4 whether the transaction meets its criteria- "transaction approval criteria" -and issues a code that approves 14A or rejects 14B the transaction, which is transmitted back to the merchant over the card network. At this point, the transaction is authorized (or not authorized).

The transaction approval criteria for the issuing bank may vary significantly. Most issuing banks check to ensure that the transaction will not exceed the credit line or available funds associated with the payment card 20, that the cardholder 40 is in good standing, and that the payment card 20 is not due. For card transactions, the issuing bank 45 may require the cardholder 40 to type a Personal Identification Number (PIN) or provide a signature. When the payment card 20 contains the chip 90, EVC information from the chip 90 will typically be needed. For card absence transactions, many issuing banks 45 require that the cardholder's billing address be provided to the merchant. Many issuing banks 45 also require the merchant to obtain a Card Verification Value (CVV) 46 from the cardholder 40. This is typically a three or four digit number code on the back of many payment cards 20. If the transaction approval information provided by the cardholder 40 does not match or meet the issuer's transaction approval criteria, the transaction should not be authorized. Many issuing banks 45 also impose limits on the number of times a particular card number 30 may be attempted to be used without passing transaction approval criteria, essentially "locking" the card number 30 for a certain period of time if too many failed attempts are made. It may vary somewhat if too many, but 3 to 5, and most preferably 3, failed attempts before locking the card number 30 is a suitable number to avoid brute force breaking.

In a preferred embodiment of the invention, additional security measures are provided. The transaction authorization system of the issuing bank, typically a back-end server, will generate a 3-time data code (OTDC), sometimes referred to as a card off-site transaction number (CNPN), although it can be used in card and card off-site transactions.

In one embodiment, the initiation of the transaction 1 will cause the cardholder's payment card number 30 or other cardholder identification information to be transmitted 2A to the issuing bank 45. ( As discussed above, the merchant transmits the information to the merchant's bank or processor(s), which transmits the information to the issuing bank 45 or its processor via the card network. The communication channels will be understood by those skilled in the art. Thus, these contents are no longer repeated for each communication between the merchant and the issuing bank 45. )

Receipt by the issuing bank 45 of sufficient information to (a) identify the cardholder 40 and (b) indicate that the cardholder 40 is attempting to conduct a transaction using the payment card 20 will trigger the issuing bank 45 to generate a 3OTDC.

In another embodiment, as is addressed in more detail below, the cardholder 40 may initiate the generation of an OTDC by sending a request 2B for an OTDC to the issuing bank 45.

Whether the OTDC is generated automatically by the issuing bank 45 in response to information indicating that a transaction has been initiated 2A or 3 at the request 2B of the cardholder 40, the generation of the OTDC may be done by a random number generator. The random number generator may be a true random number generator, a pseudo-random number generator, or a cryptographically secure pseudo-random number generator. All of which are intended to be encompassed within the phrase "random number generator". Many different computer-based random number generators are known to those skilled in the art and are available.

The OTDC may be as many numbers as desired by the issuing bank 45. Typically, the OTDC will be a three to five digit number. Letters or special characters may be included in the OTDC if they are desired.

As the name implies, a one-time data code is intended to be used once. The issuing bank's computer system may check the 4OTDC to ensure that it has not been utilized by the cardholder 40 or has not been previously used with the cardholder's payment card number 30. If the randomly generated OTDC is not unique, or if it does not meet some other criteria of the issuing bank 45, the failed OTDC will be discarded and a new OTDC will be generated before it is transmitted 6 by the issuing bank 45.

In some embodiments, the list of OTDCs that are not eligible for use with a particular payment card 20 will be reset. In general, the shorter the OTDC, the more likely it will need to be reset to prevent the system from running out of qualified OTDC. Once the set elapsed time has expired-e.g., every thirty days or every ninety days-the list of failed OTDCs may be reset. The list may be reset each time a payment card 20 expires and a new payment card 20 is issued. The list may be reset each time a new card number 30 is issued. The list of failed OTDCs may never be reset. When the length of the OTDC is more than five digits, resetting may not be necessary. Finally, the list of failed OTDCs is a security option, not a requirement. Since the OTDC is randomly generated, the probability that a randomly generated new OTDC matches the previous OTDC will be negligible-roughly 1/1000 for a three-digit OTDC. Knowing one or even several OTDCs previously used with a particular payment card number 30 will not likely enable a third party to make unauthorized purchases using the credit payment number 30, even if the OTDC is reused, because the previously used OTDC is not likely to match the OTDC generated for the transaction concerned. When the issuing bank 45 locks the card number 30 due to too many failed attempts to pass the transaction authorisation criteria, there is a further reduction in the already small risk that the previously used OTDC will be successfully used to fraudulently obtain authorisation for a particular transaction.

Once the OTDC has generated 3 and is found to meet the issuing bank's criteria 4, the issuing bank 45 will transmit 6 the OTDC to the cardholder 40. It will be appreciated that any screening of the generation and selection of OTDC will be performed by the computer system of the issuing bank. The transmission of the OTDC to the cardholder 40 may be via various means. The transmission of the OTDC to the cardholder 40 may be done via email or text, a telephone call, a push notification, or any other communication path. The issuing bank 45 may encrypt 5 the message containing the OTDC and send the message to the cardholder 40 in a format that may require the disclosure of a security key from the cardholder 40. The preferred embodiment will preferably use asymmetric encryption to protect the OTDC, although many commercially available encryption systems are available. Examples of public security keys that may be used for authorization messages include passwords and biometric keys, such as matches from a fingerprint reader, facial recognition software, iris recognition software, voice recognition software, or a combination of the foregoing.

Often, the OTDC transmission 6 to the cardholder 40 will be received 7 by the cardholder's personal portable computing device, such as a tablet, netbook, or cell phone, which may be a smartphone (collectively, "mobile device"), or by a mobile device otherwise associated with the cardholder 40. In these uses, the security of the mobile device may provide sufficient security. For example, if a cardholder's mobile device requires a password or biometric key to open the mobile device, this may be sufficient to allow a person using the mobile device to open or access messages containing the OTDC. Alternatively, messages containing OTDC may require similar independent security to open. Finally, extra security is an option, not a requirement of the system. No security is required to be in place when opening the message. If the issuing bank 45 and/or cardholder 40 so chooses, then messages containing the OTDC may be transmitted without additional security.

In another embodiment, the cardholder 40 may use his or her mobile device as the digital version of the payment card 20. In this embodiment, downloadable mobile applications designed to be compatible across mobile operating systems on the mobile device (such as iOS and android operating systems and other similar systems) will be installed on the cardholder's mobile device. The connected network may provide data storage, computing functionality, application security, and similar functionality. The cardholder 40 will enter identification information to create an account. The cardholder's identification information may include (but is not limited to) some or all of the following: the name of the cardholder; a cardholder's social security code; the cardholder's date of birth; the cardholder's home or billing address; and a driver's license or other state or federally issued identification number for the cardholder. The cardholder 40 may also enter the payment card number 30, the expiration date 47 of the payment card 20, and the CVV number 46 of the payment card 20. In this embodiment, the payment card number 30 and other cardholder identification information will be stored on the mobile device or in a remote (typically cloud-based) data storage location. Many of the information described above may correspond to information typically found in a computer chip 90 embedded in the payment card 20 using the EMV protocol. At a minimum, the information in or associated with the mobile device will be sufficient to identify the cardholder 40 and account number 30, as well as sufficient information to identify the issuing bank 45. This allows the cardholder 40 to make contactless purchases-i.e. purchases made from the merchant without presenting the merchant with a physical payment card 20.

Some payment cards 20 contain a contactless chip 49. These are chips embedded in the card, typically distinct from the secure chip 90, which contain the information discussed in the context of using the mobile device as a payment card 20. The contactless chip 49 utilizes Radio Frequency Identification (RFID) technology. The merchant's card reader powers the contactless chip in the card, which then sends out a signal containing information sufficient to identify the cardholder 40 and the issuing bank 45. This information is then transmitted to the issuing bank 45 along with other transaction information.

The physical payment card 20 need not have the payment card number 30 printed on its face when the contactless chip 49 and/or EMV chip 90 is present, or for card transactions, the payment card number 30 need not be printed on it at all.

When the cardholder's mobile device contains a downloadable mobile application as disclosed herein, the communication to the cardholder 40 of the OTDC may be performed as an in-application communication. The security measures discussed above may optionally be used to control access to communications in any application, including messages containing OTDC. The cardholder 40 will provide 8 the appropriate security key to allow the opening of the message containing the OTDC.

When the communications to the cardholder 40 of the OTDC are encrypted, the cardholder 40 will have a decryption key to allow the cardholder's mobile device to decrypt 10 the communications. The decryption key may be included on the cardholder's mobile device and/or within a downloadable mobile application on the mobile device. The updated decryption key(s) may be provided by the issuing bank 45 from time to time via the same communication method used to transmit the OTDC.

In one embodiment, the issuing bank's computer system may generate a 3OTDC after receiving information indicating that a transaction has been initiated and identifying the cardholder 2A. As used herein, a transaction is initiated when a cardholder 40 wishes to attempt to shop from a merchant and provide information via the merchant or the merchant's computer network sufficient to allow the issuing bank 45 to identify the cardholder 40.

Alternatively, the cardholder's mobile device may contact the issuing bank 45 directly via the internet or other telecommunications network to alert the issuing bank 45 that OTDC generation is required. This request 2B may occur automatically when the cardholder 40 begins to use the mobile device as a payment card 20, or the cardholder 40 may use the mobile device to contact the issuing bank 45 to request 2B OTDC before making a purchase using the mobile device or physical payment card 20, or before initiating a card absence transaction over the network or via telephone.

Whatever prompt results in a 3OTDC, it is transmitted 6 to the cardholder 40 and added to the issuing bank's transaction approval criteria. If the OTDC is not provided to the issuing bank 45 by the merchant or the merchant's system, the transaction should not be approved.

In some embodiments, the OTDC may have an expiration date or time. Unless the OTDC is used within a set number of hours or minutes from when it was generated, the OTDC cannot function. When the OTDC is generated within the process of an initiated transaction, the merchant may be identified to the issuing bank 45. In this embodiment, the OTDC may be limited to use in transactions with the identified merchant.

In some embodiments, the system may be configured to notify the cardholder 40 whether an attempt was made to use the cardholder's payment card number 30 that does not meet the issuing bank's transaction approval criteria. This notification may include the location where the attempted transaction occurred and the time at which the attempted transaction occurred. The system may provide details to the cardholder 40 regarding the reason for the transaction approval criteria not being met, e.g., the correct OTDC was not entered. The disclosed system may automatically generate a communication, populate the communication with information regarding the failed transaction attempt, and send the communication to the cardholder 40. In one embodiment, the disclosed system may send the communication to the cardholder 40 via email, text message, phone call, push notification, or any other communication path, and the communication may be provided as an in-application communication.

In some embodiments, the verification information may be provided to the cardholder 40. This may include the date, time, merchant location and amount. This may be provided to the cardholder 40 using text, email, push notifications, in-app communications, or any other means of communication. The validation information may also be maintained in a registry by the issuing bank 45 in a format accessible to the cardholder 40.

In operation, the cardholder 40 will initiate 1a purchase in the physical presence of a merchant, on the internet or via telephone. For transactions where the card is present or other cardholder is present, the transmission 2A of the payment card number 30 or other cardholder identification information to the issuing bank 45 will prompt the issuing bank 45 to generate a 3OTDC. The issuing bank 45 will transmit 6 the OTDC to the cardholder 40, most typically by transmitting 6 the OTDC to the mobile device of the cardholder. The mobile device may prompt the cardholder 40 to provide a security key, which if provided, would allow the mobile device to decrypt, display, and/or otherwise issue a 10OTDC. The cardholder 40 will then key in or otherwise provide 11 the OTDC to the merchant. For in-store transactions or transactions where both the merchant and cardholder 40 are physically present, this may be done on the keypad as the PIN phase of the transaction or in addition to the PIN phase of the transaction. For online or telephone transactions, this may be done as or in addition to the CVV phase of the transaction. For contactless transactions, the mobile device may provide the OTDC directly to the merchant's terminal. The merchant will then transmit 12 the OTDC and any other transaction information not yet provided to the issuing bank 45. If the OTDC matches the number generated by the issuing bank 45 and the issuing bank's other transaction authorization criteria are met 13, the transaction will be authorized 14A. However, if the OTDC provided to the merchant 4 does not match the OTDC generated by the issuing bank 45, or if other authorization criteria of the bank are not met, then the transaction should not be authorized 14B.

OTDC can also be used in ATM transactions as well. For purposes of this application, the term merchant encompasses ATMs. Most ATM (automated teller machine) transactions utilize card and PIN security. In an embodiment of the invention, placing the payment card 20 into an ATM, or into any ATM that utilizes contactless technology, scanning the cardholder information into the ATM will cause a signal to be transmitted to the issuing bank 45, triggering the generation of an OTDC that will then be transmitted to the cardholder's mobile device. The cardholder 40 will provide the OTDC to the ATM instead of or in addition to the PIN, at which point the ATM transaction will be allowed to proceed. If the OTDC is not provided to the ATM, then the ATM transaction should not be authorized.

Although the issuing bank 45 (or its processor) is responsible for generating the OTDC in most embodiments disclosed herein, those skilled in the art will appreciate that an intermediary may be responsible for generating the OTDC. For example, the card network 80 may generate an OTDC and transmit it to both the cardholder 40 and the issuing bank 45. From this point on, the process will be the same. The cardholder 40 will transmit the OTDC to the merchant, who will then transmit the OTDC to the issuing bank 45. Unless the OTDC provided by the merchant to the issuing bank 45 matches the OTDC generated by the intermediary, the transaction will not be approved. The identity of the intermediary is not important, except that the intermediary should not be a merchant and the intermediary should not ever communicate the OTDC to the merchant.

The advantages of the present security system are manifold. If the cardholder's payment card number 30 is revealed, it cannot be used to make purchases without the OTDC. Acquiring the OTDC will not allow third parties to shop without paying the card number 30 and other elements of the issuing bank's transaction approval criteria. Even if the OTDC and payment card number 30 were acquired, the third party would not be allowed to make additional purchases on the payment card 20. OTDC is a one-time code. It is generated for the transaction concerned and is valid only for that single transaction. Having the payment card number 30 and the old OTDC would not allow third parties to make purchases. The third party must have both the payment card number 30 and the current OTDC to make a purchase using the payment card 20. It would be useless to obtain one without the other.

Although preferred embodiments have been described herein, those skilled in the art to which the invention relates will appreciate that modifications, variations and improvements may be made without departing from the scope of the invention as defined by the appended claims.

Claims

1. A method of securing payment card transactions conducted at least in part between a cardholder, an issuing bank and a merchant via a telecommunications network, wherein the method comprises:

transmitting sufficient information to identify a cardholder to said issuing bank via said telecommunications network;

generating a one-time data code;

transmitting the one-time data code to the cardholder via the telecommunications network;

communicating the one-time data code from the cardholder to the merchant;

transmitting the one-time data code from the merchant to the issuing bank via the telecommunications network;

checking whether the one-time data code transmitted by the merchant to the issuing bank matches the generated one-time data code; and

denying authorization of the transaction unless the one-time data code transmitted by the merchant to the issuing bank matches the generated one-time data code.

2. The method of securing payment card transactions of claim 1 wherein said one-time data codes are generated using a random number generator.

3. The method of securing payment card transactions of claim 2 wherein the issuing bank generates the one-time data code.

4. The method of securing payment card transactions of claim 2, wherein said one-time data code is generated after said cardholder initiates said transaction with said merchant.

5. A method of securing payment card transactions as recited in claim 2, wherein the one-time data code is encrypted prior to transmission of the one-time data code to the cardholder.

6. The method of securing payment card transactions of claim 5, wherein the one-time data code is transmitted to the cardholder by transmitting the one-time data code to a mobile device associated with the cardholder via the telecommunications network.

7. The method of securing payment card transactions of claim 6 wherein said one-time data code is transmitted to said cardholder over said telecommunications network via a communication method selected from the group consisting of: email, text message, phone call, push notification, and combinations thereof.

8. The method of securing payment card transactions as recited in claim 6, further comprising requiring a security key to be provided to the mobile device before the one-time data code is issued to the cardholder.

9. The method of securing payment card transactions as recited in claim 8, wherein the security key is selected from the group consisting of: passwords and biometric keys and combinations thereof.

10. The method of securing payment card transactions as recited in claim 9, wherein the biometric key is selected from the group consisting of: a match from a fingerprint reader, a match from facial recognition software, a match from iris recognition software, a match from voice recognition software, or a combination thereof.

11. The method of securing payment card transactions of claim 6 wherein said mobile device decrypts said one-time data code.

12. A method of securing payment card transactions as recited in claim 1, further comprising checking whether the one-time data code has been used by the cardholder for a previous transaction, and if used, discarding the one-time data code and generating a second one-time data code.

13. The method for securing payment card transactions of claim 1 wherein said merchant comprises an ATM.

14. The method of securing payment card transactions of claim 6, wherein the mobile device is configured to be used as a contactless payment card.