An out-card automatic identification method and system suitable for cross-border scenarios

Abstract

The present application relates to payment data processing technical field, specifically, it is a kind of external card automatic identification method suitable for cross-border scene, it includes the following steps: by loading terminal parameter, key certificate and rate configuration, establish PC / SC communication connection with card reader, initially using card reader to collect chip data, obtain candidate AID list by parsing PSE / PPSE, card type is classified according to AID-BIN / IIN-Track2 process, risk assessment is carried out using local rules and cloud BIN service, the card information extracted is structured transaction message with selected payment network, and the response result is parsed after being submitted to the receiving bank, the transaction is closed loop by offline cache, and the standardized transaction result and return data are obtained.The present application solves the problems that traditional external card recognition relies on manual card selection and payment network, card type database update lags behind, leading to difficulty in adapting to new card types, and existing algorithms lack dynamic updating, multidimensional verification and cannot adapt to special protocols.

Description

Technical Field

[0001] This invention belongs to the field of payment data processing technology, specifically relating to a method and system for automatic identification of foreign cards in cross-border scenarios. Background Technology

[0002] With the booming development of the inbound tourism market and the continued recovery of cross-border consumption, the demand for foreign card payments has experienced explosive growth. However, traditional foreign card recognition methods have revealed several shortcomings in addressing this growth trend. First, traditional methods rely heavily on manual operation to select card types and payment networks. This requires cashiers to possess professional financial knowledge and extensive practical experience, increasing merchant training costs and increasing the risk of errors due to human error, thus affecting payment accuracy and efficiency. Second, traditional POS machines suffer from severe lag in card type database updates. Due to the long update cycle, newly added card types cannot be recognized and adapted by the system in a timely manner, resulting in a large number of transactions failing due to card type mismatch, causing significant inconvenience to both merchants and consumers. Third, traditional recognition methods are limited in scope, relying solely on card number range matching to identify card types. For some special card types, such as those with unique designs or functions, accurate identification is difficult, further reducing the payment success rate.

[0003] While some existing recognition algorithms can achieve basic card type matching, they have significant shortcomings. They lack dynamic update mechanisms, failing to keep up with changes in card type information; their multi-dimensional verification capabilities are weak, resulting in an accuracy rate below 90%. Furthermore, current technologies cannot adapt to the specific protocol requirements of domestic joint venture settlement companies, such as the special case where MasterCard requires settlement through a domestic joint venture. These problems not only severely reduce the overall efficiency of cross-border payments but also significantly impact the consumer experience of foreign users, becoming a major obstacle for small and medium-sized merchants expanding their international business. Therefore, developing an advanced algorithm for automatic foreign card recognition that covers multiple card types, updates in real time, achieves high accuracy, and adapts to specific protocols is urgently needed. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides an automatic foreign card identification method and system suitable for cross-border scenarios. It solves the problems of traditional foreign card identification relying on manual card selection and payment network compatibility, high training costs and susceptibility to errors, lagging card database updates leading to difficulties in adapting to new card types, limited identification dimensions making it difficult to handle special card types, and existing algorithms lacking dynamic updates, multi-dimensional verification, and compatibility with dedicated protocols. To achieve the above objectives, this invention adopts the following technical solution: The aforementioned method for automatic identification of foreign cards in cross-border scenarios includes the following steps: Establishing a PC / SC communication connection with the card reader by loading terminal parameters, key certificates, and rate configurations; initializing the environment to obtain a fully configured operating environment; collecting chip data using the card reader; verifying card number validity using the Luhn algorithm; parsing the validity period and brand rules; extracting legitimate card information to obtain valid card data after preliminary verification; obtaining a candidate AID list by parsing PSE / PPSE; classifying card types according to the AID-BIN / IIN-Track2 process; configuring priority strategies for co-branded cards to obtain classification results for card organizations, issuing banks, and card types; conducting risk assessment using local rules and cloud BIN services; de-identifying sensitive data; encrypting and storing the data to obtain risk assessment results and preprocessed data; comparing channel fees, clearing exchange rates, and transaction delays by calling the cloud rate API; automatically selecting the network with the lowest cost to obtain the optimal payment path selection result; constructing a transaction message with the extracted card information and the selected payment network; submitting it to the acquiring bank; parsing the response result; ensuring transaction closure through offline caching to obtain standardized transaction results and receipt data.

[0005] Furthermore, the process of establishing a PC / SC communication connection with the card reader by loading terminal parameters, key certificates, and rate configurations, initializing the environment, and obtaining a fully configured operating environment includes the following steps: extracting key certificates, rate rules, and channel priority data by loading the terminal's preset parameter configuration file; establishing a two-way authentication connection with the smart card reader using the PC / SC communication protocol, completing device initialization enumeration and ATR parameter parsing; synchronously verifying the validity of the key and loading risk control threshold parameters; and conducting joint debugging and verification of the rate configuration with the cloud service interface to obtain a system operating environment that includes a complete security authentication system, dynamic rate update capabilities, and device communication guarantees.

[0006] Furthermore, the process of using a card reader to collect chip data, utilizing the Luhn algorithm to verify the card number's validity, parsing the expiration date and brand rules, and extracting legitimate card information to obtain valid card data after preliminary verification includes the following steps: using a smart card reader compatible with the PC / SC protocol to collect the bank card's chip data, which includes the card number, expiration date, and information within the chip; obtaining the application identifier and application name from the chip card using EMV standard commands; verifying the validity of the collected card number using the Luhn algorithm to exclude invalid and counterfeit data; extracting the expiration date information and verifying its format to ensure the card has not expired; obtaining the first few digits of the card number; and verifying the card number's length and prefix according to the BIN and brand rules to obtain valid card data after preliminary verification.

[0007] Furthermore, the process of obtaining a candidate AID list by parsing PSE / PPSE, classifying card types according to the AID-BIN / IIN-Track2 process, configuring a priority strategy for co-branded cards, and obtaining classification results for card organizations, issuing banks, and card types includes the following steps: Based on the PSE / PPSE parsing results, obtain the priority of the candidate AID list, attempt to select the PPSE path, and if that fails, select the PSE path, recursively parsing the AID and application tag in the returned records; use the AID-BIN / IIN-Track2 three-level parsing process to classify card types, directly determining the card organization and issuing bank through the AID; when AID recognition fails, parse the BIN / IIN segment to determine the card organization, region, and issuing bank; when BIN / IIN does not match, perform fallback identification based on keywords in Track2 and the application name; for co-branded cards, automatically optimize according to the configured priority strategy to obtain classification results for card organizations, issuing banks, and card types.

[0008] Furthermore, the risk assessment using local rules and cloud-based BIN services, including sensitive data anonymization and encrypted storage, yields risk assessment results and preprocessed data. This process includes the following steps: matching local BIN rules, brand rules, and acceptance policies with card numbers, expiration dates, and brand elements; determining the card organization, card product, issuing country, and capability set through comprehensive judgment; conducting preliminary risk screening using blacklists, risk control thresholds, and industry restrictions to extract potential risk information; masking sensitive data such as PAN and Track2 fields in logs and callbacks, and outputting only the minimum necessary data to complete the anonymization operation; and storing the processed data in memory and persistently using encryption algorithms, setting access control policies to ensure security, thus obtaining valid data results after risk assessment and preprocessing.

[0009] Furthermore, the step of automatically selecting the network with the lowest cost by calling the cloud-based rate API to compare channel fees, clearing exchange rates, and transaction latency to obtain the optimal payment path selection result includes the following steps: Receiving transaction amount, currency, and available payment network information, and obtaining real-time fee data for each payment network by calling a preset cloud-based rate query API; extracting and comparing the total fees, clearing exchange rates, and transaction latency parameters of different channels, and automatically selecting the payment network with the lowest cost and best response as the final transaction path; when some networks fail to return data or the interface malfunctions, performing a rollback process based on the default priority and local rate table, and then selecting the optimal payment path selection result.

[0010] Furthermore, the process of constructing a transaction message using the extracted card information and the selected payment network, submitting it to the acquiring bank, parsing the response result, and ensuring transaction closure through offline caching to obtain standardized transaction results and receipt data includes the following steps: Constructing a transaction request message including transaction amount, currency code, and terminal serial number using the extracted card information and the selected payment network; encrypting and signing the message; submitting the message to the preset acquiring bank and payment gateway; receiving the transaction authorization result returned by the bank through a real-time interface; extracting the response code, authorization number, and transaction reference number fields; parsing the status, which includes success, rejection, and exception; encapsulating the transaction result in a standard format, which includes status, voucher, channel, and cost tag information; and sending the transaction result back to the POS system; when submission fails or the network is interrupted, calling the offline caching module to locally encrypt and store the transaction data, and automatically resubmitting it after the network is restored to obtain standardized transaction results and receipt data.

[0011] The second aspect of this invention provides an automatic foreign card identification system suitable for cross-border scenarios. This system includes the following modules: an initialization module, used to establish a PC / SC communication connection with the card reader by loading terminal parameters, key certificates, and rate configurations, initializing the environment to obtain a fully configured operating environment; a preliminary verification module, used to collect chip data using the card reader, verify the card number validity using the Luhn algorithm, parse the validity period and brand rules, extract legitimate card information, and obtain valid card data after preliminary verification; and a deep parsing module, used to obtain a candidate AID list by parsing PSE / PPSE, and classify cards according to the AID-BIN / IIN-Track2 process. The system comprises four modules: a card classification module, a risk assessment module, and a transaction execution module. The first module configures priority strategies for common standard cards, resulting in classifications by card organization, issuing bank, and card type. The second module uses local rules and cloud-based BIN services to perform risk assessments, de-identifies sensitive data, encrypts and stores it, and obtains risk assessment results and pre-processed data. The third module compares channel fees, clearing rates, and transaction latency by calling a cloud-based rate API, automatically selecting the network with the lowest cost to obtain the optimal payment path. The fourth module constructs transaction messages using the extracted card information and the selected payment network, submits them to the acquiring bank, parses the response, and ensures transaction closure through offline caching, resulting in standardized transaction results and receipt data.

[0012] A third aspect of the present invention provides an automatic foreign card identification device suitable for cross-border scenarios. The automatic foreign card identification device for cross-border scenarios includes a memory and at least one processor. The memory stores instructions. The at least one processor invokes the instructions in the memory to cause the automatic foreign card identification device for cross-border scenarios to perform the steps of the automatic foreign card identification method for cross-border scenarios as described in any of the preceding claims.

[0013] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions, characterized in that, when executed by a processor, the instructions implement the steps of the automatic foreign card identification method applicable to cross-border scenarios as described in any one of the preceding claims.

[0014] In the technical solution provided by this invention, a PC / SC communication connection with the card reader is established by loading terminal parameters, key certificates, and rate configurations, and the environment is initialized to obtain a fully configured operating environment. The card reader collects chip data, uses the Luhn algorithm to verify the validity of the card number, parses the validity period and brand rules, extracts legal card information, and obtains valid card data after preliminary verification. A candidate AID list is obtained by parsing PSE / PPSE, and card types are classified according to the AID-BIN / IIN-Track2 process. Priority strategies are configured for co-standard cards to obtain classification results of card organization, issuing bank, and card type. Risk assessment is performed using local rules and cloud BIN services, sensitive data is anonymized, encrypted, and stored to obtain risk assessment results and preprocessed data. By calling the cloud rate API to compare channel fees, clearing exchange rates, and transaction delays, the network with the lowest cost is automatically selected to obtain the optimal payment path selection result. The extracted card information and the selected payment network are used to construct a transaction message, which is submitted to the acquiring bank and the response result is parsed. Offline caching ensures transaction closure and obtains standardized transaction results and receipt data. This invention solves the problems of traditional foreign card recognition relying on manual selection of card types and payment networks, high training costs and easy errors, lagging updates to the card type database leading to difficulty in adapting to new card types, single recognition dimensions making it difficult to deal with special card types, and existing algorithms lacking dynamic updates, multi-dimensional verification and inability to adapt to dedicated protocols. Attached Figure Description

[0015] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0016] Figure 1 This is a schematic diagram of the first embodiment of an automatic foreign card identification method applicable to cross-border scenarios in this invention.

[0017] Figure 2 This is a schematic diagram of a second embodiment of an automatic foreign card identification method applicable to cross-border scenarios in this invention.

[0018] Figure 3 This is a schematic diagram of a third embodiment of an automatic foreign card identification method applicable to cross-border scenarios in this invention.

[0019] Figure 4 This is a schematic diagram of the fourth embodiment of an automatic foreign card identification method applicable to cross-border scenarios in this invention.

[0020] Figure 5 This is a schematic diagram of the fifth embodiment of an automatic foreign card identification method applicable to cross-border scenarios in this invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0022] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0023] An automatic identification method for foreign cards applicable to cross-border scenarios, such as Figure 1 As shown, the process includes the following steps: First, by loading terminal parameters, key certificates, and rate configurations, a PC / SC communication connection with the card reader is established, the environment is initialized, and a fully configured operating environment is obtained. Second, the card reader collects chip data, uses the Luhn algorithm to verify card number validity, parses expiration dates and brand rules, extracts legitimate card information, and obtains valid card data after preliminary verification. Third, by parsing PSE / PPSE, a candidate AID list is obtained, card types are classified according to the AID-BIN / IIN-Track2 process, priority strategies are configured for co-standard cards, and classification results by card organization, issuing bank, and card type are obtained. Fourth, risk assessment is performed using local rules and cloud BIN services, sensitive data is anonymized, encrypted, and stored, resulting in risk assessment results and preprocessed data. Fifth, by calling the cloud rate API to compare channel fees, clearing exchange rates, and transaction latency, the network with the lowest cost is automatically selected, resulting in the optimal payment path selection. Sixth, the extracted card information and the selected payment network are used to construct a transaction message, which is submitted to the acquiring bank, and the response result is parsed. Offline caching ensures transaction closure, resulting in standardized transaction results and receipt data.

[0024] like Figure 2As shown, in this embodiment, by loading the terminal's preset parameter configuration file, the key certificate, rate rules, and channel priority data are extracted; a two-way authentication connection with the smart card reader is established using the PC / SC communication protocol to complete device initialization enumeration and ATR parameter parsing; the key validity is verified synchronously and the risk control threshold parameters are loaded; the rate configuration is integrated with the cloud service interface for joint debugging and verification to obtain a system operating environment that includes a complete security authentication system, dynamic rate update capability, and device communication guarantee.

[0025] This invention is responsible for establishing a connection with PC / SC-compatible smart card readers, completing the initialization of the card slot and card session (enumerating the reader, connecting, negotiating the protocol T=0 / T=1, obtaining the ATR), and providing the sending and response parsing of standard APDU commands. To improve cross-device and cross-card compatibility, the module has a built-in APDU automatic repair mechanism: when a typical error status word (such as 6Cxx, 61xx, 6700, 6A80, 6A82, etc.) is received or an **APDU case (Case 1 / 2 / 3 / 4)** is detected to be inconsistent with Lc / Le, the command is automatically reorganized (completing or correcting Lc / Le, executing GETRESPONSE according to 61xx, correcting Le for 6Cxx, automatically reverting to 8300 for EMVGPO, etc.), and retransmitted under idempotent and upper limit retry strategies to ensure stable read and write operations under different card organizations and reader firmware differences.

[0026] like Figure 3 As shown, in this embodiment, a smart card reader compatible with the PC / SC protocol is used to collect the chip data of the bank card. The chip data includes the card number, expiration date, and information within the chip. The application identifier and application name are obtained from the chip card using EMV standard commands. The collected card number is validated using the Luhn algorithm to exclude invalid and counterfeit data. The expiration date information is extracted and its format is verified to ensure that the card has not expired. The first few digits of the card number are obtained, and the card number length and prefix are verified according to the BIN and brand rules to obtain the valid card data after preliminary verification.

[0027] like Figure 4 As shown, in this embodiment, based on the PSE / PPSE parsing results, the priority of the candidate AID list is obtained, and the PPSE path is attempted. If it fails, the PSE path is selected, and the AID and application tag in the returned record are recursively parsed. A three-level parsing process of AID-BIN / IIN-Track2 is used for card type classification, and the card organization and issuing bank are directly determined by the AID. When AID recognition fails, the BIN / IIN segment is parsed to determine the card organization, region, and issuing bank. When BIN / IIN does not match, fallback identification is performed based on the keywords in Track2 and the application name. For co-branded cards, automatic optimization is achieved according to the configured priority strategy to obtain the classification results of card organization, issuing bank, and card type.

[0028] For example, in the case of unknown cards, the system automatically completes the following steps: "Application catalog discovery (PSE / PPSE) → Candidate AID parsing and priority extraction → Application selection → GPO / data reading → TLV information extraction (PAN / expiration date / name / Track2, etc.) → Track2 reverse completion", providing underlying data for subsequent card organization identification, transaction data preparation and acceptance routing.

[0029] PSE / PPSE parsing and candidate AID acquisition: Depending on whether it is a contact or contactless card, PPSE (2PAY.SYS.DDF01) or PSE (1PAY.SYS.DDF01) should be selected first; and an alternative option should be selected if the selection fails.

[0030] When the PPSE path is obtained, the ApplicationTemplate (Tag'61') is parsed one by one from the returned FCI, extracting AID (4F), application tag (50), preferred name (9F12), and priority (87) to generate a candidate application list. When the PSE path is obtained: starting from SFI=1, READRECORD is executed one by one until 6A83 (record does not exist) is returned, and the above fields are recursively parsed in each record. All candidates are saved in an ordered list, and a one-to-one mapping between display item and AID is established. like Figure 5 As shown, in this embodiment, local BIN rules, brand rules, and acceptance policies are used, combined with card number, expiration date, and brand elements for matching. Through comprehensive judgment, the card organization, card product, issuing country, and capability set are determined. Preliminary risk screening is carried out using blacklists, risk control thresholds, and industry restrictions to extract potential risk information. Sensitive data such as PAN and Track2 fields are masked in logs and callbacks, and the minimum necessary output is used to complete the desensitization operation. The processed data is stored in memory and persistently using encryption algorithms, and access control policies are set to ensure security, resulting in valid data results that have undergone risk assessment and preprocessing.

[0031] Core process (including application selection → GPO / data retrieval → TLV extraction): Retrieve the target AID from the mapping based on manual response or policy, and send SELECTAID. Read PDOL (9F38) from FCI / application data, construct data domains according to tag requirements, and assemble GPO:80A8...83. <len>[pdol]00; If PDOL is not found, send a simplified GPO (8300) to try to query the card's specific information; after the card is recovered, execute AFL parsing, and obtain the (SFI, startRec, endRec) list from AFL (94) in template 77 / 80; read records one by one according to AFL, parse TLV (or continue to recursively parse TLV) to extract key fields: PAN (5A), Expiry (5F24), Cardholder (5F20), Track2 (57 or 9F6B). If GPO fails or AFL is unavailable, proceed to "Common Record Combination Rollback" (see "Main Record Rollback Reading" before Track2 rollback in the next section).

[0032] Track2 rollback information retrieval: When the master record has no data or the card cannot construct an EMV transaction, Track2 rollback parsing is initiated. It is split by the delimiter D or = (standard EMV track format); if there is no delimiter, a fixed-length assumption is used (PAN is taken as 16-19 bits, followed by 4 bits as YYMM); UnionPay special case data is also supported. If the prefix is ​​62 / 60, the first 16 bits of the PAN are taken first, and possible YYMMs are scanned in subsequent windows. The F at the end of the PAN is removed from all branches.

[0033] Card Type Determination and Display: After completing information reading, the system will automatically determine the card type based on the parsed key fields and display the recognition result to the cashier or end user in real time for manual confirmation of whether to continue the transaction. The rules include: AID prefix recognition: if the AID starts with A000000003, it is identified as VISA; if it starts with A000000333, it is identified as UnionPay; if it starts with A000000004, it is MasterCard; other RIDs are matched according to the registry; and BIN prefix recognition: if the PAN starts with "4", it is identified as VISA; if it starts with "5", it is MasterCard; and if it starts with "62 / 60", it is UnionPay.

[0034] If multiple AIDs (co-badged) are detected, the system can list all candidate organization identifiers in the identification results and prompt the operator to select a channel. During the display phase, the system only outputs identification information (e.g., "UnionPay credit card detected, continue accepting payment?"), and only executes subsequent transaction authorization or settlement processes after user confirmation.

[0035] Formal transaction information construction path: Based on the above extraction results, construct a transaction identification information object and output the final transaction information to the acceptance / routing layer for upper-level card organization determination, channel selection and subsequent authorization; the output content includes PAN, validity period, (optional) cardholder name, Track2, AID, application tag / name, priority, AIP, AFL summary; when outputting, clearly mark the data source (TLV main path or Track2 fallback) and completeness (field missing list).

[0036] UnionPay Card Special Processing Path: While UnionPay and VISA share the same overall EMV transaction structure (both follow the EMV Level-2 process), significant differences exist in the returned data format, TLV organization, tag definitions, and some transaction semantics. For UnionPay cards, the GPO returns template 77, where tags are nested in standard TLV format, with AIP (Tag82) and AFL (Tag94) as independent subfields. The system automatically switches its parsing strategy based on the template identifier during parsing to ensure compatibility with the returned formats of different card brands.

[0037] In this embodiment, the transaction amount, currency, and available payment network information are received. By calling a preset cloud rate query API, real-time transaction fee data of each payment network is obtained. The total transaction fee, clearing exchange rate, and transaction delay parameters of different channels are extracted and compared. The payment network with the lowest cost and the best response is automatically selected as the final transaction path. When some networks fail to return data or the interface is abnormal, a rollback process is performed based on the default priority and the local rate table, and the optimal payment path selection result is obtained.

[0038] The automatic payment network selection module receives transaction amount, currency, and available payment network information (such as UnionPay, VISA, MasterCard, etc.) from the transaction module before the transaction is initiated. It retrieves real-time transaction fee data for each network by calling a pre-defined cloud-based fee query API, compares the total fees of different channels, and automatically selects the network with the lowest cost as the final transaction path. If some networks fail to return data or their interfaces malfunction, the system will perform a fallback selection based on default priority or a local fee table, and return the selected result to the transaction module to execute the acquiring operation.

[0039] It receives transaction data input from the "Multi-dimensional Card Information Extraction Module," including key information such as card number (PAN), expiration date, card organization identifier, transaction amount, terminal identifier (TID), and merchant ID (MID). The module's core functions are transaction request assembly, network channel selection, communication with the acquiring bank, and transaction result processing.

[0040] Based on the selected application identifier (AID) and card type (such as Visa, MasterCard, UnionPay, etc.), the system automatically constructs a transaction request message according to the message standards of each payment network (such as EMV, ISO8583 or network API protocol), including necessary fields such as transaction amount, currency code, and terminal serial number, and performs data encryption and signature processing.

[0041] The transaction acceptance module then calls the acquiring interface to submit the encrypted transaction message to the preset acquiring bank or payment gateway. The system supports parallel configuration of multiple acquiring channels and, based on the results of "automatic payment network selection," automatically selects the channel with the lowest transaction fee or the best response latency for submission.

[0042] The system receives transaction authorization results (success, rejection, or exception) from the bank in real time, parses fields such as response code, authorization number, and transaction reference number, and outputs them to the POS system. If communication is interrupted or the bank's response times out, the system determines that the transaction submission has failed.

[0043] When a transaction fails to submit or the network is unavailable, the module automatically invokes the "offline transaction cache module" to locally encrypt and cache the transaction message and key metadata (such as timestamps, card number hashes, and amounts). The cache has time thresholds and quantity limits, and is automatically replenished by a background task once the network is restored, ensuring transaction closure and data integrity.

[0044] In this embodiment, a transaction request message including the transaction amount, currency code, and terminal serial number is constructed using the extracted card information and the selected payment network. The message is then encrypted and signed. The message is submitted to a pre-defined acquiring bank and payment gateway. The bank's transaction authorization result is received via a real-time interface. The response code, authorization number, and transaction reference number fields are extracted, and the status is parsed, including success, rejection, and exception. The transaction result is encapsulated in a standard format, which includes status, voucher, channel, and cost tag information. The transaction result is then sent back to the POS system. In case of submission failure or network interruption, the offline caching module is invoked to locally encrypt and store the transaction data. Once the network is restored, the data is automatically resubmitted, resulting in standardized transaction results and receipt data.

[0045] When online processing fails or the network is unavailable, this module is responsible for securely writing transactions to disk, managing queues, handling due dates, and ensuring timely delivery after network connection. This module receives the transaction context and the constructed acceptance message from the "Transaction Acceptance Module," as well as the callback event (local callback or webhook) after successful network connection, carrying the final authorization result (APPROVED / DECLINED / FAILED) and associated identifier.

[0046] This invention provides a unified payment interface (API) to initiate transaction requests, return results, and handle exceptions. The module receives transaction request data (including amount, currency, merchant ID, terminal ID, etc.) from the cash register, transmits it to the transaction processing module for processing, and synchronously returns the result to the cash register upon completion of the transaction. When there is a network error or the transaction fails, the system returns to an "offline queue" state, where the offline transaction cache module temporarily stores the data and automatically re-enters the queue once the network is restored. The cash register can query the transaction status in real time through the API. This module also supports basic operations such as transaction status query, cancellation, and refund, ensuring secure, reliable, and consistent data transmission between the cash register front-end and the back-end processing system.

[0047] This invention also provides an automatic foreign card identification system suitable for cross-border scenarios, comprising the following modules: an initialization module, used to establish a PC / SC communication connection with the card reader by loading terminal parameters, key certificates, and rate configurations, initializing the environment, and obtaining a fully configured operating environment; a preliminary verification module, used to collect chip data using the card reader, verify the validity of the card number using the Luhn algorithm, parse the validity period and brand rules, extract legitimate card information, and obtain valid card data after preliminary verification; and a deep parsing module, used to obtain a candidate AID list by parsing PSE / PPSE, classify card types according to the AID-BIN / IIN-Track2 process, and perform further analysis. The system employs a common card configuration priority strategy to obtain classification results based on card organization, issuing bank, and card type. A risk assessment module uses local rules and cloud-based BIN services to conduct risk assessments, anonymizes sensitive data, encrypts and stores it, and obtains risk assessment results and pre-processed data. A payment selection module compares channel fees, clearing rates, and transaction latency by calling a cloud-based rate API, automatically selecting the network with the lowest cost to obtain the optimal payment path. A transaction execution module constructs a transaction message using the extracted card information and the selected payment network, submits it to the acquiring bank, parses the response, and ensures transaction closure through offline caching, obtaining standardized transaction results and receipt data.

[0048] This invention also provides an automatic foreign card identification device suitable for cross-border scenarios. This device may further include one or more power supplies, one or more wired or wireless network interfaces, one or more input / output interfaces, and / or one or more operating systems, such as Windows Server, MacOSX, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that the structure of the automatic foreign card identification device suitable for cross-border scenarios does not constitute a limitation on the computer device provided by this invention, and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0049] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the various steps of the foreign card automatic identification method applicable to cross-border scenarios provided in the above embodiments.

[0050] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.< / len>

Claims

1. A method for automatic identification of foreign cards applicable to cross-border scenarios, characterized in that, The automatic foreign card identification method applicable to cross-border scenarios includes the following steps: By loading terminal parameters, key certificates, and rate configurations, a PC / SC communication connection with the card reader is established, the environment is initialized, and a fully configured operating environment is obtained. A card reader is used to collect chip data, the Luhn algorithm is used to verify the validity of the card number, the validity period and brand rules are parsed, and the legal card information is extracted to obtain valid card data after preliminary verification. By parsing PSE / PPSE to obtain a candidate AID list, classifying card types according to the AID-BIN / IIN-Track2 process, configuring priority strategies for common standard cards, and obtaining classification results for card organizations, issuing banks, and card types; Risk assessment is conducted using local rules and cloud-based BIN services. Sensitive data is anonymized, encrypted, and stored to obtain risk assessment results and preprocessed data. By calling the cloud rate API to compare channel fees, clearing exchange rates and transaction latency, the system automatically selects the network with the lowest cost to obtain the optimal payment path selection result. The extracted card information and the selected payment network are used to construct a transaction message. After the message is submitted to the acquiring bank, the response is parsed. Offline caching ensures a closed transaction loop, resulting in standardized transaction results and receipt data.

2. The method for automatic identification of foreign cards in cross-border scenarios according to claim 1, characterized in that, The process of establishing a PC / SC communication connection with the card reader by loading terminal parameters, key certificates, and rate configurations, initializing the environment, and obtaining a fully configured operating environment includes the following steps: By loading the terminal's preset parameter configuration file, the key certificate, rate rules, and channel priority data are extracted. A two-way authentication connection with the smart card reader is established using the PC / SC communication protocol to complete device initialization enumeration and ATR parameter parsing. The validity of the key is verified synchronously and the risk control threshold parameters are loaded. The rate configuration is then integrated with the cloud service interface for verification, resulting in a system operating environment that includes a complete security authentication system, dynamic rate update capabilities, and device communication guarantees.

3. The method for automatic identification of foreign cards in cross-border scenarios according to claim 1, characterized in that, The process of using a card reader to collect chip data, using the Luhn algorithm to verify the validity of the card number, parsing the expiration date and brand rules, and extracting legitimate card information to obtain valid card data after preliminary verification includes the following steps: A smart card reader compatible with the PC / SC protocol is used to collect chip data of bank cards. The chip data includes card number, expiration date, and information within the chip. The application identifier and application name are obtained from the chip card through the EMV standard command. The validity of the collected card number is verified by the Luhn algorithm to exclude invalid and forged data. Extract the expiration information and verify the format to ensure the card has not expired. Obtain the first few digits of the card number and verify the card number length and prefix according to the BIN and brand rules to obtain the valid card data after preliminary verification.

4. The method for automatic identification of foreign cards in cross-border scenarios according to claim 1, characterized in that, The process of obtaining a candidate AID list by parsing PSE / PPSE, classifying card types according to the AID-BIN / IIN-Track2 process, configuring priority strategies for co-branded cards, and obtaining classification results by card organization, issuing bank, and card type includes the following steps: Based on the PSE / PPSE parsing results, obtain the priority of the candidate AID list, try to select the PPSE path, and when it fails, select the PSE path, recursively parse the AID and application tag in the returned record; A three-level parsing process, AID-BIN / IIN-Track2, is used to classify card types, and the card organization and issuing bank are directly identified through AID. When AID identification fails, the BIN / IIN segment is parsed to determine the card organization, region, and issuing bank. When the BIN / IIN does not match, a fallback identification is performed based on the keywords in Track2 and the application name. For common standard cards, automatic selection is achieved based on the configured priority strategy to obtain classification results of card organization, issuing bank and card type.

5. The method for automatic identification of foreign cards in cross-border scenarios according to claim 1, characterized in that, The process of using local rules and cloud-based BIN services for risk assessment, de-identifying sensitive data, and encrypting and storing it to obtain risk assessment results and preprocessed data includes the following steps: The system adopts local BIN rules, brand rules, and acceptance policies, and matches them with card numbers, expiration dates, and brand elements. Through comprehensive judgment, it determines the card organization, card product, issuing country, and capability set. Preliminary risk screening is conducted using blacklists, risk control thresholds, and industry restrictions to extract potential risk information. Sensitive data such as PAN and Track2 fields are masked in logs and callbacks and output with the minimum necessary output to complete the desensitization operation. The processed data is encrypted and stored in memory and persistently, and access control policies are set to ensure security, resulting in valid data results that have undergone risk assessment and preprocessing.

6. The method for automatic identification of foreign cards in cross-border scenarios according to claim 1, characterized in that, The process of automatically selecting the network with the lowest cost by calling the cloud-based rate API to compare channel fees, clearing exchange rates, and transaction latency, and obtaining the optimal payment path selection result, includes the following steps: By receiving transaction amount, currency, and available payment network information, and calling a preset cloud fee query API, real-time transaction fee data of each payment network can be obtained. The system extracts and compares the total transaction fees, clearing exchange rates, and transaction delay parameters of different channels, and automatically selects the payment network with the lowest cost and best response as the final transaction path. When some networks fail to return data or interfaces malfunction, a rollback process is performed based on the default priority and the local rate table to select the optimal payment path.

7. The method for automatic identification of foreign cards in cross-border scenarios according to claim 1, characterized in that, The process of constructing a transaction message by combining the extracted card information with the selected payment network, submitting it to the acquiring bank, parsing the response result, ensuring transaction closure through offline caching, and obtaining standardized transaction results and receipt data includes the following steps: Using the extracted card information and the selected payment network, a transaction request message including the transaction amount, currency code, and terminal serial number is constructed, and the message is encrypted and signed. The message is submitted to the preset acquiring bank and payment gateway. The transaction authorization result returned by the bank is received through the real-time interface. The response code, authorization number, and transaction reference number fields are extracted and the status is parsed. The parsing status includes success, rejection, and exception. The transaction results are packaged in a standard format, which includes status, voucher, channel, and cost tag information, and then sent back to the POS system. When a submission fails or the network is interrupted, the offline caching module is invoked to locally encrypt and store the transaction data. Once the network is restored, the data will be automatically resubmitted, resulting in standardized transaction results and receipt data.

8. An automatic foreign card identification system suitable for cross-border scenarios, characterized in that, The automatic foreign card identification system suitable for cross-border scenarios includes the following modules: The initialization module is used to establish a PC / SC communication connection with the card reader by loading terminal parameters, key certificates and rate configurations, and initialize the environment to obtain a fully configured operating environment; The preliminary verification module is used to collect chip data using a card reader, verify the validity of the card number using the Luhn algorithm, parse the validity period and brand rules, extract the legal card information, and obtain valid card data after preliminary verification. The deep parsing module is used to obtain a candidate AID list by parsing PSE / PPSE, classify card types according to the AID-BIN / IIN-Track2 process, configure priority strategies for common standard cards, and obtain classification results of card organization, issuing bank and card type. The risk assessment module is used to conduct risk assessments using local rules and cloud-based BIN services, de-identify sensitive data, encrypt and store it, and obtain risk assessment results and pre-processed data. The payment selection module is used to automatically select the network with the lowest cost by calling the cloud rate API to compare channel fees, clearing exchange rates and transaction latency, and obtain the optimal payment path selection result. The transaction execution module is used to construct a transaction message with the extracted card information and the selected payment network, submit it to the acquiring bank, parse the response result, ensure transaction closure through offline caching, and obtain standardized transaction results and receipt data.

9. An automatic foreign card identification device suitable for cross-border scenarios, characterized in that, The automatic foreign card identification device for cross-border scenarios includes a memory and at least one processor. The memory stores instructions, and the at least one processor invokes the instructions in the memory to cause the automatic foreign card identification device for cross-border scenarios to perform the steps of the automatic foreign card identification method for cross-border scenarios as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instructions are executed by the processor, they implement the steps of the automatic foreign card identification method applicable to cross-border scenarios as described in any one of claims 1-7.

Images