Cross-border contactless payment method, apparatus and system

Abstract

The application provides a cross-border non-contact payment method, device and system, the method comprising: receiving a cross-border payment binding request initiated by a user through an electronic wallet application, the request containing an identification of a target overseas non-contact payment scenario; generating a payment mark suitable for the target overseas non-contact payment scenario for the unique identity of the user, and binding the payment mark with the account associated with the unique identity; returning the payment mark and virtual card generation parameters to the electronic wallet application; receiving an overseas non-contact payment transaction request initiated by the user through the virtual card, the transaction request containing the payment mark; performing demarking processing on the payment mark to obtain the unique identity of the user; sending a payment instruction containing the unique identity to the corresponding electronic wallet system, and determining one or more accounts for deduction from the account associated with the unique identity according to the preset deduction rules or the real-time selection of the user to complete the payment.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a cross-border contactless payment method, device and system. Background Technology

[0002] With increasing globalization, the demand for cross-border electronic payments is growing. Users expect to be able to conveniently and quickly make purchases abroad using their domestic e-wallets. However, existing technologies face many challenges when applying domestic e-wallets to overseas contactless (NFC) payment scenarios.

[0003] Currently, the mainstream cross-border payment solutions mainly include the following:

[0004] Bank card tokenization schemes: This scheme uses payment tokens to replace users' real bank card numbers for transactions to improve security. However, its drawback is that the tokenized object is limited to a single bank card account. For modern e-wallets that integrate multiple funding sources such as bank cards, wallet balances, and third-party payment channels, this scheme cannot integrate multi-source payment capabilities, resulting in a single payment channel and a disconnect from the e-wallet's account system. Furthermore, users need to repeat the cumbersome card-binding process every time they bind a new bank card, and managing multiple payment tokens is also very inconvenient, severely impacting the user experience.

[0005] Traditional cross-border contactless transactions using bank cards involve users directly using physical bank cards with NFC functionality or binding their physical card information to a mobile payment app (usually based on the Secure Element (SE) model) for payment. The drawback is the risk of loss and fraudulent use of physical cards. Furthermore, the SE-based mobile payment model has high technical barriers to entry, and is typically only implemented by a few mobile phone manufacturers, limiting the widespread adoption and application of domestic e-wallets overseas.

[0006] Cross-border QR code payment solution: Payment is made by scanning a QR code at overseas merchants. The main drawback of this method is its limited acceptance scope, mainly concentrated in some large merchants or popular tourist areas, failing to widely cover scenarios where contactless payments are commonly used. Furthermore, the operation of QR code payments differs from the mainstream "tap-to-pay" habit overseas.

[0007] Therefore, the industry urgently needs a new technological solution to address the challenges of balancing security, compatibility, flexibility, and user experience in cross-border contactless payment scenarios using e-wallets. Summary of the Invention

[0008] In view of this, this application provides a cross-border contactless payment method, apparatus and system to solve at least one of the aforementioned problems.

[0009] To achieve the above objectives, this application adopts the following approach:

[0010] According to a first aspect of this application, embodiments of this application provide a cross-border contactless payment method, the method being applied to a payment tokenization system, the method comprising:

[0011] Receive cross-border payment binding requests initiated by users through e-wallet applications, which contain the identifier of the target overseas contactless payment scenario;

[0012] In response to the cross-border payment binding request, a payment token adapted to the target overseas contactless payment scenario is generated for the user's unique identity, and the payment token is bound to the account associated with the unique identity;

[0013] The payment token and virtual card generation technical parameters are returned to the e-wallet application so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card for contactless payment overseas.

[0014] Receive the overseas contactless payment transaction request initiated by the user through the virtual card, wherein the transaction request includes the payment token;

[0015] The payment token is de-tagged and parsed to obtain the user's unique identity identifier;

[0016] The payment instruction containing the unique identifier is sent to the corresponding e-wallet system. The e-wallet system then determines one or more accounts associated with the unique identifier to deduct funds according to preset deduction rules or the user's real-time selection, thereby completing the payment.

[0017] As an embodiment of this application, the step of generating a payment token for the user's unique identity that is compatible with the target overseas contactless payment scenario in the above method specifically includes:

[0018] Based on the payment network type and / or target region contained in the target overseas contactless payment scenario identifier, the corresponding BIN segment rules are adapted to generate a payment tag that conforms to the payment network technical specifications.

[0019] As an embodiment of this application, the virtual card in the above method is a virtual card generated based on host card emulation technology.

[0020] As an embodiment of this application, in the above method, after the electronic wallet system determines the deduction account according to the preset deduction rules or the user's real-time selection, it further dynamically triggers at least one identity verification step, including device fingerprint verification, biometric verification, or SMS verification code verification, based on the transaction amount, device environment, or user behavior habits.

[0021] As an embodiment of this application, the account associated with the unique identity in the above method includes at least one of a bank card, a wallet balance account, or a third-party payment channel.

[0022] As an embodiment of this application, the virtual card in the above method embeds a scene identifier associated with the payment token, the scene identifier including target network type, validity period and / or target region; the method further includes: verifying the consistency between the payment token and the scene identifier embedded in the virtual card before performing de-marking processing on the payment token.

[0023] According to a second aspect of this application, embodiments of this application provide a cross-border contactless payment device, the device being applied to a payment tokenization system, the method comprising:

[0024] The binding request receiving unit is used to receive cross-border payment binding requests initiated by users through e-wallet applications, which contain the identifier of the target overseas contactless payment scenario;

[0025] The binding unit is used to respond to the cross-border payment binding request, generate a payment token for the user's unique identity that is compatible with the target overseas contactless payment scenario, and bind the payment token to the account associated with the unique identity.

[0026] A binding feedback unit is used to return the payment token and virtual card generation technical parameters to the e-wallet application, so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card to make contactless payments overseas;

[0027] A transaction request receiving unit is configured to receive an overseas contactless payment transaction request initiated by the user through the virtual card, wherein the transaction request includes the payment token;

[0028] The de-marking unit is used to de-mark the payment token and parse it to obtain the user's unique identity identifier;

[0029] The payment instruction sending unit is used to send a payment instruction containing the unique identifier to the corresponding e-wallet system. The e-wallet system then determines one or more accounts associated with the unique identifier to deduct funds according to preset deduction rules or the user's real-time selection, thereby completing the payment.

[0030] As an embodiment of this application, the step of the binding unit generating a payment token adapted to the target overseas contactless payment scenario for the user's unique identity specifically includes:

[0031] Based on the payment network type and / or target region contained in the target overseas contactless payment scenario identifier, the corresponding BIN segment rules are adapted to generate a payment tag that conforms to the payment network technical specifications.

[0032] As an embodiment of this application, the virtual card described above is a virtual card generated based on host card emulation technology.

[0033] As an embodiment of this application, the above-mentioned device further includes: a secondary verification unit, which is used to further dynamically trigger at least one identity verification step, including device fingerprint verification, biometric verification or SMS verification code verification, based on the transaction amount, device environment or user behavior habits, after the electronic wallet system determines the deduction account according to the preset deduction rules or the user's real-time selection.

[0034] As an embodiment of this application, the account associated with the unique identity includes at least one of a bank card, a wallet balance account, or a third-party payment channel.

[0035] As an embodiment of this application, the virtual card embeds a scene identifier associated with the payment token, the scene identifier including a target network type, validity period and / or target region; the device further includes: a payment token verification unit, used to verify the consistency between the payment token and the scene identifier embedded in the virtual card before performing de-marking processing on the payment token.

[0036] According to a third aspect of this application, embodiments of this application provide a cross-border contactless payment system, the system comprising: a domestic e-wallet, an overseas contactless payment device, an overseas card organization network, a domestic card organization network, a payment tokenization system, a domestic clearing network, an e-wallet institution, and a card issuing institution;

[0037] The payment tokenization system is used to receive a cross-border payment binding request initiated by a user through an e-wallet, which contains an identifier of a target overseas contactless payment scenario; respond to the cross-border payment binding request, generate a payment token for the user's unique identifier that is compatible with the target overseas contactless payment scenario, and bind the payment token to the account associated with the unique identifier; and return the payment token and virtual card generation technical parameters to the e-wallet application, so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card to make overseas contactless payments.

[0038] The overseas contactless payment device is used to forward the transaction request from the domestic e-wallet to the overseas card organization network, and the transaction request includes the payment token and transaction data;

[0039] The foreign card organization network is used to identify the BIN segment in the payment token to confirm the network type, and after confirming that the network type is correct, to route the transaction request to the domestic card organization network;

[0040] The domestic card organization network is used to send the transaction request to the payment tokenization system;

[0041] The payment tokenization system is also used to receive the transaction request, de-tokenize the payment token, and parse it to obtain the user's unique identity identifier; and send the payment instruction containing the unique identity identifier to the corresponding e-wallet institution through the domestic clearing network;

[0042] The electronic wallet institution is used to determine one or more accounts associated with the unique identifier for deduction based on the payment instruction, so as to complete the payment.

[0043] According to a fourth aspect of this application, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described working method.

[0044] According to a fifth aspect of this application, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described working method.

[0045] According to a sixth aspect of this application, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described working method.

[0046] The cross-border contactless payment method, device, and system proposed in this application break through the limitations of traditional tokenization, which is limited to bank cards. By using user-based tokenization, payment tokens are bound to user identities, rather than single bank cards. This integrates multiple funding sources within the e-wallet, such as bank cards, wallet balance accounts, and third-party payment channels. When users make payments overseas, the system can flexibly utilize the optimal payment channel based on preset rules or real-time selection, meeting diverse payment needs. Simultaneously, this application employs scenario-based dynamic token generation technology to dynamically generate payment tokens that conform to the technical specifications (such as BIN segment rules) of the target overseas payment network and region. This solves the format compatibility issue between the domestic e-wallet account system and different overseas card organization networks, enabling virtual cards based on HCE technology to be seamlessly recognized and accepted by overseas devices, significantly shortening the adaptation cycle for accessing new overseas networks. Finally, users only need to bind their entire e-wallet account system (rather than a single bank card) once to apply it to overseas contactless payments, avoiding the hassle of repeatedly performing the cumbersome card binding process for multiple bank cards. When making a payment, the system can intelligently select the optimal channel, improving the convenience and success rate of the payment, and seamlessly connecting with the mainstream "tap to pay" habit overseas. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0048] Figure 1 This is a flowchart illustrating a cross-border contactless payment method provided in an embodiment of this application;

[0049] Figure 2 This is a schematic diagram of the structure of a cross-border contactless payment method device provided in an embodiment of this application;

[0050] Figure 3 This is a schematic diagram of the structure of a cross-border contactless payment method system provided in an embodiment of this application;

[0051] Figure 4 This is a schematic diagram illustrating the entire process of cross-border contactless payment provided in an embodiment of this application;

[0052] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and descriptions of this application are used to explain this application, but are not intended to limit this application.

[0054] The information collected in the technical solution of this application is information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, and necessary confidentiality measures have been taken. This does not violate public order and good morals, and corresponding operation interfaces are provided for users to choose to authorize or refuse. The acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0055] The technical terms used in this application will be explained below:

[0056] "User": In payment scenarios, this refers to a natural person or entity holding a payment wallet account, through which they perform operations such as fund storage, transfer, and payment. Users can register based on identity identifiers such as mobile phone numbers or email addresses, without relying on the traditional bank account system. A single user can manage multiple accounts of different types.

[0057] "Account": usually refers to a bank account, which is a vehicle opened by a bank for customers to conduct business such as fund receipt and payment and settlement. It includes types such as savings accounts and settlement accounts. It is closely linked to personal identity information and the banking system, complies with financial regulatory requirements, and is used to manage customer funds and conduct various banking business operations.

[0058] "Payment Tokenization": A technical system that uses payment tokens to replace sensitive account information (such as bank card numbers) to ensure data security.

[0059] “Token”: A unique identifier used to replace the original account information and form a mapping relationship with the real account.

[0060] "HCE (Host Card Emulation) mode" is a payment technology mode that simulates smart card functions through software. In HCE mode, the generation, management and transmission of payment tokens do not depend on hardware security modules (such as the security chip in SE mode), but are implemented through the main processor of the mobile device and the software layer.

[0061] "EMV Specifications": This is a specification level in the EMV standard system released by the standardization organization EMVCo. It includes a series of EMV specifications that card organizations, acquiring banks, issuing banks, POS manufacturers, and card manufacturers in the payment industry chain must follow.

[0062] like Figure 1 The diagram shown is a flowchart illustrating a cross-border contactless payment method provided in an embodiment of this application. The method is executed by a payment tokenization system and includes the following steps:

[0063] Step S101: Receive a cross-border payment binding request initiated by the user through the e-wallet application, which includes the identifier of the target overseas contactless payment scenario.

[0064] This step marks the beginning of the user's card binding process. The user, within their domestic e-wallet application, proactively initiates a binding request for contactless payments made overseas. This binding request is sent by the e-wallet application to the Token Service Provider (TSP). The core information in this request is the target overseas contactless payment scenario identifier, which clarifies the network environment the user wishes to use the payment function, such as "overseas Mastercard contactless scenario." The Token Service Provider receives this request as the basis for subsequently generating a specific payment token.

[0065] Step S102: In response to the cross-border payment binding request, generate a payment token for the user's unique identity that is compatible with the target overseas contactless payment scenario, and bind the payment token to the account associated with the unique identity.

[0066] In this embodiment, after receiving and verifying the binding request, the payment tokenization system performs the following two key actions:

[0067] Generate a suitable payment token: The payment tokenization system does not generate a token for the user's specific bank card, but rather for the user's "unique identity" (such as a real-name authentication ID or a wallet unique ID). More importantly, in this embodiment, this payment token is dynamically generated based on the "target overseas contactless payment scenario" specified in step S101. For example, if the scenario is the Mastercard network, the system will generate a token that conforms to the Mastercard BIN segment rules. This "scenario-based dynamic token generation" ensures that the subsequently generated virtual card can be correctly identified by the target overseas network.

[0068] Establishing a binding relationship: The payment tokenization system associates the newly generated payment token with the user's unique identity. Since this user identity is already associated with all their payment methods (such as multiple bank cards, wallet balance, third-party payment channels, etc.) within their e-wallet, this step effectively binds the token to the user's entire payment capability system, rather than a single bank card.

[0069] Step S103: Return the payment token and virtual card generation technical parameters to the e-wallet application so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card to make contactless payments overseas.

[0070] Once the binding is complete, the payment tokenization system returns the generated payment token, along with the technical parameters required to generate the virtual card (such as transaction keys and personal information scripts), to the user's e-wallet application. Upon receiving this information, the e-wallet application uses HCE (Host Coin Encryption) technology to generate a virtual card at the mobile software level. This virtual card contains a payment token compliant with overseas network standards, enabling it to be correctly recognized and interacted with on contactless payment acceptance devices (such as POS machines) overseas.

[0071] Step S104: Receive the overseas contactless payment transaction request initiated by the user through the virtual card, wherein the transaction request contains the payment token.

[0072] This step leads to the actual transaction. At an overseas merchant, the user opens their e-wallet application and taps their phone against a contactless payment terminal to make a "card tap" payment. At this time, the HCE virtual card on the phone sends a transaction request containing a payment token to the terminal via NFC. This transaction request is then routed through the overseas card organization network (such as Mastercard). Because the token's format (such as the BIN segment) conforms to the network's specifications, it can be correctly identified and routed to the domestic clearing network and payment tokenization system.

[0073] Step S105: De-mark the payment token and parse it to obtain the user's unique identity identifier.

[0074] After receiving a transaction request routed from an overseas network, the core task of the payment tokenization system is to "de-tokenize" the payment token. This means the system queries its internal mapping relationship to securely parse and restore the temporary token used for the transaction, identifying the original information it is bound to—the user's unique identifier (user ID). This process decouples transaction data from the user's real account, ensuring the security of the user's sensitive information.

[0075] Step S106: Send the payment instruction containing the unique identifier to the corresponding e-wallet system. The e-wallet system will determine one or more accounts associated with the unique identifier to deduct funds according to preset deduction rules or the user's real-time selection, so as to complete the payment.

[0076] After de-tokenizing to obtain the user's identity, the payment tokenization system forwards the payment instruction containing that identity information to the corresponding e-wallet system. Upon receiving the instruction, the e-wallet system sends a deduction instruction to the final determined actual payment channel (such as a bank) to complete the transaction.

[0077] In one embodiment of this application, the account associated with the unique identifier includes at least one of a bank card, a wallet balance account, or a third-party payment channel.

[0078] As described above, the cross-border contactless payment method proposed in this application breaks through the limitations of traditional tokenization, which is limited to bank cards. By using user-based tokenization, payment tokens are bound to user identities, rather than single bank cards. This integrates multiple funding sources within the e-wallet, such as bank cards, wallet balance accounts, and third-party payment channels. When users make payments overseas, the system can flexibly utilize the optimal payment channel based on preset rules or real-time selection, meeting diverse payment needs. Simultaneously, this application, through scenario-based dynamic token generation technology, can dynamically generate payment tokens that conform to the technical specifications (such as BIN segment rules) of the target overseas payment network and region. This solves the format compatibility problem between the domestic e-wallet account system and different overseas card organization networks, enabling virtual cards based on HCE technology to be seamlessly recognized and accepted by overseas devices, significantly shortening the adaptation cycle for accessing new overseas networks. Finally, users only need to bind their entire e-wallet account system (rather than a single bank card) once to apply it to overseas contactless payments, avoiding the hassle of repeatedly performing the cumbersome card binding process for multiple bank cards. When making a payment, the system can intelligently select the optimal channel, improving the convenience and success rate of the payment, and seamlessly connecting with the mainstream "tap to pay" habit overseas.

[0079] In one embodiment of this application, the step S102 above, which generates a payment tag for the user's unique identifier that is compatible with the target overseas contactless payment scenario, specifically includes: adapting the corresponding BIN segment rules according to the payment network type and / or target region contained in the target overseas contactless payment scenario identifier, so as to generate a payment tag that conforms to the payment network technical specifications.

[0080] The core of this step lies in the dynamic generation of tokens based on the scenario. The payment tokenization system first parses the target overseas contactless payment scenario identifier received in step S101. This identifier contains crucial contextual information, most importantly the payment network type (e.g., Mastercard, Visa) and / or the target region. The payment tokenization system has a pre-configured library of technical specifications corresponding to different international card organization networks (payment network types) and regions. A key specification is the "BIN segment rule." The BIN (Bank Identification Number) is the first few digits of a bank card number, used to identify the issuing institution and card type. Different card organizations (e.g., Mastercard usually starts with 5, Visa with 4) have their own exclusive BIN segment ranges. When the system identifies the scenario identifier as "overseas Mastercard contactless scenario," it automatically calls the Mastercard network's BIN segment rule from the rule library. Similarly, if the scenario is the Visa network, the system will match the Visa BIN segment rule.

[0081] After the correct BIN segment rules are determined, the payment tokenization system dynamically generates a complete payment token. This token will strictly adhere to the technical specifications of the target payment network (such as the EMVCo specification) in terms of format.

[0082] Finally, the payment tokenization system establishes a secure mapping relationship between this newly generated payment token, which conforms to overseas scenario standards, and the user's unique identifier (rather than a specific bank card) in its internal database.

[0083] This application addresses a core pain point in traditional solutions through this step: the "format compatibility problem" between the account system of domestic e-wallets (usually not in the form of bank card numbers) and the bank card number system of overseas card organization networks. The generated payment token acts as a translator or adapter; externally (to overseas accepting devices and overseas payment networks), it appears as a standard, recognizable card number, while internally (to the payment tokenization system and e-wallet system), it uniquely points to a specific user identity within the country. This enables subsequent virtual cards generated based on HCE technology to be seamlessly and correctly recognized and accepted by overseas devices.

[0084] In another embodiment of this application, after the e-wallet system determines the deduction account according to preset deduction rules or the user's real-time selection, it further includes: dynamically triggering at least one identity verification step, including device fingerprint verification, biometric verification, or SMS verification code verification, based on the transaction amount, device environment, or user behavior habits.

[0085] The key to this step is dynamically adjusting the verification strength. The e-wallet system comprehensively analyzes the risk level of the current transaction and then decides whether and how strong additional identity verification is needed. This judgment is mainly based on the following dimensions: transaction amount, device environment, and user behavior habits, which are explained below:

[0086] Transaction Amount: For small transactions, the e-wallet system will determine them as low-risk and thus adopt silent or contactless verification methods. For example, it may rely solely on device fingerprint verification, where the backend verifies whether the device initiating the transaction is the user's frequently used device (by comparing phone hardware information, login status, IP address, etc.). If a match is found, the transaction is directly approved without any additional user action. However, for large transactions, such as when the transaction amount exceeds a preset threshold, the e-wallet system will determine that the risk has increased and will proactively trigger a stronger verification method requiring user interaction. The most common methods are biometric verification (such as fingerprints, Face ID) or requiring the user to enter an SMS verification code.

[0087] Device Environment: The e-wallet system assesses the security and trustworthiness of the device environment initiating the transaction. This includes factors such as whether it's the user's frequently used mobile phone, whether they are in a familiar geographical location, and whether the network environment (Wi-Fi / cellular network) is functioning correctly. If an abnormal environment is detected, such as logging in from an unfamiliar country or region, or using a different device for payment (i.e., a different device or outside the usual time of day), even if the transaction amount is small, the system may classify it as a high-risk transaction and initiate secondary verification, such as requiring a mandatory SMS verification code, to confirm that the operator is indeed the user.

[0088] User Behavior Habits: The e-wallet system builds a user payment behavior model based on big data analysis, including typical payment times, spending preferences, and transaction frequency. If a transaction significantly deviates from a user's usual behavior pattern (for example, a user who usually only makes small purchases during the day suddenly initiates a large transaction in the middle of the night), the system will consider this a potentially abnormal transaction and trigger additional identity verification steps to prevent fraud risks.

[0089] The above mechanism does not use a single verification method, but rather a dynamic combination of "at least one". The e-wallet system can flexibly choose according to the risk level.

[0090] This embodiment achieves a balance between security and user experience. In low-risk scenarios, it allows users to pass through seamlessly as much as possible, improving payment smoothness. In high-risk scenarios, it intervenes decisively, using multiple verification methods to ensure the authenticity of the user's identity and the security of the transaction, thereby comprehensively protecting the security of cross-border contactless transactions.

[0091] In one embodiment of this application, in step S103 above, the virtual card generated by the e-wallet application based on the payment token and the virtual card generation technical parameters embeds a scene identifier associated with the payment token. The scene identifier includes the target network type, validity period and / or target region. Correspondingly, the above method further includes: verifying the consistency between the payment token and the scene identifier embedded in the virtual card before performing de-marking processing on the payment token.

[0092] This step occurs during the actual transaction phase (after step S104 and before step S105). When the payment tokenization system receives a payment transaction request routed from an overseas network, it does not immediately perform detoxification, but instead executes a preliminary verification step.

[0093] In step S103, when the e-wallet application generates an HCE virtual card based on the payment token and related parameters, it also embeds a "context identifier" into the virtual card's data. This context identifier contains specific contextual information about the authorized use of the token, mainly including the "target network type" (such as Mastercard), "validity period," and / or "target region." When a user makes a payment, this HCE virtual card data embedded with the context identifier is sent to the payment tokenization system as part of the transaction request. Simultaneously, the transaction request also includes the core payment token itself.

[0094] Upon receiving a request, the Payment Tokenization System (TSP) simultaneously parses the "scenario identifier" embedded in the HCE virtual card data and the independent payment token. The system performs a cross-comparison to verify whether the scenarios represented by these two information sources are completely consistent. Specifically, the system checks: whether the actual network initiating the transaction (e.g., the request was routed from the Mastercard network) matches the "target network type" marked in the HCE virtual card data; whether the current transaction time is within the "validity period" marked in the HCE virtual card data; and / or whether the region where the current transaction occurred matches the "target region" marked in the HCE virtual card data.

[0095] If the payment token and the scenario identifier in the HCE virtual card match perfectly, it proves that the transaction was initiated in a legitimate and authorized scenario. The system will then proceed to the next step S105, which involves de-tokenizing the token and completing the payment process.

[0096] If the two are inconsistent (for example, a token generated for a Mastercard scenario is used in the Visa network), the system will determine that this is an abnormal or illegal transaction. This could mean that the token has been intercepted and maliciously replayed in other unauthorized payment networks. In this case, the system will reject the transaction and suspend the payment process, thereby effectively preventing the token from being illegally used on other contactless networks.

[0097] This embodiment adds a layer of dynamic, context-based access control to payment tokens by embedding a "scene identifier" in the virtual card and verifying it during transactions. It ensures that a token generated for a specific purpose (specific network, specific time, specific location) can only be used within that preset scene, greatly enhancing payment security and effectively preventing cross-network, cross-scene fraud risks.

[0098] like Figure 2 The diagram shown is a structural schematic of a cross-border contactless payment device provided in an embodiment of this application. This device is applied to a payment tokenization system and includes:

[0099] The binding request receiving unit 210 is used to receive cross-border payment binding requests initiated by users through e-wallet applications, which contain the identifier of the target overseas contactless payment scenario.

[0100] Binding unit 220 is used to respond to the cross-border payment binding request, generate a payment token for the user's unique identity that is compatible with the target overseas contactless payment scenario, and bind the payment token to the account associated with the unique identity.

[0101] The binding feedback unit 230 is used to return the payment token and virtual card generation technical parameters to the e-wallet application, so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card to make contactless payments overseas.

[0102] The transaction request receiving unit 240 is used to receive the overseas contactless payment transaction request initiated by the user through the virtual card, wherein the transaction request includes the payment token.

[0103] The de-marking unit 250 is used to de-mark the payment token and parse it to obtain the user's unique identity identifier.

[0104] The payment instruction sending unit 260 is used to send a payment instruction containing the unique identifier to the corresponding e-wallet system. The e-wallet system then determines one or more accounts associated with the unique identifier to deduct funds according to preset deduction rules or the user's real-time selection, thereby completing the payment.

[0105] In one embodiment of this application, the step of the binding unit 220 generating a payment token adapted to the target overseas contactless payment scenario for the user's unique identity specifically includes:

[0106] Based on the payment network type and / or target region contained in the target overseas contactless payment scenario identifier, the corresponding BIN segment rules are adapted to generate a payment tag that conforms to the payment network technical specifications.

[0107] In one embodiment of this application, the virtual card is a virtual card generated based on host card emulation technology.

[0108] In one embodiment of this application, the above-mentioned device further includes: a secondary verification unit, which is used to further dynamically trigger at least one identity verification step, including device fingerprint verification, biometric verification, or SMS verification code verification, based on the transaction amount, device environment, or user behavior habits, after the electronic wallet system determines the deduction account according to the preset deduction rules or the user's real-time selection.

[0109] In one embodiment of this application, the account associated with the unique identifier includes at least one of a bank card, a wallet balance account, or a third-party payment channel.

[0110] In one embodiment of this application, the virtual card embeds a scene identifier associated with the payment token, the scene identifier including a target network type, validity period and / or target region; the device further includes: a payment token verification unit, used to verify the consistency between the payment token and the scene identifier embedded in the virtual card before performing de-marking processing on the payment token.

[0111] For detailed descriptions of the above-mentioned units and modules, please refer to the corresponding descriptions in the foregoing method embodiments, which will not be repeated here.

[0112] As described above, the cross-border contactless payment device proposed in this application breaks through the limitations of traditional tokenization, which is limited to bank cards. By using user-based tokenization, it binds payment tokens to user identities, rather than a single bank card. This integrates multiple funding sources within the e-wallet, such as bank cards, wallet balance accounts, and third-party payment channels. When users make payments overseas, the system can flexibly utilize the optimal payment channel based on preset rules or real-time selection, meeting diverse payment needs. Simultaneously, this application, through scenario-based dynamic token generation technology, can dynamically generate payment tokens that conform to the technical specifications (such as BIN segment rules) of the target overseas payment network and region. This solves the format compatibility problem between the domestic e-wallet account system and different overseas card organization networks, enabling virtual cards based on HCE technology to be seamlessly recognized and accepted by overseas devices, significantly shortening the adaptation cycle for accessing new overseas networks. Finally, users only need to bind their entire e-wallet account system (rather than a single bank card) once to apply it to overseas contactless payments, avoiding the hassle of repeatedly performing the cumbersome card binding process for multiple bank cards. When making a payment, the system can intelligently select the optimal channel, improving the convenience and success rate of the payment, and seamlessly connecting with the mainstream "tap to pay" habit overseas.

[0113] like Figure 3 The diagram shown is a schematic representation of a cross-border contactless payment system provided in an embodiment of this application. The system includes: a domestic e-wallet APP 301, an overseas contactless payment device 302, an overseas card organization network 303, a domestic card organization network 304, a payment tokenization system 305, a domestic clearing network 306, an e-wallet institution 307, and a card issuing institution 308.

[0114] The payment tokenization system 305 is used to receive a cross-border payment binding request initiated by a user through a domestic e-wallet APP 301, which contains an identifier of a target overseas contactless payment scenario; respond to the cross-border payment binding request, generate a payment token for the user's unique identity that is compatible with the target overseas contactless payment scenario, and bind the payment token to the account associated with the unique identity; and return the payment token and virtual card generation technical parameters to the e-wallet application, so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card to make overseas contactless payments;

[0115] The overseas contactless payment device 302 is used to forward the transaction request of the domestic e-wallet APP 301 to the overseas card organization network 303, wherein the transaction request includes the payment token and transaction data;

[0116] The foreign card organization network 303 is used to identify the BIN segment in the payment token to confirm the network type, and after confirming that the network type is correct, routes the transaction request to the domestic card organization network 304;

[0117] Domestic card organization network 304 is used to send the transaction request to the payment tokenization system 305;

[0118] The payment tokenization system 305 is also used to receive the transaction request, perform detoxification processing on the payment token, parse it to obtain the user's unique identity identifier; and send the payment instruction containing the unique identity identifier to the corresponding e-wallet institution 307 through the domestic clearing network 306;

[0119] Electronic wallet institution 307 is used to determine one or more accounts associated with the unique identifier for deduction based on the payment instruction to complete the payment, and these associated accounts belong to card issuer 308.

[0120] like Figure 4 The diagram shown is a schematic diagram of the entire process of cross-border contactless payment provided in an embodiment of this application, where the dotted line represents the card binding and registration process, and the solid line represents the transaction process.

[0121] Step 1: Within their e-wallet application, the user selects a target overseas contactless payment scenario (e.g., "overseas Mastercard contactless scenario") and initiates a card binding request. This request essentially applies for a payment token for the user's e-wallet ID (rather than a specific bank card).

[0122] Step 2: The request is sent to the Payment Tokenization System (TSP). The TSP dynamically generates a payment token that conforms to the card organization's technical specifications, based on the user's selected scenario (e.g., Mastercard network). This token might be prefixed with the Mastercard BIN segment (usually starting with 5). Simultaneously, the system establishes a unique mapping between this token and the user's e-wallet ID, and returns the generated token and related virtual card parameters (such as personalized data) to the e-wallet application. Upon receiving this information, the e-wallet application loads and generates a virtual card based on HCE technology on the user's mobile device and displays a message indicating successful card binding.

[0123] Step 3: At a merchant overseas that supports the corresponding card organization (such as Mastercard), the user opens the e-wallet application and taps their phone against the contactless payment device (POS machine) to make a payment. At this time, the phone will send the virtual card information containing the payment token to the overseas merchant's POS machine via NFC.

[0124] Step 4: After obtaining the payment information from the POS machine, the overseas acquiring institution identifies it as a card network-based transaction. It then routes the transaction request, which includes the payment token, through the corresponding card network's overseas network (such as the Mastercard network).

[0125] Step 5: The card organization's overseas network confirms the network type is correct according to the BIN segment rules of the token, and then identifies that this is a transaction from within the country. Therefore, it routes the transaction request to its network within the country and finally forwards it to the clearing network within the country (NUCC in this example).

[0126] Step 6: The domestic clearing network sends the transaction request to the Payment Tokenization System (TSP). The TSP de-tokenizes the received payment token, that is, it parses out the domestic e-wallet user ID that the token actually maps to.

[0127] Step 7: Return this user ID along with the original transaction information to the clearing network.

[0128] Steps 8 & 9: The domestic clearing network forwards the payment instruction containing the e-wallet user ID to the corresponding wallet institution.

[0129] Step 10: After receiving the payment instruction, the wallet institution determines the final payment method based on the system's built-in deduction rules (such as minimum transaction fees, user preferences) or the user's real-time selection. This payment method can be the user's linked bank card from Issuing Institution 1, Issuing Institution 2, or the user's wallet balance account. Before executing the deduction, the system may dynamically trigger additional identity verification (such as fingerprint or SMS verification code) based on factors such as the transaction amount and device environment. After successful deduction, the entire payment process is complete.

[0130] As described above, the cross-border contactless payment system proposed in this application breaks through the limitations of traditional tokenization, which is limited to bank cards. By using user-based tokenization, it binds payment tokens to user identities, rather than a single bank card. This integrates multiple funding sources within the e-wallet, such as bank cards, wallet balance accounts, and third-party payment channels. When users make payments overseas, the system can flexibly utilize the optimal payment channel based on preset rules or real-time selection, meeting diverse payment needs. Simultaneously, this application, through scenario-based dynamic token generation technology, can dynamically generate payment tokens that conform to the technical specifications (such as BIN segment rules) of the target overseas payment network and region. This solves the format compatibility problem between the domestic e-wallet account system and different overseas card organization networks, enabling virtual cards based on HCE technology to be seamlessly recognized and accepted by overseas devices, significantly shortening the adaptation cycle for accessing new overseas networks. Finally, users only need to bind their entire e-wallet account system (rather than a single bank card) once to apply it to overseas contactless payments, avoiding the hassle of repeatedly performing the cumbersome card binding process for multiple bank cards. When making a payment, the system can intelligently select the optimal channel, improving the convenience and success rate of the payment, and seamlessly connecting with the mainstream "tap to pay" habit overseas.

[0131] Figure 5 This is a schematic diagram of the electronic device provided in the embodiments of this application. Figure 5 The illustrated electronic device is a general-purpose data processing apparatus, comprising a general-purpose computer hardware structure, including at least a processor 801 and a memory 802. The processor 801 and memory 802 are connected via a bus 803. The memory 802 is adapted to store one or more instructions or programs executable by the processor 801. These instructions or programs are executed by the processor 801 to implement the steps of the aforementioned cross-border contactless payment method.

[0132] The processor 801 described above can be a standalone microprocessor or a collection of one or more microprocessors. Thus, the processor 801 executes commands stored in the memory 802, thereby performing the method flow described in the embodiments of this application to process data and control other devices. The bus 803 connects the aforementioned components together, and also connects these components to the display controller 804, the display device, and the input / output (I / O) device 805. The input / output (I / O) device 805 can be a mouse, keyboard, modem, network interface, touch input device, motion-sensing input device, printer, and other devices known in the art. Typically, the input / output (I / O) device 805 is connected to the system via an input / output (I / O) controller 806.

[0133] The memory 802 can store software components, such as an operating system, a communication module, an interaction module, and application programs. Each of the modules and application programs described above corresponds to a set of executable program instructions that perform one or more functions and the methods described in the embodiments of the invention.

[0134] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described cross-border contactless payment method.

[0135] In summary, the cross-border contactless payment method, device, and system proposed in this application break through the limitations of traditional tokenization, which is limited to bank cards. By using user-based tokenization, payment tokens are bound to user identities, rather than single bank cards. This allows for the integration of multiple funding sources within the e-wallet, such as bank cards, wallet balance accounts, and third-party payment channels. When users make payments overseas, the system can flexibly utilize the optimal payment channel based on preset rules or real-time selection, meeting diverse payment needs. Furthermore, this application utilizes scenario-based dynamic token generation technology to dynamically generate payment tokens that conform to the technical specifications (such as BIN segment rules) of the target overseas payment network and region. This solves the format compatibility issue between the domestic e-wallet account system and different overseas card organization networks, enabling virtual cards based on HCE technology to be seamlessly recognized and accepted by overseas devices, significantly shortening the adaptation cycle for accessing new overseas networks. Finally, users only need to bind their entire e-wallet account system (rather than a single bank card) once for overseas contactless payments, avoiding the hassle of repeatedly performing the cumbersome card binding process for multiple bank cards. When making a payment, the system can intelligently select the optimal channel, improving the convenience and success rate of the payment, and seamlessly connecting with the mainstream "tap to pay" habit overseas.

[0136] Preferred embodiments of this application have been described above with reference to the accompanying drawings. Many features and advantages of these embodiments are apparent from this detailed description, and therefore the claims are intended to cover all such features and advantages of these embodiments that fall within their true spirit and scope. Furthermore, since many modifications and alterations will readily occur to those skilled in the art, the embodiments of this application are not intended to be limited to the precise structures and operations illustrated and described, but rather to encompass all suitable modifications and equivalents falling within their scope.

[0137] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0138] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0139] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0140] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0141] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A cross-border contactless payment method, characterized in that, The method is applied to a payment tokenization system, and the method includes: Receive cross-border payment binding requests initiated by users through e-wallet applications, which contain the identifier of the target overseas contactless payment scenario; In response to the cross-border payment binding request, a payment token adapted to the target overseas contactless payment scenario is generated for the user's unique identity, and the payment token is bound to the account associated with the unique identity; The payment token and virtual card generation technical parameters are returned to the e-wallet application so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card for overseas contactless payment. The virtual card embeds a scene identifier associated with the payment token, and the scene identifier includes the target network type, validity period and / or target region. Receive the overseas contactless payment transaction request initiated by the user through the virtual card, wherein the transaction request includes the payment token; Verify the consistency between the payment token and the scene identifier embedded in the virtual card; After the consistency verification is passed, the payment token is de-tokenized and parsed to obtain the user's unique identity identifier; The payment instruction containing the unique identifier is sent to the corresponding e-wallet system. The e-wallet system then determines one or more accounts associated with the unique identifier to deduct funds according to preset deduction rules or the user's real-time selection, in order to complete the payment. The step of generating a payment token for the user's unique identifier that is compatible with the target overseas contactless payment scenario specifically includes: Based on the payment network type and / or target region contained in the target overseas contactless payment scenario identifier, the corresponding BIN segment rules are adapted to generate a payment tag that conforms to the technical specifications of the corresponding payment network.

2. The cross-border contactless payment method as described in claim 1, characterized in that, The virtual card is generated based on host card emulation technology.

3. The cross-border contactless payment method as described in claim 1, characterized in that, After the e-wallet system determines the deduction account according to the preset deduction rules or the user's real-time selection, it further dynamically triggers at least one identity verification step, including device fingerprint verification, biometric verification, or SMS verification code verification, based on the transaction amount, device environment, or user behavior habits.

4. The cross-border contactless payment method as described in claim 1, characterized in that, The account associated with the unique identifier includes at least one of a bank card, a wallet balance account, or a third-party payment channel.

5. A cross-border contactless payment device, characterized in that, The device is used in a payment tokenization system, and the device includes: The binding request receiving unit is used to receive cross-border payment binding requests initiated by users through e-wallet applications, which contain the identifier of the target overseas contactless payment scenario; The binding unit is used to respond to the cross-border payment binding request, generate a payment token for the user's unique identity that is compatible with the target overseas contactless payment scenario, and bind the payment token to the account associated with the unique identity. A binding feedback unit is used to return the payment token and virtual card generation technical parameters to the e-wallet application, so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card to make contactless payments overseas. The virtual card embeds a scene identifier associated with the payment token, and the scene identifier includes the target network type, validity period and / or target region. A transaction request receiving unit is configured to receive an overseas contactless payment transaction request initiated by the user through the virtual card, wherein the transaction request includes the payment token; A payment token verification unit is used to verify the consistency between the payment token and the scene identifier embedded in the virtual card before the payment token is de-tokenized. The de-marking unit is used to de-mark the payment token and parse it to obtain the user's unique identity identifier; The payment instruction sending unit is used to send a payment instruction containing the unique identifier to the corresponding e-wallet system, which then determines one or more accounts associated with the unique identifier to deduct funds according to preset deduction rules or the user's real-time selection, in order to complete the payment. The binding unit generates a payment tag that is compatible with the target overseas contactless payment scenario for the user's unique identity. Specifically, it includes: adapting the corresponding BIN segment rules according to the payment network type and / or target region contained in the target overseas contactless payment scenario identifier to generate a payment tag that conforms to the technical specifications of the corresponding payment network.

6. A cross-border contactless payment system, characterized in that, The system includes: domestic e-wallets, overseas contactless payment devices, overseas card organization networks, domestic card organization networks, payment tokenization systems, domestic clearing networks, e-wallet institutions, and card issuers; The payment tokenization system is used to receive a cross-border payment binding request initiated by a user through an e-wallet, which includes a target overseas contactless payment scenario identifier; respond to the cross-border payment binding request, generate a payment token adapted to the target overseas contactless payment scenario for the user's unique identity, and bind the payment token to the account associated with the unique identity; and return the payment token and virtual card generation technical parameters to the e-wallet application, so that the e-wallet application can generate a virtual card based on the payment token and the virtual card generation technical parameters, and use the virtual card for overseas contactless payment, wherein the virtual card embeds a scenario identifier associated with the payment token, and the scenario identifier includes the target network type, validity period and / or target region; The payment tokenization system generates a payment token that is compatible with the target overseas contactless payment scenario for the user's unique identity. Specifically, it includes: adapting the corresponding BIN segment rules according to the payment network type and / or target region contained in the target overseas contactless payment scenario identifier to generate a payment token that conforms to the technical specifications of the corresponding payment network. The overseas contactless payment device is used to forward the transaction request from the domestic e-wallet to the overseas card organization network, and the transaction request includes the payment token and transaction data; The foreign card organization network is used to identify the BIN segment in the payment token to confirm the network type, and after confirming that the network type is correct, to route the transaction request to the domestic card organization network; The domestic card organization network is used to send the transaction request to the payment tokenization system; The payment tokenization system is also used to receive the transaction request, verify the consistency between the payment token and the scene identifier embedded in the virtual card, and after the consistency verification is passed, perform de-tokenization processing on the payment token to parse out the user's unique identity identifier; and send the payment instruction containing the unique identity identifier to the corresponding e-wallet institution through the domestic clearing network. The electronic wallet institution is used to determine one or more accounts associated with the unique identifier for deduction based on the payment instruction, so as to complete the payment.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-4.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-4.

Images