具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
图1为一示例性实施例提供的一种支付时使用电子券系统的架构示意图。如图1所示,该系统可以包括支付平台11、目标商户12、目标用户13、网络14等。
在本实施例中,支付平台不仅可以实现电子支付功能,还可以作为诸多其他功能的集成化功能平台,比如即时通讯功能、实体或虚拟商品购买功能、资源转移功能等等,本说明书公开的一个或多个实施例并不对此进行限制。
其中,支付平台11的相关功能可以由一独立主机的物理服务器实现,或者该服务器可以为主机集群承载的虚拟服务器。在运行过程中,上述服务器可以运行支付应用的服务器侧的程序,以实现该应用的相关业务功能,比如当该服务器运行支付平台11的程序时,可以实现为该支付应用的服务端。
目标商户12可以表现为任一商户使用的具有通讯功能的管理客户端所对应的服务端,也可以表现为可以管理多个商户的具有通讯功能的商户管理平台,目标商户12可以通过网络14与支付平台11进行通讯,并管理、发放商户的电子券。
目标用户13可以表现为支付平台11的服务端所对应的客户端,其运行支付应用客户端侧的程序,与支付平台11配合实现支付应用的各种功能。目标用户13的客户端可以运行于多种电子设备上,例如手机、平板设备、笔记本电脑、掌上电脑(PDAs,PersonalDigital 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),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。