WO2017028627A1 - 一种支付标记生成方法及装置 - Google Patents

一种支付标记生成方法及装置 Download PDF

Info

Publication number
WO2017028627A1
WO2017028627A1 PCT/CN2016/087509 CN2016087509W WO2017028627A1 WO 2017028627 A1 WO2017028627 A1 WO 2017028627A1 CN 2016087509 W CN2016087509 W CN 2016087509W WO 2017028627 A1 WO2017028627 A1 WO 2017028627A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
account
server
payment account
token
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/CN2016/087509
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
Publication of WO2017028627A1 publication Critical patent/WO2017028627A1/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
    • 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/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • 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/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for generating a payment token.
  • Bank card holders can use the bank card to conduct online or offline transactions, and more and more cardholders will bind the bank card with some services, which brings a lot of convenience to cardholders. For example, binding a utility bill, binding a carrier, and so on. While the bank card brings convenience to the cardholder, it also brings some trouble. If the cardholder loses the bank card, the cardholder needs to re-apply the bank card, so that the services bound to the original bank card need to be re-bound.
  • the embodiment of the invention provides a method and a device for generating a payment token, which are used to solve the problem that the service bound to the payment account needs to be re-bound with the account after the payment account is changed.
  • An embodiment of the present invention provides a method for generating a payment token, including:
  • the first server receives the tokenization request sent by the second server, where the tokenization request carries the first payment account;
  • the first server sends a payment mark request request message to the third server according to the first payment account, where the payment mark application request message is used to instruct the third server to map the second payment account to the first payment account.
  • a payment token the payment token being used to pass the payment token
  • the payment token is mapped to the first payment account, and the second payment account is generated by the third server according to the first payment account;
  • the method further includes:
  • the attribute information includes historical transaction information of the payment account, user information of the payment account, and binding service information of the payment account;
  • the payment equity information includes one or any combination of the following parameters:
  • the method further includes:
  • the first server acquires a payment token conversion response message that is sent by the third server and carries a first payment account, where the first payment account is an account that is mapped by the payment token, and the payment token conversion response message is the The third server sends after receiving the payment token conversion request message;
  • the first server sends a transaction authorization request message carrying the first payment account to a second server corresponding to the payment account, so that the second server determines whether the transaction authorization is performed according to the first payment account.
  • the first payment account is a primary account PAN.
  • An embodiment of the present invention provides a payment token generating apparatus, including:
  • a first receiving module configured to receive a tokenization request sent by the second server, where the tokenization request carries a first payment account
  • a sending module configured to send a payment mark request request message to the third server according to the first payment account, where the payment mark request request message is used to instruct the third server to map the second payment account to the first payment account a payment token, the payment token being used to map the payment token to the first payment account when the payment transaction is performed by the payment token, and the second payment account is the third server according to the first Generated by a payment account;
  • a second receiving module configured to receive a payment token response message sent by the third server, determine, according to the payment token response message, a payment token mapped by the first payment account, and use the first receiving module to A payment token mapped by the first payment account is sent to the second server.
  • the first receiving module is further configured to:
  • the attribute information includes historical transaction information of the payment account, user information of the payment account, and binding service information of the payment account;
  • the payment equity information includes one or any combination of the following parameters:
  • the second receiving module is further configured to:
  • the first payment account is a primary account PAN.
  • Embodiments of the present invention provide a payment token generating apparatus, including
  • a transceiver configured to receive a tokenization request sent by the second server, where the tokenization request carries a first payment account
  • a processor configured to send, by using the transceiver, a payment mark request request message to the third server according to the first payment account, where the payment mark request request message is used to indicate that the third server
  • the second payment account is mapped to a payment token of the first payment account, and the payment token is configured to map the payment token to the first payment account when the payment transaction is performed by the payment token,
  • the second payment account is generated by the third server according to the first payment account;
  • a processor configured to receive, by the transceiver, a payment token response message sent by the third server, determine, according to the payment token response message, a payment token mapped by the first payment account, and use the transceiver to A payment token mapped by the first payment account is sent to the second server.
  • the transceiver is further configured to:
  • the processor is configured to configure payment equity information for the payment token of the first payment account according to the attribute information of the second payment account.
  • the attribute information includes historical transaction information of the payment account, user information of the payment account, and binding service information of the payment account;
  • the processor is specifically configured to:
  • the payment equity information includes one or any combination of the following parameters:
  • the transceiver is further configured to:
  • the first payment account is a primary account PAN.
  • the first server after receiving the first payment account, the first server sends a payment token application request message to the third server, instructing the third server to map the second payment account to the location a payment token of the first payment account, the payment token being used to replace the first payment account when the first payment account performs a payment transaction.
  • the second payment account when the transaction transaction is performed by using the second payment account, after the transaction party obtains the second payment account, the second payment account may be mapped to the first payment account for transaction.
  • the payment service bound to the payment account can also be bound to the second payment account, and the service of the first payment account is not required to be re-bound to the payment account, which brings convenience to the card holder.
  • FIG. 1 is a schematic diagram of a payment process in the prior art
  • FIG. 2 is a flowchart of a method for generating a payment token according to an embodiment of the present invention
  • FIG. 3 is a schematic structural diagram of a payment network according to an embodiment of the present invention.
  • FIG. 4 is a structural diagram of a payment token generating apparatus according to an embodiment of the present invention.
  • FIG. 5 is a structural diagram of a payment token generating apparatus according to an embodiment of the present invention.
  • FIG. 1 it is a schematic diagram of a payment process in the prior art.
  • the payment process in Figure 1 is as follows:
  • the transaction terminal obtains the user's payment account and sends a transaction request to the acquirer.
  • the transaction request sent by the transaction terminal includes at least information such as a payment account.
  • the transaction terminal can be a terminal such as a POS (point of sale) machine.
  • POS point of sale
  • the acquirer receives the transaction request sent by the transaction terminal and sends the transaction request to the payment network.
  • the payment network authorizes the transaction request and sends an authorization request message to the second server corresponding to the payment account.
  • the authorization request message includes at least information such as a payment account.
  • the second server completes the confirmation of the payment account and the verification of the authorization, and sends an authorization response message to the payment network.
  • the authorization response message includes at least information such as a payment account.
  • the payment network forwards the authorization response message to the acquirer.
  • the acquirer notifies the transaction terminal of the authorization result in the authorization response message.
  • the payment account is always included in the interaction information between the transaction terminal, the acquirer, the payment network, and the second server. Payment accounts can be exposed in any of these links. In today's rapid development of Internet technology, the exposure of payment accounts can easily lead to information leakage of cardholders, thus bringing unnecessary risks to cardholders. For example, in 2013, the US retail giant Target's servers were hacked, causing the credit card account of about 40 million customers to leak.
  • one or more of the following items are installed in the sales terminal: a magnetic strip reader, a contactless reader, a contact reader, etc., for reading Take the cardholder's payment account.
  • the payment account can also be entered into the sales terminal.
  • the sales terminal is generally located in an entity merchant or a network merchant.
  • the sales terminal can communicate with the acquirer by any wired or wireless communication.
  • the acquirer receives the transaction request sent by the sales terminal corresponding to the acquirer, and forwards the transaction request to the payment network; the acquirer may be an entity such as a bank or a third party acquirer.
  • a payment network is a network entity that can confirm and authorize information about a payment account.
  • the payment network can complete the payment clearing and settlement services with the account issuer. After receiving the transaction request from the acquirer, the payment network accepts, transmits or processes the transaction request sent by the acquirer.
  • the payment network can be an entity such as a card organization.
  • the payment network may also be a Token Requestor, and initiate a tag request action to the Token Service Provider.
  • An account issuer generally refers to an entity that issues and maintains a payment account, can issue a payment account, maintain a payment account, and configure the rights of the payment account.
  • an account issuer can be an entity such as a bank.
  • the first server may refer to the requesting party
  • the second server may refer to the account issuing party
  • the third server may refer to the marking service provider
  • the first server may be a server of a card organization network
  • the second server may be a server of an account issuer
  • the third server may be a server that marks a service provider.
  • the method includes:
  • Step 201 The first server receives the tokenization request sent by the second server, where the tokenization request carries the first payment account.
  • Step 202 The first server sends a payment mark request request message to the third server according to the first payment account, where the payment mark application request message is used to instruct the third server to map the second payment account to the first a payment token of the payment account, the payment token being configured to map the payment token to the first payment account when the payment transaction is performed by the payment token, and the second payment account is the third server according to the third server Generated by the first payment account;
  • Step 203 The first server receives a payment token response message sent by the third server, determines a payment token mapped by the first payment account according to the payment token response message, and maps the first payment account. A payment token is sent to the second server.
  • the first server may receive the tokenization request sent by the second server in multiple manners, for example, by using a wired method, or by using a wireless method, etc., and the embodiment of the present invention does not limited.
  • the first server may further receive attribute information of the first payment account sent by the second server, where the attribute information includes historical transaction information of the first payment account and the first payment account.
  • User information configuring payment benefit information for the payment token of the first payment account according to the attribute information of the first payment account.
  • the first server may determine, according to the attribute information of the first payment account, the transaction habits of the user corresponding to the first payment account, the common transaction location, the transaction amount range, and the like, so that different payment equity information may be configured for the payment token.
  • the historical transaction information of the first payment account may include information such as the length of use of the first payment account, the amount of each transaction, the location of each transaction, and the type of each transaction.
  • the user information of the first payment account may include the occupation, income, credit status, and the like of the user.
  • the first server configures multiple payment equity information for the payment token, so that the payment account corresponding to the payment token has different payment rights in different payment services. Specifically, the first server determines, according to the binding service information of the second payment account, the service bound to the second payment account; and according to the historical transaction information of the second payment account and/or the user information of the second payment account, Each service bound to the second payment account sets a payment equity information.
  • the payment equity information configured by the first server for the payment token may include one or any combination of the following parameters:
  • the upper limit of the payment amount corresponding to the payment mark, and the payment amount of the first payment account corresponding to the payment mark cannot exceed the upper limit of the payment amount, otherwise the transaction may fail;
  • the upper limit of the number of payment corresponding to the payment mark, and the number of times of payment of the first payment account corresponding to the payment mark cannot exceed the upper limit of the number of payment times, otherwise the transaction may fail;
  • the payment merchant information corresponding to the payment mark may be used to limit the first payment account corresponding to the payment mark to be only used in the set payment merchant;
  • the payment type corresponding to the payment mark may limit the branch of the first payment account corresponding to the payment mark
  • the payment type can only be the set payment type
  • the payment location corresponding to the payment mark may limit that the first payment account corresponding to the payment mark can only be traded at the set payment position;
  • different payment equity information may be configured for different payment services for the payment token, where the payment token corresponds to multiple payment equity information, and each payment equity information corresponds to one payment service.
  • the first payment account is carried in the payment mark application request message sent by the first server to the third server, and the related information of the second server may be carried in the payment mark application request message.
  • the payment token application request message sent by the first server is a payment token for instructing the third server to map the second payment account to the first payment account.
  • the payment token is stored in the physical magnetic card of the second payment account, and each time the physical magnetic card of the second payment account is used for the payment transaction, the second payment account is read, and the second server can be used to The payment account is converted into the second payment account to map the first payment account, thereby completing the transaction.
  • the second payment account is generated by the third server according to the first payment account.
  • the generation rule of the second payment account is the same as the generation rule of the first payment account, and the second payment account generated by the third server is a unique account.
  • the first payment account is a primary account number (PAN)
  • the generated second payment account is also a primary account PAN, and the first payment account and the second payment account correspond to the same first server.
  • the third server is configured to establish a mapping relationship between the first payment account and the second payment account. At the same time, the third server further maintains the mapping relationship between the established first payment account and the second payment account, and queries the second payment account mapped by the first payment account, or queries the first payment of the second payment account mapping. Account number, and return the query result to the query requester and other operations.
  • the first server determines a payment token of the payment account according to the payment token response message sent by the third server.
  • the first case is a first case:
  • the first payment account is bound with a lot of payment services, such as binding water and electricity payment services, and the first payment account is mapped in the payment service bound by the first payment account.
  • the server corresponding to the payment service bound to the first payment account first obtains the second time after the payment service bound to the first payment account needs to perform the payment transaction. Paying an account, that is, obtaining a payment token, and transmitting the obtained payment token to the first server, the first server converting the payment token to the first payment account mapped by the payment token by the third server, and then the first payment The account number is sent to the first server to complete the payment transaction.
  • the second case is a first case
  • the payment token of the first payment account is stored in a storage medium of the first payment account, for example, in the payment card of the first payment account.
  • the transaction terminal can only obtain the payment token and cannot obtain the first payment account.
  • the transaction terminal sends the obtained payment token to the first server, and the first server converts the payment token into the first payment account mapped by the payment token by the third server, and then sends the first payment account to the first server. Complete the payment transaction.
  • the first payment account and the second payment account in the embodiment of the present invention are the primary account PAN.
  • the main account is generally composed of 13 to 19 digits.
  • the first 6-8 digits are the card BIN (Bank Identification Number), and the payment token card BIN is an ISO (International Standardization Organization). ) Authorized international BIN number.
  • the user holding the first payment account only needs to bind the payment service with the payment token, and when the payment transaction is performed, the payment service obtains the payment token. And sending the payment token to the first server, and the first server and the third server perform a conversion operation of the payment token and the first payment account.
  • the first payment account is changed, only the first payment account mapped by the payment token is mapped to the payment account after the change by the second server.
  • the first payment account may not be exposed during the payment transaction, and only the payment token mapped by the first payment account is required. Make a payment. Specifically, the following steps can be taken:
  • Step 1 The first server receives the transaction request message and obtains the payment token carried in the transaction request message.
  • the transaction request message can also carry parameters such as time information.
  • Step 2 The first server sends a payment token conversion request message carrying the payment token to the third server.
  • Step 3 The first server acquires a payment token conversion response message that is sent by the third server and carries a first payment account, where the first payment account is an account that is mapped by the payment token, and the payment token conversion response message is The third server transmits after receiving the payment token conversion request message.
  • De-marking of the payment account is implemented after the payment token is converted into the first payment account.
  • the payment token conversion response message further includes payment benefit information verification information of the payment token, where the payment equity information verification information is determined by the third server after verifying the payment equity information of the payment token.
  • the third server determines that the payment amount of the first payment account corresponding to the payment mark exceeds the payment amount upper limit corresponding to the payment mark, and thus determines that the payment equity information verification information is the verification failure.
  • the third server may set a field in the payment token conversion response message to indicate the payment equity information verification information, for example, using 1 bit, the bit is 0, indicating that the verification fails; the bit is 1, indicating that the verification is successful.
  • the second server performs the transaction authorization, it may determine whether to perform the transaction authorization according to the payment equity information verification information.
  • Step 4 The first server sends a transaction authorization request message carrying the first payment account to the second server corresponding to the first payment account, so that the second server determines whether the transaction authorization is performed according to the payment account.
  • Step 5 The first server receives the authorization response message sent by the second server, and replaces the first payment account with the payment token mapped by the first payment account, and sends it to the transaction request cancellation.
  • the sender of the message, and finally the sender of the transaction request message notifies the transaction terminal whether the transaction succeeded or failed.
  • the first server may further send the last four digits of the first payment account to the sender of the transaction request message, so that the sender of the transaction request message performs payment account verification.
  • the transaction request received by the first server does not include the first payment account, but a payment token mapped to the first payment account.
  • the third server will pay the token.
  • the first payment account is mapped to the payment token so that the second server can confirm the first payment account that initiated the transaction.
  • the first payment account is no longer bound to the transaction, and only the payment token is determined, and the first payment account corresponding to the payment token can be determined, thereby completing the transaction. Therefore, the payment token can be bound to various services.
  • the first payment account is replaced, only the first payment account mapped by the payment token needs to be updated, which brings convenience to the cardholder. At the same time, since the first payment account is available and invisible, the security risk caused by the disclosure of the first payment account is avoided.
  • FIG. 3 a schematic diagram of a payment network architecture provided by an embodiment of the present invention.
  • the transaction terminal 301 in FIG. 3 can be the same as the transaction terminal in the prior art, and does not require any hardware changes.
  • the transaction terminal 301 acquires the payment token mapped by the cardholder's first payment account instead of the first payment account.
  • the transaction terminal 301 transmits a transaction request message carrying a payment token to the acquirer 302.
  • the payment token instead of the payment account exists in the entire payment process.
  • the acquirer 302 forwards the transaction request of the transaction terminal 301 to the tag requester 303.
  • the tag requester 303 can be a participant in an existing payment network architecture or a newly added entity.
  • the existing payment network is used as the mark requesting party.
  • the tag requesting party 303 needs to determine the first payment account number of the payment tag mapping by the tag service provider 304 before performing the settlement with the account issuer 305, authorizing the transaction, and the like.
  • the markup service provider 304 may be a new entity.
  • the markup service provider 304 maps the payment mark sent by the mark requester 303 to the first payment account, and sends the first payment account.
  • the requesting party 303 is marked.
  • the markup service provider 304 is also responsible for the generation and distribution of payment tokens, establishing and maintaining a mapping relationship between the payment token and the first payment account, and performing operations such as switching between the payment token and the first payment account.
  • the markup service provider 304 can also determine a mark validity period for the generated payment token, during which the payment token is valid.
  • the payment process provided by the embodiment of the present invention mainly includes the following steps:
  • Step 1 The transaction terminal 301 obtains the cardholder's payment token and initiates a transaction to the acquirer 302 corresponding to the payment terminal.
  • Step 2 The acquirer 302 checks and processes the transaction initiated by the transaction terminal 301, and sends a transaction request message to the tag requester 303, where the request message carries at least the payment token.
  • Step 3 The mark requesting party 303 sends a payment mark conversion request message to the mark service provider 304 for converting the received payment mark sent by the acquirer 302 into the first payment account.
  • Step 4 The tag service provider 304 determines the first payment account of the payment tag mapping and sends it to the tag requester 303.
  • the mark service provider 304 may further verify the transaction of the payment mark according to the payment benefit information of the payment mark, generate payment benefit information verification information, and send it to the mark requesting party 303.
  • Step 5 The mark requesting party 303 replaces the payment mark in the transaction request message sent by the acquirer with the first payment account and sends it to the account issuer 305.
  • Step 6 The account issuer 305 completes the payment account verification and the authorization check, determines whether the transaction is authorized, and sends the authorization result to the tag requesting party 303.
  • Step 7 The mark requesting party 303 replaces the first payment account in the authorization result of the account issuer 305 with the payment mark, and sends it to the acquirer 302.
  • Step 8 The acquirer 302 transmits the authorization result to the transaction terminal 301.
  • the embodiment of the present invention further provides a payment mark generating device, and the specific content of the device may be implemented by referring to the foregoing method, and details are not described herein again.
  • an embodiment of the present invention provides a structure diagram of a payment token generating apparatus, and the apparatus package include:
  • the first receiving module 401 is configured to receive a tokenization request sent by the second server, where the tokenization request carries the first payment account;
  • the sending module 402 is configured to send a payment mark request request message to the third server according to the first payment account, where the payment mark request request message is used to instruct the third server to map the second payment account to the first payment account.
  • a payment token the payment token being used to map the payment token to the first payment account when the payment transaction is performed by the payment token, and the second payment account is the third server according to the Generated by the first payment account;
  • a second receiving module 403 configured to receive a payment token response message sent by the third server, determine, according to the payment token response message, a payment token mapped by the first payment account, and pass the first receiving module 401 The payment token mapped by the first payment account is sent to the second server.
  • the first receiving module 401 is further configured to:
  • the attribute information includes historical transaction information of the payment account, user information of the payment account, and binding service information of the payment account;
  • the payment equity information includes one or any combination of the following parameters:
  • the second receiving module 403 is further configured to:
  • the first payment account is a primary account PAN.
  • the embodiment of the present application further provides a payment mark generating device, which can execute the above method.
  • FIG. 5 is a schematic structural diagram of a payment token generating apparatus according to an embodiment of the present application.
  • the payment token generating apparatus includes: a processor 501, a transceiver 502, and a memory 503;
  • the processor 501 can be a central processing unit (English: central processing unit, abbreviated: CPU), a network processor (English: network processor, abbreviated: NP) or a combination of a CPU and an NP.
  • the processor 501 may further include a hardware chip.
  • the hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (abbreviated as PLD), or a combination thereof.
  • ASIC application-specific integrated circuit
  • PLD programmable logic device
  • the above PLD can be a complex programmable logic device (English: complex programmable logic device, abbreviation: CPLD), field-programmable gate array (English: field-programmable gate array, abbreviation: FPGA), general array logic (English: generic array Logic, abbreviation: GAL) or any combination thereof.
  • the memory 503 may include a volatile memory, such as a random access memory (English: random-access memory, abbreviation: RAM); the memory 503 may also include a nonvolatile memory.
  • Non-volatile memory such as read-only memory (English: read-only memory, abbreviation: ROM), flash memory (English: flash memory), hard disk (English: hard disk drive, abbreviation: HDD) Or a solid state drive (English: solid-state drive, abbreviated: SSD); the memory 503 may also include a combination of the above types of memory.
  • the memory 503 can be used to store computer instructions.
  • the transceiver 502 is configured to receive a tokenization request sent by the second server, where the tokenization request carries a first payment account;
  • the processor 501 is configured to send, by using the transceiver 502, a payment mark request request message to the third server according to the first payment account, where the payment mark request request message is used to instruct the third server to map the second payment account to a payment token of the first payment account, the payment token is configured to map the payment token to the first payment account when the payment transaction is performed by the payment token, and the second payment account is the
  • the third server is generated according to the first payment account;
  • the processor 501 is configured to receive, by the transceiver 502, a payment token response message sent by the third server, determine, according to the payment token response message, a payment token mapped by the first payment account, and pass the transceiver. 502. Send the payment token mapped by the first payment account to the second server.
  • the transceiver 502 is further configured to:
  • the processor 501 is configured to configure payment equity information for the payment token of the first payment account according to the attribute information of the second payment account.
  • the attribute information includes historical transaction information of the payment account, user information of the payment account, and binding service information of the payment account;
  • the processor 501 is specifically configured to:
  • the payment equity information includes one or any combination of the following parameters:
  • the transceiver 502 is further configured to:
  • the transceiver, the first payment account is a primary account PAN.
  • the first server after receiving the first payment account and the second payment account, the first server sends a payment token application request message to the third server, instructing the third server to map the second payment account to the a payment token of the first payment account, the payment token being used to replace the first payment account when the first payment account performs a payment transaction.
  • the transaction party when the payment transaction is performed by using the first payment account, the transaction party obtains a payment token mapped to the first payment account, that is, the second payment account, and the second payment account is obtained by this method.
  • the bound payment service can also be bound to the first payment account, and the service that binds the original second payment account does not need to be rebinded by the payment account, which brings convenience to the card holder.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention may be employed in one or more A computer program product embodied on a computer usable storage medium (including but not limited to disk storage and optical storage, etc.) containing computer usable program code.
  • a computer usable storage medium including but not limited to disk storage and optical storage, etc.
  • the present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • the computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine instruction for generating instructions executed by a processor of a computer or other programmable data processing device Means for implementing the functions specified in one or more flows of the flowchart or in a block or blocks of the flowchart.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

Landscapes

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

Abstract

一种支付标记生成方法及装置，方法包括：第一服务器接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号（201）；第一服务器根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的（202）；所述第一服务器接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并将所述第一支付账号映射的支付标记发送给所述第二服务器（203）。

Description

一种支付标记生成方法及装置
本申请要求在2015年8月18日提交中华人民共和国知识产权局、申请号为201510508169.2、发明名称为“一种支付标记生成方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及计算机技术领域，尤其涉及一种支付标记生成方法及装置。
背景技术
银行卡持卡人使用可以通过银行卡进行线上或线下的交易，同时越来越多的持卡人会将银行卡与一些业务进行绑定，从而为持卡人带来了很多便利，例如绑定水电费账户、绑定通信运营商等。银行卡为持卡人带来便利的同时，也带来了一些麻烦。如果持卡人由于银行卡丢失等情况，导致持卡人需要重新办理银行卡，从而使得原有银行卡绑定的业务均需要重新进行绑定。
目前，对于如何避免持卡人的支付账号更改导致持卡人带来的不便，还没有明确的解决方法。
发明内容
本发明实施例提供一种支付标记生成方法及装置，用以解决支付账号更改后，需要将与所述支付账号绑定的业务重新进行账号绑定的问题。
本发明实施例提供一种支付标记生成方法，包括：
第一服务器接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
所述第一服务器根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标 记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
所述第一服务器接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并将所述第一支付账号映射的支付标记发送给所述第二服务器。
优选的，还包括：
接收所述第二服务器发送的所述第二支付账号的属性信息；
根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
优选的，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
所述根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息，包括：
根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
优选的，所述支付权益信息包括以下参数中的一种或任意组合：
支付标记对应的支付金额上限；
支付标记对应的支付次数上限；
支付标记对应的支付商户信息；
支付标记对应的支付类型；
支付标记对应的支付位置；
支付标记的有效期。
优选的，所述将所述第一支付账号映射的支付标记发送给所述第二服务器之后，还包括：
所述第一服务器接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
所述第一服务器向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
所述第一服务器获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
所述第一服务器发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
优选的，所述第一支付账号为主账号PAN。
本发明实施例提供一种支付标记生成装置，包括：
第一接收模块，用于接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
发送模块，用于根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
第二接收模块，用于接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并通过所述第一接收模块将所述第一支付账号映射的支付标记发送给所述第二服务器。
优选的，所述第一接收模块还用于：
接收所述第二服务器发送的所述第二支付账号的属性信息；
根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
优选的，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
所述根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息，包括：
根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
优选的，所述支付权益信息包括以下参数中的一种或任意组合：
支付标记对应的支付金额上限；
支付标记对应的支付次数上限；
支付标记对应的支付商户信息；
支付标记对应的支付类型；
支付标记对应的支付位置；
支付标记的有效期。
优选的，所述第二接收模块还用于：
接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
优选的，所述第一支付账号为主账号PAN。
本发明实施例提供一种支付标记生成装置，包括
收发器，用于接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
处理器，用于通过所述收发器根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将 第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
处理器，用于通过所述收发器接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并通过所述收发器将所述第一支付账号映射的支付标记发送给所述第二服务器。
可选的，所述收发器还用于：
接收所述第二服务器发送的所述第二支付账号的属性信息；
所述处理器，用于根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
可选的，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
所述处理器具体用于：
根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
可选的，所述支付权益信息包括以下参数中的一种或任意组合：
支付标记对应的支付金额上限；
支付标记对应的支付次数上限；
支付标记对应的支付商户信息；
支付标记对应的支付类型；
支付标记对应的支付位置；
支付标记的有效期。
可选的，所述收发器还用于：
接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
可选的，所述第一支付账号为主账号PAN。
根据本发明实施例提供的方法及装置，第一服务器在接收到第一支付账号后，向第三服务器发送支付标记申请请求消息，指示所述第三服务器将所述第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在所述第一支付账号进行支付交易时替换所述第一支付账号。根据本发明实施例提供的方法，在使用第二支付账号进行支付交易时，交易方获得第二支付账号后，可以将第二支付账号映射为第一支付账号进行交易，通过这种方法使得第一支付账号所绑定的支付业务也能与第二支付账号绑定，不需要将绑定第一支付账号的业务进行支付账号的重新绑定，为持卡人带来了便利。
附图说明
图1为现有技术中支付流程示意图；
图2为本发明实施例提供的一种支付标记生成方法流程图；
图3为本发明实施例提供的一种支付网络架构示意图；
图4为本发明实施例提供的一种支付标记生成装置结构图；
图5为本发明实施例提供的一种支付标记生成装置结构图。
具体实施方式
下面结合说明书附图对本发明实施例做详细描述。
现有技术中，持卡人进行支付、转账等操作时，需要通过第二服务器分 配给持卡人的支付账号来完成。如图1所示，为现有技术中支付流程示意图。图1中的支付流程具体如下：
1.交易终端获取用户的支付账号，向收单方发送交易请求。交易终端发送的交易请求中至少包含支付账号等信息。
交易终端可以为POS(point of sale，销售终端)机等终端。
2.收单方接收交易终端发送的交易请求，并将该交易请求发送给支付网络。
3.支付网络授权该交易请求，并向该支付账号对应的第二服务器发送授权请求消息。授权请求消息中至少包含支付账号等信息。
4.第二服务器完成对支付账号的确认以及授权的验证，并向支付网络发送授权响应消息。授权响应消息中至少包含支付账号等信息。
5.支付网络将授权响应消息转发给收单方。
6.收单方将授权响应消息中的授权结果通知交易终端。
从上述支付流程可以看出，支付账号始终包含在交易终端、收单方、支付网络以及第二服务器之间的交互信息中。支付账号可以在其中任何一个环节遭到暴露，在互联网技术飞速发展的今天，支付账号暴露很容易造成持卡人的信息泄露，从而为持卡人带来一些不必要的风险。例如，2013年美国零售业巨头Target公司的服务器被黑客攻击，导致约4，000万客户的信用卡账号发生泄露。
需要说明的是，本发明实施例中，销售终端中安装有下列各项中的一种或多种：磁条读取器、非接触式读取器、接触式读取器等，用于读取持卡人的支付账号。当然也可以将支付账号输入到销售终端中。销售终端一般位于实体商户或者网络商户中。销售终端可以通过任何有线或者无线通信方式与收单方通信。
收单方接收与收单方对应的销售终端发送的交易请求，并将该交易请求转发给支付网络；收单方可以是银行或者第三方收单机构等实体。
支付网络是指可以对支付账号的相关信息进行确认以及授权的网络实体。 支付网络可以与账号发放方完成支付的清算以及结算等服务。支付网络接收到收单方的交易请求之后，受理、传输或处理收单方发送的交易请求。支付网络可以是卡组织等实体。在本发明实施例中，支付网络还可能会成为标记请求方(Token Requestor)，向标记服务提供方(Token Service Provider)发起标记请求动作。
账号发放方一般是指发行并维护支付账号的实体，可以发行支付账号，对支付账号进行维护，并且对支付账号的权益进行配置等。例如，账号发放方可以是银行等实体。
需要说明的是，本发明实施例中第一服务器可以是指标记请求方，第二服务器是可以指账号发放方，第三服务器可以是指标记服务提供方。
下面通过具体的实施例详细描述支付流程。
如图2所示，本发明实施例提供的一种支付标记生成方法流程图。图3流程中，第一服务器可以是卡组织网络的服务器等，第二服务器可以是账号发放方的服务器等，第三服务器可以是标记服务提供方的服务器等。
参见图2，该方法包括：
步骤201：第一服务器接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
步骤202：所述第一服务器根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
步骤203：所述第一服务器接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并将所述第一支付账号映射的支付标记发送给所述第二服务器。
步骤201中，第一服务器可以通过多种方式接收第二服务器发送的标记化请求，例如，通过有线方式，或者通过无线方式等，本发明实施例在此并不 限定。
第二服务器发送标记化请求的同时，还可以发送其他信息给第一服务器，以便第一服务器对支付账号进行分析。
举例来说，第一服务器还可以接收所述第二服务器发送的所述第一支付账号的属性信息，所述属性信息包括所述第一支付账号的历史交易信息以及所述第一支付账号的用户信息；根据所述第一支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
第一服务器可以根据第一支付账号的属性信息确定该第一支付账号对应的用户的交易习惯、常用交易地点、交易金额范围等，从而可以为支付标记配置不同的支付权益信息。
第一支付账号的历史交易信息中可以包括第一支付账号的使用时间长度、每次交易的金额、每次交易的地点、每次交易的类型等信息。
第一支付账号的用户信息可以包括用户的职业、收入、信用情况等。
可选的，第一服务器会为支付标记配置多个支付权益信息，使得支付标记对应的支付账号在不同支付业务拥有不同的支付权益。具体的，第一服务器根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
可选的，第一服务器为支付标记配置的支付权益信息可以包括以下参数中的一种或任意组合：
支付标记对应的支付金额上限，支付标记对应的第一支付账号每次的支付金额不能超过该支付金额上限，否则可能会导致交易失败；
支付标记对应的支付次数上限，支付标记对应的第一支付账号每天的支付次数不能超过该支付次数上限，否则可能会导致交易失败；
支付标记对应的支付商户信息，可以限定支付标记对应的第一支付账号只在设定的支付商户中进行交易；
支付标记对应的支付类型，可以限定支付标记对应的第一支付账号的支 付类型只能为设定的支付类型；
支付标记对应的支付位置，可以限定支付标记对应的第一支付账号只能在设定的支付位置进行交易；
支付标记的有效期。
可选的，可以为支付标记在不同支付业务下配置不同支付权益信息，此时支付标记对应多个支付权益信息，每个支付权益信息对应一个支付业务。
步骤202中，第一服务器向第三服务器发送的支付标记申请请求消息中携带第一支付账号的同时，支付标记申请请求消息中还可以携带第二服务器的相关信息。
第一服务器发送的支付标记申请请求消息是为了指示第三服务器将第二支付账号映射为第一支付账号的支付标记。举例来说，支付标记存储于第二支付账号的物理磁卡中，每次使用第二支付账号的物理磁卡进行支付交易时，读取到的是第二支付账号，通过第三服务器可以将第二支付账号转换为该第二支付账号映射第一支付账号，从而完成交易。
本发明实施例中第二支付账号为第三服务器根据第一支付账号生成的。第二支付账号的生成规则与第一支付账号的生成规则相同，而且第三服务器生成的第二支付账号为一个唯一的账号。举例来说，第一支付账号为主账号PAN(primary account number)，那么生成的第二支付账号也为主账号PAN，而且第一支付账号与第二支付账号对应于相同的第一服务器。
步骤203中，第三服务器用于建立第一支付账号与第二支付账号之间的映射关系。同时，第三服务器还对建立的第一支付账号与第二支付账号之间的映射关系进行维护，以及查询第一支付账号映射的第二支付账号，或者查询第二支付账号映射的第一支付账号，并将查询结果返回给查询请求方等操作。
第一服务器根据第三服务器发送的支付标记响应消息确定支付账号的支付标记。
通过支付标记进行支付交易的情况一般有两种，下面分别进行描述。
第一种情况：
第一支付账号绑定了很多支付业务，例如绑定水、电缴费业务，第一支付账号绑定的支付业务中映射了第一支付账号。第二支付账号被第三服务器配置为第一支付账号的支付标记之后，第一支付账号绑定的支付业务需要进行支付交易时，第一支付账号绑定的支付业务对应的服务器先获取第二支付账号，即获取支付标记，并将获取到的支付标记发送给第一服务器，第一服务器会通过第三服务器将支付标记转换为该支付标记映射的第一支付账号，然后将该第一支付账号发送给第一服务器以完成支付交易。
第二种情况：
第一支付账号的支付标记存储于第一支付账号的存储介质中，例如，第一支付账号的支付卡中。当采用第一支付账号的支付卡通过交易终端进行支付交易时，交易终端只能获取支付标记，不能获取到第一支付账号。交易终端将获取到的支付标记发送给第一服务器，第一服务器会通过第三服务器将支付标记转换为该支付标记映射的第一支付账号，然后将该第一支付账号发送给第一服务器以完成支付交易。
可选的，本发明实施例中的第一支付账号以及第二支付账号为主账号PAN。主账号一般由13至19位的数字组成，其中，前6-8位为卡BIN(Bank Identification Number，发卡行识别码)，支付标记的卡BIN是一个具有ISO(International Standardization Organization，国际标准化组织)授权的国际通用BIN号。
第二服务器发放的第一支付账号有了对应的支付标记之后，持有第一支付账号的用户只需要将支付业务与支付标记进行绑定，在进行支付交易时，支付业务获取到支付标记，并将该支付标记发送至第一服务器，由第一服务器与第三服务器进行支付标记与第一支付账号的转换操作。当第一支付账号改变时，只需要通过第二服务器将支付标记映射的第一支付账号映射为改变之后的支付账号即可。
为第一支付账号分配了支付标记之后，第一支付账号在进行支付交易过程中，第一支付账号可以不用暴露，只需通过第一支付账号映射的支付标记 进行支付。具体的，可以为以下步骤：
步骤1：第一服务器接收交易请求消息，并获取所述交易请求消息中携带的支付标记。
需要说明的是，该交易请求消息中并不携带第一支付账号。交易请求消息中还可以携带时间信息等参数。
步骤2：第一服务器向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
步骤3：第一服务器获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的。
支付标记转换为第一支付账号之后实现了支付账号的去标记化。
可选的，支付标记转换响应消息中还包括所述支付标记的支付权益信息验证信息，所述支付权益信息验证信息是所述第三服务器对所述支付标记的支付权益信息验证后确定的。
举例来说，第三服务器确定支付标记对应的第一支付账号的支付金额超过了该支付标记对应的支付金额上限，因此确定支付权益信息验证信息为验证不通过。
第三服务器可以在支付标记转换响应消息中设定一个字段来表示支付权益信息验证信息，例如，采用1个比特，该比特为0，表示验证失败；该比特为1，表示验证成功。第二服务器在进行交易授权时，可以根据支付权益信息验证信息确定是否进行交易授权。
步骤4：第一服务器发送携带有所述第一支付账号的交易授权请求消息给所述第一支付账号对应的第二服务器，以便所述第二服务器根据所述支付账号判断是否交易授权。
步骤5：第一服务器接收到第二服务器发送的授权响应消息，并将其中的第一支付账号替换为该第一支付账号映射的支付标记之后发送给交易请求消 息发送方，最后由交易请求消息发送方通知交易终端交易成功还是失败。
可选的，第一服务器还可以将第一支付账号的最后四位数字发送给交易请求消息发送方，以便交易请求消息发送方进行支付账号验证。
上述方案中，在交易发起时，第一服务器接收到的交易请求中不包含第一支付账号，而是与该第一支付账号映射的支付标记，在交易授权验证时，第三服务器将支付标记转换为与该支付标记映射的第一支付账号，使得第二服务器可以确认发起交易的第一支付账号。通过本发明实施例提供的方法，第一支付账号不再与交易绑定，只需确定支付标记，就可以确定支付标记对应的第一支付账号，从而完成交易。因此，可以将支付标记与各种业务绑定，第一支付账号在更换时，只需要更新支付标记映射的第一支付账号即可，为持卡人带来了便利。同时由于第一支付账号是可用而不可见的，避免了第一支付账号泄露后带来的安全风险。
下面以第一服务器为标记请求方，第二服务器为账号发放方，第三服务器为标记服务提供方为例，描述一种支付网络架构。具体的，如图3所示，本发明实施例提供的一种支付网络架构示意图。图3中的交易终端301可以与现有技术中的交易终端相同，不需要任何硬件上的改变。在支付流程中，交易终端301获取到持卡人的第一支付账号映射的支付标记，而不是第一支付账号。交易终端301将携带支付标记的交易请求消息发送给收单方302。支付标记代替支付账号存在于整个支付流程中。
收单方302将交易终端301的交易请求转发给标记请求方303。标记请求方303可以是现有支付网络架构中的参与者，也可以是新增加的实体。优选的，本发明实施例中，以现有的支付网络作为标记请求方。
标记请求方303在与账号发放方305进行结算、授权交易等操作前，需要通过标记服务提供方304确定支付标记映射的第一支付账号。
图3中，标记服务提供方304可以为新增的实体，在支付流程中，标记服务提供方304会将标记请求方303发送的支付标记映射为第一支付账号，并将第一支付账号发送给标记请求方303。
标记服务提供方304还负责支付标记的生成和分配，建立和维护支付标记与第一支付账号之间的映射关系，为支付标记与第一支付账号之间转换进行服务等操作。标记服务提供方304还可以为生成的支付标记确定一个标记有效期，在标记有效期内，支付标记有效。
下面通过一个具体实施例来描述上述架构下的支付流程。
结合图3，本发明实施例提供的支付流程主要包括以下步骤：
步骤一、交易终端301获取持卡人的支付标记，并向支付终端对应的收单方302发起交易。
步骤二、收单方302对交易终端301发起的交易进行检查和处理，向标记请求方303发送交易请求消息，该请求消息中至少携带支付标记。
步骤三、标记请求方303向标记服务提供方304发送支付标记转换请求消息，用于将接收到的收单方302发送的支付标记转换为第一支付账号。
步骤四、标记服务提供方304确定支付标记映射的第一支付账号，并发送给标记请求方303。
可选的，标记服务提供方304还可以对根据支付标记的支付权益信息对该支付标记的此次交易进行验证，生成支付权益信息验证信息，一并发送给标记请求方303。
步骤五、标记请求方303将收单方发送的交易请求消息中的支付标记替换为第一支付账号后发送给账号发放方305。
步骤六、账号发放方305完成支付账号验证以及授权检查，确定是否授权此次交易，并将授权结果发送给标记请求方303。
步骤七、标记请求方303将账号发放方305的授权结果中的第一支付账号替换为支付标记后，发送给收单方302。
步骤八、收单方302将授权结果发送给交易终端301。
针对上述方法流程，本发明实施例还提供一种支付标记生成装置，该装置的具体内容可以参照上述方法实施，在此不再赘述。
如图4所示，本发明实施例提供一种支付标记生成装置结构图，该装置包 括：
第一接收模块401，用于接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
发送模块402，用于根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
第二接收模块403，用于接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并通过所述第一接收模块401将所述第一支付账号映射的支付标记发送给所述第二服务器。
优选的，所述第一接收模块401还用于：
接收所述第二服务器发送的所述第二支付账号的属性信息；
根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
优选的，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
所述根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息，包括：
根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
优选的，所述支付权益信息包括以下参数中的一种或任意组合：
支付标记对应的支付金额上限；
支付标记对应的支付次数上限；
支付标记对应的支付商户信息；
支付标记对应的支付类型；
支付标记对应的支付位置；
支付标记的有效期。
优选的，所述第二接收模块403还用于：
接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
优选的，所述第一支付账号为主账号PAN。
基于相同的发明构思，本申请实施例还提供一种支付标记生成装置，该支付标记生成装置可以执行上述方法。
如图5所示，为本申请实施例提供的一种支付标记生成装置结构示意图。
参见图5，该支付标记生成装置包括：处理器501、收发器502、存储器503；
处理器501可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：network processor，缩写：NP)或者CPU和NP的组合。处理器501还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic array logic,缩写：GAL)或其任意组合。存储器503可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器503也可以包括非易失 性存储器(英文：non-volatile memory)，例如只读存储器(英文：read-only memory，缩写：ROM)，快闪存储器(英文：flash memory)，硬盘(英文：hard disk drive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器503还可以包括上述种类的存储器的组合。
所述存储器503可以用来存储计算机指令。
收发器502，用于接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
处理器501，用于通过所述收发器502根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
处理器501，用于通过所述收发器502接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并通过所述收发器502将所述第一支付账号映射的支付标记发送给所述第二服务器。
可选的，所述收发器502还用于：
接收所述第二服务器发送的所述第二支付账号的属性信息；
所述处理器501，用于根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
可选的，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
所述处理器501具体用于：
根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
可选的，所述支付权益信息包括以下参数中的一种或任意组合：
支付标记对应的支付金额上限；
支付标记对应的支付次数上限；
支付标记对应的支付商户信息；
支付标记对应的支付类型；
支付标记对应的支付位置；
支付标记的有效期。
可选的，所述收发器502还用于：
接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
所述收发器，所述第一支付账号为主账号PAN。
综上所述，第一服务器在接收到第一支付账号以及第二支付账号后，向第三服务器发送支付标记申请请求消息，指示所述第三服务器将所述第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在所述第一支付账号进行支付交易时替换所述第一支付账号。根据本发明实施例提供的方法，在使用第一支付账号进行支付交易时，交易方获得的是与第一支付账号映射的支付标记，即第二支付账号，通过这种方法使得第二支付账号所绑定的支付业务也能与第一支付账号绑定，不需要将绑定原第二支付账号的业务进行支付账号的重新绑定，为持卡人带来了便利。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个 其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器指令，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (18)

  1. 一种支付标记生成方法，其特征在于，该方法包括：
    第一服务器接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
    所述第一服务器根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
    所述第一服务器接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并将所述第一支付账号映射的支付标记发送给所述第二服务器。
  2. 如权利要求1所述的方法，其特征在于，还包括：
    接收所述第二服务器发送的所述第二支付账号的属性信息；
    根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
  3. 如权利要求2所述的方法，其特征在于，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
    所述根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息，包括：
    根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
    根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
  4. 如权利要求2所述的方法，其特征在于，所述支付权益信息包括以下参数中的一种或任意组合：
    支付标记对应的支付金额上限；
    支付标记对应的支付次数上限；
    支付标记对应的支付商户信息；
    支付标记对应的支付类型；
    支付标记对应的支付位置；
    支付标记的有效期。
  5. 如权利要求1所述的方法，其特征在于，所述将所述第一支付账号映射的支付标记发送给所述第二服务器之后，还包括：
    所述第一服务器接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
    所述第一服务器向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
    所述第一服务器获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
    所述第一服务器发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
  6. 如权利要求1至5任一项所述的方法，其特征在于，所述第一支付账号为主账号PAN。
  7. 一种支付标记生成装置，其特征在于，包括
    第一接收模块，用于接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
    发送模块，用于根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支 付账号为所述第三服务器根据所述第一支付账号生成的；
    第二接收模块，用于接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并通过所述第一接收模块将所述第一支付账号映射的支付标记发送给所述第二服务器。
  8. 如权利要求7所述的装置，其特征在于，所述第一接收模块还用于：
    接收所述第二服务器发送的所述第二支付账号的属性信息；
    根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
  9. 如权利要求8所述的装置，其特征在于，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
    所述根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息，包括：
    根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
    根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
  10. 如权利要求8所述的装置，其特征在于，所述支付权益信息包括以下参数中的一种或任意组合：
    支付标记对应的支付金额上限；
    支付标记对应的支付次数上限；
    支付标记对应的支付商户信息；
    支付标记对应的支付类型；
    支付标记对应的支付位置；
    支付标记的有效期。
  11. 如权利要求7所述的装置，其特征在于，所述第二接收模块还用于：
    接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
    向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
    获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消 息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
    发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
  12. 如权利要求7至11任一项所述的装置，其特征在于，所述第一支付账号为主账号PAN。
  13. 一种支付标记生成装置，其特征在于，包括
    收发器，用于接收第二服务器发送的标记化请求，所述标记化请求中携带第一支付账号；
    处理器，用于通过所述收发器根据第一支付账号向第三服务器发送支付标记申请请求消息，所述支付标记申请请求消息用于指示所述第三服务器将第二支付账号映射为所述第一支付账号的支付标记，所述支付标记用于在通过所述支付标记进行支付交易时，将所述支付标记映射为所述第一支付账号，所述第二支付账号为所述第三服务器根据所述第一支付账号生成的；
    处理器，用于通过所述收发器接收所述第三服务器发送的支付标记响应消息，根据所述支付标记响应消息确定所述第一支付账号映射的支付标记，并通过所述收发器将所述第一支付账号映射的支付标记发送给所述第二服务器。
  14. 如权利要求13所述的装置，其特征在于，所述收发器还用于：
    接收所述第二服务器发送的所述第二支付账号的属性信息；
    所述处理器，用于根据所述第二支付账号的属性信息为所述第一支付账号的支付标记配置支付权益信息。
  15. 如权利要求14所述的装置，其特征在于，所述属性信息包括支付账号的历史交易信息、支付账号的用户信息及支付账号的绑定业务信息；
    所述处理器具体用于：
    根据第二支付账号的绑定业务信息确定所述第二支付账号所绑定的业务；
    根据第二支付账号的历史交易信息和/或第二支付账号的用户信息，为所述第二支付账号所绑定的每个业务设定一个支付权益信息。
  16. 如权利要求14所述的装置，其特征在于，所述支付权益信息包括以下参数中的一种或任意组合：
    支付标记对应的支付金额上限；
    支付标记对应的支付次数上限；
    支付标记对应的支付商户信息；
    支付标记对应的支付类型；
    支付标记对应的支付位置；
    支付标记的有效期。
  17. 如权利要求13所述的装置，其特征在于，所述收发器还用于：
    接收交易请求消息，并获取所述交易请求消息中携带的支付标记；
    向所述第三服务器发送携带有所述支付标记的支付标记转换请求消息；
    获取所述第三服务器发送的携带有第一支付账号的支付标记转换响应消息，第一支付账号为所述支付标记映射的账号，所述支付标记转换响应消息为所述第三服务器接收到所述支付标记转换请求消息之后发送的；
    发送携带有所述第一支付账号的交易授权请求消息给所述支付账号对应的第二服务器，以便所述第二服务器根据所述第一支付账号判断是否交易授权。
  18. 如权利要求13至17任一项所述的装置，其特征在于，所述第一支付账号为主账号PAN。
PCT/CN2016/087509 2015-08-18 2016-06-28 一种支付标记生成方法及装置 Ceased WO2017028627A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510508169.2A CN105931035A (zh) 2015-08-18 2015-08-18 一种支付标记生成方法及装置
CN201510508169.2 2015-08-18

Publications (1)

Publication Number Publication Date
WO2017028627A1 true WO2017028627A1 (zh) 2017-02-23

Family

ID=56839954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/087509 Ceased WO2017028627A1 (zh) 2015-08-18 2016-06-28 一种支付标记生成方法及装置

Country Status (2)

Country Link
CN (1) CN105931035A (zh)
WO (1) WO2017028627A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106779698B (zh) * 2016-11-17 2021-01-26 飞天诚信科技股份有限公司 一种支付标记的分发及其安全支付方法、系统及装置
CN107038560B (zh) * 2017-01-06 2020-09-08 阿里巴巴集团控股有限公司 一种支付业务执行的系统、方法及装置
CN108171492B (zh) * 2018-01-12 2020-10-16 阿里巴巴集团控股有限公司 支付方法、装置及设备
CN109447607B (zh) * 2018-10-30 2021-09-21 中国银联股份有限公司 一种单位账户的交易方法及装置
CN112184210B (zh) * 2020-09-08 2025-01-07 中国银联股份有限公司 跨网络交易方法、系统及计算机可读存储介质
CN114548976A (zh) * 2020-11-26 2022-05-27 银联国际有限公司 基于token的银行卡绑卡方法及其系统、移动终端

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008151229A1 (en) * 2007-06-05 2008-12-11 Mastercard International, Inc. Methods and apparatus for preventing fraud in payment processing transactions
CN102640177A (zh) * 2009-12-03 2012-08-15 欧搜卡德远程有限责任公司 用于核准交易的系统和方法
CN103177360A (zh) * 2011-12-21 2013-06-26 中国银联股份有限公司 一种基于统一个人信息的支付系统和方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101067856A (zh) * 2007-06-28 2007-11-07 向亚峰 一种实现网络支付的方法及系统
CN101414370A (zh) * 2008-12-15 2009-04-22 阿里巴巴集团控股有限公司 利用虚拟卡提高支付安全的支付方法、系统及支付平台
CN103870957A (zh) * 2012-12-13 2014-06-18 陈文原 将虚拟账户余额运用于实体购物的交易系统及其方法
CN104504565A (zh) * 2015-01-16 2015-04-08 上海浩恺信息科技有限公司 一种基于银行虚拟卡号的移动支付系统和方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008151229A1 (en) * 2007-06-05 2008-12-11 Mastercard International, Inc. Methods and apparatus for preventing fraud in payment processing transactions
CN102640177A (zh) * 2009-12-03 2012-08-15 欧搜卡德远程有限责任公司 用于核准交易的系统和方法
CN103177360A (zh) * 2011-12-21 2013-06-26 中国银联股份有限公司 一种基于统一个人信息的支付系统和方法

Also Published As

Publication number Publication date
CN105931035A (zh) 2016-09-07

Similar Documents

Publication Publication Date Title
US12499433B1 (en) Systems and methods for contactless smart card authentication
JP6642920B2 (ja) ネットワーク・トークン・システム
US11756014B2 (en) Systems and methods for mobile device-enabled cardless cash withdrawals
US20200349534A1 (en) Secure offline approval of initiated data exchanges
US8317090B2 (en) Methods and systems for performing a financial transaction
US20210217005A1 (en) Tokenization of contactless cards
KR20260036049A (ko) 사용자 계정 연계 결제 및 청구, 통합 디지털 청구인 결제 지갑을 위한 방법, 장치 및 시스템
US20170132617A1 (en) Token-based system for securing and recovering data
JP2019507431A (ja) 位置照合を使用する認証システムおよび方法
WO2017028627A1 (zh) 一种支付标记生成方法及装置
US12086801B2 (en) System and method of using localized blockchain to enable payment card use without connectivity
KR102808364B1 (ko) 자체-규제 토큰을 인출하기 위해서 화이트리스트화된 거래 어드레스를 필요로 하는 자체-규제 토큰의 거래 어드레스로의 이전을 허용하기 이전에 거래 어드레스가 화이트리스트화되었는지를 검증
US10839371B1 (en) Contactless card tap pay for offline transactions
US20200034818A1 (en) System and method for performing cashless transactions between computing devices
CN113439284B (zh) 使用非接触式卡的验证的评论
US20200111081A1 (en) Child tokens for digital wallets
WO2022005636A1 (en) Real time selection of payment account
US12299090B2 (en) Remote creation of virtual credential bound to physical location
RU2792051C2 (ru) Система сетевых токенов
HK40055603A (zh) 使用非接触式卡的验证的评论

Legal Events

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

Ref document number: 16836491

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16836491

Country of ref document: EP

Kind code of ref document: A1