[go: up one dir, main page]

CN110766397B - Near field payment method based on data identification model - Google Patents

Near field payment method based on data identification model Download PDF

Info

Publication number
CN110766397B
CN110766397B CN201910998699.8A CN201910998699A CN110766397B CN 110766397 B CN110766397 B CN 110766397B CN 201910998699 A CN201910998699 A CN 201910998699A CN 110766397 B CN110766397 B CN 110766397B
Authority
CN
China
Prior art keywords
payment
data
payee
scene
payer
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.)
Active
Application number
CN201910998699.8A
Other languages
Chinese (zh)
Other versions
CN110766397A (en
Inventor
黄双
王文漪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Fengxin Technology Services Co ltd
Original Assignee
Shenzhen Fengxin Technology Services Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Fengxin Technology Services Co ltd filed Critical Shenzhen Fengxin Technology Services Co ltd
Priority to CN201910998699.8A priority Critical patent/CN110766397B/en
Publication of CN110766397A publication Critical patent/CN110766397A/en
Application granted granted Critical
Publication of CN110766397B publication Critical patent/CN110766397B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/206Point-of-sale [POS] network systems comprising security or operator identification provisions, e.g. password entry
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829Payment protocols; Details thereof insuring higher security of transaction involving key management

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)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The invention discloses a near field payment method based on a data identification model, which comprises the following steps: the receiving party terminal generates receiving content according to the service scene identifier and the corresponding service scene template, uses the private key of the receiving party to digitally sign the service scene identifier and the receiving content by adopting an asymmetric algorithm, and attaches an asymmetric public key of the receiving party; the receiving party terminal generates receiving data to be transmitted according to the data identification model; the payment terminal enters a unified payment entrance, and the payment terminal uses an asymmetric public key of the payee to verify whether the service scene identification and the result of the payee content are consistent with the digital signature of the payee by adopting an asymmetric algorithm; if the two types of information are consistent, the safety authentication is passed; if the payment flow is inconsistent, the payment flow cannot pass the verification, and the payment flow is ended; and automatically identifying and jumping to a corresponding payment scene flow according to the service scene identification to finish payment. The problems of fragility of service functions, inconvenience in use of users, data security risk and the like in the existing payment service flow are solved.

Description

Near field payment method based on data identification model
Technical Field
The invention relates to the technical field of mobile payment safety, in particular to a near field payment method.
Background
With the development of mobile and internet technologies, mobile payment has become a widely accepted payment method. At present, the mainstream mobile payment mode is divided into two types, one is offline payment by taking mobile application of banks and third party payment companies as carriers and taking a two-dimensional code technology as a core; another is NFC (near field communication) near field payment, which is represented by the card organization and multiple handset vendors.
The first kind uses the two-dimensional code technology as the core pay off line. Because the data information quantity displayed by the two-dimensional code is limited, the huge data quantity compiled by the advanced encryption algorithm cannot be supported and is generally transmitted in a plaintext manner, and therefore the security risks of easy tampering, easy theft and the like exist. The two-dimension code can be divided into account transfer (i.e. transmitting a collection account number), small merchant collection scene (i.e. a customer scans a merchant identity code), large merchant overuse scanning gun or intelligent POS machine scene (i.e. a merchant scans a payment authorization code of a customer), and other scenes (including but not limited to subway, bus batch authorization payment scene or other special scenes) which have different payment inlets. Although the risk of partial business can be reduced by subdividing the payment business flow, the problem of security is not solved at all, and the business functions are finely divided due to the splitting of the business, so that the use of users is inconvenient.
The other NFC near field payment represented by the card organization and a plurality of mobile phone manufacturers is superior to the two-dimension code in terms of data volume and safe transmission mode, but the compatibility of the cross manufacturers and the cross systems prevents the market popularization. Taking apple equipment as an example, only the read-write permission of an NFC module is supported at present, and the bidirectional near field communication between equipment of different manufacturers cannot be realized.
In order to solve the above problems, improve data security and continuously optimize user experience, a new payment method needs to be designed.
Disclosure of Invention
The invention aims to provide a near field payment method based on a data identification model, which solves the problems of fragmented service functions, inconvenient use of users, data security risks and the like in the existing payment service flow.
The technical scheme for achieving the purpose is as follows:
a near field payment method based on a data identification model, the data identification model comprising: service scene identification, collection content, asymmetric public key of data sender and digital signature of data sender;
the near field payment method comprises the following steps:
the receiving party terminal generates receiving content according to the service scene identifier and the corresponding service scene template, uses the private key of the receiving party to digitally sign the service scene identifier and the receiving content by adopting an asymmetric algorithm, and attaches an asymmetric public key of the receiving party;
the method comprises the steps that a payee terminal combines a service scene identifier, payee content, an asymmetric public key of the payee and a digital signature of the payee according to a data identification model to generate payee data to be transmitted;
after receiving the collection data, the payer terminal adopts an asymmetric algorithm to verify whether the service scene identification and the collection content result are consistent with the digital signature of the payee by using an asymmetric public key of the payee; if the two types of information are consistent, the safety authentication is passed; if the payment flow is inconsistent, the payment flow cannot pass the verification, and the payment flow is ended;
and the payer terminal automatically identifies and jumps to the corresponding payment scene flow according to the service scene identification to finish payment.
Preferably, the service scene identifier is one or more collection scene identifiers authorized by the financial institution to the user according to the user identity information and the service requirement;
the collection content is as follows: the data fields to be transmitted defined according to the business scene comprise merchant information, order information, security and authentication information, payment authorization information, electronic payment instructions and digital currency information;
the asymmetric public key of the data sender and the digital signature of the data sender are as follows: a unique public-private key pair assigned to the user by the financial institution; the data sender signs the data by using the private key, and the data receiver performs identity authentication and consistency check of the data and the signature by using the asymmetric public key of the data sender after receiving the data.
Preferably, the service scenario includes, but is not limited to:
transfer scenario: both sides of the transfer are natural persons authenticated by real names;
small merchant collection scene: the small merchant or individual user sends the money requesting data, and the customer pays online;
large-scale merchant super-receipts scene: merchants such as shops, supermarkets and the like send money requesting data through mobile equipment or intelligent POS machines, customer equipment receives and returns authorization information, and the merchants conduct online money requesting;
public transportation merchants support special customer authorization scenarios: the equipment such as subways and buses supports the authentication of passengers, obtains payment authorization and delays batch deduction.
Preferably, the payment scene flow includes:
when receiving that the service scene identifier corresponds to the transfer scene, triggering:
the payer jumps to the private transfer page, and the page automatically displays the content in the collection content;
the payer inputs the transfer amount, selects payment information, and completes subsequent remittance operation on the basis of meeting the requirements of a payment gateway;
when the received service scene identifier corresponds to a small merchant collection scene, triggering:
the payer jumps to the active payment page, which will contain the content in the content of the payment;
the payer inputs payment amount, selects payment information, actively sends the transaction to a bank/third party payment company gateway, and completes subsequent transaction verification;
when the received service scene identifier corresponds to a large-scale business super-receipt scene, triggering:
the payment party combines the payment authorization information according to the data identification model to generate data to be transmitted, and the data are transmitted back to the payee through the communication module; the service scene is identified as a large-scale business super-receipt scene, the receipt content is payment authorization information, a private key of a payer is used for carrying out digital signature by adopting an asymmetric algorithm, and an asymmetric public key of the payer is attached;
after receiving payment authorization information of a user, a payee firstly uses the received asymmetric public key of the payer to check, and then sends the payment authorization information and transaction information to a bank/third party payment company gateway together to finish transaction verification.
Preferably, when the received service scene identifier corresponds to a special customer authorization scene, the users of the receiving and paying parties complete the transfer or payment flow according to the requirements of the card issuing, the receiving and managing institutions.
Preferably, near field communication is performed between the payee terminal and the payer terminal through NFC, bluetooth or WiFi.
Preferably, when a scene that the payment transmits information back to the payee is required, the payer terminal signs the service scene identifier and the payee representing the reply content by using the payer private key, attaches an asymmetric public key of the payer, and then combines the two together according to a data identification model to generate data to be transmitted.
The beneficial effects of the invention are as follows: the invention ensures the communication safety and the non-falsification of the content by the innovative design of the data identification model and the application of the asymmetric algorithm, thereby improving the data safety. And meanwhile, the unified payment entrance technical concept of the user is provided, and the user experience is continuously optimized. The scene is automatically identified through the data identification model, the corresponding payment flow is jumped, manual selection or intervention is avoided, and the intelligent payment system is more intelligent. Meanwhile, the model structure is identified according to the defined data, and the requirements of different new scenes can be met by simply updating the scenes and the contents.
Drawings
FIG. 1 is a flow chart of a near field payment method based on a data identification model of the present invention;
FIG. 2 is a schematic diagram of the composition of a data recognition model in the present invention;
fig. 3 is a schematic diagram of a payment scenario of the present invention.
Detailed Description
The invention will be further described with reference to the accompanying drawings.
Financial institutions such as commercial banks, wallet service providers, acquirers, payment institutions, etc. distribute users including but not limited to asymmetric public keys, private keys, etc. based on user identity information and business requirements, and authorize one or more receipt scene identifications (Scenario) etc. to be written to mobile devices, smart devices or POS devices, etc.
The invention proposes: the concept and data recognition model of payment portal is unified. Unified payment portal concept: the user can jump to all payment scenes by clicking the payment button, and for a payer, the foreground interface is provided with only one payment button (namely a unified payment entrance), so that all types of payment can be completed, and the payment is more convenient. All business process identification is transmitted, checked, identified and automatically jumped by the background through the definition of the data identification model, so that the payment function of the payment end is simplified and integrated, and the user experience is improved by only one unified payment entrance and integrating all payment functions.
As shown in fig. 2, the data identification model includes a service scene identification (Scenario), a receipt Content (Content), an asymmetric Public Key (Public Key) of a data sender, and a digital Signature (Signature) of the data sender. The method is specifically as follows:
business Scenario identification (Scenario) the financial institution authorizes the user based on the user's identity information and business requirements. The following several common payment scenarios are initially defined, and the scenario definitions can be freely adjusted and expanded. It should be noted that, the scene definition is related to the identity authentication of the payee, and the identity authentication of the payee is responsible for the KYC audit, admission and supervision by the corresponding acquirer.
Business scenarios include, but are not limited to:
transfer scenario (i.e., transfer of collection account number): both sides of the transfer are natural persons authenticated by real names.
The small merchant/individual user supports the small merchant checkout scenario (i.e., the customer scans the merchant identity): the small merchant or individual user sends the payment data and the customer pays online.
The large merchant super-supports a code scanning gun or an intelligent POS machine money receiving scene (namely, a merchant scans a payment authorization code of a customer): merchants such as shops, supermarkets and the like send money requesting data through mobile equipment or intelligent POS machines, and customer equipment receives and returns authorization information to request money in a networking mode.
Public transportation merchants support special customer authorization scenarios: the equipment such as subways and buses supports the authentication of passengers, obtains payment authorization and delays batch deduction.
Content (Content): the data fields to be transmitted defined according to the business scenario comprise merchant information, order information, security and authentication information, payment authorization information, electronic payment instructions and digital currency information.
Asymmetric Public Key (Public Key) of data sender: a unique public-private key pair is assigned to the user by the financial institution. And the data receiver uses the public key of the data sender to carry out consistency check on the data and the signature.
Digital Signature (Signature) of the data sender, which is assigned to the user's unique public-private key pair by the financial institution. The data sender signs the data by using the private key, and the data receiver performs identity authentication and consistency check of the data and the signature by using the asymmetric public key of the data sender after receiving the data, so that the payment safety is improved.
As shown in fig. 1 and 3, the near field payment method based on the data identification model of the present invention comprises the following steps:
and S11, the payee terminal generates the payee content according to the service scene identifier and the corresponding service scene template, uses the payee private key to digitally sign the service scene identifier and the payee content by adopting an asymmetric algorithm, and attaches an asymmetric public key of the payee. Asymmetric encryption algorithms include, but are not limited to, SM2 and RSA standard algorithms.
And step S12, the payee terminal combines the service scene identification, the payee content, the asymmetric public key of the payee and the digital signature of the payee together according to the data identification model to generate the payee data to be transmitted. The message format of the data to be transmitted may support a variety of data structures including, but not limited to, libsvm, JSON, ISO8583, and the like.
In step S13, after receiving the payment data, the payer terminal sequentially takes out the corresponding service scene identifier (Scenario), the payment Content (Content), the asymmetric Public Key (Public Key) of the payee, and the digital Signature (Signature) of the payee according to the data identification model, and verifies whether the result of the service scene identifier (Scenario) and the payment Content (Content) is consistent with the digital Signature (Signature) of the payee by using the asymmetric Public Key (Public Key) of the payee using an asymmetric algorithm. If the data are consistent, the security authentication is passed, namely that the received data are complete and are sourced from the unique payee. If the received collection data is inconsistent, the received collection data is incomplete or tampered, the verification cannot be passed, and the payment flow is ended.
And S14, the payer terminal automatically identifies and jumps to a corresponding payment scene flow according to the service scene identification, finishes payment, and loads the collection data to a corresponding module.
Specifically, the payer payment scenario process includes:
(1) Transfer scenario (i.e., transfer of collection account number): when receiving a service scene identifier (Scenario) corresponding to a transfer scene, namely, the identity of a payee is authenticated as a real-name individual, triggering a transfer flow:
a) The payer jumps to the private transfer page and the page will automatically display the content contained in the payee account number, bank, etc. in the payee content, which cannot be modified.
b) And the payer inputs the transfer amount, selects information such as a payment mode, a remittance account and the like, and completes subsequent remittance operation on the basis of meeting the requirements of a payment gateway.
(2) Small merchant/individual user supported small merchant checkout scenario (i.e., customer swipes merchant identity code): when the received service scene identifier (Scenario) corresponds to a small merchant collection scene, namely, the identity of the collection party is authenticated as a small merchant, the scene is triggered:
a) The payer jumps to the active payment page, which will display merchant information, i.e. the content contained in the payment content, which cannot be modified.
b) The payer inputs payment amount, selects payment mode, payment account and other information, actively sends the transaction to the bank/third party payment company gateway, and completes the subsequent transaction verification.
(3) The large merchant super-supports a code scanning gun or an intelligent POS machine money receiving scene (namely, a merchant scans a payment authorization code of a customer): when the received service scene identifier (Scenario) corresponds to a large-scale business super-receipt scene, namely the identity authentication of the payee is large-scale business super, triggering the scene:
a) The payer receives the data identification model and jumps to a payment authorization flow according to a service scene identification (Scenario);
b) The payment authorization information is combined according to the data identification model to generate data to be transmitted, and the data to be transmitted is transmitted back to a payee through a communication module; the service scene identifier (Scenario) is a large-scale business super-receipt scene, the collection Content (Content) is payment authorization information, the private Key of the payer adopts an asymmetric algorithm to carry out digital Signature (Signature), and an asymmetric Public Key (Public Key) of the payer is attached;
c) After receiving the payment authorization information of the user, the payee firstly uses the asymmetric public key of the payer to verify, and then sends the payment authorization information and the transaction information to the gateway of the bank/third party payment company to complete the transaction verification.
(4) Other scenarios (including but not limited to subway, bus batch authorization payment scenarios or other special scenarios) may define corresponding business process flows according to specific business requirements: and the users of the receiving party and the paying party finish the transfer or payment flow according to the requirements of the issuing card, the receiving party and the supervision mechanism.
The above embodiments are provided for illustrating the present invention and not for limiting the present invention, and various changes and modifications may be made by one skilled in the relevant art without departing from the spirit and scope of the present invention, and thus all equivalent technical solutions should be defined by the claims.

Claims (7)

1. A near field payment method based on a data identification model, the data identification model comprising: service scene identification, collection content, asymmetric public key of data sender and digital signature of data sender;
the near field payment method comprises the following steps:
the receiving party terminal generates receiving content according to the service scene identifier and the corresponding service scene template, uses the private key of the receiving party to digitally sign the service scene identifier and the receiving content by adopting an asymmetric algorithm, and attaches an asymmetric public key of the receiving party;
the method comprises the steps that a payee terminal combines a service scene identifier, payee content, an asymmetric public key of the payee and a digital signature of the payee according to a data identification model to generate payee data to be transmitted;
after receiving the collection data, the payer terminal adopts an asymmetric algorithm to verify whether the service scene identification and the collection content result are consistent with the digital signature of the payee by using an asymmetric public key of the payee; if the two types of information are consistent, the safety authentication is passed; if the payment flow is inconsistent, the payment flow cannot pass the verification, and the payment flow is ended;
the payer terminal automatically identifies and jumps to the corresponding payment scene flow according to the service scene identification to finish payment;
unified payment portal concept: the user can jump to all payment scenes by clicking the "pay" button, and the foreground interface has only one "pay" button for the payer.
2. The near field payment method based on the data recognition model of claim 1, wherein the service scene identification is one or more collection scene identifications authorized by the financial institution to the user according to the user identity information and the service requirement;
the collection content is as follows: the data fields to be transmitted defined according to the business scene comprise merchant information, order information, security and authentication information, payment authorization information, electronic payment instructions and digital currency information;
the asymmetric public key of the data sender and the digital signature of the data sender are as follows: a unique public-private key pair assigned to the user by the financial institution; the data sender signs the data by using the private key, and the data receiver performs identity authentication and consistency check of the data and the signature by using the asymmetric public key of the data sender after receiving the data.
3. The near field payment method based on the data identification model of claim 1, wherein the service scenario comprises:
transfer scenario: both sides of the transfer are natural persons authenticated by real names;
small merchant collection scene: the small merchant or individual user sends the money requesting data, and the customer pays online;
large-scale merchant super-receipts scene: the merchant sends the money requesting data through the mobile device or the intelligent POS machine, the customer device receives and returns the authorization information, and the merchant requests money in a networking way;
public transportation merchants support customer authorization scenarios: the machine supports authenticating passengers, obtaining payment authorization, and delaying bulk deductions.
4. A near field payment method based on a data identification model as claimed in claim 3, wherein the payment scenario flow comprises:
when receiving that the service scene identifier corresponds to the transfer scene, triggering:
the payer jumps to the private transfer page, and the page automatically displays the content in the collection content;
the payer inputs the transfer amount, selects payment information, and completes subsequent remittance operation on the basis of meeting the requirements of a payment gateway;
when the received service scene identifier corresponds to a small merchant collection scene, triggering:
the payer jumps to the active payment page, which will contain the content in the content of the payment;
the payer inputs payment amount, selects payment information, actively sends the transaction to a bank/third party payment company gateway, and completes subsequent transaction verification;
when the received service scene identifier corresponds to a large-scale business super-receipt scene, triggering:
the payment party combines the payment authorization information according to the data identification model to generate data to be transmitted, and the data are transmitted back to the payee through the communication module; the service scene is identified as a large-scale business super-receipt scene, the receipt content is payment authorization information, a private key of a payer is used for carrying out digital signature by adopting an asymmetric algorithm, and an asymmetric public key of the payer is attached;
after receiving payment authorization information of a user, a payee firstly uses the received asymmetric public key of the payer to check, and then sends the payment authorization information and transaction information to a bank/third party payment company gateway together to finish transaction verification.
5. The near field payment method based on the data recognition model of claim 4, wherein when the received service scenario identification corresponds to a customer authorization scenario, the users of both the receiving and payment parties complete the transfer or payment process according to the requirements of the card issuing, the receipt and the regulatory agency.
6. The near field payment method based on the data identification model of claim 1, wherein near field communication is performed between the payee terminal and the payer terminal through NFC, bluetooth or WiFi.
7. The near field payment method based on a data identification model according to claim 1, wherein when a scene of information needs to be transmitted back to a payee by a payer terminal, the payer terminal signs a service scene identifier and a payee content representing the reply content using a payer private key, attaches an asymmetric public key of the payer, and then combines the two together according to the data identification model to generate data to be transmitted.
CN201910998699.8A 2019-10-21 2019-10-21 Near field payment method based on data identification model Active CN110766397B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910998699.8A CN110766397B (en) 2019-10-21 2019-10-21 Near field payment method based on data identification model

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910998699.8A CN110766397B (en) 2019-10-21 2019-10-21 Near field payment method based on data identification model

Publications (2)

Publication Number Publication Date
CN110766397A CN110766397A (en) 2020-02-07
CN110766397B true CN110766397B (en) 2023-07-25

Family

ID=69331191

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910998699.8A Active CN110766397B (en) 2019-10-21 2019-10-21 Near field payment method based on data identification model

Country Status (1)

Country Link
CN (1) CN110766397B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112712354B (en) * 2020-06-15 2024-12-17 深圳市文鼎创数据科技有限公司 Interaction method of digital currency wallet and digital currency server
CN113393242B (en) * 2021-04-27 2022-11-01 连通(杭州)技术服务有限公司 Method and equipment for safe off-line electronic payment of token model payers
CN113115228B (en) * 2021-05-20 2023-01-24 中国银联股份有限公司 A service processing method and device based on ultra-wideband
CN118552194B (en) * 2024-07-25 2024-11-29 支付宝(杭州)信息技术有限公司 Near field communication service processing method, device, equipment and cash register equipment

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104021472A (en) * 2014-05-30 2014-09-03 中国工商银行股份有限公司 Identity verification method and system
CN107784499A (en) * 2016-08-31 2018-03-09 北京银联金卡科技有限公司 The safety payment system and method for near-field communication mobile terminal

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07271865A (en) * 1994-04-01 1995-10-20 Mitsubishi Corp Database copyright management method
US9892390B2 (en) * 2007-12-12 2018-02-13 Microsoft Technology Licensing, Llc Digital content packaging, licensing and consumption
CN101567109B (en) * 2009-06-03 2012-01-04 普天信息技术研究院有限公司 Device integrating payment and gathering functions, system and trade method
US10176477B2 (en) * 2010-11-16 2019-01-08 Mastercard International Incorporated Methods and systems for universal payment account translation
KR20150022754A (en) * 2012-03-30 2015-03-04 아이피 페이오베이션 피티와이 엘티디 Payment apparatus and method
US20140201086A1 (en) * 2012-09-02 2014-07-17 Mpayme Ltd. Method and system for reversed near field contact electronic transaction
US20150120536A1 (en) * 2013-10-31 2015-04-30 Albert Talker Electronic payment and authentication system
US10055725B2 (en) * 2014-08-13 2018-08-21 Google Llc Simple in-store payments
CN106997527A (en) * 2016-01-25 2017-08-01 阿里巴巴集团控股有限公司 Credit payment method and device based on mobile terminal P2P
CN107230051B (en) * 2016-03-25 2021-06-22 中国人民银行数字货币研究所 Payment method and payment system of digital currency
CN107230055B (en) * 2016-03-25 2020-12-22 中国人民银行数字货币研究所 Method and system for paying digital currency
CN106096947B (en) * 2016-06-08 2019-10-29 广东工业大学 The half off-line anonymous method of payment based on NFC
CN106327186A (en) * 2016-08-31 2017-01-11 中城智慧科技有限公司 Offline payment method based on NFC
CN108449332A (en) * 2018-03-09 2018-08-24 中山大学 A Design Method of Lightweight Mobile Payment Protocol Based on Dual Gateways
CN108876353A (en) * 2018-05-24 2018-11-23 深圳前海益链网络科技有限公司 A kind of method of payment of the block chain number Token based on near-field communication
CN109064156A (en) * 2018-06-29 2018-12-21 拉卡拉汇积天下技术服务(北京)有限公司 Method of payment, device, electronic equipment and storage medium

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104021472A (en) * 2014-05-30 2014-09-03 中国工商银行股份有限公司 Identity verification method and system
CN107784499A (en) * 2016-08-31 2018-03-09 北京银联金卡科技有限公司 The safety payment system and method for near-field communication mobile terminal

Also Published As

Publication number Publication date
CN110766397A (en) 2020-02-07

Similar Documents

Publication Publication Date Title
US11004083B2 (en) System and method for authorizing direct debit transactions
US20180253714A1 (en) Authentication and payment system and method using mobile communication terminal
CN110766397B (en) Near field payment method based on data identification model
CN104766205B (en) A kind of method of mobile payment and device
CN104050565B (en) Intelligent payment system and its mobile terminal based on PBOC payment network
US20140046788A1 (en) Payment method and system
CN111355776A (en) Service providing method and device for carrying out encryption signature on digital currency application program and mobile terminal
US20120191556A1 (en) Systems and methods for virtual mobile transaction
US11062290B2 (en) Secure real-time transactions
US20180158042A1 (en) Secure real-time transactions
JP2014513825A5 (en)
CN107194695A (en) Transaction code is generated and end of scan, transaction code generation and method of commerce
WO2016088087A1 (en) Third party access to a financial account
KR20140095260A (en) Hybrid payment system and method in mobile terminal based on QR member
EP2584514A1 (en) Cloud credit card transaction system and transaction method thereof
US10963856B2 (en) Secure real-time transactions
US10970695B2 (en) Secure real-time transactions
CN104200365A (en) Writing and paying method for electronic check
KR20120100283A (en) System and method for electronic payment
US11037122B2 (en) Secure real-time transactions
KR20110107311A (en) Payment service system and method using mobile network, and computer program therefor
KR20120076692A (en) Method of managing payment channel
US20170323287A1 (en) System and method for providing payment service
US11037121B2 (en) Secure real-time transactions
WO2015196545A1 (en) Electronic card application method and apparatus

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB03 Change of inventor or designer information

Inventor after: Huang Shuang

Inventor after: Wang Wenyi

Inventor before: Huang Shuang

Inventor before: Wang Wenyi

Inventor before: Xue Musong

Inventor before: Zhu Zhi

CB03 Change of inventor or designer information
GR01 Patent grant
GR01 Patent grant