TWI787666B - System and method for converting financial transaction API specification - Google Patents
System and method for converting financial transaction API specification Download PDFInfo
- Publication number
- TWI787666B TWI787666B TW109139150A TW109139150A TWI787666B TW I787666 B TWI787666 B TW I787666B TW 109139150 A TW109139150 A TW 109139150A TW 109139150 A TW109139150 A TW 109139150A TW I787666 B TWI787666 B TW I787666B
- Authority
- TW
- Taiwan
- Prior art keywords
- transaction
- specifications
- api
- management platform
- receiving end
- Prior art date
Links
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Abstract
一種轉換金融交易應用程式介面規格之系統及其方法，利用一應用程式介面管理平台制定需求封包之一標頭檔中之複數規格欄位及儲存接收端之複數第二規格；當來源端接收一支付卡之交易時，透過一第一應用程式介面送出包含該交易之需求封包，需求封包為一Http網址，並包含來源端之複數第一規格；應用程式介面管理平台接收該需求封包後，對規格欄位進行轉換，形成符合接收端格式的一新需求封包；接收端透過一第二應用程式介面接收該新需求封包並確認交易後，通過應用程式介面管理平台傳送一回應封包給來源端。A system and method 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 multiple second specifications at the receiving end; when the source receives a When a payment card transaction is made, a request packet containing the transaction is sent through a first API. The request packet is an Http URL and includes a plurality of first specifications of the source end; after the API management platform receives the request packet, it The specification field is converted to form a new request packet conforming to the format of the receiving end; the receiving end receives the new request packet through a second API and confirms the transaction, and then sends a response packet to the source end through the API management platform.
Description
本發明係有關一種新型的金流架構，特別是指一種轉換金融交易應用程式介面規格之系統及其方法。 The present invention relates to a new type of cash flow framework, in particular to a system and method for converting financial transaction application programming interface specifications.
目前交易平台與銀行進行交易時，由於不同機構所使用的訊息格式不盡相同，一般使用應用程式介面(API)格式的交易訊息，雙方約定好規格後，以Https傳輸協定傳送及接收，但不同機構的欄位內容也不相同，難以對接。以第1圖為例，若要將電支機構20和金融機構22對接，則電支機構20與金融機構20需先約定好格式，電支機構20為用戶端，發出請求Request封包，而金融機構22為伺服器端，接收請求後再將Response回應給電支業者20。但由於格式不同，金融機構22難以對接多家電支機構20，同樣電支機構20為了對接多家金融機構22，也需要修改系統以符合不同金融機構22的格式需求，相當耗費時間及人力成本。
At present, when the trading 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. The column content of the institution is also different, making it difficult to connect. Taking Figure 1 as an example, if the
近幾年開放銀行之議題被廣泛討論，開放銀行的核心是技術規範，即應用程式介面(API)，其允許金融系統安全地存取共用資料和跨各方處理事務。若有一第三方機構可提供應用程式介面管理平台，並制定統一規範，利用應用程式介面管理平台進行多方格式轉換。則可快速配合政府政 策提供相應功能，且金融機構在系統最小修改、甚至不用修改之條件下，發想利用應用程式介面管理平台之特性，介接政府機關的資訊系統、一般網路交易平台及金融機構伺服器，實作應用程式介面管理平台之一對多、多對一及多對多之技術應用。 In recent years, the topic of open banking has been widely discussed. The core of open banking is the technical specification, that is, 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 API management platform, and formulate a unified specification, use the API management platform to perform multi-format conversion. can quickly cooperate with government policy The policy provides corresponding functions, and the financial institution thinks to use the characteristics of the application programming interface management platform to interface with the information system of the government agency, the general online trading platform and the server of the financial institution under the condition of minimal or no modification of the system. Implement one-to-many, many-to-one and many-to-many technical applications of the API management platform.
因此，本發明針對上述習知技術之缺失及未來之需求，提出一種轉換金融交易應用程式介面規格之系統及其方法，具體架構及其實施方式將詳述於下： Therefore, the present invention proposes a system and method for converting financial transaction application programming interface specifications in response to the lack of the above-mentioned conventional technology and future needs. The specific architecture and implementation methods will be described in detail below:
本發明之主要目的在提供一種轉換金融交易應用程式介面規格之系統及其方法，其利用應用程式介面管理平台制定一可包容各機構的交易封包規格，並可將規格欄位中的資料從來源端自動轉換成接收端的資料，以達到一對多、多對一及多對多皆可對接的目的。 The main purpose of the present invention is to provide a system and method for converting financial transaction application programming interface specifications, which uses the application programming interface management platform to formulate a transaction package specification that can accommodate various institutions, and can transfer the data in the specification column from the source The terminal automatically converts the data of the receiving terminal to achieve the purpose of one-to-many, many-to-one and many-to-many connections.
本發明之另一目的在提供一種轉換金融交易應用程式介面規格之系統及其方法，其在需求封包的網址上新增一單位代碼識別符，直接區別接收端是哪間機構，加快規格轉換。 Another object of the present invention is to provide a system and method for converting financial transaction API specifications, which adds a unit code identifier to the URL of the request packet to directly distinguish which organization the receiving end is, and speed up specification conversion.
為達上述目的，本發明提供一種轉換金融交易應用程式介面規格之系統，包括：至少一來源端，其為交易平台伺服器或金融機構伺服器，接收一支付卡之交易，並透過一第一應用程式介面送出包含該交易之一需求封包，該需求封包為一Http網址，並包含該來源端之複數第一規格；一應用程式介面管理平台，與該來源端訊號連接，制定該需求封包之一標頭檔中之複數規格欄位，並對該等規格欄位中之該第一規格進行轉換，形成一新需求封包；以及至少一接收端，其為金融機構伺服器或交易平台伺服器，與該應用程式介面管理平台訊號連接，透過一第二應用程式介面接收該新需求封包並確認交易後，通過該應用程式介面管理平台傳送一回應封包給該來源端；其中，該應用程式介面管理平台中儲存該接收端之複數第二規格，當該應用程式介面管理平台接收來自該來源端之該需求封包後，將原先包含該等第一規格之該等規格欄位轉換成該接收端之該等第二規格，以產生符合該接收端之格式的該新需求封包，並傳送到該接收端。In order to achieve the above purpose, the present invention provides a system for converting financial transaction application programming interface specifications, including: at least one source end, which is a transaction platform server or a financial institution server, receives a payment card transaction, and passes a first The application programming interface sends a request packet containing the transaction, the request packet is an Http URL, and includes a plurality of first specifications of the source end; an API management platform is connected to the source end signal, and formulates the request packet Multiple specification fields in a header file, and converting the first specification in these 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 , connected to the API management platform signal, after receiving the new request packet through a second API and confirming the transaction, sending a response packet to the source through the API management platform; wherein, the API The management platform stores multiple second specifications of the receiver, and when the API management platform receives the request packet from the source, converts the specification fields originally containing the first specifications into the receiver the second specifications to generate the new demand packet conforming to the format of the receiving end, and send it to the receiving end.
依據本發明之實施例，該來源端為交易平台伺服器而該接收端為金融機構伺服器時，該接收端為該支付卡之發卡銀行，該需求封包中之該等規格欄位中之單位名稱從該來源端之單位名稱被修改為該發卡銀行之名稱。According to the embodiment of the present invention, when the source end is a trading 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.
依據本發明之實施例，該來源端為交易平台伺服器而該接收端為金融機構伺服器時，該接收端為該支付卡之發卡銀行，該應用程式介面管理平台從該需求封包中找出該接收端之一單位代碼，並做為一單位代碼識別符填入該Http網址中，該單位代碼為該發卡銀行之銀行代碼。According to an embodiment of the present invention, when the source end is a trading platform server and the receiving end is a financial institution server, the receiving end is the issuing bank of the payment card, and the API management platform finds out from the request packet The unit code of the receiving end is filled in the Http website as a unit code identifier, and the unit code is the bank code of the issuing bank.
依據本發明之實施例，該應用程式介面管理平台所制定之該等規格欄位之長度大於等於該等第一規格及該等第二規格之內容長度，且該等第一、第二規格之內容係在該等規格欄位中靠右，左側空白、補零或填入其他符號。According to the embodiment of the present invention, the length of the specification fields formulated by the API 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 on the right side of these specification columns, and the left side is blank, zero-filled or filled with other symbols.
依據本發明之實施例，該來源端為金融機構伺服器而該接收端為交易平台伺服器時，該來源端為該支付卡之發卡銀行，該支付卡係透過自動櫃員機、行動銀行或行動支付送出該交易到該發卡銀行。According to an embodiment of the present invention, 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 made through an automatic teller machine, mobile bank or mobile payment Send the transaction to the issuing bank.
依據本發明之實施例，該等第一規格及該等第二規格之欄位名稱不同但內容為相同意義時，該應用程式介面管理平台將該等規格欄位之欄位名稱進行轉換，以與該接收端所需之欄位名稱一致。According to the embodiment of the present invention, when the field names of the first specification and the second specification are different but the contents have the same meaning, the API management platform converts the field names of the specification fields to Consistent with the field name required by the receiver.
依據本發明之實施例，該支付卡為***。According to an embodiment of the present invention, the payment card is a credit card.
依據本發明之實施例，該需求封包中更包括該支付卡之卡片資料及該交易之交易資訊，該卡片資料包括卡號、效期、金鑰，該交易資訊包括交易時間、交易金額、機台編號、交易驗證碼。According to the embodiment of the present invention, the demand packet further includes the card information of the payment card and the transaction information of the transaction, the card information includes card number, expiration date, and key, and the transaction information includes transaction time, transaction amount, machine platform number, transaction verification code.
依據本發明之實施例，該卡片資料及該交易資訊係經過加密後，透過該應用程式介面管理平台傳送到該接收端進行解密。According to the embodiment of the present invention, the card data and the transaction information are encrypted and then sent to the receiving end through the API management platform for decryption.
本發明另提供一種轉換金融交易應用程式介面規格之方法，包括下列步驟：一應用程式介面管理平台制定一需求封包之一標頭檔中之複數規格欄位，及儲存至少一接收端之複數第二規格；當至少一來源端接收一支付卡之交易時，透過一第一應用程式介面送出包含該交易之該需求封包給該應用程式介面管理平台，該需求封包為一Http網址，並包含該來源端之複數第一規格，且該至少一來源端為交易平台伺服器或金融機構伺服器；該應用程式介面管理平台接收來自該來源端之該需求封包後，對該等規格欄位進行轉換，將原先包含該等第一規格之該等規格欄位轉換成該接收端之該等第二規格，形成符合該接收端之格式的一新需求封包；以及該接收端透過一第二應用程式介面接收該新需求封包並確認交易後，通過該應用程式介面管理平台傳送一回應封包給該來源端，該接收端為金融機構伺服器或交易平台伺服器。The present invention also provides a method for converting financial transaction API specifications, including the following steps: an API management platform formulates multiple specification fields in a header file of a demand packet, and stores multiple specification fields of at least one receiving end Two specifications; when at least one source end receives a payment card transaction, send the request packet containing the transaction to the API management platform through a first API, the request packet is an Http URL, and includes the Multiple first specifications of the source end, and the at least one source end is a trading platform server or a financial institution server; the API management platform converts the specification fields after receiving the request packet from the source end , converting the specification fields originally containing the first specifications into the second specifications of the receiver to form a new demand packet conforming to the format of the receiver; and the receiver through a second application program After receiving the new request packet and confirming the transaction, the interface sends a response packet to the source through the API management platform, and the receiving end is a financial institution server or a trading platform server.
10:轉換金融交易應用程式介面規格之系統 10: System for converting financial transaction application programming interface specifications
12:來源端 12: Source end
122:第一應用程式介面 122: First API
14:應用程式介面管理平台 14: API management platform
16:接收端 16: Receiver
162:第二應用程式介面 162:Second Application Programming Interface
20:電支機構 20: Electric branch
22:金融機構 22: Financial institutions
第1A圖為習知技術電支業者與銀行點對點交易之示意圖。 Fig. 1A is a schematic diagram of a point-to-point transaction between an electronic branch operator and a bank in the prior art.
第1B圖為Http網址之組成架構圖。 Figure 1B is a structural diagram of the Http website.
第2圖為本發明轉換金融交易應用程式介面規格之系統之第一實施例之方塊圖。 Figure 2 is a block diagram of the first embodiment of the system for converting financial transaction API specifications according to the present invention.
第3圖為本發明轉換金融交易應用程式介面規格之方法之流程圖。 Fig. 3 is a flow chart of the method for converting financial transaction API specifications of the present invention.
第4圖為本發明轉換金融交易應用程式介面規格之系統之第二實施例之方塊圖。 Fig. 4 is a block diagram of the second embodiment of the system for converting financial transaction API specifications according to the present invention.
第5圖為本發明轉換金融交易應用程式介面規格之系統之第三實施例之方塊圖。 Fig. 5 is a block diagram of the third embodiment of the system for converting financial transaction API specifications of the present invention.
本發明提供一種轉換金融交易應用程式介面規格之系統及其方法，利用應用程式介面管理平台轉換交易平台及金融機構間不同格式的應用程式訊息封包，可對接多個交易平台和多間金融機構，達到一對多、多對一及多對多之交易需求。 The present invention provides a system and method for converting financial transaction application program interface specifications. The application program interface management platform is used to convert application program message packets in different formats between transaction platforms and financial institutions, and multiple transaction platforms and multiple financial institutions can be connected. Meet one-to-many, many-to-one and many-to-many transaction needs.
請參考第2圖，其為本發明轉換金融交易應用程式介面規格之系統10之第一實施例之方塊圖。轉換金融交易應用程式介面規格之系統10包含至少一個來源端12、一個應用程式介面管理平台14以及至少一個接收端16，應用程式介面管理平台14分別與來源端12及接收端16訊號連接。其中，來源端12及接收端16分別代表交易平台伺服器或金融機構伺服器的其中之一者。而來源端12設置有第一應用程式介面122，接收端設置有第二應用程式介面162。
Please refer to FIG. 2 , which is a block diagram of the first embodiment of the system 10 for converting financial transaction API specifications of the present invention. The system 10 for converting financial transaction API specifications includes at least one
不論來源端12及接收端16為交易平台伺服器或金融機構伺服器，當來源端12先接收支付卡之交易時，當即傳送交易訊息至接收端16進行確認。支付卡包括金融卡、***、儲值卡中的任一者。具體而言，來源端12的第一應用程式介面122送出包含該筆交易的需求封包。需求封包為一Http網址的形式，其中包含來源端12的複數第一規格。需求封包還包括支付卡的卡片資料以及該筆交易的交易資訊：前述卡片資料包括卡號、效期及金鑰等；交易資訊包括交易時間、商品名稱或編號、交易金額、機台編號及交易驗證碼等。支付卡可為***。
Regardless of whether the
應用程式介面管理平台14為具有公信力的第三方中介機構，其提供多方對接的平台。應用程式介面管理平台14制定需求封包之一標頭檔中之複數規格欄位，並對規格欄位中之第一規格進行轉換，形成新需求封包，藉此符合多方不同規格的交易需求。
The application programming
具體來說，應用程式介面管理平台14中預先儲存接收端16之複數第二規格。當應用程式介面管理平台14接收來自來源端12之需求封包後，會從需求封包中找出指定的接收端16與其對應的第二規格。接著，應用程式介面管理平台14將原先包含第一規格之規格欄位，轉換成接收端16之第二規格，藉此產生符合接收端16之格式的新需求封包。
Specifically, the
接收端16透過第二應用程式介面162，接收新需求封包並且確認交易。接著，接收端16透過應用程式介面管理平台14依原始路徑傳送回應封包回來源端12。
The
接下來解釋Http格式的需求封包，請參考第1B圖。第1B圖繪示了一個訊息處理可接受的網址(URL)、Method、Headers(標頭檔)以及
Body(內文)。在本發明中，應用程式介面管理平台14制定需求封包中標頭檔的規格欄位，規格欄位的數量大於等於第一規格及第二規格之數量。例如制式的規格欄位共有10個欄位，若接收端的第二規格只有4個，則應用程式介面管理平台14將該4個規格填入規格欄位中，並將其餘6個欄位刪除。此外，規格欄位之長度也大於等於第一規格及第二規格之內容長度。因此，不論來源端12和接收端16的規格有多長，規格欄位皆足以容納。在規格欄位中，右側排列有第一規格及第二規格之內容，左側的空白部分留白、補零或填入其他符號。
Next, explain the request packet in Http format, please refer to Figure 1B. Figure 1B shows a message processing acceptable URL (URL), Method, Headers (header file) and
Body (text). In the present invention, the
第3圖為轉換金融交易應用程式介面規格之方法之流程圖。於步驟S10中，一應用程式介面管理平台14制定一需求封包之一標頭檔中之複數規格欄位，及儲存至少一接收端16之複數第二規格；接著如步驟S12所述，當來源端12接收支付卡之交易時，透過一第一應用程式介面122送出包含該交易之需求封包給應用程式介面管理平台14，需求封包為一Http網址，並包含該來源端之複數第一規格；步驟S14中，應用程式介面管理平台14接收來自來源端12之需求封包後，對規格欄位進行轉換，將原先包含第一規格之規格欄位轉換成接收端16之第二規格，形成符合接收端16之格式的一新需求封包；最後如步驟S16所述，接收端16透過一第二應用程式介面162接收新需求封包，並確認交易後，通過應用程式介面管理平台14傳送一回應封包給來源端12。來源端12會將交易結果顯示給消費者觀看。
FIG. 3 is a flowchart of a method for converting financial transaction API specifications. In step S10, an
首先說明本發明的第一實施例，請再次參照第2圖。來源端12為交易平台伺服器，例如衛福部的口罩販售平台。接收端16為金融機構伺服器，例如多間有和應用程式管理平台14合作的銀行，換言之，接收端16為支
付卡的發卡銀行。假設持卡人將台灣銀行發行的******來源端12，則來源端依據自定規格、或應用程式介面管理平台14所制定的規格，發送包含第一規格的需求封包。如前文所述，需求封包具有交易資訊，故不再贅述。應用程式介面管理平台14將需求封包轉換為接收端16(即台灣銀行)的第二應用程式介面162的規格後，發送至接收端16取得授權。最後，接收端16在完成交易確認並且核發授權後，將包含授權結果的回應封包依循原始路徑傳送回來源端12，藉此通知持卡人。
Firstly, the first embodiment of the present invention will be described, please refer to Fig. 2 again. The source end 12 is a trading platform server, such as the mask sales platform of the Ministry of Health and Welfare. The receiving
較佳的，需求封包中的規格欄位可規劃卡片資料。舉例而言，在來源端12發送的需求封包中，其規格欄位有一個記載單位名稱的欄位，該欄位填寫有交易平台伺服器的名稱。在應用程式介面管理平台14接受需求封包後，將該欄位修改為發卡銀行的名稱。
Preferably, the specification field in the request packet can plan card data. For example, in the request packet sent by the source end 12, the specification field has a field for recording the name of the unit, and the field is filled with the name of the trading platform server. After the
在實際情況下，不同機構對於同樣的事物會採用不同的名稱。假設第一規格及第二規格之欄位名稱不同，但內容為相同意義時，應用程式介面管理平台14會將規格欄位之欄位名稱進行轉換，藉此與接收端16所需的欄位名稱維持一致。舉例而言，若來源端12傳送來的需求封包中，填入單位名稱的規格欄位是「銀行名稱」，但接收端16同一欄位的名稱卻是「事業單位名稱」。此時，由於應用程式介面管理平台14預先儲存各個接收端16的規格，因此能自動將欄位名稱轉換成「事業單位名稱」，藉此符合接收端16的規格。
In practice, different agencies use different names for the same thing. Assuming that the field names of the first specification and the second specification are different, but the contents have the same meaning, the
較佳的，本發明在需求封包的網址上新增一識別符，提供直接辨別接收端16的發卡銀行。應用程式介面管理平台14從需求封包中找出接收端16之一單位代碼，並做為一單位代碼識別符填入Http網址中，單位代碼為發卡銀行之銀行代碼。舉例而言，若需求封包的網址為
「https：//openapi.fisc.com.tw/mask/v1.0.0/812/Auth」。其中「812」為銀行代碼，其由來源端12填寫。換言之，來源端12或接收端16可直接套用應用程式介面管理平台14所制定的規格，亦可由本段敘述所示，由來源端12或接收端16在網址中增加單位代碼的識別符。
Preferably, the present invention adds an identifier to the website address of the request packet to directly identify the issuing bank of the receiving
接下來說明本發明的第二實施例。請參考第4圖，其為本發明轉換金融交易應用程式介面規格之系統之第二實施例之方塊圖。與第一實施例的差異在於，第二實施例為多對一的實施例。其中，來源端12為金融機構伺服器，也是支付卡的發卡銀行。接收端16為交易平台伺服器，例如政府推出之振興三倍券控管平台。支付卡透過自動櫃員機、行動銀行或行動支付發送交易請求至發卡銀行，亦即發送至來源端12。接著，來源端12(金融機構)依應用程式介面管理平台14的制定規格，同時依據業務情境發送綁定、查詢、取消綁定、審核、鎖定、撥付、ATM取消撥付、查詢取消綁定等訊息，經由應用程式介面管理平台14將訊息轉送至接收端16(如振興三倍券控管平台)，最後依循原始路徑將回應封包傳送回來源端12。由於來源端12的各個參加單位之第一應用程式介面122可能具有不同的規格，因此經由應用程式介面管理平台14轉換為接收端16的第二應用程式介面162的規格。如此一來，來源端12的各個參加單位可維持既有的API規格或微調之API規格傳輸，從而降低系統的開發成本，並且提供快速線上服務。
Next, a second embodiment of the present invention will be described. Please refer to FIG. 4 , which is a block diagram of the second embodiment of the system for converting financial transaction API specifications of the present invention. The difference from the first embodiment is that the second embodiment is a many-to-one embodiment. Wherein, the source end 12 is the server of the financial institution, which is also the issuing bank of the payment card. The receiving
接下來說明本發明第三實施例。請參照第5圖，其為本發明轉換金融交易應用程式介面規格之系統之第三實施例之方塊圖。與第一、第二實施例的差異在於，第三實施例為多對多之實施例。其中，來源端12為交易平台伺服器，例如非金融體系的第三方業者(TSP)。接收端16為金融機構伺
服器。在實際情況下，存在著需要多個交易平台同時對接多間金融機構的交易，例如開通記帳應用程式，其提供用戶查看多間銀行的帳戶資訊。對於消費者來說，開放銀行提供給消費者更大的自由，可以在一個平台上即時查看自己的所有財務狀況，而不是到不同銀行查看及處理多個帳戶。對於銀行來說，銀行有機會透過API向協力廠商開放其核心業務功能，進而擴展其業務。對於第三方業者來說，開放銀行的前提是能夠整合多個金融功能和資料，第三方業者通過整合服務和資料可提供多種創新途徑。金融機構決定開放哪些資料給哪些第三方業者，雙方通過應用程式介面管理平台14控管各API之使用限制。舉例而言，第三方業者(麻布記帳)之行動應用程式欲提供其客戶整合查詢客戶名下各家銀行***之額度，利用應用程式介面管理平台14制定之「查詢客戶個人***額度」的應用程式介面規格，先取得各接收端16(***發卡銀行)同意調用該應用程式介面後，來源端12(第三方業者)即可於客戶選取查詢後，發送應用程式介面至應用程式介面管理平台14，轉送至各接收端16(金融機構)查詢回應該客戶之***額度，並整合顯示查詢結果於客戶的行動裝置上。
Next, a third embodiment of the present invention will be described. Please refer to FIG. 5, which is a block diagram of the third embodiment of the system for converting financial transaction API specifications of the present invention. The difference from the first and second embodiments is that the third embodiment is a many-to-many embodiment. Wherein, the source end 12 is a transaction platform server, such as a third-party provider (TSP) of a non-financial system. Receiving
來源端12和接收端16之間是採點對點方式加密保護。來源端12所送出的卡片資料及交易資訊經過加密後，透過應用程式介面管理平台14傳送到接收端16，最終由接收端16進行解密。因此，應用程式介面管理平台14僅提供封包格式轉換、訊息傳遞的作用，無法解開及讀取到加密的資訊，因此不會有交易資訊外流的風險，可增加個資保護的安全性。
The point-to-point encrypted protection is adopted between the source end 12 and the receiving
綜上所述，藉由本發明所提供之轉換金融交易應用程式介面規格之系統及其方法，利用應用程式介面管理平台制定一可包容各機構的交易封 包規格，並可將需求封包的標頭檔中的規格欄位從來源端的資料自動轉換成接收端的資料，還可以在需求封包的網址上新增一單位代碼識別符，直接區別接收端是哪間機構，加快規格轉換，以使各交易平台伺服器和各金融機構伺服器即使採用不同的應用程式介面規格，仍可達到一對多、多對一及多對多等多方對接的目的。 To sum up, with the system and method for converting financial transaction application programming interface specifications provided by the present invention, the application programming interface management platform is used to develop a transaction envelope that can accommodate various institutions package specification, and can automatically convert the specification field in the header file of the required packet 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 the receiving end. Inter-organizations, speed up specification conversion, so that even if the servers of each trading platform and the servers of each financial institution adopt different API specifications, they can still achieve the purpose of multi-party connection such as one-to-many, many-to-one, and many-to-many.
唯以上所述者，僅為本發明之較佳實施例而已，並非用來限定本發明實施之範圍。故即凡依本發明申請範圍所述之特徵及精神所為之均等變化或修飾，均應包括於本發明之申請專利範圍內。 The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the scope of the present invention. Therefore, all equivalent changes or modifications based on the features and spirit described in the scope of the application of the present invention shall be included in the scope of the patent application of the present invention.
10:轉換金融交易應用程式介面規格之系統 10: System for converting financial transaction application programming interface specifications
12:來源端 12: Source end
122:第一應用程式介面 122: First API
14:應用程式介面管理平台 14: API management platform
16:接收端 16: Receiver
162:第二應用程式介面 162:Second Application Programming Interface
Claims (18)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| TW109139150A TWI787666B (en) | 2020-11-10 | 2020-11-10 | System and method for converting financial transaction API specification |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| TW109139150A TWI787666B (en) | 2020-11-10 | 2020-11-10 | System and method for converting financial transaction API specification |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| TW202219871A TW202219871A (en) | 2022-05-16 |
| TWI787666B true TWI787666B (en) | 2022-12-21 |
Family
ID=82558709
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| TW109139150A TWI787666B (en) | 2020-11-10 | 2020-11-10 | System and method for converting financial transaction API specification |
Country Status (1)
| Country | Link |
|---|---|
| TW (1) | TWI787666B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TW201035889A (en) * | 2009-03-20 | 2010-10-01 | Global Blue Holdings Ab | Interface module, system and method |
| JP5403061B2 (en) * | 2009-09-24 | 2014-01-29 | 日本電気株式会社 | Communication identification system between virtual servers and communication identification method between virtual servers |
| TWI506574B (en) * | 2013-06-20 | 2015-11-01 | Chunghwa Telecom Co Ltd | A flexible system of deployment for cloud network service |
| CN105427101A (en) * | 2015-11-19 | 2016-03-23 | 成都连银信息技术有限公司 | Unified payment access gateway supporting multiple payment channels |
| TWI648690B (en) * | 2012-07-10 | 2019-01-21 | 菲絲博克公司 | Ratings for sponsored advertisements in social networking systems, pricing methods, systems, computer program products |
| TW202004425A (en) * | 2018-04-17 | 2020-01-16 | 美商費瑟朵股份有限公司 | Device presentation with real-time feedback |
| TWM609051U (en) * | 2020-11-10 | 2021-03-11 | 財金資訊股份有限公司 | System for converting interface specification of financial transaction application program |
-
2020
- 2020-11-10 TW TW109139150A patent/TWI787666B/en active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TW201035889A (en) * | 2009-03-20 | 2010-10-01 | Global Blue Holdings Ab | Interface module, system and method |
| JP5403061B2 (en) * | 2009-09-24 | 2014-01-29 | 日本電気株式会社 | Communication identification system between virtual servers and communication identification method between virtual servers |
| TWI648690B (en) * | 2012-07-10 | 2019-01-21 | 菲絲博克公司 | Ratings for sponsored advertisements in social networking systems, pricing methods, systems, computer program products |
| TWI506574B (en) * | 2013-06-20 | 2015-11-01 | Chunghwa Telecom Co Ltd | A flexible system of deployment for cloud network service |
| CN105427101A (en) * | 2015-11-19 | 2016-03-23 | 成都连银信息技术有限公司 | Unified payment access gateway supporting multiple payment channels |
| TW202004425A (en) * | 2018-04-17 | 2020-01-16 | 美商費瑟朵股份有限公司 | Device presentation with real-time feedback |
| TWM609051U (en) * | 2020-11-10 | 2021-03-11 | 財金資訊股份有限公司 | System for converting interface specification of financial transaction application program |
Also Published As
| Publication number | Publication date |
|---|---|
| TW202219871A (en) | 2022-05-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11328293B2 (en) | Systems and methods for multi-merchant tokenization | |
| CN110612546B (en) | Method and apparatus for digital asset account management | |
| RU2642821C2 (en) | Method and system for protected transmition of remote notify service messages to mobile devices without protected elements | |
| KR102025816B1 (en) | Method and system for secure authentication of user and mobile device without secure elements | |
| US6889325B1 (en) | Transaction method and system for data networks, like internet | |
| US5903878A (en) | Method and apparatus for electronic commerce | |
| KR102151579B1 (en) | Method and system for generating an advanced storage key in a mobile device without secure elements | |
| US20080319913A1 (en) | Anonymous online payment systems and methods | |
| US11694182B2 (en) | Systems and methods for displaying payment device specific functions | |
| AU2013224695A1 (en) | Process of and apparatus for notification of financial documents and the like | |
| KR20060070484A (en) | Systems and methods for conducting secure payment transactions using a formatted data structure | |
| TW201023067A (en) | Payment method, system and payment platform capable of improving payment safety by virtual card | |
| US6742125B1 (en) | Distributed protocol for secure communication of commercial transactions and decentralized network employing the protocol | |
| US20220245633A1 (en) | System, Method, and Apparatus for Personalizing Transactions | |
| JP2002543523A (en) | Transaction method and system for a data network such as the Internet | |
| JP2002342688A (en) | Method for electric commerce, settlement proxy method, information issuing method of disposable and post-paying system and settlement requesting method | |
| CA2988809C (en) | Cross-funds management server-based payment system, and method, device and server therefor | |
| US20070253260A1 (en) | Integrating the Internet system of mediation of financial loans, purchase of goods and providing services | |
| TWM609051U (en) | System for converting interface specification of financial transaction application program | |
| TWI787666B (en) | System and method for converting financial transaction API specification | |
| CA2987295C (en) | Payment system based on shared funds-management server, and method, device and server therefor | |
| US20210390546A1 (en) | Systems and Methods for Secure Transaction Processing | |
| CA2988804A1 (en) | Payment system based on shared funds-management server, and method, device and server therefor | |
| US20120150710A1 (en) | method and system for facilitating access to financial information | |
| TWM588303U (en) | Electronic red envelope system |