A method, device and storage medium for intelligent processing of UnionPay payment transactions

Abstract

The present invention relates to the field of UnionPay CUPS payment transaction, and provides a method, device and storage medium for intelligent processing of UnionPay payment transaction. The purpose is to solve the problems of large concurrent payment transaction volume, many hot accounts, decreased system performance, frequent alarms, etc. The main scheme includes that the payment transaction mode is batch-to-online mode, the message of the core credit entry check interface is assembled, and after obtaining the return transaction result of the core business system, if the transaction result is a transaction failure, the transaction failure response message is sent to UnionPay, and the transaction ends; if the transaction is successful, the topic value in the corresponding Kafka message queue is obtained, and then the core business system payment accounting message is assembled and stored in the topic corresponding to the message queue, and the batch transaction is set to be successful, and the response message is sent to UnionPay, and the transaction ends; the system daemon thread reads the messages in the Kafka queue under the corresponding topic respectively, and sends them to the core business system for payment accounting processing.

Description

Technical Field

[0001] The present invention relates to the field of UnionPay CUPS payment-on-behalf transaction, and provides a method, device and storage medium for intelligent processing of UnionPay payment-on-behalf transaction. Background Art

[0002] In the existing transaction processing process, the payment transaction message is received and parsed, and the transaction type is determined according to the type field. If it is in online mode, it is sent to the core accounting and then assembled into a UnionPay message and sent to UnionPay, and the transaction is completed. If it is in batch mode, it enters a loop to call the core accounting, and after the end, it assembles the UnionPay message and sends it to UnionPay. The concurrent payment transaction volume is large and there are many hot accounts. This leads to the following problems:

[0003] 1. System performance degrades;

[0004] 2. New transaction requests cannot be processed in time, resulting in a timeout for the requester;

[0005] 3. Batch transactions call core accounting in a loop, the thread execution time is long (batch requests for core accounting cause the core response to slow down), and the number of system threads reaches more than 2,000, resulting in problems such as system CPU usage and frequent transaction timeout alarms.

[0006] The specific problems are as follows:

[0007] 1. When the number of concurrent transactions is large, system performance degrades, interface service processing takes a long time, and subsequent transactions time out;

[0008] 2. Alarms appear frequently. Summary of the invention

[0009] In view of the above-mentioned research problems, the purpose of the present invention is to provide a method for intelligent processing of UnionPay payment (card issuing side) transactions.

[0010] In order to achieve the above object, the present invention adopts the following technical solution:

[0011] An intelligent processing method for UnionPay payment transaction, comprising the following steps:

[0012] Step 1: After receiving the message sent by UnionPay, according to the mtype, F3 field value, identify it as a payment transaction, parse the 60.2.5 field value and the F002 field value of the account number in the 8583 message, and determine the payment transaction mode according to the 60.2.5 field value. If the 60.2.5 field value is 20, it is determined to be a batch-to-online payment mode, and the batch-to-online payment mode is used. Otherwise, the ordinary online payment mode is used;

[0013] Step 2: Continue with step 1. If the payment transaction mode is the normal online mode, parse the 8583 message, check the payment business logic, assemble the core payment accounting message, send it to the core accounting, obtain the accounting result, assemble the UnionPay payment response message, send it to UnionPay, and the transaction is completed;

[0014] Step 3: Continue with step 1. If the payment transaction mode is batch-to-online mode, parse the 8583 message, check the payment logic, assemble the core payment check interface (no accounting), and obtain the transaction result. If the transaction fails, directly assemble the failure response message and send it to UnionPay to end the transaction. If the transaction is successful, proceed to step 4.

[0015] Step 4: Continue with step 3. If the payment check interface is successful, calculate the hash value of the account number, obtain the corresponding topic value in the Kafka message queue according to the topic mapping table, and then assemble the core payment accounting message and store it in the topic corresponding to the message queue. Set the transaction to success, assemble the UnionPay response message, and send it to UnionPay. The transaction is completed.

[0016] Step 5: Continue from step 4. According to the number of topics, start the corresponding Java daemon thread, read the messages in the Kafka queue under the corresponding topic respectively, convert the messages into the core payment accounting interface format, and send them to the core for payment accounting processing. If the core transaction accounting is successful, the transaction processing is completed. If the core transaction accounting fails, the error processing table is registered and timely processed in step 6.

[0017] Step 6: Continue with step 5. If the accounting processing of the core payment transaction fails, an SMS alert will be sent to the operation personnel. The operation management personnel will log in to the system to query the error processing data within a certain time range and confirm the cause of the error processing. If it is a system problem, the payment accounting can be initiated again; if it is due to account or customer restrictions, resulting in failure of accounting, it can be transferred to the UnionPay platform for error adjustment processing after evaluation.

[0018] Compared with the prior art, the present invention has the following beneficial effects:

[0019] 1. The present invention is based on the transaction mode to realize the batch-to-online mode and ensure the orderly processing of batch transactions.

[0020] Second, based on the topic value in the Kafka message queue, the present invention starts the corresponding Java daemon thread according to the number of topics, and reads the messages in the Kafka queue under the corresponding topic respectively. The daemon thread mode is adopted to accurately and efficiently process transactions, thereby ensuring the stability of the entire transaction system.

[0021] 3. The present invention uses Kafka message queue to buffer large concurrency, improve system concurrency capability, improve interface response time, and improve the processing capability of the payment service platform. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is a schematic diagram of the process of the present invention. DETAILED DESCRIPTION

[0023] The above are only representative embodiments of the present invention in many specific application scopes, and do not constitute any limitation on the protection scope of the present invention. Any technical solutions formed by transformation or equivalent replacement fall within the protection scope of the present invention.

[0024] Existing professional terminology explanation:

[0025] 8583 message: 8583 protocol is a communication protocol based on the ISO8583 message international standard packet format. 8583 packets are composed of up to 128 fields. Each field has a unified regulation and can be either fixed-length or variable-length. The first section of the 8583 packet is a bitmap, which is the key to determine the field field during packaging and unpacking. 8583 protocol is mostly used in the development of POS machines.

[0026] mtype: message type "message type identifier".

[0027] 60.2.5 Domain: "Terminal Type" values ​​00 unknown, 01 automatic teller machine, 03 wired point-of-sale terminal, 05 multimedia terminal, 06 bank counter and counter, 07 personal computer, 08 mobile device, 09 Type I fixed-line telephone, 11 wireless point-of-sale terminal, 12 China UnionPay public service platform, 13 migrant workers bank special services, 14 merchant system, 15 third-party institution system, 16 digital set-top box, 17 Type II fixed-line telephone, 20 batch file processing system.

[0028] Core business system: refers to the core business system of banks in the financial industry. Core banking systems are customer-centric, perform account processing, meet the comprehensive teller system, and provide 24-hour service. Core payment accounting interface: the full name is "core system general accounting interface", provided by the core business system, and its function is to process customer accounts (add or subtract funds);

[0029] Core credit entry check interface: an interface provided by the core business system. Its function is to check the success of transaction information before calling the "core payment accounting interface" to improve the accuracy of the "core payment accounting" transaction.

[0030] The present invention provides an intelligent processing method for UnionPay payment transaction, which is characterized by comprising the following steps:

[0031] Step 1: The routing layer of the payment system (based on dubbo microservice communication) determines the message sent by UnionPay. After identifying it as a payment transaction based on the mtype and F3 field values, parse the 60.2.5 field value and the value of the F002 field of the account number in the 8583 message, and determine the mode of the payment transaction based on the value of the 60.2.5 field. If the 60.2.5 field value is 20, it is determined to be a batch-to-online payment mode, and the batch-to-online payment mode is used, and sent to the "batch-to-online mode" service for processing. Otherwise, the ordinary online payment mode is used and sent to the "online payment mode" service for processing;

[0032] Step 2: If the payment transaction mode is the normal online mode, parse the 8583 message, check the payment business logic, assemble the core payment accounting message, send it to the core accounting, obtain the accounting result, assemble the UnionPay payment response message, send it to UnionPay, and the transaction is completed;

[0033] Step 3: If the payment transaction mode is batch-to-online mode, parse the 8583 message, check the payment logic, assemble the message of the core credit check interface (without accounting), and obtain the transaction result returned by the core business system. If the transaction result is a transaction failure, directly assemble the response message of the failure of the core credit check interface ("response message" refers to the failure returned by the "core credit check interface", and the current transaction fails.) Send it to UnionPay and the transaction ends; if the transaction is successful, proceed to step 4.

[0034] Step 4: If the transaction result returned by the core business system is a successful transaction, the core credit entry check interface is successful ("core credit entry check" has two results, 1. Failure (in step 3); 2. Success (here, success requires the information to be put into Kafka), then calculate the hash value of the entry account, obtain the corresponding topic value in the Kafka message queue according to the topic mapping table, and then assemble the core business system payment accounting message and store it in the topic corresponding to the message queue, set this batch transaction to success, assemble the UnionPay response message, and send it to UnionPay, and the transaction ends;

[0035] Step 5: According to the number of topics, start the corresponding Java daemon thread, read the messages in the Kafka queue under the corresponding topic respectively, convert the messages into the core payment accounting interface format, and send them to the core business system for payment accounting processing. If the payment transaction accounting is successful, the transaction processing is completed. If the core transaction accounting fails, the error processing table is registered and timely processed in step 6.

[0036] Step 6: If the payment transaction fails to be recorded, an SMS alert will be sent to the operation staff. The operation management staff will log in to the system to query the error processing data within a certain time range and confirm the cause of the error processing. If it is a system problem, the payment can be initiated again. If the account entry fails due to account or customer restrictions, it can be transferred to the UnionPay platform for error adjustment after evaluation.

[0037] Because the present invention adopts the above technical solution, it has the following beneficial effects: 1. Online and batch transactions are processed separately.

[0038] 2. Batch transactions are buffered by Kafka to avoid calling the core at the same time.

[0039] 3. The controllable number of threads reduces CPU usage and improves system throughput.

[0040] 4. Batch transaction data is first sent to the core for verification to reduce the failure rate. Subsequent failures can be transferred to manual error processing.

Claims

1. An intelligent processing method for UnionPay payment transactions, characterized in that: The steps include: Step 1: The payment system routing layer determines the message sent by UnionPay. After identifying the message as a payment transaction, the domain value in the 8583 message is parsed to determine the mode of the payment transaction. If it is a batch transfer to online mode, it is sent to the "batch transfer to online mode" service for processing. If it is a common online payment mode, it is sent to the "online payment mode" service for processing; Step 2: If the payment transaction mode is the normal online mode, parse the 8583 message, check the payment business logic, assemble the core payment accounting message, send it to the core accounting, obtain the accounting result, assemble the UnionPay payment response message, send it to UnionPay, and the transaction is completed; Step 3: If the payment transaction mode is batch-to-online mode, parse the 8583 message, check the payment logic, assemble the core credit check interface message and send it to the core business system for transaction data check, and obtain the transaction result returned by the core business system. If the transaction result is a transaction failure, directly assemble the response message of the core credit check interface failure, send the assembled response message to UnionPay, and the transaction ends; if the transaction is successful, proceed to step 4; Step 4: If the transaction result returned by the core business system is a successful transaction, the core credit entry check interface is successful, and the hash value of the entry account is calculated. According to the topic mapping table, the topic value in the corresponding Kafka message queue is obtained, and then the core business system payment accounting message is assembled and stored in the topic corresponding to the message queue. The batch transaction is set to be successful, and the response message of the successful transaction is assembled. The assembled response message is sent to UnionPay, and the transaction is completed; Step 5: According to the number of topics, start the corresponding Java daemon thread, read the messages in the Kafka queue under the corresponding topic, convert the messages into the core payment accounting interface format, and send them to the core business system for payment accounting processing. If the payment transaction accounting is successful, the transaction processing is completed. If the payment transaction accounting fails, the error processing table is recorded and timely processed in step 6; Step 6: If the payment transaction fails to be recorded, an SMS alert will be sent to the operation staff. The operation management staff will log in to the system to query the error processing data within a certain time range and confirm the cause of the error processing. If it is a system problem, the payment recording can be initiated again; if it is due to account or customer restrictions, resulting in a failure in the account entry, it can be transferred to the UnionPay platform for error adjustment processing after evaluation.

2. The intelligent processing method for UnionPay payment transaction according to claim 1, characterized in that: Step 1 specifically includes: Step 1: At the routing layer of the payment system, determine the message sent by UnionPay, and after identifying it as a payment transaction according to the mtype and F3 field values, parse the 60.2.5 field value and the value of the F002 field of the account number in the 8583 message, and determine the mode of the payment transaction according to the value of the 60.2.5 field. If the 60.2.5 field value is 20, it is determined to be a batch-to-online payment mode, and the batch-to-online payment mode is used, and it is sent to the "batch-to-online mode" service for processing. Otherwise, the ordinary online payment mode is used and it is sent to the "online payment mode" service for processing.

3. An intelligent processing device for UnionPay payment transactions, characterized in that: include: Mode judgment module: judges the message sent by UnionPay at the payment system routing layer, identifies the message as a payment transaction, and parses the domain value in the 8583 message to determine the mode of the payment transaction. If it is a batch transfer online mode, it is sent to the "batch transfer online mode" service for processing; if it is a common online payment mode, it is sent to the "online payment mode" service for processing; Ordinary online module: If the payment transaction mode is ordinary online mode, parse the 8583 message, check the payment business logic, assemble the core payment accounting message, send it to the core accounting, obtain the accounting result, assemble the UnionPay payment response message, send it to UnionPay, and the transaction ends; Batch transfer module: If the payment transaction mode is batch transfer mode, the 8583 message is parsed, and after checking the payment logic, the message of the core credit check interface is assembled. After obtaining the transaction result returned by the core business system, if the transaction result is a transaction failure, the response message of the failure of the core credit check interface is directly assembled, and the assembled response message is sent to UnionPay, and the transaction ends; if the transaction is successful, it enters the cache module for processing; Cache module: If the transaction result returned by the core business system is a successful transaction, the core credit entry check interface is successful, and the hash value of the entry account is calculated. According to the topic mapping table, the topic value in the corresponding Kafka message queue is obtained, and then the core business system payment accounting message is assembled and stored in the topic corresponding to the message queue. The batch transaction is set to be successful, and the response message of the successful transaction is assembled. The assembled response message is sent to UnionPay, and the transaction is completed; Payment accounting processing module: According to the number of topics, the corresponding Java daemon thread is started, and the messages in the Kafka queue under the corresponding topic are read respectively, and the messages are converted into the core payment accounting interface format, and sent to the core business system for payment accounting processing. If the payment transaction accounting is successful, the transaction processing is completed. If the payment transaction accounting fails, the error processing table is recorded.

4. The intelligent processing device for UnionPay payment transactions according to claim 3, characterized in that: Mode judgment module: The payment system routing layer judges the message sent by UnionPay, and after identifying it as a payment transaction according to the mtype and F3 field values, parses the 60.2.5 field value and the F002 field value of the account number in the 8583 message, and judges the mode of the payment transaction according to the 60.2.5 field value. If the 60.2.5 field value is 20, it is judged as a batch-to-online payment mode, and the batch-to-online payment mode is used, and it is sent to the "batch-to-online mode" service for processing. Otherwise, the ordinary online payment mode is used and it is sent to the "online payment mode" service for processing.

5. A storage medium, characterized in that: The storage medium stores a program for intelligent processing of UnionPay payment transactions. When the processor executes the program, it implements an intelligent processing method for UnionPay payment transactions as described in any one of claims 1-2.

Images