CN116384993B - 基于云支付中心实现订单支付状态高一致性的方法与系统 - Google Patents

基于云支付中心实现订单支付状态高一致性的方法与系统 Download PDF

Info

Publication number
CN116384993B
CN116384993B CN202310653912.8A CN202310653912A CN116384993B CN 116384993 B CN116384993 B CN 116384993B CN 202310653912 A CN202310653912 A CN 202310653912A CN 116384993 B CN116384993 B CN 116384993B
Authority
CN
China
Prior art keywords
payment
notification
service
state
cloud
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202310653912.8A
Other languages
English (en)
Other versions
CN116384993A (zh
Inventor
高寿柏
仲茜
李辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shandong Shichuang Yun Service Co ltd
Original Assignee
Shandong Shichuang Yun Service Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shandong Shichuang Yun Service Co ltd filed Critical Shandong Shichuang Yun Service Co ltd
Priority to CN202310653912.8A priority Critical patent/CN116384993B/zh
Publication of CN116384993A publication Critical patent/CN116384993A/zh
Application granted granted Critical
Publication of CN116384993B publication Critical patent/CN116384993B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明公开一种基于云支付中心实现订单支付状态高一致性的方法与系统，属于安全支付的技术领域。本发明提出双向支付状态一致性保证机制，在云支付中心侧采用尽最大努力通知的方法，利用异步通知方式，应用多策略组合，提高通知消息送达的可靠性；在业务系统侧部署专用的支付适配服务组件，用于执行各类一致性保证策略，减少对业务系统的侵入，采用重要事件触发查询的方法，利用同步查询方式，应用多策略组合，提高支付状态同步的实效性。以云支付中心侧异步通知为基础，业务系统侧同步查询为增强，同时采取措施确保无论是通知或是查询机制都不能对系统的正常业务造成较大影响，这里所述的异步与同步都是针对业务系统而言的。

Description

基于云支付中心实现订单支付状态高一致性的方法与系统
技术领域
本发明公开一种基于云支付中心实现订单支付状态高一致性的方法与系统，属于安全支付的技术领域。
背景技术
为了有效应对C端用户需求和B端业务需求的快速变化，必须实现软件敏捷设计、开发和持续集成，为此工业界和学术界提出了许多新颖的软件设计模型和方法。在这些模型与方法中，目前最被业界广泛采用的是基于微服务模型的软件设计与实现方法。微服务模型是对传统SOA模型的优化，更为简单灵活，它按照“服务间松耦合、服务内高内聚”的原则，对系统功能进行了合理划分，将原来大的单体系统，拆分成若干相对独立的微服务进行实现和部署。每个微服务的设计和开发可交由独立团队完成，部署时可根据实际需求动态增减资源数量，在服务发现和运维框架的支持下，能够实现现有微服务的重用。微服务的运用实践表明，它能够有效提高企业软件开发、运维的敏捷程度和资源利用率，有效降低企业开发、部署和运维软件系统的成本。
构建微服务意味着构建分布式系统，对分布式系统进行运维对于大多数中小企业来讲是困难的，因此通常直接使用云平台提供的资源与服务进行云化部署，这已成为微服务部署的主流方式。微服务一个重要的应用场景是电商系统，由于对高性能、高可用、高并发的需求强烈，电商系统大多首选采用微服务技术。由于电商业务需求相对比较稳定，因此在进行微服务划分时，有一套成熟的方案，在这些电商系统的微服务中，最为敏感、对可靠性和一致性要求最高的是支付服务。如果不明确指明，本文的支付指的是广义支付，包括与支付相关的各类操作，常见的有付款、退款、转账、分账等。对于支付服务，早期常采用直接在电商系统中开发独立的支付服务模块的方式实现。但是由于支付过程的各主要环节会受到国家相关法律法规和行业规则的约束，其功能需求和处理流程基本一致，这样不同系统开发出的支付服务都很类似，因此完全可以将支付服务独立出来，构建由专业团队开发和运维的云支付中心，为电商及其他有支付需求的用户提供更为安全、可靠、高效、灵活的支付服务，这种支付功能交付方式将成为未来支付服务的发展趋势。
现有技术中存在以下专利文献：
中国专利文献：CN110298647A公开了一种支付方法及装置。该方法包括配置业务方的支付信息；向微服务端发起支付服务请求；通过所述微服务端返回支付结果。本申请解决了支付方式不统一的技术问题。通过本申请简化支付流程和保证支付安全。
中国专利文献：CN113723942A公开一种聚合支付方法、装置、设备及存储介质。在接收到支付服务调用请求时，从预设数据库中匹配目标配置信息，预设数据库中存放有预先聚合的多个第三方支付平台的配置信息，然后根据目标配置信息向支付服务调用请求对应的目标第三方支付平台发送交易请求，以使目标第三方支付平台反馈交易请求对应的订单支付结果通知，并在接收到订单支付结果通知时，根据订单支付结果通知向用户反馈支付服务调用请求对应的订单状态。从预设数据库中匹配目标配置信息，能够对接入的第三方支付平台的配置信息统一管理，向目标第三方支付平台发出交易请求，然后向用户反馈订单状态，从而对第三方支付平台提供的支付方式进行统一服务管理。
中国专利文献：CN110335029A提供了一种统一支付网关、方法和系统。该统一支付网关包括：业务平台接口模块，用于对接业务平台，将来自业务平台的业务订单信息发送至支付行为拆分处理模块，以及将支付结果反馈至业务平台；支付行为拆分处理模块，用于根据业务订单信息的特征生成一个或多个不同的支付行为，并提交到支付处理模块；支付处理模块，用于根据所述支付行为生成支付界面，接收支付信息并完成支付，将支付结果发送至业务平台接口模块。
中国专利文献：CN115239494A公开了一种支付交易处理方法及装置，涉及分布式，其中该方法包括：接收交易发起系统的支付交易发起后，根据交易类型确定需调动的微服务，以及调动顺序；接收并保存各微服务返回的处理结果，在根据处理结果确定微服务出现异常时，根据出现异常的微服务在支付交易中的位置及顺序，按支付业务场景中该交易类型的业务要求进行处理；将各微服务返回的处理结果存主数据库。该文献可以保证了交易处理结果和账务的一致性，避免了交易处理失败但客户账号被扣款的情况；通过异步写库存交易信息的设计方案，保证交易信息传输的可靠性，同时提高了系统的并发性能。
中国专利文献：CN115562898A提供一种分布式支付系统异常处理方法及装置，涉及分布式领域，方法包括：根据分布式支付系统共有链条上的业务逻辑节点依次调用各个业务微服务，以使所述业务微服务在被调用成功时执行相应的业务处理并更新交易的流转状态，在被调用失败时返回调用失败信号；接收所述业务微服务返回的调用失败信号，根据所述调用失败信号中的失败编码和数据库中预存储的错误信息表，更新所述交易的流转状态，其中，所述错误信息表包含错误编码和对应的出错后交易流转状态；本申请能够准确对出现异常的各服务进行统一的异常处理，提高分布式支付系统的灵活性和实用性。
由上述支付系统（服务）相关的专利文献中可知，目前主流的支付系统大都采用了微服务架构，部署为一个独立的支付服务（支付网关）。同时为了支持业务与支付的解耦，有的系统对支付过程进行抽象以支持多类型的三方支付平台，使用户可以在不同的支付平台间快速切换。支付交易处理状态的最终一致性问题，是基于支付服务的分布式系统的关键问题，为了解决这一问题文献中系统采用分布式事务处理常用的一致性补偿方法，同时结合消息队列实现数据更新的可靠性。
上述文献中的支付系统，均是作为业务平台中的一个支付服务进行实现和部署的，对业务系统的侵入性强，并不能以云化的方式为不同的业务系统共享，这类支付系统通常没有自己独立的管理系统。而云支付中心作为独立部署的为不同业务系统提供服务的系统，有独立的管理系统，可以提供支付管理、运营管理、商户管理、安全认证管理和数据分析等更为全面的服务。另外，在上述文献中解决一致性问题采用的是失败补偿的机制，它并不是从错误的源头就采取措施避免不一致情况的出现，而是发现不一致情况后进行回滚操作，恢复错误发生前的状态，因此效率较低、对业务的侵入性较强。
综上，为此本技术领域提出一种基于云支付中心的支付系统，包括支付中心系统和业务系统中的支配适配服务，如附图1所示，是一种典型的分布式系统，传统数据库事务ACID理论，Atomicity：原子性、Consistency：一致性、Isolation：隔离性、Durability：持久性，所述ACID理论已经不再适用，取而代之的是CAP理论，所述CAP理论指出一个分布式系统很难同时满足一致性，即Consistency、可用性Availability和分区容错性Partitiontolerance这三项要求，最多只能满足两项。这里的一致性指的是强一致性，即各个分布式节点中的数据必须保持一致，这导致了C和A通常很难同时满足。在大多数分布式系统中，强制实现C的代价非常高，同时高并发、高可用的需求，要求系统必须提供对A的支持。因此，多采用弱化C方式，实现最终一致性，允许在某些时间段内不同节点可以出现数据不一致的情况。
但是在具备支付功能的业务系统中，情况有所不同。在这类系统中，与支付直接相关的是订单服务，业务系统中的业务订单在支付服务中通常会有支付订单与之对应。订单的处理是基于状态的，如果订单服务和支付服务中相对应订单的支付状态不一致，可能会造成较为严重的后果，比如出现重复支付、支付成功但订单被取消等情况，对业务系统的正常运行造成较大影响，同时会大大提高业务系统的运营成本。因此，如何在保证AP的情况下，尽最大可能在支付异常发生前实现订单支付状态的一致性，从而避免异常情况的发生，保证支付流程顺利完成，是基于云支付中心的支付系统必须解决的关键问题。
由此对应衍生出的现有方法及原理：由于在支付过程中既涉及支付中心调用支付平台进行预支付，又涉及用户根据预支付信息实际进行付款，支付过程步骤多、支付时间相对较长，通常不使用同步调用的方式实现，因为线程阻塞时间较长，对系统性能的影响较大，而采用异步回调的方式将支付结果通知业务系统，业务系统根据支付结果通知修改指定订单的支付状态。若异步通知由于种种原因未能及时送达，就会出现业务订单与对应支付订单支付状态不一致的情况。为了保证系统间支付状态的一致性，相关研究机构和个人提出了很多新颖、实用的解决方法，这些方法大多将解决问题的重点放在提高支付中心向业务系统发送异步通知消息的可靠性上，具体的讲主要包括使用现有消息队列框架（如rabbitMQ、rocketMQ、kafka等）进行消息传递和按照支付系统的预定规则向业务系统重发通知两类：
(1)基于消息队列方法。该类方法多用于部署于专网或内网中的支付中心系统，即利用现有的消息队列框架的可靠性保证机制，实现异步消息的可靠性传递。现有的消息队列框架均提供相应机制以保证消息通信的可靠性。以rabbitMQ为例，在消息发送端（生产者）提供消息发送情况的确认机制，当未能将消息发送到指定交换机或队列时，消息框架会调用注册的回调函数，通知发送端消息发送失败，用户在编写的回调函数中确定如何对消息发送失败进行处理，比如重发消息等；在消息接收端（消费者）提供手动确认机制，接收端在接收到消息后，需在程序中显示对消息进行确认，否则消息不会在消息队列中删除，消息接收者在接收消息时仍会对此消息进行处理。其他的消息队列框架，如rocketMQ、kafka等也有类似的机制。
(2)重发通知方法。该类方法是目前独立部署、以api接口形式提供服务的支付平台最常采用的可靠性保证方法。即每次向业务系统发送异步通知时，如果异步通知未被响应就间隔一段时间重发通知，考虑到系统性能，一般不会频繁和无休止的重发，通常会设置最大的重发次数，达到最大重发数次后停止发送。发送时间间隔可采用固定和可变两种方式，采用可变间隔时通常开始密集，然后逐渐稀疏，发送间隔和重发次数由支付服务确定，不同的系统通常会建立不同的规则。
然而，上述方法在解决其所针对的问题时是有效的，但是在应对云支付中心环境下实现订单支付状态高一致性问题时存在一定的局限性。
其中所述基于消息队列方式存在以下问题。云支付中心通常是独立部署的，而基于消息队列方式通常只应用支付中心和业务系统在同一个内部网络中的情况，因为消息队列作为基础设施，通常不对外暴露，否则会面临安全性问题。另外，即使使用消息队列也不能完全避免消息丢失，且会降低处理消息的灵活性，同时引入新的组件也会带来新的可靠性问题。
所述重发通知的方式存在的问题。单纯采用重发方式，由于最大次数的限制，并不能完全保证消息通知可靠性；同时发送间隔由支付中心确定，而支付中心往往需要支持许多不同的业务系统，无法确保在任何时间和状态下都能满足业务系统对订单支付状态一致性的要求。
综上，针对安全支付领域，推出一种高效、有效的信息交换机制，在云支付中心环境下，确保云支付中心与业务系统支付状态的高一致性是一项亟待解决的技术问题。
发明内容
针对现有技术存在的问题，本发明公开一种基于云支付中心实现订单支付状态高一致性的方法。
本发明还公开一种实现上述方法的系统。
发明概述：
在云支付中心环境下订单支付状态不一致的原因分析：
云支付中心环境下订单支付状态不一致主要是由于网络、系统故障及人为因素导致，其中人为因素通常可通过加强管理和容灾备份的方式解决，本文重点关注由于网络和系统因素引起订单支付状态不一致的问题。网络因素包括短期因素和中长期因素两类，短期因素如网络抖动或网络拥塞导致的网络数据包丢失，通常只会影响个别通知数据包；中长期因素，包括配置错误、设备故障、管理事故等，会导致网络在一段时间内无法使用。系统因素也包括短期因素和中长期因素两类，短期因素如系统自身或外部异常导致的系统重启、用户误操作引起的异常等，通常只会使系统在短期内失效；中长期因素包括配置错误、资源不足、系统缺陷等，会导致系统在一段时间内无法使用。
为此，本发明设计一种双向支付状态一致性保证机制，即针对云支付中心环境下订单支付状态不一致原因，在云支付中心侧和业务系统侧同时采取措施，提出双向支付状态一致性保证机制，在云支付中心侧采用尽最大努力通知的方法，利用异步通知方式，应用多策略组合，提高通知消息送达的可靠性；在业务系统侧部署专用的支付适配服务组件，用于执行各类一致性保证策略，减少对业务系统的侵入，采用重要事件触发查询的方法，利用同步查询方式，应用多策略组合，提高支付状态同步的实效性。以云支付中心侧异步通知为基础，业务系统侧同步查询为增强，同时采取措施确保无论是通知或是查询机制都不能对系统的正常业务造成较大影响，这里所述的异步与同步都是针对业务系统而言的。
本发明详细的技术方案如下：
一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，包括：云支付中心侧异步通知策略和业务系统侧同步查询策略；
所述云支付中心侧异步通知策略包括：
策略一：短期重试通知策略，用于短期网络和系统因素引起订单支付状态不一致时，
步骤1-1:收到二/三方支付平台的关于支付结果异步通知消息或者重发通知定时时间到期；
步骤1-2:云支付中心的通知信息表中没有异步通知记录时，则新建该记录：包括通知的消息内容、通知地址、通知状态和通知时间；
步骤1-3:修改通知信息表中的通知次数和时间，未达到设置的最大通知次数时，向业务系统发通知，通知业务系统支付请求的处理结果，所述最大通知次数为未收到业务系统响应时重发消息的最大次数，可由支付中心管理员根据实际情况进行配置，该配置方法并不是本发明所要保护的内容；
步骤1-3-1:收到业务系统的接受成功响应，则在通知信息表中设置通知成功状态；
步骤1-3-2:未收到业务系统的接受成功响应，则根据云支付中心预设的时间间隔向消息队列发送延迟消息，准备下一次向业务系统重发通知；
步骤1-4:达到最大通知次数时，在通知信息表中设置通知失败状态；
所述业务系统侧同步查询策略包括：
策略五：短期重试查询策略，用于短期网络和系统因素引起订单支付状态不一致时，
步骤5-1:成功向支付中心发送支付请求后延迟时间到期或重发查询请求的定时时间到期；
步骤5-2:成功发送支付请求后在业务系统支付适配服务的支付请求记录表中记录此次请求，包括订单号、请求类型、请求时间、执行状态和执行次数；
步骤5-3:每次发送请求后更新支付请求记录表中的执行次数和本次请求时间，未达到设置的最大执行次数，则向支付中心发送支付状态查询请求；
步骤5-3-1：收到支付中心的查询响应结果，支付请求记录表中对应支付请求的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作，所述后处理操作包括修改订单状态、添加操作日志、修改用户权益，比如用户积分、用户优惠券、用户等级；
步骤5-3-2：未收到支付中心的查询响应结果，根据时间间隔向消息队列发送延迟消息，准备下一次重发查询，执行步骤5-1至步骤5-3；
步骤5-4：达到最大重发次数时，则在支付请求记录表中设置查询失败状态。
根据本发明优选的，所述云支付中心侧异步通知策略还包括：
策略二：事件触发通知策略，用于中长期网络和系统因素引起订单支付状态不一致时，
步骤2-1:向业务系统成功发送异步消息通知；
步骤2-2:扫描云支付中心的通知信息表；
步骤2-3:如果通知信息表中记录的某条异步通知的通知地址与步骤2-1中通知地址属于同一业务系统，且通知状态为通知失败状态，则重发该通知；
步骤2-4:收到业务系统的接受成功响应，通知信息表中设置通知成功状态。
根据本发明优选的，所述云支付中心侧异步通知策略还包括：
策略三：重启触发通知策略，主要用于短期网络和系统因素引起订单支付状态不一致时，
步骤3-1:云支付中心支付服务重启；
步骤3-2:扫描云支付中心的通知信息表；
步骤3-3:如果表中某条异步通知的通知状态为通知失败状态，则重发该通知；
步骤3-4:收到业务系统的接受成功响应，在通知信息表中设置该异步通知的通知状态为通知成功状态。
根据本发明优选的，所述云支付中心侧异步通知策略还包括：
策略四：空闲时间定时通知策略，主要用于中长期网络和系统因素引起订单支付状态不一致时，此为保底通知策略，
步骤4-1:到达定时任务时间，通常可设置在凌晨3点，此时系统比较空闲；
步骤4-2:扫描通知信息表；
步骤4-3:如果通知信息表中某条异步通知的通知状态为通知失败状态，则重发该通知；如果收到业务系统的接受成功响应，在通知信息表中设置该异步通知的通知状态为通知成功状态；
步骤4-4:扫描云支付中心的支付记录表，所述支付记录表记录支付订单的相关数据；
步骤4-5:对于尚未收到二/三方支付平台异步通知的支付记录，则向二/三方支付平台发送支付状态查询请求：
如果二/三方支付平台的查询响应信息明确支付流程已结束，即支付成功或支付失败，则向业务系统补发通知，收到业务系统的接受成功响应后，通知信息表中对应异步通知的通知状态设置通知成功状态。
根据本发明优选的，所述业务系统侧同步查询策略还包括：
策略六：事件触发查询策略，用于中长期网络和系统因素引起订单支付状态不一致时，
步骤6-1：由支付状态的重要支付事件触发，如订单超时（未支付成功将取消订单）、分账触发（有未完成的退款将不能触发分账）等；
步骤6-2：扫描支付请求记录表；
步骤6-3：如果表中有相关记录，所述相关记录是指与具体业务有关的记录，如支付订单超时时对应订单的支付请求记录，分账执行前分账订单对应的售后订单的支付请求记录等，且处于进行中状态，则重发订单支付结果的查询请求；
步骤6-4：如果收到支付中心的查询响应结果，支付请求记录表中相应的支付请求记录的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作，所述后处理操作包括修改订单状态、添加操作日志、修改用户权益，比如用户积分、用户优惠券、用户等级。
根据本发明优选的，所述业务系统侧同步查询策略还包括：
策略七：重启触发查询策略，主要用于短期网络和系统因素引起订单支付状态不一致时，
步骤7-1：业务系统重启；
步骤7-2:扫描业务系统支付适配服务的支付请求记录表；
步骤7-3:如果表中某条支付请求记录的执行状态为进行中状态，则重发对应支付结果的查询请求；
步骤7-4：如果收到支付中心的查询响应结果，支付请求记录表中相应的支付请求记录的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作。
上述七个策略中，所述策略一、策略二、策略三、策略四用于支付中心侧支付结果的异步通知，所述策略五、策略六、策略七用于业务系统侧支付结果的同步查询。在实际使用过程中并非七个策略都要使用，可根据支付的实际情况和各个策略的特点选择对应的策略进行组合。
所述云支付中心侧异步通知策略中，策略一是基础策略，所有的策略组合必须包括策略一；策略四是定时策略，可作为保底策略，能够有效应对中长期因素导致的支付状态不一致的情况，而且在系统较空闲的时间启动运行，对系统的影响较小，一般也推荐使用；策略二、三是事件触发策略，可根据现有策略组合的使用效果灵活选用。
所述业务系统侧同步查询策略中，策略五通常与策略一配套使用，因此一般会选用；策略六、策略七，可根据业务要求、资源情况并结合当前策略组合使用效果灵活选用。
根据本发明优选的，所述基于云支付中心实现订单支付状态高一致性的方法，还包括确定消息的首次发送时机与重发间隔的方法，包括：通过业务系统接收多次回调时间间隔的观测值估计；
对于云支付中心侧的策略二、三、四等三个策略和业务系统侧的策略六、七等两个策略，它们的首次发送时机是由定时任务或系统事件触发确定的，而且只发送一次无需确定重发间隔；而云支付中心侧的策略一，能够确定首次发送时机，但是由于云支付中心需要适配不同类型的业务系统，很难找到一个普适的重发间隔，因此通常采用经验值，所以上述策略中，只有策略五需要确定首次发送时机和重发间隔，从而与策略一相匹配；
通常情况下，由于云支付中心是专门开发和部署的，因此在针对支付业务进行优化和加固后，出现异常的概率较低；当连续两次异步通知都没有被接收到的时候，认为发生了异常，大概率是业务系统侧造成的，此时启动短期重试查询策略，即业务系统侧策略五，用以解决可能发生的短期异常是合理的；
设随机变量X为业务系统成功发出支付请求后收到支付中心第二次异步通知的时间间隔，其单位为秒，首次通知因故丢失，；通过一组回调时间间隔的观测值，利用点估计求解/>的估计值；
根据准则：
若随机变量，/>的观测值以99.7%的概率落入/>的区间中，因此，在发出请求/>秒后仍然没有收到云支付中心的异步通知，则认为有异常情况发生，即向支付中心询问订单的支付状态；基于以上分析，取/>作为首次发送查询的时间；
和/>分别为/>的点估计值，其计算公式如公式(1)和公式(2)所示，其中为样本数据的观测值，/>为样本数：
（1）
（2）
取作为重发时间间隔，本方法还应用于：如果不明确短期故障导致未接收到支付中心回调的原因；
例：根据表1求解业务系统侧策略一的首次查询时间和重发时间间隔；
表1支付需求发出后支付结果通知到达业务系统的时间表
表1记录了业务系统在支付需求发出后收到云支付中心前两次异步通知的时间，表1中的数据是Strongpay云支付中心系统中测得的数据，测试中为了让云支付中心重发通知，会令业务系统忽略第一次收到的通知，这样超时后支付中心将基于策略一重发通知；根据Shapiro-Wilk检验，对研究总体随机变量提出以下假设，/>：总体服从正态分布；/>:总体不服从正态分布；
按照下列公式计算检验统计量 ：
（3）
在公式（3）中，为随机变量/>排序后的样本数据；/>为样本均值；/>是样本量为/>（本例为10）时所对应的系数，所述系数可查表获得，目前主流的统计工具如/>，都内置了该表，并提供了专门的函数，输入/>的值后直接获得/>值；设检验的显著程度；
通过表1中“第二次”对应列的数据计算得，W=0.91837，p-value= 0.3435>0.05，由于统计量，/>的值越大，表示数据越符合正态分布；p-value是指当原假设为真时，样本观察结果出现的概率，当其值小于指定的显著程度时则拒绝原假设；
所以，由W和p-value的值被认为样本数据符合正态分布；
根据公式(1)和公式(2)计算表1中第二次时间的和/>分别为53和1.3，因此可取1分钟作为首次发送查询的时间，取3秒作为重试时间间隔。
根据本发明优选的，所述确定消息的首次发送时机与重发间隔的方法中，通过短期故障恢复时间间隔的观测值估计。
根据本发明优选的，通过短期故障恢复时间间隔的观测值估计的方法，包括：
通过短期故障恢复的时间间隔的观测值估计首次查询时间和重发时间间隔，如前文所述，由于支付中心稳定性高，网络数据包丢失大概率是业务系统端发生网络拥塞造成的，如果通过监测发现，发生网络拥塞是短期故障，如秒杀活动，则设随机变量Y为短期故障造成网络拥塞恢复的时间间隔，设，在故障发生时进行数据采集获取/>的观测值，然后将/>作为首次发送查询的时间；
和/>分别为/>的点估计值，其中/>为随机变量/>样本数据的观测值，为样本数：
（4）
（5）
取作为重发时间间隔。
一种实现上述方法的系统，其特征在于，包括，业务系统、云支付中心和二/三方支付平台；
所述业务系统是有支付需求的、用于处理实际业务的信息系统，例如电子商务系统等；
所述云支付中心，是独立部署在云上的，为客户提供可共享支付服务的信息系统；
所述二/三方支付平台，具有独立的支付许可牌照，为用户提供实际支付服务的支付平台，典型的二方支付是银行卡、银行转账支付等，典型的三方支付平台有支付宝支付、微信支付、京东支付等；
图1所示的基于云支付中心的支付流程如下，业务系统通过其支付适配服务向云支付中心发送支付请求；云支付中心接收到支付请求后，对请求用户身份进行认证，对请求参数进行检查，对于合法请求新建支付订单，并根据用户的支付配置和支付参数调用二/三方支付平台的支付服务接口提交支付请求，如果是同步请求需等待二/三方支付平台的支付结果，如果是异步调用，由指定的回调接口负责接收二/三方支付平台的支付结果通知；二/三方支付平台收到支付请求并对请求进行认证、检查后，执行实际的支付操作，并将支付结果通知云支付中心；云支付中心收到二/三方支付平台的支付结果后进行必要的后处理工作，如修改支付订单的状态、向通知信息表中添加异步通知等，然后向业务系统发送支付结果通知作为支付请求的相应；业务系统的支付适配服务接收到云支付中心的支付结果通知后，完成认证、检查后根据支付结果执行相应的后处理操作，比如修改订单状态等。
根据本发明优选的，所述业务系统包括：业务服务集合、系统服务集合和支付适配服务；
所述业务服务集合，为用户提供业务处理的服务集合，比如商城系统中的订单服务、库存服务等；
所述系统服务集合，为用户提供系统管理的服务集合，比如用户角色权限管理服务、用户菜单管理服务等；
所述支付适配服务，为了降低基于云支付中心的支付系统对业务系统的侵入性，最大程度简化业务系统适配支付的复杂性，而专门开发的服务，用于用户对接云支付中心的支付服务，所述支配适配服务提供统一的接口方便业务系统调用云支付中心的支付服务，安全快捷的完成支付操作；本文中提出的业务系统侧同步查询策略的主要逻辑都是在支付适配服务中实现的。
根据本发明优选的，所述云支付中心包括：支付服务 、运营管理服务、商户管理服务和安全认证服务。
所述支付服务，是云支付中心的核心服务，提供标准化的、对具体支付渠道透明的支付请求接入、验证、处理和响应机制；提供支付参数配置、支付订单构建与维护、支付结果查询、支付消息异步通知等功能；实现对各类常用或专用二/三方支付平台的适配。在容器化技术和分布式集群技术的支持下，通过设计实现针对性的算法和业务流程，确保各个支付环节的高性能、高可用和高并发，确保支付过程的高可靠性和支付状态的高一致性；
所述运营管理服务，采用多租户模式，为各类系统管理人员提供支付渠道、支付策略、所属商户、支付应用、用户权限等信息的管理功能。管理人员按照权限可分为系统管理员和业务系统管理员两类，前者可以管理系统内的所有信息，使用运营管理服务的所有功能，创建业务系统管理员并指定其操作权限；后者只能管理指定业务系统的各类信息；
所述商户管理服务，为指定的商户提供管理所属信息的功能。系统中的商户包括系统商户和支付商户两类，后者从属于前者。系统商户是支付中心为每个实际商户建立的数据实体，由系统管理员构建和管理，用于存储和维护商户的基本信息；而支付商户则是承担业务系统里具体支付功能的数据实体，由业务系统管理员构建和管理，从属于系统商户，用于存储和维护商户在业务系统中的基本信息和支付信息。通常业务系统中的商户需要与云支付中心内的支付商户绑定；
所述安全认证服务，为云支付中心通常采用独立部署的方式，以SaaS的形式为业务系统提供支付和相关的数据管理服务，因此必须保证网络和数据的安全，保护用户隐私。由于支付服务具有高度敏感性，通常需要综合采用多种安全认证手段保证安全。比如通过高强度的安全框架和定制开发，对支付中心各类用户进行登录认证和操作授权，确保用户不能越权操作；为每个支付用户的支付应用生成数字签名密钥，在使用该应用进行支付操作时，数据必须基于此密钥进行签名和验签；对于敏感隐私数据要密文存储，加密密钥通过专门的密钥管理系统进行管理和使用；全网应用https协议进行数据传输；采用通用的网络安全加固系统和设备增强网络安全性等。
根据本发明优选的，所述二/三方支付平台包括：支付接口服务和支付服务集合；
所述支付接口服务：二/三方支付平台提供的api接口，通过指定的URL地址，利用https协议进行调用；为了方便用户使用，二/三方支付平台提供详细的api接口文档，指定调用和返回参数的格式和语义；对于支付应用，通常会要求调用者传递支付结果通知地址，支付完成后由二/三方支付平台向该地址发送支付结果通知；
所述支付服务集合：二/三方支付平台提供的具体支付服务，一般无法从外部直接调用，而是通过支付接口服务提供的api接口进行调用。
本发明的技术优势在于：
现有方法的主要问题是只考虑到在支付中心侧采取措施提高支付状态的一致性。而真正受一致性影响的是具体业务，什么时间可以出现订单支付状态不一致的情况，什么时间订单支付状态必须一致，是由具体业务决定的，只有在业务系统侧才能解决。因此没有业务系统参与，无法真正实现订单状态的高一致性。而且由于云支付中心通常需要为多个不同类型的业务系统提供服务，难以针对某个具体的业务系统进行优化，这又进一步提高了单纯在支付中心侧解决支付状态一致性的难度。为了解决上述问题，提出双向支付状态一致性保证机制，在支付中心侧和业务系统侧同时实施支付状态一致性操作。为了更为协调与高效，支付中心侧和业务系统侧的支付状态一致性操作侧重点有所不同，支付中心侧更加侧重异步通知的可靠性，业务系统侧则更加侧重支付状态同步的时效性。同现有方法相比，本文的方法更为有效，更为适合处理云支付中心环境下订单支付状态的高一致性问题。
为此，本发明的优势在于：
1. 本发明采用双向支付状态一致性保证机制。在支付中心侧与业务系统侧同时采取多策略组合方式，异步、同步相结合，兼顾可靠性、高效性与时效性，实现云支付中心环境下订单支付状态的高一致性。
2. 本发明在业务系统侧设计专门的支付适配服务，实现与云支付中心配套的支付功能和业务系统侧的订单支付状态高一致性策略，降低对业务系统的侵入性和业务系统对接云支付中心的难度。
3. 本发明在支付请求成功发送到支付中心后，确定业务系统侧询问消息首次发送时机与重发间隔的方法。基于统计学原理和支付业务的特点，结合对实际系统采集数据的分析，设计实现了两种消息首次发送时机与重发间隔的确定方法。
附图说明
图1为典型的基于云支付中心的支付系统架构图。
具体实施方式
下面结合实施例和说明书附图对本发明做详细的说明，但不限于此。
实施例1、
一种基于云支付中心实现订单支付状态高一致性的方法，包括：云支付中心侧异步通知策略和业务系统侧同步查询策略；
所述云支付中心侧异步通知策略包括：
策略一：短期重试通知策略，用于短期网络和系统因素引起订单支付状态不一致时，
步骤1-1:收到二/三方支付平台的关于支付结果异步通知消息或者重发通知定时时间到期；
步骤1-2:云支付中心的通知信息表中没有异步通知记录时，则新建该记录：包括通知的消息内容、通知地址、通知状态和通知时间；
步骤1-3:修改通知信息表中的通知次数和时间，未达到设置的最大通知次数时，向业务系统发通知，通知业务系统支付请求的处理结果，所述最大通知次数为未收到业务系统响应时重发消息的最大次数，可由支付中心管理员根据实际情况进行配置，该配置方法并不是本发明所要保护的内容；
步骤1-3-1:收到业务系统的接受成功响应，则在通知信息表中设置通知成功状态；
步骤1-3-2:未收到业务系统的接受成功响应，则根据云支付中心预设的时间间隔向消息队列发送延迟消息，准备下一次向业务系统重发通知；
步骤1-4:达到最大通知次数时，在通知信息表中设置通知失败状态；
所述业务系统侧同步查询策略包括：
策略五：短期重试查询策略，用于短期网络和系统因素引起订单支付状态不一致时，
步骤5-1:成功向支付中心发送支付请求后延迟时间到期或重发查询请求的定时时间到期；
步骤5-2:成功发送支付请求后在业务系统支付适配服务的支付请求记录表中记录此次请求，包括订单号、请求类型、请求时间、执行状态和执行次数；
步骤5-3:每次发送请求后更新支付请求记录表中的执行次数和本次请求时间，未达到设置的最大执行次数，则向支付中心发送支付状态查询请求；
步骤5-3-1：收到支付中心的查询响应结果，支付请求记录表中对应支付请求的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作，所述后处理操作包括修改订单状态、添加操作日志、修改用户权益，比如用户积分、用户优惠券、用户等级；
步骤5-3-2：未收到支付中心的查询响应结果，根据时间间隔向消息队列发送延迟消息，准备下一次重发查询，执行步骤步骤5-1至步骤5-3；
步骤5-4：达到最大重发次数时，则在支付请求记录表中设置查询失败状态。
实施例2、
如实施例1所述一种基于云支付中心实现订单支付状态高一致性的方法，所述云支付中心侧异步通知策略还包括：
策略二：事件触发通知策略，用于中长期网络和系统因素引起订单支付状态不一致时，
步骤2-1:向业务系统成功发送异步消息通知；
步骤2-2:扫描云支付中心的通知信息表；
步骤2-3:如果通知信息表中记录的某条异步通知的通知地址与步骤2-1中通知地址属于同一业务系统，且通知状态为通知失败状态，则重发该通知；
步骤2-4:收到业务系统的接受成功响应，通知信息表中设置通知成功状态。
实施例3、
如实施例1所述一种基于云支付中心实现订单支付状态高一致性的方法，所述云支付中心侧异步通知策略还包括：
策略三：重启触发通知策略，主要用于短期网络和系统因素引起订单支付状态不一致时，
步骤3-1:云支付中心支付服务重启；
步骤3-2:扫描云支付中心的通知信息表；
步骤3-3:如果表中某条异步通知的通知状态为通知失败状态，则重发该通知；
步骤3-4:收到业务系统的接受成功响应，在通知信息表中设置该异步通知的通知状态为通知成功状态。
实施例4、
如实施例1所述一种基于云支付中心实现订单支付状态高一致性的方法，所述云支付中心侧异步通知策略还包括：
策略四：空闲时间定时通知策略，主要用于中长期网络和系统因素引起订单支付状态不一致时，此为保底通知策略，
步骤4-1:到达定时任务时间，通常可设置在凌晨3点，此时系统比较空闲；
步骤4-2:扫描通知信息表；
步骤4-3:如果通知信息表中某条异步通知的通知状态为通知失败状态，则重发该通知；如果收到业务系统的接受成功响应，在通知信息表中设置该异步通知的通知状态为通知成功状态；
步骤4-4:扫描云支付中心的支付记录表，所述支付记录表记录支付订单的相关数据；
步骤4-5:对于尚未收到二/三方支付平台异步通知的支付记录，则向二/三方支付平台发送支付状态查询请求：
如果二/三方支付平台的查询响应信息明确支付流程已结束，即支付成功或支付失败，则向业务系统补发通知，收到业务系统的接受成功响应后，通知信息表中对应异步通知的通知状态设置通知成功状态。
实施例5、
如实施例1所述一种基于云支付中心实现订单支付状态高一致性的方法，所述业务系统侧同步查询策略还包括：
策略六：事件触发查询策略，用于中长期网络和系统因素引起订单支付状态不一致时，
步骤6-1：由支付状态的重要支付事件触发，如订单超时（未支付成功将取消订单）、分账触发（有未完成的退款将不能触发分账）等；
步骤6-2：扫描支付请求记录表；
步骤6-3：如果表中有相关记录，所述相关记录是指与具体业务有关的记录，如支付订单超时时对应订单的支付请求记录，分账执行前分账订单对应的售后订单的支付请求记录等，且处于进行中状态，则重发订单支付结果的查询请求；
步骤6-4：如果收到支付中心的查询响应结果，支付请求记录表中相应的支付请求记录的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作，所述后处理操作包括修改订单状态、添加操作日志、修改用户权益，比如用户积分、用户优惠券、用户等级。
实施例6、
如实施例1所述一种基于云支付中心实现订单支付状态高一致性的方法，所述业务系统侧同步查询策略还包括：
策略七：重启触发查询策略，主要用于短期网络和系统因素引起订单支付状态不一致时，
步骤7-1：业务系统重启；
步骤7-2:扫描业务系统支付适配服务的支付请求记录表；
步骤7-3:如果表中某条支付请求记录的执行状态为进行中状态，则重发对应支付结果的查询请求；
步骤7-4：如果收到支付中心的查询响应结果，支付请求记录表中相应的支付请求记录的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作。
实施例7、
如实施例1-6所述一种基于云支付中心实现订单支付状态高一致性的方法，还包括确定消息的首次发送时机与重发间隔的方法，包括：通过业务系统接收多次回调时间间隔的观测值估计；
设随机变量X为业务系统成功发出支付请求后收到支付中心第二次异步通知的时间间隔，其单位为秒，首次通知因故丢失，；通过一组回调时间间隔的观测值，利用点估计求解/>的估计值；
根据准则：
若随机变量，/>的观测值以99.7%的概率落入/>的区间中，因此，在发出请求/>秒后仍然没有收到云支付中心的异步通知，则认为有异常情况发生，即向支付中心询问订单的支付状态；基于以上分析，取/>作为首次发送查询的时间；
和/>分别为/>的点估计值，其计算公式如公式(1)和公式(2)所示，其中为样本数据的观测值，/>为样本数：/>
（1）
（2）
取作为重发时间间隔，本方法还应用于：如果不明确短期故障导致未接收到支付中心回调的原因；
例：根据表1求解业务系统侧策略一的首次查询时间和重发时间间隔；
表1支付需求发出后支付结果通知到达业务系统的时间表
表1记录了业务系统在支付需求发出后收到云支付中心前两次异步通知的时间，表1中的数据是Strongpay云支付中心系统中测得的数据，测试中为了让云支付中心重发通知，会令业务系统忽略第一次收到的通知，这样超时后支付中心将基于策略一重发通知；根据Shapiro-Wilk检验，对研究总体随机变量提出以下假设，/>：总体服从正态分布；/>:总体不服从正态分布；
按照下列公式计算检验统计量 ：
（3）
在公式（3）中，为随机变量/>排序后的样本数据；/>为样本均值；/>是样本量为/>（本例为10）时所对应的系数，所述系数可查表获得，目前主流的统计工具如/>，都内置了该表，并提供了专门的函数，输入/>的值后直接获得/>值；设检验的显著程度；
通过表1中“第二次”对应列的数据计算得，W=0.91837，p-value= 0.3435>0.05，由于统计量，/>的值越大，表示数据越符合正态分布；p-value是指当原假设为真时，样本观察结果出现的概率，当其值小于指定的显著程度时则拒绝原假设；
所以，由W和p-value的值被认为样本数据符合正态分布；
根据公式(1)和公式(2)计算表1中第二次时间的和/>分别为53和1.3，因此可取1分钟作为首次发送查询的时间，取3秒作为重试时间间隔。
实施例8、
如实施例1-6所述一种基于云支付中心实现订单支付状态高一致性的方法，所述确定消息的首次发送时机与重发间隔的方法中，通过短期故障恢复时间间隔的观测值估计，包括：
通过短期故障恢复的时间间隔的观测值估计首次查询时间和重发时间间隔，如前文所述，由于支付中心稳定性高，网络数据包丢失大概率是业务系统端发生网络拥塞造成的，如果通过监测发现，发生网络拥塞是短期故障，如秒杀活动，则设随机变量为短期故障造成网络拥塞恢复的时间间隔，设/>，在故障发生时进行数据采集获取/>的观测值，然后将/>作为首次发送查询的时间；
和/>分别为/>的点估计值，其中/>为随机变量/>样本数据的观测值，为样本数：
（4）
（5）
取作为重发时间间隔。
实施例9、
一种实现如实施例1-8所述一种基于云支付中心实现订单支付状态高一致性的方法的系统，包括，业务系统、云支付中心和二/三方支付平台；
所述业务系统是有支付需求的、用于处理实际业务的信息系统，例如电子商务系统等；
所述云支付中心，是独立部署在云上的，为客户提供可共享支付服务的信息系统；
所述二/三方支付平台，具有独立的支付许可牌照，为用户提供实际支付服务的支付平台，典型的二方支付是银行卡、银行转账支付等，典型的三方支付平台有支付宝支付、微信支付、京东支付等；
图1所示的基于云支付中心的支付流程如下，业务系统通过其支付适配服务向云支付中心发送支付请求；云支付中心接收到支付请求后，对请求用户身份进行认证，对请求参数进行检查，对于合法请求新建支付订单，并根据用户的支付配置和支付参数调用二/三方支付平台的支付服务接口提交支付请求，如果是同步请求需等待二/三方支付平台的支付结果，如果是异步调用，由指定的回调接口负责接收二/三方支付平台的支付结果通知；二/三方支付平台收到支付请求并对请求进行认证、检查后，执行实际的支付操作，并将支付结果通知云支付中心；云支付中心收到二/三方支付平台的支付结果后进行必要的后处理工作，如修改支付订单的状态、向通知信息表中添加异步通知等，然后向业务系统发送支付结果通知作为支付请求的相应；业务系统的支付适配服务接收到云支付中心的支付结果通知后，完成认证、检查后根据支付结果执行相应的后处理操作，比如修改订单状态等。
所述业务系统包括：业务服务集合、系统服务集合和支付适配服务；
所述业务服务集合，为用户提供业务处理的服务集合，比如商城系统中的订单服务、库存服务等；
所述系统服务集合，为用户提供系统管理的服务集合，比如用户角色权限管理服务、用户菜单管理服务等；
所述支付适配服务，为了降低基于云支付中心的支付系统对业务系统的侵入性，最大程度简化业务系统适配支付的复杂性，而专门开发的服务，用于用户对接云支付中心的支付服务，所述支配适配服务提供统一的接口方便业务系统调用云支付中心的支付服务，安全快捷的完成支付操作；本文中提出的业务系统侧同步查询策略的主要逻辑都是在支付适配服务中实现的。
所述云支付中心包括：支付服务 、运营管理服务、商户管理服务和安全认证服务。
所述支付服务，是云支付中心的核心服务，提供标准化的、对具体支付渠道透明的支付请求接入、验证、处理和响应机制；提供支付参数配置、支付订单构建与维护、支付结果查询、支付消息异步通知等功能；实现对各类常用或专用二/三方支付平台的适配。在容器化技术和分布式集群技术的支持下，通过设计实现针对性的算法和业务流程，确保各个支付环节的高性能、高可用和高并发，确保支付过程的高可靠性和支付状态的高一致性；
所述运营管理服务，采用多租户模式，为各类系统管理人员提供支付渠道、支付策略、所属商户、支付应用、用户权限等信息的管理功能。管理人员按照权限可分为系统管理员和业务系统管理员两类，前者可以管理系统内的所有信息，使用运营管理服务的所有功能，创建业务系统管理员并指定其操作权限；后者只能管理指定业务系统的各类信息；
所述商户管理服务，为指定的商户提供管理所属信息的功能。系统中的商户包括系统商户和支付商户两类，后者从属于前者。系统商户是支付中心为每个实际商户建立的数据实体，由系统管理员构建和管理，用于存储和维护商户的基本信息；而支付商户则是承担业务系统里具体支付功能的数据实体，由业务系统管理员构建和管理，从属于系统商户，用于存储和维护商户在业务系统中的基本信息和支付信息。通常业务系统中的商户需要与云支付中心内的支付商户绑定；
所述安全认证服务，为云支付中心通常采用独立部署的方式，以SaaS的形式为业务系统提供支付和相关的数据管理服务，因此必须保证网络和数据的安全，保护用户隐私。由于支付服务具有高度敏感性，通常需要综合采用多种安全认证手段保证安全。比如通过高强度的安全框架和定制开发，对支付中心各类用户进行登录认证和操作授权，确保用户不能越权操作；为每个支付用户的支付应用生成数字签名密钥，在使用该应用进行支付操作时，数据必须基于此密钥进行签名和验签；对于敏感隐私数据要密文存储，加密密钥通过专门的密钥管理系统进行管理和使用；全网应用https协议进行数据传输；采用通用的网络安全加固系统和设备增强网络安全性等。
所述二/三方支付平台包括：支付接口服务和支付服务集合；
所述支付接口服务：二/三方支付平台提供的api接口，通过指定的URL地址，利用https协议进行调用；为了方便用户使用，二/三方支付平台提供详细的api接口文档，指定调用和返回参数的格式和语义；对于支付应用，通常会要求调用者传递支付结果通知地址，支付完成后由二/三方支付平台向该地址发送支付结果通知；
所述支付服务集合：二/三方支付平台提供的具体支付服务，一般无法从外部直接调用，而是通过支付接口服务提供的api接口进行调用。
由图1可见，云支付中心代替了传统的支付服务模块成为支付平台向业务系统提供支付服务的代理，通过云支付中心实现了业务系统支付请求和支付平台支付服务的解耦，屏蔽不同支付平台支付细节上的差异，同时依托支付中心提供的丰富稳定的支付渠道，可以快捷灵活地为业务系统提供或变更支付平台，从而快速形成支付能力。云支付中心通常采用SaaS化方式为用户提供服务，除了提供支付服务外，还提供运营管理、商户管理、安全认证管理等服务，通过使用云支付中心提供的各类管理服务功能可以对商户信息、支付元信息、支付订单信息、支付通知信息等进行管理维护。云支付中心针对性地对支付的关键环节进行优化，可以满足业务系统对支付服务高性能、高可用、高并发的需求。通过使用云支付中心提供的专业和高质量的支付服务和其他相关服务，业务系统在大大简化支付开发、测试和交付工作的同时，无需关注用于支付业务优化的软件算法和硬件设施的开发与建设，从而显著降低资源采购、系统部署和运维的成本。下面对云支付中心的主要服务做简要介绍。
表2 支付请求发送后采用不同策略达到订单支付状态一致性的时间
表2为在实际系统中模拟业务系统所在网络发生拥塞时，业务系统支付请求发出后，业务系统与云支付中心对应订单支付状态达到一致的时间。
实验中业务系统为商城系统，云支付中心和商城系统均采用spring cloud微服务方式进行容器化部署（docker swarm平台），每个服务启动一个容器实例，数据库采用mysql，缓存采用redis，消息队列使用rabbitmq，服务注册与配置管理采用nacos，web服务器采用nginx。云服务器配置，8核处理器，8G内存，10兆共享带宽，CentOS 7操作系统，java虚拟机采用jdk11。
网络拥塞模拟使用jmeter系统，使用5台电脑，每台启动2000个线程共10000个线程，模拟10000用户并发访问，然后通过网页客户端进行商品的下单支付。
表2中对比了四种策略及策略组合，由于策略比较多，这里选择了通常必须使用的策略一、策略五以及它们的组合进行对比，用以说明双向一致性保证机机制的有效性和实效性，对比的策略分别是：
1）无措施，即不采用本专利提出的任何策略，云支付中心只向业务系统发送1次支付结果通知。
2）策略五，即在商城端使用策略五进行查询，首次查询时间为1分钟，后每隔2s查询一次，共查询3次，而云支付中心端不使用任何一致性保证策略，只发一次支付结果通知。
3）策略一，即在支付中心端采用策略一重发通知，发送时间分别为0秒、50秒、100秒、150秒、200秒、250秒，最多发送6次，在商城端不采取任何措施。
4）策略一+策略五，即在支付中心端采用策略一重发同时，发送时间分别为0秒、50秒、100秒、150秒、200秒、250秒，最多发送6次，在商城端在商城端使用策略五进行查询，首次查询时间为1分钟，后每隔2s查询一次，共查询3次。
每个方法进行10组测试，由表2可见，采用“无措施”方法时10次中有3次无法达到支付状态的最终一致，采用“策略五”方法10次中有1次无法达到支付状态的最终一致，上述情况在支付系统中时不能被允许的。
而在使用“策略一”和“策略一+策略五”两种方法时，所有10次支付请求最终都实现了支付状态的一致，但是前者用时比后者多22%，显示本专利提出的双向一致性保证机制具有较高的有效性和实效性。当然在极端的情况下，所有表2中的方法都有可能出现最终结果不一致的情况，但通过与本文提出的其他策略进行组合使用，可以将不一致发生的概率降到级小，可能在整个软件的生命周期中都不会出现，即便出现一次也可以通过人工处理的手段解决，云支付中心中提供了相应的人工保底手段。

Claims (8)

1.一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，包括：云支付中心侧异步通知策略和业务系统侧同步查询策略；
所述云支付中心侧异步通知策略包括：
策略一：短期重试通知策略，
步骤1-1:收到二/三方支付平台的关于支付结果异步通知消息或者重发通知定时时间到期；
步骤1-2:云支付中心的通知信息表中没有异步通知记录时，则新建该记录：包括通知的消息内容、通知地址、通知状态和通知时间；
步骤1-3:修改通知信息表中的通知次数和时间，未达到设置的最大通知次数时，向业务系统发通知，通知业务系统支付请求的处理结果；
步骤1-3-1:收到业务系统的接受成功响应，则在通知信息表中设置通知成功状态；
步骤1-3-2:未收到业务系统的接受成功响应，则根据云支付中心预设的时间间隔向消息队列发送延迟消息，准备下一次向业务系统重发通知；
步骤1-4:达到最大通知次数时，在通知信息表中设置通知失败状态；
所述业务系统侧同步查询策略包括：
策略五：短期重试查询策略，
步骤5-1:成功向支付中心发送支付请求后延迟时间到期或重发查询请求的定时时间到期；
步骤5-2:成功发送支付请求后在业务系统支付适配服务的支付请求记录表中记录此次请求，包括订单号、请求类型、请求时间、执行状态和执行次数；
步骤5-3:每次发送请求后更新支付请求记录表中的执行次数和本次请求时间，未达到设置的最大执行次数，则向支付中心发送支付状态查询请求；
步骤5-3-1：收到支付中心的查询响应结果，支付请求记录表中对应支付请求的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作；
步骤5-3-2：未收到支付中心的查询响应结果，根据时间间隔向消息队列发送延迟消息，准备下一次重发查询，执行步骤5-1至步骤5-3；
步骤5-4：达到最大重发次数时，则在支付请求记录表中设置查询失败状态；
所述基于云支付中心实现订单支付状态高一致性的方法，还包括确定消息的首次发送时机与重发间隔的方法，包括：通过业务系统接收多次回调时间间隔的观测值估计；
设随机变量X为业务系统成功发出支付请求后收到支付中心第二次异步通知的时间间隔，其单位为秒，首次通知因故丢失，；通过一组回调时间间隔的观测值，利用点估计求解/>的估计值；
根据准则：
若随机变量，/>的观测值以99.7%的概率落入/>的区间中，因此，在发出请求/>秒后仍然没有收到云支付中心的异步通知，则认为有异常情况发生，即向支付中心询问订单的支付状态；取/>作为首次发送查询的时间；
和/>分别为/>的点估计值，其计算公式如公式(1)和公式(2)所示，其中/>为样本数据的观测值，/>为样本数：
（1）
（2）
取作为重发时间间隔；
所述确定消息的首次发送时机与重发间隔的方法中，通过短期故障恢复时间间隔的观测值估计，包括：
通过短期故障恢复的时间间隔的观测值估计首次查询时间和重发时间间隔，如果通过监测发现，发生网络拥塞是短期故障，则设随机变量为短期故障造成网络拥塞恢复的时间间隔，设/>，在故障发生时进行数据采集获取/>的观测值，然后将/>作为首次发送查询的时间；
和/>分别为/>的点估计值，其中/>为随机变量/>样本数据的观测值，/>为样本数：
（4）
（5）
取作为重发时间间隔。
2.根据权利要求1所述一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，所述云支付中心侧异步通知策略还包括：
策略二：事件触发通知策略，
步骤2-1:向业务系统成功发送异步消息通知；
步骤2-2:扫描云支付中心的通知信息表；
步骤2-3:如果通知信息表中记录的某条异步通知的通知地址与步骤2-1中通知地址属于同一业务系统，且通知状态为通知失败状态，则重发该通知；
步骤2-4:收到业务系统的接受成功响应，通知信息表中设置通知成功状态。
3.根据权利要求1所述一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，所述云支付中心侧异步通知策略还包括：
策略三：重启触发通知策略，
步骤3-1:云支付中心支付服务重启；
步骤3-2:扫描云支付中心的通知信息表；
步骤3-3:如果表中某条异步通知的通知状态为通知失败状态，则重发该通知；
步骤3-4:收到业务系统的接受成功响应，在通知信息表中设置该异步通知的通知状态为通知成功状态。
4.根据权利要求1所述一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，所述云支付中心侧异步通知策略还包括：
策略四：空闲时间定时通知策略，
步骤4-1:到达定时任务时间；
步骤4-2:扫描通知信息表；
步骤4-3:如果通知信息表中某条异步通知的通知状态为通知失败状态，则重发该通知；如果收到业务系统的接受成功响应，在通知信息表中设置该异步通知的通知状态为通知成功状态；
步骤4-4:扫描云支付中心的支付记录表；
步骤4-5:对于尚未收到二/三方支付平台异步通知的支付记录，则向二/三方支付平台发送支付状态查询请求：
如果二/三方支付平台的查询响应信息明确支付流程已结束，即支付成功或支付失败，则向业务系统补发通知，收到业务系统的接受成功响应后，通知信息表中对应异步通知的通知状态设置通知成功状态。
5.根据权利要求1所述一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，所述业务系统侧同步查询策略还包括：
策略六：事件触发查询策略，
步骤6-1：由支付状态的重要支付事件触发；
步骤6-2：扫描支付请求记录表；
步骤6-3：如果表中有相关记录，且处于进行中状态，则重发订单支付结果的查询请求；
步骤6-4：如果收到支付中心的查询响应结果，支付请求记录表中相应的支付请求记录的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作。
6.根据权利要求1所述一种基于云支付中心实现订单支付状态高一致性的方法，其特征在于，所述业务系统侧同步查询策略还包括：
策略七：重启触发查询策略，
步骤7-1：业务系统重启；
步骤7-2:扫描业务系统支付适配服务的支付请求记录表；
步骤7-3:如果表中某条支付请求记录的执行状态为进行中状态，则重发对应支付结果的查询请求；
步骤7-4：如果收到支付中心的查询响应结果，支付请求记录表中相应的支付请求记录的执行状态设置查询成功状态，根据响应数据中的订单支付状态进行相应的后处理操作。
7.一种实现如权利要求1-6任意一项所述方法的系统，其特征在于，包括，业务系统、云支付中心和二/三方支付平台；
所述业务系统是有支付需求的、用于处理实际业务的信息系统；
所述云支付中心，是独立部署在云上的，为客户提供可共享支付服务的信息系统；
所述二/三方支付平台，具有独立的支付许可牌照，为用户提供实际支付服务的支付平台。
8.如权利要求7所述的系统，其特征在于，
所述业务系统包括：业务服务集合、系统服务集合和支付适配服务；
所述业务服务集合，为用户提供业务处理的服务集合；
所述系统服务集合，为用户提供系统管理的服务集合；
所述支付适配服务，用于用户对接云支付中心的支付服务；
所述云支付中心包括：支付服务 、运营管理服务、商户管理服务和安全认证服务；
所述二/三方支付平台包括：支付接口服务和支付服务集合；
所述支付接口服务：二/三方支付平台提供的api接口，通过指定的URL地址，利用https协议进行调用；二/三方支付平台提供详细的api接口文档，指定调用和返回参数的格式和语义；对于支付应用，要求调用者传递支付结果通知地址，支付完成后由二/三方支付平台向该地址发送支付结果通知；
所述支付服务集合：二/三方支付平台提供的具体支付服务，通过支付接口服务提供的api接口进行调用。
CN202310653912.8A 2023-06-05 2023-06-05 基于云支付中心实现订单支付状态高一致性的方法与系统 Active CN116384993B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310653912.8A CN116384993B (zh) 2023-06-05 2023-06-05 基于云支付中心实现订单支付状态高一致性的方法与系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310653912.8A CN116384993B (zh) 2023-06-05 2023-06-05 基于云支付中心实现订单支付状态高一致性的方法与系统

Publications (2)

Publication Number Publication Date
CN116384993A CN116384993A (zh) 2023-07-04
CN116384993B true CN116384993B (zh) 2023-08-22

Family

ID=86971657

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310653912.8A Active CN116384993B (zh) 2023-06-05 2023-06-05 基于云支付中心实现订单支付状态高一致性的方法与系统

Country Status (1)

Country Link
CN (1) CN116384993B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116737395A (zh) * 2023-08-14 2023-09-12 北京海科融通支付服务有限公司 一种异步信息处理系统及方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110335029A (zh) * 2019-06-26 2019-10-15 中通服创发科技有限责任公司 统一支付网关、方法和系统
WO2019196244A1 (zh) * 2018-04-10 2019-10-17 平安科技（深圳）有限公司 实时回调订单的方法和系统
CN110706071A (zh) * 2019-09-25 2020-01-17 口碑(上海)信息技术有限公司 订单支付请求的异常处理方法、设备、服务器及系统
CN110941625A (zh) * 2019-11-27 2020-03-31 江苏满运软件科技有限公司 支付一致性校验方法、系统、设备及存储介质
CN112464069A (zh) * 2020-11-16 2021-03-09 银盛支付服务股份有限公司 一种支付超时补偿机制实现方法
CN115271694A (zh) * 2022-07-29 2022-11-01 江苏银承网络科技股份有限公司 订单支付方法及系统
CN115456622A (zh) * 2022-07-19 2022-12-09 汇通数科智能科技有限公司 基于第三方支付渠道b2c电商订单合并支付的处理方法
CN115562898A (zh) * 2022-09-27 2023-01-03 中国银行股份有限公司 分布式支付系统异常处理方法及装置
CN116128491A (zh) * 2022-12-19 2023-05-16 上海商米科技集团股份有限公司 支付信息确定方法、装置、系统和电子设备

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8566193B2 (en) * 2006-08-11 2013-10-22 Sap Ag Consistent set of interfaces derived from a business object model

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019196244A1 (zh) * 2018-04-10 2019-10-17 平安科技（深圳）有限公司 实时回调订单的方法和系统
CN110335029A (zh) * 2019-06-26 2019-10-15 中通服创发科技有限责任公司 统一支付网关、方法和系统
CN110706071A (zh) * 2019-09-25 2020-01-17 口碑(上海)信息技术有限公司 订单支付请求的异常处理方法、设备、服务器及系统
CN110941625A (zh) * 2019-11-27 2020-03-31 江苏满运软件科技有限公司 支付一致性校验方法、系统、设备及存储介质
CN112464069A (zh) * 2020-11-16 2021-03-09 银盛支付服务股份有限公司 一种支付超时补偿机制实现方法
CN115456622A (zh) * 2022-07-19 2022-12-09 汇通数科智能科技有限公司 基于第三方支付渠道b2c电商订单合并支付的处理方法
CN115271694A (zh) * 2022-07-29 2022-11-01 江苏银承网络科技股份有限公司 订单支付方法及系统
CN115562898A (zh) * 2022-09-27 2023-01-03 中国银行股份有限公司 分布式支付系统异常处理方法及装置
CN116128491A (zh) * 2022-12-19 2023-05-16 上海商米科技集团股份有限公司 支付信息确定方法、装置、系统和电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PetroBlock: A Blockchain-Based Payment Mechanism for Fueling Smart Vehicles;Faisal Jamil等;Applied Sciences;第11卷;1-24 *

Also Published As

Publication number Publication date
CN116384993A (zh) 2023-07-04

Similar Documents

Publication Publication Date Title
US11966916B2 (en) Resource transfer method and apparatus, storage medium, and computer device
CN112330326B (zh) 一种应用于银行交易区块链系统的业务处理方法和装置
CN103782574B (zh) 用于数据库事务的幂等性
CN109901949B (zh) 双活数据中心的应用灾备系统及方法
CN110647580A (zh) 分布式容器集群镜像管理主节点、从节点、系统及方法
US20220084031A1 (en) Backend architecture method and system for aggregate payment, computer device, and storage medium
JP6218979B1 (ja) ブロックチェーンを利用した金融取引方法およびシステム
CN101753374A (zh) 服务器对服务器的完整性检查
CN111770102A (zh) 一种区块链跨链方法、装置、计算机设备及存储介质
CN111245900B (zh) 一种分布式消息发送的处理系统及其处理方法
CN106911648B (zh) 一种环境隔离方法及设备
CN116384993B (zh) 基于云支付中心实现订单支付状态高一致性的方法与系统
US20140089156A1 (en) Addresses in financial systems
US20230052935A1 (en) Asynchronous accounting method and apparatus for blockchain, medium and electronic device
WO2012171349A1 (zh) 一种分布式自增计数的实现方法、装置及系统
CN112446786A (zh) 一种异常交易处理方法、装置、电子设备和可读存储介质
CN111311254A (zh) 一种基于区块链的业务处理方法、装置和系统
CN111563124A (zh) 基于区块链的作业处理方法、装置及系统
US11765058B2 (en) Extensible, secure and efficient monitoring and diagnostic pipeline for hybrid cloud architecture
CN115643271A (zh) 一种云上多应用数据同步方法、装置、服务器及介质
CN115271694A (zh) 订单支付方法及系统
US11582345B2 (en) Context data management interface for contact center
CN109784709A (zh) 企业信息化协作应用方法及系统
CN111695901A (zh) 账务凭证处理方法、装置、设备及存储介质
CN113448931B (zh) 数据处理方法、业务交易平台及业务提供平台

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant