WO2020108109A1 - 一种基于绑定关系的联合支付方法及系统 - Google Patents

一种基于绑定关系的联合支付方法及系统 Download PDF

Info

Publication number
WO2020108109A1
WO2020108109A1 PCT/CN2019/110513 CN2019110513W WO2020108109A1 WO 2020108109 A1 WO2020108109 A1 WO 2020108109A1 CN 2019110513 W CN2019110513 W CN 2019110513W WO 2020108109 A1 WO2020108109 A1 WO 2020108109A1
Authority
WO
WIPO (PCT)
Prior art keywords
joint
initiator
current
payment
joint payment
Prior art date
Application number
PCT/CN2019/110513
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 阿里巴巴集团控股有限公司
Priority to SG11202100837PA priority Critical patent/SG11202100837PA/en
Publication of WO2020108109A1 publication Critical patent/WO2020108109A1/zh
Priority to PH12021550200A priority patent/PH12021550200A1/en
Priority to US17/163,068 priority patent/US11501280B2/en

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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/01—Social networking
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/06009—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking
    • G06K19/06046—Constructional details
    • G06K19/06112—Constructional details the marking being simulated using a light source, e.g. a barcode shown on a display or a laser beam with time-varying intensity profile
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • G06Q20/229—Hierarchy of users of accounts
    • G06Q20/2295—Parent-child type, e.g. where parent has control on child rights
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device

Definitions

  • the embodiments of the present specification relate to the technical field of e-commerce, and in particular, to a joint payment method and system based on a binding relationship.
  • the subway is the main means of daily travel for users. You can scan the code to pay for the subway. That is, each user needs to display their own graphic code when entering the subway station, and can only enter the station after being identified. Displaying your own graphic code again and completing the payment outbound after being identified means that currently each user's smart terminal can only display its corresponding graphic code to complete the payment outbound.
  • users have the need to use their own smart terminals to show multiple users their respective graphic codes to complete payment outbound. Therefore, in the current scenario of scanning and paying to take the subway, buying tickets, buying scenic tickets, etc., a solution that can be jointly paid for is urgently needed so that users can display their corresponding graphic codes for multiple users through their own smart terminals. Joint payment.
  • the embodiments of the present specification provide a method and system for joint payment based on a binding relationship.
  • the technical solutions are as follows:
  • a joint payment method based on binding relationship includes:
  • the client sends a joint payment request to the server, where the joint payment request carries the identification of the initiator of the joint payment and the identification corresponding to the current joint object;
  • the server analyzes the identifier of the joint payment initiator and the corresponding identifier of the current joint object carried in the received joint payment request;
  • the server determines whether a binding relationship has been established between the joint payment initiator and the current joint object based on the identification of the joint payment initiator and the corresponding identification of the current joint object;
  • the server If yes, the server generates a graphic code corresponding to the joint payment initiator and the current joint object, and sends the graphic code corresponding to the joint payment initiator and the current joint object to the client;
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • a joint payment method based on binding relationship is applied to the client.
  • the method includes:
  • the server Send a joint payment request to the server, where the joint payment request carries the identification of the initiator of the joint payment and the identification corresponding to the current joint object;
  • the graphic codes respectively corresponding to the joint payment initiator and the current joint object are: the joint payment initiator identifier carried by the server according to the joint payment request and The identifier corresponding to the current joint object determines whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, generates a graphic code corresponding to the joint payment initiator and the current joint object respectively;
  • a joint payment method based on binding relationship is applied to the server.
  • the method includes:
  • the identifier of the joint payment initiator and the corresponding identifier of the current joint object determine whether a binding relationship has been established between the joint payment initiator and the current joint object;
  • the server If yes, the server generates a graphic code corresponding to the joint payment initiator and the current joint object, and sends the graphic code corresponding to the joint payment initiator and the current joint object to the client, so that the client receives and associates
  • the graphic codes corresponding to the payment initiator and the current joint object respectively display the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • a joint payment system based on binding relationship includes: a client and a server;
  • the client sends a joint payment request to the server, where the joint payment request carries the identification of the initiator of the joint payment and the identification corresponding to the current joint object;
  • the server analyzes the identifier of the joint payment initiator and the corresponding identifier of the current joint object carried in the received joint payment request;
  • the server determines whether a binding relationship has been established between the joint payment initiator and the current joint object based on the identification of the joint payment initiator and the corresponding identification of the current joint object;
  • the server If yes, the server generates a graphic code corresponding to the joint payment initiator and the current joint object, and sends the graphic code corresponding to the joint payment initiator and the current joint object to the client;
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • a joint payment device based on binding relationship, applied to a client includes:
  • the request sending module is used to send a joint payment request to the server, where the joint payment request carries the identifier of the joint payment initiator and the identification corresponding to the current joint object;
  • the graphic code receiving module is used to receive the graphic codes corresponding to the joint payment initiator and the current joint object respectively.
  • the graphic codes respectively corresponding to the joint payment initiator and the current joint object are: the server carries according to the joint payment request The identifier of the joint payment initiator and the corresponding identifier of the current joint object, to determine whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, to generate corresponding to the joint payment initiator and the current joint object respectively Graphic code
  • the graphic code display module is used to display the graphic codes respectively corresponding to the joint payment initiator and the current joint object to complete the joint payment.
  • a joint payment device based on binding relationship is applied to the server.
  • the device includes:
  • the request receiving module is used to receive the joint payment request sent by the client;
  • An identification parsing module used for parsing the identification of the joint payment initiator and the identification corresponding to the current joint object carried in the received joint payment request;
  • the judgment module is used for judging whether a binding relationship has been established between the joint payment initiator and the current joint object according to the identification of the joint payment initiator and the corresponding identification of the current joint object;
  • the graphic code generation module is used for generating graphic codes corresponding to the joint payment initiator and the current joint object respectively, and sending the graphic codes respectively corresponding to the joint payment initiator and the current joint object to the client, so that The client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • the client sends a joint payment request to the server, and the server parses the identifier of the joint payment initiator and the corresponding identifier of the current joint object carried in the received joint payment request, and according to the joint The identifier of the payment initiator and the identifier corresponding to the current joint object, to determine whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, to generate graphic codes corresponding to the joint payment initiator and the current joint object respectively And sent to the client, the client receives the graphic code corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic code corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment. In this way, users can display their corresponding graphic codes for multiple users through their own smart terminals to complete the joint payment.
  • FIG. 1 is a schematic flowchart of a joint payment method based on a binding relationship according to an embodiment of this specification
  • FIG. 2 is a schematic diagram showing a graphic code according to an embodiment of this specification.
  • FIG. 3 is a schematic structural diagram of a joint payment device based on a binding relationship applied to a client according to an embodiment of the present specification
  • FIG. 4 is a schematic structural diagram of a joint payment device based on a binding relationship applied to a server according to an embodiment of the present specification
  • FIG. 5 is a schematic structural diagram of a device for configuring an apparatus of an embodiment of this specification.
  • this specification provides a joint payment technology solution based on binding relationship.
  • the joint payment initiator and current payment are generated.
  • the graphic codes corresponding to the joint object are sent to the client.
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object to complete Joint payment. In this way, users can display their corresponding graphic codes for multiple users through their own smart terminals to complete the joint payment.
  • the client sends a joint payment request to the server, the joint payment request carries the identification of the joint payment initiator and the identification corresponding to the current joint object; the server parses the identification of the joint payment initiator carried in the received joint payment request and The identifier corresponding to the current joint object; the server determines whether a binding relationship has been established between the joint payment initiator and the current joint object according to the identifier of the joint payment initiator and the corresponding ID of the current joint object; if so, the server generates Graphic codes corresponding to the joint payment initiator and the current joint object respectively, and send the graphic codes respectively corresponding to the joint payment initiator and the current joint object to the client; the client receives the joint payment initiator and the current joint object The graphic codes corresponding to each display the graphic codes respectively corresponding to the initiator of the joint payment and the object of the current joint to complete the joint payment.
  • the client is the client of the application installed on the smart terminal, such as the Alipay client
  • the server can be in the form of a specific server or server cluster. This form of network realizes the communication connection, which is not limited in this specification.
  • this specification provides a method for establishing a binding relationship, which is applied to the server and can complete joint payment based on the binding relationship.
  • the user when the user enters the subway ride graphic code page, it is determined to receive the user's display operation instruction for the graphical code, and the user is determined to be the initiator of the binding relationship. For example, before the user A rides on the subway, he opens the subway ride graphic code page, from which it can be determined that the user A's display operation instruction for the graphic code is received, and then user A can be determined to be the initiator of the binding relationship.
  • the object of the binding relationship may be determined from the user friends who have a friend relationship with the user, or while the initiator of the binding relationship is determined, the user friend who has the friend relationship with the user may be determined
  • the binding relationship object is determined in the embodiment of this specification without limitation. Specifically, the binding relationship object may be determined from user friends who have a friend relationship with the user in the following manner.
  • the intimacy of each user friend with the user can be determined, and the user friend whose intimacy with the user satisfies the preset requirements can be determined as the binding relationship object.
  • the specific intimacy can be expressed in the form of an intimacy value, for example, the intimacy of user D and user A is 95, and the corresponding determination that the user’s friend whose intimacy meets the preset requirements is the binding relationship object can be determined and User friends whose intimacy of the user is not less than a preset threshold are binding relationship objects.
  • the user friends who have a friend relationship with user A are: user D, user E, and user F. From the user friends who have a friend relationship with user A, determine the intimacy of each user friend and user A, that is, determine the users separately The intimacy of D with user A, the intimacy of user E with user A, the intimacy of user F with user A, the specific intimacy of user D with user A is 95, the intimacy of user E with user A is 90, the user F If the intimacy with user A is 85 and the preset intimacy threshold is 90, it can be determined that user D and user E are binding relationship objects.
  • the user friends who have a friend relationship with the user determine the information interaction status of each user friend with the user, and determine that the user friend whose information interaction status with the user meets the preset requirements is a binding relationship object.
  • the number of chats and the frequency of chats between each user friend and the user can be counted to determine Each user's friend interacts with the user's information, and determines that the number of chats with the user and the chat frequency is not less than a preset threshold as the binding relationship object.
  • the father, mother, and daughter are binding relationship objects.
  • the determined binding relationship object is recommended to the binding relationship initiator, that is, the determined binding relationship object is recommended to the user, so that the binding relationship initiator preferentially selects the determined Binding relationship object.
  • the determined binding relationship objects are user B, user C, and user D
  • the determined binding relationship objects are recommended to user A: user B, user C, and user D, so that user A preferentially selects user B and user C.
  • User D is a user B, user C, and user D
  • the binding relationship initiator may select one or more of them, or directly select one or more of the user friends who have a friend relationship with themselves, that is, ignore the recommended Bind relationship objects, or select a plurality of recommended binding relationship objects and user friends who have a friend relationship with themselves.
  • binding relationship request Send a binding relationship request to the selected binding relationship object according to the binding relationship object selected by the binding relationship initiator, wherein the binding relationship request can be sent to the selected binding relationship object according to a preset sending rule, to Make the selected binding relationship object agree to the binding relationship with the binding relationship initiator.
  • the binding relationship request can be sent to the selected binding relationship object according to the following rules:
  • binding relationship initiator After the binding relationship initiator selects the binding relationship object, send the binding relationship request to the selected binding relationship object in a one-time broadcast, or in accordance with the order in which the binding relationship initiator selects the binding relationship object
  • the form of broadcasting sends the binding relationship request to the selected binding relationship object in sequence, and the specific sending rules are various, which is not limited in this specification.
  • the binding relationship object After sending the binding relationship request to the selected binding relationship object, after receiving the binding relationship request, the binding relationship object authorizes and returns a response notification to the server, and the server receives the selection selected by the binding relationship initiator After the response notification returned by the binding relationship object, it is determined that the response notification is to agree to binding, and the binding is established based on the basic information of the binding relationship initiator (such as name, age, user account, etc.) and the basic information of the binding relationship object The binding relationship between the relationship initiator and the binding relationship object.
  • the basic information of the binding relationship initiator such as name, age, user account, etc.
  • the response notification is to agree to binding, and the basic information of initiator A according to the binding relationship, and the basic information of user B, user C’s
  • the basic information and the basic information of user D establish binding relationships, such as user A-user B, user A-user C, and user A-user D, respectively.
  • binding relationship initiator After the binding relationship is established, it is prompted that the binding relationship initiator has established the binding relationship, and the object that establishes the binding relationship with itself will be marked under the account of the binding relationship initiator.
  • the method for establishing a binding relationship based on the above, as shown in FIG. 1, is a schematic flowchart of a binding payment method based on a binding relationship provided by this specification.
  • the method may specifically include the following steps:
  • the client sends a joint payment request to the server, where the joint payment request carries the identifier of the joint payment initiator and the identifier corresponding to the current joint object;
  • the client sends a joint payment request to the server, the joint payment request carries the identification of the joint payment initiator and the current joint object, the user is the joint payment initiator, the current joint object That is, the joint object selected by the user, the joint object selected by the user may be an object that establishes a binding relationship with itself, or may be a user's own user friend.
  • the joint object selected by user A at the time is the father and mother, and the joint object selected next time may be the father.
  • the client sends a joint payment request to the server.
  • Mother's logo where the logo can be name, age, user account, etc., that is, information that can uniquely indicate the user's identity.
  • the server analyzes the identifier of the joint payment initiator and the identifier corresponding to the current joint object carried in the received joint payment request;
  • the server receives the joint payment request, and parses the identifier of the joint payment initiator and the object of the current joint object carried in it. For example, it parses the identifier of user A: Li San, 35, 1306, and the identifier of user B: Zhang San, 55 1306..., User C's logo: Li Si, 56, 1306...
  • S103 The server determines whether a binding relationship has been established between the joint payment initiator and the current joint object according to the identification of the joint payment initiator and the corresponding identification of the current joint object;
  • the identifier of the joint payment initiator and the identifier corresponding to the current joint object it can be found whether there is a binding relationship between the joint payment initiator and the current joint object, for example, the identifier corresponding to the joint payment initiator user A is Li San, 35, 1306..., the corresponding identifier of the current joint user B is Zhang San, 55, 1306..., after searching, Li San and Zhang San already have a binding relationship (Li San, 35, 1306...- Zhang San, 55, 1306%), which indicates that the binding relationship has been established between the user A of the joint payment initiator and the user B of the current joint object.
  • the server If yes, the server generates a graphic code corresponding to the joint payment initiator and the current joint object, and sends the graphic code corresponding to the joint payment initiator and the current joint object to the client;
  • the server randomly generates the corresponding corresponding to the joint payment initiator and the current joint object
  • the graphic code here can be two-dimensional code, bar code, etc.
  • the graphic codes corresponding to the joint payment initiator and the current joint object randomly generated by the server may have an expiration date, such as a Minutes, one minute later, the server again randomly generates graphic codes corresponding to the joint payment initiator and the current joint object, and sends a notification to the client to update the graphic code, and the newly generated joint code with the joint payment initiator and the current joint
  • the graphic codes corresponding to the objects are sent to the client.
  • the joint payment initiator is prompted to fail the joint payment, and the joint payment initiator and the current joint object are guided to establish a binding relationship.
  • the situation where there is no binding relationship between the joint payment initiator and the current joint object may be that the current joint object has not established a binding relationship with the joint payment initiator, or some of them have not established a binding relationship with the joint payment initiator .
  • Specific guidance to establish a binding relationship between the originator of the joint payment and the current joint object can be done in the following ways:
  • the server determines the joint object that has not established a binding relationship with the joint payment initiator from the current joint object, and sends a message to establish a binding relationship to the client to notify the joint payment initiator to establish a binding with the determined joint object Relationship, after the joint payment initiator selects and confirms the determined joint object, the server sends a binding relationship request to the determined joint object, and after receiving the response notification returned by the determined joint object, establishes the joint payment initiator The binding relationship with the determined joint object, and notifying the joint payment initiator that the binding relationship has been established.
  • the client receives the graphic codes respectively corresponding to the joint payment initiator and the current joint object, and displays the graphic codes respectively corresponding to the joint payment initiator and the current joint object to complete the joint payment.
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object sent by the server, and displays the graphic codes respectively corresponding to the joint payment initiator and the current joint object according to a preset display rule to complete the joint payment.
  • the joint payment initiator can use its own smart terminal to use its own graphic code to complete the payment for itself, and use its own smart terminal to use the graphic code corresponding to the joint object to complete the payment for the joint object, that is, one person in the joint payment initiator
  • Multiple payments can be made to multiple users on the smart terminal, and the specific payment amount can be directly deducted from the account of the joint payment initiator, or can be deducted from the respective accounts of the joint payment initiator and the joint object. Not limited.
  • the preset display rule here can be to automatically display the graphic codes corresponding to the joint payment initiator and the current joint object in sequence at the preset time interval, or it can be displayed in the form of a menu with the joint payment initiator and the current joint.
  • the graphic codes corresponding to the objects respectively, as shown in FIG. 2 are used by the initiator of the joint payment to select the corresponding graphic code.
  • the specific display rules are various, and this specification will not repeat them one by one again.
  • the client sends a joint payment request to the server, and the server analyzes the identifier of the joint payment initiator and the corresponding identifier of the current joint object carried in the received joint payment request, and according to The identifier of the joint payment initiator and the corresponding identifier of the current joint object, to determine whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, to generate graphics corresponding to the joint payment initiator and the current joint object respectively
  • the code is sent to the client.
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment. In this way, users can display their corresponding graphic codes for multiple users through their own smart terminals to complete the joint payment.
  • A. Send a joint payment request to the server, where the joint payment request carries the identification of the initiator of the joint payment and the identification corresponding to the current joint object;
  • the embodiments of the present specification also provide a binding payment device based on a binding relationship, which is applied to the client.
  • the device includes: a request sending module 310, a graphic code receiving module 320, Graphic code display module 330.
  • the request sending module 310 is used to send a joint payment request to the server, where the joint payment request carries the identification of the joint payment initiator and the identification corresponding to the current joint object;
  • the graphic code receiving module 320 is used to receive the graphic codes corresponding to the joint payment initiator and the current joint object respectively.
  • the graphic codes corresponding to the joint payment initiator and the current joint object respectively are:
  • the identifier of the joint payment initiator and the corresponding identifier of the current joint object are carried to determine whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, the generation corresponds to the joint payment initiator and the current joint object Graphic code
  • the graphic code display module 330 is used to display the graphic codes respectively corresponding to the joint payment initiator and the current joint object to complete the joint payment.
  • This specification also provides a binding payment device based on the binding relationship, which is applied to the server. As shown in FIG.
  • the request receiving module is used to receive the joint payment request sent by the client;
  • An identification parsing module used for parsing the identification of the joint payment initiator and the identification corresponding to the current joint object carried in the received joint payment request;
  • the judgment module is used for judging whether a binding relationship has been established between the joint payment initiator and the current joint object according to the identification of the joint payment initiator and the corresponding identification of the current joint object;
  • the graphic code generation module is used for generating graphic codes corresponding to the joint payment initiator and the current joint object respectively, and sending the graphic codes respectively corresponding to the joint payment initiator and the current joint object to the client, so that The client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • This specification also provides a joint payment system based on binding relationship, which includes: client and server;
  • the client sends a joint payment request to the server, where the joint payment request carries the identification of the initiator of the joint payment and the identification corresponding to the current joint object;
  • the server analyzes the identifier of the joint payment initiator and the corresponding identifier of the current joint object carried in the received joint payment request;
  • the server determines whether a binding relationship has been established between the joint payment initiator and the current joint object based on the identification of the joint payment initiator and the corresponding identification of the current joint object;
  • the server If yes, the server generates a graphic code corresponding to the joint payment initiator and the current joint object, and sends the graphic code corresponding to the joint payment initiator and the current joint object to the client;
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • the client sends a joint payment request to the server, and the server analyzes the identifier of the joint payment initiator and the corresponding identifier of the current joint object carried in the received joint payment request, and according to The identifier of the joint payment initiator and the corresponding identifier of the current joint object, to determine whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, to generate graphics corresponding to the joint payment initiator and the current joint object respectively
  • the code is sent to the client.
  • the client receives the graphic codes corresponding to the joint payment initiator and the current joint object respectively, and displays the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment. In this way, users can display their corresponding graphic codes for multiple users through their own smart terminals to complete the joint payment.
  • the device may include a processor 510, a memory 520, an input/output interface 530, a communication interface 540, and a bus 550.
  • the processor 510, the memory 520, the input/output interface 530, and the communication interface 540 realize the communication connection between the devices within the device through the bus 550.
  • the processor 510 may be implemented by a general-purpose CPU (Central Processing Unit, central processing unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. Programs to implement the technical solutions provided by the embodiments of this specification.
  • the memory 520 may be implemented in the form of ROM (Read Only Memory, Read Only Memory), RAM (Random Access Memory, Random Access Memory), static storage device, dynamic storage device, or the like.
  • the memory 520 may store an operating system and other application programs.
  • related program codes are stored in the memory 520 and called and executed by the processor 510.
  • the input/output interface 530 is used to connect an input/output module to realize information input and output.
  • the input/output/module can be configured as a component in the device (not shown in the figure), or can be externally connected to the device to provide corresponding functions.
  • the input device may include a keyboard, mouse, touch screen, microphone, various sensors, etc.
  • the output device may include a display, a speaker, a vibrator, an indicator light, and the like.
  • the communication interface 540 is used to connect a communication module (not shown in the figure) to implement communication interaction between the device and other devices.
  • the communication module can realize communication through a wired method (such as USB, network cable, etc.), and can also realize communication through a wireless method (such as mobile network, WIFI, Bluetooth, etc.).
  • the bus 550 includes a path for transferring information between various components of the device (for example, the processor 510, the memory 520, the input/output interface 530, and the communication interface 540).
  • the device may also include the necessary to achieve normal operation Other components.
  • the above-mentioned device may also include only the components necessary to implement the solutions of the embodiments of the present specification, rather than including all the components shown in the figures.
  • Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the aforementioned joint payment method based on a binding relationship is realized.
  • the method includes at least:
  • a joint payment method based on binding relationship is applied to the client.
  • the method includes:
  • the server Send a joint payment request to the server, where the joint payment request carries the identification of the initiator of the joint payment and the identification corresponding to the current joint object;
  • the graphic codes respectively corresponding to the joint payment initiator and the current joint object are: the joint payment initiator identifier carried by the server according to the joint payment request and The identifier corresponding to the current joint object determines whether a binding relationship has been established between the joint payment initiator and the current joint object, and if so, generates a graphic code corresponding to the joint payment initiator and the current joint object respectively;
  • Embodiments of the present specification also provide a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the aforementioned joint payment method based on a binding relationship is realized.
  • the method includes at least:
  • a joint payment method based on binding relationship is applied to the server.
  • the method includes:
  • the identifier of the joint payment initiator and the corresponding identifier of the current joint object determine whether a binding relationship has been established between the joint payment initiator and the current joint object;
  • the server If yes, the server generates a graphic code corresponding to the joint payment initiator and the current joint object, and sends the graphic code corresponding to the joint payment initiator and the current joint object to the client, so that the client receives and associates
  • the graphic codes corresponding to the payment initiator and the current joint object respectively display the graphic codes corresponding to the joint payment initiator and the current joint object respectively to complete the joint payment.
  • Computer-readable media including permanent and non-permanent, removable and non-removable media, can store information by any method or technology.
  • the information may 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 technologies, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices.
  • computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.
  • the system, device, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product with a certain function.
  • a typical implementation device is a computer, and the specific form of the computer may be 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 sending and receiving device, and a game control Desk, tablet computer, wearable device, or any combination of these devices.
  • the embodiments in this specification are described in a progressive manner.
  • the same or similar parts between the embodiments can be referred to each other.
  • Each embodiment focuses on the differences from other embodiments.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.
  • the device embodiments described above are only schematic, wherein the modules described as separate components may or may not be physically separated, and the functions of the modules may be the same when implementing the embodiment solutions of the present specification Or multiple software and/or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art can understand and implement without paying creative labor.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Marketing (AREA)
  • Computing Systems (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Optics & Photonics (AREA)
  • Child & Adolescent Psychology (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

公开了基于绑定关系的联合支付方法及系统。基于绑定关系的联合支付方法，该方法包括：客户端向服务端发送联合支付请求；服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。

Description

一种基于绑定关系的联合支付方法及系统 技术领域
本说明书实施例涉及电子商务技术领域，尤其涉及一种基于绑定关系的联合支付方法及系统。
背景技术
随着智能终端的发展及移动支付的普及，极大地方便了用户的日常生活。例如，地铁作为当下用户日常出行的主要交通工具，可以扫码付款乘坐地铁，即每个用户在进地铁站时需展示自己的图形码，待被识别后方可进站，在出地铁站时需再次展示自己的图形码，待被识别后即可完成付款出站，意味着目前每个用户的智能终端只能展示自己对应的图形码完成付款出站。然而在一些特殊情况下，为了便利，用户存在使用自己的智能终端为多个用户展示各自对应的图形码完成付款出站的需求。因此在当下扫描付款乘坐地铁、购买车票、购买景区门票等类似的场景下，急需一种可以联合支付的方案，以使用户可通过自身的智能终端可以为多个用户展示各自对应的图形码完成联合支付。
发明内容
针对上述技术问题，本说明书实施例提供一种基于绑定关系的联合支付方法及系统，技术方案如下：
一种基于绑定关系的联合支付方法，该方法包括：
客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；
客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付 发起方、当次联合对象分别对应的图形码以完成联合支付。
一种基于绑定关系的联合支付方法，应用于客户端，该方法包括：
向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
接收与联合支付发起方、当次联合对象分别对应的图形码，所述与联合支付发起方、当次联合对象分别对应的图形码为：服务端根据联合支付请求携带的联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码；
展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
一种基于绑定关系的联合支付方法，应用于服务端，该方法包括：
接收客户端发送的联合支付请求；
解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，以使客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
一种基于绑定关系的联合支付系统，该系统包括：客户端以及服务端；
客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联 合支付发起方、当次联合对象分别对应的图形码发送至客户端；
客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
一种基于绑定关系的联合支付装置，应用于客户端，该装置包括：
请求发送模块，用于向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
图形码接收模块，用于接收与联合支付发起方、当次联合对象分别对应的图形码，所述与联合支付发起方、当次联合对象分别对应的图形码为：服务端根据联合支付请求携带的联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码；
图形码展示模块，用于展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
一种基于绑定关系的联合支付装置，应用于服务端，该装置包括：
请求接收模块，用于接收客户端发送的联合支付请求；
标识解析模块，用于解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
判断模块，用于根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
图形码生成模块，用于若是，生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，以使客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
本说明书实施例所提供的技术方案，客户端向服务端发送联合支付请求，服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识，并根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码并发送至客户端，客户端接收与联合支付发起方、当次联合对象分别 对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。如此一来，用户可通过自身的智能终端可以为多个用户分别展示各自对应的图形码以完成联合支付。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。
此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本说明书实施例的基于绑定关系的联合支付方法的流程示意图；
图2是本说明书实施例的展示图形码的示意图；
图3是本说明书实施例的应用于客户端的基于绑定关系的联合支付装置的结构示意图；
图4是本说明书实施例的应用于服务端的基于绑定关系的联合支付装置的结构示意图；
图5是用于配置本说明书实施例装置的一种设备的结构示意图。
具体实施方式
背景技术中所提到的用户在乘坐地铁出行时，经常会有同行的家人、朋友，特别是与未成年子女同行时，为了快速进站，这时用户存在使用自己的智能终端为家人、朋友、子女展示各自对应的图形码的需求，待被识别后，家人、朋友、子女可依次进站，而在出站时，同理用户同样存在使用自己的智能终端为家人、朋友、子女展示各自对应的图形码完成联合支付的需求，家人、朋友、子女可依次出站。另外在其它的应用场景下，用户购买火车票、自助餐票或者景区门票时，经常会有同行的家人、朋友，这时用户同样存在使用自己的智能终端为家人、朋友展示各自对应的图形码以完成联合支付的需求，类似的应用场景(一人一票，关注人数的应用场景)本说明书在此不再一一赘述。
针对上述问题，本说明书提供一种基于绑定关系的联合支付技术方案，通过判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码并发送至客户端，客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。如此一来，用户可通过自身的智能终端可以为多个用户分别展示各自对应的图形码以完成联合支付。
具体的，本说明书提供的技术方案如下：
客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
在本说明书的实施例中，客户端为智能终端上安装的应用程序的客户端，例如支付宝客户端，服务端可以是特定的一台服务器或服务器集群的形式，客户端与服务端可通过各种形式的网络实现通信连接，本说明书对此不作限定。
为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。
为了更好地对本说明书实施例提供的技术方案进行描述，本说明书提供一种绑定关系的建立方法，应用于服务端，基于绑定关系可以完成联合支付。
具体的本说明书实施例提供的绑定关系的建立方法可以包括以下步骤：
S1，当接收到用户针对图形码的展示操作指令时，确定所述用户为绑定关系发起方；
以当下地铁的乘车图形码为例，当用户进入地铁乘车图形码页面之后，即确定接收到用户针对图形码的展示操作指令，确定该用户为绑定关系发起方。例如，用户A在乘坐地铁之前，打开了地铁乘车图形码页面，由此可以确定接收到用户A针对图形码的展 示操作指令，则可以确定用户A为绑定关系发起方。
S2，从与所述用户存在好友关系的用户好友中确定绑定关系对象；
在确定绑定关系发起方之后，可以从与所述用户存在好友关系的用户好友中确定绑定关系对象，或者在确定绑定关系发起方的同时，从与所述用户存在好友关系的用户好友中确定绑定关系对象，本说明书实施例对此不作限定，具体的可以通过以下方式从与所述用户存在好友关系的用户好友中确定绑定关系对象。
可以从与该用户存在好友关系的用户好友中，确定每个用户好友与该用户的亲密度，确定与所述用户的亲密度满足预设要求的用户好友为绑定关系对象。具体的亲密度可以以亲密值的形式体现，例如用户D与用户A的亲密度为95，相应的确定与所述用户的亲密度满足预设要求的用户好友为绑定关系对象可以是确定与所述用户的亲密度不小于预设阈值的用户好友为绑定关系对象。
例如，与用户A存在好友关系的用户好友为：用户D、用户E、用户F，从与用户A存在好友关系的用户好友中，确定每个用户好友与用户A的亲密度，即分别确定用户D与用户A的亲密度、用户E与用户A的亲密度、用户F与用户A的亲密度，具体用户D与用户A的亲密度为95，用户E与用户A的亲密度90，用户F与用户A的亲密度为85，亲密度预设阈值为90，则可以确定用户D、用户E为绑定关系对象。
或者从与该用户存在好友关系的用户好友中，确定每个用户好友与该用户的信息交互状况，确定与该用户的信息交互状况满足预设要求的用户好友为绑定关系对象。具体的，可以在预设的时间段内(例如一个月、两周)，从与该用户存在好友关系的用户好友中，统计每个用户好友与该用户的聊天次数以及聊天频率，即可以确定每个用户好友与该用户的信息交互状况，确定与该用户的聊天次数以及聊天频率不小于预设阈值的用户好友为绑定关系对象。
另外，还可以判断该用户是否开启亲情账户，若是，则确定亲情账户中包括的成员为绑定关系对象；若否，则可以提示该用户开启亲情账户。
例如，经过判断得知用户A已开启亲情账户，亲情账户中包含的成员为父亲、母亲、女儿，则可以确定父亲、母亲、女儿为绑定关系对象。
S3，向绑定关系发起方推荐所确定的绑定关系对象，以使绑定关系发起方优先选择所确定的绑定关系对象；
针对S2中所确定的绑定关系对象，向绑定关系发起方推荐所确定的绑定关系对象， 即向该用户推荐所确定的绑定关系对象，以使绑定关系发起方优先选择所确定的绑定关系对象。
例如，所确定的绑定关系对象为用户B、用户C、用户D，向用户A推荐所确定的绑定关系对象：用户B、用户C、用户D，以使用户A优先选择用户B、用户C、用户D。
S4，根据绑定关系发起方所选择的绑定关系对象，向所选择的绑定关系对象发送绑定关系请求，以使所选择的绑定关系对象同意与绑定关系发起方绑定关系；
针对S3中所推荐的绑定关系对象，绑定关系发起方可能选择其中的一个或多个，或者直接从与自身存在好友关系的用户好友中选择其中的一个或多个，即忽略所推荐的绑定关系对象，或者在所推荐的绑定关系对象以及与自身存在好友关系的用户好友中选择其中的多个。
根据绑定关系发起方所选择的绑定关系对象，向选择的绑定关系对象发送绑定关系请求，其中可以按照预设的发送规则向所选择的绑定关系对象发送绑定关系请求，以使所选择的绑定关系对象同意与绑定关系发起方绑定关系。其中可以按照以下规则向所选择的绑定关系对象发送绑定关系请求：
待绑定关系发起方选择绑定关系对象完毕之后，以广播的形式一次性向所选择的绑定关系对象发送绑定关系请求，或者依照绑定关系发起方选择绑定关系对象的顺序，以单播的形式依次向所选择的绑定关系对象发送绑定关系请求，具体的发送规则多种多样，本说明书对此不作限定。
S5，接收所选择的绑定关系对象返回的响应通知，建立绑定关系发起方与绑定关系对象之间的绑定关系。
向所选择的绑定关系对象发送绑定关系请求之后，绑定关系对象接收到该绑定关系请求之后，进行授权，向服务端返回响应通知，服务端接收到绑定关系发起方所选择的绑定关系对象返回的响应通知后，判断该响应通知为同意绑定，依据绑定关系发起方的基本信息(如姓名、年龄、用户账户等)以及绑定关系对象的基本信息，建立绑定关系发起方与绑定关系对象之间的绑定关系。
例如，在接收到用户B、用户C、用户D各自返回的响应通知之后，判断该响应通知为同意绑定，依据绑定关系发起方A的基本信息，以及用户B的基本信息、用户C的基本信息、用户D的基本信息分别建立绑定关系，如用户A-用户B、用户A-用户C、 用户A-用户D。
另外，在绑定关系建立完成之后，提示绑定关系发起方绑定关系已建立，在绑定关系发起方的账户下会标记与自身建立绑定关系的对象。
基于上述的绑定关系的建立方法，如图1所示，为本说明书提供的一种基于绑定关系的联合支付方法的流程示意图，该方法具体可以包括以下步骤：
S101，客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
当用户选择相应的联合对象之后，客户端向服务端发送联合支付请求，该联合支付请求中携带联合支付发起方以及当次联合对象对应的标识，该用户即联合支付发起方，该当次联合对象即该用户选择的联合对象，该用户选择的联合对象可能是与自身建立绑定关系的对象，也可以是用户自身的用户好友。
例如，用户A当次选择的联合对象是父亲、母亲，下次选择的联合对象可能是父亲，客户端向服务端发送联合支付请求，该联合支付请求中携带用户A的标识、父亲的标识、母亲的标识，这里标识可以是姓名、年龄、用户账户等，即可以唯一标明用户身份的信息。
S102，服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
服务端接收联合支付请求，解析其中携带的联合支付发起方标识以及当次联合对象的标识，例如解析用户A的标识：李三、35、1306……，用户B的标识：张三、55、1306……，用户C的标识：李四、56、1306……。
S103，服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
针对S102中解析得到的联合支付发起方标识以及当次联合对象对应的标识，可以根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系。
具体的，可以依据根据联合支付发起方标识以及当次联合对象对应的标识，查找是否存在联合支付发起方与当次联合对象之间的绑定关系，例如联合支付发起方用户A对应的标识为李三、35、1306……，当次联合对象用户B对应的标识为张三、55、1306……， 经过查找李三与张三已存在绑定关系(李三、35、1306……-张三、55、1306……)，即表明联合支付发起方用户A与当次联合对象用户B之间已建立绑定关系。
S104，若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；
若联合支付发起方与当次联合对象之间已建立绑定关系，根据联合支付发起方标识以及当次联合对象对应的标识，服务端随机生成与联合支付发起方、当次联合对象分别对应的图形码，这里的图形码可以是二维码、条形码等。
将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，优选的，服务端随机生成的与联合支付发起方、当次联合对象分别对应的图形码可以存在有效期，例如一分钟，一分钟之后，服务端再次随机生成与联合支付发起方、当次联合对象分别对应的图形码，向客户端发送更新图形码的通知，将新生成的与联合支付发起方、当次联合对象分别对应的图形码发送至客户端。
若联合支付发起方与当次联合对象之间没有建立绑定关系，则提示联合支付发起方联合支付失败，并引导联合支付发起方与当次联合对象之间建立绑定关系。这里联合支付发起方与当次联合对象之间没有建立绑定关系存在的情况可能是当次联合对象全部没有与联合支付发起方建立绑定关系，或者部分没有与联合支付发起方建立绑定关系。具体引导联合支付发起方与当次联合对象之间建立绑定关系可以通过以下方式：
服务端从当次联合对象中确定与联合支付发起方没有建立绑定关系的联合对象，向客户端发送建立绑定关系的消息，用于通知联合支付发起方与所确定的联合对象建立绑定关系，在联合支付发起方选择所确定的联合对象并确认之后，服务端向所确定的联合对象发送绑定关系请求，在接收到所确定的联合对象返回的响应通知后，建立联合支付发起方与所确定的联合对象之间的绑定关系，并告知联合支付发起方绑定关系已建立。
S105，客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
客户端接收服务端发送的与联合支付发起方、当次联合对象分别对应的图形码，按照预设的展示规则展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。此时联合支付发起方可使用自身的智能终端使用自身的图形码为自身完成支付，使用自身的智能终端使用联合对象对应的图形码，为联合对象完成支付，即在联合支付发起方一个人的智能终端上可以对多个用户进行联合支付，具体产生的支付金额可以直 接从联合支付发起方的账户中扣除，也可以分别从联合支付发起方、联合对象各自的账户中扣除，本说明书对此不作限定。
这里预设的展示规则可以是按照预设的时间间隔自动依次展示与联合支付发起方、当次联合对象分别对应的图形码，也可以是以菜单的形式展示与联合支付发起方、当次联合对象分别对应的图形码，如图2所示，供联合支付发起方选择相应图形码，具体的展示规则多种多样，本说明书再次不再一一赘述。
通过上述对本说明书提供的技术方案的描述，客户端向服务端发送联合支付请求，服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识，并根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码并发送至客户端，客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。如此一来，用户可通过自身的智能终端可以为多个用户分别展示各自对应的图形码以完成联合支付。
为了更清楚的说明本说明书实施例的方案，下面分别从单侧的角度，对执行的方法进行说明：
对于客户端，需要执行的任务主要如下：
A，向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
B，接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
对于服务端，需要执行的任务主要如下：
a，解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
b，根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
c，若是，生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端。
关于客户端、服务端的单侧执行方法细节，可以参见前面实施例的描述，这里不再赘述。
相对于上述方法实施例，本说明书实施例还提供一种基于绑定关系的联合支付装置，应用于客户端，如图3所示，该装置包括：请求发送模块310、图形码接收模块320、图形码展示模块330。
请求发送模块310，用于向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
图形码接收模块320，用于接收与联合支付发起方、当次联合对象分别对应的图形码，所述与联合支付发起方、当次联合对象分别对应的图形码为：服务端根据联合支付请求携带的联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码；
图形码展示模块330，用于展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
本说明书还提供一种基于绑定关系的联合支付装置，应用于服务端，如图4所示，该装置包括：请求接收模块410、标识解析模块420、判断模块430、图形码生成模块440。
请求接收模块，用于接收客户端发送的联合支付请求；
标识解析模块，用于解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
判断模块，用于根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
图形码生成模块，用于若是，生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，以使客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
本说明书还提供一种基于绑定关系的联合支付系统，该系统包括：客户端以及服务端；
客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；
客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
通过上述对本说明书提供的技术方案的描述，客户端向服务端发送联合支付请求，服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识，并根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码并发送至客户端，客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。如此一来，用户可通过自身的智能终端可以为多个用户分别展示各自对应的图形码以完成联合支付。
本说明书实施例还提供一种计算机设备，如图5所示，该设备可以包括：处理器510、存储器520、输入/输出接口530、通信接口540和总线550。其中处理器510、存储器520、输入/输出接口530和通信接口540通过总线550实现彼此之间在设备内部的通信连接。
处理器510可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。
存储器520可以采用ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器520可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例 所提供的技术方案时，相关的程序代码保存在存储器520中，并由处理器510来调用执行。
输入/输出接口530用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。
通信接口540用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。
总线550包括一通路，在设备的各个组件(例如处理器510、存储器520、输入/输出接口530和通信接口540)之间传输信息。
需要说明的是，尽管上述设备仅示出了处理器510、存储器520、输入/输出接口530、通信接口540以及总线550，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的基于绑定关系的联合支付方法。该方法至少包括：
一种基于绑定关系的联合支付方法，应用于客户端，该方法包括：
向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
接收与联合支付发起方、当次联合对象分别对应的图形码，所述与联合支付发起方、当次联合对象分别对应的图形码为：服务端根据联合支付请求携带的联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码；
展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的基于绑定关系的联合支付方法。该方法至少包括：
一种基于绑定关系的联合支付方法，应用于服务端，该方法包括：
接收客户端发送的联合支付请求；
解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，以使客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。

Claims (14)

  1. 一种基于绑定关系的联合支付方法，该方法包括：
    客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
    服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
    服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
    若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；
    客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  2. 根据权利要求1所述的方法，所述若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，包括：
    若是，服务端随机生成与联合支付发起方、当次联合对象分别对应的图形码。
  3. 根据权利要求1所述的方法，所述展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付，包括：
    按照预设的展示规则展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  4. 根据权利要求1所述的方法，所述方法还包括：
    若联合支付发起方与当次联合对象之间没有建立绑定关系，则提示联合支付发起方联合支付失败，并引导联合支付发起方与当次联合对象之间建立绑定关系。
  5. 一种基于绑定关系的联合支付方法，应用于客户端，该方法包括：
    向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
    接收与联合支付发起方、当次联合对象分别对应的图形码，所述与联合支付发起方、当次联合对象分别对应的图形码为：服务端根据联合支付请求携带的联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码；
    展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  6. 一种基于绑定关系的联合支付方法，应用于服务端，该方法包括：
    接收客户端发送的联合支付请求；
    解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
    根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
    若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，以使客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  7. 一种基于绑定关系的联合支付系统，该系统包括：客户端以及服务端；
    客户端向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
    服务端解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
    服务端根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
    若是，服务端生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端；
    客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  8. 根据权利要求7所述的系统，所述服务端具体通过以下方式生成与联合支付发起方、当次联合对象分别对应的图形码：
    若是，服务端随机生成与联合支付发起方、当次联合对象分别对应的图形码。
  9. 根据权利要求7所述的系统，所述客户端具体通过以下方式展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付：
    按照预设的展示规则展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  10. 根据权利要求7所述的系统，所述系统还包括：
    若联合支付发起方与当次联合对象之间没有建立绑定关系，则提示联合支付发起方联合支付失败，并引导联合支付发起方与当次联合对象之间建立绑定关系。
  11. 一种基于绑定关系的联合支付装置，应用于客户端，该装置包括：
    请求发送模块，用于向服务端发送联合支付请求，所述联合支付请求中携带联合支付发起方标识以及当次联合对象对应的标识；
    图形码接收模块，用于接收与联合支付发起方、当次联合对象分别对应的图形码，所述与联合支付发起方、当次联合对象分别对应的图形码为：服务端根据联合支付请求携带的联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系，若是，生成与联合支付发起方、当次联合对象分别对应的图形码；
    图形码展示模块，用于展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  12. 一种基于绑定关系的联合支付装置，应用于服务端，该装置包括：
    请求接收模块，用于接收客户端发送的联合支付请求；
    标识解析模块，用于解析所接收到的联合支付请求中携带的联合支付发起方标识以及当次联合对象对应的标识；
    判断模块，用于根据联合支付发起方标识以及当次联合对象对应的标识，判断联合支付发起方与当次联合对象之间是否已建立绑定关系；
    图形码生成模块，用于若是，生成与联合支付发起方、当次联合对象分别对应的图形码，并将与联合支付发起方、当次联合对象分别对应的图形码发送至客户端，以使客户端接收与联合支付发起方、当次联合对象分别对应的图形码，展示与联合支付发起方、当次联合对象分别对应的图形码以完成联合支付。
  13. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求5所述的方法。
  14. 一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如权利要求6所述的方法。
PCT/CN2019/110513 2018-11-28 2019-10-11 一种基于绑定关系的联合支付方法及系统 WO2020108109A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
SG11202100837PA SG11202100837PA (en) 2018-11-28 2019-10-11 Joint payment method and system based on binding relationship
PH12021550200A PH12021550200A1 (en) 2018-11-28 2021-01-27 Joint payment method and system based on binding relationship
US17/163,068 US11501280B2 (en) 2018-11-28 2021-01-29 Joint payment method and system based on binding relationship

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811430699.XA CN110046882A (zh) 2018-11-28 2018-11-28 一种基于绑定关系的联合支付方法及系统
CN201811430699.X 2018-11-28

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/163,068 Continuation US11501280B2 (en) 2018-11-28 2021-01-29 Joint payment method and system based on binding relationship

Publications (1)

Publication Number Publication Date
WO2020108109A1 true WO2020108109A1 (zh) 2020-06-04

Family

ID=67273650

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/110513 WO2020108109A1 (zh) 2018-11-28 2019-10-11 一种基于绑定关系的联合支付方法及系统

Country Status (6)

Country Link
US (1) US11501280B2 (zh)
CN (1) CN110046882A (zh)
PH (1) PH12021550200A1 (zh)
SG (1) SG11202100837PA (zh)
TW (1) TWI709930B (zh)
WO (1) WO2020108109A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111914583A (zh) * 2020-07-13 2020-11-10 杭州海康机器人技术有限公司 图形码的识别方法、装置以及设备
CN114037036A (zh) * 2021-11-04 2022-02-11 腾讯科技（深圳）有限公司 图形码处理方法、装置、计算机设备和存储介质

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110046882A (zh) * 2018-11-28 2019-07-23 阿里巴巴集团控股有限公司 一种基于绑定关系的联合支付方法及系统
CN113011891B (zh) * 2021-03-22 2023-03-21 支付宝（中国）网络技术有限公司 应用于关联支付的核身处理方法及装置
CN113160438B (zh) * 2021-04-30 2023-01-20 中国银行股份有限公司 一种账户绑定方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110251922A1 (en) * 2010-04-09 2011-10-13 Payasone Llc Multi-party payment object oriented system and method
US20140351118A1 (en) * 2013-05-21 2014-11-27 Lucy Ma Zhao Multi-payer payment system
CN107545425A (zh) * 2016-06-24 2018-01-05 华为软件技术有限公司 一种支付方法和装置
CN108335098A (zh) * 2018-01-24 2018-07-27 阿里巴巴集团控股有限公司 一种多人付款的方法和装置
CN108596597A (zh) * 2018-04-26 2018-09-28 维沃移动通信有限公司 一种支付方法及移动终端
CN110046882A (zh) * 2018-11-28 2019-07-23 阿里巴巴集团控股有限公司 一种基于绑定关系的联合支付方法及系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1452131A (zh) * 2002-04-19 2003-10-29 黄庆祥 二维条码网络券产生系统
US20120150740A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for processing gift transfers via a social network
US8280788B2 (en) * 2009-10-29 2012-10-02 Visa International Service Association Peer-to-peer and group financial management systems and methods
US8326769B1 (en) * 2011-07-01 2012-12-04 Google Inc. Monetary transfer in a social network
US10127563B2 (en) * 2011-09-15 2018-11-13 Stephan HEATH System and method for providing sports and sporting events related social/geo/promo link promotional data sets for end user display of interactive ad links, promotions and sale of products, goods, gambling and/or services integrated with 3D spatial geomapping, company and local information for selected worldwide locations and social networking
US10380629B2 (en) * 2012-05-25 2019-08-13 Microsoft Technology Licensing, Llc Leveraging a social graph to deliver relevant recommendations
US20140201067A1 (en) * 2013-01-14 2014-07-17 Hooko Limited System and method for facilitating a transaction
US20170011029A1 (en) * 2013-05-09 2017-01-12 Moodwire, Inc. Hybrid human machine learning system and method
US9953311B2 (en) * 2013-09-25 2018-04-24 Visa International Service Association Systems and methods for incorporating QR codes
US20150242911A1 (en) * 2014-02-25 2015-08-27 Ebay Inc. Group check in
US10997592B1 (en) * 2014-04-30 2021-05-04 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
CN105654293B (zh) * 2014-12-03 2020-01-17 阿里巴巴集团控股有限公司 支付方法及装置
US20160180316A1 (en) * 2014-12-17 2016-06-23 Facebook, Inc. Techniques to automatically predict and configure payment transactions
KR102557801B1 (ko) * 2016-02-04 2023-07-21 삼성전자주식회사 휴대 장치 및 휴대 장치의 전자 결제방법
CN106897341A (zh) * 2016-07-08 2017-06-27 阿里巴巴集团控股有限公司 二维码信息查询方法、服务器、客户端及系统
CA3080883A1 (en) * 2016-10-31 2018-05-03 Kevin Kelly Drive-thru / point-of-sale automated transaction technologies and apparatus
US10496995B2 (en) * 2017-05-01 2019-12-03 Facebook, Inc. Facilitating payment transactions between users of a plurality of payment providers
WO2019079290A1 (en) * 2017-10-18 2019-04-25 Walmart Apollo, Llc ENGINE OF GROUPED PURCHASING RULES
CN108022162A (zh) * 2017-12-28 2018-05-11 深圳春沐源控股有限公司 酒店自助选房入住方法、装置、终端及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110251922A1 (en) * 2010-04-09 2011-10-13 Payasone Llc Multi-party payment object oriented system and method
US20140351118A1 (en) * 2013-05-21 2014-11-27 Lucy Ma Zhao Multi-payer payment system
CN107545425A (zh) * 2016-06-24 2018-01-05 华为软件技术有限公司 一种支付方法和装置
CN108335098A (zh) * 2018-01-24 2018-07-27 阿里巴巴集团控股有限公司 一种多人付款的方法和装置
CN108596597A (zh) * 2018-04-26 2018-09-28 维沃移动通信有限公司 一种支付方法及移动终端
CN110046882A (zh) * 2018-11-28 2019-07-23 阿里巴巴集团控股有限公司 一种基于绑定关系的联合支付方法及系统

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111914583A (zh) * 2020-07-13 2020-11-10 杭州海康机器人技术有限公司 图形码的识别方法、装置以及设备
CN111914583B (zh) * 2020-07-13 2022-07-29 杭州海康机器人技术有限公司 图形码的识别方法、装置以及设备
CN114037036A (zh) * 2021-11-04 2022-02-11 腾讯科技（深圳）有限公司 图形码处理方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
PH12021550200A1 (en) 2021-10-18
CN110046882A (zh) 2019-07-23
US20210150509A1 (en) 2021-05-20
SG11202100837PA (en) 2021-03-30
TW202030662A (zh) 2020-08-16
US11501280B2 (en) 2022-11-15
TWI709930B (zh) 2020-11-11

Similar Documents

Publication Publication Date Title
WO2020108109A1 (zh) 一种基于绑定关系的联合支付方法及系统
US10726458B2 (en) Peer-assisted shopping
US20170061561A1 (en) Mobile ride-sharing social networking e-commerce platform
US10235663B2 (en) Method, system and server system of payment based on a conversation group
JP2016541075A (ja) ピア支援電子商取引ショッピングの装置及び方法
CN110072151B (zh) 虚拟礼物展示方法、电子设备及计算机可读存储介质
CN109118315A (zh) 基于信用担保的业务处理方法、装置以及设备
CN109831314B (zh) 用于建立用户群的方法和设备
TW201403502A (zh) 實施名片應用方法及裝置
US20240028695A1 (en) Function Migration Method and Apparatus
CN111147872A (zh) 信息展示方法、装置和电子设备
JP2020126545A (ja) 情報処理方法、情報処理装置、及び情報処理プログラム
KR20160147001A (ko) 근접 기반 컴퓨팅 장치 간 협상 기법
US20240077992A1 (en) Interaction method, and electronic device
CN114402348A (zh) 系统
US20180349940A1 (en) Sns-linked reward granting system, sns-linked reward granting method and sns-linked reward granting program
US20140351135A1 (en) Registration process
JP2020123098A (ja) 情報処理方法、情報処理装置、及びプログラム
TW201918961A (zh) 業務對象處理、頁面提供方法及裝置
CN108985831A (zh) 一种线下交易的判别方法、装置、及计算机设备
JP6026703B2 (ja) ルータアクセス制御方法、装置、ルータ、プログラム、及び記録媒体
CN112330315A (zh) 一种支付信息处理方法、装置、电子设备及存储介质
CN111861645A (zh) 付费电子书籍解锁方法、设备及计算机可读介质
KR101746785B1 (ko) 모바일 단말의 위치 기반 온라인 커뮤니티 서비스 제공 방법, 모바일 단말, 서비스 제공 서버 및 기록매체
CN111429131A (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: 19890265

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: 19890265

Country of ref document: EP

Kind code of ref document: A1