Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/3224—Transactions dependent on location of M-devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/4012—Verifying personal identification numbers [PIN]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
  • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Definitions

• the invention relates in general to the field of secure electronic credit transactions, and more particularly, to a method and a system for secure credit card payment using a credit card with a magnetic stripe.
• EMV is the leading payment system specification for credit cards on the market and was jointly developed by the companies Europay International, Mastercard International, and Visa International, hence the abbreviation EMV.
• EMV Europay International, Mastercard International, and Visa International
• PCT/EP2010/066186 relies on that the cardholder has a payment card with an integrated EMV approved chip which can be read by the secure card reader device, which today is not always the case, for instance when the payment card only has a magnetic stripe or when only a unsecure card reader device is available.
• an aspect of the present invention is to provide a way to make secure and EMV approved credit card payments using a payment card with a magnetic strip and an ordinary unsecure mobile phone with an unsecure card reader device which seek to mitigate, alleviate, or eliminate one or more of the above-identified deficiencies in the art and disadvantages singly or in any combination with a sustained level of payment security.
• a first aspect of the present invention relates to a method of conducting an electronic card payment between a merchant, having a merchant's device with a card reader, and a cardholder, having a payment card and a cardholder's device, characterized in that it comprises reading payment card information associated with said payment card using said card reader in said merchant's device, entering purchase information in the merchant's device and transmitting said purchase information and said payment card information to a payment server, entering a personal identification number (PIN) in said cardholder's device, and submitting said PIN to said payment server, and transmitting said purchase information and an updated payment card information comprising at least said PIN to a bank server (106) conducting said card payment.
• PIN personal identification number
• the method may further comprise that in said payment sever retrieving, from previously stored payment card information, at least one contact information associated with said received payment card information, and transmitting a request for PIN message to said cardholder's device (103), using said contact information.
• the invention further relates to a method wherein said request for PIN message contains a web address of a secure web page on said payment server and wherein the step of submitting the PIN comprises submitting said PIN via said web page.
• the invention further relates to a method wherein the contact information may be at least one phone number or one email address.
• the method may further comprise transmitting said at least one contact information associated with said payment card to said merchant's device, and selecting in said merchant's device a contact information to use for communication with said cardholder's device and transmitting information about said selection to said payment server, and wherein said request for PIN message is transmitted to said cardholder's device, using said selected contact information.
• the method may further comprise transmitting a receipt message and a signature request from said payment server to said merchant's device and signing said receipt message and transmitting said signed receipt message to said payment server.
• the method may further comprise determining, in the merchant's device, the geographical coordinates of the merchant's device, and transmitting it to said payment server determining, in the cardholder's device, the geographical coordinates of the cardholder's device, and submitting it to said payment server in the payment server comparing the geographical coordinates of the merchant's device and the cardholder's device, and if said geographical coordinates are separated more than a specified distance from each other an rejection message is transmitted from said payment server to said merchant's device and/or to the cardholder's device.
• the method may further comprise the step of starting a time-limited payment session in the payment server when said purchase information and payment card information is received from said merchant's device.
• a second aspect of the present invention relates to a system for conducting an electronic card payment between a merchant and a cardholder, the system comprising a merchant's device, a cardholder's device and a payment server characterized in that said merchant's device, cardholder's device and payment server, are adapted to perform the steps described in the first aspect of the present invention related to a method for conducting an electronic card payment between a merchant and a cardholder as described above.
• Fig. 1 shows a block diagram of a system for conducting card payments using an ordinary mobile device and a card reader device, according to an embodiment of the present invention
• Fig 2 shows a flow chart describing the steps in a method for conducting a credit card payment, according to the embodiment of the present invention.
• Embodiments of the present invention will be exemplified using a mobile communication device such as a mobile phone.
• a mobile communication device such as a mobile phone.
• the invention is as such equally applicable to electronic devices in general which have wired- and/or wireless communication capabilities. Examples of such devices may for instance be any type of mobile phone, laptop (such as standard, ultra portables, netbooks, and micro-laptops), handheld computer, portable digital assistant, tablet computer, gaming device, accessory to mobile phones, etc.
• laptop such as standard, ultra portables, netbooks, and micro-laptops
• handheld computer portable digital assistant
• tablet computer tablet computer
• gaming device accessory to mobile phones, etc.
• the embodiments outlined in this specification are exemplified with, and related to, mobile phones only.
• Embodiments of the present invention will be exemplified using a credit card.
• the invention is as such equally applicable to any type of credit card having a magnetic strip conforming to the ISO/IEC 781 1 numbering standard.
• Examples of such credit cards may for instance be any type of debit card, charge card, fleet card, store-value card, or gift card.
• Payment cards may for instance be any type of debit card, charge card, fleet card, store-value card, or gift card.
• Payment cards may for instance be any type of debit card, charge card, fleet card, store-value card, or gift card.
• PIN personal identification number
• a payment card payment may also be authorized by the cardholder's signature.
• the cardholder notifies the merchant that he or she does not have a PIN code for the payment card after which the merchant hands over a paper slip to the cardholder and requesting the cardholder to sign it with his or hers signature.
• FIG. 1 shows a block diagram of such a secure electronic payment system 100 comprising a payment card with a magnetic stripe 101 , a merchant's device 102 which may be an ordinary mobile phone with an integrated or add-on unsecure card reader, a cardholders' device 103 which also may be an ordinary mobile phone, a payment server 105 handling the payment session and a bank server 106.
• the cardholder will, when paying for the item or service he or she wishes to purchase, present his or hers payment card 101 with a magnetic strip to the merchant.
• the merchant will initiate a payment application in the merchant's device 102,201 .
• the merchant's device 102 could be any type of electronic device having the capability of running a payment application, having a user-interface for presenting and inputting information, a (unsecure) card reader device either integrated, attached or in communication with it, and means for communicating either by wire or wireless with a payment server 105 over a communication network 104 such as the Internet.
• the merchant is then prompted by the payment application in the merchant's device 102 to enter purchase information and payment card information 202.
• the merchant will swipe the payment card 101 ,202 in the card reader and thereby reading payment card information from the magnetic stripe on the payment card into the merchant's device.
• the merchant will also manually or automatically enter purchase information in the merchant's device.
• the entered purchase information generally comprise the amount that the cardholder is paying for the item or service, but may also comprise further information about the item (such as a description of the item or service), information about the merchant (such as social security number, etc.), the merchant's business (such as the merchants bank account number, VAT identification number or the like), the geographical position of the merchant's store or the merchant's device.
• the magnetic stripe on the payment card usually contain up to three tracks with payment card information written in different encodings.
• the read payment card information generally comprises a primary account number (PAN), the name of the cardholder and but may also comprise discretionary data.
• PAN primary account number
• the discretionary data may differ depending on the type of payment card and may be any of a personal identification number (PIN) verification value (PW), expiry date and a card security code (CSC, also known as CVC, CW, CVV2, CVD, etc.).
• the PAN is a structured and standardised numbering scheme in accordance with ISO/IEC 7812.
• the ISO/IEC 7812 number is typically 16 digits in length and it consists of:
• the PAN is often embossed or printed on the payment card and encoded the magnetic stripe in accordance with ISO/IEC 7810 and ISO/IEC 781 1 .
• the entered purchase information and read payment card information are transmitted from the merchant's device 103 to a payment server 105, in encrypted form, for instance using an industrial strength Secure Socket Layer (SSL) encryption method, via a wireless or wired link over a network such as the Internet 104, step 203.
• SSL Secure Socket Layer
• the payment server 105 When the payment server 105 receives the purchase information and the payment card information, the payment server initiates a payment session 204 and decrypts the received purchase information and payment card information.
• the received purchase information and payment card information may temporary be stored in the payment server 105 for the duration of the payment session.
• the payment server 105 will serve as the hub for the on-going payment session, managing the payment session with the merchant's device 102, the bank server 106 and the cardholder's device 103 to complete or reject the payment.
• the payment can be rejected for several reasons such as that the cardholder has not got enough money on his or hers bank account, any step in the payment session goes wrong, the cardholder or the merchant are band due to misuse of the payment service or due to criminal matters, etc.
• the payment session may or may not be limited in time.
• a time-limited payment session is started in the payment server 204. If the payment session is limited in time, all information relating to the ongoing payment session will be deleted for security reasons if the payment session times-out, despite being managed in a secure environment in the payment server 105.
• a time-out receipt stating that the merchant and the cardholder engaged in a payment that timed-out may optionally be stored in the payment server 105.
• the payment server 105 compares all or a part of the received and decrypted payment card information with previously stored payment card information in the payment server 105.
• Each payment card information stored in the payment server 105 is associated with list of contact information compiled by the cardholder (usually during a registration process).
• the list of contact information comprises at least one way of how the cardholder associated to the payment card from which the payment card information is extracted, can be reached or contacted.
• the contact information may for instance comprise (at least) one or several of; a phone number, an email address, a Skype identity, Google Talk identity, or any other type of communication address.
• the associated list of contact information associated with the matched stored payment card information can be retrieved from the payment server 105.
• Payment card information and the associated list of contact information may for instance be stored in the payment server 105 during a mandatory registration process that the cardholder has to complete before the cardholder can use the payment card 101 for the first time.
• the retrieved list of contact information (comprising for instance a phone number and an email address) is, in an embodiment of the present invention, transmitted from the payment server 105 to the merchant's mobile device 103.
• the list of contact information (for example the phone number and the email address) is displayed to the merchant.
• the merchant is then able to select one of the displayed, in the payment application in the merchant's device, contact information from the list of contact information, for example the phone number, preferably in cooperation with the cardholder.
• step 206 the selected contact information is transmitted back to the to the payment server 105 via the payment application in the merchant's device 102.
• the transmission over the network 104 between the merchant's device and the payment server 105 may or may not be encrypted using SSL technique.
• a request for PIN message is transmitted to the cardholder's device using the selected contact information.
• the request for PIN message is displayed in a payment application on a display in the cardholder's device (103).
• the request for PIN message contains a web address, such as a uniform resource locator (URL), to a secure web page.
• the request for PIN message containing the URL is displayed to the cardholder in a payment application on a display in the cardholder's device, and the cardholder activates the web address by for instance clicking on it.
• a secure web page is then accessed on the payment server 105 and securely displayed to the cardholder in the payment application in the cardholder's mobile device.
• the previously entered (by the merchant) PIN is presented to the cardholder using the secure web page.
• the web page may in a variant also contain information about the merchant (i.e. personal name, name of the store, VAT identification number, geographical position, etc.) and the amount to be charged.
• the cardholder is prompted to submit the PIN in order to continue the payment session and the time-limited payment session if one has been started.
• the secure web page is preferably hosted on the payment server 105 in a secure, both physically secure and software secure way, environment.
• the entering of the PIN may then, computer wise, take place in the secure environment on the payment server 105 in an encrypted state and not in the unsecure environment in the cardholder's device 208, and thus eliminating any eavesdropping applications running in the cardholder's device.
• the cardholder enters the PIN in the secure web page, and thereby submitting the PIN from the cardholder's device 103 to the payment server 105.
• the payment application could be a compiled application launched in the cardholder ' s otherwise unsecure cardholder's device 103.
• the payment application in the cardholder's mobile device establishes a secure and encrypted connection with the payment server 105using industry-standard-strong-SSL technique.
• the payment application creates a secure environment in the mobile phone by for example using a web-based sandbox technique. In this way the card holder may safely enter his or hers PIN code without the risk of a malicious third party program intercepting it.
• the actual representation of numbers and/or letters in the payment application could be uniquely created for the occasion by the payment server and will not be reused.
• the payment server 105 may also verify that the PIN code submitted via the cardholder's device is legit and that the payment session initiated by the merchant is legit by for instance comparing the geographical positions of the merchant's device 102 and the cardholder's device 103.
• This approach requires that both the merchant's device 102 and the cardholder's device 103 transmit their geographical location (by for instance reading the global positioning system (GPS) coordinates from a GPS service in each device) to the payment server 105 for comparison.
• GPS global positioning system
• the merchant's device's coordinates may either be pre- registered in the payment server 105 (a store usually do not change location that often) or it may be included in the purchase information or in the payment information transmitted to the payment server 105.
• the cardholder's device 103 may for instance submit its geographical coordinates when submitting the PIN code to the payment server 105. If the payment server 105 comes to the conclusion, by comparing the geographical coordinates with each other, that the merchant's device and the cardholder's device are separated more than a specified distance from each other, then the card payment session may be terminated and an error or rejection message may be sent to the merchant's device and/or to the cardholder's device.
• the payment card information in the payment server 105 is updated with the received PIN code, thus forming an updated payment card information.
• the payment server 105 will transmit the updated payment card information (with the PIN) and the purchase information to the bank server 106,209 for conducting the electronic card payment between the merchant and the cardholder.
• the bank server will, when conducting the electronic card payment perform an on-line verification and a payment transaction (i.e. a disbursement of money from the cardholder's account to the merchant's account).
• the transmission between the payment server 105 and the bank server 106 may be encrypted with a method that fulfills the requirements of worldwide standards of security of online transfer of payment card details through a secure socket layer.
• the bank server 106 receives the encrypted purchase information and the updated payment card information, decrypts the encrypted purchase information and the updated payment card information, verifies the updated payment card information and performs the payment transaction if everything checks out.
• the bank server 106 completes the online verification and payment transaction by transmitting a receipt message from the bank server 106, to the payment server 105.
• the receipt message may for instance contain an acknowledgement whether the payment amount was successfully charged to the account or not.
• the receipt message is transmitted from the payment server 105 to the merchant's device 102, and displayed to the merchant in the payment application on the display, and/or to the cardholder's device, and displayed to the cardholder in the payment application on the display.
• the receipt message is stored in the payment server 105. Since the receipt message is stored in the payment server 105 it may later be accessed and viewed by the merchant and/or the cardholder.
• the transmitting and storing of the receipt message formally ends the payment session or the time-limited payment session if one has been started.
• the receipt message together with a signature request is transmitted from the payment server 105,210 to the merchant's device 102 and displayed to the merchant in the payment application on the display.
• the merchant hands the merchant's device 102 to the cardholder whom enter his or hers signature in the payment application, and thus signing the receipt message 21 1 .
• the cardholder enters his or hers signature using the touch screen and a stylus, or any other method, to enter the signature on the merchant's device 102.
• the signed receipt message is transmitted in an encrypted state to the payment server 105,21 1 from the merchant's device, where a payment receipt is generated based on said signed receipt message.
• the payment receipt is stored in the payment server 105.
• the generation of the payment receipt in the payment server 105 formally ends the payment session or the time-limited payment session if one has been started.
• the payment receipt may be transmitted to the merchant's device 102, to the cardholder's device or to both the merchant's device 102 and to the cardholder's device. Since the payment receipt is stored in the payment server 105 it may later be accessed and viewed by the merchant and/or the cardholder.
• a payment session may be completed without the need for a payment card 101 with an EMV-approved chip, a fully secure merchant's device 102, a fully secure cardholder's device 103 or a secure card reader. It is to be understood that as stated above this is a typical use- case. However one or more of the steps disclosed in figure 2 may be omitted. For example could steps 209 and 210 be omitted.
• the payment server 105 is easy to keep safe, both physically and software-wise since it is usually placed in a remote secure location and protected by state-of-the-art security software.
• the payment method comprising the combination of using a user signature in the merchant's device and the method of requesting a PIN code from the cardholder's device, will increase the security further, because this solution requires proximity (i.e. being in the same physical location) between the merchant's device and the cardholder's device since the cardholder is required sign the receipt message in the merchant's device.

Landscapes

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

Priority Applications (1)

Applications Claiming Priority (1)

Publications (1)

Family

ID=46516718

Family Applications (1)

Country Status (1)

Cited By (1)

Citations (5)

• 2012
  • 2012-07-09 WO PCT/EP2012/063433 patent/WO2014008922A1/fr not_active Ceased

Patent Citations (5)

Similar Documents

Legal Events