本发明涉及电子交易技术领域，更具体地，涉及一种基于二维码的交易方法和系统。
背景技术：
二维码交易是一种基于账户体系搭起来的新一代无线交易方案，商家可把账号、商品价格等交易信息汇编成一个二维码，用户通过手机扫二维码，便可实现与商家的支付结算、查询等交易。凭借快速、方便的特点，二维码交易已经成为电子交易的主流模式，各类银行、支付机构、技术服务方等对于二维码交易都有不同的需求。
目前，基于开源qrcode(quickresponsecode)为主流的二维码交易，其实现已经不是一个难题。但是基于目前的实现方式，账户机构和受理机构之间必须一对一接入，接入工作对双方都需要耗费相当大的资源。对于资源较缺乏的小机构，由于承担不起这样的接入成本，其业务发展受到限制。此外，由于受理机构具有独立的基于二维码的交易系统，当付款方的受理机构与收款方的受理机构不同时，这两套独立的二维码交易系统无法相互识别，所以在实现付款方和收款方的互联互通上存在较大的问题。
因此，需要一种技术以解决不同的基于二维码的交易系统之间的交易。
技术实现要素：
本发明实施例提供一种基于二维码的交易方法和系统，以解决不同的基于二维码的交易系统之间的交易。
为了解决上述问题，本发明提供一种基于二维码的交易方法，所述方法包括：
接收来自第一受理机构的第一请求，所述第一请求是基于二维码生成的，所述二维码由第二受理机构生成；
基于所述第一请求得到第二请求，所述第二请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息；
向所述付款方的账户机构发送所述第二请求。
可选地，所述方法还包括：
接收所述付款方的账户机构的第二应答，所述第二应答与所述第二请求一一对应；
向所述第一受理机构发送所述第二应答。
可选地，所述方法还包括：
所述第一请求是收款请求，所述第二请求是扣款请求，所述第二应答是扣款应答。
可选地，所述第一请求和所述第二请求是预下单请求，所述第二应答是预下单结果应答。
可选地，所述第一请求是支付页面生成请求，所述第二请求是预下单请求，所述第二应答是预下单结果应答；
所述基于所述第一请求得到第二请求具体包括：
解析所述支付页面生成请求得到所述第一受理机构的客户端，并向所述第一受理机构的客户端发送支付页面生成应答，所述支付页面生成应答与所述支付页面生成请求一一对应；
接收所述第一受理机构的客户端的确认订单请求；
基于所述确认订单请求得到预下单请求。
可选地，所述方法还包括：
接收所述付款方的账户机构的第三应答，所述第三应答是基于所述第一受理机构的客户端的确认支付请求得到的，所述确认支付请求是基于所述预下单结果应答得到的；
向所述第一受理机构发送所述第三应答。
可选地，所述方法还包括：
基于所述预下单结果应答，向所述第一受理机构的客户端发送确认支付提示。
可选地，所述第一请求包括所述二维码、所述二维码的解码信息中的至少一个。
可选地，所述方法还包括：
接收来自第三受理机构的查询请求，所述查询请求包括查询条件；
向所述第三受理机构发送查询应答，所述查询应答与所述查询请求一一对应。
可选地，所述查询请求包括查询账户机构；所述方法还包括：向所述查询账户机构发送所述查询请求；接收所述查询账户机构的查询应答。
为了解决上述问题，本发明提供一种基于二维码的交易系统，所述系统包括：
第一请求接收模块，用于接收来自第一受理机构的第一请求，所述第一请求是基于二维码生成的，所述二维码由第二受理机构生成；
第二请求生成模块，用于基于所述第一请求得到第二请求，所述第二请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息；
第二请求发送模块，用于向所述付款方的账户机构发送所述第二请求。
可选地，所述系统还包括：
第二应答接收模块，用于接收所述付款方的账户机构的第二应答，所述第二应答与所述第二请求一一对应；
第二应答发送模块，用于向所述第一受理机构发送所述第二应答。
可选地，所述第一请求是收款请求，所述第二请求是扣款请求，所述第二应答是扣款应答。
可选地，所述第一请求和所述第二请求是预下单请求，所述第二应答是预下单结果应答。
可选地，所述第一请求是支付页面生成请求，所述第二请求是预下单请求，所述第二应答是预下单结果应答；
所述第二请求生成模块具体用于：
解析所述支付页面生成请求得到所述第一受理机构的客户端，并向所述第一受理机构的客户端发送支付页面生成应答，所述支付页面生成应答与所述支付页面生成请求一一对应；
接收所述第一受理机构的客户端的确认订单请求；
基于所述确认订单请求得到预下单请求。
可选地，所述系统还包括：
第三应答接收模块，用于接收所述付款方的账户机构的第三应答，所述第三应答是基于所述第一受理机构的客户端的确认支付请求得到的，所述确认支付请求是基于所述预下单结果应答得到的；
第三应答发送模块，用于向所述第一受理机构发送所述第二应答。
可选地，所述系统还包括：
确认支付提示发送模块，用于基于所述预下单结果应答，向所述第一受理机构的客户端发送确认支付提示。
可选地，所述第一请求包括所述二维码、所述二维码的解码信息中的至少一个。
可选地，所述系统还包括：
查询请求接收模块，用于接收来自第三受理机构的查询请求，所述查询请求包括查询条件；
查询应答发送模块，用于向所述第三受理机构发送查询应答，所述查询应答与所述查询请求一一对应。
可选地，所述查询请求包括查询账户机构；所述系统还包括：查询请求发送模块，用于向所述查询账户机构发送所述查询请求；查询应答接收模块，接收所述查询账户机构的查询应答。
在本发明中，通过在受理机构和账户机构之间间接连接，实现不同支付系统的间接连接，能有效减少多个支付系统之间的连接复杂度，降低成本。同时，通过间接连接，互不联通的支付系统的二维码可以实现识别，从而实现基于二维码的支付交易。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例
图1为根据本发明一实施方式的一种基于二维码的交易方法流程图；
图2为根据本发明一实施方式的一种基于二维码的交易方法流程图；
图3为根据本发明一实施方式的一种基于二维码的交易方法流程图；
图4为根据本发明一实施方式的一种基于二维码的交易方法流程图；
图5为根据本发明一实施方式的一种基于二维码的交易系统结构图；以及
图6为根据本发明一实施方式的电子设备示意图。
具体实施方式
为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本领域技术人员可以理解，本申请中的“第一”、“第二”等术语仅用于区别不同设备、模块或参数等，既不代表任何特定技术含义，也不表示它们之间的必然逻辑顺序。
相较于条形码为代表的一维码，二维码可以存储的数据量更大，可以包含数字、字符，及中文文本等混合内容，有一定的容错性。基于二维码的交易，由于其便利性，目前已得到广泛的应用，企业、个人都有使用需求。二维码的编码过程大致包括以下几步骤：1、数据分析，确定编码的字符类型，按相应的字符集转换成符号字符；选择纠错等级，在规格一定的条件下，纠错等级越高其真实数据的容量越小。2、数据编码，将数据字符转换为位流，每8位一个码字，整体构成一个数据的码字序列。3、纠错编码，按需要将上步骤中的码字序列分块，并根据纠错等级和分块的码字，产生纠错码字，并把纠错码字加入到数据码字序列，成为一个新的序列。4、构造最终数据信息，构造矩阵，生成格式和版本信息放入相应区域内。此外，为保障安全性，在二维码的编码过程中还可以包括加密等步骤。通过上述编码过程，发现二维码兼具一定的通识性和特殊性。
在基于二维码的交易中，二维码包括付款码和收款码，扫码终端可以是手机软件、扫码枪等，涉及个人、商户、银行、第三方支付平台等多方。目前银行、第三方支付平台均具有独立的基于二维码的交易系统，即在不同交易系统下的生成的二维码不具有完全的通识性，影响实际使用的便利性。为能更直观表述，将实际交易中的扫码方和被扫码方所采用的交易系统的机构认为是受理机构，将付款机构、收款机构认为是账户机构。一般而言，受理机构可以是第三方支付平台，也可以是银行，而账户机构也可以是第三方支付平台或银行。
如图1所示，本发明一实施方式的一种基于二维码的交易方法流程图，应用于万码平台。
步骤s11，接收来自第一受理机构的第一请求，所述第一请求是基于二维码生成的，所述二维码由第二受理机构生成。
在二维码支付交易中，一方提供二维码，另一方负责扫码。二维码是由第二受理机构生成，并具有一定的用户标识，例如携带收款账户信息、付款账户信息等。扫码方通过手机软软件、扫码枪等终端扫描二维码并生成收款订单或者付款订单，然后将收款订单或者付款订单发送至终端所隶属的第一受理机构，第一受理机构根据收款订单或者付款订单生成第一请求，并通过接口将第一请发送到万码平台。由此可见，第一请求是基于二维码生成的。第一请求可以包括原始的二维码，例如图像数据，还可以包括对二维码进行解码后得到的解码信息，例如携带纠错码字的码字序列，或者是两者兼具。如果第一受理机构解析原始的二维码得到的解码信息包含原始二维码的所有信息，此时第一请求可以不包括原始的二维码，这样能最大限度地发挥每个受理机构所具有的功能。由于二维码的特殊性，第一请求包括二维码的解码信息一般而言不是完全解码的信息，例如不包括付款方的账号信息或者收款方的账号信息。此外，第一请求还可以包括扣款信息，扣款信息包括交易金额、订单号、交易类型、交易币种等。
步骤s12，基于所述第一请求得到第二请求，所述第二请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息。
步骤s13，向所述付款方的账户机构发送所述第二请求。
万码平台作为一个独立的中间平台，向多个受理机构、多个账户机构提供接口，可以获得不同受理机构的二维码的解码方法，在此基础上就可以解析由第一受理机构生成的第一请求和由第二受理机构生成的二维码，得到第二请求，所述第二请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息。付款方的账号信息、收款方的账号信息可以是付款方或收款方的账号，也可以是付款方或收款方的特征标识。为了进一步保证数据的安全性，付款方的账号信息、收款方的账号信息和扣款金额信息可以是经过加密，使得只有付款方账户机构能解析。此外，第二请求可以包括订单号、交易时间、清算时间、交易类型、手机软件特征标识、用户名称、用户代码、受理机构特征标识、交易渠道、手机软件调用方中的一个或多个。
在本实施例中，通过在受理机构和账户机构之间架构万码平台，实现不同支付系统的间接连接，既能完成不同支付系统的交易，同时可以减少多个支付系统之间的连接复杂度，降低成本。此外，充分利用万码平台的独立性、客观性、公正性，支付系统可以赋予其更强的二维码解码能力，从而快速实现隶属于不同支付系统下的二维码支付交易。
出于安全、商业等因素考虑，万码平台也可以不具有完全解析二维码的能力，此时通过调用二维码对应的受理机构接口，将二维码的解码任务转发给对应的受理机构，在这种情况下，所述基于所述第一请求得到第二请求具体包括：
步骤s121，根据所述第一请求确定所述第二受理机构。
步骤s122，向所述第二受理机构发送所述第一请求。
步骤s123，接收来第二请求，所述第二请求是由所述第二受理机构解析所述第一请求得到的。
万码平台根据第一请求确定所述第二受理机构，在这里，接收的第一请求中可能已经包括第二受理机构的信息，也可能需要万码平台经过解析所述第一请求才能确定第二受理机构。然后，通过调用第二受理机构的接口，将第一请求发送给第二受理机构；第二受理机构完全解析所述第一请求生成第二请求，并将该第二请求发送给万码平台。所述第二请求中的非秘密信息，例如扣款金额信息，可以是由第一受理机构直接发送给万码平台，或者是万码平台解析第一请求得到，或者是第二受理机构解析第一请求得到，本发明实施例不作限制。在该实施例中，通过在受理机构和账户机构之间架构万码平台，实现不同支付系统的间接连接，既能完成不同支付系统的交易，同时可以减少多个支付系统之间的连接复杂度，降低成本。此外，各个支付系统之间还能保持商业秘密性和安全性，灵活地进入或退出。
进一步的，所述方法还包括：
步骤s14,接收所述付款方的账户机构的第二应答，所述第二应答与所述第二请求一一对应；
步骤s15,向所述第一受理机构发送所述第二应答。
付款方的账户机构在接收到第二请求后，按照第二请求对相应的付款方账号执行扣款或者预下单，并生成第二应答。如果第二请求执行成功，则第二应答是执行成功信息；如果第二请求执行失败，则第二应答是执行失败信息及其失败的参数。账户机构将第二应答发给万码平台，万码平台将第二应答转发给第一受理机构。万码平台还可以保存第二应答，以便清算、后续的查询等。
万码平台提供三种子模式为受理机构和账户机构提供扫码消费支付转接服务，根据账户机构、受理机构的需求选择性使用。
在一种实施方式中，所述第一请求是收款请求，所述第二请求是扣款请求，所述第二应答是扣款应答。当二维码是付款码，第一受理机构是收款方所隶属的受理机构，第一请求是收款方向其受理机构发起的收款请求，第二请求是受理机构向万码平台上送的扣款请求，第二应答是账户机构执行万码平台发送的扣款请求后生成的扣款应答。
在一种实施方式中，所述第一请求和所述第二请求是预下单请求，所述第二应答是预下单结果应答。当二维码是收款码，第一受理机构是付款方所隶属的受理机构，并且第一受理机构选择自定义支付页面，此时第一请求是付款方的受理机构向万码平台发送的预下单请求，第二请求是万码平台向付款方的账户机构发送的预下单请求，第二应答是账户机构执行万码平台发送的预下单请求后生成的预下单结果应答。此时预下单请求是不完全的扣款请求，需要接收到付款方的确认支付请求后才能进行最后的扣款操作。
在一种实施方式中，所述第一请求是支付页面生成请求，所述第二请求是预下单请求，所述第二应答是预下单结果应答。当二维码是收款码，第一受理机构是付款方所隶属的受理机构，并且第一受理机构选择万码平台统一的支付页面，此时，第一请求是付款方的受理机构向万码平台发送的支付请求生成页面，第二请求是万码平台向付款方的账户机构发送的预下单请求，第二应答是账户机构执行万码平台发送的预下单请求后生成的预下单结果应答。万码平台收到支付页面生成请求后，解析得到第一受理机构的客户端，并向所述第一受理机构的客户端发送支付页面生成应答，支付页面生成应答与支付页面生成请求一一对应。客户端响应支付页面生成应答，向用户呈现支付页面，用户确认订单，即客户端向万码平台发送确认订单请求。万码平台基于确认订单请求得到预下单请求，并对相应的付款方的账户机构发送预下单请求。账户机构执行预下单请求，返回预下单结果应答至万码平台。万码平台将预下单结果应答发送给第一受理机构。进一步的，所述方法还可以包括：基于所述预下单结果应答，向所述第一受理机构的客户端发送确认支付提示，用于提醒客户确认支付。这样可以尽可能减少受理机构的任务，缩短消费者等待时间。
当第二请求是预下单请求时，万码平台还可以接收所述付款方的账户机构的第三应答，所述第三应答是基于所述第一受理机构的客户端的确认支付请求得到的，所述确认支付请求是基于所述预下单结果应答得到的；向所述第一受理机构发送第三应答。当用户通过客户端发出确认支付请求后，账户机构执行扣款，并将交易结果的通知即第三应答返回给万码平台。万码平台可以向第一受理机构转发第三应答，也可以自己保存第三应答。
在一种实施方式中，本方法还可以包括：接收来自第三受理机构的查询请求，所述查询请求包括查询条件；向所述第三受理机构发送查询应答，所述查询应答与所述查询请求一一对应。进一步的，所述查询请求包括查询账户机构，方法还可以包括：向所述查询账户机构发送所述查询请求；接收所述查询账户机构的查询应答。万码平台收到来自受理机构的查询请求，查询条件可以是交易记录、交易状态、交易时间、清算时间、交易渠道、用户名称、用户代码、交易金额，查询条件可以是精确条件也可以是模糊条件。如果查询请求是交易记录或者交易状态时，如果万码平台中保存该交易记录或者该交易状态为最终态时，则直接将查询信息返回受理机构，即查询应答；如果万码平台中无该交易记录或者该交易状态为未知，万码平台向对应的查询账户机构转发查询请求，由该查询账户机构生成对应的查询应答，并将该查询应答返回给受理机构。
如图2所示，本发明一实施方式的一种基于二维码的交易方法流程图。
步骤201，客户a出示由第二受理机构生成的付款码，用户b用扫码终端扫码后向所属的第一受理机构发送收款订单。这里用户a可是商户，也可以是个人。
步骤202，第一受理机构基于收款订单生成用户b对客户a的带有付款码的收款请求，即第一请求。由于第一受理机构能识别所述付款码的部分信息，因此所述收款请求包括付款码、付款码的解码信息，除此以外还包括商户的特征信息和扣款金额信息。
步骤203，万码平台接收所述收款请求，解析所述收款请求得到扣款请求，即第二请求。所述扣款请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息。
步骤204，万码平台向所述付款方的账户机构发送所述扣款请求。
步骤205，所述付款方的账户机构接收并执行扣款请求，然后向所述万码平台发送扣款应答，即第二应答，所述扣款应答与所述扣款请求一一对应。在此过程中，所述付款方的账户机构可以验证扣款请求，如果完成扣款请求，则发送的扣款应答是成功扣款，如果没有完成扣款请求，则根据错误原因发送对应的扣款应答，错误原因可以是账号不存在、余额不足等等，本发明不作限制。此外，付款方的账户机构还可以向付款方的手机、软件等发送扣款通知。
步骤206，万码平台接收并保存扣款应答。
步骤207，万码平台向所述第一受理机构发送所述扣款应答。
通过以上步骤就可以实现用户a与用户b之间的二维码支付交易，本实施方式还可以包括：
步骤208，第一受理机构向万码平台发送用户报备请求，所述用户报备请求包括用户报备账户机构和用户信息。实际中，部分账户机构要求接入的受理机构定期或不定期的向其报备用户信息，因此一般而言当受理机构新增某一用户时会发起用户报备请求，当然受理机构的用户在减少时也可以发起用户报备请求，或者受理机构定期向该账户机构发起用户报备请求。
步骤209，万码平台接收商户用户请求，并向所述用户报备机构发送用户报备请求。在这里用户报备账户机构和用户信息可以时加密信息或者非加密信息，或者是，可直接读取信息或非可直接读取信息，本实施方式不作限制。
步骤210，所述用户报备账户机构执行用户报备请求，并向所述万码平台发送用户报备应答，所述用户报备应答与所述用户报备请求一一对应。在此过程中，所述用户报备账户机构可以检查流水看商户信息是否重复，如果完成用户报备请求，则发送的商户用户应答是成功商户报备，如果没有完成用户报备请求，则根据错误原因发送对应的用户报备应答，本发明不作限制。
在本实施例中，通过在受理机构和账户机构之间架构万码平台，实现不同支付系统的间接连接，减少多个支付系统之间的连接复杂度，降低成本，同时完成不同支付系统的支付、用户报备等交易。
如图3所示，本发明一实施方式的一种基于二维码的交易方法流程图。
步骤301，用户a使用其手机软件扫描用户c的收款码，生成付款订单并发送到用户a的手机软件所隶属的受理机构，即第一受理机构。用户c的收款码由第二受理机构生成，携带有用户c的特征信息。这里用户a、c可是商户，也可以是个人。
步骤302，第一受理机构基于付款订单生成第一请求，并通过接口发送给万码平台。这里的第一受理机构在使用万码平台时选择由万码平台提供支付页面，即万码平台提供统一或定制的支付页面。所以这里的第一请求是支付页面生成请求。
步骤303，万码平台接收所述支付页面生成请求，并根据该支付页面生成请求得到与支付页面生成请求对应的支付页面生成应答和用户a所使用的手机软件。将支付页面生成应答发送给用户a的手机软件。
步骤304，手机软件接收支付页面生成应答后显示支付页面，支付页面包括收款方名称、付款金额输入框和确认订单的触发。用户a根据实际支付场景填入支付金额，确认订单后通过手机软件向万码平台发送确认订单请求。确认订单的触发可以是虚拟按键、虚拟滑动条、支付密码验证、手势密码验证、指纹验证、面部验证、声音验证等，本发明不作限定。可选的，支付页面还可以包括收款方标识、万码平台标识等。
步骤305，万码平台接收确认订单请求，解析确认订单请求得到预下单请求，即第二请求。预下单请求包括付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息。预下单不是真正的扣款，需要用户a的进一步确认或者支付指令才能继续后续的扣款，可以是冻结扣款金额对应的额度。
步骤306，付款方的账户机构接收预下单请求，执行预下单请求，然后向所述万码平台发送预下单结果应答，即第二应答，所述预下单结果应答与所述预下单请求一一对应。在此过程中，所述付款方的账户机构可以验证预下单请求，如果完成预下单请求，则发送的预下单结果应答是成功预下单，如果没有完成预下单请求，则根据错误原因发送对应的预下单结果应答，错误原因可以是账号不存在、余额不足等等，本发明不作限制。
步骤307，万码平台接收所述预下单结果应答，并向所述第一受理机构发送预下单结果应答。进一步的，万码平台可以保存预下单结果应答，以便于过程记录、查询记录等。
步骤308，万码平台接收
预下单结果应答后回调用户a的手机软件，向其发送确认支付的提示，用于提醒用户支付该订单。同样的，用户确认支付的触发可以是虚拟按键、虚拟滑动条、支付密码验证、手势密码验证、指纹验证、面部验证、声音验证等，本发明不作限定。对于用户a而言，订单确认和支付确认可以做成合并，用户实际使用时无法区分。
步骤309，用户a的手机软件接收并显示确认支付提示，用户确认支付，并向其付款账户的账户机构发送扣款确认。
步骤310，付款方的账户机构根据用户a的扣款确认完成支付交易，并向用户a的手机软件返回扣款结果。
步骤311，付款方的账户机构执行支付交易后，还可以向万码平台发送扣款结果应答，即第三应答。由此可见，第三应答是基于第一受理机构的客户端的确认支付请求得到的，而确认支付请求是基于所述预下单结果应答得到的。
步骤312，万码平台向第一受理机构转发扣款结果应答。进一步的，万码平台可以选择保存扣款结果应答。扣款结果应答可以与预下单结果应答按订单、用户等共同保存，或者，按交易状态等分开保存，视保存目的而定。
通过以上步骤就可以实现用户a与用户c之间的二维码支付交易，本实施方式还可以包括：
步骤313，用户a通过其手机软件向第一受理机构发送查询请求。不管是个人或者商户，平时我们都有需求查询自己某一账户的收入、支出情况。这样的查询可以是精确查询，例如查询某一账号、某段时间、某种货币的支出情况，也可以是模糊查询，例如自己所有账户的流水，本实施方式不作限制。
步骤314，第一受理机构接收并向万码平台发送所述查询请求。当然，如果第一受理机构出于一定的因素需要对用户发送的查询请求作处理，例如安全，记录等因素，本实施方式不限制。
步骤315，万码平台接收来自第一受理机构的查询请求，所述查询请求包括查询账户机构和查询条件，向所述查询账户机构发送查询请求。查询条件可以是查询账号信息、交易时间信息、清算时间等等，查询账号信息可以是用户a的账号，也可以是用户a的特征标识。在这里查询账户机构和查询条件可以时加密信息或者非加密信息，或者是，可直接读取信息或非可直接读取信息，本实施方式不作限制。
步骤316，查询账户机构接收并执行查询请求，然后向万码平台发送所述查询应答。所述查询应答与所述查询请求一一对应。如果所述查询请求中包括具体的查询条件，那查询应答是具体的符合查询条件的交易信息，如果所述查询请求中不包括具体的查询条件，那查询应答则是用户a在该查询账户机构的所有交易信息，本实施方式不限制。
步骤317，万码平台接收查询应答，并向第一受理机构发送所述查询应答。
步骤318，第一受理机构接收查询应答，并向用户a的手机软件发送所述查询应答。
如果万码平台保存有查询条件对应的查询信息，万码平台将不转发来自受理机构的查询请求，而是直接执行查询请求得到查询信息，并将查询应答返回给受理机构。
在本实施例中，通过在受理机构和账户机构之间架构万码平台，实现不同支付系统的间接连接，减少多个支付系统之间的连接复杂度，降低成本，同时完成不同支付系统的支付、查询等交易。
如图4所示，本发明一实施方式的一种基于二维码的交易方法流程图。
步骤401，用户a使用其手机软件扫描用户c的收款码，生成付款订单并发送到用户a的手机软件所隶属的受理机构，即第一受理机构。用户c的收款码由第二受理机构生成，携带有用户c的特征信息。这里用户a、c可是商户，也可以是个人。
步骤402，第一受理机构接收并响应付款订单。这里的第一受理机构在使用万码平台时选择自定义提供支付页面，因此根据该付款订单，第一受理机构返回支付页面生成应答。
步骤403，手机软件接收支付页面生成应答后显示支付页面，支付页面包括收款方名称、付款金额输入框和确认订单的触发。用户a根据实际支付场景填入支付金额，确认订单后手机软件向第一受理机构发送确认订单请求。确认订单的触发可以是虚拟按键、虚拟滑动条、支付密码验证、手势密码验证、指纹验证、面部验证、声音验证等，本发明不作限定。可选的，支付页面还可以包括收款方标识、万码平台标识等。
步骤404，第一受理机构基于确认订单生成预下单请求，即第一请求，并通过接口发送给万码平台。
步骤405，万码平台接收预下单请求，并向付款方的账户机构转发预下单请求。预下单请求包括付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息。预下单不是真正的扣款，需要用户a的进一步确认或者支付指令才能继续后续的扣款，可以是冻结某一额度。当然可能由于第一受理机构的解码能力或者协议要求，第一受理机构生成的预下单请求是不完全预下单请求，此时即使直接发送给账户机构不能执行预下单。这种情况下，万码平台需要对于接收到的“预下单请求”做进一步处理，得到账户可以执行的预下单请求。
步骤406，付款方的账户机构接收预下单请求，执行预下单请求，然后向所述万码平台发送预下单结果应答，即第二应答，所述预下单结果应答与所述预下单请求一一对应。在此过程中，所述付款方的账户机构可以验证预下单请求，如果完成预下单请求，则发送的预下单结果应答是成功预下单，如果没有完成预下单请求，则根据错误原因发送对应的预下单结果应答，错误原因可以是账号不存在、余额不足等等，本发明不作限制。
步骤407，万码平台接收所述预下单结果应答，并向所述第一受理机构发送预下单结果应答。进一步的，万码平台可以保存预下单结果应答，以便于过程记录、查询记录等。
步骤408，第一受理机构接收预下单结果应答后回调用户a的手机软件，向其发送确认支付的提示，用于提醒用户支付该订单。同样的，用户确认支付的触发可以是虚拟按键、虚拟滑动条、支付密码验证、手势密码验证、指纹验证、面部验证、声音验证等，本发明不作限定。对于用户a而言，订单确认和支付确认可以做成合并，用户实际使用时无法区分。
步骤409，用户a的手机软件接收并显示确认支付提示，用户确认支付，并向其付款账户的账户机构发送扣款确认。
步骤410，付款方的账户机构根据用户a的扣款确认完成支付交易，并向用户a的客户端返回扣款结果。
步骤411，付款方的账户机构执行支付交易后，还可以向万码平台发送扣款结果应答，即第三应答。由此可见，第三应答是基于第一受理机构的客户端的确认支付请求得到的，而确认支付请求是基于所述预下单结果应答得到的。
步骤412，万码平台向第一受理机构转发扣款结果应答。进一步的，万码平台可以选择保存扣款结果应答。扣款结果应答可以与预下单结果应答按订单、用户等共同保存，或者，按交易交易状态等分开保存，视保存目的而定。
通过以上步骤就可以实现用户a与用户c之间的二维码支付交易，本实施方式还可以包括：
步骤413，在清算时或者内部查询时，第一受理机构也可以发起查询请求。这样的查询可以是精确查询，例如查询某一账号、某段时间、某种货币的支出情况，也可以是模糊查询，例如自己所有账户的流水，本实施方式不作限制。如果第一受理机构出于一定的因素需要对用户发送的查询请求作处理，例如安全，记录等因素，本实施方式不限制。
步骤414，万码平台接收来自第一受理机构的查询请求，所述查询请求包括查询账户机构和查询条件，向所述查询账户机构发送查询请求。查询条件可以是查询账号信息、交易时间信息、清算时间等等，查询账号信息可以是第一受理机构的用户的账号或者标识，例如用户a。在这里查询账户机构和查询账号信息可以时加密信息或者非加密信息，或者是，可直接读取信息或非可直接读取信息，本实施方式不作限制。
步骤415，查询账户机构接收并执行查询请求，然后向万码平台发送所述查询应答。所述查询应答与所述查询请求一一对应。如果所述查询请求中包括具体的查询条件，那查询应答是具体的符合查询条件的交易信息，如果所述查询请求中不包括具体的查询条件，那查询应答则是用户a在该查询账户机构的所有交易信息，本实施方式不限制。
步骤416，万码平台接收查询应答，并向第一受理机构发送所述查询应答。
如果万码平台保存有查询条件对应的查询信息，万码平台将不转发来自受理机构的查询请求，而是直接执行查询请求得到查询信息，并将查询应答返回给受理机构。
在本实施例中，通过在受理机构和账户机构之间架构万码平台，实现不同支付系统的间接连接，减少多个支付系统之间的连接复杂度，降低成本，同时完成不同支付系统的支付、查询等交易。
如图5所示，本发明提供一种基于二维码的交易系统，所述系统包括：
第一请求接收模块，用于接收来自第一受理机构的第一请求，所述第一请求是基于二维码生成的，所述二维码由第二受理机构生成；
第二请求生成模块，用于基于所述第一请求得到第二请求，所述第二请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息；
第二请求发送模块，用于向所述付款方的账户机构发送所述第二请求。
可选地，所述系统还包括：
第二应答接收模块，用于接收所述付款方的账户机构的第二应答，所述第二应答与所述第二请求一一对应；
第二应答发送模块，用于向所述第一受理机构发送所述第二应答。
可选地，所述第一请求是收款请求，所述第二请求是扣款请求，所述第二应答是扣款应答。
可选地，所述第一请求和所述第二请求是预下单请求，所述第二应答是预下单结果应答。
可选地，所述第一请求是支付页面生成请求，所述第二请求是预下单请求，所述第二应答是预下单结果应答；
所述第二请求生成模块具体用于：
解析所述支付页面生成请求得到所述第一受理机构的客户端，并向所述第一受理机构的客户端发送支付页面生成应答，所述支付页面生成应答与所述支付页面生成请求一一对应；
接收所述第一受理机构的客户端的确认订单请求；
基于所述确认订单请求得到预下单请求。
可选地，所述系统还包括：
第三应答接收模块，用于接收所述付款方的账户机构的第三应答，所述第三应答是基于所述第一受理机构的客户端的确认支付请求得到的，所述确认支付请求是基于所述预下单结果应答得到的；
第三应答发送模块，用于向所述第一受理机构发送所述第二应答。
可选地，所述系统还包括：
确认支付提示发送模块，用于基于所述预下单结果应答，向所述第一受理机构的客户端发送确认支付提示。
可选地，所述第一请求包括所述二维码、所述二维码的解码信息中的至少一个。
可选地，所述系统还包括：
查询请求接收模块，用于接收来自第三受理机构的查询请求，所述查询请求包括查询条件；
查询应答发送模块，用于向所述第三受理机构发送查询应答，所述查询应答与所述查询请求一一对应。
可选地，所述查询请求包括查询账户机构；所述系统还包括：查询请求发送模块，用于向所述查询账户机构发送所述查询请求；查询应答接收模块，接收所述查询账户机构的查询应答。
参考图6，为本发明一个实施方式的电子设备示意图。如图6所示，该电子设备包括：
存储器63以及一个或多个处理器61；
其中，所述存储器63与所述一个或多个处理器61通信连接，所述存储器63中存储有可被所述一个或多个处理器执行的指令，所述指令被所述一个或多个处理器61执行，以使所述一个或多个处理器61执行：
接收来自第一受理机构的第一请求，所述第一请求是基于二维码生成的，所述二维码由第二受理机构生成；
基于所述第一请求得到第二请求，所述第二请求包括所述付款方的账户机构、付款方的账号信息、收款方的账号信息和扣款金额信息；
向所述付款方的账户机构发送所述第二请求。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。