CN116720861A - 基于用户解约的处理方法、装置以及设备 - Google Patents

基于用户解约的处理方法、装置以及设备 Download PDF

Info

Publication number
CN116720861A
CN116720861A CN202310658009.0A CN202310658009A CN116720861A CN 116720861 A CN116720861 A CN 116720861A CN 202310658009 A CN202310658009 A CN 202310658009A CN 116720861 A CN116720861 A CN 116720861A
Authority
CN
China
Prior art keywords
information
user
offer
merchant
processing 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.)
Pending
Application number
CN202310658009.0A
Other languages
English (en)
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.)
Bank of China Ltd
Original Assignee
Bank of China 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 Bank of China Ltd filed Critical Bank of China Ltd
Priority to CN202310658009.0A priority Critical patent/CN116720861A/zh
Publication of CN116720861A publication Critical patent/CN116720861A/zh
Pending legal-status Critical Current

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/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/405—Establishing or using transaction specific rules
    • 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3221—Access to banking information through M-devices
    • 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • 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/4014—Identity check for transactions
    • 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/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • 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/4015—Transaction verification using location information

Landscapes

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

Abstract

本申请提供一种基于用户解约的处理方法、装置以及设备，可用于金融领域或其他领域。该方法包括：响应于第一设备发起的解约处理请求，对解约处理请求进行验证；若确定对解约处理请求的验证通过，则生成与解约处理请求对应的解约信息；若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息。本申请的方法，保障了客户的权益，提升了客户的满意度。

Description

基于用户解约的处理方法、装置以及设备
技术领域
本申请涉及金融领域或其他领域，尤其涉及一种基于用户解约的处理方法、装置以及设备。
背景技术
随着信息技术的发展，银行的交易需要通过线上的系统完成交易处理过程。线上的系统为用户提供了定期扣款交易的服务。用户的银行卡和商户的设备之间建立了定期扣款合约之后，商户的设备可以定期向银行的服务器发起定期扣款请求，定期扣款请求用于请求从用户的银行卡中扣款。
现有技术中，用户可以请求对定期扣款交易的服务进行解约；用户的设备向商户的设备发起解约请求；商户的设备在接收到用户的设备发送的解约请求之后，需要商户的设备基于商户的触发进行解约的处理，进而在商户同意解约之后，商户的设备向银行的服务器发起同意解约信息；然后，银行的服务器才可以不会自动从用户的银行卡中扣款。
但是现有技术中，在用户请求对定期扣款交易的服务进行解约的时候，若商户自己拒绝同意解约，或者商户遗漏了用户发起的解约请求，则导致银行的服务器会定期的从用户的银行卡中扣款；导致给用户带来经济损失。
发明内容
本申请提供一种基于用户解约的处理方法、装置以及设备，用以解决在用户请求对定期扣款交易的服务进行解约的时候，银行的服务器依然会定期的从用户的银行卡中扣款的问题。
第一方面，本申请提供一种基于用户解约的处理方法，包括：
响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证；其中，所述解约处理请求中包括商户标识和用户标识，所述解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，所述第一设备为用户的设备；所述用户标识为用户唯一标识，和/或，用户的银行卡号；所述商户标识为第二设备的终端号；所述第二设备为商户的设备；
若确定对所述解约处理请求的验证通过，则生成与所述解约处理请求对应的解约信息；
若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，所述定期扣款请求为基于预设日期而定时发起的，所述定期扣款请求中包括商户标识和用户标识；所述解约列表中包括至少一个解约信息，所述解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，所述解约信息中包括商户标识和用户标识；
若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向所述第二设备发送第一反馈信息；其中，所述第一反馈信息表征所述定期扣款请求中的用户标识对应的用户账户已解约。
在一种可能的实现方式中，所述解约处理请求中包括位置信息；所述位置信息包括以下的任意一种：第一设备的地理位置信息、第一设备的IP地址信息、第一设备的国际移动设备识别码；
响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证，包括：
响应于第一设备发起的解约处理请求，确定与所述第一设备对应的用户登录信息；其中，所述用户登录信息中包括在历史时刻中对应的用户标识和位置信息，所述历史时刻为所述第一设备发出历史的解约处理请求或者历史的签约处理请求的时刻，所述签约处理请求用于请求进行定期扣款的签约处理；
若确定所述用户登录信息中包括所述解约处理请求中的位置信息，则确定对所述解约处理请求的验证通过，若确定所述用户登录信息中不包括所述解约处理请求中的位置信息，则确定对所述解约处理请求的验证不通过；或者，若确定所述用户登录信息中包括所述解约处理请求中的位置信息时，所述用户登录信息包括的所述解约处理请求中的位置信息的次数大于第一预设次数，则确定对所述解约处理请求的验证通过，若确定所述用户登录信息中包括所述解约处理请求中的位置信息时，所述用户登录信息包括的所述解约处理请求中的位置信息的次数小于等于第一预设次数，则确定对所述解约处理请求的验证不通过。
在一种可能的实现方式中，响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证，包括：
响应于第一设备发起的解约处理请求，向所述第一设备发送验证请求；
接收所述第一设备发送的验证信息；其中，所述验证信息包括以下的一种或多种：用户姓名、用户银行卡有效期、人脸信息、指纹信息；
若确定接收到的验证信息与预存的验证信息一致，则确定对所述解约处理请求的验证通过；
若确定接收到的验证信息与预存的验证信息不一致，则确定对所述解约处理请求的验证不通过。
在一种可能的实现方式中，响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证，包括：
响应于第一设备发起的解约处理请求，确定与所述第一设备对应的手机号码；
向与所述第一设备对应的手机号码的设备发送第一验证码；
若确定在第一预设时长内接收到所述手机号码的设备发送的第二验证码、且所述第二验证码与所述第一验证码一致，则确定对所述解约处理请求的验证通过；
若确定在第一预设时长内未接收到所述手机号码的设备发送的第二验证码，和/或，所述第二验证码与所述第一验证码不一致，则确定对所述解约处理请求的验证不通过。
在一种可能的实现方式中，在若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程之前，还包括：
若确定签约信息列表中包括与所述解约处理请求中的用户标识、商户标识均对应的签约信息，则执行若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程的步骤；
其中，所述签约信息列表中包括签约信息，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
在一种可能的实现方式中，在确定拒绝执行与定期扣款请求对应的交易过程之后，还包括：
在第二预设时长之后，若接收到下一次的定期扣款请求，则拒绝执行与下一次的定期扣款请求对应的交易过程。
在一种可能的实现方式中，所述方法，还包括：
若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识不匹配，则确定执行与定期扣款请求对应的交易过程。
在一种可能的实现方式中，对所述解约处理请求进行验证，包括：
若确定在第三预设时长内接收到所述第一设备发起的解约处理请求的次数，小于等于第二预设次数，则对所述第一设备当前所发起的解约处理请求进行验证。
在一种可能的实现方式中，所述方法还包括：
接收第一设备发送的签约请求；其中，所述签约请求中包括商户标识和用户标识，所述签约请求中还包括签约验证信息；
若对所述签约请求中的签约验证信息的验证成功，则生成签约信息；其中，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
在一种可能的实现方式中，所述方法还包括：
将解约信息存储至区块链的第一区块中；并将签约信息存储至区块链的第二区块中；其中，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
第二方面，本申请提供一种基于用户解约的处理装置，包括：
验证单元，用于响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证；其中，所述解约处理请求中包括商户标识和用户标识，所述解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，所述第一设备为用户的设备；所述用户标识为用户唯一标识，和/或，用户的银行卡号；所述商户标识为第二设备的终端号；所述第二设备为商户的设备；
第一生成单元，用于若确定对所述解约处理请求的验证通过，则生成与所述解约处理请求对应的解约信息；
查询单元，用于若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，所述定期扣款请求为基于预设日期而定时发起的，所述定期扣款请求中包括商户标识和用户标识；所述解约列表中包括至少一个解约信息，所述解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，所述解约信息中包括商户标识和用户标识；
第一确定单元，用于若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向所述第二设备发送第一反馈信息；其中，所述第一反馈信息表征所述定期扣款请求中的用户标识对应的用户账户已解约。
在一种可能的实现方式中，所述解约处理请求中包括位置信息；所述位置信息包括以下的任意一种：第一设备的地理位置信息、第一设备的IP地址信息、第一设备的国际移动设备识别码；
所述验证单元，包括：
第一确定模块，用于响应于第一设备发起的解约处理请求，确定与所述第一设备对应的用户登录信息；其中，所述用户登录信息中包括在历史时刻中对应的用户标识和位置信息，所述历史时刻为所述第一设备发出历史的解约处理请求或者历史的签约处理请求的时刻，所述签约处理请求用于请求进行定期扣款的签约处理；
第一处理模块，用于若确定所述用户登录信息中包括所述解约处理请求中的位置信息，则确定对所述解约处理请求的验证通过，若确定所述用户登录信息中不包括所述解约处理请求中的位置信息，则确定对所述解约处理请求的验证不通过；或者，若确定所述用户登录信息中包括所述解约处理请求中的位置信息时，所述用户登录信息包括的所述解约处理请求中的位置信息的次数大于第一预设次数，则确定对所述解约处理请求的验证通过，若确定所述用户登录信息中包括所述解约处理请求中的位置信息时，所述用户登录信息包括的所述解约处理请求中的位置信息的次数小于等于第一预设次数，则确定对所述解约处理请求的验证不通过。
在一种可能的实现方式中，所述验证单元，包括：
第一发送模块，用于响应于第一设备发起的解约处理请求，向所述第一设备发送验证请求；
接收模块，用于接收所述第一设备发送的验证信息；其中，所述验证信息包括以下的一种或多种：用户姓名、用户银行卡有效期、人脸信息、指纹信息；
第二处理模块，用于若确定接收到的验证信息与预存的验证信息一致，则确定对所述解约处理请求的验证通过；
第三处理模块，用于若确定接收到的验证信息与预存的验证信息不一致，则确定对所述解约处理请求的验证不通过。
在一种可能的实现方式中，所述验证单元，包括：
第二确定模块，用于响应于第一设备发起的解约处理请求，确定与所述第一设备对应的手机号码；
第二发送模块，用于向与所述第一设备对应的手机号码的设备发送第一验证码；
第四处理模块，用于若确定在第一预设时长内接收到所述手机号码的设备发送的第二验证码、且所述第二验证码与所述第一验证码一致，则确定对所述解约处理请求的验证通过；
第五处理模块，用于若确定在第一预设时长内未接收到所述手机号码的设备发送的第二验证码，和/或，所述第二验证码与所述第一验证码不一致，则确定对所述解约处理请求的验证不通过。
在一种可能的实现方式中，在所述第一确定单元之前，还包括：
第一处理单元，用于若确定签约信息列表中包括与所述解约处理请求中的用户标识、商户标识均对应的签约信息，则执行若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程的步骤；
其中，所述签约信息列表中包括签约信息，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
在一种可能的实现方式中，在所述第一确定单元之后，还包括：
第二处理单元，用于在第二预设时长之后，若接收到下一次的定期扣款请求，则拒绝执行与下一次的定期扣款请求对应的交易过程。
在一种可能的实现方式中，所述装置，还包括：
第二确定单元，用于若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识不匹配，则确定执行与定期扣款请求对应的交易过程。
在一种可能的实现方式中，所述验证单元，包括：
第三确定模块，用于若确定在第三预设时长内接收到所述第一设备发起的解约处理请求的次数，小于等于第二预设次数，则对所述第一设备当前所发起的解约处理请求进行验证。
在一种可能的实现方式中，所述装置还包括：
接收单元，用于接收第一设备发送的签约请求；其中，所述签约请求中包括商户标识和用户标识，所述签约请求中还包括签约验证信息；
第二生成单元，用于若对所述签约请求中的签约验证信息的验证成功，则生成签约信息；其中，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
在一种可能的实现方式中，所述装置还包括：
第一存储单元，用于将解约信息存储至区块链的第一区块中；
第二存储单元，用于将签约信息存储至区块链的第二区块中；
其中，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
第三方面，本申请提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；
所述存储器存储计算机执行指令；
所述处理器执行所述存储器存储的计算机执行指令，以实现上述第一方面提供的方法。
第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现上述第一方面提供的方法。
第五方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述第一方面提供的方法。
本申请提供的基于用户解约的处理方法、装置以及设备，银行的服务器响应于第一设备发起的解约处理请求，对解约处理请求进行验证，使银行的服务器可以验证第一设备发起的解约处理请求是否合法；若银行的服务器确定对解约处理请求的验证通过，那么银行的服务器就生成与解约处理请求对应的解约信息，保证了解约信息的合法性；如果银行的服务器接收到第二设备发起的定期扣款请求，那么银行的服务器响应于第二设备发起的定期扣款请求，查询解约列表，能够确认第二设备发起的定期扣款请求中，用户标识对应的用户账户与商户标识对应的商户账户是否已经解绑；如果银行的服务器确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，那么银行的服务器就确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息，保障了客户的权益，提升了客户的满意度。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1为本申请实施例的应用场景的示意图；
图2为本申请实施例提供的一种基于用户解约的处理方法的流程示意图；
图3为本申请实施例提供的另一种基于用户解约的处理方法的流程示意图；
图4为本申请实施例提供的一种基于用户解约的处理装置的结构示意图；
图5为本申请实施例提供的另一种基于用户解约的处理装置的结构示意图；
图6为本申请实施例提供的又一种基于用户解约的处理装置的结构示意图；
图7为本申请实施例提供一种电子设备的结构示意图；
图8为根据一示例性实施例示出的一种终端设备的框图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。
需要说明的是，本申请基于用户解约的处理方法、装置以及设备可用于金融领域或其他领域，也可用于除金融领域之外的任意领域，本申请基于用户解约的处理方法、装置以及设备的应用领域不做限定。
随着信息技术的发展，银行的交易需要通过线上的系统完成交易处理过程。线上的系统为用户提供了定期扣款交易的服务。用户的银行卡和商户的设备之间建立了定期扣款合约之后，商户的设备可以定期向银行的服务器发起定期扣款请求，定期扣款请求用于请求从用户的银行卡中扣款；然后，银行的服务器根据商户的设备发起的定期扣款请求，自动从用户的银行卡中扣款。
一个示例中，用户可以请求对定期扣款交易的服务进行解约；用户的设备向商户的设备发起解约请求。然后，商户的设备在接收到用户的设备发送的解约请求之后，需要商户的设备基于商户的触发进行解约的处理，进而在商户同意解约之后，商户的设备向银行的服务器发起同意解约信息。然后，银行的服务器才可以不会自动从用户的银行卡中扣款。
但是上述方式中，在用户请求对定期扣款交易的服务进行解约的时候，若商户自己拒绝同意解约，或者若商户遗漏了用户发起的解约请求，或者若商户恶意拒绝解约，则导致银行的服务器依然会定期的从用户的银行卡中扣款；引发用户要求商户退款的争议问题，导致给用户带来经济损失，导致用户的体验较差。
本申请提供的基于用户解约的处理方法、装置以及设备，旨在解决现有技术的如上技术问题。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
图1为本申请实施例的应用场景的示意图，如图1所示，用户的设备为第一设备01，商户的设备为第二设备02，银行的服务器03。银行的服务器03可以接收第一设备01发送的请求，并且银行的服务器03还可以接收第二设备02发送的请求；基于第一设备01、第二设备02以及银行的服务器03，可以完成本申请的实施例的方案。
图2为本申请实施例提供的一种基于用户解约的处理方法的流程示意图，如图2所示，该方法包括：
S201、响应于第一设备发起的解约处理请求，对解约处理请求进行验证；其中，解约处理请求中包括商户标识和用户标识，解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，第一设备为用户的设备；用户标识为用户唯一标识，和/或，用户的银行卡号；商户标识为第二设备的终端号，第二设备为商户的设备。
示例性地，本实施例的执行主体可以为银行的服务器。
第一设备基于用户的操作，向银行的服务器发送解约处理请求。其中，第一设备为用户的设备；解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，解约处理请求包括商户标识和用户标识；用户标识为用户唯一标识，和/或，用户的银行卡号；商户标识为第二设备的终端号，第二设备为商户的设备。
银行的服务器在接收到第一设备发送的解约处理请求之后，银行的服务器对第一设备当前所发起的解约处理请求的合法性进行验证。
通过上述技术手段，银行的服务器可以验证第一设备发起的解约处理请求的合法性。
S202、若确定对解约处理请求的验证通过，则生成与解约处理请求对应的解约信息。
示例性地，如果银行的服务器验证到解约处理请求是合法的，那么银行的服务器就确定对解约处理请求的验证通过，银行的服务器就生成与解约处理请求对应的解约信息。其中，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
S203、若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识；解约列表中包括至少一个解约信息，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
示例性地，第二设备自动地向银行的服务器发送定期扣款请求。或者，第二设备基于商户的操作，向银行的服务器发送定期扣款请求。其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识。一个示例中，第二设备在每个月1日自动地向银行的服务器发送定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。或者，另一个示例中，第二设备基于商户的操作，在每个月1日向银行的服务器发送定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。
银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器在解约列表中查询，是否存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配。其中，解约列表中包括至少一个解约信息，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。一个示例中，本申请设置了一个银行探针，银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器使用银行探针在解约列表中查询，是否存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配。其中，解约列表中包括4个解约信息：解约信息1、解约信息2、解约信息3、解约信息4，其中，解约信息1中包括商户标识a和用户标识b，解约信息2中包括商户标识a和用户标识c，解约信息3中包括商户标识d和用户标识b，解约信息4中包括商户标识d和用户标识e。
S204、若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识对应的用户账户已解约。
示例性地，如果银行的服务器确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，那么银行的服务器就拒绝执行与定期扣款请求对应的交易过程，并且将一反馈信息发送给第二设备。其中，第一反馈信息表征定期扣款请求中的用户标识对应的用户账户已解约。
一个示例中，如果银行的服务器确定解约列表中存在解约信息1与定期扣款请求所携带的商户标识a、用户标识b均匹配，那么银行的服务器就确定拒绝执行与当前次的定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识b对应的用户账户已解约。
本实施例，银行的服务器响应于第一设备发起的解约处理请求，对解约处理请求进行验证，使银行的服务器可以验证第一设备发起的解约处理请求是否合法；若银行的服务器确定对解约处理请求的验证通过，那么银行的服务器就生成与解约处理请求对应的解约信息，保证了解约信息的合法性；如果银行的服务器接收到第二设备发起的定期扣款请求，那么银行的服务器响应于第二设备发起的定期扣款请求，查询解约列表，能够确认第二设备发起的定期扣款请求中，用户标识对应的用户账户与商户标识对应的商户账户是否已经解绑；如果银行的服务器确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，那么银行的服务器就确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息，保障了客户的权益，提升了客户的满意度。
图3为本申请实施例提供的另一种基于用户解约的处理方法的流程示意图，如图3所示，该方法包括：
S301、接收第一设备发送的签约请求；其中，签约请求中包括商户标识和用户标识，签约请求中还包括签约验证信息。
示例性地，本实施例的执行主体可以为银行的服务器。
线上的系统为用户提供了定期扣款交易的服务。用户的银行卡和商户的设备之间可以建立定期扣款合约。
在用户需要与商户之间建立定期扣款合约的时候，用户可以通过商户网站进行签约。此时，用户操作第一设备，第一设备显示有商户网站；进而用户通过在第一设备上操作商户网站发起签约的请求，第一设备生成签约请求。其中，签约请求中包括商户标识、用户标识以及签约验证信息。商户标识为用户需要签约的商户的商户标识，用户标识为当前的用户的标识；签约验证信息包括用户身份证明文件、用户人脸图像、用户指纹、用户个人信息、等等。第一设备将签约请求发送给银行的服务器。
或者，用户前往商户的客户现场，用户在客户现场完成签约。此时，用户操作自己的第一设备，进而第一设备生成签约请求；或者，用户操作商户所提供的第一设备，进而第一设备生成签约请求。其中，签约请求中包括商户标识、用户标识以及签约验证信息。商户标识为用户需要签约的商户的商户标识，用户标识为当前的用户的标识；签约验证信息包括用户身份证明文件、用户人脸图像、用户指纹、用户个人信息、等等。第一设备将签约请求发送给银行的服务器。
进而银行的服务器接收到第一设备发送的签约请求。
S302、若对签约请求中的签约验证信息的验证成功，则生成签约信息；其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
示例性地，银行的服务器验证签约请求中的签约验证信息的合法性。其中，签约验证信息包括用户身份证明文件、用户人脸图像、用户指纹、用户个人信息、等等。如果签约验证信息是合法的，银行的服务器对签约请求中的签约验证信息的验证成功，银行的服务器就生成签约信息。其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。一个示例中，银行的服务器验证签约请求中的签约验证信息的合法性，包括，银行的服务器验证用户身份证明文件是合法的、用户人脸图像完整清晰、用户指纹完整清晰、用户个人信息完整、等等。如果签约请求中的签约验证信息是合法的，银行的服务器对签约请求中的签约验证信息的验证成功，银行的服务器就生成签约信息。其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
通过本步骤的方法，银行的服务器可以保证签约信息的合法性。
S303、将签约信息存储至区块链的第二区块中；其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
示例性地，银行的服务器将签约信息存储至区块链的第二区块中。其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
通过本步骤的方法，银行的服务器将签约信息进行存储，之后银行的服务器可以直接调用签约信息。
S304、响应于第一设备发起的解约处理请求，若确定在第三预设时长内接收到第一设备发起的解约处理请求的次数，小于等于第二预设次数，则对第一设备当前所发起的解约处理请求进行验证；其中，解约处理请求中包括商户标识和用户标识，解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，第一设备为用户的设备；用户标识为用户唯一标识，和/或，用户的银行卡号；商户标识为第二设备的终端号。
一个示例中，解约处理请求中包括位置信息；位置信息包括以下的任意一种：第一设备的地理位置信息、第一设备的IP地址信息、第一设备的国际移动设备识别码。
一个示例中，步骤S304包括以下几种实现方式：
步骤S304的第一种实现方式、响应于第一设备发起的解约处理请求，确定与第一设备对应的用户登录信息；其中，用户登录信息中包括在历史时刻中对应的用户标识和位置信息，历史时刻为第一设备发出历史的解约处理请求或者历史的签约处理请求的时刻，签约处理请求用于请求进行定期扣款的签约处理。
若确定用户登录信息中包括解约处理请求中的位置信息，则确定对解约处理请求的验证通过，若确定用户登录信息中不包括解约处理请求中的位置信息，则确定对解约处理请求的验证不通过。或者，若确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数大于第一预设次数，则确定对解约处理请求的验证通过；若确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数小于等于第一预设次数，则确定对解约处理请求的验证不通过。
步骤S304的第二种实现方式、响应于第一设备发起的解约处理请求，向第一设备发送验证请求。接收第一设备发送的验证信息；其中，验证信息包括以下的一种或多种：用户姓名、用户银行卡有效期、人脸信息、指纹信息。若确定接收到的验证信息与预存的验证信息一致，则确定对解约处理请求的验证通过。若确定接收到的验证信息与预存的验证信息不一致，则确定对解约处理请求的验证不通过。
步骤S304的第三种实现方式、响应于第一设备发起的解约处理请求，确定与第一设备对应的手机号码。向与第一设备对应的手机号码的设备发送第一验证码。若确定在第一预设时长内接收到手机号码的设备发送的第二验证码、且第二验证码与第一验证码一致，则确定对解约处理请求的验证通过。若确定在第一预设时长内未接收到手机号码的设备发送的第二验证码，和/或，第二验证码与第一验证码不一致，则确定对解约处理请求的验证不通过。
示例性地，第一设备基于用户的操作，向银行的服务器发起解约处理请求。其中，第一设备为用户的设备；解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，解约处理请求中包括商户标识、用户标识、位置信息；用户标识为用户唯一标识，和/或，用户的银行卡号；商户标识为第二设备的终端号；位置信息包括以下的任意一种：第一设备的地理位置信息、第一设备的IP地址信息、第一设备的国际移动设备识别码。国际移动设备识别码(International Mobile Equipment Identity，IMEI)为设备的唯一标识码。
银行的服务器在接收到第一设备发送的解约处理请求之后，银行的服务器确定在第三预设时长内接收到第一设备发起的解约处理请求的次数。如果银行的服务器确定在第三预设时长内接收到第一设备发起的解约处理请求的次数，小于等于第二预设次数，那么就对第一设备当前所发起的解约处理请求进行验证。一个示例中，银行的服务器在接收到第一设备发送的解约处理请求之后，银行的服务器确定在一个月内接收到第一设备发起的解约处理请求的次数。如果银行的服务器确定在一个月内接收到第一设备发起的解约处理请求的次数，小于等于2次，那么就对第一设备当前所发起的解约处理请求进行验证；如果银行的服务器确定在一个月内接收到第一设备发起的解约处理请求的次数，大于2次，那么就不对第一设备当前所发起的解约处理请求进行验证，然后将解约处理请求不通过信息发送给第一设备。
其中，对第一设备当前所发起的解约处理请求进行验证，可以采用以下几种方式。
第一种方式。第一设备基于用户的操作，向银行的服务器发送解约处理请求，银行的服务器在接收到第一设备发送的解约处理请求之后，银行的服务器确定与第一设备对应的用户登录信息。其中，用户登录信息中包括在历史时刻中对应的用户标识和位置信息，历史时刻为第一设备发出历史的解约处理请求或者历史的签约处理请求的时刻，签约处理请求用于请求进行定期扣款的签约处理。
银行的服务器分析用户登录信息中的位置信息、解约处理请求中的位置信息。一种方式，如果银行的服务器确定用户登录信息中包括解约处理请求中的位置信息，那么银行的服务器就确定对解约处理请求的验证通过；如果银行的服务器确定用户登录信息中不包括解约处理请求中的位置信息，那么银行的服务器就确定对解约处理请求的验证不通过。或者，另一种方式，如果银行的服务器确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数大于第一预设次数，那么银行的服务器就确定对解约处理请求的验证通过；如果银行的服务器确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数小于等于第一预设次数，那么银行的服务器就确定对解约处理请求的验证不通过。一个示例中，银行的服务器分析用户登录信息中的位置信息、解约处理请求中的位置信息。如果银行的服务器确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数大于2次，那么银行的服务器就确定对解约处理请求的验证通过；如果银行的服务器确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数小于等于2次，那么银行的服务器就确定对解约处理请求的验证不通过。
第二种方式。第一设备基于用户的操作，向银行的服务器发送解约处理请求，银行的服务器在接收到第一设备发送的解约处理请求之后，银行的服务器向第一设备发送验证请求。
第一设备在接收到银行的服务器发送的验证请求之后，第一设备基于用户的操作，向银行的服务器发送验证信息。其中，验证信息包括以下的一种或多种：用户姓名、用户银行卡有效期、人脸信息、指纹信息。银行的服务器接收到第一设备发送的验证信息。银行的服务器分析第一设备发送的验证信息、预存的验证信息。如果银行的服务器确定接收到的验证信息与预存的验证信息一致，那么银行的服务器就确定对解约处理请求的验证通过；如果银行的服务器确定接收到的验证信息与预存的验证信息不一致，那么银行的服务器就确定对解约处理请求的验证不通过。一个示例中，第一设备基于用户的操作，向银行的服务器发送的验证信息。其中，验证信息包括两项：用户姓名、人脸信息。银行的服务器接收到第一设备发送的验证信息。如果第一设备发送的用户姓名、人脸信息与银行的服务器预存的用户姓名、人脸信息，两项验证信息均一致，那么银行的服务器就确定对解约处理请求的验证通过；如果第一设备发送的用户姓名、人脸信息与银行的服务器预存的用户姓名、人脸信息，两项验证信息中至少一项验证信息不一致，那么银行的服务器就确定对解约处理请求的验证不通过。或者，另一个示例中，第一设备向银行的服务器发送的验证信息。其中，验证信息包括三项：用户姓名、用户银行卡有效期、人脸信息。银行的服务器接收到第一设备发送的验证信息。如果第一设备发送的用户姓名、用户银行卡有效期、人脸信息与银行的服务器预存的用户姓名、用户银行卡有效期、人脸信息，三项验证信息均一致，那么银行的服务器就确定对解约处理请求的验证通过；如果第一设备发送的用户姓名、用户银行卡有效期、人脸信息与银行的服务器预存的用户姓名、用户银行卡有效期、人脸信息，三项验证信息中至少一项验证信息不一致，那么银行的服务器就确定对解约处理请求的验证不通过。
第三种方式。第一设备基于用户的操作，向银行的服务器发送解约处理请求，银行的服务器在接收到第一设备发送的解约处理请求之后，银行的服务器确定与第一设备对应的手机号码。
银行的服务器向手机号码的设备发送第一验证码，手机号码的设备接收到银行的服务器发送的第一验证码，第一设备基于用户的操作，向银行的服务器发送第二验证码。如果银行的服务器确定在第一预设时长内接收到手机号码的设备发送的第二验证码、且第二验证码与第一验证码一致，那么银行的服务器就确定对解约处理请求的验证通过。如果银行的服务器确定在第一预设时长内未接收到手机号码的设备发送的第二验证码，和/或，第二验证码与第一验证码不一致，那么银行的服务器就确定对解约处理请求的验证不通过。一个示例中，银行的服务器向手机号码的设备发送验证码10001，手机号码的设备接收到银行的服务器发送的验证码10001，第一设备基于用户的操作，向银行的服务器发送验证码10001，如果银行的服务器在发出验证码之后1分钟内接收到第一设备发送的验证码10001，银行的服务器就确定对解约处理请求的验证通过；如果银行的服务器在发出验证码之后1分钟之后接收到第一设备发送的验证码10001，银行的服务器就确定对解约处理请求的验证不通过。或者，另一个示例中，银行的服务器向手机号码的设备发送验证码10002，手机号码的设备接收到银行的服务器发送的验证码10002，第一设备基于用户的操作，向银行的服务器发送验证码10003，银行的服务器在发出验证码之后1分钟内，和/或，1分钟之后接收到第一设备发送的验证码10003，那么银行的服务器就确定对解约处理请求的验证不通过。或者，另一个示例中，银行的服务器向手机号码的设备发送验证码10004，手机号码的设备接收到银行的服务器发送的验证码10004，用户没有通过第一设备向银行的服务器发送验证码，银行的服务器在发出验证码之后1分钟内没有接收到第一设备发送的验证码10004，那么银行的服务器就确定对解约处理请求的验证不通过。
通过本步骤的方法，避免了用户频繁的解约、签约，银行的服务器验证了解约处理请求的真实性、合法性。
S305、若确定对解约处理请求的验证通过，则生成与解约处理请求对应的解约信息。
示例性地，如果银行的服务器确定对解约处理请求的验证通过，那么银行的服务器就生成与解约处理请求对应的解约信息。其中，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
通过本步骤的方法，银行的服务器保证了解约处理请求的真实性、合法性。
S306、将解约信息存储至区块链的第一区块中。
示例性地，银行的服务器将解约信息存储至区块链的第一区块中。其中，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
通过本步骤的方法，银行的服务器将解约信息进行存储，之后银行的服务器可以直接调用解约信息。
S307、若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识；解约列表中包括至少一个解约信息，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
示例性地，第二设备自动地向银行的服务器发送定期扣款请求。或者，第二设备基于商户的操作，向银行的服务器发送定期扣款请求。其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识。一个示例中，第二设备在每个月1日自动地向银行的服务器发送定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。或者，另一个示例中，第二设备基于商户的操作，在每个月1日向银行的服务器发送定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。
银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器在解约列表中查询，是否存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配。其中，解约列表中包括至少一个解约信息，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。一个示例中，银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器在解约列表中查询，是否存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配。其中，解约列表中包括4个解约信息：解约信息1、解约信息2、解约信息3、解约信息4，其中，解约信息1中包括商户标识a和用户标识b，解约信息2中包括商户标识a和用户标识c，解约信息3中包括商户标识d和用户标识b，解约信息4中包括商户标识d和用户标识e。
通过本步骤的方法，银行的服务器能够确认第二设备发起的定期扣款请求中，用户标识对应的用户账户与商户标识对应的商户账户是否已经解绑。
S308、若确定签约信息列表中包括与解约处理请求中的用户标识、商户标识均对应的签约信息，则执行步骤S309。
其中，签约信息列表中包括签约信息，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
示例性地，第二设备自动地向银行的服务器发送定期扣款请求。或者，第二设备基于商户的操作，向银行的服务器发送定期扣款请求。其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识。
银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器在签约信息列表中查询，是否包括与解约处理请求中的用户标识、商户标识均对应的签约信息。其中，签约信息列表中包括签约信息，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。如果银行的服务器确定签约信息列表中包括与解约处理请求中的用户标识、商户标识均对应的签约信息，那么银行的服务器就执行步骤S309；如果银行的服务器确定签约信息列表中不包括与解约处理请求中的用户标识、商户标识均对应的签约信息，那么银行的服务器就确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第二反馈信息。其中，第二反馈信息表征定期扣款请求中的用户标识对应的用户账户与商户标识对应的商户账户之间未签约。
一个示例中，第二设备在每个月1日自动地向银行的服务器发送定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。
银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器在签约信息列表中查询，是否包括与解约处理请求中的用户标识、商户标识均对应的签约信息。其中，签约列表中包括4个签约信息：签约信息1、签约信息2、签约信息3、签约信息4，其中，签约信息1中包括商户标识a和用户标识b，签约信息2中包括商户标识a和用户标识c，签约信息3中包括商户标识d和用户标识b，签约信息4中包括商户标识d和用户标识e。
银行的服务器确定签约信息列表中包括与解约处理请求中的用户标识a、商户标识b均对应的签约信息1，银行的服务器执行步骤S309。
或者，另一个示例中，第二设备基于商户的操作，在每个月1日向银行的服务器发送定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识f。
银行的服务器在接收到第二设备发送的定期扣款请求之后，银行的服务器在签约信息列表中查询，是否包括与解约处理请求中的用户标识、商户标识均对应的签约信息。其中，签约列表中包括4个签约信息：签约信息1、签约信息2、签约信息3、签约信息4，其中，签约信息1中包括商户标识a和用户标识b，签约信息2中包括商户标识a和用户标识c，签约信息3中包括商户标识d和用户标识b，签约信息4中包括商户标识d和用户标识e。
银行的服务器确定签约信息列表中不包括与解约处理请求中的用户标识a、商户标识f均对应的签约信息，银行的服务器就确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第二反馈信息。其中，第二反馈信息表征定期扣款请求中的用户标识对应的用户账户与商户标识对应的商户账户之间未签约。
通过本步骤的方法，银行的服务器能够确认第二设备发起的定期扣款请求中，用户标识对应的用户账户与商户标识对应的商户账户之前是否签过约，保证了定期扣款请求的真实性。
S309、若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识对应的用户账户已解约。
示例性地，如果银行的服务器确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，那么银行的服务器就确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识对应的用户账户已解约。
一个示例中，如果银行的服务器确定解约列表中存在解约信息1与定期扣款请求所携带的商户标识a、用户标识b均匹配，那么银行的服务器就确定拒绝执行与当前次的定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识b对应的用户账户已解约。
通过本步骤的方法，保障了客户的权益，提升了客户的满意度。
S310、在第二预设时长之后，若接收到下一次的定期扣款请求，则拒绝执行与下一次的定期扣款请求对应的交易过程。
示例性地，在第二预设时长之后，如果第二设备自动地向银行的服务器发送下一次的定期扣款请求，或者，第二设备基于商户的操作，向银行的服务器发送下一次的定期扣款请求，银行的服务器接收到第二设备发送的下一次的定期扣款请求，那么银行的服务器就拒绝执行与下一次的定期扣款请求对应的交易过程。
一个示例中，在一个月之后，如果第二设备自动地向银行的服务器发送下一次的定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。或者，第二设备基于商户的操作，向银行的服务器发送下一次的定期扣款请求，其中，定期扣款请求包括商户标识a、用户标识b。银行的服务器接收到第二设备发送的下一次的定期扣款请求，那么银行的服务器就拒绝执行与下一次的定期扣款请求对应的交易过程。
S311、若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识不匹配，则确定执行与定期扣款请求对应的交易过程。
示例性地，如果银行的服务器确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识不匹配，那么银行的服务器就确定执行与定期扣款请求对应的交易过程。一个示例中，如果银行的服务器确定解约列表中不存在解约信息与定期扣款请求所携带的商户标识a、用户标识b均匹配，那么银行的服务器就确定执行与当前次的定期扣款请求对应的交易过程。
通过本步骤的方法，银行的服务器能够确认第二设备发起的定期扣款请求中，用户标识对应的用户账户与商户标识对应的商户账户仍然处于签约状态，保证了定期扣款请求对应的交易过程的合法性。
图4为本申请实施例提供的一种基于用户解约的处理装置的结构示意图，如图4所示，该装置400包括三个模块，分别为：客户定期交易识别模块401、客户定期交易解约商户管理模块402、客户定期交易解约商户检查模块403。
其中，客户定期交易识别模块401，用于银行的服务器识别出客户针对客户银行卡发起的定期扣款交易。这个模块在商户发起定期扣款交易后，银行的服务器获取交易的银行卡号、交易的商户名称、交易的商户终端号(商户终端号是签约商户的唯一识别)、交易日期、交易金额等信息，银行的服务器把相关信息存到定期交易数据表中。当客户需要设置定期交易名单时，银行的服务器把客户已经发生的定期扣款交易信息传送给客户定期交易解约商户管理模块。
客户定期交易解约商户管理模块402，用于客户针对客户银行卡的定期扣款交易，客户可以新增、修改、查询、删除定期交易解约商户名单数据表中记录的数据。这个模块在客户通知银行的服务器去查询客户银行卡已经发起的定期扣款交易，客户要求银行的服务器拒绝此银行卡在具体的商户进行定期扣款交易或者重新允许此银行卡在具体的商户进行定期扣款交易时，客户输入银行卡号、商户名称、商户唯一终端号、黑名单生效标识等信息，银行的服务器把客户输入的银行卡号、商户名称、商户唯一终端号、黑名单生效标识、当前设置日期等信息记录到定期交易解约商户名单数据表中。其中，黑名单生效标识表征客户与具体的商户之间需要解约，客户要求银行的服务器不要执行当前扣款。客户与具体的商户解约后，可以再次与该商户签约，此时，黑名单生效标识为失效。银行的服务器限制客户每月只能解约2次，并且如果客户与具体的商户解约，不允许客户与该商户当天再续约。
客户定期交易解约商户检查模块403，用于在银行的服务器识别出定期扣款交易时，银行的服务器使用定期扣款交易中的信息，匹配定期交易解约商户名单数据表中记录的数据，如果匹配上了，银行的服务器就拒绝当前次扣款交易。这个模块在银行的服务器收到商户发起的定期交扣款易，银行的服务器识别出定期扣款交易时，银行的服务器使用定期扣款交易中的银行卡号、商户唯一终端号，查询客户定期交易解约商户管理模块中定期交易解约商户名单数据表，如果查询到与商户发起的定期扣款交易匹配的定期扣款交易，并且判断黑名单生效标识为已经生效，银行的服务器会拒绝当前次商户定期扣款交易。如果查询不到与商户发起的定期扣款交易匹配的定期扣款交易，银行的服务器会执行当前次商户定期扣款交易。
其中，客户不需要每次都设置客户定期交易解约商户管理模块，在客户有需要的时候再进行设置。银行的服务器每次执行定期交易解约商户名单检查模块时，都需要访问定期交易解约商户名单数据表。
本实施例提供的装置，可以参见上述实施例提供的方法，技术过程和效果相同，不再赘述。
图5为本申请实施例提供的另一种基于用户解约的处理装置的结构示意图，如图5所示，该装置500，包括：
验证单元501，用于响应于第一设备发起的解约处理请求，对解约处理请求进行验证；其中，解约处理请求中包括商户标识和用户标识，解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，第一设备为用户的设备；用户标识为用户唯一标识，和/或，用户的银行卡号；商户标识为第二设备的终端号；第二设备为商户的设备。
第一生成单元502，用于若确定对解约处理请求的验证通过，则生成与解约处理请求对应的解约信息。
查询单元503，用于若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识；解约列表中包括至少一个解约信息，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
第一确定单元504，用于若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识对应的用户账户已解约。
本实施例提供的装置，可以参见上述实施例提供的方法，技术过程和效果相同，不再赘述。
图6为本申请实施例提供的又一种基于用户解约的处理装置的结构示意图，如图6所示，该装置600，包括：
验证单元601，用于响应于第一设备发起的解约处理请求，对解约处理请求进行验证；其中，解约处理请求中包括商户标识和用户标识，解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，第一设备为用户的设备；用户标识为用户唯一标识，和/或，用户的银行卡号；商户标识为第二设备的终端号；第二设备为商户的设备。
第一生成单元602，用于若确定对解约处理请求的验证通过，则生成与解约处理请求对应的解约信息。
查询单元603，用于若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，定期扣款请求为基于预设日期而定时发起的，定期扣款请求中包括商户标识和用户标识；解约列表中包括至少一个解约信息，解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，解约信息中包括商户标识和用户标识。
第一确定单元604，用于若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向第二设备发送第一反馈信息；其中，第一反馈信息表征定期扣款请求中的用户标识对应的用户账户已解约。
一个示例中，解约处理请求中包括位置信息；位置信息包括以下的任意一种：第一设备的地理位置信息、第一设备的IP地址信息、第一设备的国际移动设备识别码。
验证单元601，包括：
第一确定模块6011，用于响应于第一设备发起的解约处理请求，确定与第一设备对应的用户登录信息；其中，用户登录信息中包括在历史时刻中对应的用户标识和位置信息，历史时刻为第一设备发出历史的解约处理请求或者历史的签约处理请求的时刻，签约处理请求用于请求进行定期扣款的签约处理。
第一处理模块6012，用于若确定用户登录信息中包括解约处理请求中的位置信息，则确定对解约处理请求的验证通过，若确定用户登录信息中不包括解约处理请求中的位置信息，则确定对解约处理请求的验证不通过；或者，若确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数大于第一预设次数，则确定对解约处理请求的验证通过，若确定用户登录信息中包括解约处理请求中的位置信息时，用户登录信息包括的解约处理请求中的位置信息的次数小于等于第一预设次数，则确定对解约处理请求的验证不通过。
一个示例中，验证单元601，包括：
第一发送模块6013，用于响应于第一设备发起的解约处理请求，向第一设备发送验证请求。
接收模块6014，用于接收第一设备发送的验证信息；其中，验证信息包括以下的一种或多种：用户姓名、用户银行卡有效期、人脸信息、指纹信息。
第二处理模块6015，用于若确定接收到的验证信息与预存的验证信息一致，则确定对解约处理请求的验证通过。
第三处理模块6016，用于若确定接收到的验证信息与预存的验证信息不一致，则确定对解约处理请求的验证不通过。
一个示例中，验证单元601，包括：
第二确定模块6017，用于响应于第一设备发起的解约处理请求，确定与第一设备对应的手机号码。
第二发送模块6018，用于向与第一设备对应的手机号码的设备发送第一验证码。
第四处理模块6019，用于若确定在第一预设时长内接收到手机号码的设备发送的第二验证码、且第二验证码与第一验证码一致，则确定对解约处理请求的验证通过。
第五处理模块6020，用于若确定在第一预设时长内未接收到手机号码的设备发送的第二验证码，和/或，第二验证码与第一验证码不一致，则确定对解约处理请求的验证不通过。
一个示例中，在第一确定单元604之前，还包括：
第一处理单元605，用于若确定签约信息列表中包括与解约处理请求中的用户标识、商户标识均对应的签约信息，则执行若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程的步骤。
其中，签约信息列表中包括签约信息，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
一个示例中，在第一确定单元604之后，还包括：
第二处理单元606，用于在第二预设时长之后，若接收到下一次的定期扣款请求，则拒绝执行与下一次的定期扣款请求对应的交易过程。
一个示例中，装置600，还包括：
第二确定单元607，用于若确定解约列表中存在解约信息与定期扣款请求所携带的商户标识、用户标识不匹配，则确定执行与定期扣款请求对应的交易过程。
一个示例中，验证单元601，包括：
第三确定模块6021，用于若确定在第三预设时长内接收到第一设备发起的解约处理请求的次数，小于等于第二预设次数，则对第一设备当前所发起的解约处理请求进行验证。
一个示例中，装置600还包括：
接收单元608，用于接收第一设备发送的签约请求；其中，签约请求中包括商户标识和用户标识，签约请求中还包括签约验证信息。
第二生成单元609，用于若对签约请求中的签约验证信息的验证成功，则生成签约信息；其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
一个示例中，装置600还包括：
第一存储单元610，用于将解约信息存储至区块链的第一区块中
第二存储单元611，用于将签约信息存储至区块链的第二区块中。
其中，签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，签约信息中包括商户标识和用户标识。
本实施例提供的装置，可以参见上述实施例提供的方法，技术过程和效果相同，不再赘述。
图7为本申请实施例提供一种电子设备的结构示意图，如图7所示，该电子设备，包括：发送器701、接收器702、存储器703和处理器704。
存储器703，用于存储计算机指令。
处理器704，用于运行存储器703存储的计算机指令实现前述实施例提供任一实现方式的方法的技术方案。
接收器702，用于接收其他设备发送的指令和数据。
发送器701，用于向外部设备发送指令和数据。
图8为根据一示例性实施例示出的一种终端设备的框图，该设备可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。
装置800可以包括以下一个或多个组件：处理组件802，存储器804，电源组件806，多媒体组件808，音频组件810，输入/输出(I/O)接口812，传感器组件814，以及通信组件816。
处理组件802通常控制装置800的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件802可以包括一个或多个处理器820来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件802可以包括一个或多个模块，便于处理组件802和其他组件之间的交互。例如，处理组件802可以包括多媒体模块，以方便多媒体组件808和处理组件802之间的交互。
存储器804被配置为存储各种类型的数据以支持在装置800的操作。这些数据的示例包括用于在装置800上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器804可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
电源组件806为装置800的各种组件提供电力。电源组件806可以包括电源管理系统，一个或多个电源，及其他与为装置800生成、管理和分配电力相关联的组件。
多媒体组件808包括在所述装置800和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件808包括一个前置摄像头和/或后置摄像头。当装置800处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。
音频组件810被配置为输出和/或输入音频信号。例如，音频组件810包括一个麦克风(MIC)，当装置800处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器804或经由通信组件816发送。在一些实施例中，音频组件810还包括一个扬声器，用于输出音频信号。
I/O接口812为处理组件802和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
传感器组件814包括一个或多个传感器，用于为装置800提供各个方面的状态评估。例如，传感器组件814可以检测到装置800的打开/关闭状态，组件的相对定位，例如所述组件为装置800的显示器和小键盘，传感器组件814还可以检测装置800或装置800一个组件的位置改变，用户与装置800接触的存在或不存在，装置800方位或加速/减速和装置800的温度变化。传感器组件814可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件814还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件814还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。
通信组件816被配置为便于装置800和其他设备之间有线或无线方式的通信。装置800可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件816经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件816还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。
在示例性实施例中，装置800可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。
在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器804，上述指令可由装置800的处理器820执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本申请还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现上述实施例提供的方法。
本申请还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述实施例提供的方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (13)

1.一种基于用户解约的处理方法，其特征在于，所述方法包括：
响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证；其中，所述解约处理请求中包括商户标识和用户标识，所述解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，所述第一设备为用户的设备；所述用户标识为用户唯一标识，和/或，用户的银行卡号；所述商户标识为第二设备的终端号；所述第二设备为商户的设备；
若确定对所述解约处理请求的验证通过，则生成与所述解约处理请求对应的解约信息；
若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，所述定期扣款请求为基于预设日期而定时发起的，所述定期扣款请求中包括商户标识和用户标识；所述解约列表中包括至少一个解约信息，所述解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，所述解约信息中包括商户标识和用户标识；
若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向所述第二设备发送第一反馈信息；其中，所述第一反馈信息表征所述定期扣款请求中的用户标识对应的用户账户已解约。
2.根据权利要求1所述的方法，其特征在于，所述解约处理请求中包括位置信息；所述位置信息包括以下的任意一种：第一设备的地理位置信息、第一设备的IP地址信息、第一设备的国际移动设备识别码；
响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证，包括：
响应于第一设备发起的解约处理请求，确定与所述第一设备对应的用户登录信息；其中，所述用户登录信息中包括在历史时刻中对应的用户标识和位置信息，所述历史时刻为所述第一设备发出历史的解约处理请求或者历史的签约处理请求的时刻，所述签约处理请求用于请求进行定期扣款的签约处理；
若确定所述用户登录信息中包括所述解约处理请求中的位置信息，则确定对所述解约处理请求的验证通过，若确定所述用户登录信息中不包括所述解约处理请求中的位置信息，则确定对所述解约处理请求的验证不通过；或者，若确定所述用户登录信息中包括所述解约处理请求中的位置信息时，所述用户登录信息包括的所述解约处理请求中的位置信息的次数大于第一预设次数，则确定对所述解约处理请求的验证通过，若确定所述用户登录信息中包括所述解约处理请求中的位置信息时，所述用户登录信息包括的所述解约处理请求中的位置信息的次数小于等于第一预设次数，则确定对所述解约处理请求的验证不通过。
3.根据权利要求1所述的方法，其特征在于，响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证，包括：
响应于第一设备发起的解约处理请求，向所述第一设备发送验证请求；
接收所述第一设备发送的验证信息；其中，所述验证信息包括以下的一种或多种：用户姓名、用户银行卡有效期、人脸信息、指纹信息；
若确定接收到的验证信息与预存的验证信息一致，则确定对所述解约处理请求的验证通过；
若确定接收到的验证信息与预存的验证信息不一致，则确定对所述解约处理请求的验证不通过。
4.根据权利要求1所述的方法，其特征在于，响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证，包括：
响应于第一设备发起的解约处理请求，确定与所述第一设备对应的手机号码；
向与所述第一设备对应的手机号码的设备发送第一验证码；
若确定在第一预设时长内接收到所述手机号码的设备发送的第二验证码、且所述第二验证码与所述第一验证码一致，则确定对所述解约处理请求的验证通过；
若确定在第一预设时长内未接收到所述手机号码的设备发送的第二验证码，和/或，所述第二验证码与所述第一验证码不一致，则确定对所述解约处理请求的验证不通过。
5.根据权利要求1所述的方法，其特征在于，在若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程之前，还包括：
若确定签约信息列表中包括与所述解约处理请求中的用户标识、商户标识均对应的签约信息，则执行若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程的步骤；
其中，所述签约信息列表中包括签约信息，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
6.根据权利要求1所述的方法，其特征在于，在确定拒绝执行与定期扣款请求对应的交易过程之后，还包括：
在第二预设时长之后，若接收到下一次的定期扣款请求，则拒绝执行与下一次的定期扣款请求对应的交易过程。
7.根据权利要求1-6中任一项所述的方法，其特征在于，所述方法，还包括：
若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识不匹配，则确定执行与定期扣款请求对应的交易过程。
8.根据权利要求1-6中任一项所述的方法，其特征在于，对所述解约处理请求进行验证，包括：
若确定在第三预设时长内接收到所述第一设备发起的解约处理请求的次数，小于等于第二预设次数，则对所述第一设备当前所发起的解约处理请求进行验证。
9.根据权利要求1-6中任一项所述的方法，其特征在于，所述方法还包括：
接收第一设备发送的签约请求；其中，所述签约请求中包括商户标识和用户标识，所述签约请求中还包括签约验证信息；
若对所述签约请求中的签约验证信息的验证成功，则生成签约信息；其中，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
10.根据权利要求1-6中任一项所述的方法，其特征在于，所述方法还包括：
将解约信息存储至区块链的第一区块中；并将签约信息存储至区块链的第二区块中；其中，所述签约信息表征用户标识对应的用户账户与商户标识对应的商户账户之间签约，所述签约信息中包括商户标识和用户标识。
11.一种基于用户解约的处理装置，其特征在于，所述装置包括：
验证单元，用于响应于第一设备发起的解约处理请求，对所述解约处理请求进行验证；其中，所述解约处理请求中包括商户标识和用户标识，所述解约处理请求表征请求用户标识对应的用户账户与商户标识对应的商户账户解绑，所述第一设备为用户的设备；所述用户标识为用户唯一标识，和/或，用户的银行卡号；所述商户标识为第二设备的终端号；所述第二设备为商户的设备；
第一生成单元，用于若确定对所述解约处理请求的验证通过，则生成与所述解约处理请求对应的解约信息；
查询单元，用于若接收到第二设备发起的定期扣款请求，则响应于第二设备发起的定期扣款请求，查询解约列表；其中，所述定期扣款请求为基于预设日期而定时发起的，所述定期扣款请求中包括商户标识和用户标识；所述解约列表中包括至少一个解约信息，所述解约信息表征用户标识对应的用户账户与商户标识对应的商户账户解绑，所述解约信息中包括商户标识和用户标识；
第一确定单元，用于若确定所述解约列表中存在解约信息与所述定期扣款请求所携带的商户标识、用户标识均匹配，则确定拒绝执行与定期扣款请求对应的交易过程，并向所述第二设备发送第一反馈信息；其中，所述第一反馈信息表征所述定期扣款请求中的用户标识对应的用户账户已解约。
12.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；
所述存储器存储计算机执行指令；
所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1-10中任一项所述的方法。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-10中任一项所述的方法。
CN202310658009.0A 2023-06-05 2023-06-05 基于用户解约的处理方法、装置以及设备 Pending CN116720861A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310658009.0A CN116720861A (zh) 2023-06-05 2023-06-05 基于用户解约的处理方法、装置以及设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310658009.0A CN116720861A (zh) 2023-06-05 2023-06-05 基于用户解约的处理方法、装置以及设备

Publications (1)

Publication Number Publication Date
CN116720861A true CN116720861A (zh) 2023-09-08

Family

ID=87864106

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310658009.0A Pending CN116720861A (zh) 2023-06-05 2023-06-05 基于用户解约的处理方法、装置以及设备

Country Status (1)

Country Link
CN (1) CN116720861A (zh)

Similar Documents

Publication Publication Date Title
CN109039990B (zh) 基于验证码进行行为验证的方法及装置
CN106157027B (zh) 支付方法、装置和系统
CN110049062B (zh) 验证码校验方法、装置、系统、服务器、电子设备及存储介质
CN107230060B (zh) 一种账号挂失的方法和装置
KR20190004700A (ko) 스마트 카메라에 액세스하는 방법 및 장치
CN105678549A (zh) 支付方法及装置
US20180146363A1 (en) Identity verification method and apparatus, and storage medium
CN114915923B (zh) 5g消息即服务触发方法、装置、电子设备及存储介质
CN104217328A (zh) 一种多重验证的支付方法及装置
CN107230064B (zh) 虚拟卡的复用方法及装置
CN105357669A (zh) 用于连接WiFi的方法和装置
CN111917728A (zh) 一种密码验证方法及装置
CN107145771B (zh) 应用程序解锁方法、装置及终端
CN109246094B (zh) 用户终端的验证方法、装置及存储介质
CN116579890A (zh) 基于区块链的在线签约系统
CN106408304B (zh) 账户安全管理方法和装置
CN116720861A (zh) 基于用户解约的处理方法、装置以及设备
CN113034141A (zh) 一种移动支付方法、装置、可穿戴设备和存储介质
CN109255601B (zh) 终端公交卡的处理方法及装置
CN110740360B (zh) 多媒体资源播放方法及装置
CN108074094B (zh) 资源补充方法及装置
CN107241318B (zh) 一种账号挂失的方法和装置
CN106603229B (zh) 签名信息生成方法及装置
CN117314436A (zh) 资源置换方法、装置、系统、计算机可读存储介质
CN110768995B (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