CN110458545A - 电子交易处理方法、服务器、交易终端和系统 - Google Patents

Abstract

本发明公开了一种电子交易处理方法、服务器、交易终端和系统，电子交易处理方法包括：接收交易终端发送的针对订单交易的自证请求，判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；若匹配，则不执行冲正处理。本实施例的电子交易处理方法，为电子交易可能失败时提供了自证方案，避免自动冲正导致冲正率过高引起资金损失，降低了冲正率，交易效率得到大幅提高。

Description

电子交易处理方法、服务器、交易终端和系统

技术领域

本发明涉及计算机技术领域，具体涉及一种电子交易处理方法、服务器、交易终端和系统。

背景技术

在进行电子交易操作时，比如在利用POS(Point Of Sale)系统即销售点信息系统进行交易时，如果出现由于对POS交易终端的交易请求的应答超时或其它原因造成交易状态不确定的情况，POS交易终端自动向后台发送冲正请求来取消原始交易，并当冲正完成后重新再刷一笔。冲正是为系统认为可能交易失败时采取的补救手段，在进行电子交易操作时，如果出现对于交易请求的应答报文超时或其它原因造成交易状态不确定的情况，需要向交易请求的接收方发送冲正报文来取消原始的交易请求。这里，冲正是对正交易的反向交易。

发明内容

本发明提供了一种电子交易处理方法、服务器、交易终端和系统，提高了交易效率，降低了冲正率。

根据本申请的一个方面，提供了一种电子交易处理方法，包括：

接收交易终端发送的针对订单交易的自证请求，

判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；

若匹配，则不执行冲正处理。

根据本申请的另一个方面，提供了一种电子交易的处理方法，包括：

向服务器发送包含订单信息的交易处理请求，如果预定时间内未收到服务器返回的交易结果，则提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息；

将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器。

根据本申请的又一个方面，提供了一种服务器，包括：

接收单元，用于接收交易终端发送的针对订单交易的自证请求；

冲正判断单元，用于判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；若匹配，则不执行冲正处理。

根据本申请的再一个方面，提供了一种交易终端，包括：

接口单元，用于在向服务器发送包含订单信息的交易处理请求后的预定时间内未收到服务器返回的交易结果时，提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息；

发送单元，用于将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器。

根据本申请的又一个方面，提供了一种冲正处理系统，包括：服务器以及至少一个与所述服务器通信的交易终端；

所述服务器包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于本申请一个方面所述电子交易处理方法的步骤的指令；

所述交易终端包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于本申请另一个方面所述电子交易处理方法的步骤的指令。

根据本申请的又一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本申请一个方面或本申请另一个方面所述电子交易处理方法的步骤。

根据本申请的一个方面，提供了一种电子交易处理方法，包括：

生成订单交易的证明信息；

接收交易终端发送的针对订单交易的自证请求，判断所述自证请求中携带的交易验证信息与所述订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；

若匹配，则不执行冲正处理。

根据本申请的另一个方面，提供了一种电子交易处理方法，包括：

通过输入接口获取交易验证信息，将获取的交易验证信息携带在自证请求中并发送所述自证请求至服务器；

如果预定时间内未收到服务器返回的自证结果，则根据来自服务器的校验规则以及获取的交易验证信息进行自证。

本发明实施例的有益效果是：应用本发明实施例的技术方案，交易终端如果在预定时间内未收到服务器返回的交易结果提供交易验证信息的输入接口，通过输入接口获取交易验证信息，将获取的交易验证信息携带在自证请求中发送给服务器，服务器判断自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，订单交易的证明信息在交易成功时发送至关联用户(比如消费者)账户；若匹配，则不执行冲正处理。或者，交易终端如果在预定时间内没有收到服务器返回的自证结果可以根据获取的交易验证信息以及来自服务器的校验规则进行自证。如此，为电子交易提供了支持自证(消费者自己证明交易成功)的方案，避免了交易终端在未收到交易处理结果时自动发起冲正或者因网络问题自证不成功而发起冲正导致冲正率过高，耗费交易资源、影响消费者体验的问题，降低了电子交易的冲正率。

附图说明

图1是本发明一个实施例的电子交易处理方法的流程图；

图2是本发明另一个实施例的电子交易处理方法的流程图；

图3是本发明又一个实施例的电子交易处理方法的流程图；

图4是本发明一个实施例的服务器的结构框图；

图5是本发明一个实施例的交易终端的结构框图；

图6是本发明一个实施例的冲正处理系统的结构框图；

图7是本发明一个实施例的电子交易处理方法的流程图；

图8是本发明另一个实施例的电子交易处理方法的流程示意图；

图9是本发明一个实施例的服务器的框图；

图10是本发明一个实施例的交易终端的框图；

图11是本发明一个实施例的冲正处理系统的框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在进行电子交易过程中，通常涉及两个主体，即，交易终端和位于后台的服务器。为便于理解，这里对交易过程进行简要说明。交易终端在发起一笔交易时，生成对应的订单信息(比如，能够唯一标识一笔交易的订单号)，并将订单信息携带在交易处理请求中发送至服务器。服务器接收到交易终端发送的包含订单信息的交易处理请求时，处理相应交易，并保存交易处理结果，然后将交易处理结果返回给发送请求的交易终端，供交易终端查看交易处理结果。

但是，交易终端(比如POS终端)发起一笔交易后没有收到交易处理结果时，为避免交易纠纷，交易终端会自动发起冲正来取消该笔交易，而在冲正后仍需要进行一遍交易，这导致交易效率低下、交易时间延长并且消费者体验不佳。如果出现大规模故障，导致反复交易都无法获取到交易处理结果，不仅导致冲正率过高，耗费大量交易资源，而且消费者可能直接取消消费，进而造成商户损失，影响业务收入。

对此，本发明实施例提供了电子交易处理方法、服务器、交易终端和系统，改变交易的自动冲正流程，避免了通信故障时自动冲正造成的资金损失，帮助商户提高业务收入，降低电子交易的冲正率，并提高消费者满意度。

实施例一

图1是本发明一个实施例的电子交易处理方法的流程图，参见图1，本实施例的电子交易处理方法，由服务器执行，包括下列步骤：

步骤S101，接收交易终端发送的针对订单交易的自证请求。

本实施例中的交易例如是支付行为，任何系统内外的支付行为都可以形成一次交易，订单是交易存在的记录。交易常见的情况是：一方(比如商户)提供服务，收取服务费；另一方(比如消费者)支付服务费，获取服务。

步骤S102，判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；若匹配，则不执行冲正处理。这里的自证，顾名思义，是交易终端不确定服务器端是否交易成功时，向服务器证明终端侧交易已经成功的操作。

由图1所示可知，本实施例的电子交易处理方法，服务器接收交易终端的自证请求，并根据自证请求中携带的交易验证信息与订单交易的证明信息匹配结果，若两者匹配，则不执行冲正处理，避免了在交易终端认为交易不成功时自动发起冲正，提高了交易效率和用户的体验。

在本发明的一个实施例中，图1所示方法还包括：若自证请求中携带的交易验证信息与所述订单交易的证明信息不匹配，则执行冲正处理。

也就是说，服务器在收到交易终端发送到自证请求之后，进行判断，并根据判断结果确定是否执行冲正处理。具体是，如果自证请求中携带的交易验证信息与订单交易的证明信息匹配，则不执行冲正处理；如果自证请求中携带的交易验证信息与订单交易的证明信息不匹配，则执行冲正处理。这样，提供了交易的自证流程，弥补了单一、自动冲正流程的不足，提高了交易效率，满足了多样需求。

本发明的一个实施例中，前述执行冲正处理包括：根据接收到的交易终端发送的冲正请求中包含的订单信息确定出相应的订单交易，撤销订单交易，并为撤销的订单交易添加冲正标记。

具体的，当服务器接收到交易终端发送的冲正请求后，确定相应的交易(冲正请求中包含订单信息，相应的交易是与订单信息对应的交易)，接着判断交易是否已经处理，如果服务器端已经交易成功，则回滚交易并为交易添加手动冲正标记；否则不处理，然后将冲正处理结果返回给交易终端。

需要说明的是，当服务器确定出冲正由交易终端发起时，为相应的交易添加冲正标记(比如“手动冲正”)，这里的手动冲正标记区别于自动冲正，添加手动冲正标记方便了服务器统计交易终端发起的手动冲正的数量，为后续改进和决策提供参考。

服务器进行冲正处理是现有技术，这里不再过多说明。

本发明的一个实施例中，前述步骤S102的判断自证请求中携带的交易验证信息与所述订单交易的证明信息是否匹配包括：判断自证请求中携带的交易验证信息与交易成功时发送至关联用户账户的所述订单交易的证明信息是否一致且所述交易验证信息是否有效；若所述交易验证信息与所述订单交易的证明信息一致且所述交易验证信息有效，则确定所述交易验证信息与所述订单交易的证明信息匹配，否则，确定所述交易验证信息与所述订单交易的证明信息不匹配。

需要说明的是，服务器在处理交易时，会保存交易处理相关信息，其中，在交易处理成功时服务器保存订单交易的证明信息，并将订单交易的证明信息发送至关联用户(比如消费者)账户。

后续，服务器收到了交易终端发送的自证请求后，提取自证请求中的交易验证信息，判断交易验证信息的有效性，并判断交易验证信息与交易成功时发送至关联用户账户的订单交易的证明信息是否一致。当判断出自证请求中的交易验证信息有效时(比如，交易验证消息的格式满足预设信息格式)，再将有效的交易验证信息与订单交易的证明信息比对，如果自证请求中携带的交易验证信息与订单交易的证明信息一致，那么即可确定交易验证信息与订单交易的证明信息匹配，也表明当前请求自证的交易是处理成功的交易，服务器即可向交易终端返回自证通过消息。

这里的交易验证信息与订单交易的证明信息一致包括两种情况，一种是交易验证信息与订单交易的证明信息完全相同，比如，订单交易的证明信息为414326，共六位数字，收到的自证请求中的交易验证信息也为六位数字414326，这说明交易验证信息与订单交易的证明信息是一致的。另一种情况是，交易验证信息与订单交易的证明信息一一对应，比如，订单交易的证明信息是一个如下的问题：交易金额与交易时间分别是。服务器收到的自证请求中的交易验证信息为xx元，x月x日x分。而服务器端交易成功的订单交易中只有一笔交易的时间和金额与交易验证信息唯一对应。这也能说明交易验证信息与订单交易的证明信息是一致的。

而如果自证请求中的交易验证信息无效(比如，交易验证消息的格式不满足预设信息格式)，或交易验证信息与任意一个发送至关联用户账户交易成的订单交易的交易验证信息均不一致，那么即可确定当前请求自证的交易不成功，服务器这时向交易终端返回自证不通过消息。

在本发明的一个实施例中，图1所示方法进一步包括：当接收交易终端发送的包含订单信息的查询请求时，根据查询请求找到对应订单交易的交易结果，并返回交易结果给交易终端。

也就是说，服务器还可以接收交易终端发送的查询请求，查询请求是交易终端发送的用来查询交易处理结果的请求。实际应用中，由于网络或系统故障等原因，查询交易处理结果可能需要花费较长时间从而导致服务器未能及时向交易终端返回交易处理结果。这样，当服务器收到交易终端发送的查询请求后，根据订单信息查询与订单信息对应的交易的处理结果，并将查询结果返回给交易终端。

可以理解，查询结果可能是查询到了交易处理结果，也可能是未查询到交易处理结果。对于查询到交易处理结果的情况又可以分为查询到交易处理成功的结果和查询到交易处理失败的结果两种。

实施例二

图2是本发明另一个实施例的电子交易处理方法的流程图，参见图2，本实施例的电子交易的处理方法，由交易终端执行，包括下列步骤：

步骤S201，向服务器发送包含订单信息的交易处理请求，如果预定时间内未收到服务器返回的交易结果，则提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息；

步骤S202，将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器。

由图2所示可知，本实施例的电子交易处理方法，交易终端在未收到服务器返回的交易处理结果时，提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息，将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器以进行自证。这样就避免了在未收到服务器返回的交易处理结果时自动进行冲正导致冲正率过高，影响消费者体验的问题，提高了交易的顺畅性。

自证处理是本实施例的重点，自证是基于大量现场交易中出现的下列情况：即，交易终端成功发起交易，消费者已经扣款但交易终端未收到服务器返回的交易处理结果，不确定后台交易是否成功。由于消费者已经扣款，如果这时进行冲正取消该笔交易，并在冲正后重新进行一遍交易流程，会耗费大量的交易资源，也影响消费者体验。

针对这一情况，本实施例提出交易终端发起自证。具体的，交易终端获取交易验证信息，交易验证信息是为了核对交易。前述步骤S201中，通过输入接口获取交易验证信息包括：通过输入接口获取关联用户账户的扣款通知中的交易验证信息。这是由于如果消费者已经扣款，则消费者终端中会收到服务器下发到消费者终端的扣款通知。这时，交易终端从消费者的移动终端中扣款通知里获取交易验证信息(比如，条形码或者一串数字)。

在本发明的一个实施例中，交易终端在获取到交易验证信息后，将包含交易验证信息和订单信息的自证请求发送至服务器。交易终端接收服务器进行判断后返回的消息，当接收到服务器返回的是自证通过消息时，输出交易成功的提示信息；当接收到服务器返回的是自证不通过消息时，输出交易失败进行冲正的提示信息。

也就是说，交易终端根据自证能否通过输出不同的信息，以提示用户进行后续操作。比如，当交易终端接收到了服务器发送的自证不通过消息，交易终端输出交易失败进行冲正的提示信息，供用户及时获知自证结果，并在自证不通过时进行冲正，并且对于由用户在交易终端发起的冲正的订单，在冲正处理完成后，用户可以根据冲正处理结果，要求消费者重新支付一笔，交易流程结束。

实际应用中，由于网络原因，交易终端未能及时收到交易结果，这时图2所示的方法进一步包括：如果预定时间内未收到服务器返回的交易结果，发送包含订单信息的查询请求给服务器，并在指定时间内仍查询不到订单交易结果时，执行提供交易验证信息的输入接口的步骤。

需要说明的是，本实施例中，如果交易终端在发送交易处理请求后未收到服务器返回的交易处理结果，则可以先发送查询请求到服务器来查询交易处理结果，如果查询到了交易结果就不再进行自证处理。如果在预设时间(交易终端可以设定查询时间，比如20秒钟)仍然查询不到交易处理，交易终端再提供交易验证信息的输入接口，以获取交易验证信息进行自证。这样，当交易能够正常进行的情况下避免触发自证或冲正，节省系统开销和资源，缩短交易时间，提高交易成功率。

另外，在一个实施例中，如果预定时间内未收到服务器返回的订单交易结果，提供冲正选项，当冲正选项被触发时，发送包含订单信息的冲正请求至服务器。

也就是说，交易终端在未收到服务器返回的订单交易结果的情况下，可以提供冲正选项，以发起冲正流程，从而为用户提供多种选择，既支持进行自证又支持冲正，满足交易现场的复杂状况以及用户的多种需求。

实际应用中，交易终端还可以在查询到交易处理结果，交易终端根据收到的交易处理结果判断交易是否成功，如果成功，交易终端展示交易成功页面，如果失败，交易终端展示交易失败页面，方便用户及时了解交易结果。

实施例三

图3是本发明又一个实施例的电子交易处理方法的流程图，图3，是以一笔交易的处理过程为例进行的示意性说明，本实施例的电子交易处理方法，由交易终端(比如POS终端)执行，包括下列步骤：

步骤S301，发送交易处理请求；

交易终端发起交易，向服务器发送包含订单信息的交易处理请求。

步骤S302，是否收到交易处理结果；是则执行步骤S304，否则执行步骤S303；

由于网络等原因，交易终端可能没有收到指示交易状态的交易处理结果。因此，在本步骤中，交易终端判断是否收到交易处理结果，如果收到交易处理结果，执行步骤S304，如果没有收到交易处理结果，执行步骤S303。

步骤S303，发送查询请求；

在本步骤中，交易终端向服务器发送包含订单信息的查询请求，以查询交易处理处理结果。这里的查询时间可以是10秒钟或者60秒钟。

步骤S304，交易是否成功；是则执行步骤S305，否则执行步骤S306；

本步骤是在收到了交易处理结果的前提下，根据交易处理结果判断交易是否成功。实际应用中，由于操作失误，账户余额不足，网络等原因都可能导致交易失败，所以在本步骤中根据交易处理结果判断交易是否成功。

步骤S305，显示收银成功页面；

也就是说，如果在步骤S304中判断为交易成功(表明收到了消费者支付的费用)，那么，在本步骤中，交易终端即可显示收银成功页面。这时，交易终端还可以支持打印成功小票，以备留存。

步骤S306，显示收银失败页面；

如果在步骤S304中判断为交易不成功(表明没有收到消费者支付的费用)，那么，在本步骤中交易终端显示收银失败页面。

步骤S307，是否查询到结果；是则执行步骤S304，否则执行步骤S308；

实践中，由于故障或者网络等可能导致交易终端查询不到交易处理结果。所以，当步骤S303中发送了查询请求后，在本步骤中判断是否查询到结果，如果查询到结果，则执行步骤S304，即，判断交易是否成功，并根据交易是否成功显示相应页面。如果查询不到结果，则执行步骤S308。需要说明的是，考虑到节约交易时间，提升用户体验。交易终端可以设置查询时间，比如设置30秒，即，在30秒内，等待服务器的查询结果。

步骤S308，显示结果未知并需要进行自证或冲正页面；

当查询不到交易处理结果时，交易终端显示结果未知页面。

实际应用中，交易终端在显示结果未知页面之后，或者在显示结果未知的页面上显示自证或冲正选项供用户触发，如果自证选项被触发，表明进行自证并执行步骤S309；如果冲正选项被触发，表明进行冲正并执行步骤S313。

需要说明的是，用户可以根据消费者是否已经扣款来确定触发自证或冲正流程。比如，如果消费者已经扣款成功，则用户可以触发自证选项，这样，能够减少冲正次数，节省消费者的时间，提高消费者的满意度。如果消费者未扣款成功，则用户可以触发冲正选项，来取消这一笔交易。

步骤S309，发送自证请求；

当自证选项被触发后，交易终端提供交易验证信息的输入接口，并通过输入接口获取交易验证信息，将交易验证信息携带在自证请求中，并发送自证请求到服务器，自证请求中包含订单信息和交易验证信息。服务器收到自证请求后，根据交易验证信息核对与订单交易的证明是否匹配，匹配，则返回自证通过消息，不匹配，则返回自证不通过消息。

步骤S310，是否自证成功；是则执行步骤S311，否则执行步骤S312；

在本步骤中，交易终端判断是否自证成功，比如，如果收到服务器返回的自证通过消息，确定为自证成功，如果收到服务器返回的自证不通过消息，确定为自证不成功。

自证成功的，执行步骤S311，自证不成功的，执行步骤S312。

步骤S311，显示自证成功页面；

在本步骤中，显示包含自证成功信息的页面供用户及时查看和了解交易已经处理成功。实际应用中，在显示自证成功页面时，交易终端还支持打印成功小票，以备留存。

步骤S312，显示自证失败页面；

在本步骤中，交易终端显示包含自证失败信息的页面，供用户及时查看和了解交易处理失败。

由于自证失败的原因可能是网络状况不佳，所以在执行步骤S312之后，交易终端可以再试一次自证，即返回执行步骤S309，重新发起自证请求。或者，交易终端提示进行冲正，并在冲正完成后重新交易。

步骤S313，提示冲正重新交易；

在本步骤中，交易终端显示的冲正选项被触发之后，为了防止用户误操作，本实施例可以进行冲正弹窗提示，弹窗提示内容包括：如果冲正将撤销该笔交易并需要重新交易。

具体的，冲正流程是向服务器发送包含订单信息的冲正请求，服务器接收到冲正请求后进行判断，如果该笔交易已经处理，则撤销处理结果，如果该笔交易未处理，则不再进行处理。将冲正结果返回给交易终端。

步骤S314，显示冲正成功页面；

交易终端根据冲正结果，显示冲正成功页面供用户及时查看当前的冲正已经成功，可以重新进行交易。

实际应用中，本实施例的交易终端在显示完冲正成功页面之后，提示打印冲正小票，以备留存。

至此，本实施例的电子交易流程执行完毕。图3所示方法的流程中部分步骤(比如，自证流程对应的步骤)可以省略，当然，也可以根据实际需求，增加部分步骤，对此不做限制。

图3所示电子交易处理方法，改变了电子交易的冲正自动触发方式，即，将自动冲正流程变更为商户手动冲正，将交易撤销的主体由系统变更为商户，降低了冲正率，应用本实施例的电子交易处理方法，冲正率可以显著降低。另外，减少了系统故障时自动冲正造成的资金损失。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实际实施所必须的。

实施例四

图4是本发明一个实施例的服务器的结构框图，参见图4，服务器400包括：

接收单元401，用于接收交易终端发送的针对订单交易的自证请求；

冲正判断单元402，用于用于判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；若匹配，则不执行冲正处理。

在本发明的一个实施例中，冲正判断单元402，还用于在自证请求中携带的交易验证信息与所述订单交易的证明信息不匹配时，执行冲正处理。

在本发明的一个实施例中，冲正判断单元402，具体用于判断自证请求中携带的交易验证信息与交易成功时发送至关联用户账户的所述订单交易的证明信息是否一致且所述交易验证信息是否有效；若所述交易验证信息与所述订单交易的证明信息一致且所述交易验证信息有效，则确定所述交易验证信息与所述订单交易的证明信息匹配，否则，确定所述交易验证信息与所述订单交易的证明信息不匹配。

在本发明的一个实施例中，服务器400还包括：自证标记单元，用于当确定所述交易验证信息与所述订单交易的证明信息匹配时，为所述订单交易添加自证通过标记；以及，查询处理单元，用于当接收交易终端发送的包含订单信息的查询请求时，根据所述查询请求找到对应订单交易的交易结果，并返回交易结果给所述交易终端。

在本发明的一个实施例中，冲正判断单元402具体用于，执行冲正处理，包括，根据接收到的交易终端发送的冲正请求中包含的订单信息确定出相应的订单交易，撤销所述订单交易，并为撤销的所述订单交易添加冲正标记。

实施例五

图5是本发明一个实施例的交易终端的结构框图，参见图5，交易终端500包括：

接口单元501，用于在向服务器发送包含订单信息的交易处理请求后的预定时间内未收到服务器返回的交易结果时，提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息；

发送单元502，用于将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器。

在本发明的一个实施例中，接口单元501具体用于，通过所述输入接口获取关联用户账户的扣款通知中的交易验证信息。

在本发明的一个实施例中，图5所示交易终端500进一步包括：提示单元，用于当接收到服务器返回的自证通过消息时，输出交易成功的提示信息；当接收到服务器返回的自证不通过消息时，输出交易失败进行冲正的提示信息。

在本发明的一个实施例中，图5所示交易终端500进一步包括：查询单元，用于如果预定时间内未收到服务器返回的交易结果，发送包含订单信息的查询请求给服务器，并在指定时间内仍查询不到订单交易结果时，通知接口单元执行所述提供交易验证信息的输入接口的步骤。

在本发明的一个实施例中，图5所示交易终端500进一步包括：冲正请求单元，用于如果预定时间内未收到服务器返回的订单交易结果，提供冲正选项，当所述冲正选项被触发时，发送包含订单信息的冲正请求至服务器。

实施例六

图6是本发明一个实施例的冲正处理系统的结构框图，参见图6，冲正处理系统600包括：服务器400以及至少一个与所述服务器400通信的交易终端500；

服务器400包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于实施例一所述电子交易处理方法的步骤的指令，

交易终端500包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于实施例二所述电子交易处理方法的步骤的指令。

此外，上述的存储器中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。

基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本发明的一个实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述实施例一、实施例二或实施例三中所述电子交易处理方法的步骤。

具体应用时，交易终端与服务器之间的网络等故障除了影响交易终端不能及时收到交易处理结果外，还可能导致交易终端不能及时收到自证结果，也就是说，即使提供了取消自动冲正技术方案而由交易终端发起自证的方式来降低冲正率仍然会存在由于收不到自证结果而触发冲正从而使冲正率保持居高不下。统计发现，交易终端自证时由于交易终端与平台的服务器之间通信问题导致了近45％的自证不成功。

对此，本发明实施例提供了交易终端可以进行自证的方案，这样就从根本上解决了由于交易终端与服务端通信不畅(比如，交易终端收不到服务器的自证成功的通知)导致自证不成功进而用户选择冲正造成冲正率过高的问题。也就是说，如果自证请求被发送到了服务器，则由服务器根据自证请求来判断自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，即，服务器判断自证是否成立。如果自证请求并未被发送到服务器或者自证请求被发送到了服务器但是服务器确定的自证结果未被成功发送至交易终端，则由交易终端来进行自证。

实施例七

图7是本发明一个实施例的电子交易处理方法的流程图，参见图7，本发明实施例的这种电子交易处理方法，应用于服务器，包括下列步骤：

步骤S701，生成订单交易的证明信息；

步骤S702，接收交易终端发送的针对订单交易的自证请求，判断所述自证请求中携带的交易验证信息与所述订单交易的证明信息是否匹配，若匹配，则不执行冲正处理。所述订单交易的证明信息在交易成功时发送至关联用户账户。

具体的，步骤S701中的生成订单交易的证明信息包括：当接收到交易终端发送的银行卡支付订单交易的交易处理请求时，根据确定出的预定日期的日校验数以及预定日期的编码对应关系生成银行卡支付订单交易的证明信息；银行卡支付订单交易的证明信息在交易成功时被发送至关联用户账户。

考虑到银行卡支付订单由于单笔金额较大，错误冲正后导致的资金损失严重。并且利用通信双方的网络故障来进行银行卡套现问题时有发生，本实施例中以订单交易是银行卡支付订单交易为例来说明电子交易处理方法的实现步骤。本实施例中的交易终端可以是POS机。

在一个实施例中，服务器在接收到POS机发送的一笔银行卡支付订单交易的交易处理请求后，根据确定出的预定日期的日校验数以及预定日期的编码对应关系生成银行卡支付订单交易的证明信息。

这里的预定日期是指收到银行卡支付订单交易的交易处理请求的当天。本实施例中，日校验数以及编码对应关系是随日期而改变的，服务器根据每天的日校验数以及每天的编码对应关系来具体生成订单交易的证明信息。

本实施例中所述的预定日期的日校验数是16以上128以下的一自然数，

为了确保能够及时下发日校验数到POS机，服务器提前将16以上128以下的一自然数确定为当天的日校验数，并以当天的日期为主键对应存储日校验数。例如，服务器在2月4日的23点，确定出2月5日要使用的日校验数为120，并将日校验数120与日期信息2月5日对应存储起来。

所述的预定日期的编码对应关系是对指定字符集中的字符进行编码后得到预定日期的指示各字符对应的编码的编码对应关系。其中，指定字符集为包括0-9共十个数字以及A-Z共26个英文字母的字符集。

具体的，服务器对指定字符集中的字符进行编码后得到预定日期的指示各字符对应的编码的编码对应关系包括：对指定字符集中的字符进行二进制哈夫曼编码，得到当天的指示各字符对应的二进制哈夫曼编码的编码对应关系，其中，编码后字符的编码长度的平均值在由预定日期的日校验数确定的阈值范围内。一个实施例中，由预定日期的日校验数确定的阈值范围是指：[(日校验数/6)+4]到[(日校验数/6)-4]限定的范围，符号“/”表示数学运算中的除。也就是说，字符的编码对应关系以及日校验数不仅每天改变而且两者的变化具有相关性。

在本发明的一个实施例中，银行卡支付订单交易的证明信息可以是字母和数字组合成的六位验证码，例如68MK2W。银行卡支付订单交易的证明信息在交易成功时被发送至关联用户账户。具体来说，服务器在生成六位验证码之后，将六位验证码发送至银行卡对应的银行服务器，由银行服务器在从用户的银行账户扣款并发送扣款通知时，将六位验证码携带在扣款通知中发送至关联用户账户。可以理解，银行服务器发送扣款通知的方式可以是短信方式或者是交易记录方式，本发明实施例对此不做限制。

需要说明的是，与基于互联网应用的移动支付(比如，支付宝支付、微信支付)相比，银行卡支付有其特殊性，即，银行卡支付交易需要遵循ISO国际标准包格式的8583报文协议。8583包最多由128个字段域组成，每个域都有统一的规定，并有定长与变长之分。按照银联规定，在每日进行首笔交易之前，POS机需要向服务器发起签到请求，以使服务器返回三个工作密钥，分别用于加密POS传输给服务器的银行卡的三个信息，加强安全性。

在此基础上，本发明实施例的服务器确定出当天的日校验数以及当天的编码对应关系之后，在每日POS机签到时，即服务器在接收到交易终端在当天发送的签到报文时，将确定出的当天的日校验数以及当天的编码对应关系发送至交易终端。服务器在将校验规则即日校验数和编码对应关系发送给POS机之后，POS机便可以根据这两项信息对获取的交易验证信息进行自证，客户端自证的过程参见下文中的说明。

由上可知，本发明实施例中服务器下发校验规则至客户端，实现了在网络不畅的情况下由客户端完成自证(自证的含义是消费者通过客户端向服务器证明一笔交易已经成功扣款)，减少客户端发起冲正，有利于降低冲正率。另外，服务器通过每日下发当天的校验规则也降低了被攻击的可能性，保证了客户端自证的可信度。

为了进一步确保不会因为客户端在自证过程中被攻击或者作弊而造成平台的资金损失，本发明实施例中还提供了服务器进行二次验证。

具体的，服务器接收交易终端发送的一笔订单交易的交易处理请求，交易处理请求中包含交易发生时间早于所述订单交易且自证成功的银行卡支付订单交易的交易验证信息和订单信息；验证自证成功的银行卡支付订单交易的自证有效性。

服务器在接收到交易终端发送的一笔订单交易的交易处理请求后，如果确定该交易处理请求中包含交易发生时间早于订单交易且自证成功的银行卡支付订单交易的交易验证信息和订单信息，则验证自证成功的银行卡支付订单交易的自证有效性。

需要说明的是，POS机大都存储空间有限，所以POS机发送一笔订单交易的交易处理请求时，如果发生时间在该笔订单交易之前的一笔银行卡支付订单交易被自证成功，那么POS机将会在该笔订单交易对应的交易处理请求中携带上自证成功的银行卡支付订单交易对应的交易验证信息和订单信息并发送至服务器。可以理解，自证成功的这一笔银行卡支付订单交易的发生时间早于与交易处理请求对应的那一笔订单交易，两笔交易可以只有时间上的先后关系。

在本发明的一个实施例中，验证自证成功的银行卡支付订单交易的自证有效性包括：按照预定日期的编码对应关系将交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；判断计算结果是否等于预定日期的日校验数，如果等于则确定自证有效，如果不等于则确定自证无效。

由于服务器是根据预定日期的编码对应关系和预定日期的日校验数(具体是二进制哈夫曼编码长度和等于日校验数生成验证码)生成的订单交易证明信息(验证码)并通过银行服务器发送至消费者账户，所以，如果消费者提供的或者POS获取到的交易验证信息是未被攻击过的，那么服务器按照生成订单交易的证明信息时的逆运算还原出的交易验证信息中各字符的二进制哈夫曼编码，编码长度之和一定等于日校验数。基于上述原理，服务器在收到自证成功的银行卡支付订单交易的交易验证信息之后，按照预定日期的编码对应关系将交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；判断计算结果是否等于预定日期的日校验数，如果等于则确定自证有效，如果不等于则确定自证无效。

以上可知，自证成功的银行卡支付订单交易的验证码最终会由客户端发送到服务器再次验证并进行标记，这样就完全避免了被可疑交易等攻击造成平台的资金损失。

实施例八

图8是本发明另一个实施例的电子交易处理方法的流程示意图，参见图8，本实施例的电子交易处理方法应用于交易终端，包括下列步骤：

步骤S801，通过输入接口获取交易验证信息，将获取的交易验证信息携带在自证请求中并发送所述自证请求至服务器；

步骤S802，如果预定时间内未收到服务器返回的自证结果，则根据来自服务器的校验规则以及获取的交易验证信息进行自证。

需要说明的是，本实施例中，交易终端(比如POS机)提供输入接口并通过输入接口获取交易验证信息，将获取的交易验证信息携带在自证请求中并发送自证请求至服务器。考虑到实践中POS机与服务器之间可能网络不畅，POS机很有可能长时间收不到服务器的信息，为了避免POS机在网络不畅的情况下主动发起冲正导致冲正率较高，本实施例中，对服务器返回自证结果设定一个定时器，当定时器记录的时间达到了预设时间阈值(比如60秒)时，POS机再根据来自服务器的校验规则以及获取的交易验证信息进行自证。如此，一方面通过设定时间阈值，只有在预定时间内没有收到自证结果时，才触发交易终端进行自证，避免了交易终端进行大量自证增加POS机的开销。另一方面，在没有收到服务器的自证结果时，为客户端提供了自证方案，避免了在网络不畅的情况下需要消费者长时间等待等影响消费体验的问题，也方便了更好应对交易现场的复杂情况。

在本发明的一个实施例中，来自服务器的校验规则包括：预定日期的编码对应关系以及预定日期的日校验数。预定日期的编码对应关系是预定日期的指示各字符对应的二进制哈夫曼编码的编码对应关系，其中，编码后字符的编码长度的平均值在由预定日期的日校验数确定的阈值范围内。由预定日期的日校验数确定的阈值范围是指：[(日校验数/6)+4]到[(日校验数/6)-4]限定的范围，符号“/”表示数学运算中的除。哈夫曼编码(HuffmanCoding)，又称霍夫曼编码，是一种编码方式，哈夫曼编码是可变字长编码的一种。本实施例中预定日期的日校验数为16以上128以下的一自然数。

前述步骤S801中通过输入接口获取交易验证信息包括：通过输入接口获取由服务器根据预定日期的编码对应关系以及预定日期的日校验数生成的银行卡支付订单交易的交易验证信息。这里获取的交易验证信息例如是字母和数字组合成的六位验证码68MK2W。

在本发明的一个实施例中，根据来自服务器的校验规则以及获取的交易验证信息进行自证包括：

按照预定日期的编码对应关系将获取的所述交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算所述交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；判断所述计算结果是否等于预定日期的日校验数，如果等于则确定自证成功，如果不等于则确定自证失败。

需要说明的是，按照规定，支持银行卡支付的POS机遵循8583协议，POS机在每天开机后首先要发送签到报文到服务器，这样服务器根据收到的签到报文将当天的日校验码以及当天的编码对应关系下发至POS机，后续POS机在进行自证时根据当天的日校验码以及当天的编码对应关系来进行，如此降低了被攻击的概率。具体的自证过程如下：POS机按照当天的编码对应关系将通过输入接口获取的交易验证信息(该交易验证信息来自关联用户账户)中各字符还原成对应的二进制哈夫曼编码，然后计算各字符对应的二进制哈夫曼编码的长度之和得到计算结果(比如，和为120)；判断计算结果(120)是否等于当天的日校验数(120)，如果等于则确定自证成功，如果不等于则确定自证失败。可知，本实施例中计算结果和日校验数均为120，两者相等。

POS机在确定自证成功或失败的情况下均输出提示信息，以方便用户及时了解自证的结果。

在本发明的一个实施例中，该电子交易处理方法进一步包括：在确定自证成功后，将银行卡支付订单交易对应的交易验证信息以及订单信息携带在交易发生时间晚于银行卡支付订单交易的一笔订单交易的交易处理请求中上传至服务器，以使服务器验证自证成功的银行卡支付订单交易的自证有效性。

考虑到POS机大多都存储空间有限，优选地，本实施例中POS机仅保存一笔自证成功的银行卡支付订单交易的数据以节省存储空间。这样每次当POS机在该银行卡支付订单交易之后发生下一笔订单交易，需要发送该下一笔订单交易对应的交易处理请求到服务器时，POS机将发生时间早于该下一笔订单交易且自证成功的银行卡支付订单交易的交易验证信息以及订单信息携带在该下一笔订单交易对应的交易处理请求中发送交易处理请求至服务器，以使服务器根据银行卡支付订单交易的交易验证信息来验证自证成功的银行卡支付订单交易的自证有效性。

由上可知，本实施例的交易终端接收来自服务器的校验规则，当与服务器之间的网络通信不畅时，根据获取的交易验证信息，以及来自服务器的校验规则进行校验，从而避免了长时间等待影响消费体验，也解决了在自证不成功时转而选择冲正导致冲正率过高的问题。

实施例九

图9是本发明一个实施例的服务器的框图，参见图9，本实施例的服务器900包括信息生成单元901，接收单元902以及冲正判断单元903；

信息生成单元901，用于生成订单交易的证明信息；

接收单元902，用于接收交易终端发送的针对订单交易的自证请求；

冲正判断单元903，用于判断所述自证请求中携带的交易验证信息与所述订单交易的证明信息是否匹配，若匹配，则不执行冲正处理。所述订单交易的证明信息在交易成功时发送至关联用户账户。

在本发明的一个实施例中，信息生成单元901具体用于当接收到交易终端发送的银行卡支付订单交易的交易处理请求时，根据确定出的预定日期的日校验数以及预定日期的编码对应关系生成银行卡支付订单交易的证明信息；所述银行卡支付订单交易的证明信息在交易成功时被发送至关联用户账户。

在本发明的一个实施例中，所述确定出的预定日期的日校验数是16以上128以下的一自然数，所述确定出的预定日期的编码对应关系是对指定字符集中的字符进行编码后得到预定日期的指示各字符对应的编码的编码对应关系。对指定字符集中的字符进行编码后得到预定日期的指示各字符对应的编码的编码对应关系包括：对指定字符集中的字符进行二进制哈夫曼编码，得到指示各字符对应的二进制哈夫曼编码的编码对应关系，其中，编码后字符的编码长度的平均值在由预定日期的日校验数确定的阈值范围内；

在本发明的一个实施例中，该服务器进一步包括下发单元，用于在接收到交易终端在预定日期发送的签到报文时，将确定出的预定日期的日校验数以及预定日期的编码对应关系发送至所述交易终端。

在本发明的一个实施例中，该服务器进一步包括二次验证单元，用于接收交易终端发送的一笔订单交易的交易处理请求，所述交易处理请求中包含交易发生时间早于所述订单交易且自证成功的银行卡支付订单交易的交易验证信息和订单信息；验证自证成功的银行卡支付订单交易的自证有效性。验证自证成功的银行卡支付订单交易的自证有效性具体包括：按照所述预定日期的编码对应关系将所述交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算所述交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；判断所述计算结果是否等于预定日期的日校验数，如果等于则确定自证有效，如果不等于则确定自证无效。

需要说明的是，本实施例中服务器的功能单元的工作过程与前述实施例七的方法实施例中的举例解释说明一致，这里不再赘述。

实施例十

图10是本发明一个实施例的交易终端的框图，参见图10，本实施例的交易终端1000包括：接口单元1001，发送单元1002以及自证单元1003；

接口单元1001，用于通过输入接口获取交易验证信息，

发送单元1002，将获取的交易验证信息携带在自证请求中并发送所述自证请求至服务器；

自证单元1003，如果预定时间内未收到服务器返回的自证结果，则根据来自服务器的校验规则以及获取的交易验证信息进行自证。

在本发明的一个实施例中，来自服务器的校验规则包括：预定日期的编码对应关系以及预定日期的日校验数；所述预定日期的编码对应关系是预定日期的指示各字符对应的二进制哈夫曼编码的编码对应关系，其中，编码后字符的编码长度的平均值在由预定日期的日校验数确定的阈值范围内；所述预定日期的日校验数为16以上128以下的一自然数。

接口单元1001具体用于通过所述输入接口获取由服务器根据预定日期的编码对应关系以及预定日期的日校验数生成的银行卡支付订单交易的交易验证信息。

在本发明的一个实施例中，自证单元1003具体用于按照所述预定日期的编码对应关系将获取的所述交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算所述交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；判断所述计算结果是否等于预定日期的日校验数，如果等于则确定自证成功，如果不等于则确定自证失败。

在本发明的一个实施例中，发送单元1002还用于在确定自证成功后，将银行卡支付订单交易对应的交易验证信息以及订单信息携带在交易发生时间晚于所述银行卡支付订单交易的一笔订单交易的交易处理请求中上传至服务器，以使所述服务器验证自证成功的银行卡支付订单交易的自证有效性。

需要说明的是，本实施例中交易终端的功能单元的工作过程与前述实施例八的方法实施例中的举例解释说明一致，这里不再赘述。

图11是本发明一个实施例的冲正处理系统的框图，参见图11，冲正处理系统1100包括：服务器900以及至少一个与所述服务器900通信的交易终端1000；

服务器900包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于实施例七所述电子交易处理方法的步骤的指令，

交易终端1000包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于实施例八所述电子交易处理方法的步骤的指令。

本发明的一个实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述实施例七或实施例八中所述电子交易处理方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图的一个流程或多个流程和/或方框图的一个方框或多个方框中指定的功能的装置。

需要说明的是术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本发明的说明书中，说明了大量具体细节。然而能够理解的是，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。类似地，应当理解，为了精简本发明公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。

以上所述仅为本发明的具体实施方式。在本发明的上述教导下，本领域技术人员可以在上述实施例的基础上进行其他的改进或变形。本领域技术人员应该明白，上述的具体描述只是更好的解释本发明的目的，本发明的保护范围以权利要求的保护范围为准。

Claims (26)

1.一种电子交易处理方法，其特征在于，包括：

接收交易终端发送的针对订单交易的自证请求，

判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；

若匹配，则不执行冲正处理。

2.如权利要求1所述的方法，其特征在于，该方法进一步包括：

若自证请求中携带的交易验证信息与所述订单交易的证明信息不匹配，则执行冲正处理。

3.如权利要求1所述的方法，其特征在于，所述判断自证请求中携带的交易验证信息与所述订单交易的证明信息是否匹配包括：

判断自证请求中携带的交易验证信息与交易成功时发送至关联用户账户的所述订单交易的证明信息是否一致且所述交易验证信息是否有效；

若所述交易验证信息与所述订单交易的证明信息一致且所述交易验证信息有效，则确定所述交易验证信息与所述订单交易的证明信息匹配，

否则，确定所述交易验证信息与所述订单交易的证明信息不匹配。

4.如权利要求3所述的方法，其特征在于，该方法进一步包括：

当确定所述交易验证信息与所述订单交易的证明信息匹配时，为所述订单交易添加自证通过标记；

以及，当接收交易终端发送的包含订单信息的查询请求时，根据所述查询请求找到对应订单交易的交易结果，并返回交易结果给所述交易终端。

5.如权利要求2所述的方法，其特征在于，所述执行冲正处理包括：

根据接收到的交易终端发送的冲正请求中包含的订单信息确定出相应的订单交易，撤销所述订单交易，并为撤销的所述订单交易添加冲正标记。

6.一种电子交易处理方法，其特征在于，包括：

向服务器发送包含订单信息的交易处理请求，如果预定时间内未收到服务器返回的交易结果，则提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息；

将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器。

7.如权利要求6所述的方法，其特征在于，通过所述输入接口获取交易验证信息包括：

通过所述输入接口获取关联用户账户的扣款通知中的交易验证信息。

8.如权利要求6或7所述的方法，其特征在于，该方法进一步包括：

当接收到服务器返回的自证通过消息时，输出交易成功的提示信息；

当接收到服务器返回的自证不通过消息时，输出交易失败进行冲正的提示信息。

9.如权利要求6所述的方法，其特征在于，该方法进一步包括：

如果预定时间内未收到服务器返回的交易结果，发送包含订单信息的查询请求给服务器，并在指定时间内仍查询不到订单交易结果时，执行所述提供交易验证信息的输入接口的步骤。

10.如权利要求6所述的方法，其特征在于，该方法进一步包括：

如果预定时间内未收到服务器返回的订单交易结果，提供冲正选项，

当所述冲正选项被触发时，发送包含订单信息的冲正请求至服务器。

11.一种服务器，其特征在于，包括：

接收单元，用于接收交易终端发送的针对订单交易的自证请求；

冲正判断单元，用于判断所述自证请求中携带的交易验证信息与订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；若匹配，则不执行冲正处理。

12.如权利要求11所述的服务器，其特征在于，所述冲正判断单元，还用于在自证请求中携带的交易验证信息与所述订单交易的证明信息不匹配时，执行冲正处理。

13.一种交易终端，其特征在于，包括：

接口单元，用于在向服务器发送包含订单信息的交易处理请求后的预定时间内未收到服务器返回的交易结果时，提供交易验证信息的输入接口，并通过所述输入接口获取交易验证信息；

发送单元，用于将获取的交易验证信息携带在自证请求中，并发送所述自证请求至服务器。

14.如权利要求13所述的交易终端，其特征在于，所述接口单元具体用于，通过所述输入接口获取关联用户账户的扣款通知中的交易验证信息。

15.一种冲正处理系统，其特征在于，包括：服务器以及至少一个与所述服务器通信的交易终端；

所述服务器包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于权利要求1至5任一项或，权利要求17至22任一项所述电子交易处理方法的步骤的指令，

所述交易终端包括：处理器，以及用于存储所述处理器可执行指令的存储器，所述处理器，用于执行存储器中所存储的对应于权利要求6至10任一项或权利要求23至26任一项所述电子交易处理方法的步骤的指令。

16.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1至5任一项、权利要求6至10任一项，或权利要求17至22任一项、权利要求23至26任一项所述电子交易处理方法的步骤。

17.一种电子交易处理方法，其特征在于，包括：

生成订单交易的证明信息；

接收交易终端发送的针对订单交易的自证请求，判断所述自证请求中携带的交易验证信息与所述订单交易的证明信息是否匹配，所述订单交易的证明信息在交易成功时发送至关联用户账户；

若匹配，则不执行冲正处理。

18.如权利要求17所述的方法，其特征在于，生成订单交易的证明信息包括：

当接收到交易终端发送的银行卡支付订单交易的交易处理请求时，根据确定出的预定日期的日校验数以及预定日期的编码对应关系生成银行卡支付订单交易的证明信息；

所述银行卡支付订单交易的证明信息在交易成功时被发送至关联用户账户。

19.如权利要求18所述的方法，其特征在于，

所述确定出的预定日期的日校验数是16以上128以下的一自然数，

所述确定出的预定日期的编码对应关系是对指定字符集中的字符进行编码后得到预定日期的指示各字符对应的编码的编码对应关系。

20.如权利要求19所述的方法，其特征在于，所述对指定字符集中的字符进行编码后得到预定日期的指示各字符对应的编码的编码对应关系包括：

对指定字符集中的字符进行二进制哈夫曼编码，得到指示各字符对应的二进制哈夫曼编码的编码对应关系，其中，编码后字符的编码长度的平均值在由预定日期的日校验数确定的阈值范围内；

该方法进一步包括：

在接收到交易终端在预定日期发送的签到报文时，将确定出的预定日期的日校验数以及预定日期的编码对应关系发送至所述交易终端。

21.如权利要求20所述的方法，其特征在于，该方法进一步包括：

接收交易终端发送的一笔订单交易的交易处理请求，所述交易处理请求中包含交易发生时间早于所述订单交易且自证成功的银行卡支付订单交易的交易验证信息和订单信息；

验证自证成功的银行卡支付订单交易的自证有效性。

22.如权利要求21所述的方法，其特征在于，所述验证自证成功的银行卡支付订单交易的自证有效性包括：

按照所述预定日期的编码对应关系将所述交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算所述交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；

判断所述计算结果是否等于预定日期的日校验数，

如果等于则确定自证有效，如果不等于则确定自证无效。

23.一种电子交易处理方法，其特征在于，包括：

通过输入接口获取交易验证信息，将获取的交易验证信息携带在自证请求中并发送所述自证请求至服务器；

如果预定时间内未收到服务器返回的自证结果，则根据来自服务器的校验规则以及获取的交易验证信息进行自证。

24.如权利要求23所述的方法，其特征在于，所述来自服务器的校验规则包括：预定日期的编码对应关系以及预定日期的日校验数；

所述预定日期的编码对应关系是预定日期的指示各字符对应的二进制哈夫曼编码的编码对应关系，其中，编码后字符的编码长度的平均值在由预定日期的日校验数确定的阈值范围内；

所述预定日期的日校验数为16以上128以下的一自然数；

所述通过输入接口获取交易验证信息包括：通过所述输入接口获取由服务器根据预定日期的编码对应关系以及预定日期的日校验数生成的银行卡支付订单交易的交易验证信息。

25.如权利要求24所述的方法，其特征在于，根据来自服务器的校验规则以及获取的交易验证信息进行自证包括：

按照所述预定日期的编码对应关系将获取的所述交易验证信息中各字符还原成对应的二进制哈夫曼编码，计算所述交易验证信息中各字符对应的二进制哈夫曼编码的长度之和，得到计算结果；

判断所述计算结果是否等于预定日期的日校验数，如果等于则确定自证成功，如果不等于则确定自证失败。

26.如权利要求25所述的方法，其特征在于，该方法进一步包括：

在确定自证成功后，将银行卡支付订单交易对应的交易验证信息以及订单信息携带在交易发生时间晚于所述银行卡支付订单交易的一笔订单交易的交易处理请求中上传至服务器，以使所述服务器验证自证成功的银行卡支付订单交易的自证有效性。