交易通信方法、服务器、POS机及电子设备与流程

本公开总体涉及互联网技术领域，具体而言，涉及一种交易通信方法、服务器、pos机、电子设备及计算机可读介质。

背景技术：

pos(pointofsale，销售终端)机几乎全部支持刷银行卡交易，刷卡交易也是大家生活中支付的一种必不可少的选择。对于pos机上的刷卡交易的实现方，必须得遵守银联pos的一些交互规范，但是这些陈旧的规范并没有随着技术的发展进行调整，整个刷卡交易的体验和交易的指标较差。

图1示出相关实施示例中现有pos机的通信交互流程图，交互过程中需要涉及pos机、交易后台和收单机构。如图1所示，pos机刷卡完成后将刷卡交易发送给交易后台，交易后台再将交易密文透传到收单机构，之后再由收单机构向交易后台回传回包，再由交易后台向pos即回传回包。如果pos机收到回包说明交易成功，pos机将交易成功的结果上报给交易后台，交易后台在数据库中对本次交易的结果进行状态更新。但是，如果pos机未收到回包，就会引起冲正，即pos机向交易后台发送冲正请求，交易后台将冲正请求同样通过密文透传的方式发送到收单机构，收单机构接受冲正请求并将冲正响应的回包(即冲正回包)回传到交易后台，交易后台再将冲正回包回传给pos机。pos机收到冲正回包后，将冲正成功的结果上报给交易后台，交易后台在数据库中对本次冲正的结果进行状态更新。

在上述交易和冲正过程中，由于pos机的刷卡交易均是以pos机这一端为准，交易后台充当透传角色，交易后台对于交易的结果以及冲正的结果并不知情，数据库的订单状态也是依赖于pos机上报的结果来完成更新的，因此一旦其中任何一个过程出现网络通信异常，就会容易导致交互的报文丢失。如图1中所示，当pos机未收到交易请求的回包时，pos机就会发起冲正请求，这会导致交易的冲正率偏高。另外，无论是交易请求还是冲正请求，交易后台数据库的订单状态更新单纯地依赖于pos机的上报。当pos机上报的结果(交易或是冲正)没有发送到交易后台时，会导致交易状态不一致；当交易请求没有成功发出时，会造成顾客的钱被扣，但是由于交易后台的订单状态没有得到更新，商家却无法实时地得知交易的状态，从而出现大量的客户投诉工单。

因此，现有技术中的技术方案还存在有待改进之处。

在所述背景技术部分公开的上述信息仅用于加强对本公开的背景的理解，因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开提供一种交易通信方法、服务器、pos机、电子设备及计算机可读介质，解决上述技术问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一方面，提供一种交易通信方法，包括：

接收来自pos机的交易请求，并将所述交易请求发送给请求处理方，其中所述交易请求为响应于所述pos机的刷卡交易而触发；接收并缓存所述请求处理方返回的响应信息；根据所述响应信息更新所述刷卡交易的状态。

在本公开的一个实施例中，所述响应信息为表征交易结果的交易响应数据，所述交易通信方法还包括：

将所述交易响应数据发送给所述pos机；如果所述pos机未收到所述交易响应数据，则触发交易查询请求；所述服务器响应于所述交易查询请求，将缓存的所述交易响应数据发送给所述pos机。

在本公开的一个实施例中，还包括：

如果所述服务器未收到冲正请求，则所述pos机在预设时间段内重复发出所述冲正请求，直到所述服务器收到所述冲正请求，其中所述冲正请求为当所述交易查询请求的查询策略失效后所述pos机仍未收到所述交易响应数据时，由所述pos机触发并发出。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述交易通信方法还包括：

如果所述服务器收到所述冲正请求，但是所述pos机未收到所述冲正响应数据，则所述服务器响应于所述pos机的冲正查询请求，将缓存的所述冲正响应数据发送给所述pos机。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述交易通信方法还包括：

如果所述服务器收到所述冲正请求，但是所述pos机未收到所述冲正响应数据，则所述服务器等待下一次冲正请求，并响应于所述下一次冲正请求将缓存的所述冲正响应数据发送给所述pos机。

在本公开的一个实施例中，还包括：

对缓存的所述交易响应数据和所述冲正响应数据的密文进行解析，并根据解析后的交易结果和冲正结果更新所述刷卡交易的状态。

根据本公开的另一方面，还提供一种服务器，包括：

通信模块，配置为接收来自pos机的交易请求以及将所述交易请求发送给请求处理方，其中所述交易请求为响应于所述pos机的刷卡交易而触发；

缓存模块，配置为接收并缓存所述请求处理方返回的响应信息；

更新模块，配置为根据所述响应信息更新数据库状态。

在本公开的一个实施例中，所述响应信息为表征交易结果的交易响应数据，所述通信模块包括：

交易响应数据发送模块，配置为将所述交易响应数据发送给所述pos机；

交易查询模块，配置为当所述pos机未收到所述交易响应数据而触发交易查询请求时，响应于所述交易查询请求，将缓存的所述交易响应数据发送给所述pos机。

在本公开的一个实施例中，所述通信模块还包括：

冲正请求接收模块，配置为当所述服务器未收到冲正请求时，所述pos机在预设时间段内重复发出所述冲正请求，直到所述服务器收到所述冲正请求，其中所述冲正请求为当所述交易查询请求的查询策略失效后所述pos机仍未收到所述交易响应数据时，由所述pos机触发并发出。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述通信模块还包括：

冲正查询模块，配置为当所述服务器收到所述冲正请求，但是所述pos机未收到所述冲正响应数据时，响应于所述pos机冲正查询请求，将缓存的所述冲正响应数据发送给所述pos机。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述通信模块还包括：

等待冲正模块，配置为当所述服务器收到所述冲正请求，但是所述pos机未收到所述冲正响应数据时，等待下一次冲正请求，并响应于所述下一次冲正请求将缓存的所述冲正响应数据发送给所述pos机。

在本公开的一个实施例中，还包括：

解析模块，配置为对所述缓存模块中的所述交易响应数据和所述冲正响应数据的密文进行解析，并将解析后的交易结果和所述冲正结果发送给所述更新模块进行数据库状态更新。

根据本公开的另一方面，还提供一种交易通信方法，包括：

响应刷卡交易而触发并发出交易请求；向服务器查询所述请求处理方返回的响应信息，其中所述服务器缓存有所述响应信息。

在本公开的一个实施例中，所述响应信息为表征交易结果的交易响应数据，所述交易通信方法还包括：

如果所述pos机未收到所述交易响应数据而触发交易查询请求，并将所述交易查询请求发送给所述服务器；所述pos机接收所述服务器响应于所述交易查询请求而返回的所述交易响应数据。

在本公开的一个实施例中，还包括：

当所述交易查询请求的查询策略失效后，所述pos机仍未收到所述交易响应数据时，所述pos机触发冲正请求。

在本公开的一个实施例中，还包括：

如果所述pos机没有成功发出所述冲正请求，则所述pos机在预设时间段内重复发出所述冲正请求，直到所述冲正请求发出成功。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述交易通信方法还包括：

如果所述pos机已经成功发出所述冲正请求，但是未收到所述冲正响应数据，则所述pos机触发并发出冲正查询请求；所述pos机接收所述服务器响应于所述冲正查询请求而返回的所述冲正响应数据。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述交易通信方法还包括：

如果所述pos机已经成功发出所述冲正请求，但是未收到所述冲正响应数据，则所述pos机接收所述服务器等待下一次冲正请求，并响应于所述下一次冲正请求将缓存的冲正响应数据。

在本公开的一个实施例中，所述pos机采用轮询的查询策略发送所述交易查询请求和所述冲正查询请求。

根据本公开的另一方面，还提供一种pos机，包括：

交易请求模块，配置为响应刷卡交易而触发并发出交易请求；

响应数据查询模块，配置为向服务器查询所述请求处理方返回的响应信息，其中所述服务器缓存有所述响应信息。

在本公开的一个实施例中，所述响应信息为表征交易结果的交易响应数据，所述pos机还包括：

交易查询模块，配置为如果所述pos机未收到所述交易响应数据而触发交易查询请求，并将所述交易查询请求发送给所述服务器；

交易响应数据接收模块，配置为接收所述服务器响应于所述交易查询请求而返回的所述交易响应数据。

在本公开的一个实施例中，还包括：

冲正请求触发模块，配置为当所述交易查询请求的查询策略失效后，所述pos机仍未收到所述交易响应数据时，触发冲正请求。

在本公开的一个实施例中，还包括：

冲正请求发送模块，配置为当所述pos机没有成功发出所述冲正请求时，在预设时间段内重复发出所述冲正请求，直到所述冲正请求发出成功。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述pos机还包括：

冲正查询模块，配置为当所述pos机已经成功发出所述冲正请求，但是未收到所述冲正响应数据时，触发并发出冲正查询请求；

冲正响应数据接收模块，配置为接收所述服务器响应于所述冲正查询请求而返回的冲正响应数据。

在本公开的一个实施例中，所述响应信息为表征冲正结果的冲正响应数据，所述pos机还包括：

冲正响应数据等待模块，配置为当所述pos机已经成功发出所述冲正请求，但是未收到所述冲正响应数据时，等待并接收所述服务器响应于下一次冲正请求而返回的所述冲正响应数据。

根据本公开实施例提供的交易通信方法、服务器、pos机、电子设备及计算机可读介质，通过在服务器侧缓存请求处理方返回的响应数据，使得服务器(即交易后台)对于交易的状态不再是依据pos机上报的结果来更新，而是以服务器缓存的状态为准，能够实时更新，这样商家也能及时得知交易的状态，因订单异常导致的投诉率也大大降低。

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

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1示出相关实施示例中现有pos机的通信交互流程图。

图2示出本公开一实施例中提供的一种交易通信方法的流程图。

图3示出本公开一实施例中步骤s203之后的流程图。

图4示出本公开一实施例中冲正请求没有发出的情况下的步骤流程图。

图5示出本公开一实施例中冲正请求成功发出但是未收到冲正回包的情况下的步骤流程图。

图6示出本公开一实施例中的方法在整个交易流程的交互示意图。

图7示出本公开另一实施例中提供的一种服务器的示意图。

图8示出本公开另一实施例中的通信模块的示意图。

图9示出本公开另一实施例中提供的另一种服务器的示意图。

图10示出本公开一实施例中提供的另一种交易通信方法的流程图。

图11示出本公开一实施例中步骤s101之后流程图。

图12示出本公开一实施例中冲正阶段的步骤流程图。

图13示出本公开另一实施例中提供的一种pos机的示意图。

图14示出本公开另一实施例中提供的一种电子设备的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知结构、方法、装置、实现、材料或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。

图1中的收单机构作为业务处理方，是指银行卡支付交易中，从事特约商户的开拓与管理、授权请求、账单结算等活动，其利益主要来源于商户回佣、商户支付的其他服务费(如pos机租用费、月费等)及商户存款增加，能够实现收单业务的请求处理方除了大多数发卡银行(即收单行)，也有一些非银行专业服务机构。

图1所示的交易流程中交易后台仅充当透传角色，交易的结果以及冲正的结果都是依赖pos机上报，并更新数据库状态。另外，整个交易流程中总是将交易中的核心部分，即订单状态存储在pos机一侧，但是由于pos机是长期暴露在公网中，而且公网的安全性较差，非常容易受到不法分子攻击，使得不法分子有机会对pos机记录的订单状态进行篡改，交易的安全性较差。

图2示出本公开一实施例中提供的一种交易通信方法的流程图，该方法用于交易系统中的服务器，也就是交易后台。该方法包括以下步骤：

如图2所示，在步骤s201中，接收来自pos机的交易请求，其中本实施例中的交易请求为响应于pos机的刷卡交易而触发。

如图2所示，在步骤s202中，将交易请求发送给请求处理方。

如图2所示，在步骤s203中，接收并缓存请求处理方返回的响应信息。

如图2所示，在步骤s204中，根据响应信息更新刷卡交易的状态。

需要说明的是，本实施例中，在请求阶段(也就是pos机向服务器发出请求以及服务器将请求发送给请求处理方的阶段)，服务器仍然充当透传角色，但是在响应阶段(也就是请求处理方向服务器发出响应信息以及服务器将响应信息发送给pos机的阶段)，服务器不再仅仅充当透传响应信息的角色，而是将收到的响应信息缓存下来，这里的“请求”是指交易请求和冲正请求，“响应信息”是指交易响应数据和冲正响应数据。在下述实施例中出现的交易回包就是表征交易是否成功的响应数据，冲正回包就是表征冲正是否成功的响应数据。

根据图1所示流程可知，pos机进行刷卡交易触发后首先进入交易阶段，如果交易阶段pos机未收到交易回包则触发进入下一个阶段，即冲正阶段。因此，在交易阶段，上述步骤s203接收的响应信息为交易回包，交易回包是代表请求处理方针对交易请求是否成功交易的回包。

在本实施例中，图3示出步骤s203之后的流程图，包括以下步骤：

如图3所示，在步骤s301中，将交易回包发送给pos机，如果pos机未收到交易回包则触发交易查询请求，则进行步骤s302。虽然服务器收到请求处理方返回的交易回包之后，会将交易回包发送给pos机，但是由于通信状况的影响，pos机有可能存在收不到交易回包的情况，因此需要pos机主动向服务器进行交易查询。

如图3所示，在步骤s302中，服务器响应于交易查询请求，将缓存的交易回包发送给pos机。也就是，通过服务器将交易回包发送给pos机，以便将交易结果告知给商户，商户获知本次刷卡交易的结果是否成功。

该方法在未收到交易回包的情况下先进行查询，并且查询可以不断重试，如果通过查询以及重试查询能够收到交易回包就能完成交易，不需要再冲正，从而可以降低冲正率。

基于上述步骤s301，pos机按照一定的查询策略向服务器发出交易查询请求，在本实施例中，查询策略可以是轮询，也就是在一段预设时间内(如1分钟)一直查询，直到收到服务器返回的交易回包。但是，如果当交易查询请求的查询策略失效(也就是在预设时间内通过多次查询也未收到交易回包)后，pos机仍未收到交易回包时，则由pos机触发并发出冲正请求，即进入冲正阶段。

在本实施例中，由于通信状况的影响，冲正阶段还包括两种情况：第一种情况，冲正请求没有发出；第二种情况，冲正请求虽然已经成功发出，但是未收到相应的回包，此时，冲正阶段的回包为冲正回包，冲正回包是代表请求处理方针对冲正请求是否成功冲正的回包。

图4示出本实施例中冲正请求没有发出的情况下的步骤流程图，包括以下步骤：

如图4所示，在步骤s401中，pos机在预设时间段内重复发出冲正请求，直到服务器收到冲正请求。

如图4所示，在步骤s402中，服务器收到冲正请求后，将冲正请求再发送给请求处理方。

如图4所示，在步骤s403中，请求处理方针对本次冲正请求产生相应的冲正回包，并发送给服务器。

如图4所示，在步骤s404中，服务器根据冲正回包更新刷卡交易的状态，并将冲正回包发送给pos机，以便将冲正结果告知给商户，商户获知冲正的结果是否成功。

图5示出本实施例中冲正请求成功发出但是未收到冲正回包的情况下的步骤流程图，包括以下步骤：

如图5所示，在步骤s501中，pos机向服务器发出冲正查询请求，也就是进行冲正查询，类似于交易查询的过程。

如图5所示，在步骤s502中，服务器响应于pos机的冲正查询请求，将缓存的冲正回包发送给pos机，以便将冲正结果告知给商户，商户获知冲正的结果是否成功。

本实施例中不会因偶然一次的通信状况影响pos机接收交易回包或冲正回包，而是在没收到之后先进行交易查询和冲正查询，而且是反复查询，这样可以大幅度降低异常订单导致的顾客投诉，为顾客带来良好的刷卡体验。

对于冲正请求成功发出但是未收到冲正回包的情况，还可以采用如下方案：

服务器等待下一次冲正请求，并响应于下一次冲正请求将缓存的冲正回包发送给pos机。由于一般pos机都能够进行自动冲正，因此即便这一次的冲正回包未收到，还会有针对本次刷卡进行冲正的冲正请求从pos机发出，服务器同样可以将冲正的回包发给pos机，以便将冲正结果告知给商户，商户获知冲正的结果是否成功。

需要说明的是，步骤s404中服务器将冲正回包发送给pos机的步骤如果不成功，其后续处理参见对于冲正请求成功发出但是未收到冲正回包的情况下的处理方案，此处不再赘述。

还需要说明的是，本实施例中服务器还对交易回包和冲正回包的密文进行解析，并将解析后的交易结果和冲正结果进行缓存，这样，整个交易的结果都不再如现有方案一样依赖pos机的上报，而是以服务器自己后台缓存的结果为准。与现有方案交易的结果以公网中的pos机上报的结果为准相比，本实施例中的方法可以防止交易结果被人恶意篡改，从而提高交易的安全性。

图6示出本实施例中的方法在整个交易流程的交互示意图。

如图6所示，在交易阶段，pos机触发刷卡交易，将交易请求发送给服务器(图6中均用交易后台表示)，交易后台再将交易请求以交易密文透传的方式发送给请求处理方，请求处理方再将交易回包发送给交易后台，交易后台缓存交易回包，并依据交易回包中的交易结果更新数据库状态。交易后台还将交易回包发送给pos机，如果pos机未收到交易回包则进入查询阶段，进行交易查询。

pos机向交易后台发出查询请求，并在查询策略失效前采用轮询的方式在一定时间内反复重试，交易后台将交易回包发送给pos机。

如果到查询策略，pos机仍然未收到交易回包，则引发冲正，进入冲正阶段。如果交易后台未收到冲正请求，则pos机一直重试发送，直到发出冲正请求。如果交易后台已经收到冲正请求，但是pos机并未收到相应的冲正回包，则进入查询阶段，进行查询，类似于交易查询，交易后台将缓存的冲正回包发送给pos机；或者交易后台等待下一次冲正请求，并响应于下一次冲正请求将缓存的冲正回包发送给pos机。

综上所述，本实施例提供的交易通信方法通过在服务器侧缓存请求处理方返回的回包，使得服务器(即交易后台)对于交易的状态不再是依据pos机上报的结果来更新，而是以服务器缓存的状态为准，能够实时更新，这样商家也能及时得知交易的状态，因订单异常导致的投诉率也大大降低。通过对交互过程进行改进，尽可能降低冲正率，但是在反复查询都未果的情况下冲正也尽量提高冲正的成功率。

图7示出本公开另一实施例中提供的一种服务器的示意图，该服务器就是交易系统中的交易后台，与pos机以及请求处理方共同完成整个交易过程。如图7所示，服务器700包括通信模块710、缓存模块720和更新模块730。

其中通信模块710配置为接收来自pos机的交易请求以及将交易请求发送给请求处理方，其中交易请求为响应于pos机的刷卡交易而触发。简单来说，通信模块710就是完成服务器与pos机以及请求处理方730之间的通信。缓存模块720配置为接收并缓存请求处理方返回的响应信息，这也是本实施例中的服务器与现有方案的主要区别之处，即服务器不仅仅起到透传角色，而是在返回交易回包或冲正回包的过程中将其缓存。更新模块730配置为根据响应信息更新刷卡交易的状态，因此本实施例中的交易结果或冲正结果是以服务器中更新模块730更新后的状态为准。

在本实施例中，通信模块具有两方面的作用，一是与pos机进行交互，即接收pos机发送的交易请求和冲正请求，以及向pos机返回交易回包和冲正回包；二是与请求处理方进行交互，即向请求处理方发送交易请求和冲正请求，以及接收请求处理方返回的交易回包和冲正回包。

图8示出本公开另一实施例中的通信模块的示意图。在本实施例中，交易阶段服务器收到请求处理方返回的回包为交易回包，交易回包是代表请求处理方针对交易请求是否成功交易的回包。如图8所示，通信模块710包括：交易回包发送模块711和交易查询模块712，交易回包发送模块711配置为将交易回包发送给pos机。交易查询模块712配置为当pos机未收到交易回包而触发交易查询请求时，响应于交易查询请求，将缓存的交易回包发送给pos机。通过pos机的查询，服务器将交易回包发送给pos机，以便将交易结果告知给商户，商户获知本次刷卡交易的结果是否成功。查询策略可以是轮询，也就是在一段预设时间内(如1分钟)一直查询，直到收到服务器返回的交易回包。

通过设置交易查询模块，在未收到交易回包的情况下先进行查询，并且查询可以不断重试，如果通过查询以及重试查询能够收到交易回包就能完成交易，不需要再冲正，从而可以降低冲正率。

当交易查询请求的查询策略失效(也就是在预设时间内通过多次查询也未收到交易回包)后，pos机仍未收到交易回包时，由pos机触发并发出冲正请求，即进入冲正阶段。

冲正阶段还包括两种情况：第一种情况，冲正请求没有发出；第二种情况，冲正请求虽然已经成功发出，但是未收到相应的回包，此时，冲正阶段的回包为冲正回包，冲正回包是代表请求处理方针对冲正请求是否成功冲正的回包。

如图8所示，通信模块710还包括冲正请求接收模块713，配置为当服务器未收到冲正请求时，pos机在预设时间段内重复发出冲正请求，直到服务器收到冲正请求。也就是通过反复重试，以确保冲正请求接收模块713能够接收到冲正请求，再将冲正请求再发送给请求处理方，请求处理方针对本次冲正请求产生相应的冲正回包，并发送给服务器。服务器再根据冲正回包更新刷卡交易的状态，并将冲正回包发送给pos机，以便将冲正结果告知给商户，商户获知冲正的结果是否成功。

如图8所示，通信模块710还包括冲正查询模块714，配置为当服务器收到冲正请求，但是pos机未收到冲正回包时，响应于pos机冲正查询请求，将缓存的冲正回包发送给pos机。

通过设置冲正查询模块，在没收到之后先进行交易查询和冲正查询，而且是反复查询，这样可以大幅度降低异常订单导致的顾客投诉，为顾客带来良好的刷卡体验。

如图8所示，通信模块710还包括等待冲正模块715，配置为当服务器收到冲正请求，但是pos机未收到冲正回包时，等待下一次冲正请求，并响应于下一次冲正请求将缓存的冲正回包发送给pos机。

整个交易的结果是以服务器自己后台缓存的结果为准，与现有方案交易的结果以公网中的pos机上报的结果为准相比，本实施例可以防止交易结果被人恶意篡改，从而提高交易的安全性。

另外，该服务器中各个模块中没有涉及的功能参见上述方法实施例中的相关描述，此处不再赘述。

本实施例中的服务器能够实现与上述服务器的交易通信方法相同的技术效果，此处不再赘述。

图9还示出另一种服务器的示意图，除了包括上述的通信模块710、缓存模块720、更新模块730，还包括解析模块740，配置为对通信模块710收到的交易回包和冲正回包的密文进行解析，并将解析后的交易结果和冲正结果发送给缓存模块720进行缓存。

图10示出本公开一实施例中提供的另一种交易通信方法的流程图，该方法用于交易系统中的pos机。该方法包括以下步骤：

如图10所示，在步骤s1001中，响应刷卡交易而触发并发出交易请求。

如图10所示，在步骤s1002中，向服务器查询请求处理方返回的响应信息，其中服务器缓存有响应信息。

在请求阶段(也就是pos机向服务器发出请求以及服务器将请求发送给请求处理方的阶段)，服务器仍然充当透传角色，但是在响应阶段(也就是请求处理方向服务器发出响应信息以及服务器将响应信息发送给pos机的阶段)，服务器不再仅仅充当透传回包的角色，而是将收到的响应信息缓存下来，这里的“请求”是指交易请求和冲正请求，“响应信息”是指交易回包和冲正回包。

在交易阶段，pos从服务器接收的响应信息为交易回包，交易回包是代表请求处理方针对交易请求是否成功交易的回包。

在本实施例中，图11示出步骤s1001之后流程图，包括以下步骤：

如图11所示，在步骤s1101中，如果pos机未收到交易回包而触发交易查询请求，并将交易查询请求发送给服务器。虽然服务器收到请求处理方返回的交易回包之后，会将交易回包发送给pos机，但是由于通信状况的影响，pos机有可能存在收不到交易回包的情况，因此需要pos机主动向服务器发出交易查询请求进行交易查询。

如图11所示，在步骤s1102中，pos机接收服务器响应于交易查询请求而返回的交易回包，以便商户获知本次刷卡交易的结果是否成功。

通过图11所示的步骤，pos机在未收到交易回包的情况下先进行查询，并且查询可以不断重试，如果通过查询以及重试查询能够收到交易回包就能完成交易，不需要再冲正，从而可以降低冲正率。

在步骤s111中，pos机按照一定的查询策略向服务器发出交易查询请求，在本实施例中，查询策略可以是轮询，也就是在一段预设时间内(如1分钟)一直查询，直到收到服务器返回的交易回包。但是，如果当交易查询请求的查询策略失效(也就是在预设时间内通过多次查询也未收到交易回包)后，pos机仍未收到交易回包时，则由pos机触发冲正请求，即进入冲正阶段。

在本实施例中，触发冲正请求后，由于通信状况的影响，冲正阶段还包括两种情况：第一种情况，冲正请求没有发出；第二种情况，冲正请求虽然已经成功发出，但是未收到相应的回包，此时，冲正阶段的回包为冲正回包，冲正回包是代表请求处理方针对冲正请求是否成功冲正的回包。

图12示出本实施例中冲正阶段的步骤流程图，包括以下步骤：

如图12所示，在步骤s1201中，如果pos机没有成功发出冲正请求，则pos机在预设时间段内重复发出冲正请求，直到冲正请求发出成功。之后，服务器收到冲正请求后，将冲正请求再发送给请求处理方；请求处理方针对本次冲正请求产生相应的冲正回包，并发送给服务器；服务器根据冲正回包更新数据库状态，并将冲正回包发送给pos机，pos机根据收到的冲正回包获知冲正的结果是否成功。

如图12所示，在步骤s1202中，如果pos机已经成功发出冲正请求，但是未收到冲正回包，则pos机触发并发出冲正查询请求，也就是进行冲正查询，类似于交易查询的过程。在本实施例中，pos机采用轮询的查询策略发送交易查询请求和冲正查询请求。

如图12所示，在步骤s1203中，pos机接收服务器响应于冲正查询请求而返回的冲正回包，以获知冲正的结果是否成功。

本实施例中不会因偶然一次的通信状况影响pos机接收交易回包或冲正回包，而是在没收到之后先进行交易查询和冲正查询，而且是反复查询，这样可以大幅度降低异常订单导致的顾客投诉，为顾客带来良好的刷卡体验。

对于pos机已经成功发出冲正请求，但是未收到冲正回包的情况，还可以采用如下方案：

pos机接收服务器等待下一次冲正请求，并响应于下一次冲正请求将缓存的冲正回包。由于一般pos机都能够进行自动冲正，因此即便这一次的冲正回包未收到，还会有针对本次刷卡进行冲正的冲正请求从pos机发出，服务器同样可以将冲正回包发给pos机，pos机接收冲正回包以获知冲正的结果是否成功。

需要说明的是，上述步骤冲正请求在第一次没有发出成功并经过多次重试而发出之后，服务器将冲正回包发送给pos机的步骤如果不成功，其后续处理参见对于冲正请求成功发出但是未收到冲正回包的情况下的处理方案，此处不再赘述。

本实施例中pos机收到交易回报或者冲正回包之前，服务器还对交易回包和冲正回包的密文进行解析，并将解析后的交易结果和冲正结果进行缓存，这样，整个交易的结果都不再如现有方案一样依赖pos机的上报，而是以服务器自己后台缓存的结果为准。与现有方案交易的结果以公网中的pos机上报的结果为准相比，本实施例中的方法可以防止交易结果被人恶意篡改，从而提高交易的安全性。

综上所述，本实施例提供的交易通信方法pos机通过向服务器查询服务器中缓存的请求处理方返回的响应信息，使得服务器(即交易后台)对于交易的状态不再是依据pos机上报的结果来更新，而是以服务器缓存的状态为准，能够实时更新，这样商家也能及时得知交易的状态，因订单异常导致的投诉率也大大降低。在交易阶段，pos机重复查询交易回包，可以降低冲正率。但是在反复查询都未果的情况下进入冲正阶段，在一次冲正请求没有发出的情况下也是反复重试，尽量提高冲正的成功率。

图13示出本公开另一实施例中提供的一种pos机的示意图，该pos机与上述实施例中的服务器(也就是交易后台)以及请求处理方共同完成整个交易过程，pos机主要完成与服务器之间的通信功能。如图13所示，pos机1300包括交易请求模块1301和回包查询模块1302。

其中交易请求模块1301配置为响应刷卡交易而触发并发出交易请求，回包查询模块1302配置为向服务器查询请求处理方返回的响应信息，其中服务器缓存有响应信息。

在本实施例中，交易阶段pos机收到的响应信息为交易回包，交易回包是代表请求处理方针对交易请求是否成功交易的回包。冲正阶段pos机收到的响应信息为冲正回包，冲正回包是代表请求处理方针对冲正请求是否成功交易的回包。

如图13所示，pos机还包括交易查询模块1303，配置为如果pos机未收到交易回包而触发交易查询请求，并将交易查询请求发送给服务器。

如图13所示，pos机还包括交易回包接收模块1304，配置为接收服务器响应于交易查询请求而返回的交易回包。通过pos机的查询，pos机接收服务器返回的交易回包，以便商户获知本次刷卡交易的结果是否成功。查询策略可以是轮询，也就是在一段预设时间内(如1分钟)一直查询，直到收到服务器返回的交易回包。

在本实施例中，pos机中通过设置交易查询模块，在未收到交易回包的情况下先进行查询，并且查询可以不断重试，如果通过查询以及重试查询能够收到交易回包就能完成交易，不需要再冲正，从而可以降低冲正率。

如图13所示，pos机还包括冲正请求触发模块1305，配置为当交易查询请求的查询策略失效后，pos机仍未收到交易回包时，触发冲正请求。

当交易查询请求的查询策略失效(也就是在预设时间内通过多次查询也未收到交易回包)后，pos机仍未收到交易回包时，由pos机触发并发出冲正请求，即进入冲正阶段。

冲正阶段还包括两种情况：第一种情况，冲正请求没有发出；第二种情况，冲正请求虽然已经成功发出，但是未收到相应的回包，此时，冲正阶段的回包为冲正回包，冲正回包是代表请求处理方针对冲正请求是否成功冲正的回包。

如果冲正请求没有发出，如图13所示，pos机还包括冲正请求发送模块1306，配置为当pos机没有成功发出冲正请求时，在预设时间段内重复发出冲正请求，直到冲正请求发出成功。也就是通过反复重试，以确保服务器能够接收到冲正请求，再将冲正请求再发送给请求处理方，请求处理方针对本次冲正请求产生相应的冲正回包，并发送给服务器。服务器再根据冲正回包更新数据库状态，并将冲正回包发送给pos机，以便将冲正结果告知给商户，商户获知冲正的结果是否成功。

如果冲正请求虽然已经成功发出，但是未收到相应的回包，如图13所示，pos机还包括冲正查询模块1307，配置为当pos机已经成功发出冲正请求，但是未收到冲正回包时，触发并发出冲正查询请求。

如图13所示，pos机还包括冲正回包接收模块1308，配置为接收服务器响应于冲正查询请求而返回的冲正回包。

在本实施例中，pos机通过设置冲正查询模块，在没收到之后先进行交易查询和冲正查询，而且是反复查询，这样可以大幅度降低异常订单导致的顾客投诉，为顾客带来良好的刷卡体验。

如图13所示，pos机还包括冲正回包等待模块1309，配置为当pos机已经成功发出冲正请求，但是未收到冲正回包时，等待并接收服务器响应于下一次冲正请求而返回的冲正回包。

整个交易的结果是以服务器自己后台缓存的结果为准，pos机收到服务器返回的交易回包或者冲正回包，以便商户获知交易或者冲正的结果是否成功。与现有方案交易的结果以公网中的pos机上报的结果为准相比，本实施例可以防止交易结果被人恶意篡改，从而提高交易的安全性。

本实施例中的pos机能够实现与上述pos机的交易通信方法相同的技术效果，此处不再赘述。

另外，该pos机中各个模块中没有涉及的功能参见上述方法实施例中的相关描述，此处不再赘述。

另一方面，本公开还提供了一种电子设备，包括处理器和存储器，存储器存储用于上述处理器控制以下的操作的指令：

接收来自pos机的交易请求，并将交易请求发送给请求处理方，其中交易请求为响应于pos机的刷卡交易而触发；接收并缓存请求处理方返回的响应信息；根据响应信息更新刷卡交易的状态。

另一方面，本公开还提供了另一种电子设备，包括处理器和存储器，存储器存储用于上述处理器控制以下的操作的指令：

响应刷卡交易而触发并发出交易请求；向服务器查询请求处理方返回的响应信息，其中服务器缓存有响应信息。

下面参考图14，其示出了适于用来实现本申请实施例的电子设备的计算机系统1400的结构示意图。图14示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图14所示，计算机系统1400包括中央处理单元(cpu)1401，其可以根据存储在只读存储器(rom)1402中的程序或者从存储部分1407加载到随机访问存储器(ram)1403中的程序而执行各种适当的动作和处理。在ram1403中，还存储有系统1400操作所需的各种程序和数据。cpu1401、rom1402以及ram1403通过总线1404彼此相连。输入/输出(i/o)接口1405也连接至总线1404。

以下部件连接至i/o接口1405：包括键盘、鼠标等的输入部分1406；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分1407；包括硬盘等的存储部分1408；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分1409。通信部分1409经由诸如因特网的网络执行通信处理。驱动器1410也根据需要连接至i/o接口1405。可拆卸介质1411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1410上，以便于从其上读出的计算机程序根据需要被安装入存储部分1408。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1409从网络上被下载和安装，和/或从可拆卸介质1411被安装。在该计算机程序被中央处理单元(cpu)1401执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括发送单元、获取单元、确定单元和第一处理单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，发送单元还可以被描述为“向所连接的服务端发送图片获取请求的单元”。

另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：接收来自pos机的交易请求，并将交易请求发送给请求处理方，其中交易请求为响应于pos机的刷卡交易而触发；接收并缓存请求处理方返回的响应信息；根据响应信息更新刷卡交易的状态。

另一方面，本公开还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：响应刷卡交易而触发并发出交易请求；向服务器查询请求处理方返回的响应信息，其中服务器缓存有响应信息。

应清楚地理解，本公开描述了如何形成和使用特定示例，但本公开的原理不限于这些示例的任何细节。相反，基于本公开公开的内容的教导，这些原理能够应用于许多其它实施方式。

以上具体地示出和描述了本公开的示例性实施方式。应可理解的是，本公开不限于这里描述的详细结构、设置方式或实现方法；相反，本公开意图涵盖包含在所附权利要求的精神和范围内的各种修改和等效设置。