Transaction processing method and device, electronic equipment, storage medium and program product

Abstract

The invention provides a transaction processing method and device, electronic equipment, a storage medium and a program product. The method comprises the following steps: receiving a transaction message of a to-be-processed transaction through a first card organization network; the transaction message comprises a transaction ciphertext version number; the first card organization network is a card organization network of one of the plurality of card organizations; determining whether the transaction ciphertext version number is a transaction ciphertext version number corresponding to the first card organization network through the first card organization network; under the condition that the transaction ciphertext version number is not the transaction ciphertext version number corresponding to the first card organization network, the transaction message is sent to the issuing bank server through the first card organization network; and processing the to-be-processed transaction based on the transaction message through the issuing bank server. According to the invention, transaction processing failures can be reduced.

Description

Transaction processing methods, apparatus, electronic devices, storage media and program products Technical Field

[0001] This application relates to the field of transaction processing technology, and in particular to a transaction processing method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the rapid development of the international payment market, dual-branded cards (i.e., bank cards that integrate two card organization applications in the same card chip) have become an important vehicle for cooperation between different card organizations.

[0003] Typically, when a dual-branded card interacts with a Point of Sale (POS) terminal, the cardholder can manually or the POS terminal can automatically select the card network application to process the transaction. The POS terminal then interacts with the card network application to generate a transaction message and sends it to the acquiring institution. The acquiring institution then forwards the transaction information to the card network for processing.

[0004] However, the inventors discovered through research that in actual transactions, the card network to which the acquiring institution sends transaction information may not match the card network application selected by the user (or automatically selected by the POS terminal). This mismatch between the card network and the card network application can lead to card network transaction checks failing and issuing bank transaction verification failing, ultimately causing the transaction to fail. Summary of the Invention

[0005] This application provides transaction processing methods, apparatus, electronic devices, storage media, and program products to reduce transaction processing failures.

[0006] In a first aspect, embodiments of this application provide a transaction processing method, the method being applied to a transaction system, the transaction system comprising: a card network of multiple card organizations, and an issuing bank server, the method comprising:

[0007] The system receives transaction messages for pending transactions through a first card organization network; the transaction message includes a transaction ciphertext version number; the first card organization network is the card organization network of one of the plurality of card organizations.

[0008] The transaction ciphertext version number is determined through the first card organization network to be the transaction ciphertext version number corresponding to the first card organization network.

[0009] If the transaction ciphertext version number is not the transaction ciphertext version number corresponding to the first card organization network, the transaction message is sent to the issuing bank's server through the first card organization network.

[0010] The issuing bank's server processes the pending transaction based on the transaction message.

[0011] Optionally, the transaction message further includes: the Bank Identifier (BIN) of the transaction bank card. Before determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network, the method further includes:

[0012] Based on the BIN of the transaction bank card, the first card organization network determines whether the transaction bank card is a target type bank card; the target type bank card is a bank card that has deployed applications from the multiple card organizations.

[0013] The step of determining whether the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network through the first card organization network includes:

[0014] If the bank card used for the transaction is a bank card of the target type, the transaction ciphertext version number is determined through the first card organization network to determine whether the transaction ciphertext version number is the transaction ciphertext version number corresponding to the first card organization network.

[0015] Optionally, the transaction message further includes: card carrier information of the transaction bank card; and when the transaction bank card is a bank card of the target type, determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network includes:

[0016] When the transaction bank card is the target type and the card carrier information is used to characterize the transaction bank card as a bank card with an embedded integrated circuit IC, the transaction encrypted version number is determined through the first card organization network to be the transaction encrypted version number corresponding to the first card organization network.

[0017] Optionally, before receiving the transaction message of the transaction to be processed through the first card organization network, the method further includes:

[0018] The issuing bank's server sends a network access application to the card network of the multiple card organizations.

[0019] In response to the network access application, the issuing bank server provides its public key certificate to the issuing bank server through any of the multiple card network networks.

[0020] The issuing bank's public key certificate and the IC card public key certificate of the transaction card are written into the transaction card through the issuing bank's server, so that the point-of-sale terminal can complete offline verification with the transaction card based on the IC card public key certificate and the issuing bank's public key certificate.

[0021] Optionally, the transaction message further includes: an application identifier of the target application used by the point-of-sale terminal, and application ciphertext, wherein the target application is one of the applications of the plurality of card organizations; the step of processing the pending transaction based on the transaction message through the issuing bank's server includes:

[0022] The issuing bank's server determines the application encryption key of the target application based on the application identifier of the target application.

[0023] Based on the application ciphertext decryption key of the target application, the application ciphertext is decrypted to obtain transaction information;

[0024] Based on the transaction information, the security verification of the transaction to be processed is performed to obtain the security verification result of the transaction to be processed.

[0025] If the security verification result indicates that the transaction to be processed is normal, the transaction to be processed is then processed.

[0026] Optionally, the application ciphertext decryption key is a symmetric key.

[0027] Optionally, the transaction information includes at least one of the following: the card number of the bank card used for the transaction, the application identifier of the target application, the serial number of the main account bound to the target application, and a transaction counter.

[0028] Optionally, before determining whether the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network through the first card organization network, the method further includes:

[0029] The transaction message is verified by the first card organization network to obtain the protocol format verification result.

[0030] When the protocol format verification result is used to indicate that the transaction message protocol format is correct, the target field of the protocol message is read through the first card organization network to obtain the transaction ciphertext version number.

[0031] Optionally, the method further includes:

[0032] When the transaction ciphertext version number is the transaction ciphertext version number corresponding to the first card organization network, the transaction message is parsed through the first card organization network to obtain the cardholder identity verification information;

[0033] Through the first card organization network, using a preset cardholder authentication method, the cardholder is authenticated based on the authentication information to obtain an authentication result; the multiple card organizations use the same cardholder authentication method;

[0034] When the authentication result indicates that the cardholder's authentication has been successful, the transaction message is sent to the issuing bank's server.

[0035] The issuing bank's server processes the pending transaction based on the transaction message.

[0036] Optionally, after sending the transaction message to the issuing bank's server through the first card organization network, the method further includes:

[0037] Using the first card organization network, anomalies are identified based on the card number of the transaction bank card and at least one of the transaction messages; the anomalies are factors that cause the transaction ciphertext version number to be different from the transaction ciphertext version number corresponding to the first card organization network.

[0038] Optionally, the method further includes:

[0039] Based on the abnormal factors, the target terminal for outputting the prompt information is determined through the first card organization network; the target terminal for outputting the prompt information is at least one of the following: point-of-sale terminal management equipment, acquiring institution terminal, and issuing bank server.

[0040] Send a prompt message to the target terminal that outputs the prompt message, the prompt message being used to indicate that there is an abnormality at the target terminal that outputs the prompt message.

[0041] Secondly, this application provides a transaction processing apparatus, which is applied to a transaction system, the transaction system including: a card network of multiple card organizations, and an issuing bank server, the apparatus including:

[0042] The receiving module is used to receive a transaction message of a transaction to be processed through a first card organization network; the transaction message includes: a transaction encrypted version number; the first card organization network is the card organization network of one of the plurality of card organizations;

[0043] The determining module is used to determine, through the first card organization network, whether the transaction ciphertext version number is the transaction ciphertext version number corresponding to the first card organization network;

[0044] The sending module is used to send the transaction message to the issuing bank's server through the first card organization network when the transaction ciphertext version number is not the transaction ciphertext version number corresponding to the first card organization network.

[0045] The processing module is used to process the pending transaction based on the transaction message through the issuing bank's server.

[0046] Thirdly, this application provides an electronic device, including: a processor and a memory; the processor is communicatively connected to the memory;

[0047] The memory stores computer instructions;

[0048] The processor executes computer instructions stored in the memory to implement the method as described in any one of the first aspects.

[0049] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of the first aspects.

[0050] Fifthly, this application provides a computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of the first aspects.

[0051] The transaction processing method, apparatus, electronic device, storage medium, and program product provided in this application embodiment enable a first card organization network to receive and identify the transaction encrypted version number contained in the transaction message. By determining whether the transaction encrypted version number corresponds to the version number of the first card organization network, the first card organization network can determine whether the current pending transaction is a transaction that does not match the card application and the card organization network. When such a mismatched pending transaction is identified, the first card organization network does not directly reject the transaction because it is not a transaction of its own card organization, but continues to send the transaction message to the issuing bank's server for transaction processing. Through the above method, the issuing bank's server can process pending transactions, thereby realizing cross-card organization network transactions, avoiding transaction failures, reducing transaction processing failures, and improving user experience. Attached Figure Description

[0052] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0053] Figure 1 is a flowchart illustrating a transaction processing method based on a dual-label card;

[0054] Figure 2 is a flowchart illustrating a transaction processing method provided in this application;

[0055] Figure 3 is a flowchart illustrating another transaction processing method provided in this application;

[0056] Figure 4 is a schematic diagram of the key system classification of a transaction bank card provided in this application;

[0057] Figure 5 is a schematic diagram of key distribution in a card organization network provided in this application;

[0058] Figure 6 is a flowchart illustrating another transaction processing method provided in this application;

[0059] Figure 7 is a schematic diagram of a transaction processing device provided in this application;

[0060] Figure 8 is a schematic diagram of the hardware structure of an electronic device provided in this application.

[0061] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0063] With the rapid development of the payment market, dual-branded cards (i.e., bank cards that integrate two card organization applications into the same card chip) have become an important vehicle for cooperation between different card organizations. Through chip-based upgrades, these cards support the coexistence of multiple applications from different card organizations, are compatible with various acceptance environment technical standards, and have data security isolation and priority selection functions between applications.

[0064] Figure 1 is a flowchart illustrating a transaction processing method based on dual-branded cards. As shown in Figure 1, when a dual-branded card is inserted into a POS terminal, the terminal reads the AID identifier of the application within the card and, in conjunction with cardholder selection or application priority rules, determines the card organization application to interact with the card. The terminal generates a transaction message based on the selected application (e.g., application 1 corresponding to card organization network 1 in Figure 1 or application 2 corresponding to card organization network 2 in Figure 1) and sends the transaction to the corresponding card organization network (e.g., card organization network 1 or card organization network 2 in Figure 1) through the acquiring institution. The card organization network can then complete the transaction through the issuing institution.

[0065] Each card organization independently builds its own key system, including a root certificate issued by a CA (Certificate Authority), an issuing bank's public key certificate, and a symmetric key. During a transaction, the terminal and the card complete offline verification based on the IC card's public key and the issuing bank's public key. The ciphertext in the transaction message needs to be decrypted using the corresponding card organization's symmetric key. For example, the ciphertext generated by Application 1 needs to be verified through the key system of card organization network 1, while Application 2 requires the key system support of card organization network 2.

[0066] The existing transaction path strictly requires consistency between the card interaction application and the card network to which the transaction is sent. If the terminal selects application 1, the transaction must be sent to card network 1; if application 2 is selected, it must be sent to card network 2. Otherwise, a mismatch between the card network and the card network application will lead to card network transaction check failure and issuer transaction verification failure, thus causing the transaction to fail.

[0067] For example, when a card uses application 1 to generate ciphertext for a transaction, but the transaction is sent to card network 2, the issuing bank cannot correctly parse the ciphertext due to differences in key systems and verification rules, ultimately leading to the transaction being rejected. Furthermore, if acquiring institutions need to adapt to such cross-network transactions, they must modify their terminals and systems, which is costly and time-consuming.

[0068] Therefore, how to achieve seamless transfer of dual-branded card transactions across card organization networks has become an urgent technical problem to be solved.

[0069] In view of the aforementioned problems with existing transaction methods, this application proposes a dynamic transaction method based on transaction ciphertext identifiers. Through this method, the card network can identify the transaction ciphertext identifier to determine whether the transaction was initiated by another card network. If, based on the transaction ciphertext identifier, it is determined that the transaction was not initiated by the current card network, the transaction message is forwarded to the issuing bank for processing, avoiding transaction failures. This reduces transaction processing failures and improves the user experience.

[0070] The technical solutions of this application will be described in detail below with reference to specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0071] Figure 2 is a flowchart illustrating a transaction processing method provided in this application. This method can be applied to a transaction system, which includes a card network of multiple card organizations and an issuing bank server. As shown in Figure 2, the method includes the following steps:

[0072] S201. Receive the transaction message for the pending transaction through the first card organization network. The transaction message includes: the transaction ciphertext version number.

[0073] The first card organization network is the card organization network of one of multiple card organizations.

[0074] The aforementioned transaction system can be a distributed information system that supports bank card transaction switching, authorization, and clearing. In some embodiments, the system may include a switching network (i.e., a card network) operated by different card organizations, and a server-side system (i.e., an issuing bank server) operated by each bank for processing its own card authorization requests.

[0075] The aforementioned card organization network can refer to a dedicated network built and operated by a card organization to process its bank card transactions. This network can be used for tasks such as transaction switching, some risk control, and clearing data generation.

[0076] The aforementioned card-issuing bank server can refer to the back-end server deployed by the bank that issues the bank card. Its core functions may include, but are not limited to: managing card keys, verifying the authenticity of transactions, authenticating cardholder identities, implementing risk control strategies, and making authorization decisions such as deducting funds from accounts.

[0077] The aforementioned pending transactions can refer to any type of financial transaction initiated by the cardholder that requires authorization, such as purchase transactions, cash withdrawal transactions, and inquiry transactions. This application does not limit the specific type or amount of the transaction.

[0078] Optionally, the aforementioned transaction message may be generated by a Point of Sale (POS) terminal and uploaded to the first card organization network via the acquiring institution. In some embodiments, the acquiring institution may choose to upload the transaction to the first card organization network based on its business rules (e.g., based on card BIN attribution).

[0079] The transaction ciphertext version number can be used to identify the encryption standard, algorithm version, and corresponding card network used when generating the transaction ciphertext (e.g., application ciphertext) in the transaction message. Optionally, different card network networks can correspond to different transaction ciphertext version numbers. For example, the first card network network can correspond to a transaction ciphertext version number of 0x01, while other card network networks can correspond to transaction ciphertext version numbers of 0x12 or 0x21, etc.

[0080] It should be understood that this application does not specify which card organization's network the first card organization network refers to, the specific format and protocol of the transaction message, or the encoding rules for the transaction ciphertext version number.

[0081] S202. Determine whether the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network through the first card organization network.

[0082] Optionally, after receiving a transaction message, the first card organization network may first read the transaction ciphertext version number from a designated data field of the transaction message. Then, it compares the read transaction ciphertext version number with a pre-configured standard transaction ciphertext version number supported by this network (i.e., the first card organization network) to determine whether the transaction ciphertext version number is the transaction ciphertext version number corresponding to the first card organization network.

[0083] If the transaction ciphertext version number matches the version number corresponding to the first card organization network, it indicates that the transaction message is a regular transaction generated according to the standard of the first card organization network. If they do not match, it indicates that the transaction message was processed on the terminal side using an application from another card organization, but was sent to the first card organization network by the acquiring institution, thus triggering an abnormal cross-card organization transaction.

[0084] S203. If the transaction ciphertext version number is not the transaction ciphertext version number corresponding to the first card organization network, the transaction message is sent to the issuing bank's server through the first card organization network.

[0085] Optionally, upon detecting a mismatch in the transaction ciphertext version number, the first card organization network does not immediately reject the transaction. Instead, it forwards the transaction message of the pending transaction to the issuing bank's server. This avoids transaction failures caused by inconsistencies between the acquiring institution's upload path selection and the terminal application's selection, thus ensuring the transaction success rate of dual-branded cards in complex acceptance environments.

[0086] For example, the first card organization network may determine the issuing bank server responsible for the transaction based on information such as the issuing bank identifier (e.g., BIN) in the transaction message, and route the transaction message to the issuing bank server through a secure financial private network or an agreed communication interface.

[0087] S204. Process the pending transaction through the issuing bank's server based on the transaction message.

[0088] Optionally, after receiving a transaction message from the first card organization network, the issuing bank's server can, for example, identify the card as a dual-branded card based on information in the transaction message and determine the actual card organization application used in the transaction (e.g., through the transaction ciphertext version number or application identifier AID). Then, the issuing bank's server can use the key system corresponding to that application (e.g., a symmetric key) to decrypt and verify the application ciphertext in the transaction message and execute processing logic such as cardholder authentication and transaction risk control.

[0089] For example, if the verification passes, the issuing bank's server can generate a successful transaction authorization response and return it to the POS terminal along the original path (first card organization network, acquiring institution, etc.). If the verification fails, a transaction failure response is generated.

[0090] In this embodiment, the first card organization network can receive and identify the transaction ciphertext version number contained in the transaction message. By determining whether the transaction ciphertext version number corresponds to the version number of the first card organization network, the first card organization network can determine whether the current pending transaction is a transaction that does not match the card application and the card organization network. When such a mismatched pending transaction is identified, the first card organization network does not directly reject the transaction because it is not a transaction of its own card organization, but continues to send the transaction message to the issuing bank's server for transaction processing. Through the above method, the issuing bank's server can process pending transactions, thereby realizing cross-card organization network transactions, avoiding transaction failures, reducing transaction processing failures, and improving user experience.

[0091] As one possible implementation, the transaction message may also include the Bank Identifier Number (BIN) of the transaction bank card. Before determining whether the transaction encrypted version number is the same as the transaction encrypted version number corresponding to the first card organization network, the transaction system may also determine whether the transaction bank card is a target type bank card based on the BIN of the transaction bank card through the first card organization network. Then, if the transaction bank card is a target type bank card, the transaction system can determine whether the transaction encrypted version number is the same as the transaction encrypted version number corresponding to the first card organization network through the first card organization network.

[0092] Specifically, the target type of bank card refers to a bank card that has deployed applications from multiple card organizations.

[0093] For example, the target type of bank card can be a dual-branded card (with applications from two card organizations deployed) or a multi-application card, that is, at least two different card organization payment applications are personalized within the same financial IC card chip.

[0094] For example, the first card organization network can maintain a dedicated dual-branded card BIN list or mark the 0BIN of the target type of bank card using a specific identifier. Upon receiving a transaction message, the first card organization network can parse the BIN in the transaction message and determine whether the transaction to be processed involves the target type of bank card by querying the dual-branded card BIN list or checking the specific identifier. If so, subsequent logic for checking the encrypted version number of the transaction can be triggered.

[0095] If not, it indicates that the transaction to be processed is a single-branded card (or that the card in question has an application from a card organization deployed on it). The first card organization network can, for example, process the transaction in collaboration with the issuing bank's server through the single-branded card transaction process. Specifically, the implementation method of the first card organization network collaborating with the issuing bank's server to process transactions through the single-branded card transaction process can refer to any existing single-branded card-based transaction processing flow, and will not be elaborated upon here.

[0096] By performing pre-filtering based on BIN, transactions that require the execution of the transaction processing method described in this application can be accurately identified, thereby avoiding unnecessary and complex encrypted version number checks on a large number of regular single-label card transactions, and improving the overall processing efficiency and resource utilization of the transaction system.

[0097] Optionally, the transaction message may also include: card carrier information of the transaction bank card. Optionally, when the transaction bank card is the target type and the card carrier information is used to identify that the transaction bank card is a bank card with an embedded integrated circuit (IC), the transaction system may, through the first card organization network, determine whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network.

[0098] The card carrier information can be used to indicate the physical or logical form of the bank card used for the transaction to be processed. For example, the card carrier information can be used to characterize the bank card as a magnetic stripe card, a chip card with an embedded integrated circuit, or a digital form (such as a device card in mobile payment).

[0099] Optionally, the first card organization network can parse card carrier information from specified fields in the transaction message. For example, the transaction message may contain a transaction medium type field, whose value can be a specific code, such as 01 for magnetic stripe card, 05 for IC card, 07 for contactless IC card, 81 for mobile payment device card, etc.

[0100] Optionally, if the aforementioned transaction card is not the target type, it indicates a low probability of a mismatch between the card organization's application and network. Therefore, the first card organization network can, for example, collaborate with the issuing bank's server to process transactions through a single-branded card transaction process. Specifically, the implementation method of the first card organization network collaborating with the issuing bank's server to process transactions through a single-branded card transaction process can refer to any existing single-branded card-based transaction processing flow, and will not be elaborated here.

[0101] The above method addresses the core scenario of cross-card organization transaction adaptation issues because IC card transactions involve transaction ciphertexts with varying standards generated by different card organization applications. Therefore, the method considers that the ciphertext version number check is only performed when the card carrier information is represented as an IC card. By combining the card carrier information for judgment, the pertinence and efficiency of the transaction processing logic in this application are improved.

[0102] Optionally, before receiving the transaction message of the transaction to be processed through the first card organization network, the above-mentioned transaction system may first establish a transaction cryptography system.

[0103] For example, before receiving the transaction message of the transaction to be processed through the first card organization network, the transaction system can first send a network access application to the card organization networks of multiple card organizations through the issuing bank's server.

[0104] Then, the transaction system can respond to the network access application through any of the card network networks of multiple card organizations by sending the issuing bank's public key certificate (also known as the issuing bank's public key certificate) back to the issuing bank's server.

[0105] The transaction system can use the issuing bank's server to write the issuing bank's public key certificate and the IC card's public key certificate into the transaction card, so that the subsequent point-of-sale terminal can complete offline verification with the transaction card based on the IC card's public key certificate and the issuing bank's server's public key certificate.

[0106] For example, the aforementioned network access application may include at least one of the following: the issuing bank's qualification information, the proposed card BIN range, the types of applications to be supported, and proof of security compliance. This network access application can be used to request authorization from various card organizations to enable their issued cards to be processed or transferred normally within the corresponding card organization's network.

[0107] The public key certificate of the issuing bank's server can be a key component of the Public Key Infrastructure (PKI) system. Specifically, after approving an issuing bank's application, each card organization network (e.g., the first card organization network, and other card organization networks) can use its own Certificate Authority (CA)'s private key to issue a unique public key certificate for the applying issuing bank. This public key certificate may include, for example, the issuing bank's public key information and is digitally signed by the card organization's CA to ensure the authenticity and integrity of the certificate.

[0108] Taking the example of the issuing bank server obtaining two independent issuing bank public key certificates from multiple card organizations, the certificates may belong to the same issuing bank, but they may also be different due to the different issuing CAs and the different certificate specifications they follow. Their internal format, content and purpose are distinct and independent, and they are used for identity authentication and data security protection in the network transaction process of their respective card organizations.

[0109] It should be understood that a transaction bank card can refer to a physical IC card or digital card carrier of the target type that is about to be issued. During the personalized card production process, the issuing bank's server can write the issuing bank's public key certificate obtained from various card organization networks, along with a separately generated IC card public key certificate, into the security domain of the card chip. This IC card public key certificate can be a unique public key certificate issued by the issuing bank's server (e.g., its security management system) for each card. This IC card public key certificate can be used to represent the digital identity of this bank card.

[0110] For example, when a dual-branded IC card is inserted into or near a POS terminal, the terminal can perform a certificate acquisition chain. For instance, by reading the card, the POS terminal can retrieve the IC card's public key certificate and the public key certificate of the issuing bank that issued the IC card certificate (e.g., depending on the application currently selected by the terminal, retrieving the public key certificate of the issuing bank from the corresponding card organization). The POS terminal can also use its pre-configured root certificate public key from the corresponding card organization's CA to verify the authenticity and validity of the issuing bank's public key certificate read from the card (i.e., verifying the card organization CA's signature). After successful verification, the verified issuing bank's public key is used to verify the authenticity of the IC card's public key certificate (i.e., verifying the issuing bank's signature).

[0111] Through the aforementioned certificate chain verification, the POS terminal can trust the IC card public key read from the card. The terminal can then use this public key to verify the dynamic signature data generated by the card in a transaction (e.g., a signature used for static or dynamic data authentication). This allows for offline verification of the card's authenticity and the integrity of the transaction data, completing the offline verification of the bank card transaction.

[0112] Alternatively, the offline verification method for subsequent point-of-sale terminals based on the IC card public key certificate and the issuing bank's server public key certificate with the transaction bank card can refer to any existing offline verification method.

[0113] Optionally, the public key certificate for the IC card and the public key certificate for the issuing bank's server can be an asymmetric key.

[0114] The above methods ensure that the bank card used for the transaction has the necessary digital identity credentials to support secure transactions across multiple card network networks when it leaves the factory, laying the foundation for the subsequent execution of the transaction processing provided in this application.

[0115] As one possible implementation, the transaction message may also include: an application identifier for the target application used by the point-of-sale terminal, and application ciphertext. The target application is one of multiple card network applications. The transaction system, for example, can determine the application ciphertext decryption key for the target application based on the application identifier of the target application through the issuing bank's server.

[0116] Then, the transaction system can decrypt the application ciphertext using the application ciphertext decryption key from the issuing bank's server to obtain the transaction information. Based on this transaction information, the transaction system can then perform security verification on the transaction to be processed, obtaining the security verification result. If the security verification result indicates that the transaction is not abnormal, the transaction system can then process it.

[0117] Optionally, the application ciphertext decryption key described above can be, for example, a symmetric key. Alternatively, the application ciphertext decryption key can refer to the application ciphertext key used in any existing transaction processing method.

[0118] The aforementioned application identifier can be, for example, an Application Identifier (AID). An application identifier can be a code that uniquely identifies a specific application within the IC card. When this AID is carried in the transaction message, the issuing bank's server can determine which card network application the transaction is interacting with on the terminal side.

[0119] Optionally, during the card issuance phase, the issuing bank's server can write independent application encryption and decryption keys for each card organization application within the card. These keys can be symmetric keys generated by the issuing bank according to the key management specifications of each card organization. The issuing bank's server can maintain a local key database that associates and stores the card number, application identifier (AID), and application encryption / decryption key. Upon receiving a transaction message, the issuing bank's server can extract the card number and the target application's AID, and query the key database based on the target application's AID to obtain the application encryption / decryption key used to decrypt the application's encrypted data.

[0120] For example, the aforementioned application ciphertext can be the ciphertext result generated by the transaction bank card through its security chip using a symmetric key shared with the issuing bank (the application ciphertext encryption key, the corresponding decryption key of which is the application ciphertext decryption key) to encrypt key transaction data (such as transaction amount, transaction type, terminal device number, etc.).

[0121] Optionally, the transaction information may include at least one of the following: the bank card number of the transaction, the application identifier of the target application, the main account serial number bound to the target application, and a transaction counter.

[0122] For example, the primary account serial number bound to the target application can be a serial number assigned to a specific application within the card during the personalization process, used to distinguish different application instances under the same primary account (card number). Taking a dual-branded card as an example, applications from two card organizations share the same card number, but each has its own independent application serial number. This serial number can be used for anti-counterfeiting and transaction continuity management. The issuing bank's server can, for example, verify whether the application serial number carried in the transaction message matches the application serial number of the corresponding AID under that card number recorded in the system. If they do not match, a counterfeit card or data error can be indicated, thus verifying transaction anomalies.

[0123] For example, the transaction counter mentioned above could be an independent and monotonically increasing counter maintained by the card's security chip for each application. It increments once after each successful online transaction. For example, the transaction counter can be used to prevent transaction replay attacks. The issuing bank's server can check if the value of the transaction counter in the transaction message is greater than the transaction counter value of a previously successfully recorded transaction. If the transaction counter value is less than or equal to the recorded transaction counter value, it indicates that the transaction message may be a duplicate transmission of an old message (replay attack), and the issuing bank can reject the transaction to ensure transaction security.

[0124] Optionally, the issuing bank's server can perform security verification on the transaction based on this transaction information to obtain the security verification result. This can be achieved by referring to any existing method used by the issuing bank's server for security verification during transaction processing. For example, the issuing bank's server can check whether the card status and transaction type in the transaction information are allowed. The issuing bank's server can also perform verification based on anti-replay attack parameters such as application transaction counters in the transaction information. Furthermore, the issuing bank's server can combine information such as transaction amount, time, and location to perform fraud risk scoring.

[0125] If the security verification result indicates that the transaction to be processed is normal, the issuing bank's server can process the transaction by, for example, deducting the transaction amount from the cardholder's account, generating a transaction authorization code, assembling it into an authorization response message, and returning it to the POS terminal via the first card organization network, thus completing the transaction. Alternatively, the issuing bank's server can implement the processing of the transaction by referring to any existing transaction processing method, which will not be elaborated here.

[0126] Optionally, if the security verification result is used to indicate that there is an anomaly in the transaction to be processed, the issuing bank server may, for example, send a prompt message to the POS terminal through the first card organization network to indicate that the transaction is abnormal and has failed.

[0127] The above method enables the issuing bank's server to decrypt the application's encrypted data using the application's encryption key, even when the card organization's application and network are incompatible. This decryption process retrieves the transaction information, performs security verification, and only processes the transaction if the verification result indicates no anomalies. This method ensures the security and reliability of transaction information processing even when the card organization's application and network are incompatible.

[0128] Optionally, before determining whether the transaction ciphertext version number matches the corresponding ciphertext version number of the first card organization network, the transaction system can perform message protocol format verification on the transaction message to obtain a protocol format verification result. When the protocol format verification result indicates that the transaction message protocol format is correct, the transaction system can read the target field of the protocol message through the first card organization network to obtain the transaction ciphertext version number.

[0129] Message protocol format verification refers to checking whether the received transaction message conforms to a predefined communication protocol specification. For example, after receiving a transaction message from an acquiring institution, the first card organization network can first verify its basic protocol structure, such as whether the message length is within the valid range, whether the identifier bits and version number in the message header are correct, whether the required data fields exist, and whether the length and encoding format of each field conform to the specifications. Through this method, messages that do not meet the protocol format due to transmission errors, protocol incompatibility, or malicious attacks can be filtered out, ensuring the stability and security of subsequent processing.

[0130] Optionally, the location and encoding method of the target field in the message can be explicitly defined by relevant technical standards. For example, the transaction ciphertext version number can be located under a specific sub-label in the IC card data field or security-related data field of the message. The first card organization network can, for example, accurately read the value of the target field according to the standard-defined format, as the transaction ciphertext version number.

[0131] Optionally, if the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network, the transaction system can also parse the transaction message through the first card organization network to obtain the cardholder's identity verification information.

[0132] Then, the transaction system can use the first card organization network and a preset cardholder authentication method to authenticate the cardholder based on the authentication information and obtain the authentication result. The cardholder authentication methods used by multiple card organizations can be the same.

[0133] The transaction system can send a transaction message to the issuing bank's server via the first card organization network when the authentication result indicates that the cardholder's authentication has been successful. The transaction system can then process the transaction based on the transaction message from the issuing bank's server.

[0134] For example, when the first card network determines that the transaction ciphertext version number in the transaction message is consistent with the standard version number corresponding to its own network, it determines that this is a regular transaction that conforms to the standard of its card network.

[0135] The aforementioned cardholder authentication information may include, for example, encrypted data of a personal identification number (PIN) (such as PINBlock), signature image data, or biometric tokens.

[0136] The first card organization network uses a preset cardholder authentication method. Based on the authentication information, it authenticates the cardholder and obtains the authentication result. The implementation method can refer to any existing card organization network's cardholder authentication method, which will not be elaborated here.

[0137] By ensuring that cardholder authentication methods used by multiple card organizations are the same, the balance between multiple card organizations is maintained, and the stability of authentication in a multi-card organization scenario is improved.

[0138] Optionally, after the transaction system sends the transaction message to the issuing bank's server through the first card organization network, it can also use the first card organization network to determine abnormal factors based on the card number of the transaction bank card and at least one of the factors in the transaction message.

[0139] The anomaly is that the transaction ciphertext version number is not the same as the version number corresponding to the first card organization network. This analysis addresses the root cause of the cross-card organization network phenomenon of mismatch between the terminal application and the transaction transmission network in this transaction.

[0140] For example, the first card organization network can perform comprehensive analysis by combining rich information in the transaction messages. For instance, based on the card number, it can query basic information such as the card's BIN, issuing bank, and whether it is a dual-branded card, confirming the card's inherent attributes. Through the transaction messages (including, for example, the POS terminal identifier and acquiring institution identifier), it can analyze and locate the specific POS terminal and obtain its historical transaction records to determine whether the terminal frequently engages in such cross-network transactions. If so, it indicates that the terminal's application selection logic is abnormal, meaning the anomaly is due to an error in the terminal's application selection logic. Alternatively, if the transaction messages indicate that the acquiring institution's routing configuration for the terminal is incorrect, then the anomaly is due to an error on the acquiring institution's part.

[0141] For example, the first card organization network can determine the aforementioned anomalies based on the card number of the transaction bank card and at least one of the information in the transaction message, using any existing large language model, etc.

[0142] By using the methods described above to identify anomalous factors, the first card organization network can proactively discover the root causes of these anomalous factors, laying the foundation for subsequent ecological optimization and precise problem governance in multi-card organization collaboration.

[0143] Furthermore, optionally, the transaction system can also determine the target end for outputting the alert message based on anomalies through the first card organization network. This target end can be, for example, at least one of a point-of-sale terminal management device, an acquiring institution terminal, or an issuing bank server. The transaction system can then send an alert message to this target end, indicating that an anomaly has occurred at the target end.

[0144] The aforementioned point-of-sale (POS) terminal management equipment can be, for example, a back-end system used for remote monitoring, parameter management, and software upgrades of a large number of POS terminals. The aforementioned acquiring institution terminal can, for example, refer to the acquiring institution's business operations or technical monitoring back-end.

[0145] For example, if the above-mentioned anomaly is due to a problem with the terminal application's selection logic, the target end for outputting the prompt message may include the point-of-sale terminal management device. If the above-mentioned anomaly is due to an error by the acquiring institution, the target end for outputting the prompt message may include the acquiring institution's terminal. If the above-mentioned anomaly is due to card attributes of a specific issuing bank (e.g., newly issued dual-branded cards have a higher probability of acceptance problems), the target end for outputting the prompt message may include the issuing bank's server.

[0146] For example, the content of the prompt message may include at least one of the following: a summary of the abnormal transaction characteristics (such as time, location, and de-identified card number information), a description of the identified abnormal factors, suggested investigation or remediation directions, and a severity level indicator. For instance, taking the prompt message output target as the acquiring institution's terminal as an example, the prompt message may be: "Multiple dual-brand card transactions were mistakenly routed to a mismatched card organization network within the past 24 hours by the acquiring device with terminal model ZZZ under your institution's merchant code XXX. Analysis suggests that the BIN table routing rules configured for this merchant by your institution may not match the terminal application list. Please check the relevant configuration."

[0147] By using the above method, the aforementioned notification information is sent to the target terminal, enabling users to be aware of any abnormalities in card transactions in a timely manner, thus laying the foundation for resolving the anomaly.

[0148] For example, Figure 3 is a flowchart illustrating another transaction processing method provided in this application. The bank card can be deployed with Application 1 and Application 2. The bank card can interact with the acquiring institution, which then sends the transaction to Card Network 1 or Card Network 2. Card Network 1 or Card Network 2 then forwards the transaction to the issuing institution for processing. Card Network 1 and Card Network 2 can possess the core capability of identifying the encrypted version information of the IC card transaction application during the transaction process, laying the foundation for subsequent cross-card network adaptation.

[0149] By upgrading the transaction system's key management and encrypted text recognition capabilities, the transaction network can identify multi-card organization key identifiers and encrypted version identifiers, distinguishing them from regular bank card transactions. Acquiring institutions and acceptance terminals do not require modification and can complete transaction submission based on existing logic. Partner card organizations support cooperative transfer of IC card transactions generated by such card BINs. Regarding transaction verification technology, different card organizations maintain consistent encrypted text verification capabilities for IC card transactions, accurately identifying dual-branded card transactions and transactions where the interactive application and network are incompatible. For identity verification, a unified cardholder verification method is defined, such as online PINs and signatures, maintaining consistency in cardholder verification capabilities and levels across different networks under network cooperation.

[0150] Figure 4 is a schematic diagram of the key system classification for a transaction bank card provided in this application. As shown in Figure 4, the asymmetric key includes the CA certificate on the card organization side (first card organization root CA / second card organization root CA), the issuing bank public key certificate issued by the first card organization (light-colored module in Figure 4), and the IC card public key certificate on the card side (light-colored module in Figure 4), the issuing bank public key certificate issued by the second card organization (dark-colored module in Figure 4), and the IC card public key certificate on the card side (dark-colored module in Figure 4), used for identity authentication, data encryption, etc. The symmetric key includes the first application ciphertext encryption key corresponding to the first card organization and the second application ciphertext encryption key corresponding to the second card organization, used for the generation and parsing of transaction ciphertext.

[0151] According to the card issuance cooperation scheme of card organizations, personalized data and card keys for different card organization applications are prepared during the card issuance stage. Unlike regular single-branded bank cards, card organizations issue independent issuing bank public keys for dual-branded cards. This facilitates the cooperative management and operation of bank cards by card organizations and banks, and makes it easier to distinguish them from single-branded cards during the card issuance and usage stages. During the card network access stage, the bank applies for and issues an independent issuing bank public key. During the transaction stage, the terminal interacts with the card based on the card application selected by the terminal, completing offline verification based on the IC card public key and the issuing bank's public key. The transaction is then sent to the issuing bank, where encrypted decryption and verification are completed based on different application encrypted keys. Different information elements include equivalent magnetic stripe numbers (MEKs), application master account serial numbers, application transaction counters, cardholder verification method lists, application identifiers (AIDs), application tags, application priority indicators, and encrypted version numbers.

[0152] Figure 5 is a schematic diagram of key distribution in a card organization network provided in this application. As shown in Figure 5, a dual-branded bank card can maintain the issuing bank public key certificate, IC card public key certificate, and first application encrypted key corresponding to card organization network 1, and the issuing bank public key certificate, IC card public key certificate, and second application encrypted key corresponding to card organization network 2, respectively, through card organization network 1 and card organization network 2.

[0153] During the network access phase, the issuing bank initiates an application. After meeting the business, technical rules, and standards requirements, it obtains the issuing bank's public key certificate issued by different card organizations and independently prepares the IC card public key certificate and the bank card application encrypted encryption key. Within its internal card issuance system, the issuing bank, in accordance with the rules and standards of different card organizations, completes the association of card BIN, card number, user information, and account information, and prepares personalized data. For the same card, two sets of key management capabilities, transaction counting capabilities, and transaction verification capabilities are required to handle transactions transmitted from different networks and scenarios.

[0154] Figure 6 is a flowchart illustrating another transaction processing method provided in this application. As shown in Figure 6, during the transaction stage, taking a typical consumer transaction as an example, when the card interacts with the terminal, other card network applications are used to complete the transaction (for example, in Figure 6, the card network network 1 corresponding to application 1 should be used, but in reality, the card network network 2 corresponding to application 2 receives the transaction message from the acquiring institution).

[0155] Card network 2 first determines whether a card is a dual-branded card based on its BIN. It then needs to identify transaction elements in the transaction message, such as the application ciphertext, ciphertext version number, transaction medium, and acceptance-side scenario information within the IC card data field. It dynamically analyzes the transaction type and the standardized IC application used by the transaction. For example, application 1 processes a transaction with a ciphertext version number of 0x01, while application 2 processes a transaction with a ciphertext version number of 0x12.

[0156] After analysis, Card Organization Network 2 uses a different logic than that used for single-branded card transactions to verify the transaction message and sends it to the issuing bank to verify the user's identity, card, and transaction details. Upon receiving the transaction, the issuing bank verifies the authenticity of the transaction and the cardholder's identity based on the card number, encrypted version information, application identifier information, the card's application master account serial number, and transaction counter. For example, if duplicate transaction counts are found for the same application, or if the master account serial number is inconsistent with the system's records, the transaction is considered abnormal. Transaction judgment factors can be illustrated in Table 1 below.

[0157] Table 1

[0158]

[0159] Card network cooperation is based on the authorization of card BINs between the two parties. To preserve the flexibility in the use of authorized card BINs, different card carriers may be used for transactions under the same card BIN, such as magnetic stripe cards, IC cards, and digital cards. Card networks can associate card carrier information, transaction carrier information, transaction type, and dual-branded card BINs to achieve comprehensive operational management of card issuance, usage, cancellation, inquiry, and verification. Furthermore, by monitoring mismatches between card and terminal interaction applications and the transaction network, they can optimize acceptance-side services and terminal application functions, improve acceptance-side service capabilities, and provide technical support for issuing banks to identify abnormal card usage.

[0160] In addition to basic network access and transaction management of card BINs, further refined operational management is added. For example, transactions between magnetic stripe cards and IC cards of dual-branded cards are determined based on the IC card transaction information elements and transaction carrier in the transaction message; transactions between dual-branded IC cards and mobile payment device cards are determined based on the mobile payment information elements in the transaction message; for dual-branded cards and merchant transaction failures, the reasons for failure and abnormal situations are automatically analyzed to quickly locate business or technical problems.

[0161] In this embodiment, card organizations and issuing banks have the ability to judge and identify dual-branded card transactions, addressing situations where card and terminal applications are incompatible with the transaction network. They support the use of different transaction keys and card information elements to parse and verify transaction messages. Acquiring institutions can assemble transaction messages and upload them based on existing rules. The application selection for card-terminal interaction is based on the application AID, and diverse business and technical solutions can be adopted for card organization network selection. Transactions are uploaded based on the card BIN or cooperation agreement, reducing transformation costs. Card organizations upgrade both the terminal side (bank card) and the cloud side (transaction network, system), supporting comprehensive operational management of the construction and operation capabilities of cooperative carriers (bank cards, digital bank cards, etc.).

[0162] Figure 7 is a schematic diagram of a transaction processing device provided in this application. The transaction processing device 70 is applied to a transaction system. The transaction system includes: a card network of multiple card organizations, and an issuing bank server. As shown in Figure 7, the transaction processing device 70 may include: a receiving module 71, a determining module 72, a sending module 73, and a processing module 74.

[0163] The receiving module 71 is used to receive the transaction message of the transaction to be processed through the first card organization network; the transaction message includes: the transaction encrypted version number; the first card organization network is the card organization network of one of multiple card organizations;

[0164] The determination module 72 is used to determine whether the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network through the first card organization network;

[0165] The sending module 73 is used to send the transaction message to the issuing bank's server through the first card organization network when the transaction ciphertext version number is not the transaction ciphertext version number corresponding to the first card organization network.

[0166] Processing module 74 is used to process the transaction to be processed based on the transaction message through the issuing bank's server.

[0167] Optionally, the transaction message may also include: the Bank Identifier (BIN) of the transaction bank card. Optionally, the determining module 72 is further configured to, before determining whether the transaction encrypted version number is the same as the transaction encrypted version number corresponding to the first card organization network, determine whether the transaction bank card is a target type bank card based on the BIN of the transaction bank card through the first card organization network. The target type bank card is a bank card for which applications deployed with multiple card organizations are deployed. Optionally, the determining module 72 is specifically configured to, when the transaction bank card is a target type bank card, determine whether the transaction encrypted version number is the same as the transaction encrypted version number corresponding to the first card organization network through the first card organization network.

[0168] Optionally, the transaction message may also include: card carrier information of the transaction bank card. Optionally, the determining module 72 is specifically used to determine, through the first card organization network, whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network when the transaction bank card is the target type and the card carrier information is used to characterize the transaction bank card as a bank card with an embedded integrated circuit IC.

[0169] Optionally, the sending module 73 is further configured to, before receiving the transaction message of the transaction to be processed through the first card organization network, send a network access application to the card organization networks of multiple card organizations through the issuing bank server; and, in response to the network access application, provide the issuing bank server with its public key certificate through any of the multiple card organization networks. Optionally, the processing module 74 is further configured to, through the issuing bank server, write the issuing bank server's public key certificate and the IC card public key certificate of the transaction bank card into the transaction bank card, so that the point-of-sale terminal can complete offline verification with the transaction bank card based on the IC card public key certificate and the issuing bank server's public key certificate.

[0170] Optionally, the transaction message may also include: an application identifier of the target application used by the point-of-sale terminal, and application ciphertext, wherein the target application is one of the applications from multiple card organizations. Optionally, the processing module 74 is specifically configured to: determine the application ciphertext decryption key of the target application based on the application identifier of the target application through the issuing bank's server; decrypt the application ciphertext based on the application ciphertext decryption key to obtain transaction information; perform security verification on the transaction to be processed based on the transaction information to obtain the security verification result of the transaction to be processed; and process the transaction if the security verification result indicates that the transaction to be processed is not abnormal.

[0171] Optionally, the ciphertext decryption key can be a symmetric key.

[0172] Optionally, the transaction information may include at least one of the following: the bank card number of the transaction, the application identifier of the target application, the main account serial number bound to the target application, and a transaction counter.

[0173] Optionally, the processing module 74 is further configured to perform message protocol format verification on the transaction message before determining whether the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network, and obtain the protocol format verification result; when the protocol format verification result is used to indicate that the transaction message protocol format is correct, the target field of the protocol message is read to obtain the transaction ciphertext version number.

[0174] Optionally, processing module 74 is further configured to, when the transaction ciphertext version number corresponds to the transaction ciphertext version number of the first card organization network, parse the transaction message through the first card organization network to obtain cardholder authentication information; and, through the first card organization network, use a preset cardholder authentication method to authenticate the cardholder based on the authentication information to obtain an authentication result; multiple card organizations use the same cardholder authentication method. Optionally, sending module 73 is further configured to, when the authentication result indicates that the cardholder's authentication has passed, send the transaction message to the issuing bank server. Optionally, processing module 74 is further configured to, through the issuing bank server, process the transaction to be processed based on the transaction message.

[0175] Optionally, the processing module 74 is further configured to, after sending the transaction message to the issuing bank's server through the first card organization network, determine anomaly factors through the first card organization network based on the card number of the transaction bank card and at least one of the transaction messages; the anomaly factors are factors that cause the transaction ciphertext version number to be different from the transaction ciphertext version number corresponding to the first card organization network.

[0176] Optionally, the processing module 74 is further configured to determine the target end for outputting the prompt information based on abnormal factors through the first card organization network; the target end for outputting the prompt information is at least one of a point-of-sale terminal management device, an acquiring institution terminal, and an issuing bank server. Optionally, the sending module 73 is further configured to send a prompt information to the target end for outputting the prompt information. The prompt information indicates that an abnormality exists at the target end for outputting the prompt information.

[0177] The transaction processing apparatus 70 provided in this application is used to execute the aforementioned transaction processing method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0178] Figure 8 is a schematic diagram of the hardware structure of an electronic device provided in this application. The electronic device 80 shown in Figure 8 includes a memory 81, a processor 82, and a communication interface 83. The memory 81, processor 82, and communication interface 83 are communicatively connected to each other. For example, the memory 81, processor 82, and communication interface 83 can be connected via a network. Alternatively, the electronic device 80 may also include a bus 84. The memory 81, processor 82, and communication interface 83 are communicatively connected to each other via the bus 84. Figure 8 shows an electronic device 80 in which the memory 81, processor 82, and communication interface 83 are communicatively connected to each other via the bus 84.

[0179] The memory 81 may be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 81 may store a program, which, when executed by the processor 82, enables the processor 82 and the communication interface 83 to perform the transaction processing method described in any of the foregoing embodiments. The memory may also store data required by the transaction processing method.

[0180] The processor 82 can be a general-purpose CPU, microprocessor, application-specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits.

[0181] Processor 82 can also be an integrated circuit chip with signal processing capabilities. In implementation, the transaction processing method of this application can be completed through integrated logic circuits in the hardware of processor 82 or through software instructions. The aforementioned processor 82 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the following embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the following embodiments of this application can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 81, and processor 82 reads information from memory 81 and, in conjunction with its hardware, completes the transaction processing method of this application.

[0182] The communication interface 83 uses transceiver modules, such as, but not limited to, transceivers, to enable communication between the electronic device 80 and other devices or communication networks. For example, a dataset can be acquired through the communication interface 83.

[0183] When the aforementioned electronic device 80 includes a bus 84, the bus 84 may include a path for transmitting information between various components of the electronic device 80 (e.g., memory 81, processor 82, communication interface 83).

[0184] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used in the methods described in the above embodiments.

[0185] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of an electronic device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the electronic device to implement the transaction processing methods provided in the various embodiments described above.

[0186] The term "multiple" in this document refers to two or more. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, the character " / " in this document generally indicates an "or" relationship between the preceding and following related objects; in formulas, " / " indicates a "division" relationship. Additionally, it should be understood that in the description of this application, words such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order.

[0187] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

[0188] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A transaction processing method, characterized in that, The method is applied to a transaction system, which includes: a card network of multiple card organizations, and an issuing bank server. The method includes: receiving a transaction message of a transaction to be processed through a first card network; the transaction message includes a transaction encrypted version number; the first card network is the card network of one of the multiple card organizations; determining, through the first card network, whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card network; if the transaction encrypted version number is not the transaction encrypted version number corresponding to the first card network, sending the transaction message to the issuing bank server through the first card network; and processing the transaction to be processed by the issuing bank server based on the transaction message.

2. The method according to claim 1, characterized in that, The transaction message also includes: the Bank Identifier (BIN) of the transaction bank card. Before determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network, the method further includes: determining whether the transaction bank card is a target type bank card based on the BIN of the transaction bank card through the first card organization network; the target type bank card is a bank card that has deployed applications of the multiple card organizations; determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network includes: if the transaction bank card is the target type bank card, determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network.

3. The method according to claim 2, characterized in that, The transaction message further includes: card carrier information of the transaction bank card; and when the transaction bank card is a bank card of the target type, determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network includes: when the transaction bank card is of the target type and the card carrier information is used to characterize the transaction bank card as a bank card with an embedded integrated circuit IC, determining whether the transaction encrypted version number is the transaction encrypted version number corresponding to the first card organization network through the first card organization network.

4. The method according to claim 3, characterized in that, Before receiving the transaction message of the transaction to be processed through the first card organization network, the method further includes: sending a network access application to the card organization networks of the plurality of card organizations through the issuing bank server; responding to the network access application through any one of the card organization networks of the plurality of card organizations by providing the issuing bank server with its public key certificate; and writing the issuing bank server's public key certificate and the IC card public key certificate of the transaction bank card into the transaction bank card through the issuing bank server, so that the point-of-sale terminal can complete offline verification with the transaction bank card based on the IC card public key certificate and the issuing bank server's public key certificate.

5. The method according to any one of claims 1-4, characterized in that, The transaction message also includes: an application identifier of the target application used by the point-of-sale terminal, and application ciphertext, wherein the target application is one of the applications of the plurality of card organizations; the step of processing the pending transaction based on the transaction message through the issuing bank server includes: determining the application ciphertext decryption key of the target application based on the application identifier of the target application through the issuing bank server; decrypting the application ciphertext based on the application ciphertext decryption key to obtain transaction information; performing security verification on the pending transaction based on the transaction information to obtain the security verification result of the pending transaction; and processing the pending transaction if the security verification result indicates that the pending transaction is not abnormal.

6. The method according to claim 5, characterized in that, The application's ciphertext decryption key is a symmetric key.

7. The method according to claim 5, characterized in that, The transaction information includes at least one of the following: the bank card number, the application identifier of the target application, the main account serial number bound to the target application, and a transaction counter.

8. The method according to any one of claims 1-4, characterized in that, Before determining whether the transaction ciphertext version number is the same as the transaction ciphertext version number corresponding to the first card organization network through the first card organization network, the method further includes: performing message protocol format verification on the transaction message through the first card organization network to obtain a protocol format verification result; and, when the protocol format verification result is used to indicate that the transaction message protocol format is correct, reading the target field of the protocol message through the first card organization network to obtain the transaction ciphertext version number.

9. The method according to any one of claims 1-4, characterized in that, The method further includes: when the transaction ciphertext version number is the transaction ciphertext version number corresponding to the first card organization network, parsing the transaction message through the first card organization network to obtain cardholder authentication information; using a preset cardholder authentication method through the first card organization network, authenticating the cardholder based on the authentication information to obtain an authentication result; the cardholder authentication method used by the multiple card organizations is the same; when the authentication result indicates that the cardholder's authentication is successful, sending the transaction message to the issuing bank server; and processing the pending transaction through the issuing bank server based on the transaction message.

10. The method according to any one of claims 1-4, characterized in that, After sending the transaction message to the issuing bank's server via the first card organization network, the method further includes: determining anomaly factors via the first card organization network based on the card number of the transaction bank card and at least one of the transaction messages; the anomaly factors are factors that cause the transaction ciphertext version number to be different from the transaction ciphertext version number corresponding to the first card organization network.

11. The method according to claim 10, characterized in that, The method further includes: determining the target terminal for outputting the prompting information based on the abnormal factors through the first card organization network; the target terminal for outputting the prompting information is at least one of a point-of-sale terminal management device, an acquiring institution terminal, and the issuing bank server; sending a prompting information to the target terminal for outputting the prompting information, the prompting information being used to indicate that there is an abnormality at the target terminal for outputting the prompting information.

12. A transaction processing apparatus, characterized in that, The device is applied to a transaction system, which includes a card network of multiple card organizations and an issuing bank server. The device includes: a receiving module for receiving a transaction message of a transaction to be processed via a first card network; the transaction message includes a transaction encrypted version number; the first card network is the card network of one of the multiple card organizations; a determining module for determining whether the transaction encrypted version number is the same as the transaction encrypted version number corresponding to the first card network; a sending module for sending the transaction message to the issuing bank server via the first card network if the transaction encrypted version number is not the same as the transaction encrypted version number corresponding to the first card network; and a processing module for processing the transaction to be processed based on the transaction message via the issuing bank server.

13. An electronic device, characterized in that, include: Processor and memory; The processor is communicatively connected to the memory; the memory stores computer instructions. The processor executes computer instructions stored in the memory to implement the method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-11.

Images