WO2022016840A1 - 数据处理方法、装置、设备及介质 - Google Patents

数据处理方法、装置、设备及介质 Download PDF

Info

Publication number
WO2022016840A1
WO2022016840A1 PCT/CN2021/072925 CN2021072925W WO2022016840A1 WO 2022016840 A1 WO2022016840 A1 WO 2022016840A1 CN 2021072925 W CN2021072925 W CN 2021072925W WO 2022016840 A1 WO2022016840 A1 WO 2022016840A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
payment
activated
mark
electronic device
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.)
Ceased
Application number
PCT/CN2021/072925
Other languages
English (en)
French (fr)
Inventor
詹成初
蒋海俭
邹震中
林晋任
刘刚
才华
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Priority to JP2022541670A priority Critical patent/JP7454052B2/ja
Priority to US17/910,676 priority patent/US20230058201A1/en
Priority to AU2021312655A priority patent/AU2021312655A1/en
Publication of WO2022016840A1 publication Critical patent/WO2022016840A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q20/354—Card activation or deactivation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • the present application belongs to the technical field of data processing, and in particular, relates to a data processing method, apparatus, device and medium.
  • NFC Near Field Communication
  • Embodiments of the present application provide a data processing method, apparatus, device, and medium, which can solve the problem that errors are prone to occur in the process of setting a default payment card.
  • an embodiment of the present application provides a data processing method, including:
  • the target activation data includes the to-be-activated payment mark corresponding to the to-be-activated payment card account;
  • the target payment mark in the target personalized data is updated to the payment mark to be activated; wherein, the transaction card type to which the target personalized data belongs is the same as the transaction card type to which the target activation instruction belongs;
  • an embodiment of the present application provides a data processing method, including:
  • the transaction card type of the payment card account to be activated is the same as the transaction card type to which the target activation instruction belongs;
  • the target activation instruction is used to make the target electronic device update the target payment mark in the target personalization data to the payment mark to be activated and set the updated target payment mark as In the activation state, the transaction card type to which the target personalized data belongs is the same as the transaction card type to which the target activation instruction belongs.
  • an embodiment of the present application provides a data processing device, including:
  • a first receiving module configured to receive target activation data and target activation instructions sent by the target server; wherein, the target activation data includes a to-be-activated payment mark corresponding to a to-be-activated payment card account;
  • the first processing module is used to update the target payment mark in the target personalized data to the payment mark to be activated in response to the target activation instruction; wherein, the transaction card type to which the target personalized data belongs and the transaction card type to which the target activation instruction belongs same;
  • the second processing module is configured to set the updated target payment mark to an active state.
  • an embodiment of the present application provides a data processing device, including:
  • the first obtaining module is used to obtain the payment mark to be activated and the target activation instruction stored in association with the payment card account to be activated; wherein, the transaction card type of the payment card account to be activated is the same as the transaction card type to which the target activation instruction belongs;
  • the first generation module is used for generating target activation data according to the payment mark to be activated
  • the first sending module is used to send the target activation data and the target activation instruction to the target electronic device; wherein, the target activation instruction is used to make the target electronic device update the target payment mark in the target personalization data to the payment mark to be activated and update the update
  • the subsequent target payment flag is set to an active state, and the transaction card type to which the target personalized data belongs is the same as the transaction card type to which the target activation instruction belongs.
  • an embodiment of the present application provides a data processing device, the device comprising: a processor and a memory storing computer program instructions;
  • the data processing method according to the first aspect or the second aspect is implemented when the processor executes the computer program instructions.
  • an embodiment of the present application provides a computer-readable storage medium, where computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are executed by a processor, the implementation is as described in the first aspect or the second aspect data processing method.
  • the data processing method, device, device and medium of the embodiments of the present application can directly activate the transaction card type and target activation after receiving the payment mark to be activated and the target activation instruction corresponding to the payment card account to be activated sent by the target server.
  • the target payment mark in the target personalization data of the same transaction card type to which the instruction belongs is updated to the payment mark to be activated, and the updated target payment mark is set to the active state, and then the target personalization data can be directly modified by the payment mark to be activated.
  • FIG. 1 is an architectural diagram of an example of data processing provided by the present application.
  • FIG 2 is an architectural diagram of another example of data processing provided by the present application.
  • FIG. 3 is an architectural diagram of another example of data processing provided by the present application.
  • FIG. 4 is an architectural diagram of yet another example of data processing provided by the present application.
  • FIG. 5 is a schematic flowchart of an embodiment of a data processing method provided by the present application.
  • FIG. 6 is a schematic flowchart of another embodiment of the data processing method provided by the present application.
  • FIG. 7 is a schematic flowchart of an example of a process of binding a payment card provided by an embodiment of the present application.
  • FIG. 8 is a schematic flowchart of an example of a process of setting a default payment card provided by an embodiment of the present application.
  • FIG. 9 is a schematic flowchart of an example of a process of changing a default payment card provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of an example of a process of unbinding a payment card provided by an embodiment of the present application
  • FIG. 11 is a schematic structural diagram of an embodiment of a data processing apparatus provided by the present application.
  • FIG. 12 is a schematic structural diagram of another embodiment of a data processing apparatus provided by the present application.
  • FIG. 13 is a schematic diagram of a hardware structure of an embodiment of a data processing device provided by the present application.
  • the data processing method provided by the present application can be applied to the architectures as shown in FIGS. 1 to 4 , and will be described in detail with reference to FIGS. 1 to 4 .
  • FIG. 1 shows an architecture diagram of an example of data processing provided by an embodiment of the present application.
  • the architecture diagram may include at least one electronic device 110 and an Internet financial platform server 120 .
  • the electronic device 110 may be a device with a communication function, such as a mobile phone, a tablet computer, a desktop computer, a vehicle terminal, and a wearable device, and the electronic device 110 has an NFC payment function.
  • a wearable device can be a portable device that can be worn by the user, or integrated into the user's clothing or accessories, such as smart bracelets, smart watches, smart sports shoes, smart clothing, smart glasses, smart helmets, smart rings, Smart accessories, etc.
  • the Internet financial platform server 120 may be used to provide Internet financial services.
  • the Internet financial platform server 120 may be a device with storage and computing functions, such as a cloud server or a server cluster.
  • each electronic device 110 may be installed with a financial application program corresponding to the Internet financial platform, and communicate with the Internet financial platform server 120 .
  • the Internet financial platform may be a third-party financial platform or a card organization platform.
  • the Internet finance platform server 120 can obtain the payment token to be activated stored in association with the payment card account to be activated of the electronic device 110 and the target activation instruction of the transaction card type to which the transaction card type is the same as the transaction card type of the activated payment card account, and use The payment token to be activated and the target activation instruction are sent to the target electronic device.
  • the payment card account number may include an account number of a physical bank card or an electronic bank card, and the payment mark and the payment card account number have a one-to-one correspondence.
  • the electronic device 110 can receive the payment mark to be activated and the target activation instruction corresponding to the payment card account to be activated sent by the Internet financial platform server 120, and then assign the transaction card type to which the target activation instruction belongs to the same target personalized data of the transaction card type to which the target activation instruction belongs.
  • the target payment mark in is updated to the payment mark to be activated, and the updated target payment mark is set to the active state.
  • FIG. 2 shows an architectural diagram of another example of data processing provided by an embodiment of the present application.
  • the architecture diagram may include at least one electronic device 110 , an Internet financial platform server 120 and a payment tokenization service system (Token Service Provider, TSP) platform server 130 .
  • TSP payment tokenization service system
  • the TSP platform server 130 may be used to generate payment tokens.
  • the TSP platform server 130 may be a device with storage and computing functions, such as a cloud server or a server cluster.
  • the Internet financial platform server 120 may communicate with the TSP platform server 130 to obtain the payment mark corresponding to the payment card account number for the user.
  • the Internet financial platform server 120 can generate the payment card account number of the payment mark as needed, generate the mark generation request, and send the mark generation request to the TSP platform server 130, so that the TSP platform server 130 generates the payment mark corresponding to the payment card account, and sends the mark to the Internet.
  • the financial platform server 120 feeds back the payment token.
  • the Internet financial platform server 120 may store the payment card account number in association with the received payment token.
  • FIG. 3 shows an architectural diagram of yet another example of data processing provided by the present application.
  • the architecture diagram may include at least one electronic device 110 , an Internet financial platform server 120 , a TSP platform server 130 and a Trusted Service Management (Trusted Service Management, TSM) platform server 140 .
  • TSM Trusted Service Management
  • the principles of the electronic device 110 , the Internet financial platform server 120 and the TSP platform server 130 are the same as those of the embodiment shown in FIG. 2 , and will not be repeated here.
  • the TSM platform server 140 may be used to implement information forwarding, and the TSM platform server 140 may be a device with storage and computing functions, such as a cloud server or a server cluster. Specifically, the TSM platform server 140 may communicate with the TSP platform server 130 through a trusted channel, so as to improve the security of information transmission.
  • the internet finance platform server 120 may communicate with the TSM platform server 140 .
  • the Internet financial platform server 120 may send the token generation request to the TSM platform server 140, and then the TSM platform server 140 sends the request to the TSP platform server 130 through a trusted channel.
  • the TSP platform server 130 may send the payment token to the TSM platform server 140 through a trusted channel, so that the TSM platform server 140 forwards the payment token to the Internet financial platform server 120 .
  • the communication security between the Internet financial platform server 120 and the TSP platform server 130 can be improved through the TSM platform server 140 and the trusted channel.
  • FIG. 4 shows an architecture diagram of yet another embodiment of data processing provided by the present application.
  • the architecture diagram may include at least one electronic device 110 , Internet financial platform server 120 , TSP platform server 130 , TSM platform server 140 , at least one acquiring device 150 and acquiring platform server 160 .
  • the principles of the electronic device 110 , the Internet financial platform server 120 , the TSP platform server 130 and the TSM platform server 140 are the same as those of the embodiment shown in FIG. 3 , which will not be repeated here.
  • the acquiring device 150 may be a mobile phone, a tablet computer, a point of sale (POS) terminal, etc., and the acquiring device 150 has an NFC information reading function.
  • POS point of sale
  • the acquiring platform server 160 may be used to provide acquiring services.
  • the acquiring platform server 160 may be a device with storage and computing functions, such as a cloud server or a server cluster.
  • the user can first log in to the account of the financial application program of the electronic device 110, make the financial application program in the login state, and enter the payment status of the specified electronic device bound to the account in the application interface of the financial application program.
  • the designated electronic device may be the electronic device 110 being operated by the user, or may be other electronic devices bound to the account, as long as it is an electronic device bound to the account that has passed device verification.
  • the user can select the payment card account whose status needs to be changed from among the multiple payment card accounts bound with the designated electronic device displayed in the application interface of the financial application program, so that the electronic device 110 can make the electronic device 110 according to the bank card account number and the designated electronic device.
  • the payment status of the device which generates a status change request.
  • the electronic device 110 may send the state change request to the Internet financial platform server 120 corresponding to the Internet financial platform.
  • the Internet financial platform server 120 may parse the received state change request to obtain the payment card account number and payment state carried in the state change request. Then, the payment mark stored in association with the payment card account number is acquired, and the mark state corresponding to the payment mark is updated to the payment status carried in the state change request. If the payment card account number is the account number of the default payment card of the electronic device 110, the Internet financial platform server 120 receives the transaction that is sent by the acquiring device 150 through the acquiring platform server 160 and carries the payment token stored in association with the payment card account number. When the request is made, whether to execute the transaction corresponding to the transaction request may be determined according to the tag status corresponding to the payment tag.
  • Each acquiring device 150 may be configured to send a transaction request carrying an activated payment token read from the secure element (Secure Element, SE) of the electronic device 110 to the Internet financial platform server through the acquiring platform server 160 120.
  • SE Secure Element
  • an acquiring application program corresponding to the acquiring platform may be installed in the acquiring device 150 .
  • the acquiring device 150 can read the payment token in the SE of the electronic device 110 through the acquiring application, and then send the payment token carrying the read payment token to the Internet financial platform server 120 through the acquiring platform server 160 corresponding to the acquiring platform. transaction request.
  • the Internet financial platform server 120 determines whether to execute the transaction corresponding to the transaction request according to the tag status corresponding to the payment tag carried in the transaction request.
  • the method in the server 120 to change the mark state corresponding to the payment mark stored in association with the payment card account bound to the designated electronic device realizes the change of the payment state of the designated electronic device, thereby reducing the payment card account associated with the target electronic device. There is a risk of being stolen and brushed, improving the security of the user's payment card account.
  • FIG. 5 shows a schematic flowchart of an embodiment of the data processing method provided by the present application.
  • the method shown in FIG. 5 may be executed by the target electronic device in the electronic device 110 shown in FIG. 1 to FIG. 4 .
  • the target electronic device may be any electronic device 110 .
  • the data processing method may include the following steps.
  • S510 Receive target activation data and target activation instructions sent by the target server.
  • the target server may be the Internet financial platform server 120 shown in FIG. 1 to FIG. 4 .
  • the target activation data may include a to-be-activated payment mark corresponding to the to-be-activated payment card account number.
  • the payment card account to be activated may include any one of the default payment card account to be set and the default payment card account to be changed, which is not limited herein.
  • the transaction card type to which the target activation instruction belongs is the same as the transaction card type of the payment card account to be activated, so that the target activation instruction can load the payment mark to be activated corresponding to the payment card account to be activated on the transaction card type to which it belongs and the payment card to be activated.
  • the account's trading card type is in the same target personalization data.
  • the transaction card type to which the target personalized data belongs is the same as the transaction card type to which the target activation instruction belongs. Therefore, it can be ensured that the to-be-activated payment mark corresponding to the to-be-activated payment card account number is loaded into the transaction card type and the to-be-activated payment card account number. In the target personalization data of the same transaction card type, avoid errors in the activation process of the payment token to be activated.
  • Personalized data can be a personalized application identifier (AID), which is composed of strings.
  • the personalized AID contains a common string, a payment tag, and a status value.
  • the payment tag is also composed of strings.
  • the payment tag and The state value can come after the generic string.
  • a generic string for personalizing AID could be: A000000333 010102 00 63020000 01 0000.
  • the first 10 digits can be fixed strings
  • the 11-16 digits can be used to indicate the account type, such as the debit type is 010101
  • the credit type is 010102
  • the quasi-credit type is 010103
  • the 17-18 digits can indicate Application type, such as 00 for financial applications and 01 for non-financial applications
  • the 19th-26th digits can be the institution code of the application provider
  • the 27th-28th digits can be extended, and its functions can be customized
  • the chip card type can be indicated, such as 0000 for PBOC2.0 type and 1000 for PBOC3.0 type.
  • the target payment mark in the target personalization data may be an initialization mark.
  • the target electronic device may replace the initialization token with the payment token to be activated in response to the target activation instruction.
  • the target activation instruction may be an application protocol data unit (Application Protocol Data Unit, APDU) instruction, such as: an Install for install command, specifically, refer to the parameter definition in GP Amendment C.
  • APDU Application Protocol Data Unit
  • the target electronic device can be installed with the target personalized data activation program corresponding to the target personalized data, and execute the target loading operation corresponding to the target activation instruction through the target personalized data activation program, that is, through the target personalized data activation program, the target personalized data is activated.
  • the target payment token in is updated to the payment token to be activated.
  • the target electronic device can execute the target activation operation corresponding to the target activation instruction through the target personalized data activation program, that is, activate the target personalized data through the target personalized data activation program, thereby realizing the activation of the target payment mark.
  • the transaction card type to which the target activation instruction belongs can be directly changed to the same transaction card type as the transaction card type to which the target activation instruction belongs.
  • the target payment mark in the target personalization data is updated to the payment mark to be activated, and the updated target payment mark is set to the active state, and then the target payment mark in the target personalization data can be updated and updated directly by the payment mark to be activated.
  • Activating the updated target payment token eliminates the need to delete the activated payment token and its corresponding personalized data in the process of activating the payment token to be activated, thereby reducing the deletion of personalized data and personalization data in the process of activating the payment token to be activated.
  • the process of verification and personalized data download avoids errors caused by the above process when setting the default payment card, and improves the success rate of setting the default card.
  • the data processing method may further include:
  • a default card setting request is sent to the target server; wherein the default card setting request is used to make the target server feed back target activation data and target activation instructions corresponding to the default payment card account to be set.
  • the user may select any payment card account number as the default payment card account to be set from at least one payment card account number bound to the target electronic device displayed in the application interface of the financial application program of the target electronic device.
  • the electronic device can generate a default card setting request according to the default payment card account number to be set and the target electronic device identifier, and then send the default card setting request to the Internet financial platform server, so that the Internet financial platform server can feed back the corresponding default payment card account number to be set.
  • Target activation data and target activation instructions The method for the Internet financial platform server to feed back target activation data and target activation instructions will be described in detail later.
  • the target electronic device identifier may be an Internet Protocol (Internet Protocol, IP) address of the target electronic device.
  • IP Internet Protocol
  • the target electronic device identifier may also be a device identification code (Identity document, ID) of the target electronic device.
  • the target personalized data may be the target electronic device Personalization data for which the payment token stored in the target secure element is inactive.
  • the target electronic device when receiving the target activation data and the target activation instruction sent by the target server, may directly execute S520 if the target personalization data has been stored in the target secure element of the target electronic device.
  • the target activation data received by the target electronic device Data when receiving the target activation data and the target activation instruction sent by the target server, in the case that the target personalization data is not stored in the target secure element of the target electronic device, the target activation data received by the target electronic device Data also includes personalization data that can be targeted.
  • the data processing method may further include:
  • the target personalization data is stored in the target secure element.
  • the target personalized data can be loaded into the target security element first, so as to ensure that the payment mark to be activated corresponding to the payment card account to be activated is activated. reliability.
  • the data processing method may further include:
  • a default card change request is sent to the target server, wherein the default card change request is used to make the target server feed back target activation data and target activation instructions corresponding to the default payment card account to be changed.
  • the user can select any payment card account other than the payment card account that has been set as the default payment card from at least one payment card account number bound to the target electronic device displayed in the application interface of the financial application program of the target electronic device.
  • the card account number is used as the default payment card account number to be changed.
  • the target electronic device can generate a default card change request according to the default payment card account number to be changed and the target electronic device identifier, and then send the default card change request to the Internet financial platform server, so that the Internet financial platform server can feed back the corresponding default payment card account number to be changed.
  • target activation data and target activation instructions The method for the Internet financial platform server to feed back target activation data and target activation instructions will be described in detail later.
  • the target personalization data may be the personalization data in which the payment token stored in the target secure element is in an active state. In other embodiments, the target personalization data may also be the personalization data in which the payment tag stored in the target secure element is in an inactive state, which is not limited herein.
  • the target electronic device when receiving the target activation data and the target activation instruction sent by the target server, may directly execute S520 if the target personalization data has been stored in the target secure element of the target electronic device.
  • the target activation data received by the target electronic device Data when receiving the target activation data and the target activation instruction sent by the target server, in the case that the target personalization data is not stored in the target secure element of the target electronic device, the target activation data received by the target electronic device Data also includes personalization data that can be targeted.
  • the data processing method may further include:
  • the target personalization data is stored in the target secure element.
  • the target personalized data can be loaded into the target security element first, so as to ensure that the payment mark to be activated corresponding to the payment card account to be activated is activated. reliability.
  • the data processing method may further include:
  • the target electronic device may execute the target restoration operation corresponding to the target activation instruction through the target personalized data activation program, that is, through the target personalized data activation program, the personalized data of the payment mark that is in the activated state is set as Inactive state, and then cancel the activation of the payment mark originally in the active state, to ensure that only one payment mark in the target security element of the target electronic device is in the active state.
  • FIG. 6 shows a schematic flowchart of another embodiment of the data processing method provided by the present application.
  • the method shown in FIG. 6 may be executed by the Internet financial platform server 120 shown in FIG. 1 to FIG. 4 .
  • the data processing method may include the following steps.
  • S610 Acquire the payment mark to be activated and the target activation instruction stored in association with the account of the payment card to be activated.
  • the transaction card type of the payment card account to be activated is the same as the transaction card type to which the target activation instruction belongs.
  • the Internet financial platform server can obtain the payment mark to be activated stored in association with the account of the payment card to be activated from the locally stored payment mark, and obtain the type of transaction card to which it belongs and the payment card to be activated from the activation instruction stored locally.
  • the payment mark to be activated may be loaded into a data packet corresponding to the target activation data, so as to generate the target activation data.
  • the target activation instruction is used to make the target electronic device update the target payment mark in the target personalization data to the payment mark to be activated and set the updated target payment mark to the active state, the transaction card type to which the target personalization data belongs and the target activation
  • the transaction card type to which the order belongs is the same.
  • the target activation instruction to be activated Pay mark after obtaining the payment mark to be activated stored in association with the payment card account to be activated and the target activation instruction to which the transaction card type to which it belongs is the same as the transaction card type of the payment card account to be activated, according to the target activation instruction to be activated Pay mark, generate target activation data, and send target activation data and target activation instruction to the target electronic device, so that the target electronic device will assign the transaction card type to which the target activation instruction belongs to the target in the target personalized data of the same transaction card type
  • the payment mark is updated to the payment mark to be activated, and the updated target payment mark is set to an active state, and then the target payment mark in the target personalized data can be updated directly by using the payment mark to be activated and the updated target payment mark is activated , there is no need to delete the activated payment token and its corresponding personalized data in the process of activating the payment token to be activated, thereby reducing the personalization data deletion, personalized data verification and personalized data download in the process of
  • the data processing method may further include:
  • S620 may specifically include:
  • Target activation data is generated according to the payment token to be activated and the target personalization data.
  • the Internet financial platform server can obtain the target personalized data of the same transaction card type as the transaction card type to which the target activation instruction belongs from the locally stored personalized data, and store the target personalized data together with the payment mark to be activated. Loaded into the data package corresponding to the target activation data to generate target activation data.
  • the data processing method may further include:
  • obtaining target personalized data may specifically include:
  • the target personalization data is acquired.
  • the Internet financial platform server needs to first send a data query request to the target electronic device to query whether the target security element of the target electronic device has stored the target personalized data. After receiving the data query request, the target electronic device can query whether the target personalization data is stored in the target security element, and feed back the data query result to the Internet financial platform server. The Internet financial platform server can receive the data query result fed back by the target electronic device.
  • the target activation data can be generated directly according to the payment mark to be activated; if the data query result is If the target personalization data is not queried in the target secure element, the target personalization data can be obtained, and the target activation data can be generated according to the payment mark to be activated and the target personalization data.
  • the target security element of the target electronic device stores the target personalization data required to activate the payment mark to be activated, and then, according to the judgment result, it is determined whether to send the target individual to the target electronic device. to enable the target electronic device to reliably effect the activation of the payment token to be activated.
  • the target personalized data required for the payment mark to be activated may be the personalized data of the same transaction card type as the transaction card type to which the target activation instruction belongs.
  • a payment card type can correspond to a set of personalized data.
  • a credit card type may correspond to a set of personalized data
  • a debit card type may correspond to a set of personalized data
  • One type of payment card can correspond to a set of general personalization data, which can eliminate the differences in the personalization data among various payment card issuers, and improve the compatibility between the device card and the industry machine.
  • the payment card account number to be activated may include a default payment card account number to be set.
  • the data processing method may further include:
  • the default card setting request is parsed to obtain default card setting request information; wherein the default card setting request information includes the default payment card account number to be set.
  • the Internet finance platform server can parse the default card setting request in response to the default card setting request, obtain the default payment card account number to be set and the target electronic device identifier of the target electronic device, and then query and The payment mark stored in association with the default payment card account to be set is used as the payment mark to be activated.
  • the Internet financial platform server can send target activation data and target activation instructions corresponding to the default payment card account to be set for the target electronic device when the user has a default card setting requirement for the target electronic device.
  • the data processing method may further include:
  • An association relationship between the payment token to be activated and the target electronic device is established.
  • the target electronic device after executing the target activation instruction, the target electronic device will feed back the activation result to the Internet financial platform server.
  • the activation result may be used to indicate that the target electronic device has set the payment flag to be activated to an activated state, or may be used to indicate that the target electronic device has failed to activate the payment flag to be activated.
  • the Internet financial platform server may, after sending the target activation data and the target activation instruction to the target electronic device, receive the activation result sent by the target electronic device, and when the activation result is used to indicate that the target electronic device has set the to-be-activated payment flag to the activated state
  • the attribute of the payment card corresponding to the account of the payment card to be activated is set as the default payment card of the target electronic device
  • the mark state corresponding to the payment mark to be activated is set to the activated state
  • the payment mark to be activated is established with the The association relationship between the target electronic device identifiers of the target electronic device enables the NFC payment function of the target electronic device to be available.
  • the Internet financial platform server may feed back the first prompt information to the target electronic device.
  • the first prompt information is used to prompt the user that the default payment card of the target electronic device is successfully set, and the NFC payment function can be used normally through the default payment card.
  • the bound payment card account number and the personalized data in the target electronic device belong to a loosely coupled relationship, that is, a dynamic mapping relationship.
  • the payment card account number to be activated may further include a default payment card account number to be changed.
  • the data processing method may further include:
  • the default card change request is parsed to obtain default card change request information; wherein the default card change request information includes the default payment card account number to be changed.
  • the Internet financial platform server can respond to the default card change request, parse the default card change request, obtain the default payment card account number to be changed and the target electronic device identifier of the target electronic device, and then query and The payment mark stored in association with the default payment card account to be changed is used as the payment mark to be activated.
  • the Internet financial platform server can send target activation data and target activation instruction corresponding to the default payment card account number to be changed to the target electronic device when the user has a demand for changing the default card of the target electronic device.
  • the data processing method may further include:
  • the target payment card account number wherein, the payment card attribute corresponding to the target payment card account number is the target attribute, and the target attribute is the default payment card of the target electronic device.
  • sending a data query request to the target electronic device may specifically include:
  • a data query request is sent to the target electronic device.
  • the Internet financial platform server may query the target payment card account number of the default payment card whose current payment card attribute is the target electronic device, that is, the original default payment card account number. Then, the payment card type of the target payment card account number is compared with the payment card type of the default payment card account number to be changed. Finally, if the comparison result is that the payment card type of the target payment card account is the same as the payment card type of the default payment card account to be changed, it means that the target personalization data is stored in the target secure element of the target electronic device, which can be directly activated according to the type of the target payment card. Pay token, generate target activation data.
  • the comparison result is that the payment card type of the target payment card account is different from the payment card type of the default payment card account to be changed, it means that the target security element of the target electronic device does not store the target personalized data, and it needs to be sent to the target electronic device.
  • Target personalization data therefore, the target personalization data can be acquired, and the target activation data can be generated according to the payment token to be activated and the target personalization data.
  • the data processing method may further include:
  • An association relationship between the payment mark to be activated and the target electronic device is established, and the association relationship between the target payment mark and the target electronic device is deleted.
  • the target electronic device after executing the target activation instruction, the target electronic device will feed back the activation result to the Internet financial platform server.
  • the activation result may be used to indicate that the target electronic device has set the payment flag to be activated to an activated state, or may be used to indicate that the target electronic device has failed to activate the payment flag to be activated.
  • the Internet financial platform server may, after sending the target activation data and the target activation instruction to the target electronic device, receive the activation result sent by the target electronic device, and when the activation result is used to indicate that the target electronic device has set the to-be-activated payment flag to the activated state
  • the payment card attribute corresponding to the payment card account to be activated can be set as the default payment card of the target electronic device, and the payment card attribute corresponding to the original default payment card account number can be set as the non-target attribute
  • the mark state corresponding to the payment mark to be activated can be set to the active state, and the mark state corresponding to the original target payment mark stored in association with the original default payment card account number can be set to the inactive state.
  • the payment mark to be activated and the target electronic The association relationship between the target electronic device identifiers of the device, make the payment mark to be activated as the new target payment mark, and delete the association relationship between the original target payment mark and the target electronic device identification of the target electronic device.
  • the Internet financial platform server may feed back the second prompt information to the target electronic device.
  • the second prompt information is used to prompt the user that the default payment card of the target electronic device is successfully changed, and the NFC payment function can be used normally through the new default payment card.
  • the association between the payment mark to be activated and the target electronic device can be established, and the association between the original target payment mark and the target electronic device can be deleted, so as to realize the connection between the default payment card account and the target electronic device. Changes in the mapping relationship between target electronic devices.
  • the data processing method may further include:
  • the payment card binding request parsing the payment card binding request to obtain payment card binding request information; wherein the payment card binding request information includes the payment card account number to be bound;
  • the mark generation request is used to make the payment mark management server generate a payment mark corresponding to the payment card account to be bound;
  • the payment card account to be bound and the payment mark corresponding to the payment card account to be bound are associated and stored.
  • the user can first log in to the account of the financial application program of the target electronic device, keep the financial application program in the login state, and select the target electronic device bound to the account in the application interface of the financial application program, that is, the electronic device that the user is operating. Then, the user can add the payment card account number bound to the target electronic device in the application interface of the financial application program as the payment card account number to be bound, so that the target electronic device can generate a payment card binding request according to the payment card account number to be bound . Next, the target electronic device may send the payment card binding request to the Internet financial platform server.
  • the Internet financial platform server can parse the payment card binding request to obtain the target electronic device identifier of the payment card account to be bound and the target electronic device. According to the payment card account to be bound, a mark generation request is generated, and the mark generation request is sent to the payment mark management server.
  • the payment token management server may be the TSP platform server 130 shown in FIG. 2 to FIG. 4 .
  • the TSP platform server may parse the token generation request to obtain the payment to be bound. card account number, then generate a payment mark corresponding to the payment card account to be bound, and associate and store the payment card account to be bound with the payment mark corresponding to the payment card account to be bound.
  • the payment mark corresponding to the payment card account to be bound is fed back to the Internet financial platform server.
  • the Internet finance platform server can receive the payment token corresponding to the payment card account to be bound fed back by the TSP platform server, and then associate and store the payment token corresponding to the payment card account to be bound and the payment card account to be bound, so that the user can When the bound payment card account number is set for the target electronic device or the default payment card account number is changed, the payment mark corresponding to the default payment card account number may be sent to the target electronic device.
  • the Internet financial platform server may also send third prompt information to the target electronic device after binding the target payment card account number to the target electronic device.
  • the third prompt information is used to prompt the user that the payment card account to be bound is successfully bound with the target electronic device.
  • the TSP platform server may generate a payment mark corresponding to the payment card account to be bound by using a preset mark generation method.
  • the mark generation method may be to use a preset encryption algorithm to encrypt all numbers of the account to be bound with the payment card to obtain an encrypted encrypted string, and use the encrypted string as the payment mark corresponding to the account of the payment card to be bound.
  • the mark generation method may be to use a preset encryption algorithm to encrypt part of the numbers to be bound with the payment card account, to obtain an encrypted encrypted string, and to perform encryption between the unencrypted numbers to be bound with the payment card account and the encrypted string. Splicing to obtain the payment mark corresponding to the payment card account to be bound.
  • the Internet financial platform server may communicate with the TSP platform server through the TSM platform server, so as to improve data security.
  • the data processing method may further include:
  • the state change request In response to the state change request, analyze the state change request to obtain state change request information; wherein, the state change request information includes the payment card account number of the state to be changed and the target payment state of the target electronic device;
  • the status change request is used to request the Internet finance platform server to update the mark status corresponding to the payment mark in the status to be changed stored in association with the payment card account of the status to be changed specified by the user to the target electronic device specified by the user
  • the target payment status of the device can be a state change request sent by the target electronic device, or a state change request sent by other electronic devices other than the target electronic device, as long as the electronic device is installed with the financial application corresponding to the Internet financial platform and the financial application is installed.
  • the logged-in account is bound to the target electronic device whose payment status of the NFC payment function needs to be changed.
  • the user can first log in to the account of the financial application program of the electronic device, make the financial application program in the login state, and select the target electronic device to which the account has been bound in the application interface of the financial application program. Then, the user can input the payment card account number to be changed and the target payment status of the target electronic device in the application interface of the financial application program, and the target payment status can be the payment status of the target electronic device the user wants to change.
  • the electronic device operated by the user can generate a state change request according to the payment card account number to be changed and the target payment state, and send the state change request to the Internet financial platform server.
  • the target payment state may include any one of an activation state, a loss reporting state, and an unbinding state.
  • the target payment state can be divided into a normal state and an abnormal state, the abnormal state can include any one of the loss reporting state and the unbinding state, and the normal state can include the activated state.
  • the activated state means that the NFC payment function of the electronic device is activated and available.
  • the loss-reporting state means that the NFC payment function of the electronic device has been activated and is in the loss-reporting registration state. In the loss-reporting state, the NFC payment function is suspended.
  • the unbound state means that the NFC payment function of the electronic device has been activated and the payment card account is not bound. In the unbound state, the NFC payment function is also suspended.
  • the target electronic device or other electronic devices may directly communicate with the Internet financial platform server.
  • the status change request information may further include an identifier of the target electronic device.
  • the electronic device operated by the user after the electronic device operated by the user receives the payment card account number to be changed and the target payment state of the target electronic device input by the user, it can also obtain the target electronic device identification corresponding to the target electronic device, and then can obtain the target electronic device identification based on the target electronic device identification, The payment card account number to be changed and the target payment state generate a state change request.
  • the Internet financial platform server may store the mark state corresponding to the payment mark. For example, the Internet financial platform server may add a status bit to the payment mark, the status bit is provided with a status value, one status value corresponds to one mark status, and different status values correspond to different mark statuses. Meanwhile, the token status is the same as the payment status.
  • the Internet finance platform server may determine the target status value corresponding to the marked status that is the same as the target payment status, and set the payment mark status bit of the status to be changed to The target state value is used to update the tag state corresponding to the payment tag of the state to be changed to the target payment state.
  • the Internet financial platform server can, according to the mark status corresponding to the payment mark, The payment status of the electronic device corresponding to the payment mark is determined, and then it can be determined whether to execute the transaction corresponding to the transaction request carrying the payment mark according to the payment status of the electronic device.
  • the target payment status of the target electronic device can be updated through the target mark status corresponding to the target payment mark, without deleting the target payment mark in the target electronic device, only the target mark of the target payment mark in the Internet financial platform server needs to be changed.
  • By updating the status of the target electronic device it can avoid the problem that the user cannot change the payment status of the target electronic device after the target electronic device is lost, thereby reducing the risk of the bank account associated with the target electronic device being stolen, and improving the security of the user's bank account. sex.
  • the payment mark corresponding to the state to be changed can be directly marked.
  • the marked state is updated to the target payment state, and then the fourth prompt information is fed back to the target electronic device.
  • the fourth prompt information is used to prompt the user that the payment status of the payment card account whose status is to be changed and bound to the target electronic device has been changed to the target payment status.
  • the information processing method may further include:
  • the transaction request is parsed to obtain transaction request information; wherein the transaction request information includes a target payment mark;
  • the abnormal state includes any one of the loss reporting state and the unbinding state.
  • the merchant can read the activated payment mark stored in the target secure element of the target electronic device through the target acquiring device, that is, the target payment mark.
  • the target payment mark, the target acquiring device identification of the target acquiring device, and the transaction amount generate a transaction request, and then send the transaction request to the Internet financial platform server.
  • the target acquiring device identification may be the IP address of the target acquiring device identification, or may be the device ID of the target acquiring device identification.
  • the Internet financial platform server can receive the transaction request sent by the target acquiring device, and analyze the transaction request to obtain the target payment mark, the target acquiring device identification and the transaction amount, and then query the mark status corresponding to the target payment mark.
  • the Internet financial platform server may refuse to execute the transaction corresponding to the transaction request when the mark state corresponding to the target payment mark is abnormal; when the mark state corresponding to the target payment mark is normal, the query is stored in association with the target payment mark the target transaction card account number, send the target transaction card account number, target acquiring device identification and transaction amount to the card issuer server, so that the card issuer server completes the transaction corresponding to the transaction request, and realizes the transfer of the transaction amount from the target transaction card account number to the target recipient.
  • the single device ID corresponds to the transaction card account number, and then the transaction completion result is fed back to the Internet financial platform server. After receiving the transaction completion result, the Internet financial platform server may forward the transaction completion result to the target acquiring device.
  • the target acquiring device may directly communicate with the Internet financial platform server, and the target acquiring device may also communicate with the Internet financial platform server through the acquiring platform server, which is not limited herein.
  • the user does not need to delete the personalized data or the payment mark stored in the target secure element of the target electronic device, but only needs to change the payment status of the target electronic device to an abnormal state, so that the target electronic device
  • the marked status of the corresponding payment mark is changed to the abnormal status, so that when the target electronic device is used for payment again, the Internet financial platform server can refuse to execute the transaction, so as to avoid the bank account associated with the target electronic device from being stolen and swiped.
  • the information processing method may further include:
  • the payment card attribute corresponding to the payment card account in the state to be changed is the target attribute
  • the association relationship between the payment card account in the state to be changed and the target electronic device is deleted.
  • the target attribute is the default payment card of the target electronic device.
  • the Internet financial platform server can determine whether there is an association relationship between the payment mark and the target electronic device, and then determine the payment card attribute corresponding to the payment card account number stored in association with the payment mark. If there is a relationship between the payment mark and the target electronic device association relationship, then the payment card attribute corresponding to the payment card account number stored in association with the payment tag is the default payment card of the target electronic device, otherwise the payment card attribute corresponding to the payment card account number stored in association with the payment tag is the non-default payment card of the target electronic device Card.
  • the payment token Since the payment token is stored in the target secure element of the target electronic device only when the payment card attribute corresponding to the payment card account number stored in association with the payment token is the default payment card of the target electronic device, the payment token will be stored in the target secure element of the target electronic device.
  • the payment card attribute corresponding to the payment card account in the state is a non-default payment card of the target electronic device, it is only necessary to update the mark state corresponding to the payment mark whose status is to be changed to the target payment status.
  • the payment card attribute corresponding to the payment card account whose status is to be changed is the default payment card of the target electronic device
  • the target secure element of the target electronic device since the target secure element of the target electronic device stores the payment mark to be changed, in order to avoid the occurrence of the Internet financial platform server If there is a verification error, the association relationship between the payment card account in the state to be changed and the target electronic device can be further deleted, so that after receiving the transaction request corresponding to the payment mark in the state to be changed and determining that the target payment state is normal, It is further determined whether there is an associated relationship between the payment mark to be changed and the target electronic device, and then it is determined whether to execute the transaction corresponding to the transaction request.
  • the transaction corresponding to the transaction request is executed; if there is no association between the payment mark to be changed and the target electronic device, the transaction is not executed. Request the corresponding transaction.
  • the security of the bank account associated with the target electronic device can be further improved.
  • the information processing method may further include:
  • the Internet financial platform server can generate transaction feedback information corresponding to the transaction request, so that the transaction feedback information carries the mark state corresponding to the target payment mark, and then sends the transaction feedback information to the target acquiring device.
  • the target acquiring device receives the transaction feedback information, it can display the mark status corresponding to the target payment mark carried by the transaction feedback information, so as to show the target payment status of the target electronic device to the transaction-related personnel (payee or payer). Inform the person involved in the transaction of the reason for the refusal of the transaction.
  • FIG. 7 shows a schematic flowchart of an example of a process of binding a payment card provided by an embodiment of the present application.
  • the process of binding the payment card may include:
  • the user opens the application interface of the financial application program of the target electronic device, logs in the account in the application interface of the financial application program, and selects the payment card type to be bound to the target electronic device, so that the target electronic device receives the payment card input by the user type;
  • the user inputs the payment card account number to be bound to the target electronic device on the application interface of the financial application program, so that the target electronic device receives the payment card account number input by the user;
  • the target electronic device judges the type of the payment card, if the type of the payment card is a debit card type, execute S704, and if the type of the payment card is a credit card type, execute S705;
  • the target electronic device displays the debit card verification page, so that the user checks the payment card information corresponding to the payment card account, and inputs the withdrawal password and the verification code sent by the Internet financial platform server of the financial application under the condition that the withdrawal password is correct, Make the target electronic device receive the verification code input by the user, and then execute S706;
  • the target electronic device displays a credit card verification page, enabling the user to check the payment card information corresponding to the payment card account, and to receive the inputted CVN2 code of the credit card, the validity period of the credit card, and the Internet financial platform server of the financial application confirming the credit card.
  • the verification code sent when the CVN2 code of the debit card and the valid period of the credit card are correct, so that the target electronic device receives the verification code input by the user, and then executes S706;
  • the target electronic device generates a payment card binding request according to the verification code, the payment card account number and the target electronic device identifier of the target electronic device;
  • the target electronic device sends a payment card binding request to the Internet financial platform server;
  • the Internet financial platform server in response to the payment card binding request, parses the payment card binding request, and obtains the verification code, the payment card account number and the target electronic device identifier of the target electronic device, and in the case of successful verification of the verification code, Generate a token generation request based on the payment card account number;
  • the Internet financial platform server sends a tag generation request to the TSP platform server;
  • the TSP platform server generates a payment mark corresponding to the payment card account number in response to the mark generation request, and stores the payment card account number and the payment mark in association;
  • the TSP platform server sends the payment mark corresponding to the payment card account number to the Internet financial platform server;
  • the Internet financial platform server associates and stores the payment card account number and the payment mark;
  • the Internet financial platform server sends third prompt information to the target electronic device
  • the target electronic device displays third prompt information to prompt the user that the payment card account number and the target electronic device are successfully bound.
  • FIG. 8 shows a schematic flowchart of an example of a process of setting a default payment card provided by an embodiment of the present application. As shown in Figure 8, the process of setting a default payment card may include:
  • the user opens the application interface of the financial application program of the target electronic device, logs in to the account in the application interface of the financial application program, and selects a payment card account to be set as the target electronic device in at least one payment card account bound with the target electronic device The payment card account number of the default payment card, so that the target electronic device receives the payment card account number to be set entered by the user;
  • the target electronic device generates a default card setting request according to the payment card account number and the target electronic device identifier of the target electronic device;
  • the target electronic device sends a default card setting request to the Internet financial platform server;
  • the Internet financial platform server in response to the default card setting request, parses the default card setting request to obtain the payment card account number and the target electronic device identifier;
  • the Internet financial platform server queries the payment token stored in association with the payment card account, and then sends a data query request to the target electronic device;
  • the target electronic device can query whether the personalized data corresponding to the payment mark is stored in the target security element, and feed back the data query result to the Internet financial platform server;
  • the Internet financial platform server can judge the data query result. If the data query result is that the personalized data corresponding to the payment token is queried in the target security element, then execute S808, and if the data query result is that the target security element is not found in the target security element If the personalized data corresponding to the payment token is found, then execute S809;
  • the Internet financial platform server sends the payment token and the activation instruction corresponding to the payment token to the target electronic device, and then executes S810;
  • the Internet financial platform server sends the payment mark, the activation instruction corresponding to the payment mark, and the personalized data corresponding to the payment mark to the target electronic device, and then executes S810;
  • the target electronic device loads the payment mark into the personalized data corresponding to the payment mark and activates the payment mark to an active state
  • the target electronic device sends an activation result to the Internet financial platform server to indicate that the target electronic device has set the payment flag to an activated state;
  • the Internet financial platform server sets the mark state corresponding to the payment mark to the active state, then sets the payment card attribute corresponding to the payment card account number stored in association with the payment mark as the default payment card of the target electronic device, and establishes The association relationship between the payment token and the target electronic device;
  • the Internet financial platform server feeds back the first prompt information to the target electronic device
  • the target electronic device displays the first display information to prompt the user that the default payment card setting of the target electronic device is successful.
  • FIG. 9 shows a schematic flowchart of an example of a process of changing a default payment card provided by an embodiment of the present application.
  • the change default payment card process may include:
  • the user opens the application interface of the financial application program of the target electronic device, logs in to the account in the application interface of the financial application program, and selects a payment card account to be replaced with the target electronic device in at least one payment card account bound to the target electronic device.
  • the payment card account number of the new default payment card so that the target electronic device receives the payment card account number to be changed input by the user;
  • the target electronic device generates a default card change request according to the payment card account number and the target electronic device identifier of the target electronic device;
  • the target electronic device sends a default card change request to the Internet financial platform server;
  • the Internet financial platform server in response to the default card change request, parses the default card change request, and obtains the payment card account number and the target electronic device identifier;
  • the Internet financial platform server queries the payment token stored in association with the payment card account number and the payment token currently associated with the target electronic device identifier, and queries the payment card account number stored in association with the queried payment token, and the query finds
  • the payment card account number is the original default payment card account number, that is, the payment card account whose payment card attribute is the default payment card of the target electronic device;
  • the Internet financial platform server compares the payment card type of the original default payment card account with the payment card type of the received payment card account, if they are the same, execute S907, if not, execute S908;
  • the Internet financial platform server sends the received payment token corresponding to the payment card account number and the activation instruction corresponding to the payment token to the target electronic device, and then executes S909;
  • the Internet financial platform server sends the received payment token corresponding to the payment card account number, the activation instruction corresponding to the payment token, and the personalized data corresponding to the payment token to the target electronic device, and then executes S909;
  • the target electronic device loads the payment mark into the personalized data corresponding to the payment mark and activates the payment mark to an active state
  • the target electronic device sends an activation result to the Internet financial platform server to indicate that the target electronic device has set the payment flag to an activated state;
  • the Internet financial platform server first sets the payment card attribute corresponding to the payment card account number stored in association with the payment mark as the default payment card of the target electronic device, and sets the payment card attribute corresponding to the original default payment card account number as a non-target attribute, Then, the mark state corresponding to the payment mark is set to the active state, and the mark state corresponding to the payment mark stored in association with the original default payment card account number is set to the inactive state, and finally, the connection between the payment mark and the target electronic device is established. , and delete the association between the payment token stored in association with the original default payment card account and the target electronic device;
  • the Internet financial platform server feeds back second prompt information to the target electronic device
  • the target electronic device displays second prompt information to prompt the user that the default payment card of the target electronic device is successfully changed.
  • FIG. 10 shows a schematic flowchart of an example of a process of unbinding a payment card provided by an embodiment of the present application.
  • the process of unbinding the payment card may include:
  • the user opens the application interface of the financial application program of the target electronic device, logs in to the account in the application interface of the financial application program, and selects the to-be-unbound to be unbound in at least one payment card account bound to the target electronic device
  • the payment card account number so that the target electronic device receives the payment card account number to be unbound and the target payment state of the target electronic device input by the user, wherein the target payment state is the unbound state
  • the target electronic device generates an unbinding request according to the target electronic device identifier, the payment card account number and the target payment status;
  • the target electronic device sends an unbinding request to the Internet financial platform server
  • the Internet financial platform server in response to the unbinding request, parses the unbinding request to obtain the target electronic device identifier, the payment card account number and the target payment status;
  • the Internet financial platform server queries the payment card attribute corresponding to the payment card account, and judges the payment card attribute corresponding to the payment card account. If the payment card attribute is a non-default payment card of the target electronic device, execute S1006. If the payment card attribute is the default payment card of the target electronic device, execute S1007;
  • the Internet financial platform updates the mark state corresponding to the payment mark stored in association with the payment card account to the unbound state, and then executes S1008;
  • the Internet financial platform updates the mark state corresponding to the payment mark stored in association with the payment card account to an unbound state, and deletes the association relationship between the payment mark stored in association with the payment card account and the target electronic device, and then executes S1008;
  • the Internet financial platform server sends fourth prompt information to the target electronic device
  • the target electronic device displays fourth prompt information to prompt the user that the payment status of the payment card account to be unbound has been changed to the unbound state.
  • the payment card attribute corresponding to the payment card account to be unbound is the default payment card of the target electronic device
  • the Internet financial platform server receives the After the transaction request corresponding to the payment token stored in association with the payment card account is sent, the transaction corresponding to the transaction request may be rejected when it is found that the token status of the payment token is an unbound state.
  • the mark state corresponding to the payment mark stored in the Internet financial platform server can be updated to the unbinding state.
  • Users can also click the loss reporting function to update the marked status corresponding to the payment mark stored in the Internet financial platform server to the reporting status.
  • the process of reporting the loss of the payment card is similar to the process of unbinding the payment card, and details are not described here.
  • the user can also click the rebinding function and cancel the loss reporting function to make the payment mark stored in the Internet financial platform server.
  • the corresponding marked state is re-updated to the activated state, and the process is similar to the process of unbinding the payment card, which is not repeated here.
  • the target electronic device and the bound payment card account number and the personalized data loaded in the target secure element belong to a loosely coupled relationship and a dynamic mapping relationship. Therefore, the default payment is re-bound in the subsequent During the card process, it will not cause frequent verification, download and rewriting process of the card.
  • the target secure element can store general personalized data loading payment tags, which can eliminate the differences between the personalized data of various card issuers, improve the compatibility between the personalized data and the acquiring device, and has a good industry reputation. Cooperation promotion prospects.
  • FIG. 11 shows a schematic structural diagram of an embodiment of a data processing apparatus provided by the present application.
  • the apparatus shown in FIG. 11 may be the target electronic device in the electronic devices 110 shown in FIG. 1 to FIG. 4 .
  • the target electronic device may be any electronic device 110 .
  • the data processing apparatus 1100 may include a first receiving module 1110 , a first processing module 1120 and a second processing module 1130 .
  • the first receiving module 1110 may be configured to receive target activation data and target activation instructions sent by the target server.
  • the target activation data includes a to-be-activated payment mark corresponding to the to-be-activated payment card account number.
  • the first processing module 1120 may be configured to update the target payment mark in the target personalization data to the payment mark to be activated in response to the target activation instruction.
  • the transaction card type to which the target personalized data belongs is the same as the transaction card type to which the target activation instruction belongs.
  • the second processing module 1130 may be configured to set the updated target payment flag to an active state.
  • the transaction card type to which the target activation instruction belongs can be directly changed to the same transaction card type as the transaction card type to which the target activation instruction belongs.
  • the target payment mark in the target personalization data is updated to the payment mark to be activated, and the updated target payment mark is set to the active state, and then the target payment mark in the target personalization data can be updated and updated directly by the payment mark to be activated.
  • Activating the updated target payment token eliminates the need to delete the activated payment token and its corresponding personalized data in the process of activating the payment token to be activated, thereby reducing the deletion of personalized data and personalization data in the process of activating the payment token to be activated.
  • the process of verification and personalized data download avoids errors caused by the above process when setting the default payment card, and improves the success rate of setting the default card.
  • the target personalization data may be the personalization data in which the payment token stored in the target secure element is in an activated state.
  • the target personalization data may be the personalization data in which the payment token stored in the target secure element is in an inactive state.
  • the target activation data may also include target personalization data
  • the data processing apparatus 1100 may further include a first storage module, and the first storage module may be used for storing the target personalization data in the target security element.
  • the data processing apparatus 1100 may further include a third processing module, and the third processing module may be configured to set an activated payment flag other than the updated target payment flag to an inactive state.
  • the payment card account to be activated may include a default payment card account to be set.
  • the data processing apparatus 1100 may further include a second receiving module, a second generating module and a second sending module.
  • the second receiving module may be configured to receive the default payment card account number to be set.
  • the second generating module may be configured to generate a default card setting request according to the default payment card account number to be set.
  • the second sending module may be configured to send a default card setting request to the target server, wherein the default card setting request is used to make the target server feed back target activation data and target activation instructions corresponding to the default payment card account to be set.
  • the payment card account number to be activated may include a default payment card account number to be changed.
  • the data processing apparatus 1100 may further include a third receiving module, a third generating module and a third sending module.
  • the third receiving module may be configured to receive the default payment card account number to be changed.
  • the third generation module may be configured to generate a default card change request according to the default payment card account number to be changed.
  • the third sending module may be configured to send a default card change request to the target server.
  • the default card change request is used to make the target server feed back target activation data and target activation instructions corresponding to the default payment card account to be changed.
  • the data processing apparatus 1100 shown in FIG. 11 can execute various steps in the method embodiment shown in FIG. 5 , and realize various processes and effects in the method embodiment shown in FIG. 5 , which will not be described here. Repeat.
  • FIG. 12 shows a schematic structural diagram of another embodiment of the data processing apparatus provided by the present application.
  • the apparatus shown in FIG. 12 may be the Internet financial platform server 120 shown in FIG. 1 to FIG. 4 .
  • the data processing apparatus 1200 may include a first obtaining module 1210 , a first generating module 1220 and a first sending module 1230 .
  • the first obtaining module 1210 may be configured to obtain the payment mark to be activated and the target activation instruction stored in association with the payment card account to be activated; wherein, the transaction card type of the payment card account to be activated is the same as the transaction card type to which the target activation instruction belongs.
  • the first generating module 1220 may be configured to generate target activation data according to the payment mark to be activated.
  • the first sending module 1230 can be used to send the target activation data and the target activation instruction to the target electronic device; wherein, the target activation instruction is used to make the target electronic device update the target payment mark in the target personalization data to the payment mark to be activated and the target payment mark to be activated.
  • the updated target payment flag is set to an active state, and the transaction card type to which the target personalized data belongs is the same as the transaction card type to which the target activation instruction belongs.
  • the target activation instruction to be activated Pay mark after obtaining the payment mark to be activated stored in association with the payment card account to be activated and the target activation instruction to which the transaction card type to which it belongs is the same as the transaction card type of the payment card account to be activated, according to the target activation instruction to be activated Pay mark, generate target activation data, and send target activation data and target activation instruction to the target electronic device, so that the target electronic device will assign the transaction card type to which the target activation instruction belongs to the target in the target personalized data of the same transaction card type
  • the payment mark is updated to the payment mark to be activated and the updated target payment mark is set to an active state, and then the target payment mark in the target personalized data can be updated directly by using the payment mark to be activated and the updated target payment mark is activated, There is no need to delete the activated payment token and its corresponding personalized data in the process of activating the payment token to be activated, thereby reducing the process of personal data deletion, personal data verification and personal data download in the process of activ
  • the data processing apparatus 1200 may further include a second acquisition module, and the second acquisition module may be used to acquire target personalized data.
  • the first generating module 1220 may be specifically configured to generate the target activation data according to the payment mark to be activated and the target personalized data.
  • the data processing apparatus 1200 may further include a fourth sending module and a fourth receiving module.
  • the fourth sending module may be configured to send a data query request to the target electronic device.
  • the data query request is used to query the target personalization data in the target secure element of the target electronic device.
  • the fourth receiving module may be configured to receive the data query result fed back by the target electronic device.
  • the second acquisition module may be specifically configured to acquire the target personalized data when the data query result is that the target personalized data is not queried in the target security element.
  • the payment card account to be activated may include a default payment card account to be set.
  • the data processing apparatus 1200 may further include a fifth receiving module and a first parsing module.
  • the fifth receiving module may be configured to receive a default card setting request sent by the target electronic device.
  • the first parsing module may be configured to parse the default card setting request in response to the default card setting request to obtain default card setting request information.
  • the default card setting request information includes the default payment card account number to be set.
  • the data processing apparatus 1200 may further include a sixth receiving module, a fourth processing module, a fifth processing module and a sixth processing module.
  • the sixth receiving module may be configured to receive the activation result sent by the target electronic device.
  • the activation result is used to indicate that the target electronic device has set the payment flag to be activated to an activated state.
  • the fourth processing module may be configured to, in response to the activation result, set the payment card attribute corresponding to the account number of the payment card to be activated as the target attribute.
  • the target attribute is the default payment card of the target electronic device.
  • the fifth processing module may be configured to set the mark state corresponding to the payment mark to be activated to the active state.
  • the sixth processing module may be used to establish an association relationship between the payment mark to be activated and the target electronic device.
  • the payment card account number to be activated may include a default payment card account number to be changed.
  • the data processing apparatus 1200 may further include a seventh receiving module and a second parsing module.
  • the seventh receiving module may be configured to receive a default card change request sent by the target electronic device.
  • the second parsing module may be configured to parse the default card change request in response to the default card change request to obtain default card change request information.
  • the default card change request information includes the default payment card account number to be changed.
  • the data processing apparatus 1200 may further include a third acquisition module, and the third acquisition module may be used to acquire the target payment card account number.
  • the payment card attribute corresponding to the target payment card account number is the target attribute, and the target attribute is the default payment card of the target electronic device.
  • the fourth sending module may be specifically configured to send a data query request to the target electronic device when the payment card type of the target payment card account is different from the payment card type of the default payment card account to be changed.
  • the data processing apparatus 1200 may further include an eighth receiving module, a seventh processing module, an eighth processing module and a ninth processing module.
  • the eighth receiving module may be configured to receive the activation result sent by the target electronic device.
  • the activation result is used to indicate that the target electronic device has set the payment flag to be activated to an activated state.
  • the seventh processing module may be configured to, in response to the activation result, set the payment card attribute corresponding to the payment card account number to be activated as the target attribute, and set the payment card attribute corresponding to the target payment card account number as the non-target attribute.
  • the eighth processing module may be configured to set the mark state corresponding to the payment mark to be activated to the active state, and set the mark state corresponding to the target payment mark stored in association with the target payment card account number to the inactive state.
  • the ninth processing module may be configured to establish an association relationship between the payment mark to be activated and the target electronic device, and delete the association relationship between the target payment mark and the target electronic device.
  • the data processing apparatus 1200 may further include a ninth receiving module, a third parsing module, a fourth generating module, a fifth sending module, a tenth receiving module, and a second storage module.
  • the ninth receiving module may be configured to receive a payment card binding request sent by the target electronic device.
  • the third parsing module may be configured to parse the payment card binding request in response to the payment card binding request to obtain payment card binding request information.
  • the payment card binding request information includes the payment card account to be bound.
  • the fourth generation module may be configured to generate a tag generation request according to the payment card account to be bound.
  • the fifth sending module may be configured to send a mark generation request to the payment mark management server, wherein the mark generation request is used to make the payment mark management server generate a payment mark corresponding to the payment card account to be bound.
  • the tenth receiving module may be configured to receive the payment mark corresponding to the account of the payment card to be bound fed back by the payment mark management server.
  • the second storage module may be configured to associate and store the payment card account to be bound and the payment mark corresponding to the payment card account to be bound.
  • the data processing apparatus 1200 may further include an eleventh receiving module, a fourth parsing module, a fourth acquiring module, and a tenth processing module.
  • the eleventh receiving module may be configured to receive a state change request.
  • the fourth parsing module may be configured to parse the state change request in response to the state change request to obtain the state change request information.
  • the state change request information includes the payment card account number of the state to be changed and the target payment state of the target electronic device.
  • the fourth obtaining module may be configured to obtain the payment mark of the to-be-changed state stored in association with the payment card account of the to-be-changed state.
  • the tenth processing module may be configured to update the mark state corresponding to the payment mark of the to-be-changed state to the target payment state.
  • the target payment state may include any one of a loss reporting state and an unbinding state
  • the data processing apparatus 1200 may further include an eleventh processing module, and the eleventh processing module may be configured to delete the payment in the to-be-changed state under the condition that the payment card attribute corresponding to the payment card account of the to-be-changed state is the target attribute The association between the card account number and the target electronic device.
  • the target attribute is the default payment card of the target electronic device.
  • the target payment state may include any one of a loss reporting state, an unbinding state, and an activated state.
  • the data processing apparatus 1200 may further include a twelfth receiving module, a fifth parsing module, a twelfth processing module, and a thirteenth processing module.
  • the twelfth receiving module may be configured to receive the transaction request sent by the target acquiring device.
  • the fifth parsing module may be configured to parse the transaction request in response to the transaction request to obtain transaction request information.
  • the transaction request information includes the target payment mark.
  • the twelfth processing module may be used to query the mark state corresponding to the target payment mark.
  • the thirteenth processing module may be configured to refuse to execute the transaction corresponding to the transaction request when the mark state corresponding to the target payment mark is an abnormal state.
  • the abnormal state includes any one of the loss reporting state and the unbinding state.
  • the data processing apparatus 1200 may further include a fifth generating module and a sixth sending module.
  • the fifth generation module may be configured to generate transaction feedback information corresponding to the transaction request according to the mark state corresponding to the target payment mark.
  • the sixth sending module may be configured to send transaction feedback information to the target acquiring device.
  • the data processing apparatus 1200 shown in FIG. 12 can execute various steps in the method embodiment shown in FIG. 6 , and realize various processes and effects in the method embodiment shown in FIG. 6 , which will not be described here. Repeat.
  • FIG. 13 shows a schematic diagram of the hardware structure of an embodiment of the data processing device provided by the present application.
  • the data processing apparatus may include a processor 1301 and a memory 1302 having computer program instructions stored thereon.
  • the above-mentioned processor 1301 may include a central processing unit (CPU), or a specific integrated circuit (Application Specific Integrated Circuit, ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.
  • CPU central processing unit
  • ASIC Application Specific Integrated Circuit
  • Memory 1302 may include mass storage for data or instructions.
  • memory 1302 may include a Hard Disk Drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a Universal Serial Bus (USB) drive or two or more A combination of more than one of the above.
  • Memory 1302 may include removable or non-removable (or fixed) media, where appropriate.
  • Memory 1302 may be internal or external to the data processing device, where appropriate.
  • memory 1302 is non-volatile solid state memory.
  • memory 1302 includes read only memory (ROM).
  • the ROM may be a mask programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically rewritable ROM (EAROM) or flash memory or A combination of two or more of the above.
  • PROM programmable ROM
  • EPROM erasable PROM
  • EEPROM electrically erasable PROM
  • EAROM electrically rewritable ROM
  • flash memory or A combination of two or more of the above.
  • the processor 1301 reads and executes the computer program instructions stored in the memory 1302 to implement any one of the data processing methods in the foregoing embodiments.
  • the data processing device may also include a communication interface 1303 and a bus 1310 .
  • the processor 1301 , the memory 1302 , and the communication interface 1303 are connected through the bus 1310 and complete the mutual communication.
  • the communication interface 1303 is mainly used to implement communication between modules, apparatuses, units and/or devices in the embodiments of the present application.
  • Bus 1310 includes hardware, software, or both, coupling components of the data processing device to each other.
  • bus 1310 may include an Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) interconnect, Industry Standard Architecture (ISA) ) bus, Infiniband Interconnect, Low Pin Count (LPC) bus, Memory Bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus or other suitable bus or a combination of two or more of the above.
  • Bus 1310 may include one or more buses, where appropriate. Although embodiments of this application describe and illustrate a particular bus, this application contemplates any suitable bus or interconnect.
  • the data processing device can execute the information processing method in the embodiments of the present application, thereby implementing the data processing method and apparatus described in conjunction with FIG. 5 to FIG. 12 .
  • the embodiments of the present application may be implemented by providing a computer-readable storage medium.
  • Computer program instructions are stored on the computer-readable storage medium; when the computer program instructions are executed by the processor, any one of the data processing methods in the foregoing embodiments is implemented.
  • the functional blocks shown in the above-described structural block diagrams may be implemented as hardware, software, firmware, or a combination thereof.
  • it When implemented in hardware, it may be, for example, an electronic circuit, an application specific integrated circuit (ASIC), suitable firmware, a plug-in, a function card, or the like.
  • ASIC application specific integrated circuit
  • elements of the present application are programs or code segments used to perform the required tasks.
  • the program or code segments may be stored in a machine-readable medium or transmitted over a transmission medium or communication link by a data signal carried in a carrier wave.
  • a "machine-readable medium” may include any medium that can store or transmit information.
  • machine-readable media examples include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, and the like.
  • the code segments may be downloaded via a computer network such as the Internet, an intranet, or the like.
  • processors may be, but are not limited to, general purpose processors, special purpose processors, application specific processors, or field programmable logic circuits. It will also be understood that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can also be implemented by special purpose hardware that performs the specified functions or actions, or that special purpose hardware and/or A combination of computer instructions is implemented.

Landscapes

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

Abstract

一种数据处理方法、装置、设备及介质。该数据处理方法包括：接收目标服务器发送的目标激活数据和目标激活指令（S510）；其中，目标激活数据包括待激活支付卡账号对应的待激活支付标记；响应于目标激活指令，将目标个人化数据中的目标支付标记更新为待激活支付标记（S520）；其中，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同；将更新后的目标支付标记设置为激活状态（S530）。上述方法能够解决在设置默认支付卡的过程中容易产生错误的问题。

Description

数据处理方法、装置、设备及介质
相关申请的交叉引用
本申请要求享有于2020年07月24日提交的名称为“数据处理方法、装置、设备及介质”的中国专利申请202010725073.2的优先权，该申请的全部内容通过引用并入本文中。
技术领域
本申请属于数据处理技术领域，尤其涉及一种数据处理方法、装置、设备及介质。
背景技术
随着科技的发展，近场通信(Near Field Communication，NFC)支付功能逐渐成为了电子设备的标准配置。当用户在购物消费或乘坐公共交通工具时，只需将电子设备靠近销售点(Point of Sale，POS)终端或公共交通工具的刷卡机，便可在短时间内完成支付。
目前，在用户为电子设备设置NFC功能的默认支付卡的过程中，容易产生错误，导致设置默认支付卡的成功率较低。
发明内容
本申请实施例提供一种数据处理方法、装置、设备及介质，能够解决在设置默认支付卡的过程中容易产生错误的问题。
第一方面，本申请实施例提供了一种数据处理方法，包括：
接收目标服务器发送的目标激活数据和目标激活指令；其中，目标激活数据包括待激活支付卡账号对应的待激活支付标记；
响应于目标激活指令，将目标个人化数据中的目标支付标记更新为待激活支付标记；其中，目标个人化数据所属的交易卡类型与目标激活指令 所属的交易卡类型相同；
将更新后的目标支付标记设置为激活状态。
第二方面，本申请实施例提供了一种数据处理方法，包括：
获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令；其中，待激活支付卡账号的交易卡类型与目标激活指令所属的交易卡类型相同；
根据待激活支付标记，生成目标激活数据；
向目标电子设备发送目标激活数据和目标激活指令；其中，目标激活指令用于使目标电子设备将目标个人化数据中的目标支付标记更新为待激活支付标记以及将更新后的目标支付标记设置为激活状态，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同。
第三方面，本申请实施例提供了一种数据处理装置，包括：
第一接收模块，用于接收目标服务器发送的目标激活数据和目标激活指令；其中，目标激活数据包括待激活支付卡账号对应的待激活支付标记；
第一处理模块，用于响应于目标激活指令，将目标个人化数据中的目标支付标记更新为待激活支付标记；其中，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同；
第二处理模块，用于将更新后的目标支付标记设置为激活状态。
第四方面，本申请实施例提供了一种数据处理装置，包括：
第一获取模块，用于获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令；其中，待激活支付卡账号的交易卡类型与目标激活指令所属的交易卡类型相同；
第一生成模块，用于根据待激活支付标记，生成目标激活数据；
第一发送模块，用于向目标电子设备发送目标激活数据和目标激活指令；其中，目标激活指令用于使目标电子设备将目标个人化数据中的目标支付标记更新为待激活支付标记以及将更新后的目标支付标记设置为激活状态，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同。
第五方面，本申请实施例提供了一种数据处理设备，该设备包括：处理器以及存储有计算机程序指令的存储器；
处理器执行计算机程序指令时实现如第一方面或第二方面所述的数据处理方法。
第六方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现如第一方面或第二方面所述的数据处理方法。
本申请实施例的数据处理方法、装置、设备及介质，能够在接收到目标服务器发送的待激活支付卡账号对应的待激活支付标记和目标激活指令之后，直接将所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据中的目标支付标记更新为待激活支付标记，并将更新后的目标支付标记设置为激活状态，进而可以直接利用待激活支付标记对目标个人化数据中的目标支付标记进行更新并激活更新后的目标支付标记，无需在激活待激活支付标记的过程中删除已激活的支付标记及其对应的个人化数据，从而减少激活待激活支付标记过程中的个人化数据删除、个人化数据验证及个人化数据下载的过程，避免在设置默认支付卡时因上述的过程产生错误，提高设置默认卡的成功率。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请提供的数据处理的一示例的架构图；
图2是本申请提供的数据处理的另一示例的架构图；
图3是本申请提供的数据处理的又一示例的架构图；
图4是本申请提供的数据处理的再一示例的架构图；
图5是本申请提供的数据处理方法的一实施例的流程示意图；
图6是本申请提供的数据处理方法的另一实施例的流程示意图；
图7是本申请实施例提供的绑定支付卡过程的一示例的流程示意图；
图8是本申请实施例提供的设置默认支付卡过程的一示例的流程示意图；
图9是本申请实施例提供的更改默认支付卡过程的一示例的流程示意图；
图10是本申请实施例提供的解绑支付卡过程的一示例的流程示意图；
图11是本申请提供的数据处理装置的一实施例的结构示意图；
图12是本申请提供的数据处理装置的另一实施例的结构示意图；
图13是本申请提供的数据处理设备的一实施例的硬件结构示意图。
具体实施方式
下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本申请，并不被配置为限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本申请所提供的数据处理方法，可以应用于如图1至图4的架构中，具体结合图1至图4进行详细说明。
图1示出了本申请实施例提供的数据处理的一示例的架构图。如图1所示，该架构图中可以包括至少一个电子设备110和互联网金融平台服务器120。
其中，电子设备110可以是手机、平板电脑、台式电脑、车载终端和可穿戴设备等具有通讯功能的设备，电子设备110具有NFC支付功能。可穿戴设备可以是一种可被用户穿戴在身上、或整合到用户衣服或配件中的便携式设备，如智能手环、智能手表、智能运动鞋、智能服装、智能眼镜、智能头盔、智能戒指、智能饰品等。
互联网金融平台服务器120可以用于提供互联网金融服务。具体地，互联网金融平台服务器120可以是云服务器或者服务器集群等具有存储以及计算功能的设备。
继续参见图1，每个电子设备110内可以分别安装有互联网金融平台对应的金融应用程序，并且与互联网金融平台服务器120进行通信。其中，互联网金融平台可以为第三方金融平台或者卡组织平台。
互联网金融平台服务器120可以获取与电子设备110的待激活支付卡账号关联存储的待激活支付标记(Token)以及所属的交易卡类型与激活支付卡账号的交易卡类型相同的目标激活指令，并将待激活支付标记和目标激活指令发送至目标电子设备。其中，支付卡账号可以包括实体银行卡或者电子银行卡的账号，支付标记与支付卡账号具有一一对应的关系。
电子设备110可以接收互联网金融平台服务器120发送的待激活支付卡账号对应的待激活支付标记和目标激活指令，然后将所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据中的目标支付标记更新为待激活支付标记，并且将更新后的目标支付标记设置为激活状态。
图2示出了本申请实施例提供的数据处理的另一示例的架构图。如图2所示，该架构图中可以包括至少一个电子设备110、互联网金融平台服务器120和支付标记化服务系统(Token Service Provider，TSP)平台服务器130。
其中，电子设备110和互联网金融平台服务器120的原理与图1所示 实施例相同，在此不做赘述。
TSP平台服务器130可以用于生成支付标记。具体地，TSP平台服务器130可以是云服务器或者服务器集群等具有存储以及计算功能的设备。互联网金融平台服务器120可以与TSP平台服务器130通信，以为用户获取支付卡账号对应的支付标记。
互联网金融平台服务器120可以根据需要生成支付标记的支付卡账号，生成标记生成请求，并且向TSP平台服务器130发送标记生成请求，使TSP平台服务器130生成该支付卡账号对应的支付标记，并且向互联网金融平台服务器120反馈该支付标记。
互联网金融平台服务器120在接收到TSP平台服务器130反馈的支付标记后，可以将该支付卡账号和接收到的支付标记关联存储。
图3示出了本申请提供的数据处理的又一示例的架构图。如图3所示，该架构图中可以包括至少一个电子设备110、互联网金融平台服务器120、TSP平台服务器130和可信服务管理(Trusted Service Management，TSM)平台服务器140。
其中，电子设备110、互联网金融平台服务器120和TSP平台服务器130的原理与图2所示实施例相同，在此不做赘述。
TSM平台服务器140可以用于实现信息转发，TSM平台服务器140可以是云服务器或者服务器集群等具有存储以及计算功能的设备。具体地，TSM平台服务器140可以通过可信通道与TSP平台服务器130通信连接，以提高信息传输的安全性。
互联网金融平台服务器120可以与TSM平台服务器140通信。互联网金融平台服务器120可以将标记生成请求发送至TSM平台服务器140，然后由TSM平台服务器140通过可信通道发送至TSP平台服务器130。TSP平台服务器130可以通过可信通道向TSM平台服务器140发送支付标记，使TSM平台服务器140将支付标记转发给互联网金融平台服务器120。
由此，在本申请实施例中，可以通过TSM平台服务器140和可信通道，提高互联网金融平台服务器120与TSP平台服务器130之间的通信安 全性。
图4示出了本申请提供的数据处理的再一实施例的架构图。如图4所示，该架构图中可以包括至少一个电子设备110、互联网金融平台服务器120、TSP平台服务器130、TSM平台服务器140、至少一个收单设备150和收单平台服务器160。
其中，电子设备110、互联网金融平台服务器120、TSP平台服务器130和TSM平台服务器140的原理与图3所示实施例相同，在此不做赘述。
收单设备150可以是手机、平板电脑、销售(point of sale，POS)终端等，收单设备150具有NFC信息读取功能。
收单平台服务器160可以为用于提供收单服务。具体地，收单平台服务器160可以是云服务器或者服务器集群等具有存储以及计算功能的设备。
用户首先可以登录电子设备110的金融应用程序的账户，使金融应用程序处于登录态，并在金融应用程序的应用界面内输入该账户已绑定的指定电子设备的支付状态。其中，该指定电子设备可以为用户正在操作的电子设备110，也可以为该账户已绑定的其他电子设备，只要是该账户已绑定的已通过设备验证的电子设备即可。然后，用户可以在金融应用程序的应用界面内显示的与指定电子设备绑定的多个支付卡账号中，选择需要进行状态变更的支付卡账号，使电子设备110根据该银行卡账号和指定电子设备的支付状态，生成状态变更请求。接着，电子设备110可以向该互联网金融平台对应的互联网金融平台服务器120发送该状态变更请求。
互联网金融平台服务器120在接收到该电子设备110发送的状态变更请求之后，可以对接收到的状态变更请求进行解析，得到状态变更请求中携带的支付卡账号和支付状态。然后，获取与该支付卡账号关联存储的支付标记，并且，将该支付标记对应的标记状态更新为状态变更请求中携带的支付状态。如果该支付卡账号为电子设备110的默认支付卡的账号，互联网金融平台服务器120在接收到收单设备150通过收单平台服务器160发送的携带有与该支付卡账号关联存储的支付标记的交易请求时，可以根 据该支付标记对应的标记状态确定是否执行该交易请求对应的交易。
每个收单设备150可以用于将携带有从电子设备110的安全元件(Secure Element，SE)中读取的处于激活状态的支付标记的交易请求通过收单平台服务器160发送给互联网金融平台服务器120。
具体地，收单设备150内可以安装有收单平台对应的收单应用程序。收单设备150可以通过收单应用程序读取电子设备110的SE中的支付标记，接着通过收单平台对应的收单平台服务器160向互联网金融平台服务器120发送携带有所读取的支付标记的交易请求。
互联网金融平台服务器120在接收到交易请求之后，根据交易请求中携带的支付标记对应的标记状态确定是否执行交易请求对应的交易，可以在用户无法更改指定电子设备的支付状态，通过对互联网金融平台服务器120内的与指定电子设备绑定的支付卡账号关联存储的支付标记对应的标记状态进行更改的方式，实现对指定电子设备的支付状态的变更，进而降低与目标电子设备关联的支付卡账户存在被盗刷的风险，提高用户的支付卡账户的安全性。
根据上述架构，下面结合图5至图10对本申请实施例提供的数据处理方法进行详细说明。
图5示出了本申请提供的数据处理方法的一实施例的流程示意图。
在本申请一些实施例中，图5所示的方法可以由图1至图4中所示的电子设备110中的目标电子设备执行。其中，目标电子设备可以为任意电子设备110。
如图5所示，该数据处理方法可以包括如下步骤。
S510、接收目标服务器发送的目标激活数据和目标激活指令。
其中，目标服务器可以为图1至图4中所示的互联网金融平台服务器120。
目标激活数据可以包括待激活支付卡账号对应的待激活支付标记。待激活支付卡账号可以包括待设置的默认支付卡账号和待变更的默认支付卡账号中的任一种，在此不做限制。
目标激活指令所属的交易卡类型与待激活支付卡账号的交易卡类型相 同，以使目标激活指令可以将待激活支付卡账号对应的待激活支付标记加载于所属的交易卡类型与待激活支付卡账号的交易卡类型相同的目标个人化数据中。
S520、响应于目标激活指令，将目标个人化数据中的目标支付标记更新为待激活支付标记。
目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同，由此，可以保证将待激活支付卡账号对应的待激活支付标记加载于所属的交易卡类型与待激活支付卡账号的交易卡类型相同的目标个人化数据中，避免待激活支付标记的激活过程出现错误。
个人化数据可以为个人化应用标示符(application identifier，AID)，其由字符串构成，个人化AID内包含有通用字符串、支付标记和状态值，支付标记也由字符串构成，支付标记和状态值可以位于通用字符串之后。
例如，个人化AID的通用字符串可以为：A000000333 010102 00 63020000 01 0000。其中，前10位可以为固定字符串，第11-16位可以用于指示账户类型，如借记类型为010101、贷记类型为010102、准贷记类型为010103，第17-18位可以指示应用类型，如金融应用为00、非金融应用为01，第19-26位可以为应用提供方的机构代码，第27-28位可以为扩展为，可以自定义其功能，第29-32位可以指示芯片卡类型，如PBOC2.0类型为0000，PBOC3.0类型为1000。
在本申请一些实施例中，在待激活支付卡账号为待设置的默认支付卡账号的情况下，目标个人化数据中的目标支付标记可以为初始化标记。目标电子设备可以响应于目标激活指令，利用待激活支付标记替换该初始化标记。
在本申请一些实施例中，目标激活指令可以为应用协议数据单元(Application Protocol Data Unit，APDU)指令，如：Install for install命令，具体地可以参见GP Amendment C中的参数定义。
目标电子设备可以安装有目标个人化数据对应的目标个人化数据激活程序，并通过目标个人化数据激活程序执行目标激活指令对应的目标加载操作，即通过目标个人化数据激活程序将目标个人化数据中的目标支付标 记更新为待激活支付标记。
S530、将更新后的目标支付标记设置为激活状态。
目标电子设备可以通过目标个人化数据激活程序执行目标激活指令对应的目标激活操作，即通过目标个人化数据激活程序激活目标个人化数据，进而实现对目标支付标记的激活。
在本申请实施例中，能够在接收到目标服务器发送的待激活支付卡账号对应的待激活支付标记和目标激活指令之后，直接将所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据中的目标支付标记更新为待激活支付标记，并将更新后的目标支付标记设置为激活状态，进而可以直接利用待激活支付标记对目标个人化数据中的目标支付标记进行更新并激活更新后的目标支付标记，无需在激活待激活支付标记的过程中删除已激活的支付标记及其对应的个人化数据，从而减少激活待激活支付标记过程中的个人化数据删除、个人化数据验证及个人化数据下载的过程，避免在设置默认支付卡时因上述的过程产生错误，提高设置默认卡的成功率。
在本申请一些实施方式中，在待激活支付卡账号为待设置的默认支付卡账号的情况下，在S510之前，该数据处理方法还可以包括：
接收待设置的默认支付卡账号；
根据待设置的默认支付卡账号，生成默认卡设置请求；
向目标服务器发送默认卡设置请求；其中，默认卡设置请求用于使目标服务器反馈待设置的默认支付卡账号对应的目标激活数据和目标激活指令。
具体地，用户可以在目标电子设备的金融应用程序的应用界面内显示的与目标电子设备绑定的至少一个支付卡账号中，选择任一个支付卡账号作为待设置的默认支付卡账号。电子设备可以根据待设置的默认支付卡账号和目标电子设备标识，生成默认卡设置请求，然后向互联网金融平台服务器发送默认卡设置请求，使互联网金融平台服务器反馈待设置的默认支付卡账号对应的目标激活数据和目标激活指令。其中，互联网金融平台服务器反馈目标激活数据和目标激活指令的方法将在后文详细说明。
在本申请一些实施例中，目标电子设备标识可以为目标电子设备的网际互连协议(Internet Protocol，IP)地址。在另一些实施例中，目标电子设备标识也可以为目标电子设备的设备身份识别码(Identity document，ID)。
在本申请一些实施例中，在待激活支付卡账号为待设置的默认支付卡账号的情况下，由于此前目标电子设备中未激活其他的支付标记，因此，目标个人化数据可以为目标电子设备的目标安全元件中所存储的支付标记处于非激活状态的个人化数据。
在一些实施例中，在接收目标服务器发送的目标激活数据和目标激活指令时，在目标电子设备的目标安全元件中已存储有目标个人化数据的情况下，目标电子设备可以直接执行S520。
在另一些实施例中，在接收目标服务器发送的目标激活数据和目标激活指令时，在目标电子设备的目标安全元件中未存储有目标个人化数据的情况下，目标电子设备所接收的目标激活数据还包括可以目标个人化数据。可选地，在S520之前，该数据处理方法还可以包括：
将目标个人化数据存储于目标安全元件中。
因此，可以在目标电子设备的目标安全元件中未存储有目标个人化数据的情况下，先在目标安全元件中加载目标个人化数据，以保证激活待激活支付卡账号对应的待激活支付标记的可靠性。
在本申请一些实施方式中，在待激活支付卡账号为待变更的默认支付卡账号的情况下，在S510之前，该数据处理方法还可以包括：
接收待变更的默认支付卡账号；
根据待变更的默认支付卡账号，生成默认卡变更请求；
向目标服务器发送默认卡变更请求；其中，默认卡变更请求用于使目标服务器反馈待变更的默认支付卡账号对应的目标激活数据和目标激活指令。
具体地，用户可以在目标电子设备的金融应用程序的应用界面内显示的与目标电子设备绑定的至少一个支付卡账号中，选择已被设置为默认支付卡的支付卡账号以外的任一个支付卡账号作为待变更的默认支付卡账 号。目标电子设备可以根据待变更的默认支付卡账号和目标电子设备标识，生成默认卡变更请求，然后向互联网金融平台服务器发送默认卡变更请求，使互联网金融平台服务器反馈待变更的默认支付卡账号对应的目标激活数据和目标激活指令。其中，互联网金融平台服务器反馈目标激活数据和目标激活指令的方法将在后文详细说明。
在本申请一些实施例中，在待激活支付卡账号为待变更的默认支付卡账号的情况下，此前目标电子设备中已激活其他的支付标记。因此，在一些实施例中，目标个人化数据可以为目标安全元件中所存储的支付标记处于激活状态的个人化数据。在另一些实施例中，目标个人化数据还可以为目标安全元件中所存储的支付标记处于非激活状态的个人化数据，在此不做限制。
在一些实施例中，在接收目标服务器发送的目标激活数据和目标激活指令时，在目标电子设备的目标安全元件中已存储有目标个人化数据的情况下，目标电子设备可以直接执行S520。
在另一些实施例中，在接收目标服务器发送的目标激活数据和目标激活指令时，在目标电子设备的目标安全元件中未存储有目标个人化数据的情况下，目标电子设备所接收的目标激活数据还包括可以目标个人化数据。可选地，在S520之前，该数据处理方法还可以包括：
将目标个人化数据存储于目标安全元件中。
因此，可以在目标电子设备的目标安全元件中未存储有目标个人化数据的情况下，先在目标安全元件中加载目标个人化数据，以保证激活待激活支付卡账号对应的待激活支付标记的可靠性。
在本申请一些实施例中，在目标个人化数据为目标安全元件中所存储的支付标记处于非激活状态的个人化数据的情况下，在S530之后，该数据处理方法还可以包括：
将更新后的目标支付标记以外的激活支付标记设置为非激活状态。
由于此前目标电子设备中已激活其他的支付标记，为避免收单设备读取目标电子设备的目标安全元件中的目标支付标记时发生错误，还需要将更新后的目标支付标记以外的激活支付标记，即原处于激活状态的支付标 记设置为非激活状态。
在本申请实施例中，目标电子设备可以通过目标个人化数据激活程序执行目标激活指令对应的目标还原操作，即通过目标个人化数据激活程序将原处于激活状态的支付标记的个人化数据设置为非激活状态，进而取消对原处于激活状态的支付标记的激活，保证目标电子设备的目标安全元件中仅有一个支付标记处于激活状态。
图6示出了本申请提供的数据处理方法的另一实施例的流程示意图。
在本申请一些实施例中，图6所示的方法可以由图1至图4中所示的互联网金融平台服务器120执行。
如图6所示，该数据处理方法可以包括如下步骤。
S610、获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令。
待激活支付卡账号的交易卡类型与目标激活指令所属的交易卡类型相同。
具体地，互联网金融平台服务器可以在本地存储的支付标记中获取与待激活支付卡账号关联存储的待激活支付标记，并且在本地存储的激活指令中，获取所属的交易卡类型与待激活支付卡账号的交易卡类型相同的目标激活指令。
S620、根据待激活支付标记，生成目标激活数据。
在本申请一些实施例中，可以将待激活支付标记加载于目标激活数据对应的数据包中，以生成目标激活数据。
S630、向目标电子设备发送目标激活数据和目标激活指令。
目标激活指令用于使目标电子设备将目标个人化数据中的目标支付标记更新为待激活支付标记以及将更新后的目标支付标记设置为激活状态，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同。目标电子设备激活待激活支付标记的方法已在图5所示的方法实施例中详细说明，在此不做赘述。
在本申请实施例中，能够在获取到与待激活支付卡账号关联存储的待激活支付标记和所属的交易卡类型与待激活支付卡账号的交易卡类型相同 的目标激活指令之后，根据待激活支付标记，生成目标激活数据，并向目标电子设备发送目标激活数据和目标激活指令，使目标电子设备将所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据中的目标支付标记更新为待激活支付标记，以及将更新后的目标支付标记设置为激活状态，进而可以直接利用待激活支付标记对目标个人化数据中的目标支付标记进行更新并激活更新后的目标支付标记，无需在激活待激活支付标记的过程中删除已激活的支付标记及其对应的个人化数据，从而减少激活待激活支付标记过程中的个人化数据删除、个人化数据验证及个人化数据下载的过程，避免在设置默认支付卡时因上述的过程产生错误，提高设置默认卡的成功率。
在本申请另一个实施方式中，为了避免因目标电子设备的目标安全元件中未存储有目标个人化数据而导致待激活支付标记激活失败，在S620之前，该数据处理方法还可以包括：
获取目标个人化数据。
相应地，S620可以具体包括：
根据待激活支付标记和目标个人化数据，生成目标激活数据。
由此，互联网金融平台服务器可以在本地存储的个人化数据中获取所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据，并且将目标个人化数据与待激活支付标记一同加载于目标激活数据对应的数据包中，以生成目标激活数据。
在本申请一些实施例中，为了进一步提高目标电子设备激活待激活支付标记的可靠性，在获取目标个人化数据之前，该数据处理方法还可以包括：
向目标电子设备发送数据查询请求；其中，数据查询请求用于查询目标电子设备的目标安全元件中的目标个人化数据；
接收目标电子设备反馈的数据查询结果。
相应地，获取目标个人化数据可以具体包括：
在数据查询结果为在目标安全元件中未查询到目标个人化数据的情况下，获取目标个人化数据。
具体地，互联网金融平台服务器在向目标电子设备发送目标激活数据和目标激活指令之前，需要先向目标电子设备发送数据查询请求，以查询目标电子设备的目标安全元件中是否已经存储有目标个人化数据。目标电子设备在接收到数据查询请求之后，可以查询目标安全元件中是否存储有目标个人化数据，并将数据查询结果反馈给互联网金融平台服务器。互联网金融平台服务器可以接收目标电子设备反馈的数据查询结果，如果数据查询结果为在目标安全元件中查询到目标个人化数据，可以直接根据待激活支付标记，生成目标激活数据；如果数据查询结果为在目标安全元件中未查询到目标个人化数据，可以获取目标个人化数据，并且根据待激活支付标记和目标个人化数据，生成目标激活数据。
由此，在本申请实施例中，可以首先判断目标电子设备的目标安全元件中是否存储有激活待激活支付标记所需的目标个人化数据，进而根据判断结果确定是否向目标电子设备发送目标个人化数据，以使目标电子设备能够可靠地实现对待激活支付标记的激活。
在本申请实施例中，待激活支付标记所需的目标个人化数据可以为所属的交易卡类型与目标激活指令所属的交易卡类型相同的个人化数据。一种支付卡类型可以对应一套个人化数据。
例如，贷记卡类型可以对应一套个人化数据，借记卡类型可以对应一套个人化数据。
一种支付卡类型可以对应一套通用的个人化数据，可以消除各个支付卡发行方之间的个人化数据的差异，提高了设备卡和行业机之间兼容性。
在本申请一个实施方式中，待激活支付卡账号可以包括待设置的默认支付卡账号。
相应地，在S610之前，该数据处理方法还可以包括：
接收目标电子设备发送的默认卡设置请求；
响应于默认卡设置请求，对默认卡设置请求进行解析，得到默认卡设置请求信息；其中，默认卡设置请求信息包括待设置的默认支付卡账号。
互联网金融平台服务器在接收到默认卡设置请求后，可以响应于默认卡设置请求，对默认卡设置请求进行解析，得到待设置的默认支付卡账号 和目标电子设备的目标电子设备标识，然后查询与待设置的默认支付卡账号关联存储的支付标记，作为待激活支付标记。
由此，互联网金融平台服务器可以在用户具有对目标电子设备的默认卡设置需求的情况下，为目标电子设备发送待设置的默认支付卡账号对应的目标激活数据和目标激活指令。
在本申请一些实施例中，在待激活支付卡账号为待设置的默认支付卡账号的情况下，在S630之后，该数据处理方法还可以包括：
接收目标电子设备发送的激活结果；其中，激活结果用于指示目标电子设备已将待激活支付标记设置为激活状态；
响应于激活结果，将待激活支付卡账号对应的支付卡属性设置为目标属性；其中，目标属性为目标电子设备的默认支付卡；
将待激活支付标记对应的标记状态设置为激活状态；
建立待激活支付标记与目标电子设备之间的关联关系。
具体地，目标电子设备在执行目标激活指令之后，会向互联网金融平台服务器反馈激活结果。其中，激活结果可以用于指示目标电子设备已将待激活支付标记设置为激活状态，或者可以用于指示目标电子设备对待激活支付标记设置激活失败。
互联网金融平台服务器可以在向目标电子设备发送目标激活数据和目标激活指令之后，接收目标电子设备发送的激活结果，并且在激活结果为用于指示目标电子设备已将待激活支付标记设置为激活状态的激活结果的情况下，将待激活支付卡账号对应的支付卡属性设置为目标电子设备的默认支付卡，并且将待激活支付标记对应的标记状态设置为激活状态，同时建立待激活支付标记与目标电子设备的目标电子设备标识之间的关联关系，使目标电子设备的NFC支付功能处于可用状态。
然后，互联网金融平台服务器可以向目标电子设备反馈第一提示信息。其中，第一提示信息用于提示用户目标电子设备的默认支付卡设置成功，可以通过默认支付卡正常使用NFC支付功能。
在本申请实施例中，所绑定的支付卡账号与目标电子设备中的个人化数据属于松耦合关系，即动态映射关系，可以通过建立待激活支付标记与 目标电子设备之间的关联关系，来实现对默认支付卡账号与目标电子设备之间的映射关系的建立。
在本申请另一些实施方式中，待激活支付卡账号还可以包括待变更的默认支付卡账号。
相应地，在S610之前，该数据处理方法还可以包括：
接收目标电子设备发送的默认卡变更请求；
响应于默认卡变更请求，对默认卡变更请求进行解析，得到默认卡变更请求信息；其中，默认卡变更请求信息包括待变更的默认支付卡账号。
互联网金融平台服务器在接收到默认卡变更请求后，可以响应于默认卡变更请求，对默认卡变更请求进行解析，得到待变更的默认支付卡账号和目标电子设备的目标电子设备标识，然后查询与待变更的默认支付卡账号关联存储的支付标记，作为待激活支付标记。
由此，互联网金融平台服务器可以在用户具有对目标电子设备的默认卡变更需求的情况下，为目标电子设备发送待变更的默认支付卡账号对应的目标激活数据和目标激活指令。
在本申请一些实施例中，在待激活支付卡账号为待变更的默认支付卡账号的情况下，在上述的向目标电子设备发送数据查询请求之前，该数据处理方法还可以包括：
获取目标支付卡账号；其中，目标支付卡账号对应的支付卡属性为目标属性，目标属性为目标电子设备的默认支付卡。
相应地，向目标电子设备发送数据查询请求可以具体包括：
在目标支付卡账号的支付卡类型与待变更的默认支付卡账号的支付卡类型不相同的情况下，向目标电子设备发送数据查询请求。
互联网金融平台服务器可以在向目标电子设备发送数据查询请求之前，查询当前的支付卡属性为目标电子设备的默认支付卡的目标支付卡账号，即原默认支付卡账号。然后，对目标支付卡账号的支付卡类型和待变更的默认支付卡账号的支付卡类型进行比较。最后，若比较结果为目标支付卡账号的支付卡类型与待变更的默认支付卡账号的支付卡类型相同，则说明目标电子设备的目标安全元件中存储有目标个人化数据，可以直接根 据待激活支付标记，生成目标激活数据。若比较结果为目标支付卡账号的支付卡类型与待变更的默认支付卡账号的支付卡类型不同，则说明目标电子设备的目标安全元件中未存储有目标个人化数据，需要向目标电子设备发送目标个人化数据，因此，可以获取目标个人化数据，并且根据待激活支付标记和目标个人化数据，生成目标激活数据。
在本申请另一些实施例中，在待激活支付卡账号为待变更的默认支付卡账号的情况下，在S630之后，该数据处理方法还可以包括：
接收目标电子设备发送的激活结果；其中，激活结果用于指示目标电子设备已将待激活支付标记设置为激活状态；
响应于激活结果，将待激活支付卡账号对应的支付卡属性设置为目标属性，并且将目标支付卡账号对应的支付卡属性为非目标属性；
将待激活支付标记对应的标记状态设置为激活状态，并且将与目标支付卡账号关联存储的目标支付标记对应的标记状态设置为非激活状态；
建立待激活支付标记与目标电子设备之间的关联关系，并且删除目标支付标记与目标电子设备之间的关联关系。
具体地，目标电子设备在执行目标激活指令之后，会向互联网金融平台服务器反馈激活结果。其中，激活结果可以用于指示目标电子设备已将待激活支付标记设置为激活状态，或者可以用于指示目标电子设备对待激活支付标记设置激活失败。
互联网金融平台服务器可以在向目标电子设备发送目标激活数据和目标激活指令之后，接收目标电子设备发送的激活结果，并且在激活结果为用于指示目标电子设备已将待激活支付标记设置为激活状态的激活结果的情况下，首先，可以将待激活支付卡账号对应的支付卡属性设置为目标电子设备的默认支付卡，并且将原默认支付卡账号对应的支付卡属性为非目标属性，然后，可以将待激活支付标记对应的标记状态设置为激活状态，并且将与原默认支付卡账号关联存储的原目标支付标记对应的标记状态设置为非激活状态，最后，建立待激活支付标记与目标电子设备的目标电子设备标识之间的关联关系，使待激活支付标记作为新的目标支付标记，并且删除原目标支付标记与目标电子设备的目标电子设备标识之间的关联关 系。
在本申请一些实施例中，互联网金融平台服务器可以向目标电子设备反馈第二提示信息。其中，第二提示信息用于提示用户目标电子设备的默认支付卡变更成功，可以通过新的默认支付卡正常使用NFC支付功能。
由此，在本申请实施例中，可以通过建立待激活支付标记与目标电子设备之间的关联关系以及删除原目标支付标记与目标电子设备之间的关联关系，来实现对默认支付卡账号与目标电子设备之间的映射关系的变更。
在本申请再一些实施方式中，在S610之前，该数据处理方法还可以包括：
接收目标电子设备发送的支付卡绑定请求；
响应于支付卡绑定请求，对支付卡绑定请求进行解析，得到支付卡绑定请求信息；其中，支付卡绑定请求信息包括待绑定支付卡账号；
根据待绑定支付卡账号，生成标记生成请求；
向支付标记管理服务器发送标记生成请求；其中，标记生成请求用于使支付标记管理服务器生成待绑定支付卡账号对应的支付标记；
接收支付标记管理服务器反馈的待绑定支付卡账号对应的支付标记；
将待绑定支付卡账号和待绑定支付卡账号对应的支付标记关联存储。
用户首先可以登录目标电子设备的金融应用程序的账户，使金融应用程序处于登录态，并在金融应用程序的应用界面内选择该账户已绑定的目标电子设备，即用户正在操作的电子设备。然后，用户可以在金融应用程序的应用界面内添加为目标电子设备绑定的支付卡账号，作为待绑定支付卡账号，使目标电子设备根据待绑定支付卡账号，生成支付卡绑定请求。接着，目标电子设备可以向互联网金融平台服务器发送该支付卡绑定请求。
互联网金融平台服务器在接收到支付卡绑定请求之后，可以解析支付卡绑定请求，得到待绑定支付卡账号和目标电子设备的目标电子设备标识。根据待绑定支付卡账号，生成标记生成请求，并且向支付标记管理服务器发送该标记生成请求。
在一些实施例中，支付标记管理服务器可以为图2至图4中所示的 TSP平台服务器130，TSP平台服务器在接收到标记生成请求之后，可以对标记生成请求进行解析，得到待绑定支付卡账号，然后生成待绑定支付卡账号对应的支付标记，并且将待绑定支付卡账号和待绑定支付卡账号对应的支付标记关联存储。将待绑定支付卡账号对应的支付标记反馈给互联网金融平台服务器。
互联网金融平台服务器可以接收TSP平台服务器反馈的待绑定支付卡账号对应的支付标记，然后将将待绑定支付卡账号和待绑定支付卡账号对应的支付标记关联存储，以在用户基于已绑定的支付卡账号为目标电子设备设置或者变更默认支付卡账号时，可以将默认支付卡账号对应的支付标记发送给目标电子设备。
进一步地，互联网金融平台服务器还可以在将目标支付卡账号与目标电子设备绑定之后，向目标电子设备发送第三提示信息。其中，第三提示信息用于提示用户待绑定支付卡账号与目标电子设备绑定成功。
在本申请实施例中，TSP平台服务器可以利用预先设置的标记生成方式，生成待绑定支付卡账号对应的支付标记。
例如，标记生成方式可以为利用预设的加密算法对待绑定支付卡账号的全部数字进行加密，得到加密后的加密字符串，将加密字符串作为待绑定支付卡账号对应的支付标记。再例如，标记生成方式可以为利用预设的加密算法对待绑定支付卡账号的部分数字进行加密，得到加密后的加密字符串，将待绑定支付卡账号的未加密数字和加密字符串进行拼接，得到待绑定支付卡账号对应的支付标记。
在本申请一些实施例中，互联网金融平台服务器可以通过TSM平台服务器与TSP平台服务器进行通信，以提高数据安全性。
在本申请再一个实施方式中，该数据处理方法还可以包括：
接收状态变更请求；
响应于状态变更请求，对状态变更请求进行解析，得到状态变更请求信息；其中，状态变更请求信息包括待变更状态的支付卡账号和目标电子设备的目标支付状态；
获取与待变更状态的支付卡账号关联存储的待变更状态的支付标记；
将待变更状态的支付标记对应的标记状态更新为目标支付状态。
在本申请一些实施例中，状态变更请求用于请求互联网金融平台服务器将与用户指定的待变更状态的支付卡账号关联存储的待变更状态的支付标记对应的标记状态更新为用户指定的目标电子设备的目标支付状态。状态变更请求可以为目标电子设备发送的状态变更请求，也可以为目标电子设备以外的其它电子设备发送的状态变更请求，只要是电子设备安装有互联网金融平台对应的金融应用程序并且金融应用程序所登录的账号绑定有要变更NFC支付功能的支付状态的目标电子设备即可。
具体地，用户首先可以登录电子设备的金融应用程序的账户，使金融应用程序处于登录态，并在金融应用程序的应用界面内选择该账户已绑定的目标电子设备。然后，用户可以在金融应用程序的应用界面内输入待变更状态的支付卡账号和目标电子设备的目标支付状态，目标支付状态可以为用户想要更改的目标电子设备的支付状态。用户操作的电子设备可以根据待变更状态的支付卡账号和目标支付状态生成状态变更请求，并且将状态变更请求发送给互联网金融平台服务器。
在本申请实施例中，目标支付状态可以包括激活状态、挂失状态和解绑状态中的任一种。目标支付状态可以分为正常状态和异常状态，异常状态可以包括挂失状态和解绑状态中的任一种，正常状态可以包括激活状态。
激活状态指的是电子设备的NFC支付功能已激活并且处于可用状态。挂失状态指的是电子设备的NFC支付功能已激活并且处于挂失登记状态，在挂失状态下，NFC支付功能暂停使用。解绑状态指的是电子设备的NFC支付功能已激活并且处于未绑定支付卡账号状态，在解绑状态下，NFC支付功能也暂停使用。
在本申请实施例中，目标电子设备或者其它电子设备可以直接与互联网金融平台服务器通信。
在本申请一些实施例中，状态变更请求信息还可以包括目标电子设备标识。
即用户操作的电子设备在接收到用户输入的待变更状态的支付卡账号 和目标电子设备的目标支付状态之后，还可以获取目标电子设备对应的目标电子设备标识，进而可以基于目标电子设备标识、待变更状态的支付卡账号和目标支付状态生成状态变更请求。
在本申请一些实施例中，互联网金融平台服务器可以存储支付标记对应的标记状态。例如，互联网金融平台服务器可以为支付标记增加状态位，状态位上设有状态值，一个状态值对应一个标记状态，并且不同的状态值对应不同的标记状态。同时，标记状态与支付状态相同。
在这些实施例中，由于标记状态与支付状态相同，可选地，互联网金融平台服务器可以确定与目标支付状态相同的标记状态对应的目标状态值，并且将待变更状态的支付标记状态位设置为该目标状态值，以实现将待变更状态的支付标记对应的标记状态更新为目标支付状态。
在本申请实施例中，由于一个电子设备存储有一个处于激活状态的支付标记，并且每个支付标记对应的标记状态与支付状态相同，因此，互联网金融平台服务器可以根据支付标记对应的标记状态，确定支付标记对应的电子设备的支付状态，进而可以根据电子设备的支付状态确定是否执行携带有该支付标记的交易请求对应的交易。
由此，能够通过目标支付标记对应的目标标记状态对目标电子设备的目标支付状态进行更新，无需删除目标电子设备中的目标支付标记，仅需要将互联网金融平台服务器中的目标支付标记的目标标记状态进行更新，即可以避免在目标电子设备丢失后，用户无法更改目标电子设备的支付状态的问题，进而降低与目标电子设备关联的银行账户存在被盗刷的风险，提高用户的银行账户的安全性。
在本申请实施例中，无论待变更状态的支付卡账号对应的支付卡属性为目标电子设备的非默认支付卡还是目标电子设备的默认支付卡，均可以直接将待变更状态的支付标记对应的标记状态更新为目标支付状态，然后向目标电子设备反馈第四提示信息。其中，第四提示信息用于提示用户与目标电子设备绑定的待变更状态的支付卡账号的支付状态已变更为目标支付状态。
在本申请一些实施例中，该信息处理方法还可以包括：
接收目标收单设备发送的交易请求；
响应于交易请求，对交易请求进行解析，得到交易请求信息；其中，交易请求信息包括目标支付标记；
查询目标支付标记对应的标记状态；
在目标支付标记对应的标记状态为异常状态的情况下，拒绝执行交易请求对应的交易；
其中，异常状态包括挂失状态和解绑状态中的任一种。
具体地，用户在使用目标电子设备进行支付时，商户可以通过目标收单设备读取目标电子设备的目标安全元件中存储的处于激活状态的支付标记，即目标支付标记，目标收单设备可以根据目标支付标记、目标收单设备的目标收单设备标识和交易金额生成交易请求，然后将交易请求发送给互联网金融平台服务器。
目标收单设备标识可以为目标收单设备标识的IP地址，也可以为目标收单设备标识的设备ID。
互联网金融平台服务器可以接收目标收单设备发送的交易请求，并且对交易请求进行解析，得到目标支付标记、目标收单设备标识和交易金额，然后查询目标支付标记对应的标记状态。互联网金融平台服务器可以在目标支付标记对应的标记状态为异常状态的情况下，拒绝执行交易请求对应的交易；在目标支付标记对应的标记状态为正常状态的情况下，查询与目标支付标记关联存储的目标交易卡账号，将目标交易卡账号、目标收单设备标识和交易金额发送给发卡机构服务器，使发卡机构服务器完成交易请求对应的交易，实现将交易金额由目标交易卡账号转移至目标收单设备标识对应的交易卡账号中，然后将交易完成结果反馈给互联网金融平台服务器。互联网金融平台服务器在接收到交易完成结果后，可以将交易完成结果转发给目标收单设备。
在本申请实施例中，目标收单设备可以直接与互联网金融平台服务器通信，目标收单设备还可以通过收单平台服务器与互联网金融平台服务器通信，在此不做限制。
由此，用户可以在目标电子设备丢失后，无需删除目标电子设备的目 标安全元件中所存储的个人化数据或者支付标记，仅需将目标电子设备的支付状态更改为异常状态，使目标电子设备对应的支付标记的标记状态更改为异常状态，便可以在该目标电子设备再次被用于支付时，由互联网金融平台服务器拒绝执行交易，避免与目标电子设备关联的银行账户存在被盗刷，提高用户的银行账户的安全性。
在本申请另一些实施例中，为了进一步降低与目标电子设备关联的支付卡账户存在被盗刷的风险，在目标支付状态包括挂失状态和解绑状态中的任一种的情况下，在得到状态变更请求信息之后，该信息处理方法可以还可以包括：
在待变更状态的支付卡账号对应的支付卡属性为目标属性的情况下，删除待变更状态的支付卡账号与目标电子设备之间的关联关系。
其中，目标属性为目标电子设备的默认支付卡。
具体地，互联网金融平台服务器可以通过确定支付标记与目标电子设备之间是否存在关联关系，进而确定与支付标记关联存储的支付卡账号对应的支付卡属性，若支付标记与目标电子设备之间存在关联关系，则与支付标记关联存储的支付卡账号对应的支付卡属性为目标电子设备的默认支付卡，否则与支付标记关联存储的支付卡账号对应的支付卡属性为目标电子设备的非默认支付卡。
由于仅在与支付标记关联存储的支付卡账号对应的支付卡属性为目标电子设备的默认支付卡的情况下，目标电子设备的目标安全元件中才会存储有该支付标记，因此，在待变更状态的支付卡账号对应的支付卡属性为目标电子设备的非默认支付卡的情况下，仅需要待变更状态的支付标记对应的标记状态更新为目标支付状态即可。而在待变更状态的支付卡账号对应的支付卡属性为目标电子设备的默认支付卡的情况下，由于目标电子设备的目标安全元件中存储有待变更状态的支付标记，为了避免互联网金融平台服务器出现校验失误，还可以进一步删除待变更状态的支付卡账号与目标电子设备之间的关联关系，以在接收到待变更状态的支付标记对应的交易请求时并确定目标支付状态为正常状态之后，进一步确定待变更状态的支付标记与目标电子设备之间是否存在关联关系，进而确定是否执行交 易请求对应的交易。
具体地，若待变更状态的支付标记与目标电子设备之间存在关联关系，则执行交易请求对应的交易；若待变更状态的支付标记与目标电子设备之间不存在关联关系，则不执行交易请求对应的交易。
由此，在本申请实施例中，可以进一步提高与目标电子设备关联的银行账户的安全性。
在本申请又一些实施例中，在拒绝执行交易请求对应的交易之后，该信息处理方法还可以包括：
根据目标支付标记对应的标记状态，生成交易请求对应的交易反馈信息；
向目标收单设备发送交易反馈信息。
具体地，互联网金融平台服务器可以生成交易请求对应的交易反馈信息，使交易反馈信息内携带有目标支付标记对应的标记状态，然后向目标收单设备发送交易反馈信息。当目标收单设备接收到交易反馈信息后，可以显示交易反馈信息所携带的目标支付标记对应的标记状态，以向交易相关人员(收款方或付款方)展示目标电子设备的目标支付状态，告知交易相关人员拒绝交易的原因。
下面，将以图7至图10为例，对本申请实施例提供的数据处理的各个过程进行详细说明。
图7示出了本申请实施例提供的绑定支付卡过程的一示例的流程示意图。如图7所示，该绑定支付卡过程可以包括：
S701、用户打开目标电子设备的金融应用程序的应用界面，在金融应用程序的应用界面内登陆账户，并且选择要为目标电子设备绑定的支付卡类型，使目标电子设备接收用户输入的支付卡类型；
S702、用户在金融应用程序的应用界面输入要为目标电子设备绑定的支付卡账号，使目标电子设备接收用户输入的支付卡账号；
S703、目标电子设备对支付卡类型进行判断，若支付卡类型为借记卡类型，则执行S704，若支付卡类型为贷记卡类型，则执行S705；
S704、目标电子设备显示借记卡验证页面，使用户核对支付卡账号对 应的支付卡信息，并输入取款密码以及金融应用程序的互联网金融平台服务器在确认取款密码正确的情况下发送的验证码，使目标电子设备接收用户输入的验证码，然后执行S706；
S705、目标电子设备显示贷记卡验证页面，使用户核对支付卡账号对应的支付卡信息，并接收输入的贷记卡CVN2码、贷记卡有效期以及金融应用程序的互联网金融平台服务器在确认贷记卡CVN2码和贷记卡有效期正确的情况下发送的验证码，使目标电子设备接收用户输入的验证码，然后执行S706；
S706、目标电子设备根据验证码、支付卡账号和目标电子设备的目标电子设备标识，生成支付卡绑定请求；
S707、目标电子设备向互联网金融平台服务器发送支付卡绑定请求；
S708、互联网金融平台服务器响应于支付卡绑定请求，对支付卡绑定请求进行解析，得到验证码、支付卡账号和目标电子设备的目标电子设备标识，在对验证码验证成功的情况下，根据支付卡账号，生成标记生成请求；
S709、互联网金融平台服务器向TSP平台服务器发送标记生成请求；
S710、TSP平台服务器响应于标记生成请求，生成支付卡账号对应的支付标记，并将支付卡账号与支付标记关联存储；
S711、TSP平台服务器向互联网金融平台服务器发送支付卡账号对应的支付标记；
S712、互联网金融平台服务器将支付卡账号和支付标记关联存储；
S713、互联网金融平台服务器向目标电子设备发送第三提示信息；
S714、目标电子设备显示第三提示信息，以提示用户支付卡账号与目标电子设备绑定成功。
图8示出了本申请实施例提供的设置默认支付卡过程的一示例的流程示意图。如图8所示，该设置默认支付卡过程可以包括：
S801、用户打开目标电子设备的金融应用程序的应用界面，在金融应用程序的应用界面内登陆账户，并且在与目标电子设备绑定的至少一个支付卡账号中，选择要设置为目标电子设备的默认支付卡的支付卡账号，使 目标电子设备接收用户输入的待设置的支付卡账号；
S802、目标电子设备根据该支付卡账号和目标电子设备的目标电子设备标识，生成默认卡设置请求；
S803、目标电子设备向互联网金融平台服务器发送默认卡设置请求；
S804、互联网金融平台服务器响应于默认卡设置请求，对默认卡设置请求进行解析，得到该支付卡账号和目标电子设备标识；
S805、互联网金融平台服务器查询与该支付卡账号关联存储的支付标记，然后向目标电子设备发送数据查询请求；
S806、目标电子设备在接收到数据查询请求之后，可以查询目标安全元件中是否存储有该支付标记对应的个人化数据，并将数据查询结果反馈给互联网金融平台服务器；
S807、互联网金融平台服务器可以对数据查询结果进行判断，若数据查询结果为在目标安全元件中查询到该支付标记对应的个人化数据，则执行S808，若数据查询结果为在目标安全元件中未查询到该支付标记对应的个人化数据，则执行S809；
S808、互联网金融平台服务器向目标电子设备发送该支付标记和该支付标记对应的激活指令，然后执行S810；
S809、互联网金融平台服务器向目标电子设备发送该支付标记、该支付标记对应的激活指令和该支付标记对应的个人化数据，然后执行S810；
S810、目标电子设备将该支付标记加载于该支付标记对应的个人化数据中并且将该支付标记激活为激活状态；
S811、目标电子设备向互联网金融平台服务器发送用于指示目标电子设备已将该支付标记设置为激活状态的激活结果；
S812、互联网金融平台服务器向将该支付标记对应的标记状态设置为激活状态，然后，将与该支付标记关联存储的支付卡账号对应的支付卡属性设置为目标电子设备的默认支付卡，并且建立该支付标记与目标电子设备之间的关联关系；
S813、互联网金融平台服务器向目标电子设备反馈第一提示信息；
S814、目标电子设备显示第一示信息，以提示用户目标电子设备的默 认支付卡设置成功。
图9示出了本申请实施例提供的更改默认支付卡过程的一示例的流程示意图。如图9所示，该更改默认支付卡过程可以包括：
S901、用户打开目标电子设备的金融应用程序的应用界面，在金融应用程序的应用界面内登陆账户，并且在与目标电子设备绑定的至少一个支付卡账号中，选择要更换为目标电子设备的新的默认支付卡的支付卡账号，使目标电子设备接收用户输入的待变更的支付卡账号；
S902、目标电子设备根据该支付卡账号和目标电子设备的目标电子设备标识，生成默认卡变更请求；
S903、目标电子设备向互联网金融平台服务器发送默认卡变更请求；
S904、互联网金融平台服务器响应于默认卡变更请求，对默认卡变更请求进行解析，得到该支付卡账号和目标电子设备标识；
S905、互联网金融平台服务器查询与该支付卡账号关联存储的支付标记和当前与该目标电子设备标识具有关联关系的支付标记，并查询与查询到的支付标记关联存储的支付卡账号，该查询到的支付卡账号即为原默认支付卡账号，即支付卡属性为目标电子设备的默认支付卡的支付卡账号；
S906、互联网金融平台服务器对原默认支付卡账号的支付卡类型和接收到的支付卡账号的支付卡类型进行比较，若相同，则执行S907，若不相同，则执行S908；
S907、互联网金融平台服务器向目标电子设备发送接收到的支付卡账号对应的支付标记和该支付标记对应的激活指令，然后执行S909；
S908、互联网金融平台服务器向目标电子设备发送接收到的支付卡账号对应的支付标记、该支付标记对应的激活指令和该支付标记对应的个人化数据，然后执行S909；
S909、目标电子设备将该支付标记加载于该支付标记对应的个人化数据中并且将该支付标记激活为激活状态；
S910、目标电子设备向互联网金融平台服务器发送用于指示目标电子设备已将该支付标记设置为激活状态的激活结果；
S911、互联网金融平台服务器首先将与该支付标记关联存储的支付卡 账号对应的支付卡属性设置为目标电子设备的默认支付卡，并且将原默认支付卡账号对应的支付卡属性为非目标属性，然后，将该支付标记对应的标记状态设置为激活状态，并且将与原默认支付卡账号关联存储的支付标记对应的标记状态设置为非激活状态，最后，建立该支付标记与目标电子设备之间的关联关系，并且删除与原默认支付卡账号关联存储的支付标记与目标电子设备之间的关联关系；
S912、互联网金融平台服务器向目标电子设备反馈第二提示信息；
S913、目标电子设备显示第二提示信息，以提示用户目标电子设备的默认支付卡变更成功。
图10示出了本申请实施例提供的解绑支付卡过程的一示例的流程示意图。如图10所示，该解绑支付卡过程可以包括：
S1001、用户打开目标电子设备的金融应用程序的应用界面，在金融应用程序的应用界面内登陆账户，并且在与目标电子设备绑定的至少一个支付卡账号中，选择要解绑的待解绑支付卡账号，使目标电子设备接收用户输入的待解绑的支付卡账号和目标电子设备的目标支付状态，其中，目标支付状态为解绑状态；
S1002、目标电子设备根据目标电子设备标识、该支付卡账号和目标支付状态，生成解绑请求；
S1003、目标电子设备向互联网金融平台服务器发送解绑请求；
S1004、互联网金融平台服务器响应于解绑请求，对解绑请求进行解析，得到目标电子设备标识、该支付卡账号和目标支付状态；
S1005、互联网金融平台服务器查询该支付卡账号对应的支付卡属性，并对该支付卡账号对应的支付卡属性进行判断，若支付卡属性为目标电子设备的非默认支付卡，则执行S1006，若支付卡属性为目标电子设备的默认支付卡，则执行S1007；
S1006、互联网金融平台将与该支付卡账号关联存储的支付标记对应的标记状态更新为解绑状态，然后执行S1008；
S1007、互联网金融平台将与该支付卡账号关联存储的支付标记对应的标记状态更新为解绑状态，并删除与该支付卡账号关联存储的支付标记 与目标电子设备之间的关联关系，然后执行S1008；
S1008、互联网金融平台服务器向目标电子设备发送第四提示信息；
S1009、目标电子设备显示第四提示信息，以提示用户待解绑的支付卡账号的支付状态已变更为解绑状态。
在待解绑的支付卡账号对应的支付卡属性为目标电子设备的默认支付卡的情况下，在目标电子设备与该支付卡账号解绑成功之后，如果互联网金融平台服务器器接收到收单设备发送的与该支付卡账号关联存储的支付标记对应的交易请求后，可以在查询到该支付标记的标记状态为解绑状态时，拒绝该交易请求对应的交易。
需要说明的是，用户点击解绑功能后，能够使互联网金融平台服务器内存储的支付标记对应的标记状态更新为解绑状态。用户还可以点击挂失功能，使互联网金融平台服务器内存储的支付标记对应的标记状态更新为挂失状态。具体地，挂失支付卡过程与解绑支付卡过程相似，在此不做赘述。
另外，用户在将互联网金融平台服务器内存储的支付标记对应的标记状态更新为解绑状态和挂失状态之后，还可以点击重新绑定功能和取消挂失功能，使互联网金融平台服务器内存储的支付标记对应的标记状态重新更新为激活状态，其过程与解绑支付卡过程相似，在此不做赘述。
由此，在本申请实施例中，目标电子设备与所绑定的支付卡账号与目标安全元件中加载的个人化数据属于松耦合关系，属于动态映射关系，因此，在后续重新绑定默认支付卡的过程中，不会造成频繁的验证、下载以及重新写卡的过程。同时，目标安全元件中可以存储通用的个人化数据加载支付标记，可以消除各个发卡机构的个人化数据之间的差异，提高了个人化数据与收单设备之间的兼容性，具有良好的行业合作推广前景。
图11示出了本申请提供的数据处理装置的一实施例的结构示意图。
在本申请一些实施例中，图11所示的装置可以为图1至图4中所示的电子设备110中的目标电子设备。其中，目标电子设备可以为任意电子设备110。
如图11所示，该数据处理装置1100可以包括第一接收模块1110、第 一处理模块1120和第二处理模块1130。
第一接收模块1110可以用于接收目标服务器发送的目标激活数据和目标激活指令。其中，目标激活数据包括待激活支付卡账号对应的待激活支付标记。
第一处理模块1120可以用于响应于目标激活指令，将目标个人化数据中的目标支付标记更新为待激活支付标记。其中，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同。
第二处理模块1130可以用于将更新后的目标支付标记设置为激活状态。
在本申请实施例中，能够在接收到目标服务器发送的待激活支付卡账号对应的待激活支付标记和目标激活指令之后，直接将所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据中的目标支付标记更新为待激活支付标记，并将更新后的目标支付标记设置为激活状态，进而可以直接利用待激活支付标记对目标个人化数据中的目标支付标记进行更新并激活更新后的目标支付标记，无需在激活待激活支付标记的过程中删除已激活的支付标记及其对应的个人化数据，从而减少激活待激活支付标记过程中的个人化数据删除、个人化数据验证及个人化数据下载的过程，避免在设置默认支付卡时因上述的过程产生错误，提高设置默认卡的成功率。
在本申请一些实施例中，目标个人化数据可以为目标安全元件中所存储的支付标记处于激活状态的个人化数据。
在本申请另一些实施例中，目标个人化数据可以为目标安全元件中所存储的支付标记处于非激活状态的个人化数据。
在本申请一些实施例中，目标激活数据还可以包括目标个人化数据；
其中，该数据处理装置1100还可以包括第一存储模块，第一存储模块可以用于将目标个人化数据存储于目标安全元件中。
在本申请一些实施例中，该数据处理装置1100还可以包括第三处理模块，第三处理模块可以用于将更新后的目标支付标记以外的激活支付标记设置为非激活状态。
在本申请一些实施例中，待激活支付卡账号可以包括待设置的默认支付卡账号。
其中，该数据处理装置1100还可以包括第二接收模块、第二生成模块和第二发送模块。
第二接收模块可以用于接收待设置的默认支付卡账号。
第二生成模块可以用于根据待设置的默认支付卡账号，生成默认卡设置请求。
第二发送模块可以用于向目标服务器发送默认卡设置请求；其中，默认卡设置请求用于使目标服务器反馈待设置的默认支付卡账号对应的目标激活数据和目标激活指令。
在本申请另一些实施例中，待激活支付卡账号可以包括待变更的默认支付卡账号。
其中，该数据处理装置1100还可以包括第三接收模块、第三生成模块和第三发送模块。
第三接收模块可以用于接收待变更的默认支付卡账号。
第三生成模块可以用于根据待变更的默认支付卡账号，生成默认卡变更请求。
第三发送模块可以用于向目标服务器发送默认卡变更请求。其中，默认卡变更请求用于使目标服务器反馈待变更的默认支付卡账号对应的目标激活数据和目标激活指令。
需要说明的是，图11所示的数据处理装置1100可以执行图5所示的方法实施例中的各个步骤，并且实现图5所示的方法实施例中的各个过程和效果，在此不做赘述。
图12示出了本申请提供的数据处理装置的另一实施例的结构示意图。
在本申请一些实施例中，图12所示的装置可以为图1至图4中所示的互联网金融平台服务器120。
如图12所示，该数据处理装置1200可以包括第一获取模块1210、第一生成模块1220和第一发送模块1230。
第一获取模块1210可以用于获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令；其中，待激活支付卡账号的交易卡类型与目标激活指令所属的交易卡类型相同。
第一生成模块1220可以用于根据待激活支付标记，生成目标激活数据。
第一发送模块1230可以用于向目标电子设备发送目标激活数据和目标激活指令；其中，目标激活指令用于使目标电子设备将目标个人化数据中的目标支付标记更新为待激活支付标记以及将更新后的目标支付标记设置为激活状态，目标个人化数据所属的交易卡类型与目标激活指令所属的交易卡类型相同。
在本申请实施例中，能够在获取到与待激活支付卡账号关联存储的待激活支付标记和所属的交易卡类型与待激活支付卡账号的交易卡类型相同的目标激活指令之后，根据待激活支付标记，生成目标激活数据，并向目标电子设备发送目标激活数据和目标激活指令，使目标电子设备将所属的交易卡类型与目标激活指令所属的交易卡类型相同的目标个人化数据中的目标支付标记更新为待激活支付标记以及将更新后的目标支付标记设置为激活状态，进而可以直接利用待激活支付标记对目标个人化数据中的目标支付标记进行更新并激活更新后的目标支付标记，无需在激活待激活支付标记的过程中删除已激活的支付标记及其对应的个人化数据，从而减少激活待激活支付标记过程中的个人化数据删除、个人化数据验证及个人化数据下载的过程，避免在设置默认支付卡时因上述的过程产生错误，提高设置默认卡的成功率。
在本申请一些实施例中，该数据处理装置1200还可以包括第二获取模块，第二获取模块可以用于获取目标个人化数据。
其中，第一生成模块1220可以具体用于根据待激活支付标记和目标个人化数据，生成目标激活数据。
在本申请一些实施例中，该数据处理装置1200还可以包括第四发送模块和第四接收模块。
第四发送模块可以用于向目标电子设备发送数据查询请求。其中，数 据查询请求用于查询目标电子设备的目标安全元件中的目标个人化数据。
第四接收模块可以用于接收目标电子设备反馈的数据查询结果。
其中，第二获取模块可以具体用于在数据查询结果为在目标安全元件中未查询到目标个人化数据的情况下，获取目标个人化数据。
在本申请一些实施例中，待激活支付卡账号可以包括待设置的默认支付卡账号。
其中，该数据处理装置1200还可以包括第五接收模块和第一解析模块。
第五接收模块可以用于接收目标电子设备发送的默认卡设置请求。
第一解析模块可以用于响应于默认卡设置请求，对默认卡设置请求进行解析，得到默认卡设置请求信息。其中，默认卡设置请求信息包括待设置的默认支付卡账号。
在本申请一些实施例中，该数据处理装置1200还可以包括第六接收模块、第四处理模块、第五处理模块和第六处理模块。
第六接收模块可以用于接收目标电子设备发送的激活结果。其中，激活结果用于指示目标电子设备已将待激活支付标记设置为激活状态。
第四处理模块可以用于响应于激活结果，将待激活支付卡账号对应的支付卡属性设置为目标属性。其中，目标属性为目标电子设备的默认支付卡。
第五处理模块可以用于将待激活支付标记对应的标记状态设置为激活状态。
第六处理模块可以用于建立待激活支付标记与目标电子设备之间的关联关系。
在本申请一些实施例中，待激活支付卡账号可以包括待变更的默认支付卡账号。
其中，该数据处理装置1200还可以包括第七接收模块和第二解析模块。
第七接收模块可以用于接收目标电子设备发送的默认卡变更请求。
第二解析模块可以用于响应于默认卡变更请求，对默认卡变更请求进 行解析，得到默认卡变更请求信息。其中，默认卡变更请求信息包括待变更的默认支付卡账号。
在本申请一些实施例中，该数据处理装置1200还可以包括第三获取模块，第三获取模块可以用于获取目标支付卡账号。其中，目标支付卡账号对应的支付卡属性为目标属性，目标属性为目标电子设备的默认支付卡。
其中，第四发送模块可以具体用于在目标支付卡账号的支付卡类型与待变更的默认支付卡账号的支付卡类型不相同的情况下，向目标电子设备发送数据查询请求。
在本申请一些实施例中，该数据处理装置1200还可以包括第八接收模块、第七处理模块、第八处理模块和第九处理模块。
第八接收模块可以用于接收目标电子设备发送的激活结果。其中，激活结果用于指示目标电子设备已将待激活支付标记设置为激活状态。
第七处理模块可以用于响应于激活结果，将待激活支付卡账号对应的支付卡属性设置为目标属性，并且将目标支付卡账号对应的支付卡属性为非目标属性。
第八处理模块可以用于将待激活支付标记对应的标记状态设置为激活状态，并且将与目标支付卡账号关联存储的目标支付标记对应的标记状态设置为非激活状态。
第九处理模块可以用于建立待激活支付标记与目标电子设备之间的关联关系，并且删除目标支付标记与目标电子设备之间的关联关系。
在本申请一些实施例中，该数据处理装置1200还可以包括第九接收模块、第三解析模块、第四生成模块、第五发送模块、第十接收模块和第二存储模块。
第九接收模块可以用于接收目标电子设备发送的支付卡绑定请求。
第三解析模块可以用于响应于支付卡绑定请求，对支付卡绑定请求进行解析，得到支付卡绑定请求信息。其中，支付卡绑定请求信息包括待绑定支付卡账号。
第四生成模块可以用于根据待绑定支付卡账号，生成标记生成请求。
第五发送模块可以用于向支付标记管理服务器发送标记生成请求；其中，标记生成请求用于使支付标记管理服务器生成待绑定支付卡账号对应的支付标记。
第十接收模块可以用于接收支付标记管理服务器反馈的待绑定支付卡账号对应的支付标记。
第二存储模块可以用于将待绑定支付卡账号和待绑定支付卡账号对应的支付标记关联存储。
在本申请一些实施例中，该数据处理装置1200还可以包括第十一接收模块、第四解析模块、第四获取模块和第十处理模块。
第十一接收模块可以用于接收状态变更请求。
第四解析模块可以用于响应于状态变更请求，对状态变更请求进行解析，得到状态变更请求信息。其中，状态变更请求信息包括待变更状态的支付卡账号和目标电子设备的目标支付状态。
第四获取模块可以用于获取与待变更状态的支付卡账号关联存储的待变更状态的支付标记。
第十处理模块可以用于将待变更状态的支付标记对应的标记状态更新为目标支付状态。
在本申请一些实施例中，目标支付状态可以包括挂失状态和解绑状态中的任一种；
其中，该数据处理装置1200还可以包括第十一处理模块，第十一处理模块可以用于在待变更状态的支付卡账号对应的支付卡属性为目标属性的情况下，删除待变更状态的支付卡账号与目标电子设备之间的关联关系。其中，目标属性为目标电子设备的默认支付卡。
在本申请一些实施例中，目标支付状态可以包括挂失状态、解绑状态和激活状态中的任一种。
在本申请一些实施例中，该数据处理装置1200还可以包括第十二接收模块、第五解析模块、第十二处理模块和第十三处理模块。
第十二接收模块可以用于接收目标收单设备发送的交易请求。
第五解析模块可以用于响应于交易请求，对交易请求进行解析，得到 交易请求信息。其中，交易请求信息包括目标支付标记。
第十二处理模块可以用于查询目标支付标记对应的标记状态。
第十三处理模块可以用于在目标支付标记对应的标记状态为异常状态的情况下，拒绝执行交易请求对应的交易。
其中，异常状态包括挂失状态和解绑状态中的任一种。
在本申请一些实施例中，该数据处理装置1200还可以包括第五生成模块和第六发送模块。
第五生成模块可以用于根据目标支付标记对应的标记状态，生成交易请求对应的交易反馈信息。
第六发送模块可以用于向目标收单设备发送交易反馈信息。
需要说明的是，图12所示的数据处理装置1200可以执行图6所示的方法实施例中的各个步骤，并且实现图6所示的方法实施例中的各个过程和效果，在此不做赘述。
图13示出了本申请提供的数据处理设备的一实施例的硬件结构示意图。
数据处理设备可以包括处理器1301以及存储有计算机程序指令的存储器1302。
具体地，上述处理器1301可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。
存储器1302可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器1302可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器1302可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器1302可在数据处理设备的内部或外部。在特定实施例中，存储器1302是非易失性固态存储器。在特定实施例中，存储器1302包括只读存储器(ROM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(PROM)、可擦除PROM(EPROM)、电可擦除 PROM(EEPROM)、电可改写ROM(EAROM)或闪存或者两个或更多个以上这些的组合。
处理器1301通过读取并执行存储器1302中存储的计算机程序指令，以实现上述实施例中的任意一种数据处理方法。
在一个示例中，数据处理设备还可包括通信接口1303和总线1310。其中，如图13所示，处理器1301、存储器1302、通信接口1303通过总线1310连接并完成相互间的通信。
通信接口1303，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。
总线1310包括硬件、软件或两者，将数据处理设备的部件彼此耦接在一起。举例来说而非限制，总线1310可包括加速图形端口(AGP)或其他图形总线、增强工业标准架构(EISA)总线、前端总线(FSB)、超传输(HT)互连、工业标准架构(ISA)总线、无限带宽互连、低引脚数(LPC)总线、存储器总线、微信道架构(MCA)总线、外围组件互连(PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(SATA)总线、视频电子标准协会局部(VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1310可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。
该数据处理设备可以执行本申请实施例中的信息处理方法，从而实现结合图5至图12描述的数据处理方法和装置。
另外，结合上述实施例中的数据处理方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种数据处理方法。
需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申 请的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。
以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。
上面参考根据本申请的实施例的方法、装置(系统)和机器程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由程序或指令实现。这些程序或指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些程序或指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。
还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。
以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应 理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。

Claims (25)

  1. 一种数据处理方法，包括：
    接收目标服务器发送的目标激活数据和目标激活指令；其中，所述目标激活数据包括待激活支付卡账号对应的待激活支付标记；
    响应于所述目标激活指令，将目标个人化数据中的目标支付标记更新为所述待激活支付标记；其中，所述目标个人化数据所属的交易卡类型与所述目标激活指令所属的交易卡类型相同；
    将更新后的目标支付标记设置为激活状态。
  2. 根据权利要求1所述的方法，其中，所述目标个人化数据为目标安全元件中所存储的支付标记处于激活状态的个人化数据。
  3. 根据权利要求1所述的方法，其中，所述目标个人化数据为目标安全元件中所存储的支付标记处于非激活状态的个人化数据。
  4. 根据权利要求3所述的方法，其中，所述目标激活数据还包括所述目标个人化数据；
    其中，所述将目标个人化数据中的目标支付标记更新为所述待激活支付标记之前，所述方法还包括：
    将所述目标个人化数据存储于所述目标安全元件中。
  5. 根据权利要求3所述的方法，其中，所述将更新后的目标支付标记设置为激活状态之后，所述方法还包括：
    将所述更新后的目标支付标记以外的激活支付标记设置为非激活状态。
  6. 根据权利要求3或4所述的方法，其中，所述待激活支付卡账号包括待设置的默认支付卡账号；
    其中，所述接收目标服务器发送的目标激活数据和目标激活指令之前，所述方法还包括：
    接收所述待设置的默认支付卡账号；
    根据所述待设置的默认支付卡账号，生成默认卡设置请求；
    向所述目标服务器发送所述默认卡设置请求；其中，所述默认卡设置 请求用于使所述目标服务器反馈所述待设置的默认支付卡账号对应的所述目标激活数据和所述目标激活指令。
  7. 根据权利要求2至5任一项所述的方法，其中，所述待激活支付卡账号包括待变更的默认支付卡账号；
    其中，所述接收目标服务器发送的目标激活数据和目标激活指令之前，所述方法还包括：
    接收所述待变更的默认支付卡账号；
    根据所述待变更的默认支付卡账号，生成默认卡变更请求；
    向所述目标服务器发送所述默认卡变更请求；其中，所述默认卡变更请求用于使所述目标服务器反馈所述待变更的默认支付卡账号对应的所述目标激活数据和所述目标激活指令。
  8. 一种数据处理方法，包括：
    获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令；其中，所述待激活支付卡账号的交易卡类型与所述目标激活指令所属的交易卡类型相同；
    根据所述待激活支付标记，生成目标激活数据；
    向目标电子设备发送所述目标激活数据和所述目标激活指令；其中，所述目标激活指令用于使所述目标电子设备将目标个人化数据中的目标支付标记更新为所述待激活支付标记以及将更新后的目标支付标记设置为激活状态，所述目标个人化数据所属的交易卡类型与所述目标激活指令所属的交易卡类型相同。
  9. 根据权利要求8所述的方法，其中，所述根据所述待激活支付标记，生成目标激活数据之前，所述方法还包括：
    获取所述目标个人化数据；
    其中，所述根据所述待激活支付标记，生成目标激活数据，包括：
    根据所述待激活支付标记和所述目标个人化数据，生成所述目标激活数据。
  10. 根据权利要求9所述的方法，其中，所述获取所述目标个人化数据之前，所述方法还包括：
    向所述目标电子设备发送数据查询请求；其中，所述数据查询请求用于查询所述目标电子设备的目标安全元件中的所述目标个人化数据；
    接收所述目标电子设备反馈的数据查询结果；
    其中，所述获取所述目标个人化数据，包括：
    在所述数据查询结果为在所述目标安全元件中未查询到所述目标个人化数据的情况下，获取所述目标个人化数据。
  11. 根据权利要求10所述的方法，其中，所述待激活支付卡账号包括待设置的默认支付卡账号；
    其中，所述获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令之前，所述方法还包括：
    接收所述目标电子设备发送的默认卡设置请求；
    响应于所述默认卡设置请求，对所述默认卡设置请求进行解析，得到默认卡设置请求信息；其中，所述默认卡设置请求信息包括所述待设置的默认支付卡账号。
  12. 根据权利要求11所述的方法，其中，所述向目标电子设备发送所述目标激活数据和所述目标激活指令之后，所述方法还包括：
    接收所述目标电子设备发送的激活结果；其中，所述激活结果用于指示所述目标电子设备已将所述待激活支付标记设置为激活状态；
    响应于所述激活结果，将所述待激活支付卡账号对应的支付卡属性设置为目标属性；其中，所述目标属性为所述目标电子设备的默认支付卡；
    将所述待激活支付标记对应的标记状态设置为激活状态；
    建立所述待激活支付标记与所述目标电子设备之间的关联关系。
  13. 根据权利要求10所述的方法，其中，所述待激活支付卡账号包括待变更的默认支付卡账号；
    其中，所述获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令之前，所述方法还包括：
    接收所述目标电子设备发送的默认卡变更请求；
    响应于所述默认卡变更请求，对所述默认卡变更请求进行解析，得到默认卡变更请求信息；其中，所述默认卡变更请求信息包括所述待变更的 默认支付卡账号。
  14. 根据权利要求13所述的方法，其中，所述向所述目标电子设备发送数据查询请求之前，所述方法还包括：
    获取目标支付卡账号；其中，所述目标支付卡账号对应的支付卡属性为目标属性，所述目标属性为所述目标电子设备的默认支付卡；
    其中，所述向所述目标电子设备发送数据查询请求，包括：
    在所述目标支付卡账号的支付卡类型与所述待变更的默认支付卡账号的支付卡类型不相同的情况下，向所述目标电子设备发送数据查询请求。
  15. 根据权利要求14所述的方法，其中，所述向目标电子设备发送所述目标激活数据和所述目标激活指令之后，所述方法还包括：
    接收所述目标电子设备发送的激活结果；其中，所述激活结果用于指示所述目标电子设备已将所述待激活支付标记设置为激活状态；
    响应于所述激活结果，将所述待激活支付卡账号对应的支付卡属性设置为所述目标属性，并且将所述目标支付卡账号对应的支付卡属性为非目标属性；
    将所述待激活支付标记对应的标记状态设置为激活状态，并且将与所述目标支付卡账号关联存储的目标支付标记对应的标记状态设置为非激活状态；
    建立所述待激活支付标记与所述目标电子设备之间的关联关系，并且删除所述目标支付标记与所述目标电子设备之间的关联关系。
  16. 根据权利要求8所述的方法，其中，所述获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令之前，所述方法还包括：
    接收所述目标电子设备发送的支付卡绑定请求；
    响应于所述支付卡绑定请求，对所述支付卡绑定请求进行解析，得到支付卡绑定请求信息；其中，所述支付卡绑定请求信息包括待绑定支付卡账号；
    根据所述待绑定支付卡账号，生成标记生成请求；
    向支付标记管理服务器发送所述标记生成请求；其中，所述标记生成请求用于使所述支付标记管理服务器生成所述待绑定支付卡账号对应的支 付标记；
    接收所述支付标记管理服务器反馈的所述待绑定支付卡账号对应的支付标记；
    将所述待绑定支付卡账号和所述待绑定支付卡账号对应的支付标记关联存储。
  17. 根据权利要求8所述的方法，其中，所述方法还包括：
    接收状态变更请求；
    响应于所述状态变更请求，对所述状态变更请求进行解析，得到状态变更请求信息；其中，所述状态变更请求信息包括待变更状态的支付卡账号和所述目标电子设备的目标支付状态；
    获取与所述待变更状态的支付卡账号关联存储的待变更状态的支付标记；
    将所述待变更状态的支付标记对应的标记状态更新为所述目标支付状态。
  18. 根据权利要求17所述的方法，其中，所述目标支付状态包括挂失状态和解绑状态中的任一种；
    其中，所述得到状态变更请求信息之后，所述方法还包括：
    在所述待变更状态的支付卡账号对应的支付卡属性为目标属性的情况下，删除所述待变更状态的支付卡账号与所述目标电子设备之间的关联关系；其中，所述目标属性为所述目标电子设备的默认支付卡。
  19. 根据权利要求17所述的方法，其中，所述目标支付状态包括挂失状态、解绑状态和激活状态中的任一种。
  20. 根据权利要求8所述的方法，其中，所述方法还包括：
    接收目标收单设备发送的交易请求；
    响应于所述交易请求，对所述交易请求进行解析，得到交易请求信息；其中，所述交易请求信息包括所述目标支付标记；
    查询所述目标支付标记对应的标记状态；
    在所述目标支付标记对应的标记状态为异常状态的情况下，拒绝执行所述交易请求对应的交易；
    其中，所述异常状态包括挂失状态和解绑状态中的任一种。
  21. 根据权利要求20所述的方法，其中，所述拒绝执行所述交易请求对应的交易之后，所述方法还包括：
    根据所述目标支付标记对应的标记状态，生成所述交易请求对应的交易反馈信息；
    向所述目标收单设备发送所述交易反馈信息。
  22. 一种数据处理装置，包括：
    第一接收模块，用于接收目标服务器发送的目标激活数据和目标激活指令；其中，所述目标激活数据包括待激活支付卡账号对应的待激活支付标记；
    第一处理模块，用于响应于所述目标激活指令，将目标个人化数据中的目标支付标记更新为所述待激活支付标记；其中，所述目标个人化数据所属的交易卡类型与所述目标激活指令所属的交易卡类型相同；
    第二处理模块，用于将更新后的目标支付标记设置为激活状态。
  23. 一种数据处理装置，包括：
    第一获取模块，用于获取与待激活支付卡账号关联存储的待激活支付标记和目标激活指令；其中，所述待激活支付卡账号的交易卡类型与所述目标激活指令所属的交易卡类型相同；
    第一生成模块，用于根据所述待激活支付标记，生成目标激活数据；
    第一发送模块，用于向目标电子设备发送所述目标激活数据和所述目标激活指令；其中，所述目标激活指令用于使所述目标电子设备将目标个人化数据中的目标支付标记更新为所述待激活支付标记以及将更新后的目标支付标记设置为激活状态，所述目标个人化数据所属的交易卡类型与所述目标激活指令所属的交易卡类型相同。
  24. 一种数据处理设备，包括：处理器以及存储有计算机程序指令的存储器；
    所述处理器执行所述计算机程序指令时实现如权利要求1-21中任意一项所述的数据处理方法。
  25. 一种计算机可读存储介质，所述计算机可读存储介质上存储有计 算机程序指令，所述计算机程序指令被处理器执行时实现如权利要求1-21中任意一项所述的数据处理方法。
PCT/CN2021/072925 2020-07-24 2021-01-20 数据处理方法、装置、设备及介质 Ceased WO2022016840A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2022541670A JP7454052B2 (ja) 2020-07-24 2021-01-20 データ処理方法、装置、デバイス及び媒体
US17/910,676 US20230058201A1 (en) 2020-07-24 2021-01-20 Data processing method, apparatus, device and computer-readable storage medium
AU2021312655A AU2021312655A1 (en) 2020-07-24 2021-01-20 Data processing method and apparatus, device and medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010725073.2 2020-07-24
CN202010725073.2A CN111932245B (zh) 2020-07-24 2020-07-24 数据处理方法、装置、设备及介质

Publications (1)

Publication Number Publication Date
WO2022016840A1 true WO2022016840A1 (zh) 2022-01-27

Family

ID=73314595

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/072925 Ceased WO2022016840A1 (zh) 2020-07-24 2021-01-20 数据处理方法、装置、设备及介质

Country Status (6)

Country Link
US (1) US20230058201A1 (zh)
JP (1) JP7454052B2 (zh)
CN (1) CN111932245B (zh)
AU (1) AU2021312655A1 (zh)
TW (1) TWI784456B (zh)
WO (1) WO2022016840A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111932245B (zh) * 2020-07-24 2023-09-19 中国银联股份有限公司 数据处理方法、装置、设备及介质
CN112581123B (zh) * 2020-12-08 2024-02-23 中国银联股份有限公司 卡管理方法、用户终端、服务器、系统及存储介质
CN112232805B (zh) * 2020-12-15 2021-03-02 中国银联股份有限公司 卡管理方法、用户终端、服务器、系统及存储介质
US20220391896A1 (en) * 2021-06-02 2022-12-08 American Express Travel Related Services Company, Inc. Hosted point-of-sale service
JP7230120B2 (ja) * 2021-06-30 2023-02-28 楽天グループ株式会社 サービス提供システム、サービス提供方法、及びプログラム

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100057624A1 (en) * 2008-08-29 2010-03-04 First Data Corporation Car wallet application
CN105741106A (zh) * 2016-01-29 2016-07-06 宇龙计算机通信科技(深圳)有限公司 一种nfc支付方式的选择方法及装置
CN106920090A (zh) * 2017-02-24 2017-07-04 北京小米移动软件有限公司 Nfc支付方法及装置
CN110462663A (zh) * 2017-03-31 2019-11-15 维萨国际服务协会 用于表示动态真实凭证的静态令牌系统和方法
CN110781699A (zh) * 2019-10-31 2020-02-11 北京小米支付技术有限公司 Nfc卡片的切换方法及装置
CN111932245A (zh) * 2020-07-24 2020-11-13 中国银联股份有限公司 数据处理方法、装置、设备及介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9955332B2 (en) * 2009-01-28 2018-04-24 Headwater Research Llc Method for child wireless device activation to subscriber account of a master wireless device
CN101511074B (zh) * 2009-03-30 2012-03-07 宇龙计算机通信科技(深圳)有限公司 移动终端支付的账户选择方法、系统、服务器及终端
US9558481B2 (en) * 2010-09-28 2017-01-31 Barclays Bank Plc Secure account provisioning
US9881260B2 (en) * 2012-10-03 2018-01-30 Moovel North America, Llc Mobile ticketing
KR102008206B1 (ko) * 2016-07-20 2019-08-07 코나아이 (주) 카드 거래 서비스를 관리하는 서버, 방법 및 시스템
US11538025B1 (en) * 2017-02-14 2022-12-27 Wells Fargo Bank, N.A. Mobile wallet first time customer
CN107016486B (zh) * 2017-03-03 2021-05-04 北京小米支付技术有限公司 信息变更方法及装置
TWM563013U (zh) * 2017-07-13 2018-07-01 熊子傑 結合行動通訊裝置及應用場域系統的快捷付費系統
CN109034818B (zh) * 2018-06-19 2022-05-13 创新先进技术有限公司 生成支付标记、利用支付标记进行验证的方法及装置
CA3050480A1 (en) * 2018-07-24 2020-01-24 Royal Bank Of Canada Payment card with secure element and replenishable tokens
CN109993513A (zh) * 2019-03-22 2019-07-09 北京三快在线科技有限公司 支付账户绑定银行卡的方法、装置和系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100057624A1 (en) * 2008-08-29 2010-03-04 First Data Corporation Car wallet application
CN105741106A (zh) * 2016-01-29 2016-07-06 宇龙计算机通信科技(深圳)有限公司 一种nfc支付方式的选择方法及装置
CN106920090A (zh) * 2017-02-24 2017-07-04 北京小米移动软件有限公司 Nfc支付方法及装置
CN110462663A (zh) * 2017-03-31 2019-11-15 维萨国际服务协会 用于表示动态真实凭证的静态令牌系统和方法
CN110781699A (zh) * 2019-10-31 2020-02-11 北京小米支付技术有限公司 Nfc卡片的切换方法及装置
CN111932245A (zh) * 2020-07-24 2020-11-13 中国银联股份有限公司 数据处理方法、装置、设备及介质

Also Published As

Publication number Publication date
CN111932245B (zh) 2023-09-19
TWI784456B (zh) 2022-11-21
CN111932245A (zh) 2020-11-13
AU2021312655A1 (en) 2022-05-26
JP7454052B2 (ja) 2024-03-21
US20230058201A1 (en) 2023-02-23
JP2023510731A (ja) 2023-03-15
TW202205168A (zh) 2022-02-01

Similar Documents

Publication Publication Date Title
US11374943B2 (en) Secure interface using non-secure element processors
US10776101B2 (en) Systems and methods for updatable applets
CN111932245B (zh) 数据处理方法、装置、设备及介质
US11250391B2 (en) Token check offline
US11640592B2 (en) System, method, and apparatus for integrating multiple payment options on a merchant webpage
US20160132875A1 (en) Enhancement of mobile device initiated transactions
TWI797638B (zh) 資訊處理方法、裝置、設備及介質
US11580531B2 (en) Systems and methods for minimizing user interactions for cardholder authentication
WO2019178075A1 (en) Digital access code
KR20250047749A (ko) 분산형 디지털화된 대리자를 사용한 지불 처리를 위한 방법 및 시스템
WO2025170641A2 (en) Token portfolio migration system and method
WO2024215307A1 (en) Devices, systems, and methods for seamlessly integrating and facilitating the use of fiat and digital assets
HK40040570B (zh) 数据处理方法、装置、设备及介质
US20240370862A1 (en) Mutual authentication of peer-to-peer payments
HK40040570A (zh) 数据处理方法、装置、设备及介质
US20250061457A1 (en) Platform-agnostic universal transaction profiles
HK40040571B (zh) 信息处理方法、装置、设备及介质
WO2025071589A1 (en) Validation of non-fungible token by associating issuer payment link token on a mobile device
WO2025147250A1 (en) Tap to provision device binding technique
AU2024328246A1 (en) Platform-agnostic universal transaction profiles

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: 21847234

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021312655

Country of ref document: AU

Date of ref document: 20210120

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2022541670

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21847234

Country of ref document: EP

Kind code of ref document: A1