WO2022237606A1 - 在支付时使用电子券的方法及装置 - Google Patents

在支付时使用电子券的方法及装置 Download PDF

Info

Publication number
WO2022237606A1
WO2022237606A1 PCT/CN2022/090861 CN2022090861W WO2022237606A1 WO 2022237606 A1 WO2022237606 A1 WO 2022237606A1 CN 2022090861 W CN2022090861 W CN 2022090861W WO 2022237606 A1 WO2022237606 A1 WO 2022237606A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
payment
merchant
user
electronic coupon
Prior art date
Application number
PCT/CN2022/090861
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 WO2022237606A1 publication Critical patent/WO2022237606A1/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/38—Payment protocols; Details thereof
    • G06Q20/387—Payment using discounts or coupons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G06F16/90335—Query processing

Definitions

  • a method for using electronic coupons in payment is proposed, which is applied to a payment platform, and the method includes: receiving a payment request, and receiving a payment request from the Determine the target user and target merchant corresponding to the payment request in the payment request; query the target electronic coupons owned by the target user corresponding to the target merchant according to the established tripartite correspondence between users, merchants and electronic coupons ; Pay by using the queried target electronic coupon.
  • a device for using electronic coupons in payment which is applied to a target merchant, and the device includes: a first generation unit, configured to generate a payment request, and the payment request includes the target user the information of the target merchant and the information of the target merchant; the first sending unit is used to send the payment request to the payment platform, so that the payment platform can determine that the target user has corresponding to the target electronic coupon of the target merchant, and use the target electronic coupon for payment.
  • an electronic device including: a processor; a memory for storing processor-executable instructions; wherein, the processor executes the executable instructions to implement the above-mentioned first aspect The method described in the examples.
  • a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the above-mentioned embodiments of the first aspect are implemented.
  • Fig. 1 is a schematic diagram of the network architecture of the electronic coupon system used in payment according to the embodiment of this specification;
  • Fig. 2 is a flow chart of the first method for using electronic coupons during payment according to an exemplary embodiment of this specification
  • Fig. 3 is a flowchart of a second method for using electronic coupons during payment according to an exemplary embodiment of the present specification
  • Fig. 4 is a flowchart of a third method for using electronic coupons during payment according to an exemplary embodiment of this specification
  • Fig. 6 is a flow chart of multi-party interaction showing another method of using electronic coupons during payment according to an exemplary embodiment of this specification
  • Fig. 7 is a schematic diagram of a device for using electronic coupons during payment according to an exemplary embodiment of this specification.
  • Fig. 8 is a block diagram of a first device for using electronic coupons during payment according to an exemplary embodiment of this specification
  • Fig. 9 is a block diagram of a second device for using electronic coupons during payment according to an exemplary embodiment of this specification.
  • Fig. 10 is a block diagram of a third device for using electronic coupons during payment according to an exemplary embodiment of this specification.
  • first, second, third, etc. may be used in this specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word “if” as used herein may be interpreted as “at” or “when” or “in response to a determination.”
  • Fig. 1 is a schematic structural diagram of a system for using electronic coupons during payment provided by an exemplary embodiment.
  • the system may include a payment platform 11, a target merchant 12, a target user 13, a network 14, and the like.
  • the payment platform can not only realize the electronic payment function, but also serve as an integrated functional platform for many other functions, such as instant messaging function, physical or virtual commodity purchase function, resource transfer function, etc., one of the functions disclosed in this specification or multiple embodiments are not limited thereto.
  • the relevant functions of the payment platform 11 can be implemented by a physical server of an independent host, or the server can be a virtual server carried by a host cluster.
  • the above-mentioned server can run the server-side program of the payment application to realize the relevant business functions of the application.
  • the server runs the program of the payment platform 11, it can be implemented as the server of the payment application.
  • the target merchant 12 can be represented as a service end corresponding to a management client with a communication function used by any merchant, or can be represented as a merchant management platform with a communication function that can manage multiple merchants.
  • the target merchant 12 can communicate with
  • the payment platform 11 communicates, manages and distributes the merchant's electronic coupons.
  • the target user 13 can be represented as a client corresponding to the server of the payment platform 11, which runs the program on the client side of the payment application, and cooperates with the payment platform 11 to realize various functions of the payment application.
  • the client of the target user 13 can run on various electronic devices, such as mobile phones, tablet devices, notebook computers, handheld computers (PDAs, Personal Digital Assistants), wearable devices (such as smart glasses, smart watches, etc.), of course,
  • PDAs Personal Digital Assistants
  • wearable devices such as smart glasses, smart watches, etc.
  • the network 14 for interaction between the payment platform 11, the merchant platform 12, and the user client 13 may include various types of wired or wireless networks.
  • the network 12 may include a public switched telephone network (Public Switched Telephone Network, PSTN) and the Internet.
  • PSTN Public Switched Telephone Network
  • the above-mentioned three-party corresponding relationship can be established in another way. It is still assumed that the merchant platform manages multiple offline merchants in a unified manner. Users can receive electronic coupons at the merchant platform. ID, and then generate an independent correspondence between the user ID and the e-coupon ID received by him and the offline merchant information corresponding to the e-coupon. The relationship is synchronized to the payment platform, and the payment platform aggregates the independent corresponding relationships synchronized by different merchant platforms to form a tripartite corresponding relationship between each merchant, user, and electronic coupon. Alternatively, the payment platform may not aggregate the independent corresponding relationships, that is, In the payment platform, each offline merchant can correspond to a type of three-party correspondence, which is not limited in this manual. It is worth noting that the user can also receive the e-voucher corresponding to the offline merchant from the offline store, and the offline store can generate the above independent corresponding relationship and synchronize it to the payment platform, which is not limited in this manual.
  • the above-mentioned target electronic coupons can be used for deduction when the user pays. Since there may be restrictions on the use of electronic coupons in one or more dimensions, such as amount restrictions, that is, they can only be used when the payment amount meets a certain amount; frequency restrictions, that is, the number of times that electronic coupons can be used; use time restrictions, that is, electronic coupons can be used time period; product restrictions, that is, it can only be used when the order contains a certain brand and type of product; therefore, it is necessary to check the use conditions of the target e-coupon before use, and use it when it is confirmed that the e-coupon can be used Target e-coupon for payment.
  • amount restrictions that is, they can only be used when the payment amount meets a certain amount
  • frequency restrictions that is, the number of times that electronic coupons can be used
  • use time restrictions that is, electronic coupons can be used time period
  • product restrictions that is, it can only be used when the order contains a certain brand and type of product
  • the electronic coupon closest to the expiration date can be used first, etc., can be sorted according to a single factor, or can be sorted according to a variety of factors to determine the electronic coupon. Coupon priority. Certainly, when the discounts among the electronic coupons do not conflict, multiple electronic coupons can be used at the same time, so that the target user can get the best discount.
  • this manual establishes a three-party corresponding relationship between users, electronic coupons and merchants, so that the payment platform can inquire about the three-party corresponding relationship it owns when the user makes a payment.
  • the e-coupons of specific merchants can be automatically deducted during payment.
  • This manual eliminates the cumbersome steps for users to manually select e-coupons, making the payment process simpler and faster, and improving the efficiency of electronic payment; moreover, the payment platform or target merchants can The verification of the use status and conditions of the electronic coupons is completed, which improves the accuracy of the use of electronic coupons, and does not require staff or users to manually check the electronic coupons, further improving the efficiency of payment.
  • the multiple checks of the three-party correspondence between the payment platform and the target merchant it is possible to prevent counterfeit electronic coupons from being used normally, improve the security of the payment process, and reduce the risk of property losses suffered by the payment platform and merchants.
  • the target merchant in the scenario where the user pays at an offline merchant, can use scanning or other methods to identify the payment code displayed by the user in the form of a payment barcode or a payment QR code.
  • the code contains the user ID, and then the background server corresponding to the offline merchant (or the background server of the unified management platform of the offline merchant) can generate a payment request, and can send the offline merchant's own PMS and the payment obtained from the payment code
  • the user ID is included in the payment request sent to the payment platform.
  • Step 304 Send the payment request to the payment platform, so that the payment platform can determine the target electronic coupons owned by the target user corresponding to the target merchants according to the established tripartite correspondence between users, merchants and electronic coupons, and use The target electronic coupon is used for payment.
  • one or more e-vouchers may be queried based on the above-mentioned tripartite relationship.
  • the electronic coupons can be screened according to the payment request to determine the available electronic coupons for payment.
  • the association between the electronic coupon ID and its corresponding offline merchant information (such as PMS) is called the first correspondence
  • the merchant platform synchronizes the above-mentioned first correspondence to the payment platform
  • the user can receive the electronic voucher through the payment platform, thereby establishing the second corresponding relationship between the user ID and the electronic voucher ID.
  • the correspondence among the user ID, the coupon ID, and the offline merchant can be generated.
  • the electronic coupons can be issued uniformly by the merchant management platform that uniformly manages multiple offline merchants, or each offline merchant can issue electronic coupons and synchronize the above-mentioned first correspondence to the payment platform.
  • the subject can be flexibly adjusted according to the specific rules of the merchant platform, which does not affect the implementation of this method, so this specification does not limit it.
  • the payment platform can synchronize the user's coupon collection information, that is, the association between the electronic coupon and the user, to the corresponding target merchant when the user receives the electronic coupon, so that the target merchant can establish a tripartite relationship between the electronic coupon, the user, and the merchant.
  • the payment platform inquires about the target electronic coupon that can be used, it will feed back the PMS of the target user, coupon ID, and offline merchant corresponding to the target electronic coupon to the target merchant, so that the target merchant can check according to the three-party corresponding relationship, check After correctness, notify the payment platform that the target electronic coupon can be used for payment.
  • the payment platform can synchronize the user's coupon collection information, that is, the association between the electronic coupon and the user, to the corresponding target merchant when the user receives the electronic coupon, so that the target merchant can establish a tripartite relationship between the electronic coupon, the user, and the merchant.
  • the payment platform inquires about the target electronic coupon that can be used, it will feed back the PMS of the target user, coupon
  • the payment platform maintains the corresponding relationship between users, merchants and electronic coupons for query.
  • a user may have multiple electronic coupons corresponding to different offline merchants, and merchants may also issue different
  • the above-mentioned three-party correspondence represents a specific electronic coupon owned by a specific user and usable in a specific offline merchant. Therefore, the payment platform can match the target user with the user information in the above correspondence, and match the target merchant with the merchant information in the above correspondence. When both of the above can be successfully matched, the above correspondence can be used to lock The target user owns the e-voucher corresponding to the target merchant.
  • the above-mentioned three-party corresponding relationship can be established in another way. It is still assumed that the merchant platform manages multiple offline merchants in a unified manner. Users can receive electronic coupons at the merchant platform. ID, and then generate an independent correspondence between the user ID and the e-coupon ID received by him and the offline merchant information corresponding to the e-coupon. The relationship is synchronized to the payment platform, and the payment platform aggregates the independent corresponding relationships synchronized by different merchant platforms to form a tripartite corresponding relationship between each merchant, user, and electronic coupon. Alternatively, the payment platform may not aggregate the independent corresponding relationships, that is, In the payment platform, each offline merchant can correspond to a type of three-party correspondence, which is not limited in this manual. It is worth noting that the user can also receive the e-voucher corresponding to the offline merchant from the offline store, and the offline store can generate the above independent corresponding relationship and synchronize it to the payment platform, which is not limited in this manual.
  • the target electronic coupon when the target electronic coupon satisfies the use conditions and the status of the target electronic coupon is usable, the target electronic coupon can be used in the subsequent payment process, for example, the payment can be made according to the usage rules of the target electronic coupon The amount is modified so that the target user obtains an interface containing the modified payment amount, and when the target user checks that the amount is correct, the payment can be confirmed to complete the payment process.
  • Fig. 5 is a multi-party interaction flow chart showing a method for using electronic coupons during payment according to an exemplary embodiment of this specification.
  • the interaction process between the payment platform 51, the target merchant 52, and the target user 53 includes the following steps: Steps 502-506, in the scenario of offline payment, the target merchant 62 can scan the payment code provided by the user.
  • the above payment code can be in the form of a barcode, a two-dimensional code or any graphic that can record data symbol information and perform subsequent payment operations. This manual does not limit the specific form of the payment code.
  • the target merchant 52 scans the payment code provided by the target user 53, it internally performs the order placing operation shown in step 504, and generates a payment request.
  • the target merchant can include the PMS (or other information that can uniquely identify the merchant) of the offline merchant where the current target user is located, and the user ID obtained from the payment code in the payment The request is sent to the payment platform 61.
  • Step 508 after receiving the payment request, the payment platform 51 extracts the target user and target merchant information contained therein, that is, determines the user ID of the current order and the PMS of the offline merchant corresponding to the order, and stores the above two information Match with the three-party correspondence between merchants, users, and electronic coupons maintained by the payment platform 51, and use the electronic coupons corresponding to the successfully matched three-party correspondences as the target electronic coupons.
  • the payment platform 51 can receive the first corresponding relationship between the electronic coupons to be collected and the PMS of the corresponding offline merchants that are synchronized by each merchant.
  • the target merchant 52 A certain number of e-vouchers are issued, each e-voucher has a unique identification, called coupon ID, and each e-voucher corresponds to a specific offline merchant, that is, the above-mentioned e-vouchers can be used in its corresponding offline Used in merchants, assuming that the target merchant 52 here is the background server independently used by the current offline merchant, then the relationship between the coupon ID and the PMS corresponding to the target merchant 52 is called the first correspondence, and the target merchant 52 can synchronize
  • the first correspondence is to the payment platform 51, and the user can receive the electronic coupon through the payment platform 51, so as to establish the second correspondence between the user ID and the coupon ID.
  • the correspondence among the user ID, the coupon ID, and the PMS of the offline merchant can be generated.
  • the user can receive the electronic voucher at the target merchant 52, and the target merchant can pull the user ID when receiving, and then generate an independent correspondence between the user ID and the coupon ID received and the PMS corresponding to the target merchant.
  • the above independent correspondence indicates that the user , electronic coupons, and merchants, and then the target merchant 52 synchronizes the above-mentioned independent correspondences to the payment platform, and the payment platform aggregates the synchronized independent correspondences of different target merchants to form a relationship between each merchant, the user, and the electronic coupons.
  • the three-party corresponding relationship, or the payment platform may not aggregate independent corresponding relationships, that is, on the payment platform, each offline merchant may correspond to a type of three-party corresponding relationship, which is not limited in this manual.
  • Step 510 the payment platform returns the coupon ID, target user ID, and PMS to the target merchant.
  • the target merchant 52 can determine the target electronic coupon determined by the payment platform 51 according to the coupon ID, combined with the user ID and PMS, it can check again with the three-party correspondence maintained by itself.
  • Steps 512-514 verify the target electronic coupon and notify the payment platform 51 that the target electronic coupon can be used.
  • the verification of the electronic coupon here includes multiple verifications.
  • the target merchant can determine the target electronic coupon through the coupon ID.
  • the target merchant 52 can check the usage conditions of the target electronic coupon.
  • the target merchant 52 can obtain the order information corresponding to the current payment, and determine whether the current payment meets the target electronic coupon according to the order information. conditions of use; when the target electronic coupons meet the conditions of use, notify the payment platform to use the target electronic coupons for payment, specifically, the use conditions of some electronic coupons and the specific commodities in the order corresponding to the current payment Information is related, in other words, some electronic coupons can only be used when the user purchases some specific products.
  • the target merchant can obtain the specific information of the order corresponding to the current payment, and determine whether the current order meets the usage corresponding to the queried electronic coupon. condition. Or, the target merchant 52 can check the use status of the target electronic coupon, such as checking whether the above-mentioned electronic coupon has been used, or whether it has exceeded the number of times that can be used, etc. Of course, the status of the above-mentioned electronic coupon can be maintained in the payment platform 51 Here, the judgment method will not be repeated here.
  • the payment platform 51 can synchronize the coupon collection information to the target merchant 52 when the user collects the coupon, so that the target merchant 52 can establish a tripartite correspondence between the user ID, PMS, and coupon ID, and send the coupon ID returned by the payment platform, The target user ID, PMS and the three-party correspondence are checked again to prevent the circulation of counterfeit electronic coupons.
  • step 512 after the target merchant 52 has passed the verification of all aspects of the target electronic coupon, it can enter step 514 to notify the payment platform that the target electronic coupon can be used, so as to perform the following other steps.
  • Steps 516-520 when the above-mentioned target electronic coupon is confirmed to be usable, the payment platform 51 can modify the payment amount according to the preset rules in the electronic coupon, and present the modified payment amount to the target user, so that the target user Check the revised payment and confirm the payment.
  • steps 518-520 can also be omitted, and the payment can be made directly according to the modified payment amount.
  • Steps 522-524 after the payment is completed, the payment platform 51 can send a payment notice to the target merchant 52, so that the target merchant 52 can modify the status of the target electronic coupon.
  • the target electronic coupon is an electronic coupon with a preset number of uses
  • the usable times can be reduced by one, so that it can be used when checking the e-coupon next time.
  • the status of the above-mentioned electronic coupons is maintained by the payment platform 51, the status of the above-mentioned electronic coupons can also be changed after the payment is completed, which will not be repeated here.
  • Fig. 6 is a flow chart of multi-party interaction of a method for using electronic coupons during payment according to an exemplary embodiment of the present specification.
  • the interactive process between the payment platform 61, the target merchant 62, and the target user 63 includes the following steps:
  • Steps 602-608 in the scenario of offline payment, the target merchant 62 can pre-order the operation, so that the payment platform 61 generates an order code and returns it to the target merchant 62.
  • the form of the above order code can be barcode, two-dimensional Code and other graphics that can record data symbol information and perform subsequent payment operations. This manual does not limit the specific form of the order code.
  • the target merchant 62 After the target merchant 62 generates the order code, it can be shown to the target user 63, and the target user 63 can generate a payment request through operations such as scanning.
  • the target user 63 can include the PMS (or other information that can uniquely identify the merchant) of the offline merchant where the current target user is located, and its own user ID in the payment request. sent to the payment platform 61.
  • Step 610 after receiving the payment request, the payment platform 61 extracts the target user and target merchant information contained therein, that is, determines the user ID of the current order and the PMS of the offline merchant corresponding to the order, and stores the above two information Matching is performed with the three-party correspondence between merchants, users, and electronic coupons maintained by the payment platform 61 itself, and the electronic coupons corresponding to the successfully matched three-party corresponding relationships are used as target electronic coupons.
  • the payment platform 61 can receive the first corresponding relationship between the electronic coupons to be collected and the PMS of the corresponding offline merchants that are synchronized by each merchant.
  • the target merchant 62 A certain number of e-vouchers are issued, each e-voucher has a unique identification, called coupon ID, and each e-voucher corresponds to a specific offline merchant, that is, the above-mentioned e-vouchers can be used in its corresponding offline Used in merchants, assuming that the target merchant 62 here is the background server used independently by the current offline merchant, then the association between the coupon ID and the PMS corresponding to the target merchant 62 is called the first correspondence, and the target merchant 62 can be synchronized
  • the first correspondence is to the payment platform 61, and the user can receive the electronic coupon through the payment platform 61, so as to establish the second correspondence between the user ID and the coupon ID.
  • the correspondence among the user ID, the coupon ID, and the PMS of the offline merchant can be generated.
  • the user can receive the electronic voucher at the target merchant 62, and the target merchant can pull the user ID when receiving, and then generate an independent correspondence between the user ID and the voucher ID received and the PMS corresponding to the target merchant.
  • the above independent correspondence indicates that the user , electronic coupons, and merchants, and then the target merchant 62 synchronizes the above independent correspondences to the payment platform, and the payment platform aggregates the synchronized independent correspondences of different target merchants to form a relationship between each merchant, user, and electronic coupons.
  • the three-party corresponding relationship, or the payment platform may not aggregate independent corresponding relationships, that is, on the payment platform, each offline merchant may correspond to a type of three-party corresponding relationship, which is not limited in this manual.
  • Step 612 the payment platform returns the coupon ID, target user ID, and PMS to the target merchant.
  • the target merchant 62 can determine the target electronic coupon determined by the payment platform 61 according to the coupon ID, and can check again with the three-party correspondence maintained by itself in combination with the user ID and PMS.
  • Steps 514-516 check the target electronic coupon and notify the payment platform 61 that the target electronic coupon can be used.
  • the verification of the electronic coupon here includes multiple verifications.
  • the target merchant can determine the target electronic coupon through the coupon ID.
  • the target merchant 62 can check the usage conditions of the target electronic coupon.
  • the target merchant 62 can obtain the order information corresponding to the current payment, and determine whether the current payment meets the target electronic coupon according to the order information. conditions of use; when the target electronic coupons meet the conditions of use, notify the payment platform to use the target electronic coupons for payment, specifically, the use conditions of some electronic coupons and the specific commodities in the order corresponding to the current payment Information is related, in other words, some electronic coupons can only be used when the user purchases some specific products.
  • one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.
  • the device for using electronic coupons during payment can be applied to the device shown in FIG. 7 to realize the technical solution of this specification.
  • the device for using electronic coupons during payment may include: a receiving unit 802, configured to receive a payment request, and determine the target user and target merchant corresponding to the payment request from the payment request; a query unit 804, configured to According to the established three-party correspondence between users, merchants and electronic coupons, query the target electronic coupons owned by the target user corresponding to the target merchants; the payment unit 806 is configured to use the queried target electronic coupons Make a payment.
  • the payment request may include: a payment request sent by the target merchant or a payment request sent by the target user.
  • the above-mentioned apparatus may further include: a first correspondence relationship generation unit 808, configured to receive a first correspondence relationship between each merchant’s synchronized electronic coupons to be collected and merchant information of the corresponding merchant; according to the first correspondence relationship, and the second corresponding relationship between received electronic coupons and user information generated by each user receiving the electronic coupons to be received, to generate the three-party corresponding relationship.
  • a first correspondence relationship generation unit 808 configured to receive a first correspondence relationship between each merchant’s synchronized electronic coupons to be collected and merchant information of the corresponding merchant; according to the first correspondence relationship, and the second corresponding relationship between received electronic coupons and user information generated by each user receiving the electronic coupons to be received, to generate the three-party corresponding relationship.
  • the independent corresponding relationship is generated by the merchant based on its own merchant information, the electronic coupons supported by itself and the user information of the user who receives the electronic coupons;
  • the independent correspondences are aggregated to form the three-way correspondence.
  • the above-mentioned second correspondence generating unit 906 can also be used to synchronize the first correspondence between the electronic coupon to be collected and the merchant information of the corresponding merchant to the payment platform, and then make the payment platform according to the first correspondence.
  • the above device may further include: a checking unit 908, configured to check the status of the target electronic coupon according to the status of the electronic coupon maintained by itself and generate a checking result; return the checking result to the payment platform, The payment platform determines whether the target electronic coupon is available, and then uses the target electronic coupon to make payment when the target electronic coupon is available.
  • a checking unit 908 configured to check the status of the target electronic coupon according to the status of the electronic coupon maintained by itself and generate a checking result; return the checking result to the payment platform, The payment platform determines whether the target electronic coupon is available, and then uses the target electronic coupon to make payment when the target electronic coupon is available.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computational Linguistics (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

一种在支付时使用电子券的方法及装置，该方法可以包括：接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户（202）；根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券（204）；使用查询到的所述目标电子券进行支付（206）。通过将用户、电子券与商户之间建立三方对应关系，以使支付平台可以在用户进行支付时，根据上述三方对应关系查询到其拥有的对应于特定商户的电子券，从而在支付时完成自动抵扣，免去了用户手动选择电子券的繁琐步骤，提升了支付效率。

Description

在支付时使用电子券的方法及装置 技术领域
本说明书涉及通信技术领域，特别是在支付时使用电子券的方法及装置。
背景技术
电子支付作为新兴的支付方式，极大的便利了人们的生活。商户为了推广产品、拉动消费，往往会采用在电子支付平台中发放电子券的形式，向消费者提供一定额度的折扣。消费者对电子券进行领取后，需要在进行电子支付时选择可以抵扣的电子券，从而使用选择的电子券完成支付。
然而，由于上述使用电子券的过程依赖于支付时的手动选择，因此，消费者很可能忘记使用电子券，从而造成电子券的使用率低下，并且，使用电子券的繁琐步骤，也降低了支付效率和用户的使用体验。
发明内容
有鉴于此，本说明书提供在支付时使用电子券的方法及装置。
具体的，本说明书通过如下技术方案实现：根据本说明书的第一方面，提出了一种在支付时使用电子券的方法，应用于支付平台，所述方法包括：接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户；根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券；使用查询到的所述目标电子券进行支付。
根据本说明书的第二方面，提出了一种在支付时使用电子券的方法，应用于商户客户端，所述方法包括：生成支付请求，所述支付请求中包含目标用户的信息和所述商户客户端对应的目标商户的信息；向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
根据本说明书的第三方面，提出了一种在支付时使用电子券的方法，应用于用户客户端，所述方法包括：生成支付请求，所述支付请求中包含目标用户的信息和所述商户客户端对应的目标商户的信息；向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
根据本说明书的第四方面，提出了一种在支付时使用电子券的装置，应用于支付平台，所述装置包括：接收单元，用于接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户；查询单元，用于根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券；支付单元，用于使用查询到的所述目标电子券进行支付。
根据本说明书的第五方面，提出了一种在支付时使用电子券的装置，应用于目标商户，所述装置包括：第一生成单元，用于生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；第一发送单元，用于向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
根据本说明书的第六方面，提出了一种在支付时使用电子券的装置，应用于目标用户，所述装置包括：第二生成单元，用于生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；第二发送单元，用于向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
根据本说明书的第七方面，提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，所述处理器通过运行所述可执行指令以实现如上述第一方面的实施例中所述的方法。
根据本说明书实施例的第八方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述第一方面的实施例中所述方法的步骤。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。
图1是应用本说明书实施例的在支付时使用电子券系统的网络架构示意图；
图2是根据本说明书一示例性实施例示出的第一种在支付时使用电子券方法的流程图；
图3是根据本说明书一示例性实施例示出的第二种在支付时使用电子券方法的流程图；
图4是根据本说明书一示例性实施例示出的第三种在支付时使用电子券方法的流程图；
图5是根据本说明书一示例性实施例示出的一种在支付时使用电子券方法的多方交互流程图；
图6是根据本说明书一示例性实施例示出的另一种在支付时使用电子券方法的多方交互流程图；
图7是根据本说明书一示例性实施例示出的一种在支付时使用电子券的设备示意图；
图8是根据本说明书一示例性实施例示出的第一种在支付时使用电子券的装置框图；
图9是根据本说明书一示例性实施例示出的第二种在支付时使用电子券的装置框图；
图10是根据本说明书一示例性实施例示出的第三种在支付时使用电子券的装置框 图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
图1为一示例性实施例提供的一种支付时使用电子券系统的架构示意图。如图1所示，该系统可以包括支付平台11、目标商户12、目标用户13、网络14等。
在本实施例中，支付平台不仅可以实现电子支付功能，还可以作为诸多其他功能的集成化功能平台，比如即时通讯功能、实体或虚拟商品购买功能、资源转移功能等等，本说明书公开的一个或多个实施例并不对此进行限制。
其中，支付平台11的相关功能可以由一独立主机的物理服务器实现，或者该服务器可以为主机集群承载的虚拟服务器。在运行过程中，上述服务器可以运行支付应用的服务器侧的程序，以实现该应用的相关业务功能，比如当该服务器运行支付平台11的程序时，可以实现为该支付应用的服务端。
目标商户12可以表现为任一商户使用的具有通讯功能的管理客户端所对应的服务端，也可以表现为可以管理多个商户的具有通讯功能的商户管理平台，目标商户12可以通过网络14与支付平台11进行通讯，并管理、发放商户的电子券。
目标用户13可以表现为支付平台11的服务端所对应的客户端，其运行支付应用客户端侧的程序，与支付平台11配合实现支付应用的各种功能。目标用户13的客户端可以运行于多种电子设备上，例如手机、平板设备、笔记本电脑、掌上电脑(PDAs，Personal Digital Assistants)、可穿戴设备(如智能眼镜、智能手表等)等，当然，当采用诸如HTML5技术的在线“客户端”时，无需在电子设备上安装相应的应用程序，即可获得并运行该客户端，本说明书一个或多个实施例并不对此进行限制。
而对于支付平台11与商户平台12、用户客户端13之间进行交互的网络14，可以包括多种类型的有线或无线网络。在一实施例中，该网络12可以包括公共交换电话网络 (Public Switched Telephone Network，PSTN)和因特网。
接下来对本说明书实施例进行详细说明。
图2为根据本说明书一示例性实施例示出的一种在支付时使用电子券方法的流程图。如图2所示，该方法应用于支付平台，可以包括如下步骤：步骤102：接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户。
在一实施例中，支付平台接收支付请求，并可以根据支付请求中包含的用户ID将发送支付请求的用户确定为目标用户，上述用户ID可以为用户注册成为支付应用的用户时被分配的唯一性标识。同时，支付平台还可以根据支付请求中包含的商户PMS将上述支付请求所对应的商户确定为目标商户，值得说明的是，PMS为PID、MID和SID的总称，PID代表支付应用签发给机构的Partner ID，MID为机构签发给下属的二级商户的Merchant ID，SID对应线下店铺的Store ID，PMS可以唯一标示一个线下店铺，因此PMS可以作为线下商户的唯一性标识，进而帮助支付平台确定目标商户。另外，本说明书中的目标商户可以指代目标电子券对应的线下商户或是其后台服务器，当线下商户由平台统一管理时，也可以为商户管理平台的后台服务器。
在一实施例中，支付请求可以由商户平台发送或者由用户客户端发送，结合具体的场景而言，线下商户可以利用扫描等方式识别用户展示的付款条形码、付款二维码等形式的付款码，上述付款码中包含用户ID，进而商户平台将线下商户自身的PMS，以及从付款码中获取的用户ID包含于支付请求中发送至支付平台；或者，目标商户平台预先获取订单码，上述订单码可以由商家平台向支付平台发送预下单请求，进而由支付平台响应于预下单请求后生成并返回至商户平台。目标商户获取订单码后展示给目标用户，目标用户可以通过扫描等方式识别目标商户的订单码，上述订单码中包含目标商户的PMS，因此，目标用户可以将自身的用户ID与目标商户的PMS包含于支付请求中进而发送至支付平台。
步骤104：根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券。
在一实施例中，支付平台中维护有用户、商户与电子券之间的对应关系以供查询，例如用户可能拥有多张对应于不同线下商户的电子券，而商户也可能发放了不同的电子券，上述三方对应关系表示了一特定用户拥有的、可在特定的线下商户中使用的特定电子券。因此，可以将目标用户与上述对应关系中的用户信息进行匹配，并将目标商户与上述对应关系中的商户信息进行匹配，当上述两者均可以匹配成功时，可以通过上述对应关系锁定目标用户拥有的对应于目标商户的电子券，由于同一个目标商户可能会发放多种电子券，因此根据上述三方关系查询出的电子券可能为一张或多张，当查询到多张符合条件的电子券时，可以根据支付请求对电子券进行筛选，确定可以使用的电子券进行支付。
在一实施例中，上述三方对应关系可以通过以下步骤建立，支付平台可以接收各个商户分别同步的待领取电子券与相应商户的商户信息之间的第一对应关系，举例而言， 当商户平台统一管理多个线下商户时，假社商户平台发放100张电子券，每张电子券拥有一个唯一性的标识，称为券ID，而每张电子券均对应于一个具体的线下商户，即上述电子券可以在其对应的线下商户中使用，电子券ID与其对应的线下商户信息(例如PMS)之间的关联关系称为第一对应关系，商户平台同步上述第一对应关系至支付平台，用户可以通过支付平台领取电子券，以此建立了用户ID与电子券ID之间的第二对应关系。将上述第一对应关系与第二对应关系相结合，可以生成用户ID、券ID以及线下商户三者之间的对应关系。值得说明的是，可以由统一管理多家线下商户的商户管理平台统一发放电子券，也可以由各个线下商户自行发放电子券并将上述第一对应关系同步至支付平台，电子券的发放主体可以根据商户平台的具体规则灵活调整，并不影响本方法的实施，因此本说明书对此不作限制。
在一实施例中，上述三方对应关系可以通过另一种方式建立，仍然假设商户平台统一管理多个线下商户，用户可以在商户平台处领取电子券，用户领取时，商户平台可以拉取用户ID，进而将用户ID与其领取的电子券ID和电子券对应的线下商户信息生成独立对应关系，上述独立对应关系表示了用户、电子券、商户三方的关联关系，进而商户平台将上述独立对应关系同步至支付平台，支付平台对不同商户平台同步的独立对应关系进行聚合，以形成各个商户与用户、电子券之间的三方对应关系，或者，支付平台也可以不将独立对应关系聚合，即在支付平台中，每个线下商户均可以对应一类三方对应关系，本说明书对此不作限制。值得说明的是，用户也可以从线下店铺处领取对应于此线下商户的电子券，此线下店铺可以自行生成上述独立对应关系同步至支付平台处，本说明书对此不作限制。
步骤106：使用查询到的所述目标电子券进行支付。
在一实施例中，支付平台根据三方对应关系查询到目标用户拥有的对应于目标商户的目标电子券后，可以在用户支付时使用上述目标电子券进行抵扣。由于电子券可能存在一个或多个维度上的使用限制，例如金额限制，即支付金额满足一定数额时才可以使用；次数限制，即电子券可以使用的次数；使用时间限制，即电子券可以使用的时间段；商品限制，即只有在订单中包含某一品牌、种类的商品时才可以使用；因此，在使用前需要对目标电子券的使用条件进行核查，确定电子券可以使用时，再使用目标电子券进行支付。上述确定电子券是否可以使用的过程可以由支付平台执行，也可以由目标商户进行，值得说明的是，目标商户可以为目标电子券对应的线下商户服务器或者管理上述线下商户的平台服务器，为了上下文的统一和简洁统称为目标商户。当由目标商户确定目标电子券是否可以使用时，支付平台可以将查询到的目标电子券ID反馈至其对应的目标商户，以使目标商户明确其需要进行判断的电子券，进而对目标电子券的使用条件进行判断。
在一实施例中，支付平台可以在用户领取电子券时将用户的领券信息，即电子券与用户的关联关系同步至相应的目标商户，以使目标商户建立电子券、用户以及商户的三方对应关系，当支付平台查询到可以使用的目标电子券时，将目标用户、券ID以及目标电子券对应的线下商户的PMS反馈至目标商户，以使目标商户根据三方对应关系进 行核对，核对无误后通知支付平台可以使用目标电子券进行支付。通过本实施例，通过将用户的领券信息同步至目标商户，可以防止利用伪造的电子券进行支付的行为，降低商家遭受财产损失的风险。
在一实施例中，电子券具有状态信息，用于表示电子券当前是否可用，上述状态信息可能会随着目标电子券的使用而发生变化。譬如，可以多次使用的电子券，当使用次数超出了电子券本身可以使用的次数时，电子券的状态会从可用变为不可用。上述电子券的状态信息可以由支付平台和/或目标商户维护，当由目标商户维护电子券状态时，支付平台可以将查询到的目标电子券ID反馈至其对应的目标商户，以使目标商户明确其需要进行状态核查的电子券，进而对目标电子券的状态进行核查。
在一实施例中，当支付平台确定目标电子券满足使用条件并且目标电子券的状态为可使用状态时，可以在后续的支付过程中使用上述目标电子券，例如，可以根据目标电子券的使用规则对支付金额进行修改，以使目标用户获取包含修改后的支付金额的界面，当目标用户核对金额无误时，可以确认支付，以完成支付过程。当上述目标电子券被使用后，可以由支付平台更改上述目标电子券的状态，当电子券的状态由目标商户维护时，支付平台可以向其发送支付通知，以使目标商户对目标电子券的状态进行更改。具体而言，如果目标电子券的预设可使用次数为单次，当目标电子券被使用后，可将目标电子券的状态更改为不可用状态；如果目标电子券的预设可用次数为多次，当目标电子券被使用一次后，将所述目标电子券的可用次数减一；如果目标电子券具有可用金额的限制，假设目标电子券共可以抵用100元，并可以多次抵用，而用户此次的支付金额仅为10元，则可以从100元中扣除已经支付的10元，将目标电子券的可用抵扣金额修改为90元。
值得说明的是，当查询到多张电子券，并且多张电子券均可使用时，可以根据将可使用的多张电子券进行优先级排序，首先对优先级高的电子券进行使用，当优先级较高的电子券不能使用时，再选择优先级低的电子券进行使用。上述排序所依据的因素可以灵活调整，例如，可以根据优惠金额从高到底排序，计算每张可使用电子券使用后用户需要支付的金额，选择用户需要支付金额最低的电子券作为此次使用的电子券，或者，可以根据使用日期排序，当优惠券具有限用日期时，选用距离失效日期最近的电子券优先使用等等，可以根据单一的因素排序，也可以根据多种因素综合排序确定电子券的优先级。当然，当电子券之间的优惠不冲突时，可以同时使用多张电子券，以使目标用户得到最佳优惠。
由以上本说明书提供的技术方案可见，本说明书通过将用户、电子券与商户之间建立三方对应关系，以使支付平台可以在用户进行支付时，根据上述三方对应关系查询到其拥有的对应于特定商户的电子券，从而在支付时完成自动抵扣，本说明书免去了用户手动选择电子券的繁琐步骤，使支付过程更加简洁迅速，提升了电子支付效率；并且，支付平台或者目标商户可以完成对电子券的使用状态和使用条件的核对，提升了使用电子券时的准确性，无需工作人员或者用户对电子券进行人工核对，进一步提升了支付时的效率。此外，通过支付平台与目标商户对三方对应关系的多次核对，可以防止伪造电 子券被正常使用，提升了支付过程中的安全性，降低了支付平台和商户遭受财产损失的风险。
图3为根据本说明书一示例性实施例示出的一种在支付时使用电子券方法的流程图。如图3所示，该方法应用于目标商户，可以包括如下步骤：步骤302：生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息。
在一实施例中，用户在线下商户中付款的场景下，目标商户即当前用户所在的线下商户可以利用扫描等方式识别用户展示的付款条形码、付款二维码等形式的付款码，上述付款码中包含用户ID，进而线下商户所对应的后台服务器(或者线下商户的统一管理平台的后台服务器)可以生成支付请求，并且可以将线下商户自身的PMS，以及从付款码中获取的用户ID包含于支付请求中发送至支付平台。
步骤304：向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
在一实施例中，支付平台中维护有用户、商户与电子券之间的对应关系以供查询，例如用户可能拥有多张对应于不同线下商户的电子券，而商户也可能发放了不同的电子券，上述三方对应关系表示了一特定用户拥有的、可在特定的线下商户中使用的特定电子券。因此，支付平台可以将目标用户与上述对应关系中的用户信息进行匹配，并将目标商户与上述对应关系中的商户信息进行匹配，当上述两者均可以匹配成功时，可以通过上述对应关系锁定目标用户拥有的对应于目标商户的电子券，由于同一个目标商户可能会发放多种电子券，因此根据上述三方关系查询出的电子券可能为一张或多张，当查询到多张符合条件的电子券时，可以根据支付请求对电子券进行筛选，确定可以使用的电子券进行支付。
在一实施例中，上述三方对应关系可以通过以下步骤建立，支付平台可以接收各个商户分别同步的待领取电子券与相应商户的商户信息之间的第一对应关系，举例而言，当商户平台统一管理多个线下商户时，假设商户平台发放100张电子券，每张电子券拥有一个唯一性的标识，称为券ID，而每张电子券均对应于一个具体的线下商户，即上述电子券可以在其对应的线下商户中使用，电子券ID与其对应的线下商户信息(例如PMS)之间的关联关系称为第一对应关系，商户平台同步上述第一对应关系至支付平台，用户可以通过支付平台领取电子券，以此建立了用户ID与电子券ID之间的第二对应关系。将上述第一对应关系与第二对应关系相结合，可以生成用户ID、券ID以及线下商户三者之间的对应关系。值得说明的是，可以由统一管理多家线下商户的商户管理平台统一发放电子券，也可以由各个线下商户自行发放电子券并将上述第一对应关系同步至支付平台，电子券的发放主体可以根据商户平台的具体规则灵活调整，并不影响本方法的实施，因此本说明书对此不作限制。
在一实施例中，上述三方对应关系可以通过另一种方式建立，仍然假设商户平台统一管理多个线下商户，用户可以在商户平台处领取电子券，用户领取时，商户平台可以拉取用户ID，进而将用户ID与其领取的电子券ID和电子券对应的线下商户信息生成 独立对应关系，上述独立对应关系表示了用户、电子券、商户三方的关联关系，进而商户平台将上述独立对应关系同步至支付平台，支付平台对不同商户平台同步的独立对应关系进行聚合，以形成各个商户与用户、电子券之间的三方对应关系，或者，支付平台也可以不将独立对应关系聚合，即在支付平台中，每个线下商户均可以对应一类三方对应关系，本说明书对此不作限制。值得说明的是，用户也可以从线下店铺处领取对应于此线下商户的电子券，此线下店铺可以自行生成上述独立对应关系同步至支付平台处，本说明书对此不作限制。
在一实施例中，支付平台可以在用户领取电子券时将用户的领券信息，即电子券与用户的关联关系同步至相应的目标商户，以使目标商户建立电子券、用户以及商户的三方对应关系，当支付平台查询到可以使用的目标电子券时，将目标用户、券ID以及目标电子券对应的线下商户的PMS反馈至目标商户，以使目标商户根据三方对应关系进行核对，核对无误后通知支付平台可以使用目标电子券进行支付。通过本实施例，通过将用户的领券信息同步至目标商户，可以防止利用伪造的电子券进行支付的行为，降低商家遭受财产损失的风险。
在一实施例中，电子券具有状态信息，用于表示电子券当前是否可用，上述状态信息可能会随着目标电子券的使用而发生变化。譬如，可以多次使用的电子券，当使用次数超出了电子券本身可以使用的次数时，电子券的状态会从可用变为不可用。当由目标商户维护电子券状态时，支付平台可以将查询到的目标电子券ID反馈至其对应的目标商户，以使目标商户明确其需要进行状态核查的电子券，进而对目标电子券的状态进行核查。
在一实施例中，当支付平台确定目标电子券满足使用条件并且目标电子券的状态为可使用状态时，可以在后续的支付过程中使用上述目标电子券，例如，可以根据目标电子券的使用规则对支付金额进行修改，以使目标用户获取包含修改后的支付金额的界面，当目标用户核对金额无误时，可以确认支付，以完成支付过程。当上述目标电子券被使用后，支付平台可以向目标商户发送支付通知，以使目标商户对目标电子券的状态进行更改。具体而言，如果目标电子券的预设可使用次数为单次，当目标电子券被使用后，可将目标电子券的状态更改为不可用状态；如果目标电子券的预设可用次数为多次，当目标电子券被使用一次后，将所述目标电子券的可用次数减一；如果目标电子券具有可用金额的限制，假设目标电子券共可以抵用100元，并可以多次抵用，而用户此次的支付金额仅为10元，则可以从100元中扣除已经支付的10元，将目标电子券的可用抵扣金额修改为90元。
在一实施例中，目标商户可以获取当前支付对应的订单信息，根据所述订单信息确定所述当前支付是否满足所述目标电子券的使用条件；当所述目标电子券满足使用条件时，通知所述支付平台使用所述目标电子券进行支付。具体而言，部分电子券的使用条件和当前支付所对应的订单中的具体商品信息有关，换言之，有些电子券只有在用户购买了某些特定商品时才可以使用，此时目标商户可以获取当前支付所对应订单的具体信息，确定当前订单是否满足查询到的电子券对应的使用条件，如果满足，向支付平台发 送通知，使支付平台使用目标电子券进行支付。
图4为根据本说明书一示例性实施例示出的一种在支付时使用电子券方法的流程图。如图4所示，该方法应用于目标商户，可以包括如下步骤：步骤402：生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息。
在一实施例中，用户在线下商户进行支付的场景下，目标商户可以预先获取订单码，上述订单码可以由管理线下商户的商户管理平台或者线下商户对应的后台服务器向支付平台发送预下单请求，进而由支付平台响应于预下单请求后生成并返回至目标商户处。目标商户获取订单码后展示给目标用户，目标用户可以通过扫描等方式识别目标商户的订单码，上述订单码中包含当前用户所在的线下商户所对应的PMS，因此，目标用户可以将自身的用户ID与当前用户所在的线下商户的PMS包含于支付请求中进而发送至支付平台。
步骤404：向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
在一实施例中，支付平台中维护有用户、商户与电子券之间的对应关系以供查询，例如用户可能拥有多张对应于不同线下商户的电子券，而商户也可能发放了不同的电子券，上述三方对应关系表示了一特定用户拥有的、可在特定的线下商户中使用的特定电子券。因此，支付平台可以将目标用户与上述对应关系中的用户信息进行匹配，并将目标商户与上述对应关系中的商户信息进行匹配，当上述两者均可以匹配成功时，可以通过上述对应关系锁定目标用户拥有的对应于目标商户的电子券，由于同一个目标商户可能会发放多种电子券，因此根据上述三方关系查询出的电子券可能为一张或多张，当查询到多张符合条件的电子券时，可以根据支付请求对电子券进行筛选，确定可以使用的电子券进行支付。
在一实施例中，上述三方对应关系可以通过以下步骤建立，支付平台可以接收各个商户分别同步的待领取电子券与相应商户的商户信息之间的第一对应关系，举例而言，当商户平台统一管理多个线下商户时，假设商户平台发放100张电子券，每张电子券拥有一个唯一性的标识，称为券ID，而每张电子券均对应于一个具体的线下商户，即上述电子券可以在其对应的线下商户中使用，电子券ID与其对应的线下商户信息(例如PMS)之间的关联关系称为第一对应关系，商户平台同步上述第一对应关系至支付平台，用户可以通过支付平台领取电子券，以此建立了用户ID与电子券ID之间的第二对应关系。将上述第一对应关系与第二对应关系相结合，可以生成用户ID、券ID以及线下商户三者之间的对应关系。值得说明的是，可以由统一管理多家线下商户的商户管理平台统一发放电子券，也可以由各个线下商户自行发放电子券并将上述第一对应关系同步至支付平台，电子券的发放主体可以根据商户平台的具体规则灵活调整，并不影响本方法的实施，因此本说明书对此不作限制。
在一实施例中，上述三方对应关系可以通过另一种方式建立，仍然假设商户平台统一管理多个线下商户，用户可以在商户平台处领取电子券，用户领取时，商户平台可以 拉取用户ID，进而将用户ID与其领取的电子券ID和电子券对应的线下商户信息生成独立对应关系，上述独立对应关系表示了用户、电子券、商户三方的关联关系，进而商户平台将上述独立对应关系同步至支付平台，支付平台对不同商户平台同步的独立对应关系进行聚合，以形成各个商户与用户、电子券之间的三方对应关系，或者，支付平台也可以不将独立对应关系聚合，即在支付平台中，每个线下商户均可以对应一类三方对应关系，本说明书对此不作限制。值得说明的是，用户也可以从线下店铺处领取对应于此线下商户的电子券，此线下店铺可以自行生成上述独立对应关系同步至支付平台处，本说明书对此不作限制。
在一实施例中，当目标电子券满足使用条件并且目标电子券的状态为可使用状态时，可以在后续的支付过程中使用上述目标电子券，例如，可以根据目标电子券的使用规则对支付金额进行修改，以使目标用户获取包含修改后的支付金额的界面，当目标用户核对金额无误时，可以确认支付，以完成支付过程。
图5为根据本说明书一示例性实施例示出的一种在支付时使用电子券的方法的多方交互流程图。如图5所示，支付平台51、目标商户52、目标用户53之间的交互过程包括以下步骤：步骤502～506，在线下支付的场景中，目标商户62可以通过扫描用户提供的付款码进行收款，上述付款码的形式可以为条形码、二维码等任何可以记录数据符号信息并且进行后续的收付款操作的图形，本说明书对付款码的具体形式不作限制。当目标商户52扫描目标用户53提供的付款码后在内部进行步骤504所示的下单操作，并生成支付请求。由于上述付款码中包含用户ID，因此目标商户可以将当前目标用户所在的线下商户自身具有的PMS(或是其它可以唯一标识商户的信息)，以及从付款码中获取的用户ID包含于支付请求中发送至支付平台61。
步骤508，支付平台51在接受到支付请求后，提取其中包含的目标用户以及目标商户信息，即确定当前下单的用户ID以及此订单所对应的线下商户的PMS，并将上述两个信息与支付平台51自身维护的商户、用户、电子券之间的三方对应关系分别进行匹配，将匹配成功的三方对应关系中所对应的电子券作为目标电子券。
具体而言，上述三方对应关系可以通过以下步骤建立，支付平台51可以接收各个商户分别同步的待领取电子券与相应线下商户的PMS之间的第一对应关系，举例而言，目标商户52发放了一定数量的电子券，每张电子券拥有一个唯一性的标识，称为券ID，而每张电子券均对应于一个具体的线下商户，即上述电子券可以在其对应的线下商户中使用，假设此处的目标商户52即当前线下商户独立使用的后台服务器，那么券ID与目标商户52所对应的PMS之间的关联关系称为第一对应关系，目标商户52可以同步第一对应关系至支付平台51，用户可以通过支付平台51领取电子券，以此建立用户ID与券ID之间的第二对应关系。将上述第一对应关系与第二对应关系相结合，可以生成用户ID、券ID以及线下商户的PMS三者之间的对应关系。或者，用户可以在目标商户52处领取电子券，领取时目标商户可以拉取用户ID，进而将用户ID与其领取的券ID和目标商户对应的PMS生成独立对应关系，上述独立对应关系表示了用户、电子券、商户三方的关联关系，进而目标商户52将上述独立对应关系同步至支付平台，支付平 台对不同目标商户同步的独立对应关系进行聚合，以形成各个商户与用户、电子券之间的三方对应关系，或者，支付平台也可以不将独立对应关系聚合，即在支付平台中，每个线下商户均可以对应一类三方对应关系，本说明书对此不作限制。
步骤510，支付平台返回券ID、目标用户ID、PMS至目标商户处。目标商户52可以根据券ID确定支付平台51确定的目标电子券，结合用户ID和PMS可以和自身维护的三方对应关系进行再次核对。
步骤512～514，对目标电子券进行核查并通知支付平台51目标电子券可以使用，值得说明的是，此处的核查电子券包含多方面的核查，目标商户通过券ID可以确定目标电子券，在此步骤中，目标商户52可以对目标电子券的使用条件进行核查，譬如，目标商户52可以获取当前支付对应的订单信息，根据所述订单信息确定所述当前支付是否满足所述目标电子券的使用条件；当所述目标电子券满足使用条件时，通知所述支付平台使用所述目标电子券进行支付，具体而言，部分电子券的使用条件和当前支付所对应的订单中的具体商品信息有关，换言之，有些电子券只有在用户购买了某些特定商品时才可以使用，此时目标商户可以获取当前支付所对应订单的具体信息，确定当前订单是否满足查询到的电子券对应的使用条件。或者，目标商户52可以对目标电子券的使用状态进行核查，譬如核查上述电子券是否已经被使用，或者是否已经超出了可使用的次数等，当然，上述电子券的状态可以维护于支付平台51处，判断方法在此不再赘述。又或者，支付平台51可以在用户领券时将领券信息同步至目标商户52，以使目标商户52建立用户ID、PMS、券ID之间的三方对应关系，并将支付平台返回的券ID、目标用户ID、PMS与三方对应关系进行再次核对，以防止伪造电子券的流通。步骤512中目标商户52对目标电子券各方面的核查均通过后可以进入步骤514，通知支付平台目标电子券可以使用，以进行下述其它步骤。
步骤516～520，支付平台51在上述目标电子券被确认可以使用的情况下，可以根据电子券中的预设规则修改支付金额，并将修改后的支付金额展示给目标用户，以使目标用户对修改后的支付进行核对并确认支付。当然，如果经由目标用户授权，或者当前支付订单满足免密支付的条件，也步骤518～520也可以省略，直接根据修改后的支付金额进行支付。
步骤522～524，支付完成后支付平台51可以向目标商户52发送支付通知，以使目标商户52修改目标电子券的状态，譬如，当目标电子券是具有预设使用次数的电子券时，此时可以将目标电子券的可使用次数减一，以供下次核查电子券时使用。当然，如果上述电子券的状态被支付平台51维护，支付完成后同样可以对上述电子券的状态进行更改，在此不再赘述。
图6为根据本说明书一示例性实施例示出的一种在支付时使用电子券的方法的多方交互流程图。如图6所示，支付平台61、目标商户62、目标用户63之间的交互过程包括以下步骤：
步骤602～608，在线下支付的场景中，目标商户62可以进行预下单的操作，以使支付平台61生成订单码并返回至目标商户62处，上述订单码的形式可以为条形码、二维 码等任何可以记录数据符号信息并且进行后续的收付款操作的图形，本说明书对订单码的具体形式不作限制。当目标商户62生成订单码后可以将其展示给目标用户63，目标用户63可以通过扫描等操作生成支付请求。由于上述订单码中包含目标商户的PMS，因此目标用户63可以将当前目标用户所在的线下商户自身具有的PMS(或是其它可以唯一标识商户的信息)，以及自身的用户ID包含于支付请求中发送至支付平台61。
步骤610，支付平台61在接受到支付请求后，提取其中包含的目标用户以及目标商户信息，即确定当前下单的用户ID以及此订单所对应的线下商户的PMS，并将上述两个信息与支付平台61自身维护的商户、用户、电子券之间的三方对应关系分别进行匹配，将匹配成功的三方对应关系中所对应的电子券作为目标电子券。
具体而言，上述三方对应关系可以通过以下步骤建立，支付平台61可以接收各个商户分别同步的待领取电子券与相应线下商户的PMS之间的第一对应关系，举例而言，目标商户62发放了一定数量的电子券，每张电子券拥有一个唯一性的标识，称为券ID，而每张电子券均对应于一个具体的线下商户，即上述电子券可以在其对应的线下商户中使用，假设此处的目标商户62即当前线下商户独立使用的后台服务器，那么券ID与目标商户62所对应的PMS之间的关联关系称为第一对应关系，目标商户62可以同步第一对应关系至支付平台61，用户可以通过支付平台61领取电子券，以此建立用户ID与券ID之间的第二对应关系。将上述第一对应关系与第二对应关系相结合，可以生成用户ID、券ID以及线下商户的PMS三者之间的对应关系。或者，用户可以在目标商户62处领取电子券，领取时目标商户可以拉取用户ID，进而将用户ID与其领取的券ID和目标商户对应的PMS生成独立对应关系，上述独立对应关系表示了用户、电子券、商户三方的关联关系，进而目标商户62将上述独立对应关系同步至支付平台，支付平台对不同目标商户同步的独立对应关系进行聚合，以形成各个商户与用户、电子券之间的三方对应关系，或者，支付平台也可以不将独立对应关系聚合，即在支付平台中，每个线下商户均可以对应一类三方对应关系，本说明书对此不作限制。
步骤612，支付平台返回券ID、目标用户ID、PMS至目标商户处。目标商户62可以根据券ID确定支付平台61确定的目标电子券，结合用户ID和PMS可以和自身维护的三方对应关系进行再次核对。
步骤514～516，对目标电子券进行核查并通知支付平台61目标电子券可以使用，值得说明的是，此处的核查电子券包含多方面的核查，目标商户通过券ID可以确定目标电子券，在此步骤中，目标商户62可以对目标电子券的使用条件进行核查，譬如，目标商户62可以获取当前支付对应的订单信息，根据所述订单信息确定所述当前支付是否满足所述目标电子券的使用条件；当所述目标电子券满足使用条件时，通知所述支付平台使用所述目标电子券进行支付，具体而言，部分电子券的使用条件和当前支付所对应的订单中的具体商品信息有关，换言之，有些电子券只有在用户购买了某些特定商品时才可以使用，此时目标商户可以获取当前支付所对应订单的具体信息，确定当前订单是否满足查询到的电子券对应的使用条件。或者，目标商户62可以对目标电子券的使用状态进行核查，譬如核查上述电子券是否已经被使用，或者是否已经超出了可使用的 次数等，当然，上述电子券的状态可以维护于支付平台61处，判断方法在此不再赘述。又或者，支付平台61可以在用户领券时将领券信息同步至目标商户62，以使目标商户62建立用户ID、PMS、券ID之间的三方对应关系，并将支付平台返回的券ID、目标用户ID、PMS与三方对应关系进行再次核对，以防止伪造电子券的流通。步骤614中目标商户62对目标电子券各方面的核查均通过后可以进入步骤614，通知支付平台目标电子券可以使用，以进行下述其它步骤。
步骤618～622，支付平台61在上述目标电子券被确认可以使用的情况下，可以根据电子券中的预设规则修改支付金额，并将修改后的支付金额展示给目标用户，以使目标用户对修改后的支付进行核对并确认支付。当然，如果经由目标用户授权，或者当前支付订单满足免密支付的条件，也步骤618～622也可以省略，直接根据修改后的支付金额进行支付。
步骤624～626，支付完成后支付平台61可以向目标商户62发送支付通知，以使目标商户62修改目标电子券的状态，譬如，当目标电子券是具有预设使用次数的电子券时，此时可以将目标电子券的可使用次数减一，以供下次核查电子券时使用。当然，如果上述电子券的状态被支付平台61维护，支付完成后同样可以对上述电子券的状态进行更改，在此不再赘述。
上述两个交互图展示了用户在进行线下支付时可能会选择的两种支付形式，无论支付的形式如何，支付平台均可根据三方对应关系查询目标电子券，从而完成在支付时的自动抵扣，提升了支付效率，简化了用户的操作，并且通过对电子券的使用条件、使用状态等多方面的核查，可以保证查询到的电子券的准确性与使用电子券时的安全性。
图7是一示例性实施例提供的一种设备的示意结构图。请参考图7，在硬件层面，该设备包括处理器702、内部总线704、网络接口706、内存708以及非易失性存储器710，当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，比如由处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图8，在支付时使用电子券的装置可以应用于如图7所示的设备中，以实现本说明书的技术方案。其中，该在支付时使用电子券的装置可以包括：接收单元802，用于接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户；查询单元804，用于根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券；支付单元806，用于使用查询到的所述目标电子券进行支付。
可选的，所述支付请求可以包括：所述目标商户发送的支付请求或者所述目标用户发送的支付请求。
可选的，所述目标商户发送的支付请求包括：所述目标商户通过扫描所述目标用户 提供的付款码进而向所述支付平台发送的支付请求；可选的，所述目标用户发送的支付请求包括：所述目标用户通过扫描所述目标商户提供的订单码进而向所述支付平台发送的支付请求。
可选的，上述装置还可以包括：第一对应关系生成单元808，用于接收各个商户分别同步的待领取电子券与相应商户的商户信息之间的第一对应关系；根据所述第一对应关系，以及各个用户领取所述待领取电子券而产生的已领取电子券与用户信息之间的第二对应关系，生成所述三方对应关系。
或者用于接收各个商户分别同步的独立对应关系，所述独立对应关系由所述商户基于自身的商户信息、自身支持的电子券和领取所述电子券用户的用户信息而生成；对收到的独立对应关系进行聚合，以形成所述三方对应关系。
可选的，上述装置还可以包括：确定单元810，用于确定所述目标电子券是否处于可用状态；在所述目标电子券处于可用状态的情况下，使用所述目标电子券进行支付。
可选的，所述确定单元810可以用于接收所述目标商户返回的核查结果，根据所述核查结果确定所述目标电子券是否处于可用状态，所述核查结果由所述目标商户根据自身维护的电子券状态对所述目标电子券进行状态核查而生成。
可选的，上述装置还可以包括：第一状态更改单元812，用于在使用所述目标电子券进行支付后，更改所述目标电子券的状态；或者，在使用所述目标电子券进行支付后，向所述目标商户发送支付通知，以由所述目标商户更改所述目标电子券的状态。
可选的，所述更改所述目标电子券的状态包括下述任一：将所述目标电子券的状态更改为不可用状态、根据支付数额减少所述目标电子券的可用数额、减少所述目标电子券的可用次数。
可选的，上述装置还可以包括：金额修改单元814，用于根据所述目标电子券修改支付数额，以使所述目标用户获取包含修改后支付数额的支付界面，进而确认支付。
请参考图9，在支付时使用电子券的装置可以应用于如图7所示的设备中，以实现本说明书的技术方案。其中，该在支付时使用电子券的装置可以包括：第一生成单元902，用于生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；第一发送单元904，用于向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
可选的，上述装置还可以包括：第二对应关系生成单元906，用于根据商户自身的商户信息、自身支持的电子券和领取所述电子券的用户对应的用户信息生成独立对应关系；将所述独立对应关系同步至所述支付平台，以使所述支付平台对收到的独立对应关系进行聚合，以形成所述三方对应关系。
可选的，上述第二对应关系生成单元906还可以用于同步待领取电子券与相应商户的商户信息之间的第一对应关系至所述支付平台，进而使所述支付平台根据所述第一对 应关系，以及各个用户领取所述待领取电子券而产生的已领取电子券与用户信息之间的第二对应关系，生成所述三方对应关系。
可选的，所述生成支付请求包括：扫描所述目标用户提供的付款码以生成支付请求。
可选的，上述装置还可以包括：核查单元908，用于根据自身维护的电子券状态对所述目标电子券的状态进行核查并生成核查结果；将所述核查结果返回至所述支付平台，以使所述支付平台根据确定所述目标电子券是否处于可用状态，进而在所述目标电子券处于可用状态的情况下使用所述目标电子券进行支付。
可选的，上述装置还可以包括：第二状态更改单元910，用于接收所述支付平台发送的支付通知以更改所述目标电子券的状态。
可选的，所述更改所述目标电子券的状态包括下述任一：将所述目标电子券的状态更改为不可用状态、根据支付数额减少所述目标电子券的可用数额、减少所述目标电子券的可用次数。
可选的，上述装置还可以包括：订单获取单元912，用于获取当前支付对应的订单信息，根据所述订单信息确定所述当前支付是否满足所述目标电子券的使用条件；当所述目标电子券满足使用条件时，通知所述支付平台使用所述目标电子券进行支付。
请参考图10，在支付时使用电子券的装置可以应用于如图7所示的设备中，以实现本说明书的技术方案。其中，该在支付时使用电子券的装置可以包括：第二生成单元1002，用于生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；第二发送单元1004，用于向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
可选的，所述生成支付请求包括：扫描商家提供的订单码以生成所述支付请求。
可选的，上述装置还可以包括：支付确认单元1006，用于展示包含修改后支付数额的支付界面以确认支付。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或 技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (26)

  1. 一种在支付时使用电子券的方法，其特征在于，应用于支付平台，所述方法包括：
    接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户；
    根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券；
    使用查询到的所述目标电子券进行支付。
  2. 根据权利要求1所述的方法，其特征在于，所述支付请求包括：所述目标商户发送的支付请求或者所述目标用户发送的支付请求。
  3. 根据权利要求2所述的方法，其特征在于，
    所述目标商户发送的支付请求包括：所述目标商户通过扫描所述目标用户提供的付款码进而向所述支付平台发送的支付请求；
    所述目标用户发送的支付请求包括：所述目标用户通过扫描所述目标商户提供的订单码进而向所述支付平台发送的支付请求。
  4. 根据权利要求1所述的方法，其特征在于，还包括：
    接收各个商户分别同步的待领取电子券与相应商户的商户信息之间的第一对应关系；
    根据所述第一对应关系，以及各个用户领取所述待领取电子券而产生的已领取电子券与用户信息之间的第二对应关系，生成所述三方对应关系。
  5. 根据权利要求1所述的方法，其特征在于，还包括：
    接收各个商户分别同步的独立对应关系，所述独立对应关系由所述商户基于自身的商户信息、自身支持的电子券和领取所述电子券用户的用户信息而生成；
    对收到的独立对应关系进行聚合，以形成所述三方对应关系。
  6. 根据权利要求1所述的方法，其特征在于，所述使用查询到的所述目标电子券进行支付，包括：
    确定所述目标电子券是否处于可用状态；
    在所述目标电子券处于可用状态的情况下，使用所述目标电子券进行支付。
  7. 根据权利要求6所述的方法，其特征在于，所述确定所述目标电子券是否处于可用状态包括：
    接收所述目标商户返回的核查结果，根据所述核查结果确定所述目标电子券是否处于可用状态，所述核查结果由所述目标商户根据自身维护的电子券状态对所述目标电子券进行状态核查而生成。
  8. 根据权利要求6所述的方法，其特征在于，还包括：
    在使用所述目标电子券进行支付后，更改所述目标电子券的状态；
    或者，在使用所述目标电子券进行支付后，向所述目标商户发送支付通知，以由所述目标商户更改所述目标电子券的状态。
  9. 根据权利要求8所述的方法，其特征在于，所述更改所述目标电子券的状态包括下述任一：
    将所述目标电子券的状态更改为不可用状态、根据支付数额减少所述目标电子券的 可用数额、减少所述目标电子券的可用次数。
  10. 根据权利要求1所述的方法，其特征在于，还包括：
    根据所述目标电子券修改支付数额，以使所述目标用户获取包含修改后支付数额的支付界面，进而确认支付。
  11. 一种在支付时使用电子券的方法，其特征在于，应用于目标商户，所述方法包括：
    生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；
    向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
  12. 根据权利要求11所述的方法，其特征在于，还包括：
    根据商户自身的商户信息、自身支持的电子券和领取所述电子券的用户的用户信息生成独立对应关系；
    将所述独立对应关系同步至所述支付平台，以使所述支付平台对收到的独立对应关系进行聚合，以形成所述三方对应关系。
  13. 根据权利要求11所述的方法，其特征在于，还包括：
    同步待领取电子券与相应商户的商户信息之间的第一对应关系至所述支付平台，进而使所述支付平台根据所述第一对应关系，以及各个用户领取所述待领取电子券而产生的已领取电子券与用户信息之间的第二对应关系，生成所述三方对应关系。
  14. 根据权利要求11所述的方法，其特征在于，所述生成支付请求包括：
    扫描所述目标用户提供的付款码以生成支付请求。
  15. 根据权利要求11所述的方法，其特征在于，还包括：
    根据自身维护的电子券状态对所述目标电子券的状态进行核查并生成核查结果；
    将所述核查结果返回至所述支付平台，以使所述支付平台根据确定所述目标电子券是否处于可用状态，进而在所述目标电子券处于可用状态的情况下使用所述目标电子券进行支付。
  16. 根据权利要求15所述的方法，其特征在于，还包括：
    接收所述支付平台发送的支付通知以更改所述目标电子券的状态。
  17. 根据权利要求16所述的方法，其特征在于，所述更改所述目标电子券的状态包括下述任一：
    将所述目标电子券的状态更改为不可用状态、根据支付数额减少所述目标电子券的可用数额、减少所述目标电子券的可用次数。
  18. 根据权利要求11所述的方法，其特征在于，还包括：
    获取当前支付对应的订单信息，根据所述订单信息确定所述当前支付是否满足所述目标电子券的使用条件；
    当所述目标电子券满足使用条件时，通知所述支付平台使用所述目标电子券进行支付。
  19. 一种在支付时使用电子券的方法，其特征在于，应用于目标用户，所述方法包括：
    生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；
    向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
  20. 根据权利要求19所述的方法，其特征在于，所述生成支付请求包括：
    扫描商家提供的订单码以生成所述支付请求。
  21. 根据权利要求19所述的方法，其特征在于，还包括：
    展示包含修改后支付数额的支付界面以确认支付。
  22. 一种在支付时使用电子券的装置，其特征在于，应用于支付平台，所述装置包括：
    接收单元，用于接收支付请求，并从所述支付请求中确定所述支付请求对应的目标用户和目标商户；
    查询单元，用于根据已建立的用户、商户与电子券之间的三方对应关系，查询所述目标用户拥有的对应于所述目标商户的目标电子券；
    支付单元，用于使用查询到的所述目标电子券进行支付。
  23. 一种在支付时使用电子券的装置，其特征在于，应用于目标商户，所述装置包括：
    第一生成单元，用于生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；
    第一发送单元，用于向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
  24. 一种在支付时使用电子券的装置，其特征在于，应用于目标用户，所述装置包括：
    第二生成单元，用于生成支付请求，所述支付请求中包含目标用户的信息和目标商户的信息；
    第二发送单元，用于向支付平台发送所述支付请求，以使所述支付平台根据已建立的用户、商户与电子券之间的三方对应关系确定目标用户拥有的对应于目标商户的目标电子券，并使用所述目标电子券进行支付。
  25. 一种电子设备，其特征在于，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器通过运行所述可执行指令以实现如权利要求1-21中任一项所述的方法。
  26. 一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现如权利要求1-21中任一项所述方法的步骤。
PCT/CN2022/090861 2021-05-11 2022-05-05 在支付时使用电子券的方法及装置 WO2022237606A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110510865.2 2021-05-11
CN202110510865.2A CN113222598A (zh) 2021-05-11 2021-05-11 在支付时使用电子券的方法及装置

Publications (1)

Publication Number Publication Date
WO2022237606A1 true WO2022237606A1 (zh) 2022-11-17

Family

ID=77094864

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/090861 WO2022237606A1 (zh) 2021-05-11 2022-05-05 在支付时使用电子券的方法及装置

Country Status (2)

Country Link
CN (1) CN113222598A (zh)
WO (1) WO2022237606A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113222598A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 在支付时使用电子券的方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130124288A1 (en) * 2011-10-22 2013-05-16 Jamaal Carter Personal digital cashier with the coupon locator
CN104517220A (zh) * 2013-09-29 2015-04-15 中国电信股份有限公司 电子券自动受理方法、装置与系统
CN104899756A (zh) * 2014-03-06 2015-09-09 中国移动通信集团福建有限公司 一种电子券联机支付方法和系统
CN110288342A (zh) * 2019-06-21 2019-09-27 口碑(上海)信息技术有限公司 一种电子券的核销方法及装置
CN113222598A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 在支付时使用电子券的方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103679464A (zh) * 2012-09-05 2014-03-26 上海翰鑫信息科技有限公司 终端、电子票劵管理平台、使用系统及方法
CN107909397A (zh) * 2017-11-13 2018-04-13 北京小度信息科技有限公司 电子券绑定方法、装置、电子设备和计算机可读存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130124288A1 (en) * 2011-10-22 2013-05-16 Jamaal Carter Personal digital cashier with the coupon locator
CN104517220A (zh) * 2013-09-29 2015-04-15 中国电信股份有限公司 电子券自动受理方法、装置与系统
CN104899756A (zh) * 2014-03-06 2015-09-09 中国移动通信集团福建有限公司 一种电子券联机支付方法和系统
CN110288342A (zh) * 2019-06-21 2019-09-27 口碑(上海)信息技术有限公司 一种电子券的核销方法及装置
CN113222598A (zh) * 2021-05-11 2021-08-06 支付宝(杭州)信息技术有限公司 在支付时使用电子券的方法及装置

Also Published As

Publication number Publication date
CN113222598A (zh) 2021-08-06

Similar Documents

Publication Publication Date Title
US10489767B2 (en) Cloud-based point-of-sale transaction processing
US20120284147A1 (en) Online Payment Method and Device
US20200167336A1 (en) System, Method, and Apparatus for Implementing a Blockchain-Based Entity Identification Network
US20180082319A1 (en) Systems and methods for providing credit to financial service accounts
US20150142514A1 (en) System and method for payment transaction receipt management
US20220130005A1 (en) Digital asset management systems and methods
TW202022643A (zh) 內容推送方法及裝置、電子設備
US20140372169A1 (en) Systems and methods for providing business ratings
WO2020021550A1 (en) System and method for performing cashless transactions between computing devices
CN113506111A (zh) 基于区块链的实体物品所有权登记方法及装置
US20230306395A1 (en) Automatic invoice notification
US11144947B2 (en) Managing user loyalty groups at point-of-sale accesses
WO2019062704A1 (zh) 交易数据处理方法、装置及系统
WO2022237606A1 (zh) 在支付时使用电子券的方法及装置
US20240086992A1 (en) Systems and methods for providing product recommendations
KR101847450B1 (ko) 적립 포인트 전환장치
CN106372878A (zh) 一种支付方法、支付客户端和支付服务器
US20140214663A1 (en) System and method for location-based delivery of discounted prepaid gift accounts offers
US20150286998A1 (en) Methods and Systems for Facilitating Transactions
US20230137574A1 (en) System, method, and computer program product for processing an electronic payment transaction having a custom interchange rate
KR20200077937A (ko) 모바일 상품권으로 결제 후 결제 잔액에 해당하는 새로운 모바일 상품권을 발행하는 방법
US10635995B2 (en) Systems and methods for facilitating event access through payment accounts
JP6475392B2 (ja) 支払アカウントに対するトランザクションを処理するシステム及び方法
CN110659932A (zh) 一种积分管理方法、装置、系统及计算机设备
WO2018222317A1 (en) System for accessing transactional data

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

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

Country of ref document: EP

Kind code of ref document: A1