CONTACTLESS (NFC) AND QR CODE-BASED SECURE E-COMMERCE PAYMENT METHOD AND SYSTEM
Patent Information
- Authority / Receiving Office
- TR · TR
- Patent Type
- Applications
- Current Assignee / Owner
- İLKER BAKIR
- Filing Date
- 2026-06-11
- Publication Date
- 2026-07-21
Smart Images
Figure 00000009_0000 
Figure 00000010_0000
Abstract
Description
1 TARIFF 5 CONTACTLESS (NFC) AND QR CODE-BASED SECURE E-COMMERCE PAYMENTS METHOD AND SYSTEM TECHNICAL FIELD The invention is a computer system designed to enhance payment security in electronic commerce transactions. It relates to a system and method based on. In particular, the invention concerns a web resource to which payment will be made, 10 Transaction verification at the time of payment, physical payment card being scanned by NFC reader on the mobile device. Confirmation of existence through the unit and actual card information for e-commerce Payment process completed via a one-time token without accessing the interface. It is in the field. STATE OF THE ART 15 In well-known e-commerce payment applications, the user enters their card number, expiration date, and Sensitive information such as security codes are often entered into payment forms located on the browser. They enter it manually. In this approach, the card data is entered on the user's device, at the browser layer. risk of being intercepted in third-party scripts or fraudulent payment interfaces 3D Secure-like authentication mechanisms strengthen payment confirmation. Together, we completely eliminate the risk of data leakage during the process of entering card information into the payment form. It does not eliminate it. Another drawback in the current state of the technology is the physical nature of the card used during payment. Whether the user is present or not is directly determined by the e-commerce interface. It cannot be verified. Furthermore, the user must verify that the domain name they paid for actually belongs to the merchant. 25 It is often a technical issue to determine whether the redirected payment page is fake or not. It cannot be evaluated using these parameters. Therefore, entering the card information is not allowed. It does not require, verifies the presence of a physical card, and risks the payment source at the time of the transaction. An integrated solution is needed that evaluates the situation through analysis. TECHNICAL PROBLEMS THAT THE INVENTION AIMS TO SOLVE 30 The main purpose of the invention is to eliminate the need to manually enter card information into the e-commerce web interface. The goal is to reduce the risks of data leaks, phishing, and man-in-the-middle attacks by eliminating these threats. 2 Another purpose of the invention is to make the payment process dependent on the physical presence of the payment card at the time of the transaction. authorizing the cardholder by linking it to a hardware contact or near field. The goal is to strengthen communication through verification. Another purpose of the invention is to provide the domain name, certificate, and other details related to the web resource to which payment will be made. Technical parameters such as routing chain, merchant information, and blacklist records are centralized. The goal is to provide the user with security information before the transaction by putting them through a risk analysis process. 10 The invention also allows only specific card information to be transmitted to the e-commerce interface instead of the actual card information being transmitted. The process aims to utilize a token that is limited by transaction, duration, amount, and merchant. EXPLANATION OF THE FIGURES Figure 1 shows the e-commerce interface, mobile application, NFC hardware, and central system of the invention. This shows the relationship between the server, the risk database, and the payment institution. 15 Figure 2 shows the process of generating a dynamic identifier in the payment method covered by the invention, and the payment itself. It shows the steps involved in the process until approval. EXPLANATION OF REFERENCE MARKS IN THE FIGURES 1: E-commerce interface or payment SDK module 2: Dynamic payment identifier 20 3: Mobile application 4: NFC reader hardware unit 5: Physical payment card 6: Secure central server 7: Risk analysis and blacklist database 25 8: Bank or payment institution transaction center 101: Step to create a dynamic payment identifier 102: Step 1: Reading the identifier with the mobile application 103: Resource and risk score inquiry step 104: Step 30 to inform the user of the risk outcome and obtain their approval. 105: Step 1: Reading the physical card via NFC and confirming card presence. 3 106: Transaction-based token request and token production step 5 107: Step to submit the token to the e-commerce interface 108: Payment confirmation and transaction closing step DETAILED DESCRIPTION OF THE INVENTION The system that is the subject of the invention is an e-commerce interface (1), dynamic payment identifier (2), mobile application (3), NFC reader hardware unit (4), physical payment card (5), secure central server (6), 10 risk analysis and blacklist database (7) and bank or payment institution transaction center (8) It has a coordinated data processing structure carried out between them. The system is the e-commerce interface. without needing to collect card information, the payment session can be completed via mobile application and central system. Verified via the server. When a payment session is initiated, the e-commerce interface (1) receives 15 transaction-based payments from the central server (6). It requests the creation of a session log. The session log includes: merchant identifier, payment amount, currency, payment source address, timestamp, unique transaction number, and repeat. It contains information about random values generated to prevent its use. The central server (6) contains this It generates the dynamic payment identifier (2) associated with the record. The dynamic payment identifier (2), It is preferably in QR code format and does not directly contain card data; instead, it is signed or 20 an encrypted session token or a limited-time address that provides access to this token It carries information. Mobile application (3), Dynamic payment in the step of reading the identifier with the mobile application (102) It reads the identifier (2) and parses the session information within the identifier. Parsing During this process, the identifier's signature, timeout value, transaction number, and source address are checked. 25 This is done. If the signature cannot be verified, the session has expired, or the same transaction number has been used before, If used, the mobile application (3) stops the payment process and fails to send the central server (6). It sends a confirmation notification. In the source and risk score inquiry step (103), the central server (6) belongs to the payment source. It queries technical information through the risk analysis and blacklist database (7). In this query, 30 domain registration age, TLS / SSL certificate validity and certificate holder, redirection chain, merchant account and domain name matching, blacklist records, previously reported phishing records, server location and source address matching the address in the transaction session exactly. These parameters are evaluated. The values obtained from these parameters are converted into a weighted risk score. It is converted. 35 4 In the step of informing the user of the risk result and obtaining approval (104), the mobile application (3), risk 5 It displays the score to the user along with the transaction amount and trader information. The risk score is calculated in advance. If the value falls below the specified threshold, the transaction will be blocked or additional confirmation will be required from the user. The risk score is obtained if it is within the safe range and the user gives their consent. The system proceeds to the step (105) of reading the physical card via NFC and confirming the card's presence. In the step of reading the physical card with NFC and confirming the card's presence (105), user 10 Bring the physical payment card (5) close to the NFC reader hardware unit (4) on the mobile device. The mobile application (3) uses near field communication in accordance with the ISO / IEC 14443 standard. It confirms that the card was available during the transaction. The cryptographic application obtained from the card. data and dynamic validation value generated for the transaction by mobile application (3) It is transmitted to the central server (6) via an end-to-end encrypted channel. 15 like the card's security code Manually entered sensitive information is permanently stored in the e-commerce interface (1) or mobile application. It is not written to the storage area. In the process-dependent token request and token production step (106), the central server (6), NFC It matches the payment session with the verification. During the matching process, the transaction number and merchant... identifier, payment amount, currency, device session, timestamp, and user confirmation 20 They are checked together. If the checks are successful, the central server (6) only checks the relevant process. usable, becoming invalid after a certain period, and clearly displaying the actual card information. It produces a single-use token that does not contain any transaction session, trader, or amount information. Because it is cryptographically linked, it is on a different web resource or at a different amount. unusable. 25 In the step of transmitting the token to the e-commerce interface (107), the generated token is sent to the e-commerce interface (1) secure callback address, payment SDK channel, server-side notification, or secure session It is transmitted via the update. The e-commerce interface (1) only receives the token at this stage; the actual It does not collect or store data such as card number, expiration date, or card security code. Thus, if the payment interface is compromised, the attacker can use the following actual card: 30 No data is generated. In the payment confirmation and transaction closing step (108), the e-commerce interface (1) or central server (6), The bank or payment institution transmits the token-linked payment confirmation to the transaction centre (8). Transaction central (8) matches the token with the authorization information and sends the payment result to the central server. (6) reports. When the payment is successful, the session is closed; the token becomes unusable again. 35 It is brought in and the result of the risk analysis is stored as an audit record. If the payment fails, then 5 The token is cancelled, and no further payment attempts can be made with the same token. Thanks to this structure, the invention enables risk analysis of the payment source, physical card availability, and It combines token-based card data concealment within the same transaction flow. The distinctive feature of the invention is... The advantage is that it eliminates the need to enter card data in the payment web interface while simultaneously... It technically scores the reliability of the source and also physically verifies the transaction with NFC. It is connecting to the card. 20 30
Claims
6 REQUIREMENTS 5 1. It is a secure payment system for processing e-commerce payments, The system includes an e-commerce interface (1) that initiates the payment session, and the payment session in question. unique dynamic payment identifier (2), a mobile that reads the dynamic payment identifier application (3) NFC reader that reads the physical payment card (5) by near field communication hardware unit (4), secure central server (6) managing the payment session, payment source 10 risk analysis and blacklist database (7) and payment authorization It is characterized by having a bank or payment institution transaction centre (8) performing the transaction.
2. Secure payment system according to claim 1, and dynamic payment identifier (2) merchant identifier, payment amount, currency, source address, timestamp, unique transaction number and is characterized by being associated with a random value that prevents reuse. 15 3. Secure payment system according to claim 1 or 2, and dynamic payment of the mobile application (3) After reading the identifier (2), the identifier signature, transaction duration and transaction number It is characterized by verifying whether or not it has been used before.
4. According to claim 1, it is a secure payment system and the payment is made by a secure central server (6). its source; domain name, TLS / SSL certificate, routing chain, merchant-source matching, black 20 Risk analysis and blacklist database according to list records and phishing reports parameters (7) It is characterized by its scoring system.
5. According to claim 4, it is a secure payment system and the mobile application's (3) risk score is payment It displays the amount and trader information to the user, along with the risk score based on the defined threshold. If the values are not met, the payment process will be stopped or additional user confirmation will be required. 25 It is characterized by its desire.
6. Secure payment system according to Claim 1, physical payment card (5) NFC reader Reading the hardware unit (4) in accordance with the ISO / IEC 14443 standard and this by verifying the physical presence of the card at the time of the transaction as a result of the reading. It is characterized by 30 7. It is a secure payment system according to claim 6, and the data obtained as a result of NFC reading. cryptographic application data is sent by the mobile application (3) to a secure central server. (6) is characterized by being transmitted over an end-to-end encrypted channel.
8. Secure payment system according to claim 1, secure central server (6) NFC verification, payment session, user confirmation, merchant identifier, payment amount and time 35 7 After matching the stamp, a single-use card (5) that does not explicitly contain the actual card information. It is characterized by the creation of a token.
9. According to claim 8, it is a secure payment system, and the generated token is only valid for the relevant payment session. by cryptographically limiting the amount and duration applicable to the merchant. It is characteristic.
10. Secure payment system according to claim 8 or 9, card number to e-commerce interface (1), 10 only the token is transmitted, without providing an expiration date or security code. It is characteristic.
11. It is a method for ensuring secure e-commerce payments; - Creating a dynamic payment identifier specific to the payment session (101), - The dynamic payment identifier (2) is read by the mobile application (3) and the identifier is 15 It parses the session information within it, and during the parsing process, it takes the identifier's signature and time. If the overshoot value, transaction number, and source address are checked, and the signature cannot be verified, If the session has expired or the same transaction number has been used before, mobile (3) stopped the payment process and failed verification to the central server (6). Reading the dynamic payment identifier with the mobile application to which it sent the notification (102), 20 - Central server (6), technical information of the payment source, risk analysis and blacklist queried through the database (7) and in this query the domain registration age, TLS / SSL Certificate validity and certificate holder, redirection chain, merchant account and domain name. matches, blacklist records, previously reported phishing records, server location, and The source address is evaluated for exact matching with the address in the transaction session, and this 25 payment where the values obtained from the parameters are converted into a weighted risk score inquiry about the risk score of the source (103), - The mobile application (3) provides the user with the risk score, transaction amount and trader information. The transaction is indicated if the risk score is below a predetermined threshold value. blocked or additional confirmation obtained from the user, risk score within the safe range and 30 If the user gives their consent, the system can read the physical card via NFC and the card... informing the user of the risk result and confirming the existence step (105) alma (104), - The user’s physical payment card (5) is inserted into the NFC reader hardware unit (4) on the mobile device. the mobile application (3) brings closer the near field 35 in accordance with the ISO / IEC 14443 standard. 8 through communication, it confirmed that the card was available during the transaction and received 5 from the card. the obtained cryptographic application data and the dynamic verification value generated for the transaction, mobile application (3) sends end-to-end encrypted channel to central server (6) Reading the transmitted physical payment card with NFC (105), - The central server (6) pairs the payment session with NFC verification and the pairing Transaction number, merchant identifier, payment amount, currency, device session, time 10 The stamp and user approval are checked together, and if the checks are successful, the central system is activated. server (6), which can only be used in the relevant operation and becomes invalid after a certain period of time and generated a one-time token that did not explicitly contain the actual card information, and the token, The transaction session is different from the web because trader and amount information is cryptographically linked. 15 single-use processing-related items that prevent their use at the source or at a different rate. token production (106), - The generated token will be sent to the e-commerce interface (1) via a secure callback address, payment SDK channel, This is communicated via server-side notification or secure session update and is related to e-commerce. the interface (1) receives only the token at this stage; the actual card number, expiry date or does not collect or store data such as card security codes, and thus the payment is 20 Real card data that an attacker could use if the interface is compromised. transmitting the non-created token to the e-commerce interface (107) and - The e-commerce interface (1) or central server (6) confirms the token-based payment to the bank or the payment institution transmits the token to the transaction centre (8) and the transaction centre (8) it matches the authorization information and reports the payment result to the central server (6), 25 The session is closed when the payment is successful; the token becomes unusable again. and the result of the risk analysis is kept as an audit record, and if the payment fails, the token was canceled and a new payment attempt could not be made with the same token. It is characterized by including the steps to complete the payment confirmation (108).
12. According to claim 11, the method is as follows: when the token payment process is complete, the payment fails. 30 by rendering it unusable when it becomes unusable or when a predetermined period of time expires It is characteristic.