CN109246188B

CN109246188B - System supporting multi-channel transaction and multi-channel transaction processing method

Info

Publication number: CN109246188B
Application number: CN201810880008.XA
Authority: CN
Inventors: 吴裕
Original assignee: China Unionpay Data Services Co ltd
Current assignee: China Unionpay Data Services Co ltd
Priority date: 2018-08-03
Filing date: 2018-08-03
Publication date: 2022-04-29
Anticipated expiration: 2038-08-03
Also published as: CN109246188A

Abstract

The invention discloses a system for supporting multi-channel transaction and a method for processing the multi-channel transaction, wherein the system comprises: the system comprises a communication subsystem and a service processing subsystem, wherein the communication subsystem is connected with a transaction channel, the service processing subsystem is connected with a banking system, the communication subsystem receives a transaction request message sent by the transaction channel and performs message format conversion on the transaction request message according to transaction service in the transaction request message, and the service processing subsystem sends the transaction request message after the message format conversion to the banking system corresponding to the transaction service in the transaction request message for processing. The system can receive transaction request information of various transaction channels, and realizes the connection of the various transaction channels and the banking system.

Description

System supporting multi-channel transaction and multi-channel transaction processing method

Technical Field

The embodiment of the invention relates to the technical field of computer data processing, in particular to a system supporting multi-channel transaction and a multi-channel transaction processing method.

Background

The service means Of the bank is developed from the traditional counter to the current Automatic Teller Machine (ATM), Point Of Sale (POS), mobile phone bank, Integrated Circuit (IC) counter, unionpay transaction system, etc., and the above-mentioned various transaction channels may need different communication protocols to interface with the banking system, such as hypertext transfer Protocol (HTTP), Simple Object Access Protocol (Simple Object Access Protocol, SOAP), Transmission Control Protocol (Transmission Control Protocol, TCP), etc., and the transaction request message formats sent by the transaction channels are also different, and the message formats include fixed length format, variable length format, delimiter, 8583 format, field Control language format, ethernet Protocol message format, etc.

Therefore, there is a need for a system compatible with multiple transaction channels for receiving transaction request information from multiple transaction channels to connect the multiple transaction channels to a banking system.

Disclosure of Invention

The embodiment of the invention provides a system supporting multi-channel transaction and a multi-channel transaction processing method, which are used for receiving transaction request information of various transaction channels and realizing the connection between the various transaction channels and a banking system.

The system for supporting multi-channel transaction provided by the embodiment of the invention comprises: a communication subsystem and a service processing subsystem; the communication subsystem is connected with a transaction channel, and the business processing subsystem is connected with a banking business system;

the communication subsystem receives a transaction request message sent by the transaction channel and performs message format conversion on the transaction request message according to transaction service in the transaction request message;

and the business processing subsystem sends the transaction request message after message format conversion to a banking business system corresponding to the transaction business in the transaction request message for processing.

In the above embodiment, the communication subsystem receives transaction request messages sent by different transaction channels, performs format conversion on the message format of the transaction request message according to the transaction service corresponding to the transaction request message, and sends the converted transaction request message to the corresponding banking system through the service processing subsystem.

Optionally, the communication subsystem includes a communication interface module and a message conversion module; the communication interface module is connected with the transaction channel and used for receiving transaction request messages sent by the transaction channel, and the message conversion module is used for converting message formats of the transaction request messages.

In the above embodiment, the communication interface module supports multiple communication protocols, and is configured to receive transaction request messages sent by each transaction channel; according to the banking business system corresponding to the transaction business in the transaction request message, the message conversion module performs message format conversion on the received transaction request message, namely converts the transaction request message into a message format which can be analyzed by the corresponding banking business system.

Optionally, the transaction channel is an ATM/POS; the banking system comprises a unionpay system, credit card systems of all banks and debit card systems of all banks;

the communication subsystem receives a transaction request message sent by the ATM/POS through a TCP protocol, judges whether a card issuing bank of a transaction bank card and a bank to which the ATM/POS belongs are the same bank, and if so, converts the message format of the transaction request message into a message format matched with a debit card system of the card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be debit card service;

otherwise, the message format of the transaction request message is converted into the message format matched with the Unionpay system.

And the communication subsystem converts the message format of the transaction request message into a message format matched with a credit card system of a card issuing bank of the transaction bank card when determining that the transaction service in the transaction request message is credit card service.

In the above embodiment, the transaction channel may be an ATM/POS, and when receiving a transaction request message sent by the ATM/POS, it may be determined whether a card issuing bank of the transaction bank card and a bank to which the ATM/POS belongs are the same bank, and then it is determined whether a transaction service in the transaction request message is a debit card service or a credit card service, and a message format of the transaction request message is converted for different transaction request messages or for different banking systems.

Optionally, the system further includes a platform software function library (IPP);

the transaction channel is a mobile terminal/integrated circuit IC card counter machine corresponding to a mobile phone bank; and the communication subsystem is connected with a mobile terminal/IC card counter machine corresponding to the mobile phone bank through the IPP.

In the above embodiment, the IPP may receive a transaction request message sent by a mobile terminal/IC card counter corresponding to a mobile banking, and forward the message to the communication subsystem, that is, the communication subsystem may be connected to the mobile terminal/IC card counter corresponding to the mobile banking through the IPP.

Optionally, the transaction channel is a mobile terminal corresponding to a mobile banking; the banking system is a credit card system of each bank;

and the communication subsystem receives the transaction request message transmitted by the mobile terminal corresponding to the mobile phone bank and forwarded by the IPP through a TCP protocol, and converts the message format of the transaction request message into a message format matched with a credit card system of the bank corresponding to the mobile phone bank.

In the above embodiment, the communication subsystem receives, through the IPP, a transaction request message sent by a mobile terminal corresponding to a mobile banking, and if a transaction service in the transaction request message corresponds to a banking credit card system, the communication subsystem converts a format of the transaction request message into a format matched with the banking credit card system.

Optionally, the transaction channel is an IC card counter machine; the banking system is an electronic cash account system of each bank;

and the communication subsystem receives the transaction request message transmitted by the IC card counter machine and forwarded by the IPP through a TCP protocol, and converts the message format of the transaction request message into a message format matched with an electronic cash account system of a bank to which the IC card counter machine belongs.

In the above embodiment, the communication subsystem receives a transaction request message sent by the IC card counter through the IPP, and the format of the transaction request message is converted into a format adapted to the electronic cash account system when the transaction service in the transaction request message corresponds to the electronic cash account system.

Optionally, the transaction channel is a unionpay transaction system; the banking system comprises a debit card system of each bank and a credit card system of each bank;

the communication subsystem receives a transaction request message sent by the Unionpay transaction system through an HTTP protocol, and converts the message format of the transaction request message into a message format matched with a debit card system of a card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be debit card service;

and the communication subsystem receives a transaction request message sent by the Unionpay transaction system through an HTTP protocol, and converts the message format of the transaction request message into a message format matched with a credit card system of a card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be the credit card service.

In the above embodiment, the communication subsystem receives the transaction request message sent by the union pay transaction system, determines whether the transaction service in the transaction request message sent by the union pay transaction system is debit card service or credit card service, and converts the format of the message according to different banking systems.

Optionally, the system further comprises a data monitoring module and a tool management subsystem;

the data monitoring module comprises a transaction monitoring module, a resource monitoring module, an early warning notification module and a monitoring rule management module; the transaction monitoring module monitors the transaction process of the system; the resource monitoring module monitors system hardware resources; the early warning notification module provides early warning issuing means in the forms of sound, color, bullet frame and short message; the monitoring rule management module carries out parameterized configuration on the monitoring rules of the transaction monitoring module, the resource monitoring module and the early warning notification module;

the machine tool management subsystem comprises an equipment management module, a key management module, a terminal state monitoring module and a cash management module; the equipment management module carries out transaction control and Internet Protocol (IP) address verification on a transaction terminal corresponding to the transaction channel; the key management module distributes a management key to the transaction terminal corresponding to the transaction channel; the terminal state monitoring module monitors and manages the state of the transaction terminal corresponding to the transaction channel; the cash management module is matched with the ATM cash box to perform cash management.

In the above embodiment, a data monitoring module and an implement management subsystem are provided, where the data monitoring module includes a transaction monitoring module, a resource monitoring module, an early warning notification module and a monitoring rule management module, and the implement management subsystem includes an equipment management module, a key management module, a terminal state monitoring module and a cash management module, which are used to ensure normal operation of transaction service and early warning in time.

Correspondingly, the embodiment of the invention also provides a method for processing the multi-channel transaction, which comprises the following steps:

receiving a transaction request message sent by a transaction channel, and performing message format conversion on the transaction request message according to a transaction service in the transaction request message;

and sending the transaction request message after the message format conversion to a banking system corresponding to the transaction service in the transaction request message for processing.

the receiving transaction request message sent by a transaction channel, and performing message format conversion on the transaction request message according to transaction service in the transaction request message includes:

receiving a transaction request message sent by the ATM/POS through a TCP protocol, judging whether a card issuing bank of a transaction bank card and a bank to which the ATM/POS belongs are the same bank, if so, converting the message format of the transaction request message into a message format matched with a debit card system of the card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be debit card service;

Optionally, the method further includes:

and when the transaction service in the transaction request message is determined to be credit card service, converting the message format of the transaction request message into a message format matched with a credit card system of a card issuing bank of the transaction bank card.

and receiving the transaction request message transmitted by the mobile terminal corresponding to the mobile phone bank and forwarded by the IPP through a TCP protocol, and converting the message format of the transaction request message into a message format matched with a credit card system of the bank corresponding to the mobile phone bank.

and receiving the transaction request message transmitted by the IC card counter machine and forwarded by the IPP through a TCP protocol, and converting the message format of the transaction request message into a message format matched with an electronic cash account system of a bank to which the IC card counter machine belongs.

receiving a transaction request message sent by the Unionpay transaction system through an HTTP (hyper text transport protocol), and converting the message format of the transaction request message into a message format matched with a debit card system of a card issuing bank of a transaction bank card when the transaction service in the transaction request message is determined to be debit card service;

and receiving a transaction request message sent by the Unionpay transaction system through an HTTP (hyper text transport protocol), and converting the message format of the transaction request message into a message format matched with a credit card system of a card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be credit card service.

Correspondingly, an embodiment of the present invention further provides a computing device, including:

a memory for storing program instructions;

and the processor is used for calling the program instructions stored in the memory and executing the multi-channel transaction processing method according to the obtained program.

Accordingly, embodiments of the present invention also provide a computer-readable non-volatile storage medium, which includes computer-readable instructions, and when the computer reads and executes the computer-readable instructions, the computer is caused to execute the above method for processing multi-channel transactions.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a diagram illustrating a system architecture for supporting multi-channel transactions according to an embodiment of the present invention;

fig. 2 is a schematic structural diagram of a communication subsystem according to an embodiment of the present invention;

fig. 3 is a schematic structural diagram of a data monitoring module according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of a tool management subsystem according to an embodiment of the present invention;

FIG. 5 is a schematic architectural diagram of a transaction execution platform according to an embodiment of the present invention;

FIG. 6 is a flow chart illustrating a method for multi-channel transaction processing according to an embodiment of the present invention;

FIG. 7 is a flow chart illustrating a transaction channel being an ATM according to an embodiment of the present invention;

fig. 8 is a schematic flow chart of a mobile terminal corresponding to a mobile banking transaction channel according to an embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Fig. 1 shows a system 100 for supporting multi-channel transaction according to an embodiment of the present invention, which includes a communication subsystem 101 and a service processing subsystem 102, wherein the communication subsystem 101 is connected to a transaction channel 200, and the service processing subsystem 102 is connected to a banking system 300.

The communication subsystem 101 receives the transaction request message sent by the transaction channel 200, and performs message format conversion on the transaction request message according to the transaction service in the transaction request message. The business processing subsystem 102 sends the transaction request message after the message format conversion to the banking business system 300 corresponding to the transaction business in the transaction request message for processing.

As shown in fig. 2, the communication subsystem 101 includes a communication interface module 1011 and a message conversion module 1012, the communication interface module 101 is connected to the transaction channel 200 and is configured to receive a transaction request message sent by the transaction channel 200, and the message conversion module 1012 performs message format conversion on the transaction request message, that is, according to a transaction service in the transaction request message, the format of the transaction request message is converted into a format adapted to the banking system 300 corresponding to the requested service.

The communication interface module 1011 may support an HTTP protocol, a SOAP protocol, a TCP protocol, etc., and the message conversion module 1012 may convert a fixed length format, a variable length format, a delimiter, an 8583 format, a field control Language format, an ethernet protocol message format, etc. into an Extensible Markup Language (XML) format.

In other words, the communication subsystem 101 may include a communication component and an analysis component, where the communication component is used to connect to each transaction channel and receive a transaction request message sent by each transaction channel, as specifically shown in table 1; the parsing component is configured to convert the message format into a message format that is resolvable by a banking system corresponding to the parsing component, which is specifically shown in table 2.

TABLE 1

TABLE 2

The transaction channel 200 may include a mobile terminal 201, an IC counter 202, an ATM/POS203, a union pay transaction system 204, etc. corresponding to a mobile banking, when different transaction channels 200 are connected to the communication subsystem 101, messages with different formats may be sent through different transmission protocols, and meanwhile, the banking system 300 may include a union pay system 301, a credit card system 302 of each bank, a debit card system 303 of each bank, an electronic cash account system 304 of each bank, and message formats that may be received by different banks and business systems of different banks may also be different, so that the communication subsystem 101 needs to convert the message format of the received transaction request message into a message format that may be resolved by the banking system 300 corresponding to the transaction request message according to the transaction service in the transaction request message.

When the transaction channel 200 is an ATM or when the transaction channel 200 is a POS, the format of the transaction request message sent by the ATM or the POS and the communication protocol used are the same, so the case where the transaction channel 200 is an ATM or a POS is described as an embodiment. When the transaction channel 200 is an ATM/POS203, the corresponding banking system 300 includes a unionpay system 301, credit card systems 302 of banks, and debit card systems 303 of banks, that is, the transaction service in the transaction request message sent by the ATM/POS203 is the banking service requesting the unionpay system 301, the credit card systems 302 of banks, and the debit card systems 303 of banks.

Specifically, the communication subsystem 101 receives a transaction request message sent by the ATM/POS203 through a TCP protocol, where the transaction request message is an 8583 message sent by the ATM/POS203, and the communication subsystem 101 first determines whether a card issuing bank of a transaction bank card and a bank to which the ATM/POS203 belongs are the same bank, and then determines whether the transaction request is a debit card service or a credit card service.

When the communication subsystem 101 determines that the card issuing bank of the transaction bank card and the bank to which the ATM/POS203 belongs are the same bank, when the transaction service in the transaction request message is determined to be a debit card service, the message format of the transaction request message is converted into a message format adapted to the debit card system 303 of the card issuing bank of the transaction bank card, which is equivalent to converting the 8583 message sent by the ATM/POS203 into a message adapted to the debit card system 303 of the card issuing bank of the transaction bank card, and the converted message may be an XML message of the debit card system 303.

For example, after the user holds a debit card of a Chinese bank to go to the ATM 203 of the Chinese bank to draw money, and the communication subsystem 101 determines that the card issuing bank of the debit card and the bank to which the ATM 203 belongs are the same bank, the 8583 message sent by the ATM 203 can be converted into an XML message of the debit card system 303 of the Chinese bank. In addition, when the transaction service in the transaction request message received by the communication subsystem 101 is a credit card service, the message format of the transaction request message is converted into a message format adapted to the credit card system 302 of the card issuing bank of the transaction bank card, which is equivalent to converting the 8583 message sent by the ATM/POS203 into a message adapted to the credit card system 303 of the card issuing bank of the transaction bank card, and the converted message may be a fixed-length message of the credit card system 303.

When the communication subsystem 101 determines that the card issuing bank of the transaction bank card is not the same bank as the bank to which the ATM/POS203 belongs, the ATM/POS203 is connected with the card issuing bank of the transaction bank card through the unionpay system 301, that is, the communication subsystem 101 converts the message format of the transaction request message into the message format adapted to the unionpay system 301, which is equivalent to converting the 8583 message sent by the ATM/POS203 into the message adapted to the unionpay system, and the converted message may be the unionpay 8583 message.

After the communication subsystem 101 converts the format of the message, the service processing subsystem 102 sends the transaction request message after the format conversion to the banking system 300 corresponding to the transaction service in the transaction request message for processing, and according to the different transaction services or the banking system 300, the specific steps are as follows:

the business processing subsystem 102 sends the XML message of the debit card system 303 to the debit card system 303 of the card issuing bank of the transaction bank card through a SOAP protocol;

the business processing subsystem 102 sends the fixed-length message of the credit card system 302 to the credit card system 302 of the card issuing bank of the transaction bank card through a TCP protocol;

the service processing subsystem 102 sends the union pay 8583 message of the union pay system 301 to the union pay system 301 through the TCP protocol.

Optionally, the transaction request message sent by the POS203 includes three parts, namely, a Protocol Data Unit (TPDU), a message header, and application Data, as shown in table 3.

TABLE 3

TPDU description: the length is 5 bytes.

Message header description: the total length is 12 bytes, and the code is represented as a Binary-Coded Decimal (BCD) number with a length of 6 bytes when compressed.

In the transaction request message sent by the POS203, the value is filled in the application type, the software version number and the terminal state according to the POS203 terminal parameter and the current state when being packed and sent by the terminal application of the POS203, and is used for the POS center to perform corresponding processing according to the value.

In the response message returned by the POS center, the POS center fills the processing requirement, other domains keep the original value to return, and the POS carries out corresponding processing according to the processing requirement in the received message header.

The message header takes the following values:

application class definition: currently, only the magnetic stripe card financial payment class application is defined as 60.

The software version number is shown in table 4, the terminal state is shown in table 5, and the processing requirements are shown in table 6.

And (3) reserving and using: temporarily not used, and filled with "0".

TABLE 4

TABLE 5

Terminal state	Means of
		0	Normal transaction state
1	Testing transaction status

TABLE 6

Processing requirement coding	Specification of processing requirements
		0	No processing requirement
1	Downloading terminal parameters
		2	Uploading terminal state information
3	Check-in again

Description of the application data: the application data is transaction data in 8583 financial exchange information format in accordance with the International Organization for Standardization (ISO), which is described in detail in the specification of message interface at POS terminal for data of union pay.

Optionally, the transaction request message sent by the ATM 203 includes: a packet header, a packet type identifier, a bitmap, and a packet field. The structure is shown in table 7.

TABLE 7

Message header

Message type identification

Bitmap

Message domain

Wherein the total length of the packet is the first data element of the packet. The total message length, the message header, the message type identifier, the bitmap and the message field form a complete message.

The header is the first data element of the message. The message header, the message type identifier, the bitmap and the message field form a complete message.

The message type identifier is a second data element of the message, is a highest-level message type definition, and defines a general classification of the message, such as a financial type message or a management type message. The message type identifier is four bytes in length. Each message requires a message type identifier.

The bitmap defines which message fields will appear in the message. The bitmap area contains two bitmaps. Bitmap one defines fields 2 through 64 and bitmap two defines fields 65 through 128.

The message domain constitutes the main body of the message, most of which is defined by ISO8583, and the other domains are customized and used by the China union System (CUPS).

For the message header in the transaction request message sent by the ATM 203, the value is filled in the application type, the specification version number and the terminal state according to the terminal parameter and the current state of the ATM 203 when the terminal application program of the ATM 203 packages and sends the value, and the value is used for the ATM to carry out corresponding processing according to the value.

The header remains as it is returned when the response message is processed by the ATM 203 and the ATM preamble. Table 8 shows the specific composition of the header, which occupies 16 bytes.

TABLE 8

Total length of message	Application classes	Standardized version number	Terminal state	Reserve use
					N4	n2	n2	n1	n7

The total length of the packet is the first element of the header, representing the length of the entire packet, and this value is 4 bytes.

The application type is the second element of the message header, which represents the type of the following message, the length is 2 bytes, and the access module decides the route according to the domain. Specific value definitions are shown in table 9.

TABLE 9

The specification version number is the third element of the header of the packet, and indicates which specification the packet adopts, and the length is 2 bytes. Specific value definitions are shown in table 10.

Watch 10

Value of	Means of
		01	2003 China Unionpay ATM application specification version

The terminal state is the fourth element of the header of the message, which represents the transaction state represented by the message, and has a length of 1 byte. Specific value definition table 11 shows.

TABLE 11

Value of	Means of
		0	Normal transaction state
1	Testing transaction status

The reserved use is the fifth element of the message header, the reserved use is not used for the moment, the default is filled with '0', and the length is 7 bytes.

For the bitmaps in the transaction request messages sent by ATM 203, the length of the transmitted messages in the network is varied, with the bitmaps identifying which fields are in the message and which are not. There may be one or two bitmaps in a message, the number of bitmaps being determined according to the type of transaction.

(1) First bitmap

Each message has a first bitmap, the master bitmap. It consists of 64 binary bits (8 bytes) and is located after the message type identifier. Except for the first bit, each bit corresponds to a field, namely field 2 through field 64. The value of each bit indicates whether the field is present in the message:

if a bit is 0, the field associated with it is not present in the message.

If a bit is 1, the field associated with it appears in the message.

The field with field number 1 is the second bitmap, so the first bit of the basic bitmap is used to indicate whether there is a second bitmap after the main bitmap.

(2) Second bit map

The first bit of the master bitmap indicates whether there is a second bitmap, bitmap two, after the master bitmap. Like the master bitmap, bitmap two is also made up of 64 binary bits (eight bytes). The bitmap is considered an extension of the master bitmap and is associated with fields 65 to 128.

Bitmap two is only used if the message contains fields 65 through 128. The second bitmap is immediately adjacent to the master bitmap and before the message field. Each bit corresponds to a field, i.e. to the fields 65 to 128. The value of each bit indicates whether the field is present in the message:

if a bit is 0, the field associated with it is not present in the message.

If a bit is 1, the field associated with it appears in the message.

Further, the present embodiment describes the generation of the header and the usage of each domain thereof in detail. "b" in the description means bit; "n" represents a decimal number. In addition, all digital codes in this embodiment adopt an ASCII encoding method.

In binary representation, the bits arranged on the left are high order bits, and the bits arranged on the right are low order bits.

The message header, the message type identifier, the bitmap and the message field form a complete message. The standard message header has a fixed length and consists of 9 fields.

The ISO8583 message sent by the bank to the transaction system has this header, and all fields are mandatory fields, as shown in table 12.

TABLE 12

Domain	Domain name	Length (Unit: Byte)
			Field1	Head Length (Header Length)	1
Field2	Header identification and Version number (Header Flag and Version)	1
			Field3	Entire Message Length (Total Message Length)	4
Field4	Destination ID (destination ID)	11
			Field5	Source ID (Source ID)	11
Field6	Message Status identification (Message Status Flags)	3
			Field7	Batch Number (Batch Number)	1
Field8	Reserved for Use (Reserved for Use)	8
			Field9	User information (User Info)	1

This header takes up 41 bytes.

When a transaction system receives a request message, the message must include a message header constructed according to message data; the Unionpay data card issuing system stores some information in the header of the message for return to the sender in response. These fields that must be saved are 4, 5, 6, 7, 8 and 9.

The meaning of each field of the header is shown in table 13.

Watch 13

Domain name	Domain meaning
		Properties	Length and format of message header field
Description of the invention	Possible content and definition of message header fields
		Application method	Some special restrictions useful in the handling of the header fields of a message
Remarks for note	Description of the other
		Domain edit value	Value range and value rule of message header field

Further, the system may further include an IPP 103, configured to, when the transaction channel 200 is a mobile terminal/IC card counter corresponding to a mobile banking machine, connect the communication subsystem 101 with the mobile terminal/IC card counter corresponding to the mobile banking machine through the IPP 103.

When the transaction channel 200 is the mobile terminal 201 corresponding to the mobile banking, the communication subsystem 101 receives, through the TCP protocol, the transaction request message sent by the mobile terminal 201 corresponding to the mobile banking and forwarded by the IPP 103, and converts the message format of the transaction request message into a message format adapted to the credit card system 303 of the bank corresponding to the mobile banking. Specifically, the transaction request message is a message sent by the mobile terminal 201 and used for a credit card payment request, and may be determined to be a fixed-length message for credit card payment transaction, the communication subsystem 101 converts the fixed-length message for credit card payment transaction into a message adapted to the credit card system 302 of the bank corresponding to the mobile banking, and the converted message may be the fixed-length message of the credit card system 302. After the communication subsystem 101 converts the format of the message, the service processing subsystem 102 sends the fixed-length message of the credit card system 302 to the credit card system 302 of the card issuing bank of the transaction bank card through the TCP protocol.

When the transaction channel 200 is the IC card counter 202, the communication subsystem 101 receives the transaction request message sent by the IC card counter 202 and forwarded by the IPP 103 through the TCP protocol, and converts the message format of the transaction request message into a message format adapted to the electronic cash account system 304 of the bank to which the IC card counter belongs. Specifically, the transaction request message is a message sent by the IC card counter 202 and used for an IC collar deposit request, and may be determined as an IC collar deposit long-length message, the communication subsystem 101 converts the IC collar deposit long-length message into a message adapted to the electronic cash account system 304 of the bank to which the IC card counter belongs, and the converted message may be an IC card system 8583 message. After the communication subsystem 101 converts the format of the message, the service processing subsystem 102 sends the message of the IC card system 8583 to the electronic cash account system 304 through the TCP protocol.

When the transaction channel 200 is the union pay transaction system 204, the corresponding banking system 300 includes credit card systems 302 and debit card systems 303 of the banks, that is, the transaction service in the transaction request message sent by the union pay transaction system 204 is the banking service requesting the credit card systems 302 and debit card systems 303 of the banks. Specifically, the communication subsystem 101 receives a transaction request message sent by the union pay transaction system 204 through an HTTP protocol, where the transaction request message is an XML message sent by the union pay transaction system 204, and when it is determined that a transaction service in the transaction request message is a debit card service, a message format of the transaction request message is converted into a message format adapted to a debit card system 303 of an issuing bank of a transaction bank card, which is equivalent to converting the XML message sent by the union pay transaction system 204 into a message adapted to the debit card system 303 of the issuing bank of the transaction bank card, and the converted message may be a core XML message of the debit card system 303. In addition, when the transaction service in the transaction request message received by the communication subsystem 101 is a credit card service, the message format of the transaction request message is converted into a message format adapted to the credit card system 302 of the card issuing bank of the transaction bank card, which is equivalent to converting the XML message sent by the unionpay transaction system 204 into a message adapted to the credit card system 302 of the card issuing bank of the transaction bank card, and the converted message may be the 8583 message of the credit card system 302.

the business processing subsystem 102 sends the core XML message of the debit card system 303 to the debit card system 303 of the card issuing bank of the transaction bank card through a SOAP protocol;

the business processing subsystem 102 sends the 8583 message of the credit card system 302 to the credit card system 302 of the card issuing bank of the transaction bank card through the TCP protocol.

Optionally, the unionpay transaction system 204 is connected to the system 100 supporting multi-channel transactions using a two-in two-out long connection communication mode. Optionally, when the system 100 supporting multi-channel transaction communicates with a bank core system, a TCP communication protocol is used to communicate with the bank core, a message format is a Standard Operating Procedure (SOP), and specifically, a communication data packet between the two includes a public information part and a transaction data part.

The common information part comprises a system information header and a transaction common information header, and the transaction data part comprises a transaction data header (optional), service data and a system control command. The business data part comprises data units, tables and objects. The traffic data portion may be inserted into system control commands. Part of the system is related to the system, including target service code, data source code, length and other system information, and is specified by a system configuration file (database table), and the number, sequence and length of each field are fixed; the part is the information related to all transactions contained in the same data packet, including the information of transaction terminals, transaction tellers, institutions and the like, and the organization mode is the format of the system information header; the part comprises information such as a transaction code, a transaction mode, a foreground serial number, an authorized teller and the like, and the organization mode is the same as the format of a system information header. The service data part is composed of length + data, the length is represented by a binary number of one BYTE, the data is completely converted into a character string for transmission, the maximum length of the character string is specified by the system BYTE _ MAX _ LEN macro definition (in the present embodiment, BYTE _ MAX _ LEN is defined as 250(0xFA)), and the part of the system larger than the length is reserved as a control command. If the length of the data unit exceeds BYTE _ MAX _ LEN, the segment is sent, and 0xFF is used as a mark of the super-long data. For example, to transfer 768 BYTEs of data, since the system defines BYTE _ MAX _ LEN as 250, the data segment is 0xFF +250 characters +0x12+18 characters; if 250 bytes of data are to be transferred, the data segment is 0xFA +250 characters.

In addition, in the service data, a control command may be inserted, and the format thereof is: control character flag + control character string length + control character string. The control character flags are identified by the system reserved characters between BYTE _ MAX _ LEN 0xFF, which in this embodiment is 0xFB, 0xFC, 0xFD, 0xFE, which currently uses only 0XFE as the print-related control command identifier.

The composition of the entire communication packet is shown in table 14.

TABLE 14

Optionally, the system 100 for supporting multi-channel trading further comprises a data monitoring module 104 and an implement management subsystem 105.

The data monitoring module 104 is responsible for asynchronously receiving transaction data, completing functions of normal transaction, abnormal transaction monitoring, transaction statistics and the like, and the monitoring display interface is implemented in a World Wide Web (Web) interface. The data monitoring module 104 includes a transaction monitoring module 1041, a resource monitoring module 1042, an early warning notification module 1043, and a monitoring rule management module 1044, as shown in fig. 3, which provides a structural schematic of the data monitoring module 104. The modules are as follows:

the transaction monitoring module 1041 is used for monitoring the transaction process of the system, and can provide six transaction monitoring functions of overall transaction monitoring, normal transaction monitoring, statistical transaction monitoring, abnormal transaction monitoring, risk transaction monitoring and transaction log monitoring.

The resource monitoring module 1042 is used for monitoring system hardware resources, and can provide real-time monitoring of each hardware resource on the system.

The early warning notification module 1043 is used for providing early warning issuing means in the form of sound, color, frame bouncing and short message.

The monitoring rule management module 1044 performs parameterized configuration on the monitoring rules of the transaction monitoring module 1041, the resource monitoring module 1042 and the early warning notification module 1043.

The implement management subsystem 105 includes a device management module 1051, a key management module 1052, a terminal status monitoring module 1053, and a cash management module 1054, as shown in fig. 4, which provides a structural illustration of the implement management subsystem 105. The modules are as follows:

the device management module 1051 performs transaction control and IP address verification on the transaction terminal corresponding to the transaction channel 200;

the key management module 1052 distributes management keys to the transaction terminals corresponding to the transaction channels 200;

the terminal state monitoring module 1053 monitors and manages the state of the transaction terminal corresponding to the transaction channel 200;

the cash management module 1054 is matched with an ATM cash box to perform cash management, and is used for matching with an ATM cash box inventory, account checking, cash addition and subtraction and the like.

The machine tool management parameter management is realized at a Web end, machine tool equipment management functions (functions of adding, deleting, modifying and the like of machine tool equipment) are realized, and the front platform checks and controls equipment when relevant transactions are processed, such as transaction terminal IP address verification and the like.

Key management is also implemented at the Web site, which implements key management, updating, revocation, and triggers key distribution to various devices.

To better understand the present invention, another system for supporting multi-channel trading provided in the embodiments of the present invention may include a trading operation platform, where the trading operation platform adopts a soft bus design idea, supports a pipeline development mode and a component development method, that is, an architecture of "soft bus + bus driver + soft component", as specifically shown in fig. 5, and adopts a message-driven mode. The core component of the transaction operation platform is a core engine of the transaction operation platform, the core engine is a fully-open system structure, and the processing of transaction messages and services is completed by adopting a queue pair (request queue + corresponding queue) caching technology, a message automatic distribution technology, a thread pool dynamic load technology and an assembly driving technology.

The core engine has the following functions:

the method comprises the steps of resource initialization, queue buffer initialization (the number of queue pairs and the size of the buffer are configurable), creation of a working thread pool (the number of the working thread pool is configurable and can be automatically and dynamically adjusted), and assembly of functional components and methods. The core engine framework reserves interfaces init _ func, done _ func and func for the components, and the engine automatically drives the init _ func method when the components are assembled so as to allow parameters, configuration, shared variables, resource allocation and the like needed by the components to be initialized. And when the engine service is stopped, the automatic drive done _ func method releases the resource allocated by the init _ func. Therefore, init _ func and done _ func will appear symmetrically under normal conditions, and these two methods can be unloaded according to configuration under the condition of no need. Func is a component functional method that handles incoming messages.

Registering a bulletin board, and automatically registering the service information in the bulletin board (shared memory area) after the service (core engine instance) is successfully started, wherein the service information comprises the following steps: server instance name, server relationship information, message routing path information.

And (4) message identification, wherein when a message arrives, the message type is identified according to the message source. The core component provides an export of the plug-ins, and the user can write the plug-ins to identify the message type according to the actual situation.

The queue pair buffer mechanism is characterized in that a core engine adopts a queue pair mode, each queue pair comprises two queues (request and response), the queues adopt a memory linked list mode, messages are divided into 5 priority levels in the queues, the priority levels can be defined according to message types, and the messages with the higher priority levels are processed first. The queue buffer size may be defined in the engine instance configuration file.

The method comprises the steps that the message is automatically distributed, when a queue is created, an engine establishes a waiting distribution thread for each queue, when the message enters the queue, the distribution thread is awakened, the distribution thread obtains the message from the queue according to the priority (large → small) sequence of the message, and distributes the message to an idle work thread in a thread pool for processing.

And the component driving is used for searching the component method corresponding to the message type according to the message type after the working thread is activated by the distribution thread, finding the component method corresponding to the post-driving, and completing a specific task.

And (3) dynamically loading, wherein the working threads in the thread pool can be configured according to system resources and service pressure (High Level and Low Level parameters), the number of the initialized threads is the Low Level number when the system is started, and when the concurrency exceeds the value, the core engine automatically increases the working threads until the High Level value. When the pressure is reduced, the core engine automatically reduces the number of the working threads to a Low Level value. If the dynamic load is not needed, the High Level is just required to be changed into the Low Level.

Based on the same inventive concept, fig. 6 exemplarily shows a flow of a method for multi-channel transaction processing provided by the embodiment of the present invention, which can be performed by a system for supporting multi-channel transaction. As shown in fig. 6, the process specifically includes:

step 601, receiving a transaction request message sent by a transaction channel, and performing message format conversion on the transaction request message according to a transaction service in the transaction request message.

The transaction channels can comprise ATM, POS, IC counter machine, mobile phone bank, Unionpay transaction system and the like, and different transaction channels send messages with different formats through different transmission protocols.

When the transaction channel is ATM or POS, the transaction request message format and the communication protocol are consistent, so the transaction channel is ATM or POS as an embodiment. When the transaction channel is ATM/POS, a transaction request message sent by the ATM/POS is received through a TCP protocol, the transaction request message is 8583 message sent by the ATM/POS, firstly, whether a card issuing bank of a transaction bank card and a bank to which the ATM/POS belongs are the same bank is judged, and secondly, whether the transaction service in the transaction request is debit card service or credit card service is judged.

If the issuing bank of the transaction bank card and the bank to which the ATM/POS belongs are the same bank, when the transaction service in the transaction request message is determined to be debit card service, the message format of the transaction request message is converted into a message format matched with a debit card system of the issuing bank of the transaction bank card, which is equivalent to the 8583 message sent by the ATM/POS is converted into a message matched with the debit card system of the issuing bank of the transaction bank card, and the converted message can be an XML message of the debit card system. For example, a user holding a debit card of a Chinese bank to get money from an ATM of the Chinese bank, and after determining that a card issuing bank of the debit card and a bank to which the ATM belongs are the same bank, the 8583 message sent by the ATM can be converted into an XML message of a debit card system of the Chinese bank. In addition, when the transaction service in the received transaction request message is a credit card service, the message format of the transaction request message is converted into a message format adapted to a credit card system of a card issuing bank of the transaction bank card, which is equivalent to converting the 8583 message sent by the ATM/POS into a message adapted to the credit card system of the card issuing bank of the transaction bank card, and the converted message may be a fixed-length message of the credit card system.

If the card issuing bank of the transaction bank card and the bank to which the ATM/POS belongs are judged not to be the same bank, the ATM/POS is connected with the card issuing bank of the transaction bank card through the Unionpay system, namely the message format of the transaction request message is converted into the message format matched with the Unionpay system, namely the 8583 message sent by the ATM/POS is converted into the message matched with the Unionpay system, and the converted message can be the Unionpay 8583 message.

When the transaction channel is the mobile terminal corresponding to the mobile phone bank, the transaction request message transmitted by the mobile terminal corresponding to the mobile phone bank and forwarded by the IPP is received through the TCP protocol, and the message format of the transaction request message is converted into the message format matched with the credit card system of the bank corresponding to the mobile phone bank. Specifically, the transaction request message is a message sent by the mobile terminal and used for a credit card payment request, and can be determined as a fixed-length message for credit card payment transaction, the fixed-length message for credit card payment transaction is converted into a message adapted to a credit card system of a bank corresponding to the mobile phone bank, and the converted message can be the fixed-length message of the credit card system.

When the transaction channel is an IC card counter machine, a transaction request message transmitted by the IC card counter machine and forwarded by the IPP is received through a TCP protocol, and the message format of the transaction request message is converted into a message format matched with an electronic cash account system of a bank to which the IC card counter machine belongs. Specifically, the transaction request message is a message sent by the IC card counter for an IC collar deposit request, and may be determined as an IC collar deposit long-length message, and the format of the IC collar deposit long-length message is converted into a message format adapted to an electronic cash account system of a bank to which the IC card counter belongs, and the converted message may be an IC card system 8583 message.

When the transaction channel is a Unionpay transaction system, the corresponding banking system includes credit card systems of the banks and debit card systems of the banks, that is, the transaction service in the transaction request message sent by the Unionpay transaction system is the banking service requesting the credit card systems of the banks and the debit card systems of the banks. Specifically, a transaction request message sent by the unionpay transaction system is received through an HTTP protocol, the transaction request message is an XML message sent by the unionpay transaction system, and when it is determined that a transaction service in the transaction request message is a debit card service, a message format of the transaction request message is converted into a message format adapted to a debit card system of a card issuing bank of a transaction bank card, which is equivalent to converting the XML message sent by the unionpay transaction system into a message adapted to the debit card system of the card issuing bank of the transaction bank card, and the converted message format may be a core XML message of the debit card system. In addition, when the transaction service in the transaction request message received by the communication subsystem is a credit card service, the message format of the transaction request message is converted into a message format matched with a credit card system of a card issuing bank of the transaction bank card, which is equivalent to converting an XML message sent by a unionpay transaction system into a message matched with the credit card system of the card issuing bank of the transaction bank card, and the converted message may be an 8583 message of the credit card system.

Step 602, the transaction request message after the message format conversion is sent to the banking system corresponding to the transaction service in the transaction request message for processing.

Sending the transaction request message after message format conversion to a banking system corresponding to the transaction service in the transaction request message for processing, wherein the method specifically comprises the following steps according to the different transaction services or banking systems:

1. the transaction channel is ATM/POS

When the card issuing bank of the transaction bank card and the bank to which the ATM/POS belongs are the same bank, transmitting the XML message of the debit card system to the debit card system of the card issuing bank of the transaction bank card through the SOAP protocol; or sending the fixed-length message of the credit card system to a credit card system of a card issuing bank of the transaction bank card through a TCP protocol;

and when the card issuing bank of the transaction bank card is not the same bank as the bank to which the ATM/POS belongs, sending the UnionPay 8583 message of the UnionPay system to the UnionPay system through a TCP (transmission control protocol).

2. Mobile terminal with transaction channel corresponding to mobile banking

And sending the fixed-length message of the credit card system to a credit card system of a card issuing bank of the transaction bank card through a TCP protocol.

3. Counter machine for IC card in transaction channel

The IC card system 8583 message is sent to the electronic cash account system via TCP protocol.

4. Trade channel is Unionpay trade system

Sending the core XML message of the debit card system to a debit card system of an issuing bank of a transaction bank card through a SOAP protocol; or the 8583 message of the credit card system is sent to the credit card system of the card issuing bank of the transaction bank card through a TCP protocol.

For better understanding of the flow of the method for processing the multi-channel transaction provided by the embodiment of the invention, the following terms are explained in advance:

the line debit card: the issuing bank of the transaction debit card is the same bank as the bank to which the ATM/POS belongs.

The bank credit card: the card issuing bank of the transaction credit card and the bank to which the ATM/POS belongs are the same bank.

The other lines of cards: the card issuing bank of the transaction bank card and the bank to which the ATM/POS belongs are different banks.

The generation: the card issuing bank of the transaction bank card and the bank to which the ATM/POS belongs are different banks, and the bank to which the ATM/POS belongs brokers the card issuing bank of the transaction bank card to handle business.

Fig. 7 is a flow chart showing the case where the transaction channel is an ATM.

Step 701, receiving data.

The receiving ATM sends a transaction request message through a TCP protocol, and the message is a 8583 message.

At step 702, a Message Authentication Code (MAC) is checked.

The MAC can recognize falsification and disguise, namely, the integrity of the transaction request message can be confirmed, and authentication can also be carried out, wherein the input of the message authentication code comprises a message with any length and a secret key shared between a sender and a receiver, and the secret key can output data with fixed length.

Step 703, recording the running water.

And recording the transaction flow of the bank card.

Step 704, determine whether it is the present generation, if yes, go to step 705, if not, go to step 706.

It is determined whether the issuing bank of the transaction bank card and the bank to which the ATM belongs are the same bank, and if so, the transaction bank card is not the present bank, and the process goes to step 706.

Step 705, withdraw money processing.

And sending the transaction request message of the withdrawal processing to the Unionpay system, namely, carrying out the withdrawal processing in the Unionpay system.

Step 706, determining whether the transaction bank card is a debit card or a credit card, if yes, turning to step 707; if so, then flow is directed to step 708.

And step 707, withdrawal processing.

When the credit card is used for carrying out withdrawal operation, namely when the transaction bank card is a credit card, the transaction request message for withdrawal processing is sent to the credit card system of the bank to which the credit card belongs, so that the credit card system of the bank to which the credit card belongs carries out withdrawal processing.

Step 708, determining whether the transaction bank card is an IC card or a magnetic stripe card, if yes, turning to step 710, and if yes, turning to step 709.

The IC card and the magnetic stripe card belong to debit cards, wherein the IC card ensures the safety and the reality in the interaction process of the terminal and the card through an arithmetic chip and a secret key stored in the IC card, can ensure the safety of online transaction information, almost cannot be copied, has high reliability, and not only ensures the safety of online transaction, but also can realize the safe offline use; the magnetic stripe card has relatively simple stored information and easy copying, and can be verified only by sending each transaction to the bank background system in an online transaction mode for ensuring safety, so that the magnetic stripe card is easy to copy and damage. The IC card needs ARQC verification, and the magnetic stripe card does not need ARQC verification. If the card is a magnetic stripe card, sending a transaction request message for withdrawal processing to a bank core system; if the IC card is the IC card, after the IC card is subjected to ARQC verification, the transaction request message for withdrawal processing is sent to a bank core system.

Step 709, an IC card bank card password verification technique (ARQC).

The IC card carries out ARQC verification on the bank to which the IC card belongs, and whether the IC card is the card issued by the bank to which the IC card belongs is judged.

Step 710, withdrawal processing.

And sending the transaction request message of the withdrawal processing to a bank core system, namely, carrying out the withdrawal processing in the bank core system.

Step 711, accept the result.

And receiving the response message fed back by the credit card system, the unionpay system or the bank core system.

At step 712, a determination is made as to whether the transaction bank card is a debit card or a credit card, and if so, the process goes to step 713.

Step 713, determine whether the transaction bank card is an IC card or a magnetic stripe card, if so, go to step 714.

If the card is an IC card, the process goes to step 714, and the ARQC check of the IC card is performed again, if the card is a magnetic stripe card, the response message is fed back to the ATM, and the ATM can determine whether to pay money according to the response message.

And step 714, checking the ARQC code of the IC card.

In this embodiment, the transaction bank card is first determined to be a bank debit card or a bank credit card or other bank card, and routed to different banking systems according to different types of card transactions; according to the message formats of different banking systems, corresponding message format conversion is carried out; for other bank cards, converting the 8583 message into a UnionPay 8583 message, sending the message to a UnionPay system through a TCP (transmission control protocol), sending the UnionPay system to a corresponding card sender, feeding back the response message to the ATM after receiving the feedback of the UnionPay system, and determining whether to spit the bank notes according to the success or not by the ATM; for the debit card of the bank, if the IC card needs to be subjected to ARQC verification, the ARQC verification is converted into an XML message after being successful and then the XML message is sent to a debit card system through a SOAP protocol, the XML message is fed back to the ATM after receiving a debit card core feedback response message, and the ATM determines whether to spit money according to success or not; for the local line credit card, converting the local line credit card into a fixed-length message, sending the fixed-length message to a credit card core in a TCP (transmission control protocol) mode, receiving a response message fed back by a credit card system, and feeding back the response message to an ATM (automatic teller machine), wherein the ATM determines whether to spit money according to success or failure; the transaction processing flow ends.

To better understand the flow of the method for processing a multi-channel transaction provided by the embodiment of the present invention, fig. 8 also shows a schematic flow diagram when the transaction channel is a mobile terminal corresponding to a mobile banking system.

Step 801, transferring a core cash book accounting interface.

And the mobile banking APP sends a transaction request message to the IPP and calls a core cash account bookkeeping interface of the IPP.

And step 802, transferring a core cash book accounting interface.

The IPP sends a fixed-length message of credit card repayment transaction to a bank core system for accounting in a SOAP protocol mode, and calls a core cash account accounting interface of the core system.

Step 803, transferring the credit card repayment interface.

After the bank core system returns success, a credit card repayment interface of the IPP is called, and the IPP sends a fixed-length message of credit card repayment transaction to the transaction system in a TCP protocol mode.

And step 804, adjusting a credit card repayment interface.

The transaction system converts the received fixed length message of the credit card repayment transaction into a fixed length message of the credit card system, sends the fixed length message to the credit card system in a TCP protocol mode, and calls a credit card repayment interface.

Step 805, credit card repayment.

And the credit card system executes the transaction service according to the received transaction request message and returns the result to the transaction system.

When a user repays by the mobile phone bank, namely the transaction channel is the mobile phone bank, the mobile phone bank sends a message to the IPP, the IPP sends a credit card repayment fixed length message to the core system through the SOAP protocol, after the core system successfully accounts, the IPP sends the credit card repayment transaction fixed length message to the transaction system through the TCP protocol, and the transaction system converts the credit card repayment transaction fixed length message into a credit card system fixed length message and sends the credit card fixed length message to the credit card system through the TCP protocol. The credit card system returns a repayment result to the transaction system, the transaction system returns a repayment result to the IPP, and the IPP returns a final result to the mobile phone bank.

Based on the same inventive concept, an embodiment of the present invention further provides a computing device, including:

a memory for storing program instructions;

Based on the same inventive concept, the embodiment of the present invention also provides a computer-readable non-volatile storage medium, which includes computer-readable instructions, and when the computer reads and executes the computer-readable instructions, the computer is enabled to execute the above-mentioned multi-channel transaction processing method.

The embodiment of the invention provides a system for supporting multi-channel transaction and a processing method thereof, the system comprises a communication subsystem and a service processing subsystem, wherein, the communication subsystem is connected with the transaction channel, the service processing subsystem is connected with the banking system, the communication subsystem receives the transaction request message sent by the transaction channel, the transaction request message is subjected to message format conversion according to the transaction service in the transaction request message, the service processing subsystem sends the transaction request message after the message format conversion to a banking system corresponding to the transaction service in the transaction request message for processing, the transaction requests of different transaction channels can be received, and the transaction service in the transaction request message is converted into a message format which can be analyzed by the corresponding banking system, so that connection between various transaction channels and various banking systems is realized.

Meanwhile, the system for supporting multi-channel trading and the processing method thereof provided by the embodiment of the invention can comprise a trading operation platform, the trading operation platform is based on a soft bus design idea, and not only supports the establishment of an application integration framework and meets the requirement of cooperative work, but also adopts a multi-level soft component technology and is more convenient for the development of an application field framework and components. The system has good openness, expansibility and flexibility, and can flexibly expand or cut corresponding components and flexibly adjust software and hardware resource limits according to specific user requirements so as to adapt to requirements of different scales or different service characteristics. In addition, the visual development tool for the system supporting the multi-channel transaction provides an intuitive and convenient development tool for secondary rapid development of users, the tool is used without the need that the users deeply learn related languages and database technologies, the development of business functions can be carried out only by preliminarily mastering the related technologies, and the development tool integrates the functions of version management, test management and the like. The version management solves the problems of version control and collaborative development of a plurality of projects which are simultaneously developed by a user through the platform. The test management function provides the functions of case editing, case submitting and testing and case batch retesting for the user unit testing and the integrated testing, and analyzes and counts the test results. Finally, the system supporting multi-channel transaction adopts a Web development platform to realize service management, and besides basic system management functions (user management, organization management, authority management, channel management, log management and the like), the system simultaneously provides a rich development foundation construction library and provides a rapid realization guarantee for customized development of specific services.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

While preferred embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims be interpreted as including preferred embodiments and all such alterations and modifications as fall within the scope of the invention.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A system for supporting multi-channel transaction is characterized by comprising a communication subsystem and a service processing subsystem; the communication subsystem is connected with a transaction channel, and the business processing subsystem is connected with a banking business system;

the communication subsystem receives the transaction request message sent by the transaction channel, judges whether the card issuing bank of the transaction bank card and the bank to which the transaction request message belongs are the same bank or not, determines the transaction service corresponding to the transaction request message when determining that the card issuing bank of the transaction bank card and the bank to which the transaction request message belongs are the same bank or not, and performs message format conversion on the transaction request message according to the transaction service in the transaction request message; the transaction service comprises a debit card service or a credit card service;

the business processing subsystem sends the transaction request message after message format conversion to a banking business system corresponding to the transaction business in the transaction request message for processing;

if the transaction channel is an ATM/POS; the banking system comprises a unionpay system, credit card systems of all banks and debit card systems of all banks; the communication subsystem receives a transaction request message sent by a Unionpay transaction system through a hypertext transfer HTTP protocol, and if the card issuing bank of a transaction bank card and the bank to which the transaction request message belongs are determined to be the same bank, the message format of the transaction request message is converted into a message format matched with a debit card system of the card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be debit card service; or when the transaction service in the transaction request message is determined to be credit card service, converting the message format of the transaction request message into a message format matched with a credit card system of a card issuing bank of the transaction bank card; the communication subsystem receives a transaction request message sent by the Unionpay transaction system through an HTTP protocol, and if the fact that a card issuing bank of a transaction bank card and a bank to which the transaction request message belongs are not the same bank is determined, the message format of the transaction request message is converted into a message format matched with the Unionpay system;

if the transaction channel is an IC card counter machine; the banking system is an electronic cash account system of each bank; the communication subsystem receives a transaction request message transmitted by the IC card counter machine and forwarded by a platform software function library IPP through a TCP protocol, and converts the message format of the transaction request message into a message format matched with an electronic cash account system of a bank to which the IC card counter machine belongs;

if the transaction channel is a mobile terminal corresponding to a mobile phone bank; the banking system is a credit card system of each bank; and the communication subsystem receives a transaction request message transmitted by the mobile terminal corresponding to the mobile phone bank and forwarded by the IPP through a TCP protocol, and converts the message format of the transaction request message into a message format matched with a credit card system of the bank corresponding to the mobile phone bank.

2. The system of claim 1, wherein the communication subsystem comprises a communication interface module and a message conversion module; the communication interface module is connected with the transaction channel and used for receiving transaction request messages sent by the transaction channel, and the message conversion module is used for converting message formats of the transaction request messages.

3. The system of claim 1, further comprising a data monitoring module and an implement management subsystem;

the machine tool management subsystem comprises an equipment management module, a key management module, a terminal state monitoring module and a cash management module; the equipment management module carries out transaction control on a transaction terminal corresponding to the transaction channel and checks the protocol IP address interconnected between networks; the key management module distributes a management key to the transaction terminal corresponding to the transaction channel; the terminal state monitoring module monitors and manages the state of the transaction terminal corresponding to the transaction channel; the cash management module is matched with the ATM cash box to perform cash management.

4. A method of multi-channel transaction processing, comprising:

receiving a transaction request message sent by a transaction channel, judging whether an issuing bank of a transaction bank card and a bank to which the transaction request message belongs are the same bank or not, determining a transaction service corresponding to the transaction request message when the issuing bank of the transaction bank card and the bank to which the transaction request message belongs are the same bank or not, and performing message format conversion on the transaction request message according to the transaction service in the transaction request message; the transaction service comprises a debit card service or a credit card service;

sending the transaction request message after message format conversion to a banking system corresponding to the transaction service in the transaction request message for processing;

if the transaction channel is an ATM/POS; the banking system comprises a unionpay system, credit card systems of all banks and debit card systems of all banks; receiving a transaction request message sent by a Unionpay transaction system through an HTTP (hyper text transport protocol), if the card issuing bank of a transaction bank card and the bank to which the transaction request message belongs are determined to be the same bank, converting the message format of the transaction request message into a message format matched with a debit card system of the card issuing bank of the transaction bank card when the transaction service in the transaction request message is determined to be debit card service; or when the transaction service in the transaction request message is determined to be credit card service, converting the message format of the transaction request message into a message format matched with a credit card system of a card issuing bank of the transaction bank card; receiving a transaction request message sent by the Unionpay transaction system through an HTTP (hyper text transport protocol), and converting the message format of the transaction request message into a message format matched with the Unionpay system if the fact that a card issuing bank of a transaction bank card and a bank to which the transaction request message belongs are not the same bank is determined;

if the transaction channel is an IC card counter machine; the banking system is an electronic cash account system of each bank; receiving a transaction request message transmitted by the IC card counter machine and forwarded by a platform software function library IPP through a TCP protocol, and converting the message format of the transaction request message into a message format matched with an electronic cash account system of a bank to which the IC card counter machine belongs;

if the transaction channel is a mobile terminal corresponding to a mobile phone bank; the banking system is a credit card system of each bank; and receiving a transaction request message transmitted by the mobile terminal corresponding to the mobile phone bank and forwarded by the IPP through a TCP protocol, and converting the message format of the transaction request message into a message format matched with a credit card system of the bank corresponding to the mobile phone bank.

5. A computing device, comprising:

a memory for storing program instructions;

a processor for calling program instructions stored in said memory to execute the method of claim 4 in accordance with the obtained program.

6. A computer-readable non-transitory storage medium including computer-readable instructions which, when read and executed by a computer, cause the computer to perform the method of claim 4.