本申请涉及互联网技术领域，尤其涉及一种认证信息发送、订单生成、订单支付方法及装置。
背景技术：
目前，对于各类商家或机构，会由相应的认证方根据商家或机构的实际情况，为其认定相应的第三方认证信息。这一类第三方认证信息可在一定程度上反映商家或机构的信用或资质等情况。例如，若认证方是税务部门，则为某商家认定的第三方认证信息可为“海淀区纳税百强企业”。
由于第三方认证信息在一定程度上可以反映出商家的信用或资质等情况，这类信息通常可作为用户确定电子订单是否具有风险的依据或参考信息。然而，在相关技术中，在电子订单生成或处理的过程中还无法及时地将商家的第三方认证信息展示给用户，导致用户无法及时地根据商家的第三方认证信息确定电子订单是否具有风险。
技术实现要素：
有鉴于此，本申请提供一种认证信息发送、订单生成、订单支付方法及装置。
为实现上述目的，本申请提供技术方案如下：
根据本申请的第一方面，提出了一种认证信息发送方法，包括：
接收用户终端发送的包含商户标识的订单生成请求；
响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
向所述用户终端推送查找到的第三方认证信息。
根据本申请的第二方面，提出了一种认证信息发送方法，包括：
接收用户终端发送的包含商户标识的订单支付请求；
响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
向所述用户终端推送查找到的第三方认证信息。
根据本申请的第三方面，提出了一种认证信息发送方法，包括：
接收用户终端发送的用以获取订单信息确认页面的请求，所述请求包含商户标识；
响应于所述请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
向所述用户终端推送包含查找到的第三方认证信息的页面数据；所述页面数据用于渲染所述订单信息确认页面。
根据本申请的第四方面，提出了一种订单生成方法，包括：
接收用户终端发送的包含订单信息的订单生成请求，所述订单信息包括商户标识；
响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
向所述用户终端推送查找到的第三方认证信息；
当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述订单信息生成电子订单。
根据本申请的第五方面，提出了一种订单支付方法，包括：
接收用户终端发送的包含支付信息的订单支付请求，所述支付信息包括商户标识；
响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
向所述用户终端推送查找到的第三方认证信息；
当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述支付信息执行支付。
根据本申请的第六方面，提出了一种认证信息发送装置，包括：
接收单元，用于接收用户终端发送的包含商户标识的订单生成请求；
查找单元，用于响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元，用于向所述用户终端推送查找到的第三方认证信息。
根据本申请的第七方面，提出了一种认证信息发送装置，包括：
接收单元，用于接收用户终端发送的包含商户标识的订单支付请求；
查找单元，用于响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元，用于向所述用户终端推送查找到的第三方认证信息。
根据本申请的第八方面，提出了一种认证信息发送装置，包括：
接收单元，用于接收用户终端发送的用以获取订单信息确认页面的请求，所述请求包含商户标识；
查找单元，用于响应于所述请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元，用于向所述用户终端发送包含查找到的第三方认证信息的页面数据；所述页面数据用于渲染所述订单信息确认页面。
根据本申请的第九方面，提出了一种订单生成装置，包括：
接收单元，用于接收用户终端发送的包含订单信息的订单生成请求，所述订单信息包括商户标识；
查找单元，用于响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元，用于向所述用户终端推送查找到的第三方认证信息；
生成单元，用于当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述订单信息生成电子订单。
根据本申请的第十方面，提出了一种订单支付装置，包括：
接收单元，用于接收用户终端发送的包含支付信息的订单支付请求，所述支付信息包括商户标识；
查找单元，用于响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元，用于向所述用户终端推送查找到的第三方认证信息；
支付单元，用于当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述支付信息执行支付。
由以上技术方案可见，本申请实施例中，通过在订单生成或订单支付的过程中，通过查找与商户标识对应的第三方认证信息，并将查找到的第三方认证信息推送给用户终端，以供用户查看，使得用户可以快速查看到商户的第三方认证信息，信息获取效率更高。此外，用户可以基于第三方认证信息来确定当前订单是否存在风险，进而可以使得用户及时发现风险订单并执行相应的操作(如取消订单)。
另一方面，在订单生成或订单支付的过程中，由于需要用户对查看到的第三方认证信息进行确认后，服务器才执行后续的生成订单或支付的动作，这在一定程度上可减少服务器生成电子订单后，因后续用户发现订单存在风险而随即取消订单的情况，从而降低服务器生成、取消电子订单的频率，缓解服务器压力。
附图说明
图1是本申请一实施例提供的系统架构图；
图2是本申请一示例性实施例提供的一种认证信息发送方法的流程图；
图3是本申请一示例性实施例提供的一种显示第三方认证信息的页面示意图；
图4是本申请一示例性实施例提供的另一种认证信息发送方法的流程图；
图5是本申请一示例性实施例提供的另一种显示第三方认证信息的页面示意图；
图6是本申请一示例性实施例提供的又一种认证信息发送方法的流程图；
图7是本申请一示例性实施例提供的又一种显示第三方认证信息的页面示意图；
图8是本申请一示例性实施例提供的一种订单生成方法的流程图；
图9是本申请一示例性实施例提供的再一种显示第三方认证信息的页面示意图；
图10是本申请一示例性实施例提供的一种订单支付方法的流程图；
图11是本申请一示例性实施例提供的又一种显示第三方认证信息的页面示意图；
图12是本申请一示例性实施例提供的一种电子设备的结构示意图；
图13是本申请一示例性实施例提供的一种认证信息发送装置的框图；
图14是本申请一示例性实施例提供的一种电子设备的结构示意图；
图15是本申请一示例性实施例提供的一种订单生成装置的框图；
图16是本申请一示例性实施例提供的一种电子设备的结构示意图；
图17是本申请一示例性实施例提供的一种订单支付装置的框图。
具体实施方式
在相关技术中，社会上具备一定社会公信力或权威的认证方会根据商家或机构的实际情况，为商家或机构评定一种或多种第三方认证信息。这类第三方认证信息可在一定程度上反映出商家的信用情况的好坏、或公众对该商家的一个或多个方面能力的评价。认证方可包括但不限于：各类官方机构(如工商部门、税务部门、商标品牌认证部门、卫生局、中央银行等)、各级政府或者行业协会、一些第三方认证机构(如第三方信用评级机构)等。第三方认证信息可反映的商户特性包括：信用级别、资质、资产级别、负债率、规模等。以“信用”为例，若某商家被评定的第三方认证信息为：“海淀区纳税百强企业”，则在一定程度上可以反映出该商家的特征：“信用”较好，那么用户在购买该商家的商品时风险便较低。再例如，若某商家被评定的第三方认证信息为：“严重失信企业”，则在一定程度上可以反映出该商家的特征：“信用”较差，那么用户在购买该商家的商品时风险便较高。
对于用户而言，商家的第三方认证信息可以作为一种参考信息，用以评估订单的风险强弱。然而，在相关技术中，用户一般需要通过认证方的官网等途径查找到商家的第三方认证信息，信息获取效率低。而在电子订单生成或处理的过程中，还无法及时地将商家的第三方认证信息展示给用户，导致用户无法及时地根据商家的第三方认证信息确定电子订单是否具有风险，以至于用户也无法及时发现风险订单，并及时地执行订单修改或订单取消等后续操作。此外，在订单生成或订单支付的过程中，由于用户没有办法及时查看到商家的第三方认证信息并评估出订单风险的高低，这便导致用户可能无意识地针对高风险的订单进行订单生成或支付。一方面，通常直至用户利益受损后，用户才会意识到订单的风险性，然而已为时过晚。另一方面，即便用户能够在订单生成或完成支付后及时发现订单风险，并随即取消订单，然而，对于服务器而言，用户从下单、支付到取消订单，这一系列操作都需要造成服务器资源的消耗，给服务器带来较大的压力。鉴于此，为降低服务器的压力，有必要及时地将第三方认证信息提供给用户，以使得用户能够及时基于第三方认证信息来评估订单风险，避免不必要的订单生成、再取消的过程。
图1是本申请一示例性实施例提供的一种系统架构图。该系统可以包括：一个或多个用户终端10，电子商务平台服务器20，支付平台服务器40，认证信息库31以及订单信息库32。用户终端10通过与电子商务平台服务器20及支付平台服务器40进行信息交互，来完成商品信息浏览、商品选购(添加至购物车)、订单生成及订单支付等过程。订单信息库32用于存储商家和买家交易过程中所生成的电子订单信息。认证信息库31用于存放电子商务平台上各商家的第三方认证信息。其中，第三方认证信息的类型很多，诸如：商家被某信用认证机构评定的某种信用信息，或商家被某资质评定机构评定的某种资质信息，或由某第三方机构根据该商家的综合情况评定的综合评价信息或荣耀称号，等等。认证信息库31的数据可以来源于各个具有一定公信度或权威的认证方的信息库，并进行相应的数据整理。用户终端10可以包括：电脑、手机、pad等各类电子设备。以上客户端设备或服务器主要包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。
图2是本申请一示例性实施例提供的一种认证信息发送方法的流程图，图3是本申请一示例性实施例提供的一种显示第三方认证信息的页面示意图。首先，如图2所示，该方法应用于电子商务平台服务器20，包括步骤101～103，其中：
在步骤101中，接收用户终端发送的用以获取订单信息确认页面的请求，所述请求包含商户标识；
在步骤102中，响应于所述请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系。
本申请实施例中，所述第三方认证信息包括下述至少一种：
用于反映商户信用的信用认证信息；如：税务部评定的“纳税百强企业”等。
用于反映商户资质的资质认证信息；如：工商部评定的“xx百强企业”等。
对商户的评价信息，如：xx平台评定的好评率前十商家等。
本申请实施例中，所述方法还包括如下步骤：
步骤1021：从至少一个认证方信息库获取由认证方评定的第三方认证信息。
如上所述，第三方认证信息是由每一个具有一定公信度或权威的认证方进行认定的，这些被认定的第三方认证信息一般存储于各认证方提供的认证方信息库中。如，国家税务局信息库，卫生部信息库，政府公开信息库等。由于一般第三方认证信息属于对外公开的非机密信息，故可以通过各认证方信息库对外提供的访问接口来获取数据。
步骤1022：根据获取的第三方认证信息，建立认证信息库，该认证信息库存储有商户标识和第三方认证信息的映射关系。
通过对获取到的第三方认证信息进行整理，确定商户标识和第三方认证信息的映射关系。举例而言，对于某商家a11，其分别被认证方a评定为“xx区纳税百强企业”，被认证方b评定为“北京市五星级医疗机构”，被认证方c评定为“北京市百强企业”，则最终确定的商户标识和第三方认证信息的映射关系为：
商家标识：“a11”和第三方认证信息：{xx区纳税百强企业”、“北京市五星级医疗机构”、“北京市百强企业”}的映射关系。
需说明的是，在本申请实施例中，第三方认证信息可包括如下至少一种：
1.认证方认定的称号名；如：“北京市五星级医疗机构”
2.与所述称号名对应的认证方标识；如，北京市卫生局。
3.与所述称号名对应的级别。其中，举例而言，所述级别可以根据认证方来确定。比如，将政府部分认证的第三方认证信息的级别定义为第一级别，将第三方认证机构认证的第三方认证信息的级别定义为第二级别，等等。
通过建立上述认证信息库，使得商户平台服务器或支付平台服务器可以通过查询该认证信息库，查找到指定商户的第三方认证信息。当然，在可行的实施例中，也可以没有上述认证信息库，在需要获取数据时，由商户平台服务器或支付平台服务器利用一个或多个认证方系统对外提供的访问接口来实时获取数据并反馈。
本申请一实施例中，所述第三方认证信息可以包括但不限于：由认证方评定的商户资质信息、或由认证方评定的商户信用信息。
其中，商户资质信息可以反映商户具备的某一方面的资质，如，国家相关部分认证的“所销售商品为名牌商品”，“认证的体育健儿专用商品”，“xx产品一级经销商”、“五星级酒店”等。商户信用信息可以反映商户的信用度，如，相关机构认定的“纳税百强企业”，“信用示范标杆企业”“严重失信企业”，“异常运营企业”等。
在步骤103中，向所述用户终端推送包含查找到的第三方认证信息的页面数据；其中，所述页面数据用于渲染所述订单信息确认页面。
接下来，结合图3来说明步骤101～103的过程。用户在浏览商品的过程中，可以将可能需要购买的商品添加到“购物车”中。用户可以在“购物车”页面中点击“结算”，来触发用于获取订单信息确认页面的请求。当然，用户也可以在浏览某商品信息时，点击“立即购买”来触发用于获取订单信息确认页面的请求。服务器在接收到用户终端发送的用于获取订单信息确认页面的请求之后，可以根据商户标识查找到第三方认证信息，并向用户终端反馈包含第三方认证信息的页面数据。最终，用户终端可以利用页面数据渲染得到订单信息确认页面，用户可以在订单信息确认页面内选择或填写收货地址等信息，并对已有的订单信息(包括商品信息、收件人、付款金额等)进行确认，在确认信息无误之后，点击“提交订单”进行下单。其中，可在订单信息确认页面中的订单信息显示区域112内显示商户的第三方认证信息，如：“海淀区百强企业”，以供用户在确认订单信息时一并查看到该第三方认证信息，及时评估订单风险性。
图4是本申请一示例性实施例提供的另一种认证信息发送方法的流程图，图5是本申请一示例性实施例提供的另一种显示第三方认证信息的页面示意图。首先，如图4所示，该方法应用于电子商务平台服务器20，包括步骤201～203，其中：
在步骤201中，接收用户终端发送的包含商户标识的订单生成请求。
在步骤202中，响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系。
在步骤203中，向所述用户终端推送查找到的第三方认证信息。
本申请实施例中，可以通过弹框消息的方式推送第三方认证信息，或者在订单信息确认页面内的特定位置展示第三方认证信息。
接下来，结合图5来说明步骤201～203的过程。在订单信息确认页面上，用户在确认信息无误之后可以通过点击“提交订单”来触发订单生成请求。随后，当服务器接收到来自用户终端的上述订单生成请求之后，可以查找到与商户标识对应的第三方认证信息，并向所述用户终端推送查找到的第三方认证信息。最终，用户终端上可以弹出一包含第三方认证信息(如：该商家的第三方认证信息是：海淀区纳税百强企业)的消息框114。其中，该第三方认证消息可以悬浮于订单信息确认页面上，并停留片刻自动消失，以供用户查看到该第三方认证信息，与此同时，服务器可以生成一笔电子订单。当然，第三方认证信息也可以被显示在订单信息确认页面中的某个位置，为了便于用户查看，可以采取标红等方式进行突出显示。
图6是本申请一示例性实施例提供的又一种认证信息发送方法的流程图，图7是本申请一示例性实施例提供的又一种显示第三方认证信息的页面示意图。首先，如图6所示，该方法应用于支付平台服务器40，包括步骤301～303，其中：
在步骤301中，接收用户终端发送的包含商户标识的订单支付请求。
在步骤302中，响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系。
在步骤303中，向所述用户终端推送查找到的第三方认证信息。
接下来，结合图7来说明步骤301～303的过程。在用户点击“提交订单”之后，电子商务平台服务器可以生成一笔电子订单，并且，用户终端可以由订单信息确认页面跳转到支付页面，以完成付款。在支付页面上，用户可以选择支付方式、支付账号等，并输入相应的支付密码，此后，通过点击“确认付款”来触发订单支付请求。当支付平台服务器接收到来自用户终端的订单支付请求之后，也可以通过认证信息库查询与商户标识对应的第三方认证信息，并反馈给用户终端。最终，用户终端上可以弹出一包含第三方认证信息(如：该商家的第三方认证信息是：海淀区纳税百强企业)的消息框116。其中，该第三方认证消息可以悬浮于支付页面上，并停留片刻自动消失，以供用户查看到该第三方认证信息。
在上述各实施例提供的认证信息发送方法中，通过在订单生成或订单支付的过程中查找与商户标识对应的第三方认证信息，并将查找到的第三方认证信息推送给用户终端，以供用户查看，使得用户可以快速查看到商户的第三方认证信息，信息获取效率更高。此外，用户可以基于第三方认证信息来确定当前订单是否存在风险，进而可以使得用户及时发现风险订单并执行相应的操作(如取消订单等)。
图8是本申请一示例性实施例提供的一种订单生成方法的流程图，图9是本申请一示例性实施例提供的再一种显示第三方认证信息的页面示意图。首先，如图8所示，该方法应用于电子商务平台服务器20，包括步骤401～404，其中：
在步骤401中，接收用户终端发送的包含订单信息的订单生成请求，其中所述订单信息包括商户标识；
在步骤402中，响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
在步骤403中，向所述用户终端推送查找到的第三方认证信息；
在步骤404中，当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述订单信息生成电子订单。
接下来，结合图9来说明步骤401～404的过程。在订单信息确认页面上，用户可以通过点击“提交订单”来触发订单生成请求。电子商务平台服务器20在接收到用户终端发送的订单生成请求之后，会通过认证信息库查找与商家的第三方认证信息，并将查找到的第三方认证信息反馈给用户终端。最终，用户终端可以弹出一包含第三方认证信息的提示消息118，并且，需要用户对第三方认证信息进行确认，才会执行后续处理动作。具体地，当用户根据第三方认证信息(如“xx市百强企业”)判定订单风险低时，用户可以点击“确认”，来触发确认指令，服务器在收到确认指令后，生成一笔电子订单。反之，当用户根据第三方认证信息(如“严重失信企业”)判定订单风险高时，则用户可以点击“取消”，相应地，服务器不会执行生成电子订单的动作。
图10是本申请一示例性实施例提供的一种订单支付方法的流程图，图11是本申请一示例性实施例提供的又一种显示第三方认证信息的页面示意图。首先，如图10所示，该方法应用于支付服务器40，包括步骤501～504，其中：
在步骤501中，接收用户终端发送的包含支付信息的订单支付请求，所述支付信息包括商户标识；
在步骤502中，响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
在步骤503中，向所述用户终端推送查找到的第三方认证信息；
在步骤504中，当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述支付信息执行支付。
接下来，结合图11来说明步骤501～504的过程。用户在下单之后，可以通过在支付页面上点击“确认付款”，来触发订单支付请求，支付信息可包括：付款方账号，收款方账号，支付金额，支付时间等。服务器在收到订单支付请求，同理，也可以查找到相应的第三方认证信息并反馈至用户终端。最终，用户终端可以弹出一包含第三方认证信息的提示消息119，并且，需要用户对第三方认证信息进行确认，才会执行后续处理动作。具体地，当用户根据第三方认证信息(如“xx市百强企业”)判定订单风险低时，用户可以点击“确认支付”，来触发确认指令，服务器在收到确认指令后，执行扣款动作。反之，当用户根据第三方认证信息(如“严重失信企业”)判定订单风险高时，则用户可以点击“取消支付”，相应地，服务器不会执行扣款动作。
可见，利用以上实施例提供的订单生成方法和订单支付方法，在订单生成或订单支付的过程中，由于需要用户对查看到的第三方认证信息进行确认后，服务器才执行后续的生成订单或支付的动作，这在一定程度上可减少服务器生成电子订单后，因后续用户发现订单存在风险而随即取消订单的情况，或者用户付款后又取消订单的情况，从而降低服务器生成、取消电子订单的频率，缓解服务器压力。
需说明的是，本文所提及的“商家”可以包括但不限于：在线下或线上提供商品销售、商品制造或提供其他形式的服务的个体或团体。其中，对于一种互联网交易平台，所述商家可以是某一线上店铺所对应的销售商家，也可以是生产某一在售商品的商家。如，一种线上销售的“豆浆机”，若销售商家的名称是：“xx家用电器上海地区专营店”，则显示的商家第三方认证信息可以是针对该名为“xx家用电器上海地区专营店”的商家的第三方认证信息，如：“xx平台年度成交额10强”。若与上述“豆浆机”对应的商家是其生产商家：“xx电器有限公司”，则显示的商家第三方认证信息可以是针对该名为“xx电器有限公司”的商家的第三方认证信息，如：“世界豆浆机名牌影响力百强企业”。
图12是本申请一示例性实施例提供的一种电子设备的结构示意图。该电子设备可以是电子商务平台服务器或支付平台服务器，请参考图12，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成认证信息发送装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图13，在一种软件实施方式中，一种认证信息发送装置，包括：
接收单元601，用于接收用户终端发送的包含商户标识的订单生成请求；
查找单元602，用于响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元603，用于向所述用户终端推送查找到的第三方认证信息。
本申请实施例中，所述第三方认证信息包括下述至少一种：
用于反映商户信用的信用认证信息；
用于反映商户资质的资质认证信息；
对商户的评价信息。
在另一软件实施方式中，一种认证信息发送装置，包括：
接收单元601，用于接收用户终端发送的包含商户标识的订单支付请求；
查找单元602，用于响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元603，用于向所述用户终端推送查找到的第三方认证信息。
在又一软件实施方式中，一种认证信息发送装置，包括：
接收单元601，用于接收用户终端发送的用以获取订单信息确认页面的请求，所述请求包含商户标识；
查找单元602，用于响应于所述请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元603，用于向所述用户终端发送包含查找到的第三方认证信息的页面数据；所述页面数据用于渲染所述订单信息确认页面。
图14是本申请一示例性实施例提供的一种电子设备的结构示意图。该电子设备可以是电子商务平台服务器，请参考图14，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成订单生成装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图15，在一种软件实施方式中，一种订单生成装置，包括：
接收单元701，用于接收用户终端发送的包含订单信息的订单生成请求，所述订单信息包括商户标识；
查找单元702，用于响应于所述订单生成请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元703，用于向所述用户终端推送查找到的第三方认证信息；
生成单元704，用于当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述订单信息生成电子订单。
图16是本申请一示例性实施例提供的一种电子设备的结构示意图。该电子设备可以是支付平台服务器，请参考图16，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成订单支付装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
请参考图17，在一种软件实施方式中，一种订单支付装置，包括：
接收单元801，用于接收用户终端发送的包含支付信息的订单支付请求，所述支付信息包括商户标识；
查找单元802，用于响应于所述订单支付请求，根据预设的认证信息库，查找与所述商户标识对应的第三方认证信息；其中所述认证信息库中记录有商户标识和第三方认证信息的对应关系；
发送单元803，用于向所述用户终端推送查找到的第三方认证信息；
支付单元804，用于当接收到来自所述用户终端的用于确认所述第三方认证信息的确认指令时，根据所述支付信息执行支付。需说明的是，本文所记载的方法实施例的内容和装置实施例的内容，在不相冲突的情况下，可以互为补充。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。