WO2019029455A1 - 一种支付方法、装置及其设备 - Google Patents

一种支付方法、装置及其设备 Download PDF

Info

Publication number
WO2019029455A1
WO2019029455A1 PCT/CN2018/098660 CN2018098660W WO2019029455A1 WO 2019029455 A1 WO2019029455 A1 WO 2019029455A1 CN 2018098660 W CN2018098660 W CN 2018098660W WO 2019029455 A1 WO2019029455 A1 WO 2019029455A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
code
authorization
license information
Prior art date
Application number
PCT/CN2018/098660
Other languages
English (en)
French (fr)
Inventor
张华程
王维
王文治
Original Assignee
阿里巴巴集团控股有限公司
张华程
王维
王文治
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 阿里巴巴集团控股有限公司, 张华程, 王维, 王文治 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2019029455A1 publication Critical patent/WO2019029455A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the present specification relates to the field of computer technology, and in particular, to a payment method, device, and device thereof.
  • a payment method in which User A provides User B's DOI (eg, a two-dimensional code) to the merchant for payment.
  • DOI eg, a two-dimensional code
  • younger users eg, children
  • they use their parent's QR code to consume at the merchant.
  • the embodiment of the present specification provides a payment method, device and device thereof for solving the following problem: to provide a more convenient payment method.
  • the embodiment of the present specification provides a payment method, including:
  • a payment method including:
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • a payment method including:
  • the payment code is obtained according to the DOI of the second user.
  • a payment device including:
  • the receiving module receives an authorization request sent by the first user, where the authorization request carries the license information
  • Determining a module determining a second user corresponding to the authorization request
  • an authorization module authorizing the second user according to the authorization permission information.
  • a payment device including:
  • Generating a module generating a DOI according to the payment encoding parameter, so as to display to the merchant for payment;
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • a payment device including:
  • Receiving module receiving payment code and transaction information sent by the merchant
  • a payment module according to the license information and the transaction information, to make a payment to the merchant by the first user;
  • the payment code is obtained according to the DOI provided by the second user.
  • the embodiment of the present specification further provides a payment device, including:
  • a communication interface receiving an authorization request sent by the first user, where the authorization request carries the license information
  • Memory storing a payment authorization program
  • the processor listens for the authorization request, invokes the payment authorization program in the memory, and executes:
  • a payment device which, after having accepted the authorization of the first user, includes:
  • the processor calls the DOI generator in the memory and executes:
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • a payment device including:
  • the processor listens for the payment code and transaction information, calls the payment program in the memory, and executes:
  • the payment code is obtained according to the DOI of the second user.
  • an embodiment of the present specification further provides a non-volatile computer storage medium storing computer executable instructions, the computer executable instructions being set as:
  • an embodiment of the present specification further provides another non-volatile computer storage medium storing computer executable instructions, the computer executable instructions being set as:
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • embodiments of the present specification further provide another non-volatile computer storage medium storing computer executable instructions, the computer executable instructions being set as:
  • the payment code is obtained according to the DOI of the second user.
  • the first user authorizes the license information by authorizing the second user.
  • the second user generates a DOI (for example, a two-dimensional code) corresponding to the license information before the payment is required, and the merchant obtains the payment code after scanning the DOI, and sends the payment code corresponding to the DOI to the server, and the server decodes Obtain the corresponding license information, and deduct the account from the first user to the merchant after determining that the transaction information meets the authorized scope.
  • DOI for example, a two-dimensional code
  • the first user authorizes the second user
  • the server stores the license information
  • the second user generates the DOI according to the license information when needed
  • the merchant scans the DOI to obtain the corresponding code, and sends the corresponding code to the server.
  • the final transaction information (usually including the consumption information of the second user) will be sent to the first user and the second user at the same time, which facilitates the first user to supervise the consumption status of the second user and adjust the authorization range in time.
  • FIG. 1 is a schematic structural diagram of an embodiment of the present disclosure
  • FIG. 2 is a schematic flowchart of a partial payment method according to an embodiment of the present disclosure
  • FIG. 3 is a schematic flowchart of a partial payment method according to an embodiment of the present disclosure.
  • FIG. 4 is a schematic flowchart of a partial payment method according to an embodiment of the present disclosure.
  • FIG. 5 is a schematic diagram of a specific payment process provided by an embodiment of the present specification.
  • Figure 6 is a schematic diagram of an actual application provided by an embodiment of the present specification.
  • FIG. 7 is a schematic structural diagram of a partial object according to an embodiment of the present disclosure.
  • FIG. 8 is a schematic structural diagram of a payment apparatus according to an embodiment of the present disclosure.
  • FIG. 9 is a schematic structural diagram of another payment apparatus according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic structural diagram of another payment apparatus according to an embodiment of the present disclosure.
  • first user and second user are used to distinguish different users.
  • the first user refers to the party that provides the authorization in the solution (for example, the parent); the second user refers to the party that accepts the authorization in the solution (for example, a young user).
  • the first user can simultaneously correspond to multiple second users, that is, the first user can authorize multiple second users at the same time, and each license information is independent of each other and does not affect each other.
  • the visualized payment identifier used by the scan code payment scenario may be generated by the payment code.
  • the payment code may be a character string (where the payment code may be generated according to the license information, the related content will be described in detail below), and the DOI (Digital Object Unique Identifier) The form is shown (the DOI here is the payment identifier for the above visualization).
  • the DOI may include a two-dimensional code such as PDF417, QR Code, Code 49, Code 16K, Code One, etc., and such as EAN code, 39 code, cross 25 code, UPC code, 128 code, 93 code, ISBN code, and Kurd
  • EAN code 39 code
  • cross 25 code UPC code
  • UPC code 128 code
  • 93 code 93 code
  • ISBN code ISBN code
  • Kurd The one-dimensional code of the barcode and the like, and the character code, etc., the merchant scans the DOI to obtain the corresponding payment code.
  • the data processing method may adopt an architecture as shown in FIG. 1 , in which the server is associated with a client, and is capable of performing operations related to authorization and payment, including Not limited to request forwarding, message storage/sending, message/code verification, payment encoding parameter generation and delivery, decoding, payment, and the like.
  • the payment method provided by the embodiment of the present specification is described in detail below based on the architecture shown in FIG. 1.
  • the payment method includes three aspects: a payment authorization process, a DOI generation process, and a payment process, and the payment authorization process specifically includes the following steps. ,as shown in picture 2:
  • Step S201 Receive an authorization request sent by the first user, where the authorization request carries the license permission information.
  • the authorization request clarifies a specific authorization object thereof, and the authorization permission information may include an authorization time, an authorization party ID, and an authorized party ID (ie, a first user ID and a second user ID), an authorization license information modification time, and an authorization amount. Scope, authorized consumption type, authorization period, etc.
  • Step S203 determining a second user corresponding to the authorization request.
  • the authorization request carries relevant information of the authorized object (such as a user ID, an account name, and the like), and the server determines, by using related information in the authorization request, the authorization request.
  • relevant information of the authorized object such as a user ID, an account name, and the like
  • the server determines, by using related information in the authorization request, the authorization request. The second user.
  • the authorization request is forwarded to the second user, and when the second user receives the authorization, the return receipt is sent to the server, and the server receives the receipt to confirm that the second user has received the authorization. .
  • Step S205 authorizing the second user according to the authorization permission information.
  • the second user and license information is stored in a particular data table to identify that the second user has been authorized.
  • the method may include the following steps: generating an authorization code corresponding to the license information, establishing a correspondence between the authorization code, the license information, and the second user, and storing the correspondence.
  • the license information usually includes a plurality of pieces.
  • an authorization code corresponding to the license information is generated (for example, based on the license information, an MD5 operation is performed to generate a corresponding operation value.
  • the authorization code establish a certain data structure (such as a key-value pair) between the license information, the authorization code, and the second user. If the license information needs to be queried, only the authorization code needs to be found. Just fine.
  • the first user may also modify the license information, for example, may include expanding, freezing, setting/modifying the limited period, and the like.
  • the server After determining that the second user has accepted the authorization and storing the authorization information, when the second user needs to generate the DOI, the server needs to generate the payment coding parameter and send it to the second user. Specifically, the following implementation manner may be included. :
  • the payment encoding parameter is described to the second user.
  • generating the payment encoding parameter according to the license information includes:
  • the payment coding parameter is generated according to the authorization code corresponding to the authorization permission information, for example, according to the authorization code: 28170000100002XXXXX01 and the device information of the second user, etc.
  • the algorithm generates the payment coding parameter by using an algorithm: 973cfc1bc2686bc5040e7c8cfbfbbbcc3f100. This parameter is used by the second user to generate a payment code.
  • the merchant When receiving the payment code of the merchant, it may perform decoding to obtain its corresponding authorization code, and then obtain corresponding license information.
  • the DOI generation process is as shown in FIG. 3, and includes the following steps:
  • Step S301 the payment encoding parameter corresponding to the authorization permission information is obtained, where the authorization permission information is carried by the authorization request of the first user, and the payment coding parameter is generated by the server according to the authorization permission information.
  • the second user needs to send the payment coding parameter to the server for the first time to obtain the payment coding parameter.
  • the device may carry its own device feature, and the server verifies the device feature to avoid Mistake or misappropriation.
  • the payment encoding parameter may be generated based on the license information or generated according to the authorization code corresponding to the license information.
  • the foregoing method may further include: storing the payment encoding parameter to the local;
  • obtaining the payment encoding parameter corresponding to the license information may include: acquiring the locally stored payment encoding parameter, that is, when the second user cannot connect to the server, generating the DOI by using the locally stored payment encoding parameter, and adapting A wider range.
  • Step S303 generating a DOI according to the payment encoding parameter, so as to display to the merchant for payment.
  • the DOI is generated according to the payment coding parameter, and the following may be adopted: generating a payment code corresponding to the payment coding parameter, and generating a DOI according to the payment code.
  • the payment code genCode (second user ID, payment coding parameter, offset) may be generated in the following manner, wherein the offset may be Including time and so on, so that the generated payment code is dynamic, and then the DOI is also dynamic, try to avoid stealing.
  • the payment encoding parameter is generated according to the authorization code
  • the payment encoding is generated according to the payment encoding parameter
  • a specific algorithm may be used to implement the entire process reversible. That is, the payment encoding is decoded to obtain a payment encoding parameter, and the payment encoding parameter is decoded to obtain an authorization code for generating the same.
  • the prior art is mature in this respect, and is not described herein.
  • the merchant Based on the consumption information of the second user, the merchant generates transaction information.
  • the second user generates a DOI and presents it to the merchant.
  • the merchant scans the DOI to obtain its corresponding payment code.
  • the payment process provided by the embodiment of the present specification, as shown in FIG. 4, includes:
  • Step S401 receiving payment codes and transaction information sent by the merchant.
  • the payment code is obtained according to the DOI of the second user
  • the transaction information is obtained according to the consumption information of the second user.
  • Step S403 obtaining corresponding authorization permission information according to the payment code.
  • the following implementation manner may be adopted: decoding the payment code, acquiring an authorization code, and acquiring the authorization permission information corresponding to the authorization code; or decoding the payment code to obtain a payment coding parameter, and obtaining the authorization according to the payment coding parameter. Encoding, and then obtaining the license information corresponding to the authorization code.
  • Step S405 performing payment from the first user to the merchant according to the authorization permission information and the transaction information.
  • some pre-determination conditions may be included before payment to ensure that the payment process is safer and more reasonable, as shown in FIG. 5. For example, judging whether the merchant signs the contract and determining whether the two-dimensional code is valid (whether the decoding is successful, whether the decoded value conforms to the rule, whether the decoding obtains the authorized authorization code, whether it is within the validity period, and whether it is a valid authorization code ( Unfrozen, not lost, etc.)), determine whether the amount of consumption is within the license, etc., for example, by setting the validity period of the QR code to 30S from the generation time, the two-dimensional code can be effectively prevented from being maliciously stolen. It is already very common in the prior art and will not be described here.
  • the foregoing payment method may further include:
  • the first user can also obtain the consumption situation of the second user in time, which is beneficial for the first user to supervise the consumption of the second user, adjust the authorization scope or the amount in time, and the like.
  • Step S601 the first user issues an authorization request, where the authorization request carries the license information
  • Step S603 the server confirms the second user, and forwards the authorization request to the second user.
  • Step S605 the second user accepts the authorization, and returns the receipt to the server;
  • Step S607 the server generates an authorization code corresponding to the license information, and stores the license information and the authorization code.
  • Step S609 the second user uploads the feature of the device, and requests the server to deliver the payment coding parameter.
  • Step S611 the server confirms the second user, and generates a payment encoding parameter according to the authorization code and sends the payment encoding parameter to the second user.
  • Step S613 the second user generates a payment code according to the payment encoding parameter, thereby generating a DOI;
  • Step S615 the second user displays the DOI to the merchant
  • Step S617 the merchant scans the DOI to obtain a payment code, and uploads the code and transaction information to the server;
  • Step S619 the server decodes the code to obtain an authorization code.
  • Step S621 determining whether the authorization code is valid, and if valid, obtaining the corresponding authorization permission information
  • Step S623 deducting money from the first user to the merchant according to the license permission information and the transaction information.
  • the first user authorizes the second user
  • the server stores the license information
  • the second user generates the DOI according to the license information when needed
  • the merchant scans the identifier to obtain the corresponding payment code, and sends the corresponding payment code to the service.
  • the terminal performs decoding to obtain corresponding license information, and then performs payment from the first user to the merchant. Therefore, within the scope of authorization, the second user consumes, the first user pays, realizes the funds of one account using one account; meanwhile, the second user who cannot use the payment software smoothly (for example, a young user, an elderly user who is not familiar with mobile payment) Or users with limited assets/permissions) to improve the user experience.
  • the final transaction information (usually including the consumption information of the second user) will be sent to the first user and the second user at the same time, which facilitates the first user to supervise the consumption status of the second user and adjust the authorization range in time.
  • the present specification also provides a payment device. As shown in FIG. 8, the device includes:
  • the receiving module 801 receives an authorization request sent by the first user, where the authorization request carries the license information;
  • the determining module 803 is configured to determine a second user corresponding to the authorization request
  • the authorization module 805 authorizes the second user according to the authorization permission information.
  • the authorization module 805 generates an authorization code corresponding to the license information, and establishes a correspondence between the authorization code, the license information, and the second user, and stores the correspondence.
  • the receiving module 801 is further configured to receive a payment encoding parameter request of the second user, where the apparatus further includes a generating module 807, and the payment encoding parameter is generated according to the authorization permission information, where the payment encoding parameter is used for The second user generates a payment code, and the sending module 803 is further configured to send the payment encoding parameter to the second user.
  • the generating module 807 is configured to obtain an authorization code corresponding to the authorization permission information, and generate the payment coding parameter according to the authorization code.
  • the present specification also provides another payment device, as shown in FIG. 9, comprising:
  • the obtaining module 901 is configured to obtain a payment encoding parameter corresponding to the license information.
  • the generating module 903 is configured to generate a DOI according to the payment encoding parameter, so as to display to the merchant for payment;
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • the generating module 903 generates a payment code corresponding to the payment coding parameter, and generates a DOI according to the payment code.
  • the storage module 905 is further configured to: store the payment encoding parameter to the local; the obtaining module 901 is further configured to obtain the locally stored payment encoding parameter.
  • the present specification also provides another payment device, as shown in FIG. 10, including:
  • the receiving module 1001 receives the payment code and transaction information sent by the merchant;
  • the obtaining module 1003 obtains, according to the payment code, the corresponding license information
  • the payment module 1005 performs payment to the merchant through the first user;
  • the payment code is obtained according to the DOI of the second user.
  • the obtaining module 1003 is configured to decode the payment code, obtain an authorization code, and obtain authorization permission information corresponding to the authorization code.
  • the apparatus further includes a sending module 1007, and transmitting the transaction information to the first user and the second user.
  • a payment device including:
  • a communication interface receiving an authorization request sent by the first user, where the authorization request carries the license information
  • Memory storing a payment authorization program
  • the processor listens for the authorization request, invokes the payment authorization program in the memory, and executes:
  • this specification also provides another payment device, after having accepted the authorization of the first user, including:
  • the processor calls the DOI generator in the memory and executes:
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • this specification also provides another payment device, including:
  • the processor listens for the payment code and transaction information, calls the payment program in the memory, and executes:
  • an embodiment of the present specification further provides a non-volatile computer storage medium storing computer executable instructions, the computer executable instructions being set as:
  • an embodiment of the present specification further provides another non-volatile computer storage medium storing computer executable instructions, the computer executable instructions being set as:
  • the license information is sent by the first user to the server, and the payment encoding parameter is generated by the server according to the license information.
  • an embodiment of the present specification further provides another non-volatile computer storage medium storing computer executable instructions, the computer executable instructions being set as:
  • the payment code is obtained according to the DOI provided by the second user.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • the controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor.
  • computer readable program code eg, software or firmware
  • examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding.
  • Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component.
  • a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer.
  • the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage computer readable media, such as modulated data signal numbers and carrier waves.
  • embodiments of the present specification can be provided as a method, system, or computer program product.
  • embodiments of the present specification can take the form of an entirely hardware embodiment, an entirely software embodiment or a combination of software and hardware aspects.
  • embodiments of the present specification can take the form of a computer program product embodied on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer usable program code embodied therein. .
  • Embodiments of the present description can be described in the general context of computer-executable instructions executed by a computer, such as a program module.
  • program modules include routines, programs, objects, components, data structures, and the like that perform particular transactions or implement particular abstract data types.
  • Embodiments of the present specification may also be practiced in distributed computing environments where transactions are performed by remote processing devices that are connected through a communication network.
  • program modules can be located in both local and remote computer storage media including storage devices.

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)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种支付方法、装置及其设备。第一用户通过向第二用户授权，服务端存储授权许可信息。第二用户在需要进行支付之前，生成一个和授权许可信息对应的DOI(例如二维码)，商户扫描该DOI以后获得支付编码，把DOI对应的支付编码发送至服务端，服务端进行解码以获取对应的授权许可信息，在确定交易信息符合授权范围之后，从第一用户的账户扣款至商户。

Description

一种支付方法、装置及其设备 技术领域
本说明书涉及计算机技术领域，尤其涉及一种支付方法、装置及其设备。
背景技术
随着技术发展，扫码支付方式的应用越来越广。
在某些场景中，存在如下支付方式：用户A将用户B的DOI(例如二维码)，提供给商户以进行支付。例如，低龄用户(如：儿童)由于年龄限制，无法获得支付应用中的扫码服务，故使用其家长的二维码在商户进行消费。
基于此，我们需要一种更方便的支付方法。
发明内容
本说明书实施例提供一种支付方法、装置及其设备，用于解决如下问题：以提供一种更方便的支付方法。
基于此，本说明书实施例提供一种支付方法，包括：
接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
确定所述授权请求对应的第二用户；
根据所述授权许可信息对所述第二用户授权。
同时，还提供一种支付方法，包括：
获取授权许可信息所对应的支付编码参数；
根据所述支付编码参数生成DOI，以便展示给商户进行支付；
其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成。
同时，还提供一种支付方法，包括：
接收商户所发送的支付编码和交易信息；
根据所述支付编码，获取其对应的授权许可信息；
根据所述授权许可信息和交易信息，通过第一用户向商户进行支付；
其中，所述支付编码是根据第二用户的DOI所得到的。
对应的，本说明书实施例提供一种支付装置，包括：
接收模块，接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
确定模块，确定所述授权请求对应的第二用户；
授权模块，根据所述授权许可信息对所述第二用户授权。
同时，还提供一种支付装置，包括：
获取模块，获取授权许可信息所对应的支付编码参数；
生成模块，根据所述支付编码参数生成DOI，以便展示给商户进行支付；
其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成。
同时，还提供一种支付装置，包括：
接收模块，接收商户所发送的支付编码和交易信息；
获取模块，根据所述支付编码，获取其对应的授权许可信息；
支付模块，根据所述授权许可信息和交易信息，通过第一用户向商户进行支付；
其中，所述支付编码是根据第二用户提供的DOI所得到的。
对应的，本说明书实施例还提供一种支付设备，包括：
通讯接口，接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
存储器，存储支付授权程序；
处理器，监听授权请求，调用存储器中的支付授权程序，并执行：
确定所述授权请求对应的第二用户；
根据所述授权许可信息对所述第二用户授权。
同时，还提供一种支付设备，在已接受第一用户的授权后，包括：
存储器，存储DOI生成程序；
处理器，调用存储器中的DOI生成程序，并执行：
获取授权许可信息所对应的支付编码参数；
根据所述支付编码参数生成DOI，以便展示给商户进行支付；
其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成。
同时，还提供一种支付设备，包括：
通讯接口，接收商户所发送的支付编码和交易信息，
存储器，存储支付程序；
处理器，监听支付编码和交易信息，调用存储器中的支付程序，并执行：
根据所述支付编码，获取其对应的授权许可信息；
根据所述授权许可信息和交易信息，从第一用户向商户进行支付；
其中，所述支付编码是根据第二用户的DOI所得到的。
对应的，本说明书的实施例还提供一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
监听第一用户的授权请求，并执行：
确定所述授权请求对应的第二用户；
根据所述授权许可信息对所述第二用户授权。
对应的，本说明书的实施例还提供另一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
获取授权许可信息所对应的支付编码参数；
根据所述支付编码参数生成DOI，以便展示给商户进行支付；
其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成。
对应的，本说明书的实施例还提供另一种非易失性计算机存储介质，存储 有计算机可执行指令，所述计算机可执行指令设置为：
监听支付编码和交易信息，并执行：
根据所述支付编码，获取其对应的授权许可信息；
根据所述授权许可信息和交易信息，通过第一用户向商户进行支付；
其中，所述支付编码是根据第二用户的DOI所得到的。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：
第一用户通过向第二用户授权，服务端存储授权许可信息。第二用户在需要进行支付之前，生成一个和授权许可信息对应的DOI(例如二维码)，商户扫描该DOI以后获得支付编码，把DOI对应的支付编码发送至服务端，服务端进行解码以获取对应的授权许可信息，在确定交易信息符合授权范围之后，从第一用户的账户扣款至商户。
本说明书实施例中，通过第一用户向第二用户授权，服务端存储授权许可信息，第二用户在需要时根据授权许可信息生成DOI，商户扫描该DOI获得对应编码，并发送至服务端进行解码以获得对应的授权许可信息，进而从第一用户向商户进行支付。从而在授权范围内，第二用户消费，第一用户支付，实现多个账户使用一个账户的资金；同时，对于不能顺利使用支付软件的第二用户(例如低龄用户、不熟悉移动支付的高龄用户或资产/权限受限的用户)，提高了用户体验。此外，最终的交易信息(通常包含第二用户的消费信息)将会同时发送至第一用户和第二用户，有利于第一用户监管第二用户的消费状态，以及时调整授权范围。
附图说明
图1为本说明书实施例提供的架构示意图；
图2为本说明书实施例提供的部分支付方法流程示意图；
图3为本说明书实施例提供的部分支付方法流程示意图；
图4为本说明书实施例提供的部分支付方法流程示意图；
图5为本说明书实施例提供的具体支付过程的示意图；
图6为本说明书实施例提供的实际应用示意图；
图7为本说明书实施例提供的部分对象逻辑结构示意图；
图8为本说明书实施例提供的一种支付装置结构示意图；
图9为本说明书实施例提供的另一种支付装置结构示意图；
图10为本说明书实施例提供的另一种支付装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
基于前述内容，在本方案中，使用“第一用户”和“第二用户”来区分不同的用户。其中，第一用户指在本方案中提供授权的一方(如，家长)；第二用户指在本方案中接受授权的一方(如，低龄用户)。所述第一用户可同时对应多个第二用户，即，第一用户可同时对多个第二用户进行授权，各授权许可信息之间相互独立，互不影响。
此外，在本说明书实施例中，扫码支付场景所使用的可视化的支付标识可由支付编码所生成。具体而言，所述支付编码可以是一种字符串(这里的支付编码可根据授权许可信息所生成，有关内容将在下文中进行详细说明)，并以DOI(Digital Object Unique Identifier，数字对象唯一标识)的形式表现出来(这里的DOI便是上述可视化的支付标识)。DOI可包括诸如PDF417、QR Code、Code 49、Code 16K、Code One等格式的二维码，以及诸如EAN码、39码、交叉25码、UPC码、128码、93码、ISBN码及库德巴码等格式的一维码、 以及字符码等等，商户扫描该DOI即可得到其对应的支付编码。
在本说明书的实施例中，所述的数据处理方法可采用如图1所示的架构，在所述架构中，服务端与客户端相关联，能够进行授权和支付方面相关的操作，包括但不限于请求转发、消息存储/发送、消息/代码验证、支付编码参数生成和下发、解码、款项支付等等。
下面将基于如图1所示的架构，详细说明本说明书的实施例提供的支付方法，该支付方法包括三个方面：支付授权过程、DOI生成过程和支付过程，该支付授权过程具体包括以下步骤，如图2所示：
步骤S201，接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息。
所述授权请求明确其具体的授权对象，所述授权许可信息可包括授权时间、授权方ID和被授权方ID(即第一用户ID和第二用户ID)、授权许可信息修改时间、授权金额范围、授权消费类型、授权期限等等。
步骤S203，确定所述授权请求对应的第二用户。
作为本说明书实施例中的一种可行方式，所述的授权请求中携带有授权对象的相关信息(如：用户ID、账户名等等)，服务端通过授权请求中的相关信息确定授权请求对应的第二用户。
作为本说明书实施例中的另一种可行方式，转发授权请求至第二用户，在第二用户接收授权的同时，返回回执至服务端，服务端接收到回执即可确认第二用户已经接收授权。
步骤S205，根据所述授权许可信息对所述第二用户授权。
即，将所述第二用户和授权许可信息存储至特定的数据表格中，以标识第二用户已经被授权。具体而言，可包括如下实施方式：生成授权许可信息所对应的授权编码，建立所述授权编码、授权许可信息和第二用户之间的对应关系，并存储。
如前所述，授权许可信息通常包括多项，为方便进行统一管理和查找，生 成一个和授权许可信息对应的授权编码(例如：基于所述授权许可信息，进行MD5运算，生成相应的运算值，作为授权编码)，建立授权许可信息、授权编码和第二用户三者之间的某种数据结构(例如键值对的形式)，若需要查询该授权许可信息，只需查找到该授权编码即可。
在实际应用中，第一用户还可以针对该授权许可信息进行修改，例如可包括对该授权金额进行扩充、冻结、设置/修改有限期等等。
在确定第二用户已经接受授权，并存储了授权许可信息后，在第二用户需要生成DOI的时候，需要服务端生成支付编码参数下发至第二用户，具体而言，可包括如下实施方式：
接收第二用户的获取支付编码参数请求，并确定第二用户所对应的授权许可信息，根据授权许可信息生成所述支付编码参数，所述支付编码参数用于第二用户生成支付编码，发送所述支付编码参数至第二用户。
具体而言，根据授权许可信息生成所述支付编码参数，包括：
获取授权许可信息对应的授权编码，根据所述授权编码生成所述支付编码参数。即，根据授权许可信息对应的授权编码，生成支付编码参数，例如：根据授权编码：28170000100002XXXXX01和第二用户的设备信息等，通过某种算法，计算生成支付编码参数：973cfc1bc2686bc5040e7c8cfcdf9b612cc3f100。该参数用于第二用户生成支付编码。
在接收到商户的支付编码时可以进行解码以获得其对应的授权编码，进而获取对应的授权许可信息。
在已接受第一用户的授权后，第二用户进行消费时，需生成DOI以进行支付，该DOI生成过程如图3所示，包括如下步骤：
步骤S301，获取授权许可信息所对应的支付编码参数，其中，所述授权许可信息是第一用户的授权请求所携带的，所述支付编码参数是服务端根据授权许可信息生成的。
在实际应用中，第二用户首次获取支付编码参数需要对服务器请求支付编 码参数下发，例如，发送支付编码参数请求时可携带自身的设备特征，服务端通过对该设备特征进行验证，以避免误发或者盗用。如前所述，支付编码参数可根据授权许可信息生成，或者根据授权许可信息对应的授权编码生成。
在首次获取服务器支付编码参数之后，作为本申请的另一种可实施方式，前述方法还可包括：存储所述支付编码参数至本地；
进而，获取授权许可信息所对应的支付编码参数，可包括：获取本地所存储的支付编码参数，即，在第二用户无法连接至服务端时，使用存储于本地的支付编码参数生成DOI，适应范围更广。
步骤S303，根据所述支付编码参数生成DOI，以便展示给商户进行支付。
具体来说，根据所述支付编码参数生成DOI，可采用如下方式：生成支付编码参数所对应的支付编码，根据所述支付编码生成DOI。
在根据支付编码参数生成支付编码时，可以在其中加入一些其他变量，例如，可采用如下方式生成支付编码＝genCode(第二用户ID,支付编码参数,偏移量)，其中的偏移量可包括时间等等，从而生成的支付编码是动态的，进而DOI也是动态的，尽量避免盗刷。
需要说明的是，在前述的根据授权编码生成支付编码参数，以及根据支付编码参数生成支付编码时，可采用特定的算法实现整个过程可逆。即，对支付编码进行解码可得到支付编码参数，对支付编码参数解码得到生成它的授权编码，现有技术在这方面已经很成熟，此处不做赘述。
根据第二用户的消费信息，商户生成交易信息。第二用户生成DOI，并展示给商户。商户扫描该DOI，得到其对应的支付编码，进而，本说明书实施例所提供的支付过程，如图4所示，包括：
步骤S401，接收商户所发送的支付编码和交易信息。其中，所述支付编码是根据第二用户的DOI所得到的，所述交易信息是根据第二用户的消费信息所得到的。
步骤S403，根据所述支付编码，获取其对应的授权许可信息。
具体而言，可采用如下实施方式：解码所述支付编码，获取授权编码，进而获取所述授权编码对应的授权许可信息；或者，对支付编码进行解码得到支付编码参数，根据支付编码参数得到授权编码，进而得到授权编码对应的授权许可信息。
步骤S405，根据所述授权许可信息和交易信息，从第一用户向商户进行支付。
实际应用中，在支付之前，还可包括一些前置的判定条件，以保证支付过程更加安全合理，如图5所示。例如，判断商家是否签约，判断二维码是否有效(解码是不是能成功，解码后的值是不是符合规则，解码是否得到已授权的授权编码，是否在有效期内、是否是有效的授权编码(未冻结、未挂失等))、判断消费金额是否在授权许可之内等等，例如通过设置二维码的有效期为生成时间起30S，可以有效防止二维码被恶意盗刷，具体实施方式在现有技术中已很常见，此处不再赘述。
作为本说明书实施例的一个可选方案，上述的支付方法还可包括：
发送所述交易信息至第一用户和第二用户。从而第一用户也可以及时得到第二用户的消费情形，有利于第一用户对第二用户的消费进行监管，及时调整授权范围或者额度等等。
在实际应用中，本说明书实施例提供一种实际应用示例，如图6所示，包括：
步骤S601，第一用户发出授权请求，其中，所述授权请求携带授权许可信息；
步骤S603，服务端确认第二用户，转发该授权请求至第二用户；
步骤S605，第二用户接受授权，返回回执至服务端；
步骤S607，服务端生成授权许可信息对应的授权编码，存储授权许可信息和授权编码；
步骤S609，第二用户上传自身设备特征，请求服务端下发支付编码参数；
步骤S611，服务端确认第二用户，根据授权编码生成支付编码参数下发至第二用户；
步骤S613，第二用户根据支付编码参数生成支付编码，进而生成DOI；
步骤S615，第二用户展示该DOI给商户；
步骤S617，商户扫描该DOI获取支付编码，上传该编码和交易信息至服务端；
步骤S619，服务端解码该编码获得授权编码；
步骤S621，判断该授权编码是否有效，若有效，获取其对应的授权许可信息；
步骤S623，根据该授权许可信息和交易信息从第一用户扣款至商户。
基于前述内容，为使本方案更容易理解，将前述的授权许可信息、授权编码、支付编码参数、支付编码、DOI之间的逻辑关系用图的形式表示出来，如图7所示。
本说明书前述实施例中，通过第一用户向第二用户授权，服务端存储授权许可信息，第二用户在需要时根据授权许可信息生成DOI，商户扫描该标识获得对应支付编码，并发送至服务端进行解码以获得对应的授权许可信息，进而从第一用户向商户进行支付。从而在授权范围内，第二用户消费，第一用户支付，实现多个账户使用一个账户的资金；同时，对于不能顺利使用支付软件的第二用户(例如低龄用户、不熟悉移动支付的高龄用户或资产/权限受限的用户)，提高了用户体验。此外，最终的交易信息(通常包含第二用户的消费信息)将会同时发送至第一用户和第二用户，有利于第一用户监管第二用户的消费状态，以及时调整授权范围。
基于同样的思路，本说明书还提供一种支付装置，如图8所示，所述装置包括：
接收模块801，接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
确定模块803，确定所述授权请求对应的第二用户；
授权模块805，根据所述授权许可信息对所述第二用户授权。
进一步地，所述授权模块805，生成授权许可信息所对应的授权编码，建立所述授权编码、授权许可信息和第二用户之间的对应关系，并存储。
进一步地，所述接收模块801，还用于接收第二用户的支付编码参数请求，所述装置还包括生成模块807，根据授权许可信息生成所述支付编码参数，所述支付编码参数用于第二用户生成支付编码，所述发送模块803，还用于发送所述支付编码参数至第二用户。
进一步地，所述生成模块807，获取授权许可信息对应的授权编码，根据所述授权编码生成所述支付编码参数。
本说明书还提供另一种支付装置，如图9所示，包括：
获取模块901，获取授权许可信息所对应的支付编码参数；
生成模块903，根据所述支付编码参数生成DOI，以便展示给商户进行支付；
其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由服务端根据授权许可信息生成。
进一步地，所述生成模块903，生成支付编码参数所对应的支付编码，根据所述支付编码生成DOI。
进一步地，还包括存储模块905，存储所述支付编码参数至本地；所述获取模块901，还用于获取本地所存储的支付编码参数。
本说明书还提供另一种支付装置，如图10所示，包括：
接收模块1001，接收商户所发送的支付编码和交易信息；
获取模块1003，根据所述支付编码，获取其对应的授权许可信息；
支付模块1005，根据所述授权许可信息和交易信息，通过第一用户向商户 进行支付；
其中，所述支付编码是根据第二用户的DOI所得到的。
进一步地，所述获取模块1003，解码所述支付编码，获取授权编码，获取所述授权编码对应的授权许可信息。
进一步地，所述装置还包括发送模块1007，发送所述交易信息至第一用户和第二用户。
对应的，本说明书还提供一种支付设备，包括：
通讯接口，接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
存储器，存储支付授权程序；
处理器，监听授权请求，调用存储器中的支付授权程序，并执行：
确定所述授权请求对应的第二用户；
根据所述授权许可信息对所述第二用户授权。
对应的，本说明书还提供另一种支付设备，在已接受第一用户的授权后，包括：
存储器，存储DOI生成程序；
处理器，调用存储器中的DOI生成程序，并执行：
获取授权许可信息所对应的支付编码参数；
根据所述支付编码参数生成DOI，以便展示给商户进行支付；
所述授权许可信息由第一用户发送至服务端，所述支付编码参数由服务端根据授权许可信息生成。
对应的，本说明书还提供另一种支付设备，包括：
通讯接口，接收商户所发送的支付编码和交易信息，
存储器，存储支付程序；
处理器，监听支付编码和交易信息，调用存储器中的支付程序，并执行：
根据所述支付编码，获取其对应的授权许可信息；
根据所述授权许可信息和交易信息，从第一用户向商户进行支付；其中，所述支付编码是根据第二用户的DOI所得到的。
对应的，本说明书的实施例还提供一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
监听第一用户的授权请求，并执行：
确定所述授权请求对应的第二用户；
根据所述授权许可信息对所述第二用户授权。
对应的，本说明书的实施例还提供另一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
获取授权许可信息所对应的支付编码参数；
根据所述支付编码参数生成DOI，以便展示给商户进行支付；
所述授权许可信息由第一用户发送至服务端，所述支付编码参数由服务端根据授权许可信息生成。
对应的，本说明书的实施例还提供另一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
监听支付编码和交易信息，并执行：
根据所述支付编码，获取其对应的授权许可信息；
根据所述授权许可信息和交易信息，通过第一用户向商户进行支付；
其中，所述支付编码是根据第二用户提供的DOI所得到的。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和介质类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可，这里就不再一一赘述。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤或模块可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实 现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书的实施例时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快 闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信编号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本说明书中一个或多个的实施例可提供为方法、系统或计算机程序产品。因此，本说明书的实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的形式。而且，本说明书的实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书的实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书的实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本说明书的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本说明书的实施例可以有各种更改和变化。凡在本说明书的实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利范围之中。

Claims (23)

  1. 一种支付方法，包括：
    接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
    确定所述授权请求对应的第二用户；
    根据所述授权许可信息对所述第二用户授权。
  2. 如权利要求1所述的方法，根据所述授权许可信息对所述第二用户授权，包括：
    生成授权许可信息所对应的授权编码；
    建立所述授权编码、授权许可信息和第二用户之间的对应关系，并存储。
  3. 如权利要求2所述的方法，还包括：
    接收第二用户的获取支付编码参数请求；
    根据授权许可信息生成所述支付编码参数，所述支付编码参数用于第二用户生成支付编码；
    发送所述支付编码参数至第二用户。
  4. 如权利要求3所述的方法，根据授权许可信息生成所述支付编码参数，包括：
    获取授权许可信息对应的授权编码；
    根据所述授权编码生成所述支付编码参数。
  5. 一种支付方法，包括：
    获取授权许可信息所对应的支付编码参数；其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成；
    根据所述支付编码参数生成DOI，以便展示给商户进行支付。
  6. 如权利要求5所述的方法，根据所述支付编码参数生成DOI，包括：
    生成支付编码参数所对应的支付编码，
    根据所述支付编码生成DOI。
  7. 如权利要求5所述的方法，还包括：
    存储所述支付编码参数至本地；
    获取授权许可信息所对应的支付编码参数，包括：
    获取本地所存储的支付编码参数。
  8. 一种支付方法，包括：
    接收商户所发送的支付编码和交易信息；其中，所述支付编码是根据第二用户提供的DOI所得到的；
    根据所述支付编码，获取其对应的授权许可信息；
    根据所述授权许可信息和交易信息，通过第一用户向商户进行支付。
  9. 如权利要求8所述的方法，根据所述支付编码，获取其对应的授权许可信息，包括：
    解码所述支付编码，获取授权编码；
    获取所述授权编码对应的授权许可信息。
  10. 如权利要求8所述的方法，还包括：
    发送所述交易信息至第一用户和第二用户。
  11. 一种支付装置，包括：
    接收模块，接收第一用户发送的授权请求，其中，所述授权请求携带授权许可信息；
    确定模块，确定所述授权请求对应的第二用户；
    授权模块，根据所述授权许可信息对所述第二用户授权。
  12. 如权利要求11所述的装置，所述授权模块，生成授权许可信息所对应的授权编码，建立所述授权编码、授权许可信息和第二用户之间的对应关系，并存储。
  13. 如权利要求11所述的装置，所述接收模块，还用于接收第二用户的获取支付编码参数请求；
    还包括生成模块，根据授权许可信息生成所述支付编码参数，所述支付编 码参数用于第二用户生成支付编码；
    所述发送模块，还用于发送所述支付编码参数至第二用户。
  14. 如权利要求13所述的装置，所述生成模块，获取授权许可信息中的授权编码，根据所述授权编码生成所述支付编码参数。
  15. 一种支付装置，包括：
    获取模块，获取授权许可信息所对应的支付编码参数；
    生成模块，根据所述支付编码参数生成DOI，以便展示给商户进行支付；
    其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成。
  16. 如权利要求15所述的装置，所述生成模块，生成支付编码参数所对应的支付编码，根据所述支付编码生成DOI。
  17. 如权利要求16所述的装置，还包括存储模块，存储所述支付编码参数至本地；
    所述获取模块，还用于获取本地所存储的支付编码参数。
  18. 一种支付装置，包括：
    接收模块，接收商户所发送的支付编码和交易信息；
    获取模块，根据所述支付编码，获取其对应的授权许可信息；
    支付模块，根据所述授权许可信息和交易信息，通过第一用户向商户进行支付；
    其中，所述支付编码是根据第二用户的DOI所得到的。
  19. 如权利要求18所述的装置，所述获取模块，解码所述支付编码，获取授权编码，获取所述授权编码对应的授权许可信息。
  20. 如权利要求18所述的装置，还包括：
    发送模块，发送所述交易信息至第一用户和第二用户。
  21. 一种支付设备，包括：
    通讯接口，接收第一用户发送的授权请求，其中，所述授权请求携带授权 许可信息；
    存储器，存储支付授权程序；
    处理器，监听授权请求，调用存储器中的支付授权程序，并执行：
    确定所述授权请求对应的第二用户；
    根据所述授权许可信息对所述第二用户授权。
  22. 一种支付设备，包括：
    存储器，存储DOI生成程序；
    处理器，调用存储器中的DOI生成程序，并执行：
    获取授权许可信息所对应的支付编码参数；
    根据所述支付编码参数生成DOI，以便展示给商户进行支付；
    其中，所述授权许可信息由第一用户发送至服务端，所述支付编码参数由所述服务端根据授权许可信息所生成。
  23. 一种支付设备，包括：
    通讯接口，接收商户所发送的支付编码和交易信息，
    存储器，存储支付程序；
    处理器，监听支付编码和交易信息，调用存储器中的支付程序，并执行：
    根据所述支付编码，获取其对应的授权许可信息；
    根据所述授权许可信息和交易信息，从第一用户向商户进行支付；
    其中，所述支付编码是根据第二用户提供的DOI所得到的。
PCT/CN2018/098660 2017-08-07 2018-08-03 一种支付方法、装置及其设备 WO2019029455A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710666039.0A CN107578244A (zh) 2017-08-07 2017-08-07 一种支付方法、装置及其设备
CN201710666039.0 2017-08-07

Publications (1)

Publication Number Publication Date
WO2019029455A1 true WO2019029455A1 (zh) 2019-02-14

Family

ID=61034521

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/098660 WO2019029455A1 (zh) 2017-08-07 2018-08-03 一种支付方法、装置及其设备

Country Status (3)

Country Link
CN (1) CN107578244A (zh)
TW (1) TWI761519B (zh)
WO (1) WO2019029455A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110334794A (zh) * 2019-06-03 2019-10-15 阿里巴巴集团控股有限公司 离线图形码的生成方法及装置
CN112990912A (zh) * 2021-03-19 2021-06-18 联想(北京)有限公司 基于付款码的数据验证方法及装置
CN113495771A (zh) * 2020-04-08 2021-10-12 北京意锐新创科技有限公司 适用于支付设备的信息显示方法和装置

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107578244A (zh) * 2017-08-07 2018-01-12 阿里巴巴集团控股有限公司 一种支付方法、装置及其设备
CN111343635B (zh) * 2018-03-06 2023-07-14 创新先进技术有限公司 支付辅助方法、装置以及设备
CN108734460A (zh) * 2018-04-02 2018-11-02 阿里巴巴集团控股有限公司 一种支付方式推荐方法、装置及设备
CN108764886A (zh) * 2018-04-10 2018-11-06 阿里巴巴集团控股有限公司 二维码图片获取方法、装置以及设备
CN109002958A (zh) * 2018-06-06 2018-12-14 阿里巴巴集团控股有限公司 一种风险识别的方法、系统、装置及设备
CN109493078A (zh) * 2018-11-14 2019-03-19 广东小天才科技有限公司 支付系统、支付方法和第二客户端装置
CN109447655A (zh) * 2018-11-14 2019-03-08 广东小天才科技有限公司 支付系统、支付方法和第二客户端装置
CN109523268A (zh) * 2018-11-14 2019-03-26 广东小天才科技有限公司 支付系统、支付方法和第二客户端装置
CN109615391A (zh) * 2018-11-14 2019-04-12 广东小天才科技有限公司 支付系统、支付方法和第二客户端装置
CN114841700B (zh) * 2020-07-21 2024-04-16 支付宝(杭州)信息技术有限公司 支付处理方法、装置、设备及系统
CN112862496A (zh) * 2021-03-30 2021-05-28 中国工商银行股份有限公司 一种实时授权的支付方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105590199A (zh) * 2014-11-14 2016-05-18 中国银联股份有限公司 一种基于动态二维码的支付方法以及支付系统
CN106548336A (zh) * 2016-11-03 2017-03-29 努比亚技术有限公司 移动支付系统及方法
CN106934622A (zh) * 2015-12-31 2017-07-07 华为技术有限公司 一种共享账户的方法和装置
CN107578244A (zh) * 2017-08-07 2018-01-12 阿里巴巴集团控股有限公司 一种支付方法、装置及其设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2466810A (en) * 2009-01-08 2010-07-14 Visa Europe Ltd Processing payment authorisation requests
EP2628138A4 (en) * 2010-10-13 2014-04-23 Nokia Corp METHOD AND DEVICE FOR IMPLEMENTING TRANSACTIONS THROUGH A SPONSOR ACCOUNT
CN104657857A (zh) * 2013-11-19 2015-05-27 腾讯科技（深圳）有限公司 一种实现支付的方法、相关装置及系统
US20150213443A1 (en) * 2014-01-30 2015-07-30 Apple Inc. Tokenizing authorizations

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105590199A (zh) * 2014-11-14 2016-05-18 中国银联股份有限公司 一种基于动态二维码的支付方法以及支付系统
CN106934622A (zh) * 2015-12-31 2017-07-07 华为技术有限公司 一种共享账户的方法和装置
CN106548336A (zh) * 2016-11-03 2017-03-29 努比亚技术有限公司 移动支付系统及方法
CN107578244A (zh) * 2017-08-07 2018-01-12 阿里巴巴集团控股有限公司 一种支付方法、装置及其设备

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110334794A (zh) * 2019-06-03 2019-10-15 阿里巴巴集团控股有限公司 离线图形码的生成方法及装置
CN110334794B (zh) * 2019-06-03 2023-01-17 创新先进技术有限公司 离线图形码的生成方法及装置
CN113495771A (zh) * 2020-04-08 2021-10-12 北京意锐新创科技有限公司 适用于支付设备的信息显示方法和装置
CN112990912A (zh) * 2021-03-19 2021-06-18 联想(北京)有限公司 基于付款码的数据验证方法及装置
CN112990912B (zh) * 2021-03-19 2024-04-19 联想(北京)有限公司 基于付款码的数据验证方法及装置

Also Published As

Publication number Publication date
CN107578244A (zh) 2018-01-12
TW201911174A (zh) 2019-03-16
TWI761519B (zh) 2022-04-21

Similar Documents

Publication Publication Date Title
WO2019029455A1 (zh) 一种支付方法、装置及其设备
TWI695290B (zh) 登錄資訊處理方法及設備
TWI728266B (zh) 二維條碼生成、業務處理方法、裝置和設備以及二維條碼
TWI771608B (zh) 設備支付方法及裝置
WO2018103561A1 (zh) 一种业务处理方法及装置
TWI676107B (zh) 資訊交互方法及裝置
CN113302954A (zh) 用按需应用生成虚拟卡的虚拟号码以安全地自动填充表单
TW201619871A (zh) 資訊展示方法及裝置
TWI742324B (zh) 基於掃描ｄｏｉ的資訊處理方法、裝置及設備
TW201944315A (zh) 二維條碼圖片獲取方法、裝置以及設備
CN108241974B (zh) Nfc便携设备的写入、支付方法、装置以及设备
WO2022022245A1 (zh) 数字物权凭证的生成方法、装置及设备
TWI694392B (zh) 顯示數位物件唯一識別符的方法及裝置
TWI724450B (zh) 掃碼控制方法、裝置及系統
WO2019165875A1 (zh) 一种交易处理方法、服务器、客户端及系统
WO2019141128A1 (zh) 一种数据的处理方法、装置及设备
CN109003071B (zh) 支付方法、装置及设备
TWI786252B (zh) 支付方法、裝置及設備
TW201926173A (zh) 資源轉移的驗證方法、裝置和電子支付驗證方法、裝置
US11164056B2 (en) Method and system for applying barcode, and server
WO2019137357A1 (zh) 付款码获取、支付请求响应方法、装置以及设备
CN111340505A (zh) 一种支付方法、装置及电子设备
WO2019095855A1 (zh) 支付凭证信息生成方法及装置、设备
CN114640470A (zh) 一种基于数据处理系统的数据处理方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18844636

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18844636

Country of ref document: EP

Kind code of ref document: A1