TWM609051U - System for converting interface specification of financial transaction application program - Google Patents

Abstract

A system for converting financial transaction application program interface specifications, using an application program interface management platform to formulate multiple specification fields in a header file of a demand packet and store the multiple second specifications of the receiving end; when the source end receives a payment card During a transaction, a request packet containing the transaction is sent through a first application program interface. The request packet is an Http URL and contains the first specification of the source end; after the application program interface management platform receives the request packet, it checks the specification field The conversion is performed to form a new demand packet conforming to the receiving end format; the receiving end receives the new demand packet through a second application program interface and confirms the transaction, and then sends a response packet to the source end through the application program interface management platform.

Description

System for converting the interface specifications of financial transaction applications

This creation is about a new type of cash flow architecture, especially a system that converts the interface specifications of financial transaction application programs.

At present, when the transaction platform and the bank conduct transactions, because the message formats used by different institutions are not the same, the transaction messages in the application programming interface (API) format are generally used. After the two parties have agreed on the specifications, they will be sent and received by the Https transmission protocol, but they are different The content of the fields of the organization is also different, and it is difficult to connect. Taking Figure 1 as an example, if the electronic branch 20 and the financial institution 22 are to be connected, the electronic branch 20 and the financial institution 20 need to agree on the format first. The electronic branch 20 is the client and sends a request packet, and the financial institution 20 is the client. The organization 22 is a server, and after receiving the request, it responds with a Response to the electric branch 20 operator. However, due to the different formats, it is difficult for the financial institution 22 to connect to multiple home appliances branch institutions 20. Similarly, the electrical branch institution 20 also needs to modify the system to meet the format requirements of different financial institutions 22 in order to interface with multiple financial institutions 22, which is time-consuming and labor-intensive.

In recent years, the topic of open banking has been widely discussed. The core of open banking is the technical specification, namely the application programming interface (API), which allows the financial system to securely access shared data and process transactions across parties. If a third-party organization can provide an application program interface management platform, and formulate a unified standard, use the application program interface management platform for multi-format conversion. It can quickly cooperate with government policies to provide corresponding functions, and financial institutions want to use the characteristics of the application program interface management platform to interface with government agencies’ information systems, general online trading platforms and The financial institution server implements one-to-many, many-to-one and many-to-many technical applications of the application program interface management platform.

Therefore, in response to the lack of the above-mentioned conventional technology and future needs, this creation proposes a system for converting the interface specifications of financial transaction applications. The specific architecture and implementation methods will be described in detail below:

The main purpose of this creation is to provide a system for converting financial transaction application interface specifications. It uses the application interface management platform to formulate a transaction package specification that can accommodate various institutions, and can automatically convert the data in the specification field from the source. The data at the receiving end can be connected to achieve one-to-many, many-to-one and many-to-many connections.

Another purpose of this creation is to provide a system for converting financial transaction application interface specifications. It adds a unit code identifier to the URL of the demand packet to directly distinguish which institution is the receiving end and speed up the specification conversion.

To achieve the above objectives, this creation provides a system for converting financial transaction application interface specifications, including: at least one source terminal, which is a transaction platform server or a financial institution server, which receives a payment card transaction, and uses a first The application program interface sends a demand packet containing the transaction. The demand packet is an Http URL and contains the first specification of the source end; an application program interface management platform is connected with the source end signal to define the demand packet A plurality of specification fields in a header file, and conversion of the first specification in the specification fields to form a new demand packet; and at least one receiving end, which is a financial institution server or a trading platform server , Connect with the application program interface management platform signal, receive the new demand packet through a second application program interface and confirm the transaction, and send a response packet to the source end through the application program interface management platform; wherein, the application program interface The management platform stores a plurality of second specifications of the receiving end, and when the application program interface management platform receives the demand packet from the source end, it converts the specification fields that originally contained the first specifications into the receiving end The second specifications are used to generate the new demand packet conforming to the format of the receiving end and transmit it to the receiving end.

According to the embodiment of this creation, when the source end is a transaction platform server and the receiving end is a financial institution server, the receiving end is the issuing bank of the payment card, and the units in the specification fields in the demand packet The name is changed from the unit name of the source to the name of the issuing bank.

According to the embodiment of this creation, when the source end is a transaction platform server and the receiving end is a financial institution server, the receiving end is the issuing bank of the payment card, and the application program interface management platform finds out from the demand packet A unit code of the receiving end is filled in the Http URL as a unit code identifier, and the unit code is the bank code of the issuing bank.

According to the embodiment of this creation, the length of the specification fields established by the application program interface management platform is greater than or equal to the content length of the first specification and the second specification, and the length of the first and second specifications The content is to the right in these specification fields, and the left is blank, zero-filled or other symbols are filled in.

According to the embodiment of this creation, when the source end is a financial institution server and the receiving end is a transaction platform server, the source end is the issuing bank of the payment card, and the payment card is through an ATM, a mobile bank, or a mobile payment Send the transaction to the issuing bank.

According to the embodiment of this creation, when the field names of the first specifications and the second specifications are different but the content has the same meaning, the application program interface management platform converts the field names of these specifications fields to It is consistent with the field name required by the receiving end.

According to the embodiment of the present creation, the payment card is a credit card.

According to the embodiment of this creation, the demand package further includes the card data of the payment card and the transaction information of the transaction. The card data includes the card number, expiration date, and key. The transaction information includes transaction time, transaction amount, and machine. Number, transaction verification code.

According to the embodiment of this creation, the card data and the transaction information are encrypted and then sent to the receiving end for decryption through the application program interface management platform.

This creation provides a system for converting financial transaction application program interface specifications. The application program interface management platform is used to convert application message packets of different formats between trading platforms and financial institutions, which can be connected to multiple trading platforms and multiple financial institutions to achieve one pair Many, many-to-one and many-to-many transaction requirements.

Please refer to Figure 2, which is a block diagram of the first embodiment of the system 10 for creating and converting financial transaction application interface specifications. The system 10 for converting financial transaction application program interface specifications includes at least one source terminal 12, an application program interface management platform 14 and at least one receiving terminal 16. The application program interface management platform 14 is connected to the source terminal 12 and the receiving terminal 16 by signals respectively. Among them, the source terminal 12 and the receiving terminal 16 respectively represent one of a trading platform server or a financial institution server. The source end 12 is provided with a first application programming interface 122, and the receiving end is provided with a second application programming interface 162.

Regardless of whether the source terminal 12 and the receiving terminal 16 are transaction platform servers or financial institution servers, when the source terminal 1 receives the payment card transaction first, it immediately sends a transaction message to the receiving terminal 16 for confirmation. The payment card includes any one of a financial card, a credit card, and a stored-value card. Specifically, the first application program interface 122 of the source terminal 12 sends a demand packet containing the transaction. The demand packet is in the form of an Http URL, which contains the plural first specifications of the source terminal 12. The demand package also includes the card information of the payment card and the transaction information of the transaction: the aforementioned card information includes the card number, expiration date and key, etc.; transaction information includes transaction time, product name or number, transaction amount, machine number, and transaction verification Code and so on. The payment card may be a credit card.

The application program interface management platform 14 is a credible third-party intermediary organization that provides a platform for multi-party docking. The application program interface management platform 14 formulates a plurality of specification fields in a header file of a demand package, and converts the first specification in the specification field to form a new demand package, thereby meeting the transaction requirements of multiple parties with different specifications.

Specifically, the application program interface management platform 14 pre-stores a plurality of second specifications of the receiving end 16. After the application program interface management platform 14 receives the demand packet from the source end 12, it will find the designated receiving end 16 and its corresponding second specification from the demand packet. Then, the application program interface management platform 14 converts the specification field originally containing the first specification into the second specification of the receiving end 16, thereby generating a new demand packet that conforms to the format of the receiving end 16.

The receiving end 16 receives the new demand packet and confirms the transaction through the second application program interface 162. Then, the receiving end 16 transmits the response packet back to the source end 12 through the application program interface management platform 14 according to the original path.

Next, explain the demand packet in Http format, please refer to Figure 1B. Figure 1B shows a web address (URL), Method, Headers (header file), and Body (text) that are acceptable for message processing. In this creation, the application program interface management platform 14 formulates the specification field of the header file in the demand packet, and the number of the specification field is greater than or equal to the number of the first specification and the second specification. For example, there are 10 fields in the specification field of the standard. If there are only 4 second specifications at the receiving end, the application program interface management platform 14 fills the 4 specifications into the specification field and deletes the remaining 6 fields. In addition, the length of the specification field is also greater than or equal to the content length of the first specification and the second specification. Therefore, no matter how long the specifications of the source terminal 12 and the receiver terminal 16 are, the specifications field is sufficient to accommodate them. In the specification column, the content of the first specification and the second specification are arranged on the right side, and the blank part on the left is left blank, zero-filled or other symbols are filled in.

Figure 3 is a flowchart of the method of applying this creation to convert the interface specifications of financial transaction application programs. In step S10, an application program interface management platform 14 formulates a plurality of specification fields in a header file of a demand packet, and stores a plurality of second specifications of at least one receiving end 16; then, as described in step S12, when the source When the terminal 12 receives a payment card transaction, it sends a demand packet containing the transaction to the application program interface management platform 14 through a first application program interface 122. The demand packet is an Http URL and contains a plurality of first specifications of the source terminal; In step S14, after the application program interface management platform 14 receives the demand packet from the source end 12, it converts the specification field, and converts the specification field originally containing the first specification into the second specification of the receiving end 16, forming a conforming reception A new demand packet in the format of the end 16; finally, as described in step S16, the receiving end 16 receives the new demand packet through a second application program interface 162, and after confirming the transaction, transmits a response packet to the application interface management platform 14 Source side 12. The source terminal 12 will display the transaction result to the consumer for viewing.

First, the first embodiment of this creation will be explained. Please refer to Figure 2 again. The source end 12 is a trading platform server, such as a mask sales platform of the Ministry of Health and Welfare. The receiving end 16 is a server of a financial institution, such as a number of banks that cooperate with the application management platform 14. In other words, the receiving end 16 is a payment card issuing bank. Assuming that the cardholder inserts the credit card issued by the Bank of Taiwan into the source terminal 12, the source terminal sends a demand packet containing the first specification according to the self-defined specifications or the specifications established by the application program interface management platform 14. As mentioned above, the demand packet has transaction information, so I won’t repeat it here. The application program interface management platform 14 converts the demand packet into the specifications of the second application program interface 162 of the receiving end 16 (ie, Bank of Taiwan), and then sends it to the receiving end 16 for authorization. Finally, after the receiving end 16 completes the transaction confirmation and issues the authorization, it sends the response packet containing the authorization result back to the source end 12 along the original path, thereby notifying the cardholder.

Preferably, the specification field in the demand packet can be used to plan card data. For example, in the demand packet sent by the source 12, the specification field has a field for recording the unit name, and the field is filled with the name of the trading platform server. After the application program interface management platform 14 accepts the demand packet, the field is modified to the name of the issuing bank.

In reality, different organizations will use different names for the same thing. Assuming that the field names of the first specification and the second specification are different, but the content has the same meaning, the application program interface management platform 14 will convert the field name of the specification field to match the field required by the receiving end 16. The name remains the same. For example, if in the demand packet sent from the source end 12, the specification field filled with the unit name is "bank name", but the name of the same field at the receiving end 16 is "business unit name". At this time, since the application program interface management platform 14 pre-stores the specifications of each receiving end 16, it can automatically convert the field name into a "business unit name", thereby complying with the specifications of the receiving end 16.

Preferably, this creation adds an identifier to the web address of the request packet to provide the card issuing bank directly identifying the receiving end 16. The application program interface management platform 14 finds a unit code of the receiving end 16 from the demand packet and fills it in the Http URL as a unit code identifier. The unit code is the bank code of the issuing bank. For example, if the URL of the required packet is "https://openapi.fisc.com.tw/mask/v1.0.0/812/Auth". Among them, "812" is the bank code, which is filled in by the source terminal 12. In other words, the source end 12 or the sink end 16 can directly apply the specifications formulated by the application program interface management platform 14, or as shown in this paragraph, the source end 12 or the sink end 16 can add the identifier of the unit code to the URL.

Next, the second embodiment of the present creation will be explained. Please refer to Figure 4, which is a block diagram of the second embodiment of the system for creating and converting financial transaction application interface specifications. The difference from the first embodiment is that the second embodiment is a many-to-one embodiment. Among them, the source terminal 12 is a server of a financial institution, which is also the issuing bank of the payment card. The receiving end 16 is a trading platform server, such as the revitalization triple coupon control platform launched by the government. The payment card sends a transaction request to the card issuing bank through an automated teller machine, mobile bank or mobile payment, that is, to the source terminal 12. Then, the source end 12 (financial institution) according to the specifications of the application program interface management platform 14, and at the same time send binding, inquiry, unbinding, review, lock, payment, ATM cancel payment, query cancel binding and other messages according to the business context , The message is forwarded to the receiving end 16 through the application program interface management platform 14 (such as the revitalization of the triple coupon control platform), and finally the response packet is sent back to the source end 12 following the original path. Since the first application program interface 122 of each participating unit of the source end 12 may have different specifications, it is converted to the specifications of the second application program interface 162 of the receiving end 16 through the application program interface management platform 14. In this way, each participating unit of the source end 12 can maintain the existing API specifications or fine-tune the transmission of the API specifications, thereby reducing the development cost of the system and providing fast online services.

Next, the third embodiment of the present creation will be explained. Please refer to Figure 5, which is a block diagram of the third embodiment of the system for creating and converting financial transaction application interface specifications. The difference from the first and second embodiments is that the third embodiment is a many-to-many embodiment. Among them, the source terminal 12 is a trading platform server, such as a third-party provider (TSP) of a non-financial system. The receiving end 16 is a server of a financial institution. In actual situations, there are transactions that require multiple transaction platforms to connect to multiple financial institutions at the same time, such as opening a billing application that allows users to view account information of multiple banks. For consumers, Open Banking provides consumers with greater freedom to instantly view all their financial status on one platform, instead of going to different banks to view and process multiple accounts. For banks, banks have the opportunity to open their core business functions to third-party vendors through APIs, and then expand their business. For the third-party industry, the premise of open banking is the ability to integrate multiple financial functions and data. The third-party industry can provide a variety of innovative ways by integrating services and data. The financial institution decides which data to open to which third-party industry, and both parties control the usage restrictions of each API through the application program interface management platform 14. For example, the mobile application of a third-party operator (burlap accounting) wants to provide its customers with an integrated query of the credit card limit of each bank under the customer's name, using the "inquiry customer's personal credit card limit" application developed by the application interface management platform 14 Interface specifications, after obtaining the approval of each receiving end 16 (credit card issuing bank) to call the application program interface, the source end 12 (third party operator) can send the application program interface to the application program interface management platform 14 after the customer selects the query , Forward to each receiving end 16 (financial institution) to query the customer’s credit card limit, and display the query result on the customer’s mobile device.

The point-to-point encryption protection is adopted between the source end 12 and the receiving end 16. After the card data and transaction information sent by the source end 12 are encrypted, they are transmitted to the receiving end 16 through the application program interface management platform 14 and finally decrypted by the receiving end 16. Therefore, the application program interface management platform 14 only provides the functions of packet format conversion and message transmission, and cannot decrypt and read encrypted information. Therefore, there is no risk of transaction information outflow, and the security of personal information protection can be increased.

In summary, with the system for converting financial transaction application interface specifications provided by this author, the application interface management platform is used to formulate a transaction package specification that can accommodate various institutions, and the specifications in the header file of the required package can be formulated The fields are automatically converted from the data at the source end to the data at the receiving end. You can also add a unit code identifier to the URL of the required packet to directly distinguish which organization is the receiving end, speed up the specification conversion, so that the server of each trading platform can be Even if the servers of various financial institutions adopt different application programming interface specifications, they can still achieve multi-party docking such as one-to-many, many-to-one, and many-to-many.

Only the above are only the preferred embodiments of this creation, and they are not used to limit the scope of implementation of this creation. Therefore, all equivalent changes or modifications made in accordance with the characteristics and spirit of the application scope of this creation shall be included in the scope of patent application of this creation.

10: System for converting the interface specifications of financial transaction applications 12: Source 122: The first application program interface 14: Application programming interface management platform 16: receiving end 162: The second application program interface

Figure 1A is a schematic diagram of a peer-to-peer transaction between a conventional technology electric branch operator and a bank. Figure 1B is the structure diagram of the Http URL. Figure 2 is a block diagram of the first embodiment of a system for creating and converting financial transaction application interface specifications. Figure 3 is a flowchart of the method of applying this creation to convert the interface specifications of financial transaction application programs. Figure 4 is a block diagram of the second embodiment of the system for creating and converting financial transaction application interface specifications. Figure 5 is a block diagram of a third embodiment of a system for creating and converting financial transaction application interface specifications.

10: System for converting the interface specifications of financial transaction applications

12: Source

122: The first application program interface

14: Application programming interface management platform

16: receiving end

162: The second application program interface

Claims (9)

A system for converting the interface specifications of financial transaction application programs, including: At least one source end, which is a transaction platform server or a financial institution server. The source end receives a payment card transaction and sends a demand packet containing the transaction through a first application program interface. The demand packet is an Http URL, and include the plural first specifications of the source end; An application program interface management platform, connected with the source end signal, formulates multiple specification fields in a header file of the demand packet, and converts the first specification in the specification fields to form a new demand Packet; and At least one receiving end, which is a financial institution server or a trading platform server, is connected to the application program interface management platform signal. The receiving end receives the new demand packet through a second application program interface and confirms the transaction, and then passes through the application The program interface management platform sends a response packet to the source end; Wherein, the API management platform stores a plurality of second specifications of the receiving end, and when the API management platform receives the demand packet from the source end, it will originally contain the specification fields of the first specifications Bits are converted into the second specifications of the receiving end to generate the new demand packet conforming to the format of the receiving end, and transmitted to the receiving end. The system for converting financial transaction application interface specifications as described in claim 1, wherein when the source end is a transaction platform server and the receiving end is a financial institution server, the receiving end is the issuing bank of the payment card, and the requirement is The unit name in the specification fields in the package is changed from the unit name of the source end to the name of the issuing bank. The system for converting the interface specifications of financial transaction application programs as described in claim 1, wherein when the source end is a transaction platform server and the receiving end is a server of a financial institution, the receiving end is the issuing bank of the payment card, and the application The program interface management platform finds a unit code of the receiving end from the demand packet, and fills it in the Http URL as a unit code identifier. The unit code is the bank code of the issuing bank. The system for converting financial transaction application interface specifications as described in claim 1, wherein the length of the specification fields defined by the application interface management platform is greater than or equal to the content length of the first specifications and the second specifications , And the contents of the first and second specifications are to the right in the specifications field, and the left side is blank, zero-filled or other symbols are filled in. For the system for converting financial transaction application interface specifications as described in claim 1, in which the source end is a financial institution server and the receiving end is a transaction platform server, the source end is the issuing bank of the payment card, and the payment The card sends the transaction to the issuing bank through an ATM, mobile bank or mobile payment. For the system for converting financial transaction application interface specifications as described in claim 1, where the field names of the first specifications and the second specifications are different but the contents have the same meaning, the application interface management platform shall The field name of the specification field is converted to be consistent with the field name required by the receiving end. The system for converting the interface specification of a financial transaction application program as described in claim 1, wherein the payment card is a credit card. For example, the system for converting financial transaction application interface specifications as described in claim 1, wherein the demand packet further includes the card data of the payment card and the transaction information of the transaction. The card data includes the card number, expiration date, key, and Transaction information includes transaction time, transaction amount, machine number, and transaction verification code. The system for converting financial transaction application interface specifications as described in claim 1, wherein the card data and the transaction information are encrypted and sent to the receiving end through the application interface management platform for decryption.

Images