CN111353781B - 一种交易数据处理方法及系统 - Google Patents
一种交易数据处理方法及系统 Download PDFInfo
- Publication number
- CN111353781B CN111353781B CN202010171158.0A CN202010171158A CN111353781B CN 111353781 B CN111353781 B CN 111353781B CN 202010171158 A CN202010171158 A CN 202010171158A CN 111353781 B CN111353781 B CN 111353781B
- Authority
- CN
- China
- Prior art keywords
- account
- transaction
- information
- deduction
- data processing
- 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
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/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/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
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- 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/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请涉及一种交易数据处理方法及系统,其中方法包括:交易终端在离线状态下确定账户所需扣款的交易金额;交易终端根据交易金额及账户生成对应的离线交易信息;业务端根据离线交易信息生成扣款请求;业务端按照预设的请求扣款周期,将扣款请求同步至交易数据处理端;交易数据处理端根据扣款请求在账户中执行扣款;交易数据处理端在账户执行扣款后的账户信息满足账户停用条件时,暂停账户的支付功能。本申请提供的技术方案能够在支付的用户账户资金不足,透支的金额或次数过多时,通过在账户信息满足账户停用条件时,暂停所述账户的支付功能,进而可以只给该账户只垫资一次或多次,可以有效避免系统多次给该支付用户垫资,限制其恶意刷单。
Description
技术领域
本申请涉及电子支付技术领域,尤其涉及一种交易数据处理方法及系统。
背景技术
随着互联网的发展,越来越多的用户通过非现金支付进行公共交通工具的乘坐。举例来说,用户使用非接触式支付(例如闪付)乘坐公交,公交公司使用ODA(Offline DataAuthentication,脱机数据认证)模式,待用户乘车完毕后离开,公交公司在每天固定时间将交易批量发送银联进行异步扣款,银联将交易转发给非接触式支付发卡方(当非接触式支付方式是闪付时,则对应的服务方为中国银联),对用户的进行扣款,若用户资金不足,非接触式支付发卡方进行垫资,完成此笔ODA的交易(ODA交易需要发卡方承担资金损失)。后续待用户还款。
现有银联闪付黑名单技术,当用户资金不足,扣款失败后,非接触式支付发卡方垫资,返回银联强制承兑,此时银联不能马上将用户放入黑名单中,即使判定可以列为黑名单,也不能实时同步到公交闸机黑名单中(正常为1-7天时间),这样可能会出现在银联没有同步闸机黑名单期间,用户在账户没有资金的情况下,还能继续使用非接触式支付进行公交出行,且能乘车完毕离开,公交公司会继续发起扣款,导致闪付为用户多次垫资。
针对相关技术中存在的诸多技术问题,目前尚未提供有效的解决方案。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题,本申请提供了一种交易数据处理方法及系统。
第一方面,本申请实施例提供了一种交易数据处理方法,包括:
交易终端在离线状态下确定账户所需扣款的交易金额;
所述交易终端根据所述交易金额及账户生成对应的离线交易信息;
所述交易终端将所述离线交易信息同步至业务端;
所述业务端根据所述离线交易信息生成扣款请求;
所述业务端按照预设的请求扣款周期,将所述扣款请求同步至业务对接系统;
交易数据处理端接收所述业务对接系统转发的所述扣款请求;
所述交易数据处理端根据所述扣款请求在所述账户中执行扣款;
所述交易数据处理端在所述账户执行扣款后的账户信息满足账户停用条件时,暂停所述账户的支付功能。
可选的,如前述的处理方法,所述根据所述交易信息在所述账户中执行扣款,包括:
所述交易数据处理端根据所述交易信息确定所述账户的交易金额;
在所述账户中的金额大于所述交易金额时,所述交易数据处理端按照所述交易金额进行扣款,并向所述业务对接系统返回扣款成功信息;
所述业务端接收业务对接系统转发的扣款成功信息并完成交易;
在所述账户中的金额小于所述交易金额时,所述交易数据处理端按照所述交易金额进行扣款及垫资,并向所述业务对接系统返回垫资信息;
所述业务端在接收所述业务对接系统根据所述垫资信息生成的扣款成功信息后,判断交易完成。
可选的,如前述的处理方法,所述暂停所述账户的支付功能,包括:
所述交易数据处理端根据所述垫资确定所述账户的欠款信息;
所述交易数据处理端根据所述欠款信息将所述账户加入交易黑名单,以暂停所述账户的支付功能。
可选的,如前述的处理方法,在将所述账户加入交易黑名单之后,还包括:
所述交易数据处理端将所述交易黑名单发送至所述业务端;
所述业务端将所述交易黑名单转发至所述交易终端;
所述交易终端根据所述交易黑名单暂停与所述账户相关的所有交易。
可选的,如前述的处理方法,所述暂停所述账户的支付功能,包括:
根据所述扣款请求确定进行交易的用户终端的设备型号信息;
根据所述设备型号信息生成对应的账户暂停指令;
将所述账户暂停指令发送至所述用户终端,以暂停所述账户的支付功能。
可选的,如前述的处理方法,在暂停所述账户的支付功能之后,还包括:
获取所述账户关联的所有用户终端;
暂停所有所述用户终端上与所述账户相关的支付功能。
可选的,如前述的处理方法,还包括:
在接收到所述账户的还款,且所述还款大于等于所述垫资时,生成还款成功信息;
根据所述还款成功信息恢复所述账户的支付功能。
第二方面,本申请实施例提供了交易数据处理系统,包括:交易终端、业务端和交易数据处理端;
所述交易终端,用于在离线状态下确定账户所需扣款的交易金额;根据所述交易金额及账户生成对应的离线交易信息;将所述离线交易信息同步至所述业务端;
所述业务端,用于根据所述离线交易信息生成扣款请求;按照预设的请求扣款周期,将所述扣款请求同步至业务对接系统;
所述交易数据处理端,用于接收所述业务对接系统转发的所述扣款请求;根据所述扣款请求在所述账户中执行扣款;在所述账户执行扣款后的账户信息满足账户停用条件时,暂停所述账户的支付功能。
第三方面,本申请实施例提供了一种电子设备,包括:处理器、通信接口、存储器和通信总线,其中,所述处理器、通信接口和存储器通过通信总线完成相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行所述计算机程序时,实现如前述任一项所述的处理方法。
第四方面,本申请实施例提供了一种非暂态计算机可读存储介质,其特征在于,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行如前述任一项所述的处理方法。
本申请实施例提供了一种交易数据处理方法及系统,其中方法包括:交易终端在离线状态下确定账户所需扣款的交易金额;所述交易终端根据所述交易金额及账户生成对应的离线交易信息;所述交易终端将所述离线交易信息同步至业务端;所述业务端根据所述离线交易信息生成扣款请求;所述业务端按照预设的请求扣款周期,将所述扣款请求同步至业务对接系统;交易数据处理端接收所述业务对接系统转发的所述扣款请求;所述交易数据处理端根据所述扣款请求在所述账户中执行扣款;所述交易数据处理端在所述账户执行扣款后的账户信息满足账户停用条件时,暂停所述账户的支付功能。本申请实施例提供的上述技术方案与现有技术相比具有如下优点:当进行支付的用户账户资金不足,透支的金额或次数过多时,实现本方法的系统通过在账户信息满足账户停用条件时,暂停所述账户的支付功能,进而可以只给该账户只垫资一次或多次,可以有效避免系统多次给该支付用户垫资,限制其恶意刷单。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种交易数据处理方法的流程示意图;
图2为本申请另一实施例提供的一种交易数据处理方法的流程示意图;
图3为本申请另一实施例提供的一种交易数据处理方法的流程示意图;
图4为本申请另一实施例提供的一种交易数据处理方法的流程示意图;
图5为本申请另一实施例提供的一种交易数据处理方法的流程示意图;
图6为本申请另一实施例提供的一种交易数据处理系统的框图;
图7为本申请实施例提供的一种电子设备的结构示意图;
图8为本申请一种应用例提供的交易数据处理方法的流程示意图。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请的一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
图1为本申请实施例提供的一种交易数据处理方法,包括如下步骤S1至S8:
步骤S1.交易终端在离线状态下确定账户所需扣款的交易金额。
具体的,交易终端可以是:地铁闸机、公交刷卡设备或收银设备等与用户直接进行交易的终端。以公交系统中进行交易为例,现有技术中,虽然提出了公交公司定时异步提交扣款申请至银联的方案,但是仍然需要闸机等交易终端能够实时将交易金额同步至公交公司的服务器(业务端)中,才可以判断用户交易成功,但是此方式存在较大缺陷:当在地铁等运营环境下,由于闸机是固定设置的,尚且可以保障闸机与业务方系统之间通信的稳定性;但是,当交易终端是设在公交车等运营环境下的收款装置时,由于不同行路地点的网络环境差异较大,甚至会出现部分地点无法联网的情况,就会经常性出现用户刷卡失败的情况;此外,在通过POS机支付时,也经常会出现信号差无法支付的情况,极大地影响了支付的效率以及消费者的用户体验。
此外,交易终端可以只通过一次感应(例如NFC感应)的方式进行交易金额的确认,举例来说:进行商品购买时,只在结账时进行支付;交易金额也可以是通过多次感应的方式进行确认,例如:当用户使用闪付进行乘车时,需要上车前进行一次地铁闸机刷闪付后进站,乘车完毕后再地铁闸机刷闪付后离站,且交易金额是根据进站和离站的信息得到的。此外,还可以包括其他情况,在此不一一列举。
因此,在本实施例中,通过在离线状态下确定账户所需扣款的交易金额,可以有效克服支付效率差,受网络影响大的问题。
步骤S2.交易终端根据交易金额及账户生成对应的离线交易信息。
具体的,除了根据交易金额以及账户生成对应的离线交易信息,所述交易信息可以包括:账户类型、账户名、消费时间、消费类型以等其它信息;以在可以联网时,将离线交易信息同步至公交公司。
步骤S3.交易终端将离线交易信息同步至业务端。
具体的,业务端可以是对交易终端进行统一管理,以及进行扣款请求的系统。以便于向特定金融机构或系统进行申请扣费。一般的,本实施例中所述的金融机构为账户服务的提供商,例如:银行、第三方支付服务提供商等等。
步骤S4.业务端根据离线交易信息生成扣款请求。
具体的,由于离线交易信息是业务端本身进行存储的信息,无法根据其进行扣款,因此需要将离线交易信息转换为业务对接系统能够识别的信息,以顺利将其发送至业务对接系统,进而对交易数据处理端进行扣款。
步骤S5.业务端按照预设的请求扣款周期,将扣款请求同步至业务对接系统;
请求扣款周期是定期发送离线交易信息至业务对接系统的周期,具体周期的时长可以根据具体情况进行设定,举例来说,当适用于地铁等系统中时,一般两站地之间的时长至少在2分钟以上,因此只要保证周期短于改时间,即可防止用户恶意刷单透支,避免出现损失;此外,不同的应用场景中,求情扣款周期的时长可以根据具体情况进行设置,在此不做具体限定。
一般情况下,离线交易信息只向业务对接系统同步一次,当同步失败时,可以进行多次同步;进一步的,为了防止出现重复扣款等情况,离线交易信息中还可以包括时间信息,以使业务对接系统通过其判断先后两次同步得到的离线交易信息是否对应于同一笔交易。
步骤S6.交易数据处理端接收业务对接系统转发的扣款请求;
具体的,交易数据处理端可以为账号相关的服务提供方,例如发卡方、银行、第三方支付服务提供商等等。
步骤S7.交易数据处理端根据扣款请求在账户中执行扣款;
具体的,与交易信息对应的账户即为用户端进行交易的账户;由于交易信息中包括步骤S6中所述的相关信息,因此可以根据账户类型确定对应的金融服务机构或系统,同时通过相应的对接接口进行扣款申请,在申请通过之后,便可以完成对账户的扣款。
步骤S8.交易数据处理端在判断账户执行扣款后的账户信息满足账户停用条件时,暂停账户的支付功能。
具体的,账户停用条件可以是:当账户中的资金余额小于某一金额(例如:小于等于0元),当账户欠款达到某一金额(例如:欠款达到1000元),或当透支笔数达到某一数量时(例如:透支5笔)等等情况;举例来说,当用户使用闪付在银联ODA公交技术的公交闸机上刷卡乘车时,且账户信息满足账户停用条件时,使该账户无法进行支付,进而防止其一直恶意透支。
综上所述,采用本实施例中的方法,可以在进行支付的用户账户资金不足,透支的金额或次数过多时,实现本方法的系统通过在账户信息满足账户停用条件时,暂停所述账户的支付功能,进而可以只给该账户只垫资一次或多次,可以有效避免系统多次给该支付用户垫资,限制其恶意刷单。
如图2所示,在一些实施例中,如前述的处理方法,步骤S6根据扣款请求在账户中执行扣款,包括如下所述步骤S61和S63:
步骤S61.交易数据处理端根据扣款请求确定账户的交易金额。
具体的,原始的交易金额可以是交易终端或业务端本身计算得到,并写入交易信息中,因此,当交易数据处理端接收到扣款请求之后,便可以得到其中的账户以及交易金额。
步骤S62.在账户中的金额大于交易金额时,交易数据处理端按照交易金额进行扣款,并向业务对接系统返回扣款成功信息;
步骤S63.业务端接收业务对接系统转发的扣款成功信息并完成交易。
具体的,当账户中的金额大于交易金额时,则只需在账户中直接进行扣款即可;业务对接系统可以是诸如银联等系统,银联是实现本市实施例方案的系统与业务系统之间的一种对接系统,以前述步骤S21中进行乘车的例子为例,当确定交易金额之后,将交易信息以及扣款申请提交至银联;然后由银联将交易信息以及扣款申请转发至实现本实施例方案的系统中。
步骤S64.在账户中的金额小于交易金额时,交易数据处理端按照交易金额进行扣款及垫资,并向业务对接系统返回垫资信息;
步骤S65.业务端在接收业务对接系统根据垫资信息生成的扣款成功信息后,判断交易完成。
具体的,所述账户中的金额小于交易金额可以包括:存在余额,但是不足以缴纳所有交易金额;余额为零,所有交易金额均需要进行垫资;其中,垫资信息可以包括强制承兑信息,强制承兑为:用户余额不足时,实现本方法的金融机构需要为用户进行相关交易金额的全部或部分垫资;因此前置承兑信息即为表征已完成垫资的信息;进一步的,强制承兑信息在返回至银联等业务对接系统后,业务对接系统可以根据其生成或调取扣款成功的相关通知信息,并且将该通知信息发送至业务端,使其得知自己成功接收到相应的款项。
其中一种可选的应用方法可以是:
I.业务对接系统(如银联)判断确定闪付设备使用的服务提供商,便将交易信息转发至服务提供商进行扣款。
II.服务提供商针对闪付设备对应的用户账户进行扣款操作;
1).用户账户有足够资金,进行交易金额扣除,返回扣款成功。
2).用户账户资金不足情况下:
①服务提供商暂时垫资,进行强制承兑,返回银联强制承兑,银联返回公交公司扣款成功。
②用户加入黑名单,暂停该账户的支付账户状态(此时用户使用全新设备也无法加卡)。
③生成欠款记录;可以通过短信息提示用户有一笔待还款项。
④对用户已有的用户终端发送设备卡暂停指令,限制用户通过用户终端进行闪付交易,进行熔断止损。
如图3所示,在一些实施例中,如前述的处理方法,暂停账户的支付功能,包括如下所述步骤S81和S82:
步骤S81.交易数据处理端根据垫资确定账户的欠款信息。
一般的,当一个账户得到了多少的垫资,便意味着其欠款金额是多少,而欠款信息则会包括该欠款金额,因此可以通过垫资确定账户的欠款信息。
步骤S82.交易数据处理端根据欠款信息将账户加入交易黑名单,以暂停账户的支付功能。
具体的,当账户加入交易黑名单之后,该账户即无法再进行交易,并且在加入交易黑名单的方法可以包括:
通过手机端的钱包SDK(软件开发工具包)对用于支付的设备卡进行冻结,使其无法使用,设备卡就是存储在手机NFC(Near Field Communication,近场通信)芯片里的一张模拟物理卡片信息的虚拟卡片。
在一些实施例中,如前述的处理方法,在将所述账户加入交易黑名单之后,还包括如下所述步骤A1至A3:
步骤A1.交易数据处理端将交易黑名单发送至业务端;
步骤A2.业务端将交易黑名单转发至交易终端;
步骤A3.交易终端根据交易黑名单暂停与账户相关的所有交易。
具体的,将交易黑名单发送至交易终端,将交易黑名单实时同步到各个交易终端上(例如:终端闸机),并且交易终端会对黑名单中的信息进行保存,当账户请求进行交易时,交易终端便可以根据交易黑名单中的信息对该账户进行校验,以判断其是否能够进行支付,因此也可以防止出现恶意刷单的情况,降低垫资方的风险。
在一些实施例中,如前述的处理方法,暂停账户的支付功能,包括如下所述步骤S83至S85:
步骤S83.根据扣款请求确定进行交易的用户终端的设备型号信息。
具体的,为了获取进行交易的用户终端的设备型号信息,因此在获取离线交易信息的时候,交易终端即可获取相关信息,并将其写入扣款请求中,以将其发送至交易数据处理端。
步骤S84.根据设备型号信息生成对应的账户暂停指令。
具体的,由于不同的设备型号对应的系统或版本均不相同,因此能够识别的账户暂停指令也各有区别,需要针对性地生成与各个设备信号对应的账户暂停指令;可选的,不同的设备型号信息与账户暂停指令之间可以预设有对应关系,并且可以存储在数据表中,以便于快速生成或匹配得到准确的指令。
步骤S85.将账户暂停指令发送至用户终端,以暂停账户的支付功能。
具体的,在用户终端接收得到账户暂停指令之后,对其执行之后,便可以达到暂停账户的支付功能的目的;但是,并不会对账户的所有功能都进行关闭,以免影响用户的还款等操作。
如图4所示,在一些实施例中,如前述的处理方法,在步骤S8中的暂停账户的支付功能之后,还包括如下所述步骤S9和S10:
步骤S9.交易数据处理端获取账户关联的所有用户终端。
具体的,由于终端使用的频繁性,以及有的用户会根据不同的需求或场景使用不同的终端,导致越来越多的用户会同时使用多个不同的终端设备;尤其是一些异常刷单用户可能会将一个账户登录于不同的终端设备上,以寻求从其它平台上套取更多金额。
本实施例中,当用户终端上每进行依次账户设置时,都会将终端信息以及账户信息发送至交易数据处理端;因此交易数据处理端可以确定账户与设备信息之间的对应关系,并且可以通过建立数据表的形式对账户与设备信息之间的对应关系进行存储。
当需要获取账户关联的所有用户终端时,便可从数据表中进行查询得到。
步骤S10.交易数据处理端暂停所有用户终端上与账户相关的支付功能。
具体的,当一个用户终端上出现账户的支付功能被暂停之后,系统便可以在诸如数据表等形式的存储文件中匹配的到与该账户相关的所有设备卡的设备信息,然后根据各个设备卡的系统或设备类型,生成对应的设备卡冻结指令,最后向用户终端推送设备卡冻结指令,用户终端接收设备卡冻结指令之后,便对设备卡进行冻结,使其无法运行;进而可以达到将所有与该账户相关的用户终端的相应支付功能都进行暂停的目的。
举例来说:当用户A有两个手机(手机1,手机2)同时装有京东闪付,使用手机1上的京东闪付乘车后离站,产生5元的车费,公交公司将5元离线扣款交易经银联发送至京东闪付,用户A的账户资金不足,此时用户已离开,京东闪付需强制承兑这笔交易,产生一笔5元垫资;产生欠款记录后,将用户A的闪付账户暂停,同时将用户A的手机1和手机2上的京东闪付功能暂停,这两个手机都不能使用京东闪付交易,并且新手机3..n都不允许加京东闪付卡。待用户还完款后,恢复账户及所有设备的状态允许交易。
如图5所示,在一些实施例中,如前述的处理方法,还包括如下所述步骤B1和B2:
步骤B1.在接收到账户的还款,且还款大于等于垫资时,生成还款成功信息。
步骤B2.根据还款成功信息恢复账户的支付功能。
具体的,当存在垫资的时候,用户需要针对垫资进行还款,并且,当还款小于垫资时,则账户还是处于欠款状态;若只通过还款行为判断是否恢复账户的支付功能是不可行的。
因此,本实施例中,必须在还款大于等于垫资时,才生成相应的还款成功信息,还款成功信息用于表征账户目前不存在欠款;此外,还款成功信息还可以包括:还款时间、还款金额、账户信息等信息。
在前述实施例中步骤B2以及步骤S10所举例子基础上,根据还款成功信息回复账户的支付功能具体可以包括:
1、根据还款成功信息在交易黑名单中查询得到对应的账户;
2、将账户移出交易黑名单;
3、根据预先得到的用于保存账户与设备信息之间的数据表,确定该账户对应的设备信息;
4、生成或调取用于对各个设备卡恢复使用的恢复指令,将该账户对应的设备的状态恢复为可用,进而达到恢复账户的支付功能的目的。
如图6所示,根据本申请另一方面的一种实施例,本申请提供了一种交易数据处理系统,包括:交易终端1、业务端2和交易数据处理端3;
交易终端1,用于在离线状态下确定账户所需扣款的交易金额;根据交易金额及账户生成对应的离线交易信息;将离线交易信息同步至业务端;
业务端2,用于根据离线交易信息生成扣款请求;按照预设的请求扣款周期,将扣款请求同步至业务对接系统;
交易数据处理端3,用于接收业务对接系统转发的扣款请求;根据扣款请求在账户中执行扣款;在账户执行扣款后的账户信息满足账户停用条件时,暂停账户的支付功能。
如图8所示,在一种可选的应用中,以公交乘车刷卡系统为例,具体的系统架构可以包括:手机(用户终端)、公交系统、闪付系统(交易数据处理端)、银联支付清算系统(CUPS,China UnionPay System;即业务对接系统)、短信平台、可信管理系统(TSM,TrustedService Management)、手机厂商/安全载体发行方;其中,公交系统包括:闸机(交易终端)及系统服务器(业务端)。
用户通过手机端的闪付卡,刷卡进站;
在用户刷卡出站之后,闸机可以在离线状态下实时记录用户的进站及出站的站点;
闸机根据记录的进站及出站站点计算用户当次的乘车车费,并在联网状态下定期将乘车车费上传至系统服务器;
系统服务器根据车费提交至银联支付清算系统请求扣款;
银联支付清算系统判断发卡机构为闪付系统;
银联支付清算系统将车费发送至闪付系统进行扣款;
闪付系统根据车费判断用户的账户中资金是否充足;当账户资金充足时直接扣款,当账户资金不足时,强制承兑,由闪付系统进行部分或全部垫资;
在强制承兑时,返回银联支付清算系统强制承兑成功信息;
银联支付清算系统根据强制承兑成功信息生成扣款成功信息,并且将扣款成功信息下发至公交系统;
在强制承兑时,闪付系统还产生与该用户的账户对应的欠款记录;
闪付系统生成与该欠款记录对应的一条欠款短信,并发送至短信平台;
短信平台将该欠款短信发送至用户的手机端;
在生成欠款短信的同时,闪付系统还对该账户进行冻结,并且可以找出账户对应的所有设备的设备卡,以防止用户通过其它设备卡恶意透支;
闪付系统对账户进行冻结的同时,生成设备卡冻结指令,并下发至可信管理系统;
可信管理系统根据手机厂商的区别,向不同的手机厂商系统下发不同的指令;
手机厂商系统向用户的手机端推送设备卡冻结指令;
在闪付系统对账户生成设备卡冻结指令之后,还生成冻结通知并下发至短信平台;
短信平台将冻结通知发送至手机端,使用户得知自己的设备卡已被禁用,需要其及时还款。
根据本申请的另一个实施例,还提供一种电子设备,包括:如图7所示,电子设备可以包括:处理器1501、通信接口1502、存储器1503和通信总线1504,其中,处理器1501,通信接口1502,存储器1503通过通信总线1504完成相互间的通信。
存储器1503,用于存放计算机程序;
处理器1501,用于执行存储器1503上所存放的程序时,实现上述方法实施例的步骤。
上述电子设备提到的总线可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(DigitalSignalProcessing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
本申请实施例还提供一种非暂态计算机可读存储介质,非暂态计算机可读存储介质存储计算机指令,计算机指令使计算机执行上述方法实施例的步骤。
需要说明的是,在本文中,诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本发明的具体实施方式,使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。
Claims (10)
1.一种交易数据处理方法,其特征在于,包括:
交易终端在离线状态下确定账户所需扣款的交易金额;
所述交易终端根据所述交易金额及账户生成对应的离线交易信息;
所述交易终端将所述离线交易信息同步至业务端;
所述业务端根据所述离线交易信息生成扣款请求;
所述业务端按照预设的请求扣款周期,将所述扣款请求同步至业务对接系统;
交易数据处理端接收所述业务对接系统转发的所述扣款请求;
所述交易数据处理端根据所述扣款请求在所述账户中执行扣款;
所述交易数据处理端在所述账户执行扣款后的账户信息满足账户停用条件时,暂停所述账户的支付功能。
2.根据权利要求1所述的处理方法,其特征在于,所述根据所述扣款请求在所述账户中执行扣款,包括:
所述交易数据处理端根据所述扣款请求确定所述账户的交易金额;
在所述账户中的金额大于所述交易金额时,所述交易数据处理端按照所述交易金额进行扣款,并向所述业务对接系统返回扣款成功信息;
所述业务端接收业务对接系统转发的扣款成功信息并完成交易;
在所述账户中的金额小于所述交易金额时,所述交易数据处理端按照所述交易金额进行扣款及垫资,并向所述业务对接系统返回垫资信息;
所述业务端在接收所述业务对接系统根据所述垫资信息生成的扣款成功信息后,判断交易完成。
3.根据权利要求2所述的处理方法,其特征在于,所述暂停所述账户的支付功能,包括:
所述交易数据处理端根据所述垫资确定所述账户的欠款信息;
所述交易数据处理端根据所述欠款信息将所述账户加入交易黑名单,以暂停所述账户的支付功能。
4.根据权利要求3所述的处理方法,其特征在于,在将所述账户加入交易黑名单之后,还包括:
所述交易数据处理端将所述交易黑名单发送至所述业务端;
所述业务端将所述交易黑名单转发至所述交易终端;
所述交易终端根据所述交易黑名单暂停与所述账户相关的所有交易。
5.根据权利要求3所述的处理方法,其特征在于,所述暂停所述账户的支付功能,包括:
根据所述扣款请求确定进行交易的用户终端的设备型号信息;
根据所述设备型号信息生成对应的账户暂停指令;
将所述账户暂停指令发送至所述用户终端,以暂停所述账户的支付功能。
6.根据权利要求1所述的处理方法,其特征在于,在暂停所述账户的支付功能之后,还包括:
所述交易数据处理端获取所述账户关联的所有用户终端;
所述交易数据处理端暂停所有所述用户终端上与所述账户相关的支付功能。
7.根据权利要求2所述的处理方法,其特征在于,还包括:
在接收到所述账户的还款,且所述还款大于等于所述垫资时,生成还款成功信息;
根据所述还款成功信息恢复所述账户的支付功能。
8.一种交易数据处理系统,其特征在于,包括:交易终端、业务端和交易数据处理端;
所述交易终端,用于在离线状态下确定账户所需扣款的交易金额;根据所述交易金额及账户生成对应的离线交易信息;将所述离线交易信息同步至所述业务端;
所述业务端,用于根据所述离线交易信息生成扣款请求;按照预设的请求扣款周期,将所述扣款请求同步至业务对接系统;
所述交易数据处理端,用于接收所述业务对接系统转发的所述扣款请求;根据所述扣款请求在所述账户中执行扣款;在所述账户执行扣款后的账户信息满足账户停用条件时,暂停所述账户的支付功能。
9.一种电子设备,其特征在于,包括:处理器、通信接口、存储器和通信总线,其中,所述处理器、通信接口和存储器通过通信总线完成相互间的通信;
所述存储器,用于存放计算机程序;
所述处理器,用于执行所述计算机程序时,实现权利要求1-7任一项所述的处理方法。
10.一种非暂态计算机可读存储介质,其特征在于,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行权利要求1-7任一项所述的处理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010171158.0A CN111353781B (zh) | 2020-03-12 | 2020-03-12 | 一种交易数据处理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010171158.0A CN111353781B (zh) | 2020-03-12 | 2020-03-12 | 一种交易数据处理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111353781A CN111353781A (zh) | 2020-06-30 |
CN111353781B true CN111353781B (zh) | 2023-04-07 |
Family
ID=71197472
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010171158.0A Active CN111353781B (zh) | 2020-03-12 | 2020-03-12 | 一种交易数据处理方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111353781B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113781036A (zh) * | 2021-09-03 | 2021-12-10 | 浙江创建科技有限公司 | 在非稳定网络环境下可信的公共交通身份认证和联机支付系统 |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090127332A1 (en) * | 2007-11-16 | 2009-05-21 | Kyung Yang Park | System for processing payment employing off-line transaction approval mode of mobile card and method thereof |
CN101359383A (zh) * | 2008-09-23 | 2009-02-04 | 中国移动通信集团广东有限公司 | 一种基于移动通信的非接触卡应用管理系统及管理方法 |
US20170011404A1 (en) * | 2015-07-10 | 2017-01-12 | Dyron Clower | Instant funds availablity risk assessment system and method |
CN106997527A (zh) * | 2016-01-25 | 2017-08-01 | 阿里巴巴集团控股有限公司 | 基于移动终端p2p的信用支付方法及装置 |
CN112990932A (zh) * | 2016-06-07 | 2021-06-18 | 华为技术有限公司 | 数据处理方法、相关装置及系统 |
CN110046881A (zh) * | 2018-11-19 | 2019-07-23 | 阿里巴巴集团控股有限公司 | 离线场景下的支付处理方法、服务器及可读存储介质 |
CN109523254B (zh) * | 2018-11-29 | 2023-04-28 | 湖北云雷信息技术有限公司 | 一种基于手机app通过双离线扫码的多种支付方法 |
CN110070355A (zh) * | 2019-03-11 | 2019-07-30 | 深圳市微付充科技有限公司 | 一种虚拟卡支付方法、移动设备 |
CN110390733A (zh) * | 2019-03-18 | 2019-10-29 | 深圳市迈圈信息技术有限公司 | 一种公交刷卡机控制方法、装置、及计算机设备 |
CN110298665A (zh) * | 2019-06-18 | 2019-10-01 | 四川商通实业有限公司 | 定向支付离线交易黑名单管理系统及方法 |
-
2020
- 2020-03-12 CN CN202010171158.0A patent/CN111353781B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN111353781A (zh) | 2020-06-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI640937B (zh) | Online payment method and equipment | |
US20170221053A1 (en) | Digital asset conversion | |
CN110458557B (zh) | 一种付款方法、设备及存储介质 | |
US10776771B2 (en) | Electronic resource processing method and device | |
WO2020038092A1 (zh) | 一种支付风控方法及系统 | |
US20150112780A1 (en) | Method and system for processing of a real-time rebate at transaction authorization | |
CN109615353B (zh) | 一种支付方法及装置 | |
CN108764872A (zh) | 一种授权支付方法及系统、设备和存储介质 | |
CN109102268A (zh) | 一种用于聚合支付对账的方法及设备 | |
CN110046995A (zh) | 退费请求处理方法、装置及设备 | |
CN111353781B (zh) | 一种交易数据处理方法及系统 | |
AU2018202367A1 (en) | Automatic data transfer | |
US20140156510A1 (en) | Method and system of providing financial transactions for the visually impaired | |
CN110874728A (zh) | 网上支付系统、网上支付方法、装置、介质及服务器 | |
US20220230155A1 (en) | Artificial intelligence (ai) architecture with smart, automated triggers of incoming and outgoing actions and usage | |
US20220230236A1 (en) | Artificial intelligence (ai) architecture with smart, automated triggers of incoming and outgoing actions and usage | |
JP2016110321A (ja) | 資金移動方法、システムおよびプログラム | |
US20230186260A1 (en) | Artificial intelligence (ai) architecture with smart, automated triggers of incoming and outgoing actions and usage | |
CN110473053A (zh) | 基于担保的风险控制方法和装置 | |
CN113435889B (zh) | 基于信用的交易处理方法及装置 | |
CN113592503A (zh) | 统一支付认证交易方法、服务器及系统 | |
CN112163858A (zh) | 一种交易方法、装置及设备 | |
KR102442526B1 (ko) | 결제 방법, 이를 수행하는 단말 및 서버 장치 | |
CN206348842U (zh) | 一种智能卡 | |
CN113077249A (zh) | 基于etc的账户清算方法及装置 |
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 |