Payment adaptation method based on platform system

Abstract

The invention discloses a payment adaptation method based on a platform system, and belongs to the technical field of transaction function adaptation. According to the method, each three-party platform is independently subjected to adaptive packaging to form an adaptive layer, the selected adaptive layer is configured in the environment variables to serve as the payment layer, the service layer selects the corresponding adaptive layer according to the configured environment variables in the payment response to achieve the calling request, the processing result is converted into the processing message in the needed format, and the processing message is sent to the service layer. The processing message is returned to the access side for payment; the adaptation layer can ensure compatibility between different payment systems and payment modes, so that merchants can accept multiple payment modes, different payment providers can be switched according to reality, and payment scene requirements are met. By using an intermediate adaptation layer, the adaptation layer allows merchants to easily add or change payment options as needed without having to make significant changes to existing payment systems.

Description

Technical Field

[0001] The present invention belongs to the technical field of transaction function adaptation, and specifically is a method based on platform system payment adaptation. Background Art

[0002] With the development of economy, more and more acquiring institutions provide a variety of payment methods, making the payment process safer and more convenient. Application developers (callers) on cash registers / POS need to connect to acquiring applications provided by different acquiring institutions to support the payment methods of the acquiring institutions. However, different acquiring applications have differences in calling methods, communication protocols and process processing. The transaction interfaces provided by each acquiring application are also different. The caller also needs to give different interface prompts according to the calls of different acquiring interfaces.

[0003] The traditional approach is that the caller reconnects to different acquiring applications according to the needs each time, and then repackages the application version for the customer to update in order to support multiple acquiring applications. This processing method has the following disadvantages: the caller must connect according to the protocol document of the new acquiring application each time, which is a large workload; the code needs to be modified and the version needs to be re-released, and the new acquiring application can be used through upgrading; different acquiring applications have different calling methods, which makes the caller code processing complicated and difficult to unify. In addition, the original single service architecture does not have a unified payment center. Every time a new payment method is added, there are many code changes, resulting in a long time for new payment access and low payment efficiency; and after the code is changed, maintenance is difficult, resulting in poor versatility. Therefore, the process of existing third-party apps calling different acquiring applications is very cumbersome and wastes resources. It is also impossible to make different adaptations according to different business scenarios, provide different payment channels and subsequent payment bill process processing, and when the payment process of the third-party payment changes, the Internet platform also needs to be modified synchronously, and it is necessary to ensure that the payment process is consistent with the third-party platform to ensure the smooth operation of the payment capability.

[0004] Although the existing technology uses middleware to achieve unification, the template configuration method used in the existing middleware implementation process is a static template method, that is, parameters or rules are defined in the template file, and then each application parses the parameter value or the content of the custom rule statement by itself, and determines the process to be executed based on the parsing result. However, this method has poor adaptability. Once a new parameter is added or a new different rule statement is added, the application code must be modified and re-upgraded to support the parsing of this parameter or rule statement.

[0005] Application number: CN200710307427.6, entitled A method and payment system for payment through an intermediate platform, comprising: 1) the intermediate platform receives a transaction request sent by a merchant subsystem, the transaction request at least including the user's mobile phone number and transaction information including the payment amount; 2) the intermediate platform searches for the corresponding account information according to the mobile phone number; 3) the intermediate platform uses speech synthesis technology to convert the text form of the transaction information into speech, forming a voice material containing a prompt for the user's response method; 4) the intermediate platform calls the corresponding mobile phone number back to the user, and plays the voice material after the call with the user is connected; 5) the intermediate platform completes the deduction processing of the corresponding account according to the user's response to the voice material, and sends the processing result of this transaction request to the merchant subsystem or to the merchant subsystem and the user respectively. Users can pay by mobile phone, which is convenient and highly secure; however, this payment method cannot solve the problem of the mismatch between the payment ability and account splitting ability of a single payment service provider in different business scenarios. Summary of the invention

[0006] The purpose of the present invention is to address the problem that the payment capability and account splitting capability of a single payment service provider with the same capability in different business scenarios based on the current existing payment methods are not compatible, and a method for payment adaptation based on a platform system is proposed. An adaptation layer is formed by adapting and encapsulating each third-party platform separately, and the selected adaptation layer is configured in the environment variables as the payment layer. In the payment response, the business layer selects the corresponding adaptation layer according to the configured environment variables to implement the call request, and then converts the processing result into a processing message in the required format, and then returns the processing message to the access side for payment. The adaptation layer can ensure the compatibility between different payment systems and payment methods, so that merchants can accept multiple payment methods, and can support switching between different payment providers according to actual conditions to meet the needs of payment scenarios.

[0007] A method for platform system payment adaptation includes the following steps:

[0008] S1. Select multiple third-party platforms that need to be adapted, adapt and encapsulate each third-party platform separately to form an adaptation layer, and configure the selected adaptation layer as the payment layer in the environment variables;

[0009] S2. When the service side receives the payment request initiated by the access side, it verifies the parameters and user information and obtains the verification result;

[0010] S3. If the verification is passed, the corresponding adaptation layer is selected according to the business needs and a call request is initiated to the adaptation layer. After the interface responds, the relevant information of the interface request is saved and the order information is generated. The third-party platform payment interface configured in the system parameters is called for payment processing to obtain a payment response.

[0011] S4. Based on the payment response, the business layer selects the corresponding adaptation layer according to the configured environment variables to implement the call request and obtain the processing result;

[0012] S5. Convert the processing result into a processing message in a required format, and return the processing message to the access side.

[0013] Preferably, the payment platforms of the third-party platform correspond one to one with the configuration units of the adaptation layer, and each payment platform is adapted separately, and the corresponding adaptation layer indicators and then the configuration units are selected based on the actual business scenarios.

[0014] Preferably, the method of selecting the corresponding adaptation layer indicator based on the actual business scenario and then selecting the configuration unit includes: if the actual business scenario gives priority to the adaptation layer indicator with a low payment rate, then a third-party payment platform that pays through a third-party mini program channel is selected; if the actual business scenario gives priority to the adaptation layer indicator with a high stability, then a third-party platform through an official channel is selected.

[0015] Preferably, when the platform is first deployed and initialized, the selected adaptation layer is set in the project's configuration file. When the project is loaded, the selected adaptation layer is read and loaded into memory. If the configuration unit needs to be switched, the adaptation layer is determined by modifying the configuration unit.

[0016] Preferably, each adapter unit will access the log, record the action interaction with the third-party payment platform and store it in an interaction record table. The operator will regularly check the error information and prompts in the interaction based on the interaction record table and manually determine whether switching is required.

[0017] Preferably, in S3, the adaptation layer converts the call request into a payment message in the format required by the third-party platform payment interface, obtains the corresponding request interface from the system parameters, sends the order data to the third-party platform via an https request, and waits for the third-party platform payment interface to respond.

[0018] Preferably, the payment response includes saving the input parameters and return information of the interface request and generating order information within the platform, and giving the payment response of the processing result to the access side.

[0019] Preferably, based on the order information, the user clicks to pay, and the channel information and order information are passed to the platform. The platform passes the channel information and order information to the configuration unit, and the configuration unit obtains the processing result based on the channel verification parameters.

[0020] Preferably, the processing result includes that if the channel verification fails, the payment fails; if the channel verification succeeds, S5 is executed. In addition to the limit scenario, the platform will also verify the inventory quantity of the product, etc. In the case of insufficient inventory, the purchase is restricted, the payment failure is returned, and the corresponding information is fed back.

[0021] Preferably, the S5 includes converting the processing result into a processing message in a unified format, passing the corresponding channel and order information to the third-party platform payment interface through the adaptation layer, and then the interface responds, the third-party platform makes payment, and after the payment is completed, the third-party platform calls back the processing result to the adaptation layer. In simple terms, the third-party platform will return a string of payment vouchers for pulling up Alipay or WeChat payment or other channels to the platform side. After receiving the response, the adaptation layer on the platform side will process the content, return it to the access side, and then pull up the payment of the corresponding channel.

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

[0023] 1. This solution can provide additional security measures such as encryption, identity authentication and anti-fraud checks through the intermediate adaptation layer to protect both parties of the transaction from the threat of data leakage and fraudulent activities; at the same time, the adaptation layer can ensure the compatibility between different payment systems and payment methods (such as credit cards, debit cards, mobile payments, etc.), allowing merchants to accept multiple payment methods.

[0024] 2. For merchants, integrating with an intermediate adaptation layer is usually much simpler than integrating directly with multiple payment systems. The adaptation layer provides a unified interface that simplifies the integration and maintenance of the payment process; by using the intermediate adaptation layer, the adaptation layer allows merchants to easily add or change payment options as needed without making major changes to the existing payment system.

[0025] 3. This solution automates the payment process. The intermediate adaptation layer can reduce manual processing time and improve transaction efficiency. The adaptation layer can provide a seamless payment experience, reduce friction in the payment process, and thus improve customer satisfaction and loyalty. The payment adaptation layer can support switching between different payment providers based on actual needs to meet payment scenario requirements, and provide stable payment capabilities internally to meet the capabilities provided by the business. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is an overall schematic diagram of the present invention. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments.

[0028] Example 1: Figure 1 As shown, a method for platform system payment adaptation includes:

[0029] S1. Select multiple third-party platforms that need to be adapted, adapt and encapsulate each third-party platform separately to form an adaptation layer, and configure the selected adaptation layer as the payment layer in the environment variables.

[0030] Specifically, the payment platforms of the third-party platforms correspond one-to-one to the configuration units of the adaptation layer. Each payment platform is adapted separately, and the corresponding adaptation layer indicators are selected based on the actual business scenarios and then the configuration units are selected.

[0031] It should be noted that selecting the corresponding adaptation layer indicators based on the actual business scenarios and then selecting the configuration units includes: if the actual business scenarios give priority to adaptation layer indicators with low payment rates, then a third-party payment platform that pays through a third-party mini program channel is selected; if the actual business scenarios give priority to adaptation layer indicators with high stability, then a third-party platform through an official channel is selected.

[0032] The adaptation layer solves the problem of incompatibility between the payment and account splitting capabilities of a single payment service provider based on the same capabilities in different business scenarios, and is compatible with multiple payment service providers to adapt different payment capabilities according to different scenarios. The payment adaptation layer on the platform side adapts to multiple service providers, and decides to provide a certain adaptation layer that meets the capabilities to provide payment and other capabilities based on the actual scenario. The adaptation layer smoothes out the separate adaptation of different service providers, provides unified payment capabilities to the outside, and unified account splitting and completion capabilities to the platform side.

[0033] For example, in order to reduce the payment fee, the payee can choose to pay through a third-party payment platform through a third-party mini program channel, which has a lower payment fee. Or if they want stability, they can choose to pay directly to Alipay, WeChat, etc. This kind of official channel third-party platform has relatively high fees, but is more stable.

[0034] The business layer and the adaptation layer are as follows Figure 1 As shown, payment platforms correspond to adapters one by one, and each payment platform needs to be adapted separately. The selection of the most suitable internal logic depends on whether the actual business scenario pursues stability or low fees. If the actual deployment is in Province A, Province A pursues payment stability, takes stability as the priority indicator, and requires the process to run smoothly, then choose a relatively more stable adapter unit, that is, a third-party platform.

[0035] S2. When the service side receives the payment request initiated by the access side, it verifies the parameters and user information and obtains the verification result.

[0036] The verification results include verification passed and verification failed. If the verification passes, it is S3; if the verification fails, it is returned to the access side and logged.

[0037] Payment routing refers to selecting a suitable payment interface provided by a bank or other company to complete the fund transfer operation based on the payment method selected by the user, combined with factors such as rates and QOS. The main function of payment routing is to locate a payment interface for implementation to ensure the efficiency and security of the payment process.

[0038] It is understandable that identity information verification includes: three-factor bank card verification. Many financial institutions and third-party payment platforms have introduced a three-factor bank card verification interface, which effectively confirms the accuracy and security of identity information and prevents fraud risks by verifying in real time whether the name, ID number and bank card number entered by the user match each other.

[0039] It also includes Alipay real-name information verification. Alipay provides a real-name information verification product that obtains the results of the user's real-name information verification by calling the interface to ensure that the account in the current Alipay login status matches the real-name information, thereby improving payment security.

[0040] When selecting and accessing third-party payment products, you need to pay attention to the following points when performing identity information verification:

[0041] Payment fee: Before docking, be sure to communicate the payment fee in detail to avoid high fees later.

[0042] Aggregate payment or third-party payment: Choose the appropriate payment method based on business needs. Aggregate payment can provide integration of multiple payment methods, while third-party payment focuses on a single payment method.

[0043] Selection of payment interface: Determine the list of payment methods provided to users based on information such as payment application, merchant, order amount, etc. to ensure efficient payment process and user experience.

[0044] S3. If the verification passes, the corresponding adaptation layer is selected according to the business needs and a call request is initiated to the adaptation layer. After the interface responds, the relevant information of the interface request is saved and the order information is generated. The third-party platform payment interface configured in the system parameters is called for payment processing to obtain a payment response.

[0045] S4. Based on the payment response, the business layer selects the corresponding adaptation layer according to the configured environment variables to implement the call request and obtain the processing result.

[0046] S5. Convert the processing result into a processing message in a required format, and return the processing message to the access side.

[0047] Among them, the access side: WeChat applet, Android iosApp and other access applications that rely on the payment capabilities of the platform system provide payment functions to the outside world. Business layer: Process the payment requests sent by the access side, use the selected payment adaptation layer to implement the corresponding payment requirements, and record the interaction and capture the abnormal information during the interaction; Adaptation layer: Responsible for one-to-one adaptation of the third-party payment platform, and adapt to a unified capability according to the capabilities required by the platform system. For example, the input parameters of the payment of the third-party platform A and the payment of the third-party platform B are inconsistent, but as long as the business layer gives the same input parameter, the adaptation layer will convert it according to the conversion, and the adaptation layer of A will convert it into what the A payment platform needs, and the adaptation layer of B will convert it into what the B payment platform needs; Third-party platform: Responsible for realizing the subsequent payment process and the interaction at the bank level or the payment tool level to meet financial requirements and supervision.

[0048] This solution can provide additional security measures such as encryption, identity authentication and anti-fraud checks through the intermediate adaptation layer to protect both parties of the transaction from the threat of data leakage and fraudulent activities; at the same time, the adaptation layer can ensure the compatibility between different payment systems and payment methods (such as credit cards, debit cards, mobile payments, etc.), allowing merchants to accept multiple payment methods.

[0049] Example 2: Figure 1 As shown, a method for platform system payment adaptation includes:

[0050] S1. Select multiple third-party platforms that need to be adapted, adapt and encapsulate each third-party platform separately to form an adaptation layer, and configure the selected adaptation layer as the payment layer in the environment variables.

[0051] S2. When the service side receives the payment request initiated by the access side, it verifies the parameters and user information and obtains the verification result.

[0052] S3. If the verification passes, the corresponding adaptation layer is selected according to the business needs and a call request is initiated to the adaptation layer. After the interface responds, the relevant information of the interface request is saved and the order information is generated. The third-party platform payment interface configured in the system parameters is called for payment processing to obtain a payment response.

[0053] S4. Based on the payment response, the business layer selects the corresponding adaptation layer according to the configured environment variables to implement the call request and obtain the processing result.

[0054] S5. Convert the processing result into a processing message in a required format, and return the processing message to the access side.

[0055] Specifically, when the platform is deployed and initialized for the first time, the selected adaptation layer is set in the project's configuration file. When the project is loaded, the selected adaptation layer is read and loaded into the memory. If the configuration unit needs to be switched, the adaptation layer is determined by modifying the configuration unit. Each adaptation unit will log access, record the action interaction with the third-party payment platform and store it in the interaction record table. The operator will regularly check the error information and prompts in the interaction based on the interaction record table to manually determine whether switching is required.

[0056] It should be noted that multiple third-party payment platforms are connected to the Internet platform, and the access to each third-party platform is regarded as an independent adaptation unit (that is, a configuration unit), and multiple adaptation units together constitute an adaptation layer. When adjusting, the switch is used to switch which third-party payment platform is currently connected. Then the access log monitoring records all the processes of interacting with this platform to achieve the purpose of supervision. Once it is found that the capabilities provided by the third-party payment platform are no longer stable, it will continue to switch to other payment adaptation layers that have been involved.

[0057] When the project platform is deployed, it will select the corresponding payment adaptation layer as the payment layer through an environment variable (switch) configured in the project. The switching of the adaptation layer is determined by this environment variable (switch). For example, the platform system is adapted to two payment platforms A and B. When the payment platform A is selected during deployment, the environment variable (switch) is configured to A. When you want to switch, change the environment variable (switch) A to B to achieve the switch. When the platform system starts, it will look for the payment adaptation layer according to the environment variable (switch). If it is not found, the project cannot be started.

[0058] In the system framework, each adaptation layer will be connected to the log, and each action interaction with the third-party payment platform will be recorded and stored in the interaction record table. We can see the interaction records with the third-party platform on the platform management page. The operator will regularly check the error information and prompts in the interaction and manually determine whether switching is needed. Figure 1 As shown in , you can switch to other payment adaptation layers by switching the environment variable (switch).

[0059] For merchants, integrating with an intermediate adaptation layer is usually much simpler than integrating directly with multiple payment systems. The adaptation layer provides a unified interface that simplifies the integration and maintenance of the payment process; by using the intermediate adaptation layer, the adaptation layer allows merchants to easily add or change payment options as needed without making major changes to the existing payment system.

[0060] Example 3: Figure 1 As shown, a method for platform system payment adaptation includes:

[0061] When a user initiates payment from our mini program or app product page, the mini program or app submits the product code, purchase quantity, purchase amount and user information to the platform system through an HTTP request post. The platform system will first verify the user information, and then verify the product validity period and inventory. Once the verification is passed, these input parameters will be passed to the selected adaptation layer A in the memory.

[0062] After the adapter layer A obtains these input parameters, it will convert the product information and amount information into the information required by the third-party platform. For example, the product name field is called name, and the product name in the third-party platform interface is subject. The value of name is given to subject and filled with the value required by the third-party platform payment interface. The corresponding request interface is obtained from the system parameters and maintained in the platform's MySQL database. When obtaining the specified interface, each adapter layer specifies a key, and then finds the corresponding request interface based on the key. The platform will maintain a system parameter table in the database, and some configuration information will be operated by the platform side. When the program is running, it will read data from the system parameter table to execute; after the interface responds, the input parameters and return information of the interface request are saved. Next, the order information inside the platform is generated and saved in the warehouse. After completing these, the response of the processing result is given to the front end, and the front end determines whether the order creation is completed.

[0063] After the order is created, the user clicks on payment and passes the channel information and the newly generated order number to the platform. The platform passes the information to the adaptation layer A, which will verify the parameters based on the channel. For example, WeChat payment requires the WeChat open_id to be passed. If it does not exist, the payment failure will be returned.

[0064] After the parameter verification is successful, the adaptation layer packages the corresponding channel and the parameters required by the corresponding channel, and passes them to the third-party payment platform through http. Then, the response of the interface returns the response of the mini program or app to launch the payment. After the mini program or app receives this response, it can launch WeChat, Alipay or other channels normally, enter the password, and complete the payment.

[0065] After the payment is completed, the third-party platform will actively initiate a callback of the processing result to the corresponding adaptation layer. (The adaptation layers here may be different. It is possible that A is the callback of the processing result initiated by the third-party platform, and B needs to poll the processing result of the specified order of the third-party platform in a short time. Here, A is taken as an example).

[0066] In addition to the user payment scenario, the adaptation layer also has the ability to split the merchant's account. The splitting ability means that after the user pays (buying goods or redeeming cards and coupons), the platform can split the payment amount and pay different merchants or platforms. For example, after user A completes the payment, the platform will record the payment information in the MQ delay queue (a middleware used to store data), and wait until 7 days later, and then split the merchant's account for this payment information. Among them, the account splitters are merchants and commission platforms. The system will split the total amount according to the account splitters and the share ratio corresponding to the bill. At the same time, the payment splitting function of the adaptation layer needs to be called. Based on the three-party order at the time of payment, the calculated share amount and the corresponding account splitter information are passed to the adaptation layer, and the adaptation layer passes the data structure to the three-party platform according to the data format of the three-party platform. After receiving the account split information, the three-party platform returns the account split result information to the adaptation layer, and the three-party platform will pay the corresponding merchant according to the rules to complete the account split operation. After the adaptation layer completes the account splitting, it will periodically check the payment progress and record the results in the database. The platform reads the information in the database and displays it on the platform records.

[0067] This solution automates the payment process, and the intermediate adaptation layer can reduce manual processing time and improve transaction efficiency; the adaptation layer can provide a seamless payment experience, reduce friction in the payment process, and thus improve customer satisfaction and loyalty. The payment adaptation layer can support switching between different payment providers based on actual needs to meet payment scenario requirements, and provide stable payment capabilities internally to meet the capabilities provided by the business.

Claims

1. A method for platform system payment adaptation, characterized in that: The steps include: S1. Select multiple third-party platforms that need to be adapted, adapt and encapsulate each third-party platform separately to form an adaptation layer, and configure the selected adaptation layer as the payment layer in the environment variables; S2. When the service side receives the payment request initiated by the access side, it verifies the parameters and user information and obtains the verification result; S3. If the verification is passed, the corresponding adaptation layer is selected according to the business needs and a call request is initiated to the adaptation layer. After the interface responds, the relevant information of the interface request is saved and the order information is generated. The third-party platform payment interface configured in the system parameters is called for payment processing to obtain a payment response. S4. Based on the payment response, the business layer selects the corresponding adaptation layer according to the configured environment variables to implement the call request and obtain the processing result; S5. Convert the processing result into a processing message in a required format, and return the processing message to the access side.

2. A method for platform system payment adaptation according to claim 1, characterized in that: The payment platforms of the third-party platforms correspond one to one with the configuration units of the adaptation layer. Each payment platform is adapted separately, and the corresponding adaptation layer indicators and configuration units are selected based on the actual business scenarios.

3. A method for platform system payment adaptation according to claim 2, characterized in that: The selecting of the corresponding adaptation layer indicator based on the actual business scenario and then selecting the configuration unit includes: if the actual business scenario gives priority to the adaptation layer indicator with a low payment rate, then a third-party payment platform that pays through a third-party mini program channel is selected; if the actual business scenario gives priority to the adaptation layer indicator with high stability, then a third-party platform of an official channel is selected.

4. A method for platform system payment adaptation according to claim 1, characterized in that: When the platform is first deployed and initialized, the selected adaptation layer is set in the project's configuration file. When the project is loaded, the selected adaptation layer is read and loaded into memory. If the configuration unit needs to be switched, the adaptation layer is determined by modifying the configuration unit.

5. A method for platform system payment adaptation according to claim 4, characterized in that: Each of the adapter units will access the log, record the action interactions with the third-party payment platform and store them in the interaction record table. The operator will regularly check the error information and prompts in the interaction based on the interaction record table and manually determine whether switching is required.

6. A method for platform system payment adaptation according to claim 1, characterized in that: In S3, the adaptation layer converts the call request into a payment message in the format required by the third-party platform payment interface, obtains the corresponding request interface from the system parameters, sends the order data to the third-party platform through an https request, and waits for the third-party platform payment interface to respond.

7. A method for platform system payment adaptation according to claim 6, characterized in that: The payment response includes saving the input parameters and return information of the interface request and generating order information within the platform, and giving the payment response of the processing result to the access side.

8. A method for platform system payment adaptation according to claim 7, characterized in that: Based on the order information, the user clicks to pay and passes the channel information and order information to the platform. The platform passes the channel information and order information to the configuration unit, and the configuration unit obtains the processing result based on the channel verification parameters.

9. A method for platform system payment adaptation according to claim 8, characterized in that: The processing result includes that if the channel verification fails, the payment fails; if the channel verification succeeds, S5 is executed.

10. A method for platform system payment adaptation according to claim 1, characterized in that: The S5 includes converting the processing result into a processing message of a unified format, transmitting the corresponding channel and order information to the third-party platform payment interface through the adaptation layer, and then the interface responds, the third-party platform makes payment, and after the payment is completed, the third-party platform calls back the processing result to the adaptation layer.

Images