CN111833034A - 一种批量扣款方法、支付服务器、计算机设备及存储介质 - Google Patents

一种批量扣款方法、支付服务器、计算机设备及存储介质 Download PDF

Info

Publication number
CN111833034A
CN111833034A CN202010626436.7A CN202010626436A CN111833034A CN 111833034 A CN111833034 A CN 111833034A CN 202010626436 A CN202010626436 A CN 202010626436A CN 111833034 A CN111833034 A CN 111833034A
Authority
CN
China
Prior art keywords
deduction
payment
batch
deduction request
request
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.)
Granted
Application number
CN202010626436.7A
Other languages
English (en)
Other versions
CN111833034B (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.)
Taikang Insurance Group Co Ltd
Taikang Online Property Insurance Co Ltd
Original Assignee
Taikang Insurance Group Co Ltd
Taikang Online Property Insurance 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 Taikang Insurance Group Co Ltd, Taikang Online Property Insurance Co Ltd filed Critical Taikang Insurance Group Co Ltd
Priority to CN202010626436.7A priority Critical patent/CN111833034B/zh
Publication of CN111833034A publication Critical patent/CN111833034A/zh
Application granted granted Critical
Publication of CN111833034B publication Critical patent/CN111833034B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • 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
    • G06Q20/3825—Use of electronic signatures
    • 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本文涉及网络通信技术领域，尤其涉及一种批量扣款方法、支付服务器、计算机设备及存储介质。为了解决现有技术中高并发的批量扣款容易发生错误的问题，本文实施例的方法接收来自不同业务服务器发送来的批量扣款请求报文；生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格；当扣款请求的锁状态位不为锁定状态且支付状态不为完成支付状态，则修改所述扣款请求的锁状态位为锁定状态；执行锁定状态的扣款请求，完成扣款，并修改所述扣款请求的支付状态为完成支付状态。利用本文实施例，不会在高并发扣款应用时发生扣款请求重复执行造成业务失败或者用户账户数据错误的问题。

Description

一种批量扣款方法、支付服务器、计算机设备及存储介质
技术领域
本文涉及网络通信技术领域，尤其涉及一种批量扣款方法、支付服务器、计算机设备及存储介质。
背景技术
在现有保险缴费业务中，定期投资(定投)和自动续期业务由于其操作方便，避免用户忘记缴费期限而造成保险失效等问题的发生，越来越受到用户的喜爱，其中自动续期业务是指通过银行账户或微信、支付宝免等密支付完成自动缴费的业务。
现有技术中定投和自动续期业务于每月定时或者固定日期统一发起对用户指定的账户扣款，例如，统一从用户留存的银行卡账户，或者首期支付与微信签约账户中发起扣款，每批扣款申请中订单数量较多，不能采用单笔订单提交支付。在这种大批量扣款业务过程中极有可能出现重复提交请求，重复扣款的问题，这是现有技术亟需解决的问题。
发明内容
为解决现有技术中的问题，本文实施例提供了一种批量扣款方法、支付服务器、计算机设备及存储介质，用于解决现有技术中高并发的批量扣款容易发生错误的问题。
本文提供了一种批量扣款方法，包括，
接收来自不同业务服务器发送来的批量扣款请求报文；
生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格；
判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态；
当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态；
执行锁定状态的扣款请求，完成扣款，修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态。
本文还提供了一种支付服务器，包括，
接收单元，用于接收业务服务器发送的批量扣款请求报文；
批量表格生成单元，用于生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格；
判断单元，用于判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态；
锁定单元，用于当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态；
扣款单元，用于执行锁定状态的扣款请求，完成扣款，修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态。
本文实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的方法。
本文实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，该计算机指令被处理器执行时实现上述的方法。
利用本文实施例，支付服务器通过对接收到的高并发的大量扣款请求进行锁状态位以及支付状态的判断，对符合要求的扣款请求进行锁定，从而完成扣款请求的扣款处理，不会在高并发扣款应用时发生扣款请求重复执行造成业务失败或者用户账户数据错误的问题。
附图说明
为了更清楚地说明本文实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本文的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1所示为本文实施例周期性批量扣款系统的结构示意图；
图2所示为本文实施例周期性批量扣款方法的流程图；
图3所示为本文实施例支付服务器的结构示意图；
图4所示为本文实施例一种周期性批量扣款方法的具体流程图；
图5所示为本文实施例对订单进行扣款的处理流程；
图6所示为本文实施例微信支付方式的流程图；
图7所示为本文实施例中与上述图4-图6对应的支付服务器的结构示意图；
图8中为本文实施例中微信支付接口的结构示意图；
图9所示为本文实施例计算设备的结构示意图。
【附图标记说明】
101、业务服务器；
102、支付服务器；
301、接收单元；
302、批量表格生成单元；
303、判断单元；
304、锁定单元；
305、扣款单元；
701、接收单元；
702、校验单元；
703、批量表格生成单元；
704、判断单元；
705、锁定单元；
706、订单生成单元；
707、处理队列；
708、扣款单元；
7081、读取模块；
7082、支付路由模块；
7083、多个支付接口；
7084、支付状态修改模块；
709、批量扣款表格修改单元；
710、订单表格清空单元；801、查询部件；
802、判断部件；
803、支付部件；
804、反馈部件；
902、计算设备；
904、处理设备；
906、存储资源；
908、驱动机构；
910、输入/输出模块；
912、输入设备；
914、输出设备；
916、呈现设备；
918、图形用户接口；
920、网络接口；
922、通信链路；
924、通信总线。
具体实施方式
下面将结合本文实施例中的附图，对本文实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本文一部分实施例，而不是全部的实施例。基于本文中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本文保护的范围。
如图1所示为本文实施例周期性批量扣款系统的结构示意图，在本图实施例中，描述了多个业务服务器101以规定的周期在某个时间同时(几毫秒内)向一个或者多个支付服务器102发起扣款请求，支付服务器102在同一时间(极短的时间区间内)接收到大量扣款请求，当第一批扣款请求还未处理完成，第二批扣款请求到来，则由于并发处理扣款请求时极容易出现重复扣款的现象，而导致业务处理错误，造成业务处理失败、数据错误等问题。在本实施例中包括了多个业务服务器101，这些业务服务器101向支付服务器102发起扣款请求，所述扣款请求为用户的定投业务或者自动续期业务到达预定时间(例如周期性到达预定时间)后向用户留存的银行卡账户或者支付宝、微信等账户中发起扣款请求，所述银行卡账户或者支付宝、微信账户都开启了授权指定的公司或者业务从其账户中扣款。大量定时的扣款请求任务被配置到多个业务服务器101上，在同一时间多个业务服务器101可能会向支付服务器102发送相同用户的扣款请求，本文方法和装置的实施例中通过判断扣款请求是否处于锁定状态以及该扣款请求是否在流水表中有相应记录，如果两者皆否，则进行例如Redis分布式锁等方式对正在处理的扣款请求进行锁定，进行扣款处理，释放该扣款请求的锁定，从而可以避免分布式系统中高并发批量支付情况下重复扣款的问题。
如图2所示为本文实施例周期性批量扣款方法的流程图，在本实施例中，描述了周期性批量扣款的应用中对高并发的扣款请求进行处理的过程，该方法可以应用于高并发大量用户账户操作的业务，例如保险续费中的自动续费业务，或者有线电视、电话等自动续订服务等业务，运行于支付服务器中，用来处理高并发的扣款请求，具体包括以下步骤：
步骤201，接收来自不同业务服务器发送来的批量扣款请求报文。
步骤202，生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格。
步骤203，判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态。
步骤204，当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态。
步骤205，执行锁定状态的扣款请求，完成扣款，修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态。
当步骤202判断结果有一项不为否定时，则不处理所述扣款请求。
作为本文实施例的一个方面，在接收来自不同业务服务器发送来的批量扣款请求报文之后还包括，对接收到的所述批量扣款请求报文中的扣款请求进行验证。
在本步骤中，业务服务器对批量扣款请求中的扣款请求进行加密或者加入校验位，或者对扣款请求进行签名，当支付服务器接收到该批量扣款请求报文时，可以通过与业务服务器加密的逆过程，或者通过相同的校验算法计算校验位，或者对该批量扣款请求报文中的扣款请求进行验签，从而可以判断接收到的扣款请求是否有误。
作为本文实施例的一个方面，生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格中还包括，在所述批量扣款表格中针对每一个扣款请求增加了支付状态位以及扣款失败说明。
在本步骤中，每个批量扣款表格与一个业务服务器发送的批量扣款请求报文对应，也就是说，一个批量扣款请求报文对应一个批量扣款表格，这样可以方便业务服务器查询某个批次的扣款请求全部扣款处理结果，通过所述支付状态位体现扣款是否成功，扣款失败说明用来体现扣款失败的原因。
作为本文实施例的一个方面，在判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态中进一步包括，判断所述批量扣款请求报文中的扣款请求是否在订单表格中，当所述批量扣款请求报文中的扣款请求不在所述订单表格中时，则所述批量扣款请求报文中的扣款请求的锁状态位为未锁定状态。
在本步骤中，所述订单表格初始状态下为空，当在所述订单表格中具有与所述批量扣款请求报文中的扣款请求一样的扣款请求时，则所述批量扣款请求报文中的扣款请求的锁状态位为锁定状态。
作为本文实施例的一个方面，判断所述扣款请求的支付状态是否为完成支付状态中进一步包括，判断所述批量扣款请求报文中的扣款请求是否在流水表格中，当所述批量扣款请求报文中的扣款请求不在所述流水表格中时，则所述批量扣款请求报文中的扣款请求为未完成支付状态。
在本步骤中，所述流水表格初始状态下为空，当在所述流水表格中具有与所述批量扣款请求报文中的扣款请求一样的扣款请求时，则所述批量扣款请求报文中的扣款请求的支付状态位为完成支付状态。
作为本文实施例的一个方面，在当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态中进一步包括，修改所述批量扣款请求报文中的扣款请求的锁状态位的数值为锁定状态的数值。
在本步骤中，可以增加所述批量扣款请求报文中的扣款请求的锁状态位，初始值为0，或者为空，通过前述步骤判断后，当判断结果均为否的情况下，将该锁状态位的数值改为1，代表该扣款请求被锁定，不再对相同的扣款请求进行扣款处理。
作为本文实施例的一个方面，在当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态之后还包括，根据所述锁定状态的扣款请求生成订单，并写入订单表格。
在本步骤中，还将赋予每一条订单一唯一标识符，形成该订单的订单编号，用于查询订单。
作为本文实施例的一个方面，执行所述扣款请求，完成扣款进一步包括，将所述订单表格中的所有订单放入队列中进行扣款处理。
作为本文实施例的一个方面，将所述订单表格中的所有订单放入队列中进行扣款处理进一步包括，获取所述订单中的扣款相关信息；根据所述扣款相关信息进行支付方式路由；根据所述支付方式路由得到支付方式，以所述支付方式对所述订单进行扣款处理。
在本步骤中，所述订单中的扣款相关信息包括，扣款请求中的扣款方式和扣款金额，或者还可以包括其它的扣款请求中的信息，例如投保单号或保险合同号，被扣款用户的账户信息等。
作为本文实施例的一个方面，所述根据所述扣款相关信息进行支付方式路由进一步包括，当所述扣款相关信息中的支付方式不能完成所述订单的扣款处理，则根据所述扣款相关信息查找历史支付记录中的历史支付方式，询问被扣款用户是否同意使用所述历史支付方式完成所述订单的扣款处理。
在本步骤中，可以根据订单中的投保单号或保险合同号等扣款相关信息查找历史支付记录，从所述历史支付记录中找到与所述投保单号或者保险合同号相同的记录，提取该记录中的历史支付方式，向被扣款用户发送短信息或邮件的方式询问由于预留的扣款方式不能完成本次定投业务或者续期业务，是否同意转换为以前支付定投业务或者续期业务的支付方式。或者还可以根据订单中的被扣款用户的信息，例如身份证号码、手机号码等信息，查找历史支付记录中是否有相同记录，如果有则同样可以提取被扣款用户的历史支付方式，从而通知被扣款用户是否转换支付方式。
作为本文实施例的一个方面，以所述支付方式对所述订单进行扣款处理中进一步包括，当所述支付方式为免密支付方式时，根据所述扣款相关信息查询免密支付服务提供端被扣款用户的账户是否支持免密支付，根据所述免密支付服务器提供端反馈的结果，如果所述被扣款用户的账户不支持免密支付方式，则扣款处理失败，否则进行扣款处理。
在本步骤中，免密支付方式可以包括微信免密支付方式、支付宝免密支付方式、或者其它的免密支付方式。
作为本文实施例的一个方面，修改所述扣款请求的支付状态为完成支付状态进一步包括，根据所述订单表格中的订单以及所述扣款处理结果生成流水表格。
在本步骤中，所述流水表格除了包括所有订单标号以及扣款请求以外，还包括该扣款请求进行扣款处理后的扣款处理结果，当所述扣款处理结果为扣款失败时，所述流水表格还包括该扣款请求扣款失败的说明。
作为本文实施例的一个方面，所述方法还包括，根据所述流水表格中的扣款请求的支付状态修改所述批量扣款表格中扣款请求的支付状态。
通过上述本文的实施例，支付服务器通过对接收到的高并发的大量扣款请求进行锁状态位以及支付状态的判断，对符合要求的扣款请求进行锁定，从而完成扣款请求的扣款处理，不会在高并发扣款应用时发生扣款请求重复执行造成业务失败或者用户账户数据错误的问题，通过多种表格单据的配合，可以方便确定每一个业务的状态，并准确实时的将每个扣款处理结果通知给业务服务器。
如图3所示为本文实施例支付服务器的结构示意图，在本实施例中，描述了周期性批量扣款的应用中对高并发的扣款请求进行处理的支付服务器，该支付服务器可以由台式计算机、大型计算机或计算机集群实现，每一个功能单元或者模块、部件都可以由计算机软件程序实现，或者由经过编程配置的通用芯片实现，该支付服务器处于网络中，接收各业务服务器发送的扣款请求进行扣款处理，具体包括：
接收单元301，用于接收业务服务器发送的批量扣款请求报文。
批量表格生成单元302，用于生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格。
判断单元303，用于判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态。
锁定单元304，用于当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态。
扣款单元305，用于执行锁定状态的扣款请求，完成扣款，修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态。
作为本文实施例的一个方面，还包括校验单元，用于对接收到的所述批量扣款请求报文中的扣款请求进行验证。
作为本文实施例的一个方面，在所述批量扣款表格中针对每一个扣款请求增加了支付状态位以及扣款失败说明。
作为本文实施例的一个方面，所述判断单元303进一步用于，判断所述批量扣款请求报文中的扣款请求是否在订单表格中，当所述批量扣款请求报文中的扣款请求不在所述订单表格中时，则所述批量扣款请求报文中的扣款请求的锁状态位为未锁定状态。
作为本文实施例的一个方面，所述判断单元303进一步用于，判断所述批量扣款请求报文中的扣款请求是否在流水表格中，当所述批量扣款请求报文中的扣款请求不在所述流水表格中时，则所述批量扣款请求报文中的扣款请求为未完成支付状态。
作为本文实施例的一个方面，所述锁定单元304进一步用于，修改所述批量扣款请求报文中的扣款请求的锁状态位的数值为锁定状态的数值。
作为本文实施例的一个方面，还包括订单生成单元，用于根据所述锁定状态的扣款请求生成订单，并写入订单表格。
作为本文实施例的一个方面，所述扣款单元305进一步用于，将所述订单表格中的所有订单放入队列中进行扣款处理。
作为本文实施例的一个方面，所述扣款单元305进一步包括，
读取模块，用于获取所述订单中的扣款相关信息；
支付路由模块，用于根据所述扣款相关信息进行支付方式路由，得到所述订单对应的支付方式；
多个支付接口，用于根据所述支付方式对所述订单进行扣款处理；
支付状态修改模块，用于根据扣款处理结果，修改所述扣款请求的支付状态为完成支付状态。
作为本文实施例的一个方面，所述支付路由模块进一步用于，当所述扣款相关信息中的支付方式不能完成所述订单的扣款处理，则根据所述扣款相关信息查找历史支付记录中的历史支付方式，询问被扣款用户是否同意使用所述历史支付方式完成所述订单的扣款处理。
作为本文实施例的一个方面，所述多个支付接口包括免密支付接口，
所述免密支付接口进一步包括，查询部件，用于根据所述扣款相关信息查询免密支付服务提供端被扣款用户的账户是否支持免密支付；判断部件，用于根据所述免密支付服务器提供端反馈的结果，判断所述被扣款用户的账户是否支持免密支付方式，如果支持则调用支付部件进行扣款处理，否则调用反馈部件反馈扣款处理结果。
作为本文实施例的一个方面，所述支付状态修改模块还用于，根据所述订单表格中的订单以及所述扣款处理结果生成流水表格。
作为本文实施例的一个方面，还包括批量扣款表格修改单元，用于根据所述流水表格中的扣款请求的支付状态修改所述批量扣款表格中扣款请求的支付状态。
通过上述本文的实施例，支付服务器通过对接收到的高并发的大量扣款请求进行锁状态位以及支付状态的判断，对符合要求的扣款请求进行锁定，从而完成扣款请求的扣款处理，不会在高并发扣款应用时发生扣款请求重复执行造成业务失败或者用户账户数据错误的问题，通过多种表格单据的配合，可以方便确定每一个业务的状态，并准确实时的将每个扣款处理结果通知给业务服务器。
如图4所示为本文实施例一种周期性批量扣款方法的具体流程图，在本实施例中描述了在保险的定投业务或者在续期业务中实现自动扣款的应用场景，具体包括：
步骤401，业务服务器发送批量扣款请求。
在本步骤中，由多个业务服务器，例如10个业务服务器均被配置同一时间向支付服务器批量发送扣款请求，例如，根据设定的时间，例如每个月12日上午9:30发起批量扣款请求，每个业务服务器发送的扣款请求可能完全相同，也可能不完全相同，例如90％以上相同。由于业务服务器的地理位置、网络环境不同，可能不同业务服务器发送的批量扣款请求到达支付服务器的时间不尽相同，例如在2-3毫秒(ms)的时间区间(或者还可以在其他时间区间，例如1秒)所有业务服务器发送的批量扣款请求都会陆续的到达支付服务器。
业务服务器可以采用json格式封装批量扣款请求报文，在该报文中包括了orderList列表，为了后续计算以及网络传输的最优性，该orderList列表中存储有不超过500条的扣款请求，所述扣款请求可以包括投保单号、保险合同号、被扣款用户的账户信息、扣款数额，还可以包括其他信息，例如扣款方式、用户身份证号码、电话号码等，其中，在本例中账户信息可以为微信账户。
业务服务器对上述批量扣款请求进行校验，例如可以采用CRC(循环冗余校验)校验的方式或者采用MD5(信息摘要)校验的方式，对上述批量扣款请求报文进行计算后，将计算结果的数值放入所述批量扣款请求报文的校验位，并封装为批量扣款请求报文。当接收方(在本例中为支付服务器)接收到该批量扣款请求报文后，对该批量扣款请求报文进行验证。
或者，业务服务器还可以对上述批量扣款请求进行签名，将该签名中包括了业务服务器的唯一标识以及发送该批量扣款请求的时间，并将签名后的批量扣款请求封装为批量扣款请求报文，发送给支付服务器。
步骤402，支付服务器对接收到的批量扣款请求报文进行校验。
在本步骤中，支付服务器对接收到的批量扣款请求报文进行验证，即采用与业务服务器相同的校验算法，例如步骤401中的CRC校验或者MD5校验的方式，对批量扣款请求报文(不包括校验位)进行计算，并将计算结果与批量扣款请求报文中的校验位进行比较，如果相同，则证明校验通过，否则说明该批量扣款请求报文错误。
步骤403，支付服务器根据接收到的批量扣款请求报文，建立与之相应的批量扣款表格。
在本步骤中，支付服务器根据不同业务服务器发送来的批量扣款请求报文，生成相应的批量扣款表格，如下表1所示，
表1批量扣款表格
Figure BDA0002566671890000111
该批量扣款表格的名称可以用来表示批量扣款请求报文来源，用于记录该批量扣款表格属于哪个业务服务器发送的哪个批量扣款请求报文。
在初始状态下，该批量扣款表格为空，当支付服务器接收到不同业务服务器发送来的批量扣款请求报文后，将每个业务服务器发送来的每个批量扣款请求报文生成一个批量扣款表格，其中记录有该批量扣款请求报文中所有的扣款请求，在该批量扣款表格中还包括支付状态位，用于记录该扣款请求是否完成扣款，其中，0表示扣款失败，1表示扣款成功；还可以包括扣款失败说明，用于记录该扣款请求扣款失败的原因。
步骤404，支付服务器判断接收到的批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，如果为锁定状态则返回本步骤404处理下一个扣款请求，否则进入步骤405。
在本步骤中，支付服务器对接收到的扣款请求与支付服务器中的订单表格进行比对，例如通过扣款请求的投保单号或者保险合同号进行比对，如果扣款请求与订单表格中的扣款请求相同，则该扣款请求的锁状态位为锁定状态，如果所述订单表格中的扣款请求与接收到的扣款请求均不相同，则该扣款请求的锁状态位为未锁定状态。
也就是说，判断接收到的扣款请求是否存在于订单表格中，如果存在则该扣款请求的锁状态位为锁定状态，如果所述扣款请求未出现在订单表格中，则该扣款请求的锁状态位为未锁定状态。
其中，支付服务器在预定的时间接收多个业务服务器发送的批量扣款请求时，初始化本地的订单表格，将位于支付服务器缓存中的订单表格的记录清空。所述订单表格的具体描述如后述步骤407描述。
步骤405，支付服务器判断接收到的批量扣款请求报文中的扣款请求是否出现在流水表格中，如果所述扣款请求存在于流水表格中则进入步骤404处理下一个扣款请求，否则进入步骤406。
在本步骤中，所述流水表格中记录的是完成扣款处理的扣款请求，关于流水表格的描述如后述步骤409所述。
步骤406，支付服务器对预定时间区间内接收到的多个业务服务器发送的批量扣款请求报文中不重复的扣款请求进行锁定。
在本步骤中，在预定时间段内可能接收到10个批量扣款请求报文，或者为其他数量的批量扣款请求报文，其中，预定时间区间可以为2ms或者3ms，也可以为其他时间段，按照接收到的先后顺序将10个批量扣款请求报文排序，每一个批量扣款请求报文都包括了多个扣款请求，支付服务器第一个接收到的批量扣款请求报文中的扣款请求不会出现与以前扣款请求报文重复的情况，而第二个接收到的批量扣款请求报文中的扣款请求可能出现与第一个接收到的批量扣款请求报文中的扣款请求重复的情况，可以通过比较扣款请求中的投保单号或者保险合同单号来区分扣款请求是否重复，将第一次出现的扣款请求增加一个锁状态位，将该第一次出现的扣款请求的锁状态位进行修改，从而表示该扣款请求被锁定，后续到来的相同的扣款请求将不被锁定处理。
当支付服务器同时接收到多个批量扣款请求报文时，按照随机的顺序将这些批量扣款请求报文进行排序，从而判断扣款请求是否重复。
在本实施例中，可以采用Redis共享锁技术对批量扣款表中的所有扣款请求的状态位写入代表正在扣款的锁定状态。
例如，可以通过INCR锁命令来实现对批量扣款表中的某条扣款请求设置为锁状态，预先将所有批量扣款表中的所有扣款请求的状态位(key)都初始化为0，针对某一个批量扣款表中的一条扣款请求执行INCR锁命令后，在该条扣款请求的状态位中加1，如果还要对该条扣款请求进行INCR锁定操作时，会返回大于1的数值，则说明该扣款请求正在被处理过程中，不能被重复使用。
还可以通过SETNX锁命令来实现对批量扣款表中的某条扣款请求设置为锁状态，针对某一个批量扣款表中的一条扣款请求执行SETNX锁命令后，该条扣款请求的状态位中的值为该SETNX锁命令设置的值，如果还要对该条扣款请求进行SETNX锁定操作时，会由于该条扣款请求的状态位有值，返回失败信息，说明该扣款请求正在被处理过程中，不能被重复使用。
还可以通过SET锁命令来实现对批量扣款表中的某条扣款请求设置为锁状态，针对某一个批量扣款表中的一条扣款请求执行SET锁命令后，该条扣款请求的状态位中的值为该SET锁命令设置的值，并且该SET锁命令还具有设置锁过期时间的参数，如果还要对该条扣款请求进行SET锁定操作时，会由于该条扣款请求的状态位有值，返回失败信息，说明该扣款请求正在被处理过程中，不能被重复使用。
在其他实施例中，还可以通过Zookeeper(分布式系统协调)的方式实现对批量扣款表中的某条扣款请求设置为锁状态，针对某一个批量扣款表中的一条扣款请求设置为一个持久节点，每一次的锁命令都将创建一个临时节点，该临时节点从属于持久节点，当多次对该扣款请求进行锁定时，都会产生新的并列的临时节点，当该扣款请求被锁定后，产生第一个临时节点，其他的锁定命令都将不予执行，说明该扣款请求正在被处理过程中，不能被重复使用。
本文的实施例中还可以使用其他分布式系统数据锁定的技术实现，在此不能穷尽，但都可以被包括在本文的实施例中。
步骤407，支付服务器根据上述锁定的扣款请求生成相应的订单，并写入订单表格。
在本步骤中，支付服务器根据上述锁定的扣款请求生成订单编号，该订单编号为锁定的扣款请求的唯一标识符，该唯一标识符可以为数字串，或者为字符串，也可以为字符和数字组合的字符串。
所述订单表格可以如下表2所示，其中的投保单号、保险合同号、被扣款用户的账户信息、扣款数额、扣款方式与写入的扣款请求中的内容相容，还包括订单编号以及锁定状态位。该订单表格位于支付服务器的缓存中。
表2：订单表格
Figure BDA0002566671890000141
在上述订单表格中，可以不包括被扣款用户的账户信息和扣款方式，由于定投或者自动续期业务每个周期的扣款用户的账户信息和扣款方式都是固定的，因此可以根据投保单号或者保险合同号在支付服务器的支付历史记录中可以获得被扣款用户的账户信息以及扣款方式。
在其他实施例中，扣款数额也同样可以不包括在上述订单表格中，由于定投或者自动续期业务每个周期的扣款数额都是固定的，即便是扣款数额呈周期性的增加或者减少，也都有固定计算方式，因此同样可以通过支付服务器的支付历史记录获得扣款数额。
步骤408，支付服务器将所述订单表格中的所有订单放入队列进行扣款处理。
在本步骤中，支付服务器还可以将所述订单表格中的所有订单放入线程池中进行扣款处理。
在本步骤中，可以参考图5所示为本文实施例对订单进行扣款的处理流程，在附图5的实施例中描述了基于订单内容的支付路由，从而完成扣款，具体包括：
步骤501，读取订单信息，得到所述订单的扣款相关信息。
在本步骤中，所述订单信息中包括上述扣款请求中的所有信息，所述订单的扣款相关信息可以包括被扣款用户的账户信息，扣款数额和扣款方式信息。
以上述表2中的数据为例，在本实施例中获取到订单编号为1234的扣款相关信息，其中包括被扣款用户的账户信息：WX_11223344，扣款数额：500，扣款方式：微信免密支付。
步骤502，根据扣款相关信息进行支付方式路由。
在本步骤中，可以根据扣款方式进行支付方式路由，在本例中，扣款方式为微信免密支付，则支付服务器会调用相应微信免密支付接口进行扣款。
或者，在其他实施例中，还可以根据扣款数额进行支付方式路由，例如，根据被扣款用户的账户信息，在本例中为WX_11223344，通过微信支付接口查询微信支付服务器提供端该账户的免密支付限额，当扣款数额超过了微信免密支付的限额(例如该账户的免密支付限额为200，本次扣款数额为500)，则会使得扣款失败，此时查询支付服务器上的历史支付记录，查询具有相同投保单号或者保险合同号记录的其他历史支付方式，例如还存在银行卡支付方式，则会通知用户微信免密支付由于该业务(例如续期业务)的扣款数额超过免密支付额度而致使扣款请求失败，是否同意采用历史支付记录中历史支付方式继续进行该业务的扣款，在本例中历史支付方式可以为银行卡。
或者，还可以根据订单中投保担保或者保险合同号查询支付服务器历史支付记录，获得具有相同投保担保或者保险合同号的历史支付记录中的支付方式，根据该支付方式调用相应支付接口进行后续扣款处理。
或者，还可以根据订单中扣款方式和扣款数额来判断扣款数额是否超过了扣款方式对应的门限值，例如，扣款方式为银行卡，扣款数额为60000元，而银行卡的转账限额为50000元，则需要调用其他金融支付接口完成对该扣款请求的扣款处理。
支付方式路由还可以是由多个不同的条件构成，所有的条件都存储在数据库中，当对一条订单进行支付方式路由时，先根据扣款信息中的扣款方式来获取该扣款方式中所有的支付方式，例如，当扣款方式为银行类型(bank_code)时，则获取这个类型所有的支付方式。所述的条件可以包括：保额可用范围(扣款的数额是否在允许的范围内)，核保的范围(可以进行自动扣款的业务是否在允许的范围内)，业务类型可用范围(产生扣款请求业务类型是否在允许的范围内)，租户可用范围(被扣款用户所允许的扣款方式)，证件类型可用范围(被扣款用户的身份信息类型是否在允许的范围内)，地区可用范围(被扣款用户的地理位置是否在允许的范围内)，来源系统可用范围(可以发起批量扣款请求的业务服务器是否在允许的范围内)，IP可用范围(发起批量扣款请求的业务服务器的IP地址是否在允许的范围内)等条件，当然，根据此处条件进行判断的参数可以来自扣款相关信息(此时需要在扣款请求中携带有进行支付方式路由的所有所需参数)，也可以根据订单信息查找相关数据库而活的，例如查找用户数据库获得关于用户的相关信息，或者查找业务数据库获得相关业务的相关信息。
例如：当一个订单信息的扣款相关信息中的扣款方式为微信免密支付，微信免密支付接口从数据库中获取所有相应的条件，然后根据扣款相关信息传过来的入参进行比对，首先判断保额是否在保额可用的范围，根据入参获取对应租户的免密支付方式，判断租户可用范围是否配置了微信免密支付方式等等，最终组成一个链式规则。将整个链式规则组成一个规则字符串，根据运算规则当所有条件都为真时，则返回该支付方式。当任意一个条件不满足时，则不返回支付方式，通知给业务方支付失败，以及相应支付失败原因。
步骤503，根据确定的支付方式进行订单的扣款处理。
在本例中为微信支付方式，可以参考本文图6所示的微信支付方式的流程图，在本图所示的实施例中，以微信支付为例进行说明，还可以说明其他支持免密支付方式，例如支付宝、京东等免密支付方式，具体包括：
步骤601，微信支付接口向微信支付服务提供端发送查询指令，查询该订单中被扣款用户的账户中是否支持微信免密支持。
在本步骤中，查询指令可以包括微信账户信息，例如上述的WX_11223344。在实际应用场景中，微信账户中记录有是否开通免密支付的信息，被扣款用户可随时打开或者关闭(通过设置免密支付的标志位来实现)该免密支付功能，如果微信账户的免密支付功能打开，则可以正常扣款处理，否则将不能进行扣款处理。
步骤602，微信支付接口判断微信支付服务提供端反馈的结果，如果该账户支持微信免密支付，则进入步骤603，否则扣款失败，进入步骤605。
步骤603，微信支付接口向微信支付服务提供端发送微信免密支付请求。
在本步骤中，微信免密支付请求可以包括账户信息，以及扣款数额，或者还可以包括投保单号或者保险合同号。
步骤604，微信支付接口接收微信支付服务提供端发送的扣款处理结果。
在本步骤中，扣款处理结果可能有两种，一种是扣款成功，另一种是扣款失败，以及失败原因。
步骤605，微信支付接口得到扣款成功或者扣款失败以及失败原因的扣款处理结果。
至此，微信扣款的流程结束。
在其他的实施例中，当通过支付路由得到的扣款方式为银行卡扣款时，通过银行支付接口将被扣款用户的银行账户信息，例如上述的6226123345656，以及扣款数额发送给银行支付服务提供端，并且银行支付接口会收到扣款成功或者扣款失败以及失败原因的扣款处理结果，在本例中的扣款处理结果为扣款失败，扣款失败原因为账户余额不足。
在完成上述步骤503之后，该订单的扣款处理完成。
步骤409，支付服务器根据扣款处理结果生成流水表格，用以记录所有订单的扣款处理结果。
所述流水表格如下表3所示，其中记录了所有订单的扣款处理结果。
表3流水表格
Figure BDA0002566671890000171
在该流水表格中，支付状态1为扣款成功，支付状态为0时为扣款失败，此时，在扣款失败说明中写入扣款处理结果中包括的扣款失败原因。
步骤410，根据所述流水表格中的内容，修改上述批量扣款表格中的支付状态位和扣款失败说明。
在本步骤中，可以根据流水表格中的投保单号或者保险合同号匹配到批量扣款表格中的投保单号或者保险合同号，将具有相同投保单号或者保险合同号的批量扣款表格中的扣款请求的支付状态位以及相应的扣款失败说明更新。
修改后的批量扣款表格如下述表4所示，
表4为修改后的批量扣款表格
Figure BDA0002566671890000172
Figure BDA0002566671890000181
由此，当某个业务服务器查询某一个批量扣款请求报文的处理结果时，支付服务器可以将所述批量扣款表格反馈给该业务服务器，该业务服务器可以根据该批量扣款表格得到由该业务服务器发送的批量扣款请求报文的处理情况，其中哪些扣款请求完成了扣款，哪些扣款请求由于什么原因未完成扣款，从而可以另该业务服务器向相应用户发送提示信息，可以起到对账户数据实时跟踪分析的作用，并且可以防止用户由于未按时定期缴纳续期或者定投费而用造成的经济损失。
步骤411，支付服务器将所述订单表格中订单清空。
在本步骤中，可以通过前述Redis等技术手段对订单表格中的订单的锁状态位进行改写，删除该锁状态位中的锁定状态。
或者，还可以开启一计时器，当预定时间内所述订单的锁状态位的锁定状态均未被修改，则删除该订单的锁状态位中的数值，从而对该订单进行解锁操作，其中，预定时间可以例如为100秒。
当支付服务器又接收了业务服务器发送的批量扣款请求报文，或者继续处理在预定时间区间接收到的另一个批量扣款请求报文，返回步骤402重复上述步骤的处理过程。
通过上述本文的实施例，可以高并发的处理大量的关于账户数据的操作，例如扣款操作，特别是对周期性的定投、续期等业务来说，不用安排操作者定期的触发大量账户的操作，节省了人力成本；并且，通过对任务进行锁定的方式，避免了对相同任务重复操作的问题，针对周期性的扣款业务来说，避免了对同一个保单重复扣款的问题；通过支付路由的自动选择，可以根据扣款请求自动化的匹配到合适的支付方式，并且可以路由多种支付方式，特别是对免密的支付方式提供了支持，整合了系统，提高了业务处理的效率；通过多种表格单据的配合，可以方便确定每一个业务的状态，并准确实时的将每个扣款处理结果通知给业务服务器。
针对上述本文的实施例，上述的步骤401中业务服务器可以不计算校验位，也不需要进行步骤402，从而可以进一步提高支付服务器的处理效率。
上述步骤403建立批量扣款表格的步骤可以在步骤403-409的任意步骤之中或者之后，或者，还可以省略步骤403，而在步骤410中直接根据流水表格的内容增加批量扣款请求报文中的每一个扣款请求的支付状态以及扣款失败说明，形成批量扣款处理结果报文，并在对应的业务服务器查询该批量扣款请求报文的处理结果时，将修改后的批量扣款处理结果报文发送给该业务服务器。
上述步骤404和405的顺序可以颠倒，例如先执行步骤405然后根据判断结果执行步骤404，当然，此时的跳转顺序也会进行调整。
上述步骤406和407的顺序可以颠倒，例如可以先根据扣款请求生成订单，然后再在订单的锁状态位写入数值，实现对扣款请求的锁定。
本文实施例方法的执行顺序还有多种变形，在此不再赘述。
如图7所示为本文实施例中与上述图4-图6对应的支付服务器的结构示意图，可以参考本图7的结构理解上述图4-图6的方法，该支付服务器可以为台式计算设备，或者为大型计算机，或者为计算机集群，其中的每个功能单元或者模块都可以由软件程序实现，或者由通用的可编程逻辑器件通过烧刻程序实现，具体包括：
接收单元701，用于接收业务服务器发送的批量扣款请求报文。校验单元702，用于对接收到的批量扣款请求报文进行校验。批量表格生成单元703，用于根据接收到的批量扣款请求报文，建立与之相应的批量扣款表格。判断单元704，用于判断接收到的批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，并且判断接收到的批量扣款请求报文中的扣款请求是否出现在流水表格中。当判断单元704的两个判断结果都为否的情况下，锁定单元705，用于对预定时间区间内接收到的多个业务服务器发送的批量扣款请求报文中不重复的扣款请求进行锁定。订单生成单元706，用于根据上述锁定的扣款请求生成相应的订单，并写入订单表格。处理队列707，用于容纳所述订单表格中的所有订单。扣款单元708，用于对队列中的订单进行扣款处理。
所述扣款单元708中进一步包括，读取模块7081，用于读取订单信息，得到所述订单的扣款相关信息。支付路由模块7082，用于根据扣款相关信息进行支付方式路由，找出所述订单的支付方式。多个支付接口7083，用于根据确定的支付方式进行订单的扣款处理。支付状态修改模块7084，用于根据扣款处理结果，修改所述扣款请求的支付状态，例如本例中修改为完成支付状态。
在上述图6中的实施例中，所述支付接口7083可以包括微信支付接口，该微信支付接口的结构可以参考图8，具体包括，
查询部件801，用于向微信支付服务提供端发送查询指令，查询该订单中被扣款用户的账户中是否支持微信免密支持。
判断部件802，用于接收微信支付服务器提供端反馈的查询结果，如果该账户支持微信免密支付，则调用支付部件803进行微信支付；如果该账户不支持微信免密支付，则调用反馈部件804反馈扣款失败以及失败原因的扣款处理结果。
当支付部件803扣款成功或者扣款失败，都将调用反馈部件804将扣款处理结果进行反馈。
作为其他的实施例，当支付接口7083为银行卡支付接口时，可能仅包括上述的支付部件和反馈部件，用来完成银行卡账户的扣款，扣款成功或者扣款失败的扣款处理结果都将会通过反馈部件进行反馈。
上述微信支付接口以及银行支付接口反馈的扣款处理结果都将反馈给扣款单元708，由该扣款单元708的支付状态修改模块7084将扣款处理结果生成流水表格，用以记录所有订单的扣款处理结果。
上述图7中还包括批量扣款表格修改单元709，用于根据所述订单的扣款处理结果，修改上述批量扣款表格中的支付状态。
还包括订单表格清空单元710，用于当所述订单完成扣款处理后，将所述订单表格中订单清空。
如图9所示为本文实施例计算设备的结构示意图，在本实施例中支付服务器可以为本实施例中的计算设备，执行上述本文的方法。计算设备902可以包括一个或多个处理设备904，诸如一个或多个中央处理单元(CPU)，每个处理单元可以实现一个或多个硬件线程。计算设备902还可以包括任何存储资源906，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储资源906可以包括以下任一项或多种组合：任何类型的RAM，任何类型的ROM，闪存设备，硬盘，光盘等。更一般地，任何存储资源都可以使用任何技术来存储信息。进一步地，任何存储资源可以提供信息的易失性或非易失性保留。进一步地，任何存储资源可以表示计算设备902的固定或可移除部件。在一种情况下，当处理设备904执行被存储在任何存储资源或存储资源的组合中的相关联的指令时，计算设备902可以执行相关联指令的任一操作。计算设备902还包括用于与任何存储资源交互的一个或多个驱动机构908，诸如硬盘驱动机构、光盘驱动机构等。
计算设备902还可以包括输入/输出模块910(I/O)，其用于接收各种输入(经由输入设备912)和用于提供各种输出(经由输出设备914))。一个具体输出机构可以包括呈现设备916和相关联的图形用户接口(GUI)918。在其他实施例中，还可以不包括输入/输出模块910(I/O)、输入设备912以及输出设备914，仅作为网络中的一台计算设备。计算设备902还可以包括一个或多个网络接口920，其用于经由一个或多个通信链路922与其他设备交换数据。一个或多个通信总线924将上文所描述的部件耦合在一起。
通信链路922可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路922可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。
本文实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下步骤：
接收来自不同业务服务器发送来的批量扣款请求报文；
判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态；
当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态；
执行所述扣款请求，完成扣款，并修改所述扣款请求的支付状态为完成支付状态。
本文实施例提供的计算机设备还可以实现如图2、图4-图6中的方法。
对应于图2、图4-图6中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。
本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图2、图4-图6所示的方法。
应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。
还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的目的。
另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。

Claims (10)

1.一种批量扣款方法，其特征在于包括，
接收来自不同业务服务器发送来的批量扣款请求报文；
生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格；
判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态；
当判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态；
执行锁定状态的扣款请求，完成扣款，修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态。
2.根据权利要求1所述的方法，其特征在于，在判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态中进一步包括，判断所述批量扣款请求报文中的扣款请求是否在订单表格中，当所述批量扣款请求报文中的扣款请求不在所述订单表格中时，则所述批量扣款请求报文中的扣款请求的锁状态位为未锁定状态。
3.根据权利要求2所述的方法，其特征在于，判断所述扣款请求的支付状态是否为完成支付状态中进一步包括，判断所述批量扣款请求报文中的扣款请求是否在流水表格中，当所述批量扣款请求报文中的扣款请求不在所述流水表格中时，则所述批量扣款请求报文中的扣款请求为未完成支付状态。
4.根据权利要求3所述的方法，其特征在于，在当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态之后还包括，根据所述锁定状态的扣款请求生成订单，并写入订单表格。
5.根据权利要求4所述的方法，其特征在于，所述执行所述扣款请求，完成扣款进一步包括，获取所述订单中的扣款相关信息；根据所述扣款相关信息进行支付方式路由；根据所述支付方式路由得到支付方式，以所述支付方式对所述订单进行扣款处理。
6.根据权利要求5所述的方法，其特征在于，以所述支付方式对所述订单进行扣款处理中进一步包括，当所述支付方式为免密支付方式时，根据所述扣款相关信息查询免密支付服务提供端被扣款用户的账户是否支持免密支付，根据所述免密支付服务器提供端反馈的结果，如果所述被扣款用户的账户不支持免密支付方式，则扣款处理失败，否则进行扣款处理。
7.根据权利要求3所述的方法，其特征在于，执行锁定状态的扣款请求，完成扣款，并修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态中进一步包括，修改所述流水表格中扣款请求的支付状态，并根据所述流水表格中的扣款请求的支付状态修改所述批量扣款表格中扣款请求的支付状态。
8.一种支付服务器，其特征在于包括，
接收单元，用于接收业务服务器发送的批量扣款请求报文；
批量表格生成单元，用于生成与每一个业务服务器发送的批量扣款请求报文相对应的批量扣款表格；
判断单元，用于判断所述批量扣款请求报文中的扣款请求的锁状态位是否为锁定状态，以及所述扣款请求的支付状态是否为完成支付状态；
锁定单元，用于当所述判断结果均为否时，则修改所述扣款请求的锁状态位为锁定状态；
扣款单元，用于执行锁定状态的扣款请求，完成扣款，修改所述扣款请求的支付状态为完成支付状态，并修改所述批量扣款表格中扣款请求的支付状态。
9.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1-7中任一项的方法。
10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述权利要求1-7任一项的方法。
CN202010626436.7A 2020-07-02 2020-07-02 一种批量扣款方法、支付服务器、计算机设备及存储介质 Active CN111833034B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010626436.7A CN111833034B (zh) 2020-07-02 2020-07-02 一种批量扣款方法、支付服务器、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010626436.7A CN111833034B (zh) 2020-07-02 2020-07-02 一种批量扣款方法、支付服务器、计算机设备及存储介质

Publications (2)

Publication Number Publication Date
CN111833034A true CN111833034A (zh) 2020-10-27
CN111833034B CN111833034B (zh) 2024-01-30

Family

ID=72901137

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010626436.7A Active CN111833034B (zh) 2020-07-02 2020-07-02 一种批量扣款方法、支付服务器、计算机设备及存储介质

Country Status (1)

Country Link
CN (1) CN111833034B (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112434335A (zh) * 2020-11-25 2021-03-02 平安普惠企业管理有限公司 业务问题的处理方法、装置、计算机设备及存储介质
CN112529649A (zh) * 2020-11-20 2021-03-19 深圳市智莱科技股份有限公司 自助充电柜扣款异常的处理方法、装置及相关设备
CN112766768A (zh) * 2021-01-26 2021-05-07 云账户技术(天津)有限公司 合同流程管理方法、装置、电子设备以及可读存储介质
CN112927066A (zh) * 2021-03-30 2021-06-08 中国建设银行股份有限公司 一种批量扣款方法和装置
CN113111060A (zh) * 2021-03-11 2021-07-13 北京健康之家科技有限公司 数据处理方法、装置、存储介质及计算机设备
CN113222580A (zh) * 2021-05-27 2021-08-06 中国农业银行股份有限公司 账务处理方法及相关装置
CN113610537A (zh) * 2021-08-05 2021-11-05 北京云从科技有限公司 请求执行方法、服务器、计算机设备和存储介质
CN113627917A (zh) * 2021-07-08 2021-11-09 浙江吉利控股集团有限公司 一种订单处理方法、装置、设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012221397A (ja) * 2011-04-13 2012-11-12 Think Tank:Kk 資金平準化システム
CN105225152A (zh) * 2015-11-18 2016-01-06 中国电信股份有限公司南京分公司 一种电子化银行托收系统及其托收方法
US20170178110A1 (en) * 2015-12-21 2017-06-22 David Benjamin Swanson Private Payee-Controlled Compensation Disbursement System to Multiple Payee Directed Disbursement Devices
CN106971339A (zh) * 2016-01-14 2017-07-21 阿里巴巴集团控股有限公司 一种业务处理方法和装置
CN109064176A (zh) * 2018-06-11 2018-12-21 阿里巴巴集团控股有限公司 一种交易处理方法、装置及系统
CN109670807A (zh) * 2018-11-20 2019-04-23 平安科技（深圳）有限公司 扣款控制方法、装置、设备及可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012221397A (ja) * 2011-04-13 2012-11-12 Think Tank:Kk 資金平準化システム
CN105225152A (zh) * 2015-11-18 2016-01-06 中国电信股份有限公司南京分公司 一种电子化银行托收系统及其托收方法
US20170178110A1 (en) * 2015-12-21 2017-06-22 David Benjamin Swanson Private Payee-Controlled Compensation Disbursement System to Multiple Payee Directed Disbursement Devices
CN106971339A (zh) * 2016-01-14 2017-07-21 阿里巴巴集团控股有限公司 一种业务处理方法和装置
CN109064176A (zh) * 2018-06-11 2018-12-21 阿里巴巴集团控股有限公司 一种交易处理方法、装置及系统
CN109670807A (zh) * 2018-11-20 2019-04-23 平安科技（深圳）有限公司 扣款控制方法、装置、设备及可读存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张天白 等: "移动支付安全业务系统设计方案", 信息技术与标准化, no. 04, pages 25 - 28 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112529649A (zh) * 2020-11-20 2021-03-19 深圳市智莱科技股份有限公司 自助充电柜扣款异常的处理方法、装置及相关设备
CN112529649B (zh) * 2020-11-20 2024-02-27 深圳市智莱科技股份有限公司 自助充电柜扣款异常的处理方法、装置及相关设备
CN112434335A (zh) * 2020-11-25 2021-03-02 平安普惠企业管理有限公司 业务问题的处理方法、装置、计算机设备及存储介质
CN112766768A (zh) * 2021-01-26 2021-05-07 云账户技术(天津)有限公司 合同流程管理方法、装置、电子设备以及可读存储介质
CN112766768B (zh) * 2021-01-26 2022-05-17 云账户技术(天津)有限公司 合同流程管理方法、装置、电子设备以及可读存储介质
CN113111060A (zh) * 2021-03-11 2021-07-13 北京健康之家科技有限公司 数据处理方法、装置、存储介质及计算机设备
CN112927066A (zh) * 2021-03-30 2021-06-08 中国建设银行股份有限公司 一种批量扣款方法和装置
CN113222580A (zh) * 2021-05-27 2021-08-06 中国农业银行股份有限公司 账务处理方法及相关装置
CN113627917A (zh) * 2021-07-08 2021-11-09 浙江吉利控股集团有限公司 一种订单处理方法、装置、设备及存储介质
CN113610537A (zh) * 2021-08-05 2021-11-05 北京云从科技有限公司 请求执行方法、服务器、计算机设备和存储介质

Also Published As

Publication number Publication date
CN111833034B (zh) 2024-01-30

Similar Documents

Publication Publication Date Title
CN111833034A (zh) 一种批量扣款方法、支付服务器、计算机设备及存储介质
EP3568824B1 (en) Systems and methods for issuing and tracking digital tokens within distributed network nodes
CN109360077B (zh) 发票报销中的信息处理方法、装置、网关服务器和介质
CN110232565B (zh) 资源清算方法、装置、计算机设备和存储介质
WO2021135169A1 (zh) 基于区块链的管理方法、终端、装置及存储介质
JP2002245243A (ja) 私的で安全な金融取引システム及び方法
US20200007647A1 (en) Real-time Event Orchestrator
CN111523817B (zh) 基于大数据的订单业务处理方法、装置、设备和介质
CN112348326A (zh) 一种银行业务处理方法和系统
CN111105224B (zh) 支付反馈信息的处理方法、装置、电子设备和存储介质
CN115952220A (zh) 基于区块链的票据处理方法、装置、电子设备及介质
US20240152880A1 (en) Multi-Channel Payment Method and System
US20170357954A1 (en) Network for onboarding and delivery of electronic payments to new payees
WO2021073096A1 (zh) 资源数据的转移方法、装置和区块链系统
US9286321B2 (en) Systems and methods for providing an automated validity check of transactional data postings
US20220350815A1 (en) Systems and methods for data format conversion
CN111192034B (zh) 一种业务请求数据的处理方法和装置
CN113988844A (zh) 业务签约方法、装置和系统
CN113781230A (zh) 基于区块链的交易处理方法和装置
CN112965986A (zh) 业务一致性处理方法、装置、设备及存储介质
CN112070489A (zh) 一种多终端共同交易数字货币的方法、系统和存储介质
CN110852866A (zh) 用于对多个资源进行管理的方法、装置和存储介质
US20230297995A1 (en) Allocating payment transaction portions to more than one funding source via a single card
US11907801B2 (en) System for encoding resource access credential in barcode
CN110956551B (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