CN111401865A - Payment gateway system - Google Patents

Abstract

The invention relates to a payment gateway system, which is connected with the outside of a payment system and the bank side of the payment system, and comprises a payment gateway module, a payment service module and a secret key service module, wherein the payment gateway module is in communication connection with the payment service module, the payment gateway system also comprises a service registration center, the payment service module keeps a unified core logic part in the payment service in a body, and separates out independent service packages formed by interaction logics of all payment mechanisms, all the independent service packages respectively correspond to all the bank terminals at the bank side of the payment system, and all the independent service packages and the unified core logic part are respectively in communication with the service registration center and establish the relationship between the independent service packages and the unified core logic part through the service registration center. Compared with the prior art, the method has the advantages of flexible system structure, improved access efficiency and the like.

Description

A payment gateway system

technical field

The invention relates to the field of online payment, in particular to a payment gateway system.

Background technique

In various applications, online payment scenarios have become more and more common. With more and more payment structures, such as many banks, Alipay, WeChat, etc., the original one payment method is a set of processes. The method is no longer applicable, and a unified payment gateway is required to serve various application scenarios.

In general system applications, payment gateways are mainly used for the connection between business applications and various payment entities. Its basic structure is shown in Figure 1. The payment gateway is the external front-end part of the entire payment gateway system, and is mainly used for receiving various requests. and preliminary verification. The key service is used for the management of payment structure, enterprise's own key and certificate, and provides services such as encryption, decryption, signature, and signature verification according to different institutions. Bank Support Package, a toolkit that may or must be used in payment activities provided by payment institutions. The payment service is the core of the system, which completes the business logic processing of the system itself and records various documents.

The above payment gateway has a payment flow:

1. Outside the payment gateway system, for example, authorized applications (in our company, business systems such as phone bill recharge, card and coupon recharge, fuel card, etc.), initiate payment or refund and other related requests to the payment gateway, and the request should carry the necessary Key information, such as authentication information, order (serial) number of the application, amount of payment (refund), payment institution that must be used, etc.

2. After the payment gateway receives the request, it will sort out the data and hand it over to the payment service for processing. Interact with the requirements of the protocol, through the support package it provides, or complete the protocol message autonomously, and interact with the payment structure.

3. For payment transactions, after the payment service and payment structure complete the "create order" operation, the necessary information needs to be returned to the front end to initiate client or browser payment operations according to the actual requirements of the payment institution, allowing users to make payments action.

4. After the user's payment action is completed, the payment institution will notify the payment gateway of the payment result. After the gateway receives the notification, it will hand over the legal notification information to the payment service for processing.

5. The payment service will decrypt and verify the payment notification according to the agreement with the payment institution. After confirming that the data is legal, it will notify the application corresponding to the order to complete the entire payment process.

In addition, for service requests without UI interaction, such as refunds, queries, etc., the process is basically similar.

The establishment of the above-mentioned payment gateway system enables various business applications to interact with only one "payment institution" without repeated development, and can focus more on expanding their own business. From an abstract point of view, this structure is also suitable for scenarios where multiple applications have the same interaction with multiple third parties, but this infrastructure is only suitable for some entities with small business scales. With the increasing number of payment institutions, some Disadvantages will gradually appear, as follows:

1) The volume of payment services is getting larger and larger, the resource consumption is increasing, and the update startup is getting slower and slower;

2) More and more support packages need to be included, which will bring compatibility risks for some programming languages;

3) The interaction with the payment institution is all within one service, which may be affected by errors in adding and updating services.

SUMMARY OF THE INVENTION

The purpose of the present invention is to provide a payment gateway system in order to overcome the above-mentioned defects of the prior art.

The object of the present invention can be realized through the following technical solutions:

A payment gateway system, the system is connected with the outside of the payment system and the bank side of the payment system, the payment gateway system includes a payment gateway module, a payment service module and a key service module, and the payment gateway module communicates with the payment service module connect,

The payment gateway system further includes a service registration center, and the payment service module keeps the unified core logic part of the payment service in the ontology, and separates independent service packages formed by the interaction logic with each payment institution. The independent service package corresponds to each bank terminal on the bank side of the payment system, and the independent service package and the unified core logic part respectively communicate with the service registration center, and establish the relationship between the two through the service registration center.

Preferably, when the independent service package updates the service, the unified core logic part and other independent service packages keep running normally.

Preferably, the operation of the service registration center for service expansion is as follows: after adding a service instance and registering with the service registration center, the service can be provided externally.

Preferably, the operation of the service registration center for service reduction is as follows: after the registration service center deletes the service information, the corresponding service can be cancelled.

Preferably, the independent service package includes a customized interactive service package and a general interactive service package.

Preferably, for the general interactive service package, the system further includes a code or rule editing entry, a dynamic code or rule loader, and a rule interpretation executor connected in sequence, the general interactive service package and the rule interpretation and execution device connection.

Preferably, when the general interactive service package is executed, according to the payment institution and the operation type, the process logic processing is completed through dynamic code execution or through a rule interpretation executor.

Preferably, the specific process of the dynamic code execution is as follows:

(1) Write a code for a certain operation of the payment institution through the code editing portal, and store it to form a one-to-one structure of payment interface, operation type, and code content;

(2) In actual use, find the corresponding code through the payment institution and operation type, execute it dynamically, and return the corresponding result.

Preferably, the implementation of the rule interpretation executor is as follows: the rule interpretation executor completes the interpretation and operation of the established rules, completes the entire interaction process, and returns the result.

Preferably, the rule interpretation executor includes:

Parameter input rule interpreter: process input parameters as input parameter requirements of payment institutions;

Payment institution message assembler: assemble messages according to payment institution message assembly rules;

Remote Interactor: Interacts with the payment structure according to the transport method definition;

Response message interpreter: Parses the response message of the payment institution according to the return parameter rules, and assembles the return parameters.

Compared with the prior art, the present invention has the following advantages:

1) The system structure is flexible, it can coexist with the basic system structure, the improved structure and the dynamic code method, and the interactive services of the payment institutions have been independent or dynamic during the improvement, and each service is also independent from each other. affected.

2) It can be gradually advanced according to the actual situation of the company. The existing system structure of the company will not be changed. The service registration center will be introduced. The parameter of the processing method is added in the middle, so that those institutions with less business volume can be processed without consuming too many resources.

3) The addition of dynamic processing logic is to abstract the relatively unchanged process in the interaction with the payment institution, and make the changed part dynamic and editable; it increases the flexibility of work and improves the efficiency of access.

Description of drawings

Fig. 1 is the structural block diagram of the existing payment system;

Fig. 2 is the structural block diagram of the payment system of the present invention;

Fig. 3 is the schematic diagram of the expansion and reduction of the service of the present invention;

4 is a structural block diagram of another implementation manner of the present invention;

1 is the external payment system, 2 is the payment gateway system, 3 is the bank side of the payment system, 201 is the payment gateway module, 202 is the payment service module, 203 is the key service module, 204 is the service registration center, and 205 is the independent service package , 206 is the code or rule editing entry, 207 is the dynamic code or rule loader, 208 is the rule interpretation executor, 2081 is the input rule interpreter, 2082 is the payment institution message assembler, 2083 is the remote interactor, and 2084 is the Response message interpreter.

Detailed ways

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative work shall fall within the protection scope of the present invention.

As shown in FIG. 2, a payment gateway system 2 is connected with the outside of the payment system 1 and the bank side 3 of the payment system. The payment gateway system 2 includes a payment gateway module 201, a payment service module 202, and a key service module 203 and the service registration center 204, the payment gateway module 201 is connected in communication with the payment service module 202,

The payment service module keeps the unified core logic part of the payment service in the ontology, and separates the independent service package 205 formed by the interaction logic (creation of orders, refunds, etc.) with each payment institution. The package 205 corresponds to each bank terminal on the bank side 3 of the payment system respectively. The independent service package 205 and the unified core logic part respectively communicate with the service registration center 204 and establish the relationship between the two through the service registration center 204 .

As shown in Figure 3, after separating the most variable interaction part into smaller services, the interaction logic with each payment institution is independent as a separate service. If the support package is involved, it only affects itself. When the service is updated , the payment service core and other payment institutions are not affected at all, which solves the shortcomings of the basic institutions. At the same time, services generally involve two types, one is the service provider, and the other is the service consumer. The service provider provides its own information, such as what service and where (network address) to the service registration center, and the service consumption After finding the required service and address from the service registration center, the user can access and use it. Therefore, when the service is expanded, it is only necessary to add instances and register to the center to provide services to the outside world. On the contrary, after the service information is deleted in the center, consumers cannot find it, and the service will not be provided. Therefore, after the introduction of the service registration center mechanism, It makes it easier to expand and reduce changes in services, and dynamically adjust resources to adapt to business changes according to actual needs.

For most payment institutions, in the process of interacting with them, except for the content and structure of the interactive message, there is no essential difference in the interaction method, and no special support package is required. This application supports by adding dynamic codes or dynamic rules, to further improve efficiency.

As shown in FIG. 4 , the independent service package 205 includes a customized interactive service package 2051 and a general interactive service package 2052 .

For the general interactive service package, the system further includes a code or rule editing entry 206, a dynamic code or rule loader 207, and a rule interpretation executor 208, which are connected in sequence. The general interactive service package 2052 is connected with the rule interpretation Actuator 208 is connected.

The specific implementation process is as follows:

1. Establish a general bank interactive service, dynamic code (rule) loader, and code (rule) editing entry;

2. The service interface definition of the general bank interactive service should be unified and fixed, including creating an order, canceling (refunding), querying payment transactions, querying refund transactions, etc.;

3. According to the payment institution and the type of operation, the general bank interactive service is executed through dynamic code execution or through the rule interpretation executor to complete the process logic processing;

3.1. The dynamic code method can be implemented by using a programming language similar to Groovy (Groovy is an agile dynamic language used for the Java virtual machine).

(1) Write a code for a certain operation of the payment institution through the code editing portal, and store it in a persistent device (location) such as a database and file, and form a one-to-one structure of payment interface, operation type, and code content (such as the code for Bank A to create an order);

(2) In actual use, find the corresponding code through the payment institution and operation type, execute it dynamically, and return the corresponding result;

(3) For the method of writing and using Groovy, please refer to http://www.groovy-lang.org/.

3.2. Implementation of rule interpretation (taking order creation as an example)

(1) The basic process of creating an order is generally to receive input parameters, such as the payment system serial number, payment amount, payment institution (code, number), etc., and then assemble the payment parameters according to the payment institution agreement, and encrypt the assembled parameters ( signed) processing, and then sent to the institution side, the institution side returns the serial number and other parameters required by the user for payment, and the service interface is assembled and returned;

(2) According to the process definition, the rules part must contain;

①Configuration parameter definition, such as merchant number, create order request address, etc.;

②Input parameters, the comparison relationship between configuration parameters and payment institution parameters, and the processing rules of parameters, such as parameter default values, amount processing logic (processing components or elements), etc.;

③The assembly rules of the payment institution's message are generally in the request method, json format, and xml format;

④Participate in the definition of encrypted (signed) content;

⑤Transmission mode definition (socket, http, https one-way, https two-way);

⑥Definition of return parameter format and field comparison relationship (contrary to the input parameters, the reverse mapping here is the return result of the payment system);

(3) The rule interpretation executor completes the interpretation and operation of the established rules, completes the entire interaction process, and returns the result.

Rule interpretation executors can also be divided into multiple, specifically:

Parameter entry rule interpreter 2081: Process the input parameter as an entry requirement of the payment institution;

Payment institution message assembler 2082: Assemble the message according to the payment institution message assembly rule (need to call the key service for encryption and signature);

Remote Interactor 2083: Interacts with the payment structure according to the transmission method definition;

Response message interpreter 2084: parses the payment institution response message according to the return parameter rules, and assembles the return parameters;

Multiple executors work together to complete the task of creating an order.

The addition of dynamic processing logic is to abstract the relatively unchanged process in the interaction with the payment institution, and make the changed part dynamic and editable. Increase the flexibility of work and improve the efficiency of access. However, it is not suitable for some payment institutions with special interactions or requirements. Therefore, customized interactive services and general interactive services coexist, but do not affect each other. With the development of technology, it should be possible to dynamically load and use customized support packages, and finally realize full dynamic operation.

The above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited to this. Any person skilled in the art can easily think of various equivalents within the technical scope disclosed by the present invention. Modifications or substitutions should be included within the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims (10)

1. A payment gateway system is connected with the outside of a payment system and the bank side of the payment system, the payment gateway system comprises a payment gateway module, a payment service module and a secret key service module, the payment gateway module is connected with the payment service module in a communication way, and the payment gateway system is characterized in that,

the payment gateway system also comprises a service registration center, the payment service module keeps a unified core logic part in the payment service in the body, and separates out independent service packages formed by interactive logics with each payment mechanism, each independent service package corresponds to each bank terminal at the bank side of the payment system, each independent service package and the unified core logic part are respectively communicated with the service registration center, and the relationship between the independent service package and the unified core logic part is established through the service registration center.

2. The payment gateway system of claim 1, wherein the unified core logic and the remaining independent service packages are kept operating normally when the independent service packages update services.

3. The payment gateway system of claim 1, wherein the service registry performs service volume expansion as follows: after the service instance is added and registered in the service registration center, the service can be provided to the outside.

4. The payment gateway system of claim 1, wherein the service registry operates specifically for service reduction as follows: after the service information is deleted in the registered service center, the corresponding service can be logged off.

5. The payment gateway system of claim 1, wherein the independent service packages comprise a customized interactive service package and a generic interactive service package.

6. The payment gateway system of claim 5, wherein for said generic interaction service package, said system further comprises a code or rule editing portal, a dynamic code or rule loader and a rule interpretation executor connected in sequence, said generic interaction service package being connected to said rule interpretation executor.

7. The payment gateway system of claim 6, wherein the generic interaction service package, when executed, performs the process logic processing via dynamic code execution or via a rule interpretation executor according to the payment mechanism and operation type.

8. The payment gateway system of claim 7, wherein the dynamic code executes the following specific procedures:

(1) compiling a code aiming at a certain operation of the payment mechanism through a code editing inlet, and storing the code to form a one-to-one structure of a payment interface, an operation type and a code content;

(2) when the method is actually used, the corresponding codes are found through the payment mechanism and the operation type, and are dynamically executed, and the corresponding results are returned.

9. The payment gateway system of claim 7, wherein the rule interpretation executor is implemented as: the rule explanation executor completes the explanation and operation of the established rule, completes the whole interaction process and returns the result.

10. The payment gateway system of claim 7, wherein the rule interpretation executor comprises:

and a reference rule interpreter: processing the input parameters into the participation requirements of the payment mechanism;

a payment mechanism message assembler: assembling messages according to the message assembling rules of the payment mechanism;

the remote interaction device: interacting with the payment structure according to the transmission mode definition;

a response message interpreter: and analyzing the payment mechanism response message according to the return parameter rule, and assembling the return parameters.

Images