WO2019144807A1 - 支付卡的绑定方法、信任评估方法、装置和电子设备 - Google Patents

支付卡的绑定方法、信任评估方法、装置和电子设备 Download PDF

Info

Publication number
WO2019144807A1
WO2019144807A1 PCT/CN2019/071110 CN2019071110W WO2019144807A1 WO 2019144807 A1 WO2019144807 A1 WO 2019144807A1 CN 2019071110 W CN2019071110 W CN 2019071110W WO 2019144807 A1 WO2019144807 A1 WO 2019144807A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
trust evaluation
card
evaluation parameter
request
Prior art date
Application number
PCT/CN2019/071110
Other languages
English (en)
French (fr)
Inventor
朱金标
Original Assignee
阿里巴巴集团控股有限公司
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 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Priority to SG11202006066TA priority Critical patent/SG11202006066TA/en
Publication of WO2019144807A1 publication Critical patent/WO2019144807A1/zh
Priority to US16/880,315 priority patent/US10902415B2/en

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/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
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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/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
    • 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/409—Device specific authentication in transaction processing

Definitions

  • the present application relates to the field of computer software technologies, and in particular, to a payment card binding method, a trust evaluation method, a device, and an electronic device.
  • 3-D Secure A three-domain model-based authentication process that includes an Acquirer Domain, an Issuer Domain, and an Interoperability Domain.
  • the digital wallet makes a random small payment to the user's credit card. Please check if the user knows the amount used for the authentication.
  • the verification methods of the two verification methods are cumbersome, and the user's drop rate (probability of abandoning card binding and payment) is high. According to statistics, the drop rate of both programs is above 30-40%.
  • the purpose of the embodiment of the present application is to provide a payment card binding method, a trust evaluation method, a device, and an electronic device, so as to simplify the process of binding a new card and reduce the payment risk.
  • a method for payment card binding comprising:
  • binding the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • a payment card trust evaluation method comprising:
  • a payment card binding device comprising:
  • the payment unit sends a first payment request to the payment ecosystem based on the payment card binding request sent by the payment client;
  • a determining unit when the payment is successful, determining, according to at least one of the device data, the environment data, and the account data of the payment client, a trust evaluation parameter corresponding to the payment card and the payment client account;
  • the binding unit binds the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • a payment card trust evaluation apparatus comprising:
  • an electronic device comprising:
  • a memory arranged to store computer executable instructions that, when executed, cause the processor to perform the following operations:
  • binding the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • a computer readable storage medium storing one or more programs that, when executed by an electronic device comprising a plurality of applications, cause the electronic device Do the following:
  • binding the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • an electronic device comprising:
  • a memory arranged to store computer executable instructions that, when executed, cause the processor to perform the following operations:
  • a computer readable storage medium storing one or more programs that, when executed by an electronic device comprising a plurality of applications, cause the electronic device Do the following:
  • the payment is initiated by the payment card to be bound by the payment client to determine the validity of the payment card, and based on at least one of the payment client account data, the device data of the payment client, and the environment data of the payment client.
  • the trust evaluation parameters of the payment card are determined, thereby simplifying the binding process and reducing the payment risk after the new card is bound.
  • the trust evaluation parameter is fed back to the payment server by receiving a trust evaluation parameter acquisition request sent when the payment server is valid, so that the payment server can bind the payment card based on the trust evaluation parameter, thereby enabling the payment server to Simplify the new card binding process while reducing the payment risk after the new card is bound.
  • 1 is a flow chart of a method for payment card binding according to an embodiment of the present application.
  • FIG 2 is an interaction flowchart of payment card binding and payment card trust evaluation according to an embodiment of the present application.
  • FIG. 3 is a flow chart of a method for payment card trust evaluation in an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of a payment card binding apparatus according to an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a payment card trust evaluation apparatus according to an embodiment of the present application.
  • the embodiment of the present application provides a method for binding a payment card, a method for evaluating a trust, an apparatus, and an electronic device.
  • FIG. 1 is a flow chart of a method for payment card binding according to an embodiment of the present application.
  • the method of Figure 1 can be applied to a payment server, such as an electronic wallet server, an Alipay system server, and the like.
  • the method of Figure 1 can include:
  • the payment client may be an electronic wallet client or the like.
  • the user can bind a new payment card, such as a credit card, debit card, Visa card, and the like.
  • the user can perform a binding process of the payment card by sending a payment card binding request to the payment server.
  • the payment ecosystem refers to a payment service provider, and may include an acquirer, a card organization, and a card issuer (issuing bank).
  • the acquirer may provide payment and clearing services to the merchant and forward the transaction to the connection card organization;
  • the card organization may transfer the transaction to the card issuer and be responsible for liquidation with the acquirer and the issuer;
  • the issuer is responsible for Provide card products to consumers, such as bank cards in banks, and so on.
  • the embodiment of the present application does not limit this, and does not exclude other possible implementation manners of the payment ecosystem.
  • the first payment request may be sent to the payment ecosystem to verify the validity of the payment card.
  • the payment server may initiate a small payment request to verify the validity of the payment card.
  • the payment server can initiate a payment request (debit request) to the payment ecosystem through a debit transaction message. If the payment ecosystem responds to the payment request, the result of the successful payment of the payment indicates that the payment card is valid; conversely, if the payment ecosystem fails to report the payment, the payment card is invalid, and at this time, the subsequent steps are not performed.
  • the amount in the payment request may be fixed or random. For example, a random charge of $0.13 is sent, and so on.
  • the device data of the payment client may include, for example, a device ID, a device MAC address, and the like.
  • the device trust level can be determined.
  • the device is a common device for paying a client account.
  • the device has a higher trust level and a corresponding trust evaluation parameter. If the device is the device that the client account uses for the first time, the device has a lower trust level.
  • the trust evaluation parameters will also be lower. For another example, if the device has a fraud history, its device trust level is lower, the corresponding trust evaluation parameters are lower, and so on.
  • the environment data of the payment client may include, for example, the name of the WIFI connected to the terminal device where the client is located, the MAC address of the WIFI, the geographical location (latitude and longitude information) of the device, and the IP address segment.
  • the environmental trust level can also be determined based on the environmental data of the payment client.
  • the environmental trust level is lower and the corresponding trust evaluation parameters are lower.
  • Payment client account data may include: payment client account ID, registration time, customer name, gender, address, age, funding channel, history of customer profile modification, and the like.
  • the account trust level can also be determined based on the account data of the payment client.
  • the account trust level is higher; if the payment client account corresponds to an age between 8 and 12 years old, the account trust level is lower. As another example, the payment client account has a fraud history, the account trust level is lower, and so on.
  • the trust evaluation parameters corresponding to the payment card and the payment client account may be determined.
  • the trust evaluation parameter is used to determine a payment limit.
  • the payment client account After determining the trust evaluation parameter, the payment client account can be bound to the payment card based on the trust evaluation parameter.
  • the trust evaluation parameter includes at least one of the following: a trust level of the payment card, and a payment limit associated with the trust level of the payment card. It should be understood that in the process of binding a new card, the risk control system may feed back at least one of a New Card Trust Level (NCTL) and a payment limit corresponding to the NCTL to the payment server.
  • NCTL New Card Trust Level
  • step S130 can be implemented as:
  • At least one parameter of the trust level and the payment limit of the payment card in the payment client account is set.
  • the risk control system divides the NCTL level into 0, 1, 2, 3, and 4 levels.
  • the higher the NCTL level the higher the trust level and the lower the risk.
  • the corresponding payment limits for each level of the NCTL are 0 yuan, 100 yuan, 500 yuan, 1,000 yuan, and 2,000 yuan.
  • the risk control system determines that the NCTL is level 1 based on the device data of the payment client, the environment data of the payment client, the payment card identifier, the payment client account data, etc.
  • the level 1 may be fed back to the payment server, or the payment limit may be 100. Meta-feedback to the payment server, or feedback the two information of level 1 and 100 yuan to the payment server.
  • the risk control system determines that the NCTL is level 1 based on the device data of the payment client, the environment data of the payment client, the payment card identifier, the payment client account data, etc.
  • the level 1 may be fed back to the payment server, or the payment limit may be
  • the payment is initiated by the payment card to be bound by the payment client to determine the validity of the payment card, and based on the payment client account data, the device data of the payment client, and the environment data of the payment client. At least one of the trust evaluation parameters that determine the payment card can simplify the binding process while reducing the payment risk after the new card is bound.
  • the payment server may include a risk control module, configured to determine, according to at least one of device data, environment data, and account data of the payment client, a payment card and a payment client account. Trust evaluation parameters.
  • step S120 can be implemented as:
  • the trust evaluation parameter acquisition request carrying at least one of device data, environmental data, account data of the payment client, and the payment card Identification
  • the method may further include:
  • the payment amount in the first payment request is recharged into the payment client account.
  • the method may further include:
  • a trust evaluation is performed on the second payment request to determine whether the second payment request is allowed.
  • the payment server when the payment server receives the payment request for the payment card sent by the payment client account, the payment request may be sent to the risk control system to perform a risk check on the payment request.
  • the risk control system may determine whether to allow the payment based on data such as the payment card's chargeback data, transaction data, and payment card trust level, and the payment amount carried in the payment request.
  • the risk verification of the payment request by the risk control system can further reduce the payment risk after the payment card is bound.
  • the method further includes: if the second payment request is not allowed, performing a credit processing to the payment ecosystem based on the second payment request.
  • the step may be implemented as:
  • the response may further include the adjusted trust evaluation parameter of the risk control system; the method further includes:
  • the method may further include:
  • the bound payment card can adjust the payment limit as the number of transactions increases, thereby making the payment restriction and payment client account, payment Cards, equipment, environment and other factors are matched.
  • FIG. 2 is an interaction flow diagram of payment card binding and payment card trust evaluation in one embodiment of the present application.
  • information exchanges of the wallet client, the wallet server, the payment ecosystem, and the risk control system may be included. among them,
  • the wallet client the payment client of the embodiment shown in Figure 1, can be used to initiate a binding of a new card request.
  • the wallet server that is, the payment server of the embodiment shown in FIG. 1, can perform the operation of binding the new card in response to the binding of the new card request of the wallet client.
  • the payment ecosystem is the provider of the payment service.
  • the payment ecosystem may include an acquirer, a card organization, and a card issuer, wherein the acquirer may provide payment and clearing services to the merchant and forward the transaction to the connection card organization; the card organization may place the transaction Transferred to the card issuer and responsible for liquidation with the acquirer and the issuer; the issuer is responsible for providing the card product to the consumer, such as a bank card at the bank, and so on.
  • the risk control system that is, the risk control system of the embodiment shown in FIG. 1, is used to calculate and update the trust level of the NCTL wallet account, device, and environment in real time to update the NCTL and NCTL associated spending limits and respond as a wallet server.
  • the risk control system can provide an API interface through which the wallet server can obtain payment restrictions corresponding to the NCTL and/or NCTL corresponding to the new card and the wallet client account.
  • Step 1 The wallet client sends a new card binding request to the wallet server.
  • the wallet client may send the account identifier of the wallet client and the payment card related parameters to be bound to the wallet server.
  • Payment card related parameters such as payment card identification, payment card password.
  • the payment card related parameter may further include at least one of a check code of the payment card, a mobile phone number of the payment card bound by the issuing bank, and an identity of the user of the payment card.
  • wallet client can also send other account data of the wallet client to the wallet server.
  • the wallet client can also send device data to the wallet client.
  • Device data for example, the device identifier, MAC address, etc. of the terminal device where the wallet client is located.
  • the wallet client can also send environmental data to the wallet client.
  • the environmental data for example, the name of the WIFI to which the terminal device where the wallet client is located, the MAC address of the WIFI, the geographical location (latitude and longitude information) of the device, the IP address segment, and the like.
  • the geographical location of the device for example, can be obtained through the Location Based Service (LBS) of the terminal device.
  • LBS Location Based Service
  • Step 2 The wallet server sends a payment request to the payment ecosystem.
  • the wallet server can send a payment request to the payment ecosystem to verify the validity of the new card.
  • the wallet server can send a debit request to the payment ecosystem through a debit transaction message to verify the validity of the new card.
  • the payment server can initiate a small random payment amount, such as 0.13 yuan, and the like. .
  • the payment ecosystem can return a response to a successful debit or a failed charge based on a debit transaction message.
  • a successful debit or a failed charge based on a debit transaction message.
  • Step 3 The wallet server sends a trust evaluation parameter acquisition request to the risk control system.
  • the wallet server may send a trust evaluation parameter acquisition request to the risk control system by calling the NCTL Risk Service API to obtain a trust evaluation parameter corresponding to the new card and the wallet client account.
  • NCTL Risk Service API As shown in Figure 2, as input to the NCTL Risk Service API, it may include new card identification, wallet client account data, device data, and environmental data.
  • Step 4 The risk control system calculates the trust evaluation parameters.
  • the risk control system calculates the account trust level (ATL) based on the wallet client account data
  • the risk control system calculates the device trust level (DTL) based on the device data.
  • the risk control system is based on environmental data and can calculate the Environmental Trust Level (ETL).
  • ETL Environmental Trust Level
  • the model can be obtained based on the corresponding trust level calculation model.
  • the risk control system can obtain the corresponding NCTL.
  • the way to calculate the NCTL can also be obtained based on the NCTL model.
  • the training method of the foregoing model can be obtained based on the corresponding training data, and the embodiment of the present application is not limited herein.
  • the parameters of the NCTL may include only one or more of the ATL, the DTL, and the ETL, and may include other parameters than the ATL, the DTL, and the ETL.
  • the risk control system can also determine the payment limit corresponding to the NCTL.
  • Step 5 The risk control system feeds back the trust evaluation parameters.
  • the risk control system can feed back the payment restrictions corresponding to the NCTL and the NCTL to the wallet server.
  • the risk control system can also feed back only one of the NCTL and payment restrictions to the wallet server.
  • Step 6 The wallet server binds the payment card and the wallet client account.
  • the wallet server can bind parameters to the payment card and the wallet client account, and set corresponding binding parameters, such as NCTL, payment restrictions, and the like.
  • the payment server may also initiate a payment request to the payment ecosystem with reference to the scheme shown in FIG. 2, and then send the payment request to the risk control system for verification.
  • the risk control system can determine whether to allow the payment request based on the current NCTL and payment restrictions of the payment card and wallet client account. If not allowed, a billing process is initiated to the payment ecosystem.
  • the risk control system may also adjust the NCTL corresponding to the payment card and the wallet client account based on the chargeback record, the transaction record, and the current NCTL generated after the payment card is bound to the wallet client account.
  • FIG. 3 is a flow chart of a trust evaluation method for a payment card.
  • the method of Figure 3 is performed by a risk control system.
  • the method can include:
  • the trust evaluation parameter acquisition request is sent by the payment server when receiving the payment success feedback from the payment ecosystem.
  • the trust evaluation parameter is used by the payment server to bind the payment client's account and the payment card, and determine the payment limit.
  • the trust evaluation parameter is sent to the payment server by receiving the trust evaluation parameter acquisition request sent by the payment server when the payment card is valid, so that the payment server can bind the payment card based on the trust evaluation parameter. This simplifies the new card binding process and reduces the payment risk after the new card is bound.
  • the trust evaluation parameter obtaining request carries: the trust evaluation parameter obtaining request carries at least one of device data, environment data, and account data of the payment client, and the payment card identifier.
  • step S320 is specifically implemented as:
  • the trust evaluation parameter is determined based on the device trust level, the environment trust level, and the account trust level.
  • the trust evaluation parameter may also be determined based on one or both of a device trust level, an environment trust level, and an account trust level.
  • the trust evaluation parameter includes at least one of the following: a trust level of the payment card, and a payment limit associated with the trust level of the payment card.
  • the method may further include:
  • the method may further include:
  • the verification request is used to request verification whether the payment request for the payment card is allowed in the payment client account;
  • the parameter is evaluated based on the payment card and the current trust of the payment client account, and the response of the verification request is fed back to the payment server.
  • the electronic device includes a processor, optionally including an internal bus, a network interface, and a memory.
  • the memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory.
  • RAM high-speed random access memory
  • non-volatile memory such as at least one disk memory.
  • the electronic device may also include hardware required for other services.
  • the processor, the network interface, and the memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended) Industry Standard Architecture, extending the industry standard structure) bus.
  • the bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one double-headed arrow is shown in Figure 4, but it does not mean that there is only one bus or one type of bus.
  • the program can include program code, the program code including computer operating instructions.
  • the memory can include both memory and non-volatile memory and provides instructions and data to the processor.
  • the processor reads the corresponding computer program from the non-volatile memory into memory and then runs to form a payment card binding device at a logical level.
  • the processor executes the program stored in the memory and is specifically used to perform the following operations:
  • binding the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • the method performed by the payment card binding apparatus disclosed in the embodiment shown in FIG. 1 of the present application may be applied to a processor or implemented by a processor.
  • the processor may be an integrated circuit chip with signal processing capabilities.
  • each step of the above method may be completed by an integrated logic circuit of hardware in a processor or an instruction in a form of software.
  • the above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; or may be a digital signal processor (DSP), dedicated integration.
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • other programmable logic device discrete gate or transistor logic device, discrete hardware component.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application may be directly implemented by the hardware decoding processor, or may be performed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the storage medium is located in the memory, and the processor reads the information in the memory and combines the hardware to complete the steps of the above method.
  • the electronic device can also perform the method of FIG. 1 and implement the functions of the embodiment shown in FIG. 1 and FIG. 2 of the payment server or the wallet server, and details are not described herein again.
  • the electronic device of the present application does not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution body of the following processing flow is not limited to each logical unit. It can also be hardware or logic.
  • the embodiment of the present application further provides a computer readable storage medium storing one or more programs, the one or more programs including instructions, when the portable electronic device is included in a plurality of applications When executed, the portable electronic device can be configured to perform the method of the embodiment shown in FIG. 1 and specifically for performing the following operations:
  • binding the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • FIG. 5 is a schematic structural diagram of a payment card binding apparatus according to an embodiment of the present application.
  • the payment card binding apparatus 500 can include:
  • the payment unit 510 sends a first payment request to the payment ecosystem based on the payment card binding request sent by the payment client;
  • the determining unit 520 when the payment is successful, determining, according to at least one of the device data, the environment data, and the account data of the payment client, a trust evaluation parameter corresponding to the payment card and the payment client account;
  • the binding unit 530 binds the payment client account to the payment card based on the trust evaluation parameter, and the trust evaluation parameter is used to determine a payment limit.
  • the payment is initiated by the payment card to be bound by the payment client to determine the validity of the payment card, and based on the payment client account data, the device data of the payment client, and the environment data of the payment client. At least one of the trust evaluation parameters that determine the payment card can simplify the binding process while reducing the payment risk after the new card is bound.
  • the determining unit 520 is specifically configured to:
  • the trust evaluation parameter acquisition request carrying at least one of device data, environmental data, account data of the payment client, and the payment card Identification
  • the trust evaluation parameter includes at least one of the following: a trust level of the payment card, and a payment limit associated with the trust level of the payment card.
  • the binding unit 530 is specifically configured to: when binding the payment client account and the payment card, set a trust level and a payment limit of the payment card in the payment client account based on the trust evaluation parameter. At least one parameter in .
  • the payment card binding device 500 further includes a refilling unit 540, which recharges the payment amount in the first payment request into the payment client account.
  • the payment unit 510 also sends a second payment request for the payment card under the payment client account to the payment ecosystem;
  • the determining unit 520 also performs a trust evaluation on the second payment request to determine whether the second payment request is allowed.
  • the payment card binding device 500 further includes a billing unit 550 that, if the second payment request is not allowed, performs a credit processing to the payment ecosystem based on the second payment request.
  • the determining unit 520 is further configured to:
  • the response further includes the adjusted trust evaluation parameter of the risk control system; the binding unit 530 is further configured to perform binding parameters on the payment client account and the payment card based on the adjusted trust evaluation parameter. Reset.
  • the payment ecosystem includes an acquirer subsystem, a card scheme subsystem, and a card issuer subsystem.
  • the payment card binding device can also perform the method of FIG. 1 and implement the functions of the embodiment shown in FIG. 1 and FIG. 2 of the payment server or the wallet server, and details are not described herein again.
  • FIG. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
  • the electronic device includes a processor, optionally including an internal bus, a network interface, and a memory.
  • the memory may include a memory, such as a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory.
  • RAM high-speed random access memory
  • non-volatile memory such as at least one disk memory.
  • the electronic device may also include hardware required for other services.
  • the processor, the network interface, and the memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended) Industry Standard Architecture, extending the industry standard structure) bus.
  • the bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one double-headed arrow is shown in Figure 6, but it does not mean that there is only one bus or one type of bus.
  • the program can include program code, the program code including computer operating instructions.
  • the memory can include both memory and non-volatile memory and provides instructions and data to the processor.
  • the processor reads the corresponding computer program from the non-volatile memory into memory and then runs to form a payment card trust evaluation device at a logical level.
  • the processor executes the program stored in the memory and is specifically used to perform the following operations:
  • the method performed by the payment card trust evaluation device or the risk control system disclosed in the embodiment shown in FIG. 3 of the present application may be applied to a processor or implemented by a processor.
  • the processor may be an integrated circuit chip with signal processing capabilities.
  • each step of the above method may be completed by an integrated logic circuit of hardware in a processor or an instruction in a form of software.
  • the above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; or may be a digital signal processor (DSP), dedicated integration.
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application may be directly implemented by the hardware decoding processor, or may be performed by a combination of hardware and software modules in the decoding processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the storage medium is located in the memory, and the processor reads the information in the memory and combines the hardware to complete the steps of the above method.
  • the electronic device can also perform the method of FIG. 3 and implement the functions of the risk control system in the embodiment shown in FIG. 3 and FIG. 2, and details are not described herein again.
  • the electronic device of the present application does not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc., that is, the execution body of the following processing flow is not limited to each logical unit. It can also be hardware or logic.
  • the embodiment of the present application further provides a computer readable storage medium storing one or more programs, the one or more programs including instructions, when the portable electronic device is included in a plurality of applications When executed, the portable electronic device can be configured to perform the method of the embodiment shown in FIG. 3, and is specifically configured to perform the following operations:
  • FIG. 7 is a schematic structural diagram of a payment card trust evaluation apparatus according to an embodiment of the present application.
  • the payment card trust evaluation apparatus may include:
  • the receiving unit 710 is configured to receive a trust evaluation parameter obtaining request of the payment card sent by the payment server, where the trust evaluation parameter obtaining request is sent by the payment server when receiving the payment success indication returned by the payment ecosystem;
  • the sending unit 720 sends, according to the trust evaluation parameter obtaining request, the payment evaluation parameter corresponding to the payment card and the payment client account to the payment server, where the trust evaluation parameter is used by the payment server to pay the client account and the payment card. Make binding settings and determine the payment limit.
  • the trust evaluation parameter is sent to the payment server by receiving the trust evaluation parameter acquisition request sent by the payment server when the payment card is valid, so that the payment server can bind the payment card based on the trust evaluation parameter. This simplifies the new card binding process and reduces the payment risk after the new card is bound.
  • the trust evaluation parameter obtaining request carries at least one of device data, environment data, and account data of the payment client, and the payment card identifier.
  • the payment card trust evaluation device may further include a determining unit 730, where
  • the determining unit 730 determines a device trust level based on the device data of the payment client
  • the trust evaluation parameter is determined based on the device trust level, the environment trust level, and the account trust level.
  • the trust evaluation parameter includes at least one of the following: a trust level of the payment card, and a payment limit associated with the trust level of the payment card.
  • the determining unit 730 may further adjust the trust evaluation corresponding to the payment card and the payment client account based on the chargeback data, the transaction data, and the trust evaluation parameter after the payment card is bound to the payment client account. This parameter.
  • the receiving unit 710 is further configured to: receive a verification request sent by the payment server, where the verification request is used to request to verify whether the payment request for the payment card is allowed in the payment client account;
  • the sending unit 720 is further configured to: estimate the parameter based on the current trust of the payment card and the payment client account, and feed back the response of the verification request to the payment server.
  • the payment card trust evaluation apparatus can also perform the method of FIG. 3 and implement the functions of the risk control system in the embodiment shown in FIG. 3 and FIG. 2, and details are not described herein again.
  • the system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function.
  • a typical implementation device is a computer.
  • the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the information can be computer readable instructions, data structures, modules of programs, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

Landscapes

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

Abstract

一种支付卡的绑定方法、信任评估方法、装置和电子设备，该支付卡绑定方法包括：基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求（S110）；当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数（S120）；基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置（S130），该信任评估参数用于确定支付额度限制。

Description

支付卡的绑定方法、信任评估方法、装置和电子设备 技术领域
本申请涉及计算机软件技术领域，尤其涉及一种支付卡的绑定方法、信任评估方法、装置和电子设备。
背景技术
用户在使用数字钱包进行支付时，往往需要绑定一张以上的支付卡。
当用户将新的支付卡绑定到数字钱包时，目前大部分使用的验证方法是三域安全(3-D Secure)和宏观支付(Micro Charge)。
3-D Secure：基于三域模型的认证过程，该三域包括收单机构域(Acquirer Domain)、发行机构域(Issuer Domain)和互操作性域(Interoperability Domain)。
Micro Charge：数字钱包向用户的信用卡进行随机小额支付，请检查用户是否知道用于认证的金额。
但是，这两种验证方法的验证方式都较为繁琐，用户的掉单率(放弃卡绑定和支付的概率)较高。据统计，两种方案的掉单率都在30-40％以上。
发明内容
本申请实施例的目的是提供一种支付卡的绑定方法、信任评估方法、装置和电子设备，以实现对绑定新卡流程的简化，并减小支付风险。
为解决上述技术问题，本申请实施例是这样实现的：
第一方面，提出了一种支付卡绑定的方法，该方法包括：
基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
第二方面，提出了一种支付卡信任评估方法，该方法包括：
接收支付服务端发送的支付卡的信任评估参数获取请求，其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
第三方面，提出了一种支付卡绑定装置，该装置包括：
支付单元，基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
确定单元，当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
绑定单元，基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
第四方面，提出了一种支付卡信任评估装置，该装置包括：
接收单元，接收支付服务端发送的支付卡的信任评估参数获取请求，其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
发送单元，基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
第五方面，提出了一种电子设备，该电子设备包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：
基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
第六方面，提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序当被包括多个应用程序的电子设备执行时，使得该电子设备执行以下操作：
基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
第七方面，提出了一种电子设备，该电子设备包括：
处理器；以及
被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：
接收支付服务端发送的支付卡的信任评估参数获取请求，其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
第八方面，提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序当被包括多个应用程序的电子设备执行时，使得该电子设备执行以下操作：
接收支付服务端发送的支付卡的信任评估参数获取请求，其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
由以上本申请实施例提供的技术方案可见，本申请实施例方案至少具备如下一种技术效果：
第一方面，通过对支付客户端待绑定的支付卡发起支付以确定支付卡的有效性，并基于支付客户端账户数据、支付客户端所在设备数据、支付客户端所在环境数据中的至少一种确定支付卡的信任评估参数，从而能够简化绑定流程，同时减少新卡绑定后的支付风险。
第二方面，通过在接收到支付服务端于支付卡有效时发送的信任评估参数获取请求，向支付服务端反馈信任评估参数，以使得支付服务端能够基于信任评估参数绑定支付卡，从而能够简化新卡绑定流程，同时减小新卡绑定后的支付风险。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本申请的一个实施例支付卡绑定的方法流程图。
图2是本申请的一个实施例支付卡绑定及支付卡信任评估的交互流程图。
图3是本申请的一个实施例支付卡信任评估的方法流程图。
图4是本申请的一个实施例电子设备的结构示意图。
图5是本申请的一个实施例支付卡绑定装置的结构示意图。
图6是本申请的一个实施例电子设备的结构示意图。
图7是本申请的一个实施例支付卡信任评估装置的结构示意图。
具体实施方式
本申请实施例提供一种支付卡的绑定方法、信任评估方法、装置和电子设备。
为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实 施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。
图1是本申请的一个实施例支付卡绑定的方法流程图。图1的方法可应用于支付服务端，例如电子钱包服务器、支付宝系统服务器，等等。图1的方法可包括：
S110，基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求。
应理解，在本申请实施例中，支付客户端，可以是电子钱包客户端等。在支付客户端账户中，用户可绑定新的支付卡，例如信用卡、借记卡、Visa卡等等。此时，用户可通过向支付服务端发送支付卡绑定请求以进行支付卡的绑定流程。
应理解，在本申请实施例中，支付生态系统指支付服务提供方，可包括收单方、卡组织和发卡方(发卡银行)等。应理解，收单方可向商户提供支付和清算服务，并把交易转发给连接卡组织；卡组织可将交易转给发卡方，并负责和收单方、发卡方之间的清算；发卡方则负责向消费者提供卡产品，例如在银行办的银行卡，等等。当然，应理解，对于支付生态系统之间的交易流程，本申请实施例对此不作限制，也不排除支付生态系统还存在其它可能的实现方式。
当支付服务端收到支付客服端发送的支付卡绑定请求后，可向支付生态系统发送第一支付请求，以验证支付卡的有效性。
应理解，在发送第一支付请求时，支付服务端可发起一笔小额支付请求，以验证支付卡的有效性。支付服务端可通过扣款交易报文，向支付生态系统发起支付请求(扣款请求)。如果支付生态系统响应于该支付请求，反馈支付成功的结果，则表示支付卡有效；反之，如果支付生态系统反馈支付失败的结果，则表示支付卡无效，此时，不再执行后续的步骤。
应理解，支付请求中的金额，可以是固定的，也可以是随机的。例如，随机发送一笔0.13元的扣款，等等。
S120，当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数。
应理解，支付客户端的设备数据，例如，可包括：设备ID、设备MAC地址，等等。
基于支付客户端的设备数据，可确定设备信任级别。
例如，设备是支付客户端账户的常用设备，设备信任级别较高，对应的信任评估参数也会较高；如果设备是支付客户端账户第一次使用的设备，则设备信任级别较低，对应的信任评估参数也会较低。又例如，该设备曾经有欺诈历史，则其设备信任级别较低，对应的信任评估参数也会较低，等等。
支付客户端的环境数据，例如，可包括：支付客户端所在的终端设备连接的WIFI的名字，WIFI的MAC地址，设备所在的地理位置(经纬度信息)，IP地址段等。
基于支付客户端的环境数据，也可确定环境信任级别。
类似地，如果环境数据表明用户不在常驻地点，例如国外，则其环境信任级别就较低，对应的信任评估参数也会较低。
支付客户端账户数据，例如，可包括：支付客户端账户ID、注册时间、客户的姓名、性别、地址、年龄、资金渠道，客户资料修改的历史记录，等等。
基于支付客户端的账户数据，也可确定账户信任级别。
例如，支付客户端账户对应的年龄在30岁-40岁之间，则账户信任级别较高；支付客户端账户对应的年龄在8岁-12岁之间，则账户信任级别较低。又例如，支付客户端账户有过欺诈历史，则账户信任级别较低，等等。
基于设备数据、环境数据、账户数据中的一种或多种，可确定支付卡和支付客户端账户对应的信任评估参数。
S130，基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置。
其中，该信任评估参数用于确定支付额度限制。
在确定信任评估参数后，即可基于信任评估参数，对该支付客户端账户与该支付卡进行绑定设置。
可选地，该信任评估参数包括以下至少一种：支付卡的信任等级、与支付卡的信任等级关联的支付限制。应理解，在绑定新卡的流程中，风险控制系统可将新卡信任等级(New Card Trust Level，NCTL)及NCTL对应的支付限制中的至少一种反馈给支付服务端。
相应地，步骤S130可实现为：
在绑定该支付客户端账户与该支付卡时，基于该信任评估参数，设定该支付卡在该 支付客户端账户中的信任等级、支付限制中的至少一个参数。
例如，假设风险控制系统对NCTL的级别分为0、1、2、3、4五级，NCTL级别越高，信任度越高，风险越小。不妨还假设NCTL各级别对应的支付限制分别为0元，100元，500元，1000元，2000元。当风险控制系统基于支付客户端的设备数据、该支付客户端的环境数据、支付卡标识、支付客户端账户数据等确定NCTL为1级时，可将1级反馈给支付服务端，或将支付限制100元反馈给支付服务端，或者将1级和100元这两个信息一起反馈给支付服务端。当然，应理解，在这个示例中，如果确定NCTL为0级，说明支付卡可信度极低，绑定支付卡的支付客户端账户存在较高的风险。
本申请实施例中，通过对支付客户端待绑定的支付卡发起支付以确定支付卡的有效性，并基于支付客户端账户数据、支付客户端所在设备数据、支付客户端所在环境数据中的至少一种确定支付卡的信任评估参数，从而能够简化绑定流程，同时减少新卡绑定后的支付风险。
可选地，作为一个实施例，支付服务端中可包括风险控制模块，用于基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数。
可选地，作为另一个实施例，支付服务端中不具备风险控制模块。此时，步骤S120可实现为：
向风险控制系统发送关于支付卡和支付客户端账户的信任评估参数获取请求，该信任评估参数获取请求携带有该支付客户端的设备数据、环境数据、账户数据中的至少一种，以及该支付卡标识；
接收该风险控制系统基于该信任评估参数获取请求反馈的信任评估参数。
可选地，在步骤S130之后，该方法还可包括：
将该第一支付请求中的支付金额充值到该支付客户端账户中。
可选地，在步骤S130之后，该方法还可包括：
向该支付生态系统发送该支付客户端账户下关于该支付卡的第二支付请求；
对该第二支付请求进行信任评估，以确定是否允许该第二支付请求。
应理解，当支付服务端接收到支付客户端账户发送的关于该支付卡的支付请求时， 可将该支付请求发送给风险控制系统，以对该支付请求进行风险校验。风险控制系统可基于该支付卡的拒付数据、交易数据及支付卡信任级别等数据，以及支付请求中携带的支付额度，确定是否允许该支付。通过风险控制系统对支付请求的风险校验，可进一步减少支付卡绑定后的支付风险。
进一步地，该方法还包括：如果不允许该第二支付请求，则基于该第二支付请求向该支付生态系统进行冲账处理。
当然，应理解，在对该第二支付请求进行信任评估，以确定是否允许该第二支付请求的步骤中，当支付服务端不具备风险控制模块时，该步骤可实现为：
向风险控制系统发送第二支付请求的校验请求，该校验请求中携带该支付卡标识、该支付客户端账户及该第二支付请求的支付金额；
接收该风险控制系统对该校验请求的响应，其中，该响应由该风险控制系统基于该支付卡和该支付客户端账户对应的信任评估参数，以及该第二支付请求的支付金额确定。
可选地，该响应中还可携带该风险控制系统调整后的信任评估参数；该方法还包括：
基于该调整后的信任评估参数对该支付客户端账户与该支付卡进行绑定参数的重设置。
相应地，如果支付服务端具备风险控制模块，则在步骤S130之后，该方法还可包括：
基于该支付卡绑定到该支付客户端账户后的拒付数据、交易数据和信任评估参数，调整该支付卡和该支付客户端账户对应的信任评估参数。
通过基于拒付数据、交易数据及当前信任评估参数来得到调整后的信任评估参数，可以使得绑定的支付卡随着交易次数的增多调整支付限制，从而使得支付限制与支付客户端账户、支付卡、设备、环境等多方面的因素相匹配。
下面，将结合具体的实施例，对本申请实施例的方法作进一步的描述。
图2是本申请的一个实施例支付卡绑定和支付卡信任评估的交互流程图。在图2所示的实施例中，可包括钱包客户端、钱包服务端、支付生态系统和风险控制系统四方的信息交互。其中，
钱包客户端，即图1所示实施例的支付客户端，可用于发起绑定新卡请求。
钱包服务器，即图1所示实施例的支付服务端，可响应钱包客户端的绑定新卡请求，进行新卡绑定的相关操作。
支付生态系统，即图1所示实施例的支付生态系统，是支付服务的提供方。在图2所示实施例中，支付生态系统可包括收单方、卡组织和发卡方，其中，收单方可向商户提供支付和清算服务，并把交易转发给连接卡组织；卡组织可将交易转给发卡方，并负责和收单方、发卡方之间的清算；发卡方则负责向消费者提供卡产品，例如在银行办的银行卡，等等。
风险控制系统，即图1所示实施例的风险控制系统，用于实时计算和更新NCTL的钱包帐户、设备和环境的信任等级，以更新NCTL和NCTL关联支出限制，并作为钱包服务器的响应。风险控制系统可提供一个API接口，钱包服务器可通过该API接口获取新卡和钱包客户端账户对应的NCTL和/或NCTL对应的支付限制。
下面，将详细介绍方案流程。
步骤1：钱包客户端向钱包服务器发送新卡绑定请求。
应理解，钱包客户端在发送新卡绑定请求时，可将钱包客户端的账户标识和待绑定的支付卡相关参数发送给钱包服务器。
支付卡相关参数，例如，支付卡标识、支付卡密码。当然,支付卡相关参数还可包括支付卡的校验码、支付卡在发卡银行绑定的手机号码、支付卡的用户的身份标识等信息中的至少一种。
当然，应理解，钱包客户端还可将钱包客户端的其它账户数据发送给钱包服务器。
钱包客户端还可将设备数据发送给钱包客户端。设备数据，例如，钱包客户端所在的终端设备的设备标识、MAC地址等等。
钱包客户端还可将环境数据发送给钱包客户端。环境数据，例如，钱包客户端所在的终端设备连接的WIFI的名字，WIFI的MAC地址，设备所在的地理位置(经纬度信息)，IP地址段等。设备所在的地理位置，例如，可以通过终端设备的定位功能(Location Based Service，LBS)得到。
步骤2：钱包服务端向支付生态系统发送支付请求。
钱包服务端基于钱包客户端的新卡绑定请求，可向支付生态系统发送支付请求， 以校验新卡的有效性。
一个具体的例子，钱包服务端可通过一个扣款交易报文，向支付生态系统发送扣款请求，以校验新卡的有效性。例如，支付服务端可通过发起一笔很小的随机支付金额，例如0.13元，等等。。
支付生态系统根据扣款交易报文，可返回扣款成功或扣款失败的响应。其处理的具体方式可参考现有技术，本申请实施例在此不再赘述。
步骤3：钱包服务端向风险控制系统发送信任评估参数获取请求。
在图2所示实施例中，钱包服务端可通过调用NCTL Risk Service API，向风险控制系统发送信任评估参数获取请求，以获取新卡和钱包客户端账户对应的信任评估参数。
如图2所示，作为NCTL Risk Service API的输入，可包括新卡标识、钱包客户端账户数据、设备数据和环境数据。
步骤4：风险控制系统计算信任评估参数。
风险控制系统基于钱包客户端账户数据，可计算得到账户信任级别(Account Trust Level，ATL)；
风险控制系统基于设备数据，可计算得到设备信任级别(Device Trust Level，DTL)；
风险控制系统基于环境数据，可计算得到环境信任级别(Environment Trust Level，ETL)。
在计算ATL、DTL和ETL时，可基于对应的信任等级计算模型得到。
基于ATL、DTL和ETL，风险控制系统可得到对应的NCTL。计算NCTL的方式，也可基于NCTL模型得到。
上述模型的训练方式，可基于对应的训练数据得到，本申请实施例在此不作限制。
当然，应理解，确定NCTL的参数，可以只包括ATL、DTL和ETL中的一种或多种，还可以包括ATL、DTL和ETL以外的其它参数，本申请实施例对此不作限制。
此外，基于NCTL，风险控制系统还可确定NCTL对应的支付限额。
步骤5：风险控制系统反馈信任评估参数。
如图2所示，风险控制系统可将NCTL和NCTL对应的支付限制反馈给钱包服务器。当然，应理解，风险控制系统也可只将NCTL和支付限制的其中一个反馈给钱包服务器。
步骤6：钱包服务器绑定支付卡和钱包客户端账户。
钱包服务器基于风险控制系统反馈的信任评估参数，可对支付卡和钱包客户端账户进行绑定参数，并设定对应的绑定参数，例如，NCTL、支付限制，等等。
至此，完成了支付卡的绑定流程。
此外，应理解，在后续的支付流程中，支付服务端也可参照图2所示的方案向支付生态系统发起支付请求，然后将支付请求发送给风险控制系统进行校验。风险控制系统可基于支付卡和钱包客户端账户当前的NCTL和支付限制，确定是否允许该支付请求。如果不允许，则向支付生态系统发起冲账处理。
当然，应理解，风险控制系统还可基于支付卡绑定到钱包客户端账户后产生的拒付记录、交易记录及当前的NCTL，调整支付卡和钱包客户端账户对应的NCTL。
此外，应理解，上述实施例中的支付服务端与风险控制系统，也可以合并为一个系统。
图3是一种支付卡的信任评估方法流程图。图3的方法由风险控制系统执行。该方法可包括：
S310，接收支付服务端发送的支付卡的信任评估参数获取请求。
其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的。
S320，基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数。
其中，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
本申请实施例中，通过在接收到支付服务端于支付卡有效时发送的信任评估参数获取请求，向支付服务端反馈信任评估参数，以使得支付服务端能够基于信任评估参 数绑定支付卡，从而能够简化新卡绑定流程，同时减小新卡绑定后的支付风险。
可选地，该信任评估参数获取请求携带有：该信任评估参数获取请求携带有该支付客户端的设备数据、环境数据、账户数据中的至少一种，以及该支付卡标识。
可选地，步骤S320具体可实现为：
基于该支付客户端的设备数据确定设备信任级别；
基于该支付客户端的环境数据确定环境信任级别；
基于该支付客户端的账户数据确定账户信任级别；
基于设备信任级别、环境信任级别和账户信任级别，确定该信任评估参数。
当然，应理解，也可基于设备信任级别、环境信任级别、账户信任级别中的一个或两个，确定该信任评估参数。
可选地，该信任评估参数包括以下至少一种：支付卡的信任等级、与支付卡的信任等级关联的支付限制。
可选地，该方法还可包括：
基于该支付卡绑定到该支付客户端账户后的拒付数据、交易数据和信任评估该参数，调整该支付卡和该支付客户端账户对应的信任评估该参数
可选地，该方法还可包括：
接收支付服务端发送的校验请求，该校验请求用于请求校验是否允许该支付客户端账户下关于该支付卡的支付请求；
基于该支付卡和该支付客户端账户当前的信任评估该参数，向该支付服务端反馈该校验请求的响应。
图3所示实施例的具体实现可参考图1、图2所示实施例中风险控制系统执行的方法，本申请实施例在此不再赘述。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
图4是本申请的一个实施例电子设备的结构示意图。请参考图4，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(Extended Industry Standard Architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成支付卡绑定装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
上述如本申请图1所示实施例揭示的支付卡绑定装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常 规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
该电子设备还可执行图1的方法，并实现支付服务端或钱包服务端在图1、图2所示实施例的功能，本申请实施例在此不再赘述。
当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1所示实施例的方法，并具体用于执行以下操作：
基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
图5是本申请的一个实施例支付卡绑定装置的结构示意图。请参考图5，在一种软件实施方式中，支付卡绑定装置500可包括：
支付单元510，基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
确定单元520，当支付成功时，基于该支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
绑定单元530，基于该信任评估参数对该支付客户端账户与该支付卡进行绑定设置，该信任评估参数用于确定支付额度限制。
本申请实施例中，通过对支付客户端待绑定的支付卡发起支付以确定支付卡的 有效性，并基于支付客户端账户数据、支付客户端所在设备数据、支付客户端所在环境数据中的至少一种确定支付卡的信任评估参数，从而能够简化绑定流程，同时减少新卡绑定后的支付风险。
可选地，确定单元520具体用于：
向风险控制系统发送关于支付卡和支付客户端账户的信任评估参数获取请求，该信任评估参数获取请求携带有该支付客户端的设备数据、环境数据、账户数据中的至少一种，以及该支付卡标识；
接收该风险控制系统基于该信任评估参数获取请求反馈的信任评估参数。
可选地，该信任评估参数包括以下至少一种：支付卡的信任等级、与支付卡的信任等级关联的支付限制。
可选地，绑定单元530具体用于：在绑定该支付客户端账户与该支付卡时，基于该信任评估参数，设定该支付卡在该支付客户端账户中的信任等级、支付限制中的至少一个参数。
可选地，支付卡绑定装置500还包括充值单元540，将该第一支付请求中的支付金额充值到该支付客户端账户中。
可选地，支付单元510还向该支付生态系统发送该支付客户端账户下关于该支付卡的第二支付请求；
确定单元520还对该第二支付请求进行信任评估，以确定是否允许该第二支付请求。
可选地，支付卡绑定装置500还包括冲账单元550，如果不允许该第二支付请求，则基于该第二支付请求向该支付生态系统进行冲账处理。
可选地，确定单元520还用于：
向风险控制系统发送第二支付请求的校验请求，该校验请求中携带该支付卡标识、该支付客户端账户及该第二支付请求的支付金额；
接收该风险控制系统对该校验请求的响应，其中，该响应由该风险控制系统基于该支付卡和该支付客户端账户对应的信任评估参数，以及该第二支付请求的支付金额确定。
可选地，该响应中还携带该风险控制系统调整后的信任评估参数；绑定单元530还用于基于该调整后的信任评估参数对该支付客户端账户与该支付卡进行绑定参数的重设置。
可选地，该支付生态系统包括收单方子系统、卡方案子系统和发卡方子系统。
该支付卡绑定装置还可执行图1的方法，并实现支付服务端或钱包服务端在图1、图2所示实施例的功能，本申请实施例在此不再赘述。
图6是本申请的一个实施例电子设备的结构示意图。请参考图6，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(Extended Industry Standard Architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成支付卡信任评估装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
接收支付服务端发送的支付卡的信任评估参数获取请求，其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
上述如本申请图3所示实施例揭示的支付卡信任评估装置或风险控制系统执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具 有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
该电子设备还可执行图3的方法，并实现风险控制系统在图3、图2所示实施例的功能，本申请实施例在此不再赘述。
当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图3所示实施例的方法，并具体用于执行以下操作：
接收支付服务端发送的支付卡的信任评估参数获取请求，其中，该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
图7是本申请的一个实施例支付卡信任评估装置的结构示意图。请参考图7，在一种软件实施方式中，支付卡信任评估装置可包括：
接收单元710，接收支付服务端发送的支付卡的信任评估参数获取请求，其中， 该信任评估参数获取请求是该支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
发送单元720，基于该信任评估参数获取请求，向该支付服务端发送该支付卡和该支付客户端账户对应的信任评估参数，该信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
本申请实施例中，通过在接收到支付服务端于支付卡有效时发送的信任评估参数获取请求，向支付服务端反馈信任评估参数，以使得支付服务端能够基于信任评估参数绑定支付卡，从而能够简化新卡绑定流程，同时减小新卡绑定后的支付风险。
可选地，该信任评估参数获取请求携带有该支付客户端的设备数据、环境数据、账户数据中的至少一种，以及该支付卡标识。
可选地，支付卡信任评估装置还可包括确定单元730，其中，
确定单元730，基于该支付客户端的设备数据确定设备信任级别；
基于该支付客户端的环境数据确定环境信任级别；
基于该支付客户端的账户数据确定账户信任级别；
基于设备信任级别、环境信任级别和账户信任级别，确定该信任评估参数。
可选地，该信任评估参数包括以下至少一种：支付卡的信任等级、与支付卡的信任等级关联的支付限制。
可选地，确定单元730，还可基于该支付卡绑定到该支付客户端账户后的拒付数据、交易数据和信任评估该参数，调整该支付卡和该支付客户端账户对应的信任评估该参数。
可选地，接收单元710还用于：接收支付服务端发送的校验请求，该校验请求用于请求校验是否允许该支付客户端账户下关于该支付卡的支付请求；
发送单元720还用于：基于该支付卡和该支付客户端账户当前的信任评估该参数，向该支付服务端反馈该校验请求的响应。
该支付卡信任评估装置还可执行图3的方法，并实现风险控制系统在图3、图2所示实施例的功能，本申请实施例在此不再赘述。
总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范 围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (22)

  1. 一种支付卡绑定的方法，包括：
    基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
    当支付成功时，基于所述支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
    基于所述信任评估参数对所述支付客户端账户与所述支付卡进行绑定设置，所述信任评估参数用于确定支付额度限制。
  2. 如权利要求1所述的方法，基于所述支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数，包括：
    向风险控制系统发送关于支付卡和支付客户端账户的信任评估参数获取请求，所述信任评估参数获取请求携带有所述支付客户端的设备数据、环境数据、账户数据中的至少一种，以及所述支付卡标识；
    接收所述风险控制系统基于所述信任评估参数获取请求反馈的信任评估参数。
  3. 如权利要求1或2所述的方法，
    所述信任评估参数包括以下至少一种：支付卡的信任等级、与支付卡的信任等级关联的支付限制。
  4. 如权利要求3所述的方法，基于所述信任评估参数对所述支付客户端账户与所述支付卡进行绑定设置，包括：在绑定所述支付客户端账户与所述支付卡时，基于所述信任评估参数，设定所述支付卡在所述支付客户端账户中的信任等级、支付限制中的至少一个参数。
  5. 如权利要求1所述的方法，所述方法还包括：
    将所述第一支付请求中的支付金额充值到所述支付客户端账户中。
  6. 如权利要求1所述的方法，还包括：
    向所述支付生态系统发送所述支付客户端账户下关于所述支付卡的第二支付请求；
    对所述第二支付请求进行信任评估，以确定是否允许所述第二支付请求。
  7. 如权利要求6所述的方法，还包括：如果不允许所述第二支付请求，则基于所述第二支付请求向所述支付生态系统进行冲账处理。
  8. 如权利要求6所述的方法，对所述第二支付请求进行信任评估，以确定是否允许所述第二支付请求，包括：
    向风险控制系统发送第二支付请求的校验请求，所述校验请求中携带所述支付卡标识、所述支付客户端账户及所述第二支付请求的支付金额；
    接收所述风险控制系统对所述校验请求的响应，其中，所述响应由所述风险控制系统基于所述支付卡和所述支付客户端账户对应的信任评估参数，以及所述第二支付请求的支付金额确定。
  9. 如权利要求8所述的方法，所述响应中还携带所述风险控制系统调整后的信任评估参数；所述方法还包括：
    基于所述调整后的信任评估参数对所述支付客户端账户与所述支付卡进行绑定参数的重设置。
  10. 如权利要求1所述的方法，所述方法还包括：
    基于所述支付卡绑定到所述支付客户端账户后的拒付数据、交易数据和信任评估参数，调整所述支付卡和所述支付客户端账户对应的信任评估参数。
  11. 一种支付卡的信任评估方法，包括：
    接收支付服务端发送的支付卡的信任评估参数获取请求，其中，所述信任评估参数获取请求是所述支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
    基于所述信任评估参数获取请求，向所述支付服务端发送所述支付卡和所述支付客户端账户对应的信任评估参数，所述信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
  12. 如权利要求11所述的方法，包括：
    所述信任评估参数获取请求携带有所述支付客户端的设备数据、环境数据、账户数据中的至少一种，以及所述支付卡标识。
  13. 如权利要求12所述的方法，
    基于所述信任评估参数获取请求，向所述支付服务端发送所述支付卡和所述支付客户端账户对应的信任评估参数，包括：
    基于所述支付客户端的设备数据确定设备信任级别；
    基于所述支付客户端的环境数据确定环境信任级别；
    基于所述支付客户端的账户数据确定账户信任级别；
    基于设备信任级别、环境信任级别和账户信任级别，确定所述信任评估参数。
  14. 如权利要求11所述的方法，
    所述信任评估参数包括以下至少一种：支付卡的信任等级、与支付卡的信任等级关联的支付限制。
  15. 如权利要求11-14中任一项所述的方法，还包括：
    基于所述支付卡绑定到所述支付客户端账户后的拒付数据、交易数据和信任评估参 数，调整所述支付卡和所述支付客户端账户对应的信任评估参数。
  16. 如权利要求11-14中任一项所述的方法，还包括：
    接收支付服务端发送的校验请求，所述校验请求用于请求校验是否允许所述支付客户端账户下关于所述支付卡的支付请求；
    基于所述支付卡和所述支付客户端账户当前的信任评估参数，向所述支付服务端反馈所述校验请求的响应。
  17. 一种支付卡绑定装置，包括：
    支付单元，基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
    确定单元，当支付成功时，基于所述支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
    绑定单元，基于所述信任评估参数对所述支付客户端账户与所述支付卡进行绑定设置，所述信任评估参数用于确定支付额度限制。
  18. 一种支付卡的信任评估装置，包括：
    接收单元，接收支付服务端发送的支付卡的信任评估参数获取请求，其中，所述信任评估参数获取请求是所述支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
    发送单元，基于所述信任评估参数获取请求，向所述支付服务端发送所述支付卡和所述支付客户端账户对应的信任评估参数，所述信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
  19. 一种电子设备，包括：
    处理器；以及
    被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：
    基于支付客户端发送的支付卡绑定请求，通过支付生态系统校验支付卡的有效性；
    当支付卡有效时，向风险控制系统发送关于支付卡和支付客户端账户的信任评估参数获取请求；
    接收所述风险控制系统基于所述信任评估参数获取请求反馈的信任评估参数；
    基于所述信任评估参数对所述支付客户端账户与所述支付卡进行绑定设置，所述信任评估参数用于确定支付额度限制。
  20. 一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所 述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：
    基于支付客户端发送的支付卡绑定请求，向支付生态系统发送第一支付请求；
    当支付成功时，基于所述支付客户端的设备数据、环境数据、账户数据中的至少一种，确定支付卡和支付客户端账户对应的信任评估参数；
    基于所述信任评估参数对所述支付客户端账户与所述支付卡进行绑定设置，所述信任评估参数用于确定支付额度限制。
  21. 一种电子设备，包括：
    处理器；以及
    被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行以下操作：
    接收支付服务端发送的支付卡的信任评估参数获取请求，其中，所述信任评估参数获取请求是所述支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
    基于所述信任评估参数获取请求，向所述支付服务端发送所述支付卡和所述支付客户端账户对应的信任评估参数，所述信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
  22. 一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下操作：
    接收支付服务端发送的支付卡的信任评估参数获取请求，其中，所述信任评估参数获取请求是所述支付服务端在收到支付生态系统反馈的支付成功的指示时发送的；
    基于所述信任评估参数获取请求，向所述支付服务端发送所述支付卡和所述支付客户端账户对应的信任评估参数，所述信任评估参数用于支付服务端对支付客户端的账户与支付卡进行绑定设置，并确定支付额度限制。
PCT/CN2019/071110 2018-01-23 2019-01-10 支付卡的绑定方法、信任评估方法、装置和电子设备 WO2019144807A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
SG11202006066TA SG11202006066TA (en) 2018-01-23 2019-01-10 Payment card binding method, trust evaluation method, apparatus, and electronic device
US16/880,315 US10902415B2 (en) 2018-01-23 2020-05-21 Payment card binding method, trust evaluation method, apparatus, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810064258.6A CN108399543B (zh) 2018-01-23 2018-01-23 支付卡的绑定方法、信任评估方法、装置和电子设备
CN201810064258.6 2018-01-23

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/880,315 Continuation US10902415B2 (en) 2018-01-23 2020-05-21 Payment card binding method, trust evaluation method, apparatus, and electronic device

Publications (1)

Publication Number Publication Date
WO2019144807A1 true WO2019144807A1 (zh) 2019-08-01

Family

ID=63094188

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/071110 WO2019144807A1 (zh) 2018-01-23 2019-01-10 支付卡的绑定方法、信任评估方法、装置和电子设备

Country Status (5)

Country Link
US (1) US10902415B2 (zh)
CN (2) CN108399543B (zh)
SG (1) SG11202006066TA (zh)
TW (1) TWI703520B (zh)
WO (1) WO2019144807A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112053161A (zh) * 2020-05-09 2020-12-08 支付宝(杭州)信息技术有限公司 绑定处理方法、装置及设备
CN113205331A (zh) * 2020-11-24 2021-08-03 支付宝(杭州)信息技术有限公司 一种支付方法及装置、电子设备和存储介质

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108399543B (zh) * 2018-01-23 2020-09-04 阿里巴巴集团控股有限公司 支付卡的绑定方法、信任评估方法、装置和电子设备
CN110400227A (zh) * 2019-07-31 2019-11-01 中国工商银行股份有限公司 交易报文数据的处理方法、装置、系统
CN111768186A (zh) * 2020-05-19 2020-10-13 支付宝(杭州)信息技术有限公司 一种电子钱包的支付方法、装置及电子设备
CN112801655B (zh) * 2021-02-05 2024-02-23 中国银联股份有限公司 支付卡迁移方法、装置、电子设备、服务器和介质
JP7230120B2 (ja) * 2021-06-30 2023-02-28 楽天グループ株式会社 サービス提供システム、サービス提供方法、及びプログラム
CN114157510B (zh) * 2021-12-14 2023-07-04 中国联合网络通信集团有限公司 物网业务处理方法、平台和存储介质
TWI805190B (zh) * 2022-01-14 2023-06-11 玉山商業銀行股份有限公司 驗證電子支付工具的方法與系統
CN115456773B (zh) * 2022-08-26 2024-03-15 深圳市富途网络科技有限公司 基于区块链的支付控制方法、装置、设备及介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104618415A (zh) * 2014-03-13 2015-05-13 腾讯科技（深圳）有限公司 信用账户创建方法、装置及系统
CN106296187A (zh) * 2015-06-03 2017-01-04 深圳卡通新技术有限公司 一种电子支付安全控制方法及系统
CN106779701A (zh) * 2016-11-22 2017-05-31 中国银联股份有限公司 一种支付方法和装置
CN107146076A (zh) * 2017-04-10 2017-09-08 广州智造家网络科技有限公司 安全交易方法及系统
CN108399543A (zh) * 2018-01-23 2018-08-14 阿里巴巴集团控股有限公司 支付卡的绑定方法、信任评估方法、装置和电子设备

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6012048A (en) 1997-05-30 2000-01-04 Capital Security Systems, Inc. Automated banking system for dispensing money orders, wire transfer and bill payment
US7376618B1 (en) 2000-06-30 2008-05-20 Fair Isaac Corporation Detecting and measuring risk with predictive models using content mining
US7865427B2 (en) * 2001-05-30 2011-01-04 Cybersource Corporation Method and apparatus for evaluating fraud risk in an electronic commerce transaction
US7904360B2 (en) 2002-02-04 2011-03-08 Alexander William EVANS System and method for verification, authentication, and notification of a transaction
US6952779B1 (en) 2002-10-01 2005-10-04 Gideon Cohen System and method for risk detection and analysis in a computer network
US10115112B2 (en) 2006-08-31 2018-10-30 Visa U.S.A. Inc. Transaction evaluation for providing rewards
CN101071490A (zh) * 2007-03-23 2007-11-14 田小平 会员名称与银行卡绑定的电子商务系统和方法
TW200905604A (en) 2007-07-26 2009-02-01 Shacom Com Inc Credit investigation/grant system and method of network-effect credit extension
US20090240624A1 (en) 2008-03-20 2009-09-24 Modasolutions Corporation Risk detection and assessment of cash payment for electronic purchase transactions
US9135424B2 (en) * 2009-05-29 2015-09-15 Paypal, Inc. Secure identity binding (SIB)
CN101996381A (zh) * 2009-08-14 2011-03-30 中国工商银行股份有限公司 一种零售资产风险的计算方法及系统
US8412605B2 (en) 2009-12-01 2013-04-02 Bank Of America Corporation Comprehensive suspicious activity monitoring and alert system
US9785988B2 (en) * 2010-11-24 2017-10-10 Digital River, Inc. In-application commerce system and method with fraud prevention, management and control
US8473318B2 (en) 2011-07-19 2013-06-25 Bank Of America Corporation Risk score determination
CN102332127A (zh) * 2011-09-15 2012-01-25 深圳市酷开网络科技有限公司 基于网络电视在线支付业务的账户绑定方法和支付方法
WO2013056104A1 (en) * 2011-10-12 2013-04-18 C-Sam, Inc. A multi-tiered secure mobile transactions enabling platform
WO2013082190A1 (en) * 2011-11-28 2013-06-06 Visa International Service Association Transaction security graduated seasoning and risk shifting apparatuses, methods and systems
CN102542691B (zh) * 2011-12-31 2013-09-18 武汉银讯科技发展有限公司 手机之间点对点实现银行卡交易的方法
US10096020B2 (en) * 2012-08-30 2018-10-09 Worldpay, Llc Combination payment card and methods thereof
US8712854B1 (en) * 2012-08-30 2014-04-29 Vantiv, Llc Systems, methods and apparatus for payment processing
US8850517B2 (en) 2013-01-15 2014-09-30 Taasera, Inc. Runtime risk detection based on user, application, and system action sequence correlation
US20140279474A1 (en) * 2013-03-12 2014-09-18 Visa International Service Association Multi-purse one card transaction apparatuses, methods and systems
CN103279883B (zh) * 2013-05-02 2016-06-08 上海携程商务有限公司 电子支付交易风险控制方法及系统
US20150012430A1 (en) * 2013-07-03 2015-01-08 Mastercard International Incorporated Systems and methods for risk based decisioning service incorporating payment card transactions and application events
US10510073B2 (en) * 2013-08-08 2019-12-17 Visa International Service Association Methods and systems for provisioning mobile devices with payment credentials
US9532227B2 (en) * 2013-09-13 2016-12-27 Network Kinetix, LLC System and method for an automated system for continuous observation, audit and control of user activities as they occur within a mobile network
US9805366B1 (en) * 2013-09-16 2017-10-31 Square, Inc. Associating payment information from a payment transaction with a user account
US10366387B2 (en) * 2013-10-29 2019-07-30 Visa International Service Association Digital wallet system and method
US20150142667A1 (en) * 2013-11-16 2015-05-21 Mads Landrok Payment authorization system
US9635044B2 (en) 2014-06-02 2017-04-25 Bastille Networks, Inc. Electromagnetic persona generation based on radio frequency fingerprints
US10275772B2 (en) 2014-06-16 2019-04-30 Bank Of America Corporation Cryptocurrency risk detection system
WO2016004227A1 (en) * 2014-07-02 2016-01-07 Blackhawk Network, Inc. Systems and methods for dynamically detecting and preventing consumer fraud
US20160078444A1 (en) * 2014-09-16 2016-03-17 Mastercard International Incorporated Systems and methods for providing fraud indicator data within an authentication protocol
US10140615B2 (en) * 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
CN104392347B (zh) * 2014-10-23 2017-12-12 中国建设银行股份有限公司 一种账户申请方法、创建方法、相关设备及系统
US10692085B2 (en) * 2015-02-13 2020-06-23 Yoti Holding Limited Secure electronic payment
US10193700B2 (en) * 2015-02-27 2019-01-29 Samsung Electronics Co., Ltd. Trust-zone-based end-to-end security
US20160379303A1 (en) 2015-06-23 2016-12-29 Retail Capital, LLC System and method for credit evaluation
US20170193513A1 (en) * 2016-01-04 2017-07-06 American Express Travel Related Services Company, Inc. Digital wallet fraud guard
CN115719224A (zh) 2016-01-25 2023-02-28 创新先进技术有限公司 基于移动终端卡模拟的信用支付方法及装置
CN105894279A (zh) * 2016-03-29 2016-08-24 联想(北京)有限公司 一种信息处理方法及装置、设备
US20180039989A1 (en) * 2016-08-04 2018-02-08 Bank Of America Corporation Online transaction efficiency improvement system
US11144928B2 (en) * 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
CN106418952A (zh) * 2016-09-27 2017-02-22 彭泽令 一种多功能电子钱包及其钱币金额获取和消费统计方法
US10218697B2 (en) * 2017-06-09 2019-02-26 Lookout, Inc. Use of device risk evaluation to manage access to services
CN107369019B (zh) * 2017-06-26 2020-10-09 中国人民银行数字货币研究所 数字货币钱包的解绑定方法和系统
CN107527201A (zh) * 2017-07-03 2017-12-29 阿里巴巴集团控股有限公司 数据处理方法、装置和设备
CN107545416A (zh) * 2017-07-28 2018-01-05 阿里巴巴集团控股有限公司 加油、加油结算、加油支付方法、装置以及电子设备
CN107578238A (zh) * 2017-08-08 2018-01-12 阿里巴巴集团控股有限公司 一种风险控制方法及设备
CN107563738A (zh) * 2017-08-29 2018-01-09 北京小米移动软件有限公司 选定支付账户的方法及支付设备
CN107578230A (zh) * 2017-09-05 2018-01-12 深圳天珑无线科技有限公司 一种信用支付方法、系统、移动终端及计可读存储介质
WO2019105296A1 (zh) * 2017-11-29 2019-06-06 华为技术有限公司 绑卡方法及终端
US20190205867A1 (en) * 2018-01-03 2019-07-04 Mastercard International Incorporated Wallet provider data process for facilitating digitization of payment account

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104618415A (zh) * 2014-03-13 2015-05-13 腾讯科技（深圳）有限公司 信用账户创建方法、装置及系统
CN106296187A (zh) * 2015-06-03 2017-01-04 深圳卡通新技术有限公司 一种电子支付安全控制方法及系统
CN106779701A (zh) * 2016-11-22 2017-05-31 中国银联股份有限公司 一种支付方法和装置
CN107146076A (zh) * 2017-04-10 2017-09-08 广州智造家网络科技有限公司 安全交易方法及系统
CN108399543A (zh) * 2018-01-23 2018-08-14 阿里巴巴集团控股有限公司 支付卡的绑定方法、信任评估方法、装置和电子设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112053161A (zh) * 2020-05-09 2020-12-08 支付宝(杭州)信息技术有限公司 绑定处理方法、装置及设备
CN112053161B (zh) * 2020-05-09 2022-11-11 支付宝(杭州)信息技术有限公司 绑定处理方法、装置及设备
CN113205331A (zh) * 2020-11-24 2021-08-03 支付宝(杭州)信息技术有限公司 一种支付方法及装置、电子设备和存储介质
CN113205331B (zh) * 2020-11-24 2023-04-07 支付宝(杭州)信息技术有限公司 一种支付方法及装置、电子设备和存储介质

Also Published As

Publication number Publication date
CN108399543B (zh) 2020-09-04
CN112258178A (zh) 2021-01-22
US20200279248A1 (en) 2020-09-03
TWI703520B (zh) 2020-09-01
SG11202006066TA (en) 2020-07-29
US10902415B2 (en) 2021-01-26
TW201933212A (zh) 2019-08-16
CN112258178B (zh) 2024-01-26
CN108399543A (zh) 2018-08-14

Similar Documents

Publication Publication Date Title
WO2019144807A1 (zh) 支付卡的绑定方法、信任评估方法、装置和电子设备
KR102419050B1 (ko) 블록체인 잔고 조정 방법 및 디바이스, 및 전자 디바이스
US10963901B2 (en) Systems and methods for use in facilitating enrollment in loyalty accounts
US10433128B2 (en) Methods and systems for provisioning multiple devices
US9491626B2 (en) Enhanced data interface for contactless communications
US20180053189A1 (en) Systems and methods for enhanced authorization response
US10776771B2 (en) Electronic resource processing method and device
US10318954B1 (en) Processor routing number for mobile communication service provider billing
US20150161620A1 (en) System and method for risk and fraud mitigation for merchant on-boarding
US20170357965A1 (en) System and method for token based payments
JP2012523635A (ja) モバイルネットワークにおけるモバイルコンテンツ配信
CN109146493B (zh) 消费数据处理方法及装置
US20220036351A1 (en) Method and apparatus for resource exchange
WO2020114113A1 (zh) 支付码生成、移动支付方法、装置及设备
TW201841134A (zh) 貨幣類型的切換方法及裝置
US11328287B2 (en) Systems and methods for coordinating virtual wallet defaults
CN109409875B (zh) 一种账单校验方法、装置及电子设备
US9477957B2 (en) Systems and methods for transferring value to payment accounts
US11436592B2 (en) Systems and methods for coordinating virtual wallet defaults
US20140194091A1 (en) Method and System for User Signup by a Network Service Provider
US20160071075A1 (en) Systems and Methods for Transferring Value to Payment Accounts
US20190188714A1 (en) Method for permitting a transaction indicating an amount that is less than a threshold amount
US20230394467A1 (en) System and method for providing restricted token usage during an onboarding phase
WO2022082172A1 (en) Aggregated transaction accounts
CN113947481A (zh) 资源转换方法、装置、计算机设备和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19743382

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19743382

Country of ref document: EP

Kind code of ref document: A1