订单处理方法、装置及支付服务器与流程

本申请涉及网络通信技术领域，尤其涉及订单处理方法、装置及支付服务器。

背景技术：

在某些业务场景，如客户端在飞机起飞运行之前定制机票改期或升级舱位，可将改期机票或升级舱位定义为一类定制产品，其根据客户需求设定，产品信息较个性，没有统一的订单数据。需要远程实现支付操作时，提供机票服务的商户端支付二维码，然后通过邮件、彩信或传真等通信方式，将支付二维码向定制机票改期或升级舱位的客户端，客户端通过扫描支付二维码实现支付操作。

但是，支付二维码的传输过程存在链接安全风险，因此会导致支付操作的可靠性不高。

技术实现要素：

本申请提供订单处理方法、装置及支付服务器，以解决现有通过二维码实现的支付操作可靠性低的问题。

根据本申请实施例的第一方面，提供一种订单处理方法，所述方法应用在支付服务器上，所述方法包括：

接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户；

响应所述订单创建请求，生成与所述第二账户关联的支付订单，所述支付订单包括所述订单数据；

接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

在一个实施例中，所述订单创建请求还包括所述第二用户的实名制信息；所述响应所述订单创建请求，生成与所述第二账户关联的支付订单，包括：

查找与所述第二账户对应的实名制信息；

判断所述第二用户的实名制信息与查找到的实名制信息是否匹配；

若所述第二用户的实名制信息与查找到的实名制信息匹配，则响应所述订单创建请求，生成与所述第二账户关联的支付订单；

若所述第二用户的实名制信息与查找到的实名制信息不匹配，则向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

在一个实施例中，所述响应所述订单创建请求，生成与所述第二账户关联的支付订单，包括：

查找与所述第二账户对应的联系方式；

向与所述联系方式对应的联系终端发送包括所述订单数据的订单数据校验请求；

若在预设时段接收到确认订单数据无误的反馈信息，则响应所述订单创建请求，生成与所述第二账户关联的支付订单；

若在预设时段未接收到确认订单数据无误的反馈信息，则向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

在一个实施例中，所述响应所述订单创建请求，生成与所述第二账户关联的支付订单，包括：

对所述订单数据进行数字签名验证；

若验证成功，则响应所述订单创建请求，生成与所述第二账户关联的支付订单；

若验证失败，则终止订单处理。

在一个实施例中，所述响应所述订单创建请求，生成与所述第二账户关联的支付订单，包括：

调用预设的订单创建模型；

将所述订单数据输入所述预设的订单创建模型，生成所述支付订单；

将所述支付订单与所述第二账户关联。

在一个实施例中，所述接收第二客户端设备根据所述支付订单发送的支付操作信息后，所述方法还包括：

若所述支付操作信息包括成功支付提示，则向所述第一客户端设备发送订单支付成功提示，所述成功支付提示用于标示所述第二客户端设备基于所述支付订单实现了订单支付；

若所述支付操作信息不包括所述成功支付提示，则向所述第一客户端设备发送用于标示订单支付失败的支付失效信息。

根据本申请实施例的第二方面，提供一种订单处理装置，所述装置应用在支付服务器上，所述装置包括：

订单请求接收模块，用于接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息；

支付订单生成模块，用于响应所述订单创建请求，生成与所述第二账户关联的支付订单，所述支付订单包括所述订单数据；

操作信息接收模块，用于接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

在一个实施例中，所述订单创建请求还包括所述第二用户的实名制信息；所述支付订单生成模块包括：

实名信息查找子模块，用于查找与所述第二账户对应的实名制信息；

实名信息匹配子模块，用于判断所述第二用户的实名制信息与查找到的实名制信息是否匹配；

第一支付订单生成子模块，用于在所述第二用户的实名制信息与查找到的实名制信息匹配时，响应所述订单创建请求，生成与所述第二账户关联的支付订单；

第一失效信息发送子模块，用于在所述第二用户的实名制信息与查找到的实名制信息不匹配时，向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

在一个实施例中，所述支付订单生成模块包括：

联系方式查找子模块，用于查找与所述第二账户对应的联系方式；

校验请求子模块，用于向与所述联系方式对应的联系终端发送包括所述订单数据的订单数据校验请求；

第二支付订单生成子模块，用于在预设时段接收到确认订单数据无误的反馈信息时，响应所述订单创建请求，生成与所述第二账户关联的支付订单；

第二失效信息发送子模块，用于在预设时段未接收到确认订单数据无误的反馈信息时，向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

在一个实施例中，所述支付订单生成模块包括：

订单数据验证子模块，用于对所述订单数据进行数字签名验证；

第三支付订单生成子模块，用于在验证成功时，响应所述订单创建请求，生成与所述第二账户关联的支付订单；

业务处理终止子模块，用于在验证失败时，终止订单处理。

在一个实施例中，所述支付订单生成模块包括：

模型调用子模块，用于调用预设的订单创建模型；

第四支付订单生成子模块，将所述订单数据输入所述预设的订单创建模型，生成所述支付订单；

支付订单关联子模块，用于将所述支付订单与所述第二账户关联。

在一个实施例中，所述装置还包括：

支付成功提示发送模块，用于所述支付操作信息包括成功支付提示时，向所述第一客户端设备发送订单支付成功提示，所述成功支付提示用于标示所述第二客户端设备基于所述支付订单实现了订单支付；

第三失效信息发送子模块，用于在所述支付操作信息不包括所述成功支付提示时，向所述第一客户端设备发送用于标示订单支付失败的支付失效信息。

根据本申请实施例的第三方面，提供一种支付服务器，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为：

接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户；

响应所述订单创建请求，生成与所述第二账户关联的支付订单，所述支付订单包括所述订单数据；

接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

应用本申请实施例，接收第一客户端设备发送的订单创建请求；响应所述订单创建请求，生成与所述第二账户关联的支付订单，接收第二客户端设备根据所述支付订单发送的支付操作信息，可完成通过第一账户登录支付服务器的第一用户与通过第二账户登录支付服务器的第二用户之间的定制产品的支付操作，由于本申请实施例中的定制产品的支付操作基于支付服务器生成的支付订单完成，因此安全性较高，并且不会受到外界因素的干扰，可以有效提高支付操作的可靠性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是本申请实施例实现订单处理的一个应用场景示意图；

图2是本申请订单处理方法的一个实施例流程图；

图3是本申请订单处理方法的另一个实施例流程图；

图4是本申请订单处理方法的一个实施例流程图；

图5是本申请订单处理方法的另一个实施例流程图；

图6是本申请订单处理方法所在服务器的一种硬件结构图；

图7是本申请订单处理装置的一个实施例框图；

图8是本申请订单处理装置的另一个实施例框图；

图9是本申请订单处理装置的另一个实施例框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例的订单处理方法，涉及到定制产品的支付订单生成和支付操作，定制产品可以为航空领域改期的机票或升级的舱位，可以为服装领域私人定制的服装，还可为服务行业私人定制的搬家服务、家政服务，或者为其他业务领域用户定制的个性化产品。定制产品的产品信息较个性，没有统一的订单数据。需要电子支付时，可通过以下的现有支付技术实现支付操作：一、商户通过电话通话、即时通信等方式提供银行账号给客户，客户通过银行汇款的方式完成支付操作；二、商户生成支付二维码后通过邮件、彩信或传真等通信方式将支付二维码发送给客户端，客户通过扫描支付二维码完成支付操作；三、商户收集客户端的银行卡号等信息，通过调用银行接口进行银行卡号、有效期、持卡人姓名、身份证、手机号验证无误后，向银行发起扣款请求，完成支付操作。

但是，上述方式一需要客户通过银行汇款的方式完成支付操作，便捷性差，且商户需要对银行收款与机票订单逐笔核对，时效性差。上述方式二中商户需要将支付二维码通过Email、彩信或传真等手段发送至客户，在传输过程中支付二维码易被篡改，安全性差。上述方式三中商户端直接获知了客户的银行卡号等敏感信息，会提高银行卡号等敏感信息的泄密风险。

而目前时效性优、便捷性好和安全性高的支付方式，如支付服务器响应客户端的支付请求，向该客户端的账户推送支付订单，客户端通过支付订单实现支付操作的方式，并不适用于本申请实施例涉及的定制产品。因定制产品的产品信息较个性，支付服务器无法预先针对定制产品生成支付订单，若定制产品的客户端基于现有的订单支付技术向支付服务器发送支付请求后，支付服务器没有定制产品的产品名称、金额、数量等个性化的产品信息，难以实时生成支付订单，进而无法及时响应定制产品的客户端的请求，向该客户端推送支付订单，因此，该客户端难以通过现有的支付服务器，基于现有支付订单的操作流程实现定制产品的支付操作。

而本申请实施例的订单处理方法，通过接收第一客户端设备发送的订单创建请求，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户；响应所述订单创建请求，生成与所述第二账户关联的支付订单，接收第二客户端设备根据所述支付订单发送的支付操作信息，可完成通过第一账户登录支付服务器的第一用户，与通过第二账户登录支付服务器的第二用户之间的定制产品的支付操作。定制产品的支付操作基于支付服务器生成的支付订单完成，因此安全性较高、时效性优、便捷性好，并且不会受到外界因素的干扰，可以有效提高支付操作的可靠性。接下来对本申请的方案进行详细说明。

参见图1，图1是本申请实施例实现订单处理的一个应用场景示意图：

图1中，支付服务器可以由第三方支付平台服务商进行设置，通过该支付服务器可以向注册用户提供各种支付业务应用，以实现不同用户间的支付操作。如图1中，第一用户可以预先在支付服务器上注册第一账户，第二用户可以预先在支付服务器上注册第二账户。本申请实施例中的客户端设备可以具体指各种具有网络连接功能的设备，例如，手机、平板电脑等，当然，本申请实施例也不排除在PC(Personal Computer，个人计算机)上的应用。

在图1示出的应用场景中，第一用户可为提供定制产品的商户或代理所述商户的支付接收业务的用户，第二用户可为定制所述定制产品的客户或代理所述客户的支付操作业务的用户。当第一用户要与第二用户之间通过支付服务器提供的支付通道进行定制产品的支付操作时，第一用户可以在第一客户端设备上基于第一账户登录支付服务器，第二用户可以在第二客户端设备上基于第二账户登录支付服务器，然后第一客户端设备作为订单创建请求发起方，支付服务器可以获取第一客户端设备在发起订单创建请求时，所发送的第二账户和包括定制产品的相关信息的订单数据，响应所述订单创建请求，生成与所述第二账户关联的支付订单，当第二客户端设备根据所述支付订单进行支付操作时，支付服务器可以接收第二客户端设备根据所述支付订单发送的支付操作信息，根据支付操作信息可以判断第一客户端设备和第二客户端设备的支付操作完成。基于支付服务器生成的支付订单完成支付操作，安全性较高，并且不会受到外界因素的干扰，可以有效提高支付操作的可靠性。下面将结合附图1对本申请实施例进行详细描述。

参见图2，图2是本申请订单处理方法的一个实施例流程图，该实施例应用在支付服务器侧，包括步骤201-203：

步骤201：接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

本申请实施例中，第一/二用户在支付服务器上注册第一/二账户后，可以基于该第一/二账户登录支付服务器，以完成各种业务操作。其中，第一/二账户是可以由支付服务器唯一识别第一/二用户的信息，其可以包含第一/二用户的用户名，例如，第一账户为“user1@ABCD.com”；第一/二账户可以包括第一/二用户的手机号或会员名。业务操作主要指支付服务器向用户提供的对定制产品请求进行订单创建请求或订单支付的功能，或者其他与支付相关的功能。

其中，所述订单创建请求除包括所述订单数据和第二账户外，还可包括第二用户的实名制信息和联系方式，便于联系第二用户和验证第二用户身份的真实性。第二账户、第二用户的实名制信息和联系方式，可在第二用户向第一用户定制所述定制产品时，通过第二客户端设备向第一客户端设备发送，如通过短信、邮件、旺旺等即时通讯方式。定制产品的相关信息为生成定制产品的支付订单所需的产品信息，可包括定制产品的名称、订单号、价值、数量等个性化的产品信息。

在本申请的一个例子中，当第二用户向第一用户求取定制产品后，第一用户是被支付方、第二用户是支付方，需要通过支付服务器提供的支付通道进行支付时，第一用户可以通过第一客户端设备向支付服务器发送所述订单创建请求，例如，该订单创建请求可以通过在第一客户端设备的应用界面上设置的订单创建请求选项按钮进行触发，或者也可以通过对第一客户端设备进行特定姿势的操作(例如，摇一摇)进行触发等，对此本申请实施例不进行限制。

在本申请的另一个例子中，为了提高订单数据传输的安全性，在第一用户通过第一客户端设备向支付服务器发送订所述单支付请求前，第一用户可以通过第一客户端设备先对订单数据进行预设组合处理，再对组合处理后的订单数据进行MD5数字签名处理，生成签名后的订单数据，可对订单数据提供数据完整性保护。所述预设组合处理可将订单数据的各个参数按照预定顺序组合排列，所述预定顺序如：定制产品的订单号、定制产品的名称、定制产品的数量、定制产品的金额。

步骤202：响应所述订单创建请求，生成与所述第二账户关联的支付订单，所述支付订单包括所述订单数据。

本申请实施例中，在生成所述定制产品的支付订单前，支付服务器可对第一用户的身份ID和交易安全校验码(key)进行查询认证，认证成功后再生成所述定制产品的支付订单，在生成所述定制产品的支付订单后，第二用户可以通过不同方式获知所述支付订单，触发第二客户端设备向支付服务器发送针对该支付订单的支付操作信息。

其中，在第二用户获知所述支付订单的一个可选实现方式中：支付服务器可以向第一客户端设备发送所述支付订单，第一客户端设备将所述支付订单向第二客户端设备推送，第二用户在第二客户端设备的订单支付界面上导入所述支付订单；第二用户获知所述支付订单的另一个可选实现方式中：支付服务器也可以直接向第二账户推送所述支付订单。

本申请的一个例子中，所述响应所述订单创建请求，生成与所述第二账户关联的支付订单的一个可选实现方式包括：

对所述订单数据进行数字签名验证，所述数字签名验证可为MD5数字签名验证。

若验证成功，则响应所述订单创建请求，生成与所述第二账户关联的支付订单。

若验证失败，则终止订单处理。

本例子对订单数据进行数字签名验证，可验证订单数据的安全性和完整性，以防订单数据在发送过程中被篡改或损坏。

本申请的一个例子中，所述响应所述订单创建请求，生成与所述第二账户关联的支付订单的另一个可选实现方式包括：

调用预设的订单创建模型。所述预设的订单创建模型可为信用卡无卡支付系统的订单创建模型，或其他支付系统的电子订单创建模型。

将所述订单数据输入所述预设的订单创建模型，生成所述支付订单。

将所述支付订单与所述第二账户关联。

本例子，通过预设的订单创建模型，可快速生成所述支付订单。

在本申请的其他实施例中，可将第一账户、第二账户和所述订单数据输入订单创建模型，生成所述支付订单；还可将第一用户及第二用户的其他用户信息也输入订单创建模型，生成所述支付订单，对此本申请实施例不做限制。

在生成支付订单后，可根据预设的关联关系，将所述支付订单与所述第二账户关联；也可将所述支付订单与所述第二账户对应存储到关联表中，实现所述支付订单与所述第二账户的关联。

步骤203：接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

本申请实施例中，第二客户端设备发送的支付操作信息可包括成功支付提示或拒绝支付提示。成功支付提示可以包括第二账户、支付信息等，若直接通过第二账户中的资金完成本次支付操作时，支付信息可包括支付金额；若通过转账方式完成本次支付操作时，支付信息可以包括转账金额，转账账户等信息。当第二用户拒绝支付所述支付订单时，可触发支付界面的拒绝支付按钮，向支付服务器发送包括拒绝支付提示的支付操作信息。

此外，当用户拒绝支付所述订单支付时，也可不对所述支付订单做任何操作，相应的不向支付服务器发送任何支付操作信息，支付服务器在预设时段内接收不到支付操作信息，可判定对支付订单的支付操作失败。

在一个可选实现方式中，所述接收第二客户端设备根据所述支付订单发送的支付操作信息后，所述方法还包括：

若所述支付操作信息包括成功支付提示，则向所述第一客户端设备发送订单支付成功提示，所述成功支付提示用于标示所述第二客户端设备基于所述支付订单实现了订单支付。

若所述支付操作信息不包括所述成功支付提示，则向所述第一客户端设备发送用于标示订单支付失败的支付失效信息。

其中，向所述第一客户端设备发送订单支付成功提示或支付失效信息后，第一客户端设备对应所述定制产品标记支付成功标识或订单失败标识。

由上述实施例可见，该实施例中的订单处理过程中，定制产品的支付操作基于支付服务器生成的支付订单完成，因此安全性较高，并且不会受到外界因素的干扰，可以有效提高支付操作的可靠性。

在某些例子中，为了降低第二账户被误用的风险，所述订单创建请求还可包括所述第二用户的实名制信息，可在生成支付订单前，对第二账户进行实名制验证，验证过程参见图3，图3是本申请订单处理方法的另一个实施例流程图，该实施例应用在支付服务器侧，可包括步骤301-306：

步骤301：接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据、第二用户的实名制信息和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

步骤302：查找与所述第二账户对应的实名制信息。

本申请实施例中，支付服务器对应第二账户存储有账户注册时输入的实名制信息，实名制信息可包括用户身份证照的照片、用户学位证的照片、用户户口本照片、用户身份证号码、用户电话号码等用于唯一表示用户身份的信息。

查找与所述第二账户对应的实名制信息的方式可包括：根据支付服务器预存的账户与实名制信息间的对应关系，查询与所述第二账户对应存储的实名制信息。查找与所述第二账户对应的实名制信息的方式还可包括：从支付服务器获取对应第二账户存储的用户名，然后通过网络向存储有实名制信息的平台请求所述用户名对应的实名制信息。本申请对查找与所述第二账户对应的实名制信息的方式不进行限制。

步骤303：判断所述第二用户的实名制信息与查找到的实名制信息是否匹配。

本申请实施例中，若所述第二用户的实名制信息与查找到的实名制信息一致，则可判定所述第二用户的实名制信息与查找到的实名制信息匹配，若所述第二用户的实名制信息与查找到的实名制信息不一致，则可判定所述第二用户的实名制信息与查找到的实名制信息不匹配。

在订单创建请求包括第二用户的联系方式、用户名时，可判断订单创建请求所包括的第二用户的联系方式、用户名与对应第二账户存储的联系方式、用户名是否一致。

步骤304：若所述第二用户的实名制信息与查找到的实名制信息不匹配，则向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

步骤305：若所述第二用户的实名制信息与查找到的实名制信息匹配，则响应所述订单创建请求，生成与所述第二账户关联的支付订单。

步骤306：接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

在某些例子中，为了避免订单数据错误和重复创建订单，可在生成支付订单前，请求第二用户对订单数据进行校验，校验过程参见图4，图4是本申请订单处理方法的一个实施例流程图，该实施例应用在支付服务器侧，包括步骤401-406：

步骤401：接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

步骤402：查找与所述第二账户对应的联系方式。

本申请实施例中，支付服务器对应第二账户存储有账户注册时输入的联系方式，联系方式可包括用户电话号码、邮箱账号或其他通信方式对应的通信账号。

查找与所述第二账户对应的联系方式的方式可包括：根据支付服务器预存的账户与联系方式间的对应关系，查询与所述第二账户对应存储的联系方式。查找与所述第二账户对应的实名制信息的方式还可包括：从订单创建请求中查找联系方式。本申请对查找与所述第二账户对应的联系方式的方式不进行限制。

步骤403：向与所述联系方式对应的联系终端发送包括所述订单数据的订单数据校验请求。

本申请实施例中，对应步骤402中的联系方式，可通过电话通话、短信、邮件等通信方式向对应的联系终端发送所述订单数据验证请求，所述联系终端可为第二客户端设备。

步骤404：若在预设时段未接收到确认订单数据无误的反馈信息，则向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

所述预设时段可为30秒或60秒。

步骤405：若在预设时段接收到确认订单数据无误的反馈信息，则响应所述订单创建请求，生成与所述第二账户关联的支付订单。

步骤406：接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

参见图5，图5是本申请订单处理方法的另一个实施例流程图，该实施例结合图1所示应用场景，通过支付服务器与客户端设备之间的交互，详细描述了一种订单处理过程，其中，第一客户端设备可以是商户持有的商户设备，第二客户端设备可以是向商户购买定制产品的客户持有的客户设备，该实施例包括以下步骤501-513：

步骤501：商户设备和客户设备分别开启各自的支付应用后登录支付服务器。

本实施例中，商户与客户之间为了实现定制产品的订单支付，可以预先在商户设备和客户设备上分别安装支付应用(APP，Application)，在开启该支付APP后，通过注册该支付服务器时的账户名和密码登录到该支付服务器。

步骤502：商户设备向支付服务器发送订单创建请求，所述商户设备是商户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据、客户实名制信息和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

步骤503：支付服务器对所述订单数据进行数字签名验证。

步骤504：在验证成功时，支付服务器获取与第二账户对应的实名制信息和客联系方式。

步骤505：支付服务器判断第二账户对应的实名制信息与订单创建请求中的实名制信息是否一致。

步骤506：若不一致，支付服务区向商户设备发送请求失效信息。

步骤507：若一致，支付服务器向与联系方式对应的客户设备发送包括所述订单数据的订单数据校验请求。

步骤508：客户设备在预设时段未向支付服务器发送确认订单数据无误的反馈信息，支付服务区向商户设备发送请求失效信息。预设时段可为30秒或60秒。

步骤509：客户设备在预设时段向支付服务器发送确认订单数据无误的反馈信息。

步骤510：支付服务器响应所述订单创建请求，生成与所述第二账户关联的支付订单。

步骤511：支付服务器向客户设备推送所述支付订单。

步骤512：客户设备根据所述订单完成支付操作后，向支付服务器发送支付操作信息。

步骤513：支付服务器根据支付操作信息确认支付操作成功后，向商户设备发送订单成功支付提示。

由上述实施例可见，该实施例可以基于支付服务器生成的定制产品的支付订单，完成商户与客户之间的订单支付操作，因此安全性较高，并且不会受到外界自然环境的干扰，可以有效提高支付业务的可靠性。

与前述订单处理方法的实施例相对应，本申请还提供了订单处理装置的实施例。

本申请订单处理装置的实施例可以应用在支付服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在支付服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图6所示，为本申请订单处理装置所在支付服务器的一种硬件结构图，除了图6所示的处理器610、内存620、网络接口630、以及非易失性存储器640之外，实施例中装置所在的支付服务器通常根据该服务器的实际功能，还可以包括其他硬件，对此不再赘述。

参见图7，图7是本申请订单处理装置的一个实施例框图，该装置包括：订单请求接收模块710、支付订单生成模块720和操作信息接收模块730。

其中，订单请求接收模块710，用于接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

支付订单生成模块720，用于响应所述订单创建请求，生成与所述第二账户关联的支付订单，所述支付订单包括所述订单数据。

操作信息接收模块730，用于接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

在一个可选的实现方式中，支付订单生成模块720可包括(图7中未示出)：

订单数据验证子模块，用于对所述订单数据进行数字签名验证。

第三支付订单生成子模块，用于在验证成功时，响应所述订单创建请求，生成与所述第二账户关联的支付订单。

业务处理终止子模块，用于在验证失败时，终止订单处理。

在另一个可选的实现方式中，支付订单生成模块720可包括(图7中未示出)：

模型调用子模块，用于调用预设的订单创建模型。

第四支付订单生成子模块，将所述订单数据输入所述预设的订单创建模型，生成所述支付订单。

支付订单关联子模块，用于将所述支付订单与所述第二账户关联。

在一个可选的实现方式中，订单处理装置可包括(图7中未示出)：

支付成功提示发送模块，用于所述支付操作信息包括成功支付提示时，向所述第一客户端设备发送订单支付成功提示，所述成功支付提示用于标示所述第二客户端设备基于所述支付订单实现了订单支付。

第三失效信息发送子模块，用于在所述支付操作信息不包括所述成功支付提示时，向所述第一客户端设备发送用于标示订单支付失败的支付失效信息。

参见图8，图8是本申请订单处理装置的另一个实施例框图，该装置包括：订单请求接收模块810、实名制信息查找子模块820、实名制信息匹配子模块830、第一失效信息发送子模块840、第一支付订单生成子模块850和操作信息接收模块860。

其中，订单请求接收模块810，用于接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据、第二用户的实名制信息和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

实名信息查找子模块820，用于查找与所述第二账户对应的实名制信息。

实名信息匹配子模块830，用于判断所述第二用户的实名制信息与查找到的实名制信息是否匹配。

第一失效信息发送子模块840，用于在所述第二用户的实名制信息与查找到的实名制信息不匹配时，向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

第一支付订单生成子模块850，用于在所述第二用户的实名制信息与查找到的实名制信息匹配时，响应所述订单创建请求，生成与所述第二账户关联的支付订单。

操作信息接收模块860，用于接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

参见图9，图9是本申请订单处理装置的另一个实施例框图，该装置包括：订单请求接收模块910、联系方式查找子模块920、校验请求子模块930、第二失效信息发送子模块940、第二支付订单生成子模块950和操作信息接收模块960。

其中，订单请求接收模块910，用于接收第一客户端设备发送的订单创建请求，所述第一客户端设备是第一用户基于第一账户登录支付服务器的设备，所述订单创建请求包括订单数据和第二账户，所述订单数据包括定制产品的相关信息，所述第二账户为付款账户。

联系方式查找子模块920，用于根据所述第二账户信息，查找与所述第二账户对应的联系方式。

校验请求子模块930，用于向与所述联系方式对应的联系终端发送包括所述订单数据的订单数据校验请求。

第二失效信息发送子模块940，用于在预设时段未接收到确认订单数据无误的反馈信息时，向所述第一客户端设备发送用于标示订单创建请求失败的请求失效信息。

第二支付订单生成子模块950，用于在预设时段接收到确认订单数据无误的反馈信息时，响应所述订单创建请求，生成与所述第二账户关联的支付订单。

操作信息接收模块960，用于接收第二客户端设备根据所述支付订单发送的支付操作信息，所述第二客户端设备是第二用户基于所述第二账户登录所述支付服务器的设备。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。