CN113962697A - 安全认证支付方法和装置 - Google Patents
安全认证支付方法和装置 Download PDFInfo
- Publication number
- CN113962697A CN113962697A CN202111230114.1A CN202111230114A CN113962697A CN 113962697 A CN113962697 A CN 113962697A CN 202111230114 A CN202111230114 A CN 202111230114A CN 113962697 A CN113962697 A CN 113962697A
- Authority
- CN
- China
- Prior art keywords
- payment
- authentication
- user
- password
- welfare
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 230000008901 benefit Effects 0.000 claims description 14
- 238000010586 diagram Methods 0.000 description 9
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000013475 authorization Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
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
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- 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
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本申请公开了一种安全认证支付方法和装置。该方法包括：接收用户输入的实体券密码；判断预先存储的实体券密码与接收到的实体券密码是否相同；如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。本申请采用了线下发放的实体券秘密来对用户进行线上的认证，实体券秘密可以采用用户的非隐私的信息，提高了安全性，避免用户个人隐私的泄露。
Description
技术领域
本申请涉及计算机技术领域，具体而言，涉及一种安全认证支付方法和装置。
背景技术
现有技术中，用户在登录购物的应用程序时，时经常需要对用户的权限进行认证，认证时，往往需要使用用户的隐私信息，比如，需要与微信绑定的手机号等个人隐私信息，隐私信息的使用增加了用户的安全隐患。
发明内容
本申请的主要目的在于提供一种安全认证支付方法和装置，以解决上述问题。
为了实现上述目的，根据本申请的一个方面，提供了一种安全认证支付方法。
一种安全认证支付方法，包括：
接收用户输入的实体券密码；
判断预先存储的实体券密码与接收到的实体券密码是否相同；
如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，接收用户输入的实体券的密码之前，所述方法还包括：通过微信进行认证。
在一种实施方式中，通过微信进行认证，包括：
获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
在一种实施方式中，接收用户输入的实体券密码之前，所述方法还包括：使用自定义的账号密码进行认证。
在一种实施方式中，使用自定义的账号密码进行认证，包括：
接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
在一种实施方式中，调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
第二方面，本申请提出了一种安全认证支付方法，包括：
通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和/或者，使用用户预先自定义的账号密码进行认证；
认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
为了实现上述目的，根据本申请的第三方面，提供了一种安全认证支付装置，包括：
认证模块，用于通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和使用用户预先自定义的账号密码进行认证；
支付模块，用于认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，认证模块还用于，获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
在一种实施方式中，认证模块还用于，接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
在一种实施方式中，支付模块还用于，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，支付模块还用于，如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
根据本申请的第四方面，提供了一种安全认证支付装置，包括：
第四方面，本申请还提出了一种安全认证支付装置，其特征在于，包括：
接收模块，用于接收用户输入的实体券密码；
认证模块，用于判断预先存储的实体券密码与接收到的实体券密码是否相同；
支付模块，用于如果判断模块确定预先存储的实体券密码与接收到的实体券密码相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，认证模块还用于，接收用户输入的实体券的密码之前，通过微信进行认证。
在一种实施方式中，认证模块还用于，获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
在一种实施方式中，认证模块还用于，接收用户输入的实体券密码之前，使用自定义的账号密码进行认证。
在一种实施方式中，认证模块还用于，接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
在一种实施方式中，支付模块还用于，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在本申请实施例中，通过接收用户输入的实体券密码；判断预先存储的实体券密码与接收到的实体券密码是否相同；如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。本申请采用了线下发放的实体券秘密来对用户进行线上的认证，实体券秘密可以采用用户的非隐私的信息，提高了安全性，避免用户个人隐私的泄露。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1是根据本申请实施例的一种安全认证支付方法的流程图；
图2A是根据本申请实施例的一种用户登录界面示意图；
图2B是根据本申请实施例的另一种用户登录界面示意图；
图3A是根据本申请实施例的一种支付界面示意图；
图3B是根据本申请实施例的另一种支付界面示意图；
图4是根据本申请实施例的一种安全认证支付装置的结构示意图；
图5是根据本申请实施例的一种安全认证支付设备的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本申请中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本发明及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。
需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
如图1所示，本申请提出了一种安全认证支付方法，应用在后端服务器中，该方法包括如下的步骤S102至步骤S108：
S102，接收用户输入的实体券密码；
其中，实体券为企业预先线下的方式发放给的用户的。实体券中的密码可以包括但不限于：用户的工号等非隐私信息。也即是不采用手机号，身份证等隐私信息。这样可以极大提高用户的认证的安全性，防止用户的认证信息被盗用后导致的个人隐私信息泄露。
参见附图2A所示的一种用户登录界面示意图；用户输入卡号和密码来进行认证。
其中，卡号为线下发放的实体券号。密码为实体券上的密码。
值得强调的是，实体券号和密码可以采用用户的工号等非用户的隐私信息，从而提高了用户隐私信息的安全性。
S104，判断预先存储的实体券密码与接收到的实体券密码是否相同；
S106，如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
S108，如果不同，则认证不通过。
其中，企业支付应用程序为企业单独为公司员工开发的应用程序App；通过企业应用程序可以为企业的员工发放福利；福利可以为货币。使用企业应用程序可以购买商品。提高了员工的便利性。
在一种实施方式中，接收用户输入的实体券的密码之前，通过微信进行认证。具体可以采用以下的步骤：
获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；如果否，则认证不通过。
在一种实施方式中，接收用户输入的实体券密码之前，使用自定义的账号密码进行认证，具体包括以下的步骤：
接收用户输入的自定义账号和自定义密码；判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；如果相同，则通过认证；如果不相同，则认证不通过。
参见附图2B所示的另一种用户登录界面示意图；用户使用自定义的账号密码登录。
其中，自定义的账号和密码可以灵活进行设定，比如可以采用员工在企业中的工号。当然，为了提高安全性，也可以采用其他的信息实现。
本发明的上述的方法，首先采用实体券的方式进行认证，在实体券的认证方式之前，可以采用微信，或者自定义的方式进行认证。
值得强调的是，本申请的上述的方法，可以先采用实体券的方式进行认证，然后，然后再采用微信的方式进行认证，如果不通过，再采用自定义的方式进行认证。这三种方式的先后关系，可以灵活进行设置。
用户在使用福利进行购买商品时，比如，在超市购买一次商品消费时，该商品的价格,50块，但是福利余额可能只有20，导致用户无法一次购买商品。并且该 20的额度往往不能够利用。比如，用户的额度如果只是剩下了几元，几角，几分钱，则往往会造成浪费，因为用户很少单独消费一次来划掉剩余的几分钱。
在一种实施方式中，S106中，调用企业支付程序使用企业发放的福利额度进行支付时，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
其中，第三方应用程序可以微信，或者支付宝等支付应用程序实现。
参见附图3A所示的一种支付界面示意图；该支付情景中，余额为500元，还需要支付14元。用户点击确认支付后，可以从支付宝或者微信支付14元。从而完成支付。
企业支付应用程序为企业为员工开发的应用程序，该应用程序与商家合作，可以购买商家的商品，比如，某个超市中的商品。可以使用企业为员工发放的福利进行购买商品。如果福利额度不够，则调用第三方支付应用程序进行差值的支付。
本发明的上述的方法，支付方式灵活，实现了与第三方支付应用程序的灵活对接，可以灵活调用第三方支付应用程序进行差值的支付工作。
避免了福利额度不够时，影响用户购物的体验。
参见附图3B所示的另一种支付界面示意图；该用户的的福利中，账户为多个，分别为通用账户、蛋糕账户、图书账户；其中，蛋糕账户中，用来购买蛋糕；图书账户中，用来购买图书；并且每种账户设置有效期，如果过了有效期则作废，如此可以促进用户进行消费。
第二方面，本申请还提出了一种安全认证支付方法，包括：
通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和使用用户预先自定义的账号密码进行认证；
认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
本申请提出了三种认证方式，分别是：微信信息认证、自定义账号密码认证、实体券号密码认证。
微信信息认证：默认使用微信信息认证，获取用户微信授权，取得用户手机号，检查该手机号是否已录入系统，若是已录入则正常登录，若是未录入则使用其余2种认证方式。
自定义账号密码认证：微信信息认证失败后可选择使用自定义账号密码认证，需提前录入用户账号密码，用户可凭已录入的账号密码认证成功，认证成功后账号密码不再使用，下次认证直接使用微信信息。
实体券号密码认证：微信信息认证失败后可选择使用实体券号密码认证，无需提前录入任何信息，用户凭实体券号与密码即可认证成功，认证成功后券号密码作废不可再次使用，下次认证直接使用微信信息。
本申请不需要提前要求企业或用户提供手机号等隐私信息，实体券号密码认证更是无需提供任何信息，保证用户隐私数据安全，降低用户使用门槛。
根据不同使用场景和需求提供不同用户认证方式。
具体的，通过微信进行认证时，采取以下的步骤：获取与微信绑定的手机号；判断所述手机号是否存储在预先设定的手机号数据库中；如果是，则认证通过；如果否，则认证不通过。
使用自定义的账号密码进行认证时，采取以下的步骤：接收用户输入的自定义账号和自定义密码；判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；如果相同，则通过认证；如果不相同，则认证不通过。
在一种实施方式中，调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
本发明在现有微信信息认证之外，增加自定义账号密码认证以及实体券号密码认证：自定义账号密码认证：企业可提供工号、员工编号等不涉及敏感、隐私的数据作为用户认证账号。
实体券号密码认证：企业无需提供任何数据，直接使用券号密码作为用户认证账号。
本申请的方法，不需要提前要求企业或用户提供手机号等隐私信息，实体券号密码认证更是无需提供任何信息，保证用户隐私数据安全，降低用户使用门槛。根据不同使用场景和需求提供不同用户认证方式
需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
第三方面，本申请还提出了一种安全认证支付装置，参见附图4所示的一种安全认证支付装置的结构示意图；该装置包括：
认证模块41，用于通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和使用用户预先自定义的账号密码进行认证；
支付模块42，用于认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，支付模块42还用于，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，支付模块42还用于，如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
第四方面，本申请还提出了一种安全认证支付装置，其特征在于，包括：
接收模块，用于接收用户输入的实体券密码；
认证模块，用于判断预先存储的实体券密码与接收到的实体券密码是否相同；
支付模块，用于如果判断模块确定预先存储的实体券密码与接收到的实体券密码相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，认证模块还用于，接收用户输入的实体券的密码之前，通过微信进行认证。
在一种实施方式中，认证模块还用于，获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
在一种实施方式中，认证模块还用于，接收用户输入的实体券密码之前，使用自定义的账号密码进行认证。
在一种实施方式中，认证模块还用于，接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
在一种实施方式中，支付模块还用于，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
根据本申请的第五方面，提供了一种电子设备，参见附图5所示的电子设备的结构示意图；包括至少一个处理器51和至少一个存储器52；所述存储器52用于存储一个或多个程序指令；所述处理器51，用于运行一个或多个程序指令，用以执行以下的步骤:
接收用户输入的实体券密码；
判断预先存储的实体券密码与接收到的实体券密码是否相同；
如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
所述处理器51还用于，接收用户输入的实体券的密码之前，所述方法还包括：通过微信进行认证。
所述处理器51还用于，获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
所述处理器51还用于，接收用户输入的实体券密码之前，使用自定义的账号密码进行认证。
所述处理器51还用于，接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
所述处理器51还用于，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，所述处理器51还用于，通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和使用用户预先自定义的账号密码进行认证；
认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，所述处理器51还用于，判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，所述处理器51还用于，如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
第六方面，本申请还提出了一种计算机可读存储介质，计算机可读存储介质中包含一个或多个程序指令，所述一个或多个程序指令用于执行以下的步骤:
接收用户输入的实体券密码；
判断预先存储的实体券密码与接收到的实体券密码是否相同；
如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，接收用户输入的实体券的密码之前，所述方法还包括：通过微信进行认证。
在一种实施方式中，通过微信进行认证，包括：
获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
在一种实施方式中，接收用户输入的实体券密码之前，所述方法还包括：使用自定义的账号密码进行认证。
在一种实施方式中，使用自定义的账号密码进行认证，包括：
接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
在一种实施方式中，调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
所述一个或多个程序指令用于执行以下的步骤:
通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和使用用户预先自定义的账号密码进行认证；
认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
在一种实施方式中，调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
在一种实施方式中，如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。处理器读取存储介质中的信息，结合其硬件完成上述方法的步骤。
存储介质可以是存储器，例如可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。
其中，非易失性存储器可以是只读存储器(Read-Only Memory，简称ROM)、可编程只读存储器(Programmable ROM，简称PROM)、可擦除可编程只读存储器(Erasable PROM，简称EPROM)、电可擦除可编程只读存储器(Electrically EPROM，简称EEPROM)或闪存。
易失性存储器可以是随机存取存储器(Random Access Memory，简称RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，简称SRAM)、动态随机存取存储器(Dynamic RAM，简称DRAM)、同步动态随机存取存储器(Synchronous DRAM，简称 SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，简称DDRSDRAM)、增强型同步动态随机存取存储器(EnhancedSDRAM，简称 ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，简称SLDRAM) 和直接内存总线随机存取存储器(DirectRambus RAM，简称DRRAM)。
本发明实施例描述的存储介质旨在包括但不限于这些和任意其它适合类型的存储器。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件与软件组合来实现。当应用软件时，可以将相应功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
Claims (10)
1.一种安全认证支付方法，其特征在于，包括：
接收用户输入的实体券密码；
判断预先存储的实体券密码与接收到的实体券密码是否相同；
如果相同，则认证通过；进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
2.根据权利要求1所述的安全认证支付方法，其特征在于，接收用户输入的实体券的密码之前，所述方法还包括：通过微信进行认证。
3.根据权利要求2所述的安全认证支付方法，其特征在于，通过微信进行认证，包括：
获取与微信绑定的手机号；
判断所述手机号是否存储在预先设定的手机号数据库中；
如果是，则认证通过；
如果否，则认证不通过。
4.根据权利要求1所述的安全认证支付方法，其特征在于，接收用户输入的实体券密码之前，所述方法还包括：使用自定义的账号密码进行认证。
5.根据权利要求4所述的安全认证支付方法，其特征在于，使用自定义的账号密码进行认证，包括：
接收用户输入的自定义账号和自定义密码；
判断与所述自定义账号对应的自定义密码与预先存储的自定义密码是否相同；
如果相同，则通过认证；如果不相同，则认证不通过。
6.根据权利要求1所述的安全认证支付方法，其特征在于，
调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
7.一种安全认证支付方法，其特征在于，包括：
通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和使用用户预先自定义的账号密码进行认证；
认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
8.根据权利要求7所述的安全认证支付方法，其特征在于，调用企业支付程序使用企业发放的福利额度进行支付，包括：
判断福利余额是否满足当前一次消费的额度；
如果不满足，则计算所述当前一次消费的额度与福利余额的差值；
调用企业支付应用程序对福利余额进行支付；
调用第三方应用程序对所述差值进行支付。
9.根据权利要求7所述的安全认证支付方法，其特征在于，
如果福利余额满足当前一次消费的额度，则调用企业支付应用程序对当前一次消费的额度进行支付。
10.一种安全认证支付装置，其特征在于，包括：
认证模块，用于通过用户使用的微信对用户的权限进行认证；
如果微信认证不通过，则使用预先向用户发放的实体券进行认证，和/或者，使用用户预先自定义的账号密码进行认证；
支付模块，用于认证通过后，进行支付时，调用企业支付应用程序使用企业发放的福利额度进行支付。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111230114.1A CN113962697A (zh) | 2021-10-21 | 2021-10-21 | 安全认证支付方法和装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111230114.1A CN113962697A (zh) | 2021-10-21 | 2021-10-21 | 安全认证支付方法和装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113962697A true CN113962697A (zh) | 2022-01-21 |
Family
ID=79465964
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111230114.1A Pending CN113962697A (zh) | 2021-10-21 | 2021-10-21 | 安全认证支付方法和装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113962697A (zh) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103078863A (zh) * | 2013-01-08 | 2013-05-01 | 青岛海信宽带多媒体技术有限公司 | 登录认证的方法、装置及系统 |
| CN106204043A (zh) * | 2016-07-22 | 2016-12-07 | 上海瀚之友信息技术服务有限公司 | 一种支付管理系统及方法 |
| KR20180014140A (ko) * | 2018-01-29 | 2018-02-07 | 주식회사 기프텍 | 신용카드 거래를 이용하여 신용카드 상품권을 운용하는 시스템 및 방법 |
| CN111915412A (zh) * | 2020-08-17 | 2020-11-10 | 江苏华泽微福科技发展有限公司 | 一种福利商城提货信息系统及方法 |
-
2021
- 2021-10-21 CN CN202111230114.1A patent/CN113962697A/zh active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103078863A (zh) * | 2013-01-08 | 2013-05-01 | 青岛海信宽带多媒体技术有限公司 | 登录认证的方法、装置及系统 |
| CN106204043A (zh) * | 2016-07-22 | 2016-12-07 | 上海瀚之友信息技术服务有限公司 | 一种支付管理系统及方法 |
| KR20180014140A (ko) * | 2018-01-29 | 2018-02-07 | 주식회사 기프텍 | 신용카드 거래를 이용하여 신용카드 상품권을 운용하는 시스템 및 방법 |
| CN111915412A (zh) * | 2020-08-17 | 2020-11-10 | 江苏华泽微福科技发展有限公司 | 一种福利商城提货信息系统及方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11080678B2 (en) | Payment processing platform | |
| US8862509B2 (en) | Systems and methods for secure debit payment | |
| RU2438172C2 (ru) | Способ и система для осуществления двухфакторной аутентификации при транзакциях, связанных с заказами по почте и телефону | |
| US20090281951A1 (en) | Payment Processing Platform | |
| US20170091759A1 (en) | Token provisioning for non-account holder use with limited transaction functions | |
| US20160042344A1 (en) | Method and system for facilitating online and offline financial transactions | |
| CN105590214A (zh) | 一种虚拟卡的支付方法以及支付系统 | |
| US20060080197A1 (en) | Financial account management | |
| US20130268439A1 (en) | Vtex3 fraud protection system mobile verification protocol (mvp) | |
| US11908004B2 (en) | Method and system for obtaining credit | |
| EP3055819A1 (en) | Broker-mediated payment systems and methods | |
| US20130185207A1 (en) | Method and system for online authentication using a credit/debit card processing system | |
| WO2009137716A2 (en) | Payment processing platform | |
| US10755264B2 (en) | Methods and systems for secure online payment | |
| US20170169424A1 (en) | Delegation of transactions | |
| CA2978999A1 (en) | System and method of authorisation of simple, sequential and parallel requests with means of authorization through previously defined paramftfrs | |
| US20230274277A1 (en) | Identity management service via a user-level token | |
| KR100711844B1 (ko) | 통신망을 통해 인증번호를 이용해서 결제하는 방법 및 그시스템 | |
| US20220076240A1 (en) | System and method for ephemeral compute with payment card processing | |
| US20180341950A1 (en) | Transaction control | |
| CN113962697A (zh) | 安全认证支付方法和装置 | |
| US20230106418A1 (en) | Systems and methods for facilitating financial transactions | |
| KR101309835B1 (ko) | 토탈 금융거래 시스템 | |
| KR20060085134A (ko) | 대출신청방법 및 시스템과 이를 위한 기록매체 | |
| Team | Secure Your Veem Account with 2FA: A Step-by-Step Guide on Setting Up 2FA with Authenticator and SMS |
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 |