WO2019196231A1 - Daily payment method and system based on fund share redemption-to-payment transfer - Google Patents

Abstract

A daily payment method based on share-to-payment transfer, which is used in the field of computer network technology services, and which solves the technical problem of using funds to pay fees in daily life services being unavailable in the market. The method comprises the following steps: a system completes docking to a third-party fund company and a service provider and determines whether the fund share of a user is sufficient to pay the bills of daily life services; if the fund share is sufficient to pay the bills, the system is docked to the third-party fund company and the service provider to transfer the redemption of the fund share to payment to complete daily payment; and if the fund share is not sufficient to pay the bills, the user is notified. The described method has the advantage of the user being able to conveniently pay the fees of daily life services, thereby improving the user experience, and reducing pressure on bank transactions.

Description

Daily payment method and system based on fund share redemption

This application claims the priority of the Chinese patent application filed on April 10, 2018, with the application number of 201101816253.8, entitled "A daily payment method and system based on fund share redemption", the overall content of the Chinese patent application It is incorporated herein by reference.

Technical field

The present application relates to the field of Internet service technologies, and in particular, to a daily payment method and system based on fund share redemption.

Background technique

With the development of society and the continuous advancement of technology, people consume more and more payment methods. In the current rapid development of e-commerce, mobile payment and other service functions, it has become very common to pay for all aspects through the Internet. On the one hand, users pay for purchased products through various software-bound bank cards. On the other hand, the platform software will also provide some "wallets" for bank accounts to store small amounts of cash.

Although in recent years, many payment software have introduced payment for daily life services by binding debit cards, etc., but for those who deposit their own extra deposits, they are used in fund investment and financial management to collect certain income. People are often not very convenient.

In this case, the user often needs to perform fund redemption operations in advance, and the bank transaction center will redeem the amount of the redemption to the bank card bound by the user purchase fund, and the user will transfer the amount to the daily The debit card bundled with the payment software is then paid. This series of operations is too cumbersome and complicated, which greatly reduces the user experience and thus puts pressure on bank transactions.

Summary of the invention

Based on this, in order to facilitate users, the user experience is greatly improved and the bank transaction pressure is reduced. It is necessary to provide a daily payment method and system based on share transfer for the above technical problems. The method and system enable the user to directly operate on the software by performing a redemption and payment operation on the user's fund. Use the fund to conduct daily payment operations, greatly improving the user experience.

According to an embodiment of the present application, the present application provides a daily payment method based on share transfer, wherein the system refers to an execution system that runs the method, and the merchant refers to the system and the third-party fund companies to manage and manage each A software platform for a third-party fund, a service provider refers to a software platform that manages users' daily payment, and an operator refers to a company that provides daily life services to users.

The method includes the following steps:

Step 1. The merchant receives the user login information, invokes the system interface, and sends the merchant channel parameter and the user login information to the system. Step 2: The system receives the merchant channel parameter, the user login information, and provides a service selection page for the user to select. The payment service is performed, and the service provider joint login interface is invoked according to the service information selected by the user, and the user login information and the service information are sent to the service provider; Step 3, the service provider receives the user login information and the service information, and Perform a joint login to display the payment account input window to the user; Step 4: The service provider receives the payment account information input by the user, generates a billing query request, and sends the billing query request to the operator; Step 5, the operator generates and sends the billing query result to the service The service provider determines whether the billing result is empty. If yes, the service provider sends “no billing” information to the system, and the system sends “no billing” information to the user, and ends the method; otherwise, step 6 is performed. Step 6, the service provider displays the billing result to the user, and picks up Receiving and executing the user payment instruction, generating a payment order, transmitting the payment order information to the system synchronously, and calling the system cashier interface; the payment order information includes the service information and the payment amount; step 7, the system generates the system order According to the merchant channel parameter, query the cashier routing table, obtain the merchant cashier interface address, and invoke the merchant cashier interface to send the payment order information to the merchant; the cashier routing table includes all The cashier interface address corresponding to the different channel parameters of the merchant; step 8, the merchant receives the payment order information, generates a merchant order, and displays the cashier page to the user for the user to select the payment method; step 9, the merchant receives the user payment instruction, The payment password input interface is displayed, and the password input by the user is verified. If the password is entered correctly, step 10 is performed; otherwise, the password input error message is displayed, and step 9 is performed again; step 10, the merchant displays the wait to the user. Pay the result page and call the system redemption payment interface. System by a user's available funds to pay the payment order; step 11, the merchant payment request to the system polling query results sent order, after receiving the result of payment orders, the payment order status updates, and displays the user.

According to an embodiment of the present application, there is provided a daily payment system based on fund share redemption, the system comprising a data extraction module, a data processing module and a universal module;

The data extraction module is configured to extract and/or acquire files and data in the request, and perform query in other files according to the extracted data, and extract corresponding information;

The data processing module is configured to perform data filtering and data conversion operations according to the data extracted by the data extraction module, generate a request and a message notification, and use the data to perform parsing and determining;

The universal module is configured to perform a timing timing operation, invoke a third-party software interface and a page, and transmit and receive data and requests, and each message notification.

According to an embodiment of the present application, there is provided a computer readable storage medium, wherein the computer readable storage medium stores thereon a program for executing a daily payment method based on a fund share redemption payment, the program being processed by a processor When executed, perform the following steps:

Step 1. The merchant receives the user login information, invokes the system interface, and sends the merchant channel parameter and the user login information to the system. Step 2: The system receives the merchant channel parameter, the user login information, and provides a service selection page for the user to select. The payment service is performed, and the service provider joint login interface is invoked according to the service information selected by the user, and the user login information and the service information are sent to the service provider; Step 3, the service provider receives the user login information and the service information, and Perform a joint login to display the payment account input window to the user; Step 4: The service provider receives the payment account information input by the user, generates a billing query request, and sends the billing query request to the operator; Step 5, the operator generates and sends the billing query result to the service The service provider determines whether the billing result is empty. If yes, the service provider sends “no billing” information to the system, and the system sends “no billing” information to the user, and ends the method; otherwise, step 6 is performed. Step 6, the service provider displays the billing result to the user. Receiving and executing the user payment instruction, generating a payment order, transmitting the payment order information to the system synchronously, and calling the system cashier interface; the payment order information includes the service information and the payment amount; step 7, the system generates the system order According to the merchant channel parameter, query the cashier routing table, obtain the merchant cashier interface address, and invoke the merchant cashier interface to send the payment order information to the merchant; the cashier routing table includes all The cashier interface address corresponding to the different channel parameters of the merchant; step 8, the merchant receives the payment order information, generates a merchant order, and displays the cashier page to the user for the user to select the payment method; step 9, the merchant receives the user payment instruction, The payment password input interface is displayed, and the password input by the user is verified. If the password is entered correctly, step 10 is performed; otherwise, the password input error message is displayed, and step 9 is performed again; step 10, the merchant displays the wait to the user. Pay the result page and call the system redemption payment interface. System by a user's available funds to pay the payment order; step 11, the merchant payment request to the system polling query results sent order, after receiving the result of payment orders, the payment order status updates, and displays the user.

The beneficial effects of the application are mainly: for the different payment platforms, fund companies, fund management platforms, daily service payment platforms, companies providing daily life services, etc., through the user and the fund platform to establish user relationships, so that users can directly use the relevant Software, using the fund share to pay for daily service payments, while greatly improving the user experience and improving the simplicity of daily payment. At the same time, it integrates the functions of daily life service payment and fund redemption and payment, which is easy to maintain in the background and reduces the pressure on bank transactions.

DRAWINGS

1 is a schematic diagram showing the basic flow of a daily payment method based on share transfer according to an embodiment of the present application;

FIG. 2 is a flow chart showing the steps of step S800 of displaying a cashier's page to a user concurrently executing concurrently according to a daily payment method of share transfer according to an embodiment of the present application;

3 is a schematic diagram of a specific process of paying the payment order by the user's available funds in step S1000 in the daily payment method based on share transfer according to an embodiment of the present application;

4 is a schematic diagram of a specific process of a subsequent step after step S1100 in a daily payment method based on share transfer according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a daily payment system architecture based on fund share redemption and payment according to an embodiment of the present application; FIG.

6 is a schematic diagram of an operating environment of a system in which an application is installed, according to an embodiment of the present application.

detailed description

The implementation of the technical solution will be further described in detail below with reference to the accompanying drawings.

It will be understood by those skilled in the art that the following description is to be construed as illustrative of the embodiments of the invention. The present application can be applied to other than the technical details exemplified below, as long as they do not depart from the principles and spirit of the present application.

In addition, in order to avoid limitation of the description of the present specification to the simplifications, in the description in the specification, some technical details that can be obtained in the prior art materials may be omitted, simplified, modified, etc., which is a technique in the art. It is understandable to the person and this does not affect the disclosure adequacy of this specification.

Hereinafter, embodiments for carrying out the present application will be described.

1. Summary of the inventive concept

The application is that, when the user pays the daily service payment on the software platform, the payment cannot be directly made through the fund operation, so that if the user's debit card or the "wallet" balance provided in the software is insufficient, the user wants to use the fund to pay the fee. A series of operations are too cumbersome and complicated, which greatly reduces the user experience, which also puts pressure on bank transactions. If the payment operation cannot be completed on time, it will affect the daily life of users. In order to solve the foregoing technical problems, the present application provides a daily payment method based on fund redemption and payment, integrated fund and daily service payment two functions, the user only needs to use the fund management platform to use the system to conduct daily service bills. The payment operation makes it convenient for users, greatly improving the user experience and reducing the pressure on bank transactions.

2. A daily payment method based on share transfer (Figure 1 to Figure 4)

In view of the prior art, the fund share operation cannot be directly utilized for the daily service payment operation, and the embodiment of the present application proposes a daily payment method that can effectively help and improve the user experience.

In an embodiment, as shown in FIG. 1, the above-mentioned daily payment method based on share transfer mainly includes the following steps:

The system refers to the execution system that runs the method. The merchant refers to the software platform responsible for interfacing with the system and various third-party fund companies and managing various third-party funds. The service provider refers to the software platform that manages the daily payment of users, and the operator Means a company that provides daily life services to users.

It should be noted that the merchant is actually a mobile phone software app that connects different third-party fund companies, and mainly provides related services for the fund, such as introduction, purchase, recommendation, and management of fund products. The service provider refers to the existing software platform for integrating and managing the daily payment of users in the market; and the operator refers to the specific operating companies that provide services such as water, electricity and gas, such as the national grid and the water supply group. The system in this application mainly refers to the main execution system that runs the method, and is used to provide a daily payment interface for merchants.

In addition, the method and the process of daily payment described in the present application are a daily payment process for a single service of a single user, such as water fee payment by a single user.

The method includes the following steps:

S100: The merchant receives the user login information, invokes the system interface, and sends the merchant channel parameter and the user login information to the system. After receiving the user login information, the merchant checks the user login information to check whether the user is logged in. Specifically, the merchant receives the user name and password entered by the user, performs login verification on the user, and queries the user information in the merchant database. If the user name is correct and the password is entered incorrectly, the user displays the "password error" message, and the user is required to re-enter, executing S100; if the user name is wrong, the user is displayed "no such user", The user is required to re-enter, and S100 is executed; if the user name is correct and the password is correct, the merchant receives the user login information, and sends the merchant channel parameter and the user login information to the system, and executes S200. At the same time, the user login information includes a user ID, a user mobile phone number, a user password, and the like registered in the merchant app software; the merchant channel parameter is a parameter set by the merchant in advance before the start of the method, and includes The channel ID and the merchant type are used to distinguish which merchant is, and it is convenient to query the corresponding cashier interface in the cashier routing table at the same time, and at the same time, it is convenient for post-reconciling operations.

S200: The system receives the merchant channel parameter and user login information, and provides a service selection page for the user to select a service that needs to be paid. According to the service information selected by the user, the service provider joint login interface is invoked, and the user login information is Service information is sent to the service provider. The service information refers to information related to the service item of the operator selected by the user, including the service ID, the service item, the corresponding operator related information, and the like. It should be noted that the service selection page provided by the system is used to provide the user with a choice, and selects the service that needs to be paid this time. Each service item corresponds to a different service ID, and the system receives the service item after the user receives the service item. The user instructs, as the service information, the service ID and the operator information of the service item selected by the user, invokes the service provider interface, and sends the service information and the user login information to the service provider. In addition, it should be noted that when the user clicks on the service item, the system automatically records the buried point information for data collection.

S300. The service provider receives the user login information and the service information, and performs joint login, and displays a payment account input window to the user. The payment account input window is for the user to input the account that needs to be paid in the selected service item, such as the water fee and the electricity fee payment, and the account information that needs to be paid. It should be noted that when the service provider receives the current user login information for the first time, it needs to create new user information in the database, and record the user login information into the database. For example, the user information required by the service provider in the user login information is incomplete. Users are also required to make additional entries. When the user is in the subsequent use, the system directly invokes the service provider's joint login interface, and sends the user login information to the service provider. After the service provider performs the database user query, the subsequent steps can be directly performed, and no password verification is required.

S400: The service provider receives the payment account information input by the user, generates a billing query request, and sends the billing query request to the operator. In this step, the service provider generates a bill inquiry request according to the payment account information input by the user, and queries the operator whether the user has a daily service bill for payment at this time. The bill inquiry request includes user login information, service information, payment account information, and operator information. The service provider sends the bill inquiry request to the corresponding operator according to the operator information.

S500: The operator generates and sends the billing query result to the service provider, and the service provider determines whether the billing query result is empty. If yes, execute S510; otherwise, execute S600.

S510: The service provider sends “no billing” information to the system, and the system sends “no billing” information to the user, and the method ends. The operator queries the daily payment bill of the payment account under the user name according to the service information, the payment account information and the user login information in the main bill inquiry request, and if the user has an unpaid bill, the operator continues. Execute S600; otherwise, if the user does not have any bills to be paid under the payment account, after the operator sends the result to the service provider, the service provider notifies the system, and the system notifies the user.

S600, the service provider displays the billing result to the user, receives and executes the user payment instruction, generates a payment order, synchronously sends the payment order information to the system, and invokes a system cashier interface; the payment order information includes service information And the amount of the payment. The billing result contains billing details such as payment items and payment amount. After receiving the user bill query result, the service provider displays the user and waits for the user to click the payment option. If the user clicks on the payment, the service provider generates a payment order, and the payment order includes the user login information and the user payment account information. Required information for all users, such as operator information, service information, merchant channel parameters, payment items, and payment amount.

S700. The system generates a system order, queries a cashier routing table according to the merchant channel parameter, obtains a merchant cashier interface address, and invokes the merchant cashier interface to send the payment order information to the merchant; the cashier The routing table contains the cashier interface addresses corresponding to different channel parameters of all merchants. The system generates a system order according to the data in the payment order information, and queries the cashier routing table in the database according to the merchant ID in the merchant channel parameter, obtains the merchant cashier interface address, and invokes the merchant's cashier according to the address. The interface sends the payment order information to the merchant. It should be noted that, the cashier routing table is a system for assigning merchant channel parameters to the merchant according to an agreement with different merchants before the method of the present application is executed, and is recorded in the cashier routing table.

S800. The merchant receives the payment order information, generates a merchant order, and displays a cashier page to the user for the user to select a payment method. Preferably, when the merchant displays the cashier page to the user, all payment methods are hidden by default, and only the merchant wallet is displayed. The merchant wallet contains all the fund shares purchased and managed by the user in the merchant. Preferably, the merchant wallet converts all fund shares into redeemable amounts when displayed to the user, and displays them to the user.

S900: The merchant receives the user payment instruction, displays the payment password input interface, and checks the password input by the user to determine whether the password input by the user is correct. If yes, execute S1000; otherwise, execute S910. Between S800 and S900, the user can choose to leave the checkout page. If the user leaves the checkout page, the merchant calls the service provider order details query interface, queries the service provider for the order details, and returns the display to the user. At the same time, the user can select The payment is made again, and if the payment is made again, the process returns to S800.

On S910, the merchant displays the message “Password input error” to the user, and executes S900 again. Preferably, the merchant calculates the number of times the S910 is executed each time the S910 is executed. If the user fails to input the password multiple times, the merchant does not re-execute the S900, but displays the message “multiple input errors” to the user, and Go to the merchant login page and end the method.

S1000: The merchant displays the waiting payment result page to the user, and simultaneously invokes the system redemption payment payment interface, and the system pays the payment order through the user's available fund. While the front end of the merchant displays the page waiting for the payment result to the user, the background calls the redemption payment payment interface to the system, and the system cooperates with the third party fund company, the service provider and the operator to perform the redemption payment processing flow. During this period, preferably, in this step, displaying the waiting for payment result page to the user may set a timeout period. If the system has not processed the payment result for the merchant after a long time (a certain time), the merchant directly places the page. Go to the order details page.

S1100: The merchant polls the system to send an order payment result inquiry request, and after receiving the order payment result, updates the payment order status and displays it to the user. The merchant sends an order payment result inquiry request to the system every time interval. If there is a result, the merchant updates the status of the payment order and displays it to the user. If there is no result, the system is still performing the payment operation, and the merchant continues to carry out the round. Inquiry. Preferably, the certain time may be 5 seconds, may be 5 minutes, and may be a preset time of any merchant.

Further, if the merchant polls the system multiple times, after a certain period of time, the timeout processing may be performed, that is, the merchant locks the order, and notifies the background manager to perform abnormal processing on the order.

It should be noted that the merchant not only needs to judge the result of the payment, but also needs to judge the result of the payment. The payment result has success and failure, and there is still no response. This requires the merchant to conduct continuous polling and make corresponding judgments according to the difference of payment results. The payment refers to the process of the system performing the redemption and payment processing operation, and the payment refers specifically to the process of the payment to the operator after the service provider receives the payment result.

Before the status of the payment order is updated, the merchant needs to judge the payment result of the polling. If the payment is successful, the merchant changes the order status to “payable successfully” and displays to the user to end the method; if the payment fails The merchant changes the order status to "Payment failure, pending refund", and initiates the order refund through the background, calls the system's refund interface, and after the system operation personnel confirms, the system calls back the merchant's refund interface to complete the user withdrawal. paragraph.

The specific fund refund process completed by the system by calling the merchant refund interface is as follows:

(1) The merchant calls the system refund interface to generate a refund order and sends it to the system; (2) the system checks the legality of the refund order, and if the order is legal, executes iii; otherwise, returns to the merchant "Refund initiation failed" message, and end this process; (3) the system calls the merchant refund interface, the refund order is sent to the merchant; (4) after the merchant receives the refund order, call the third-party fund company The fund refund interface sends the refund order to the third-party fund company; (5) after receiving the refund order, the third-party fund company refunds the user's fund share and generates a refund. The result is sent to the merchant; (6) after receiving the refund result, the merchant notifies the system, and then the system notifies the service provider; (7) after receiving the refund result, the service provider updates the order status and sends the order status synchronously. (8) After receiving the order status, the system updates the system order status to "Refunded" and ends the process.

According to the embodiment of the present application, the step S800 in the above-mentioned daily payment method based on the share transfer method simultaneously displays the cashier page to the user, and further includes the following steps:

a. The merchant invokes a fund share inquiry interface of the third-party fund company, and sends the fund share inquiry request to the third-party fund company; the fund share inquiry request includes the user login information. Among them, the merchant can display the redemption amount of the user fund in displaying the payment method using the merchant wallet while displaying the cashier page to the user. This step a-c is to query the third party fund company for the user redeemable amount.

b. The third-party fund company queries the available fund shares of the user according to the user login information, and generates a fund query result and sends the result to the merchant; the fund query result includes the redeemable amount into which the available fund share is converted. The third-party fund company queries the user's available fund share according to the user login information in the fund share inquiry request, and converts the available fund share of the user into a redeemable amount, and records the redeemable amount into the fund query result. Send to the merchant.

c. The merchant receives the result of the fund inquiry, determines whether the redeemable amount is less than the payment amount, and if so, executes d; otherwise, executes e.

d. The merchant displays the message “The fund balance is insufficient, cannot be paid” to the user, and ends the method.

e. Display the redemption amount while displaying the cashier page to the user. After receiving the fund inquiry result sent by the third-party fund company, the merchant extracts the redeemable amount, compares the redemption amount with the payment amount in the payment order, and if the redemption amount is less than the payment amount, the fund balance Insufficient to pay; if the redeemable amount is greater than or equal to the payment amount, the redemption amount is displayed in the merchant wallet while the cashier page is displayed to the user. Preferably, if the balance of the user fund is insufficient, the merchant displays the information that the fund balance is insufficient and cannot be paid, and provides the user with other payment methods, such as online banking payment and Alipay payment.

In an embodiment, as shown in FIG. 3, in the above-mentioned daily payment method based on share transfer, the system in S1000 pays the payment order through the available funds of the user, and specifically includes the following steps:

A. The system calls a third party fund company payment interface, generates and sends a fund payment request to the third party fund company; the fund payment request includes user information and a payment amount. The system generates a fund payment request according to the user login information, the payment billing information and the like, and the fund payment request includes the user login information and the required payment amount (the payment amount is equal to the payment amount).

B. After receiving the fund payment request, the third-party fund company, according to the user information, withholds the share of the user fund share equivalent to the payment amount, and returns the payment result to the system. Wherein, the withholding specifically includes the following steps: the third-party fund company locates the available fund shares of the user according to the user information and the payment amount, and redeems the fund share equivalent to the payment amount, and redeems the The money returned is paid to the service provider and the payment result is returned to the system.

C. After receiving the payment result, the system updates the system order status. The payment result may be successful, or may be a failure, or the payment result may be empty. The system needs to judge the payment result. If the payment result is successful, the order status is updated after the order status is updated; if the payment result is If it is a failure, the background manager is notified after the order status is updated. If the payment result is empty, the third-party fund company's withholding operation is abnormal, the system suspends the order and notifies the background management personnel to perform the abnormality check.

In an embodiment, the S1100 described in the above-mentioned daily payment method based on share transfer specifically includes the following steps:

S1101: The merchant generates an order payment result query request every time interval and sends it to the system. The time interval between the merchants and the polling may be 5 seconds, and may be 5 minutes, which may be any predetermined time. At regular intervals, the merchant needs to generate an order payment result inquiry request according to the user login information, the merchant channel parameter, the payment order information and the like in a background, and query the system for the result of the order payment.

S1102: The system queries whether the order payment result sent by the third-party fund company is received, and if yes, executes S1104; otherwise, executes S1103. Among them, once the system receives the order payment result sent by the third-party fund company, it will be sent to the merchant when the merchant polls.

S1103: The system sends a “query failure” message to the merchant, and returns to execute S1101. The merchant can set a timer to judge the time when the order payment result is queried. If the merchant repeatedly queries the order payment result, the “query failure” message is received, and after a certain period of time, the system will change the order status, and Notify the background management personnel to perform abnormal troubleshooting.

S1104: The system sends the order payment result to the merchant, and after receiving the order payment result, the merchant updates the merchant order status and displays the status to the user. The merchant needs to judge the payment result after receiving the payment result of the order. If successful, the status of the updated merchant order is “paid” and displayed to the user; if the payment result is a failure, the status of the updated merchant order is “ The payment fails. At the same time, the system back-office management personnel are coordinated with the refund. If the merchant has not received the payment result for a long time, the system administrator must be notified to perform the order abnormality check.

In the embodiment, as shown in FIG. 4, after the S1100 in the daily payment method based on the share transfer, the following steps are further included:

S1201: The service provider generates a payment order inquiry request every time interval and sends it to the system. The service provider needs to poll the system for payment results every time interval. If the payment is successful, the service provider can continue to perform the payment operation, otherwise the service provider needs to perform abnormal troubleshooting and manual intervention through the system.

S1202: The system queries whether the payment result sent by the third-party fund company is received, and if yes, executes S1204; otherwise, executes S1203.

S1203: The system sends a “query failure” message to the service provider, and returns to execute S1201. If the service provider polls the system for a long time and the system sends a “query failure” messenger, the operator of the service provider needs to notify the background management personnel of the system to perform manual intervention.

S1204. The system sends the payment result to the service provider, and executes S1205.

S1205. The service provider determines whether the payment result is successful. If yes, execute S1206; otherwise, execute S1208.

S1206: The service provider pays the operator, receives the payment result, updates the payment order status, and sends the payment result to the system, and executes S1207. Among them, when the service provider receives the successful payment result, the operator's relevant interface is called, and the bill is also sold or recharged.

S1207: The system updates the system order status to “paid fee” after receiving the payment result. Among them, the merchants will continue to poll the system order status. Once the system order status is "paid", the merchant will notify the user to inform the completion of the daily payment process.

S1208: The service provider modifies the payment order status to “pending payment” and notifies the user. Among them, if the payment fails, the service provider will modify the status of the payment order and notify the system and the merchant in turn, and display the “Payment Failure” to the user, and evoke the refund process (1)-(8).

It should be noted that steps S1101-S1104 and steps S1201-S1208 are performed in parallel.

In the embodiment, before the merchant updates the payment order status in the step S1100 described in the daily payment method of the share transfer, the method further includes the following steps:

S1301: The merchant polls the system for system order status query at a certain time and receives the system order query result. The certain time may be 5 seconds, may be 5 minutes, or may be any time preset by the manual. The merchant polls the system for the order status at regular intervals and queries the system for the latest status of the system order.

S1302: Determine whether the system order query result is “paid”, if yes, the merchant updates the merchant order status, and ends the method; otherwise, returns to execute S1301. Among them, if the merchant has not inquired for a long time that the system order result is “paid”, manual intervention is required.

In an embodiment, the S800 displaying the cashier page to the user in the daily payment method based on the share transfer includes the following steps:

i. The merchant displays the cashier page to the user to determine whether the user leaves the cashier page, and if so, executes i-1; otherwise, executes iii. The step is to determine whether the user has to pay the fee after displaying the cashier page. If it is abandoned, execute i-1; otherwise, continue the payment process.

I-1, the merchant calls the service provider order details query interface, and queries the service provider for the order details, and executes ii;

Ii, receiving the order details sent by the service provider and displaying the order details page to the user, at the same time, setting the payment option on the display order details page, executing iii;

Iii. Determine whether the user clicks on the payment option, and if so, generates a payment instruction, and executes S900; otherwise, the merchant displays the cashier page to the user and continues to wait for the user instruction. Preferably, if the merchant attempter waits for the user instruction and the user does not have any operation, the merchant automatically jumps to the page to return to display the order details.

3. A daily payment system based on fund share redemption (Figure 5)

1 to 4, in accordance with an embodiment of the present application, a daily payment system based on fund share redemption is used to perform the steps of any of the methods of the present application, as shown in FIG. a data extraction module 1000, a data processing module 2000, and a general module 3000;

The data extraction module 1000 is configured to extract and/or acquire data in the file and the request, and perform query in other files according to the extracted data, and extract corresponding information. The data extraction module 1000 includes: a query module 1001 for querying data in files and information; and an extracting module 1002 for extracting and/or acquiring data and information in files and requests;

The data processing module 2000 is configured to perform data filtering and data conversion operations according to the data extracted by the data extraction module, generate a request and a message notification, and perform parsing and determining the corresponding data; the data processing module 2000 The method includes: a processing module 2001 for generating each request, message notification, and status update; and an analysis and determination module 2002 for performing data analysis and determination operations and for performing a data filtering operation;

The universal module 3000 is configured to perform a timing operation, invoke a third-party software interface and a page, and transmit and output data, a request, and a message notification. The universal module 3000 includes: performing all timing and timing operations. The timer module 3001; wherein, the timer module 3001 includes a plurality of sub-modules, such as a timing sub-module for timing operations and a counting sub-module for counting operations; and a third-party software interface for invoking And an invoking module 3002 of the page; and an output module 3003 for outputting, transmitting system data, request, and message notification; and an input module 3004 for receiving data, message notification, each request; and for storing the method of the present application A database 3005 of all the files, information and data required to perform.

Furthermore, various embodiments of the present application can also be implemented by a software module or computer readable instructions stored on one or more computer readable medium, where the computer readable instructions are when When executed, the various embodiments described herein are performed. Similarly, any combination of software modules, computer readable media, and hardware components are contemplated by the present application. The software modules can be stored on any type of computer readable storage medium such as RAM, EPROM, EEPROM, flash memory, registers, hard disk, CD-ROM, DVD, and the like.

4. An application-installed system according to an embodiment of the present application (Fig. 6)

Referring to Figure 6, there is shown an operating environment of a system in which an application is installed in accordance with an embodiment of the present application.

In this embodiment, the system for installing the application is installed and runs in the electronic device. The electronic device may be a computing device such as a desktop computer, a notebook, a palmtop computer, or a server. The electronic device can include, but is not limited to, a memory, a processor, and a display. Figure 6 shows only the electronic device having the above components, but it should be understood that not all illustrated components may be implemented, and more or fewer components may be implemented instead.

The memory may be an internal storage unit of the electronic device, such as a hard disk or memory of the electronic device, in some embodiments. The memory may also be an external storage device of the electronic device in other embodiments, such as a plug-in hard disk equipped on the electronic device, a smart memory card (SMC), and a secure digital (Secure Digital) , SD) card, flash card (Flash Card), etc. Further, the memory may also include both an internal storage unit of the electronic device and an external storage device. The memory is used to store application software installed on the electronic device and various types of data, such as program code of the system in which the application is installed. The memory can also be used to temporarily store data that has been output or is about to be output.

The processor may, in some embodiments, be a central processing unit (CPU), a microprocessor, or other data processing chip for executing program code or processing data stored in the memory, such as performing the Install the application's system, etc.

The display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch sensor, or the like in some embodiments. The display is for displaying information processed in the electronic device and a client interface for displaying visualizations, such as an application menu interface, an application icon interface, and the like. The components of the electronic device communicate with one another via a system bus.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method in the foregoing embodiment can be implemented by means of software plus a necessary general hardware platform, and can also be implemented by hardware, but in many cases. The former is a better implementation. Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk, The optical disc includes a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present application.

That is, according to an embodiment of the present application, there is also provided a computer readable storage medium having stored thereon a program for executing a daily payment method based on a fund share redemption payment, When the program is executed by the processor, the steps of the daily payment method according to an embodiment of the present application are performed.

It will be understood that the specific embodiments of the present invention have been described herein for the purpose of illustration, but the various modifications may be made without departing from the scope of the application. Those skilled in the art will appreciate that the operations and routines depicted in the flowchart steps or described herein can be varied in many ways. More specifically, the order of the steps may be rearranged, the steps may be performed in parallel, the steps may be omitted, other steps may be included, various combinations or omissions of routines may be made. Accordingly, the application is limited only by the accompanying claims.

Claims (17)

1. A daily payment method based on fund share redemption and payment, characterized in that the method comprises the following steps:

   Step 1. The merchant application receives the user login information, invokes the system interface, and sends the merchant channel parameter and the user login information to the system located in the background;

   Step 2: The system receives the merchant channel parameter and the user login information, and provides a service selection page for the user to select a service that needs to be paid. According to the service information selected by the user, the service provider joint login interface is invoked, and the user login information is obtained. And service information is sent to the service provider;

   Step 3: The service provider receives the user login information and the service information, and performs joint login, and displays a payment account input window to the user;

   Step 4: The service provider receives the payment account information input by the user, generates a billing query request, and sends the billing query request to the operator;

   Step 5: The operator generates and sends the billing query result to the service provider, and the service provider determines whether the billing query result is empty. If yes, the service provider sends “no billing” information to the system, and the system sends “no billing information” to the user. Billing information, and end the method at the same time; otherwise, perform step 6;

   Step 6, the service provider displays the billing result to the user, receives and executes the user payment instruction, generates a payment order, sends the payment order information to the system synchronously, and invokes the system cashier interface; the payment order information includes the service Information and the amount of payment;

   Step 7: The system generates a system order, queries the cashier routing table according to the merchant channel parameter, obtains the merchant cashier interface address, and invokes the merchant cashier interface to send the payment order information to the merchant application; The cashier routing table contains the cashier interface addresses corresponding to different channel parameters of all merchants;

   Step 8. The merchant application receives the payment order information, generates a merchant order, and displays a cashier page to the user for the user to select a payment method;

   Step 9. The merchant application receives the user payment instruction, displays the payment password input interface, and verifies the password input by the user. If the password input is correct, step 10 is performed; otherwise, the “password input error” message is displayed, and the steps are re-executed. 9;

   Step 10: The merchant application displays the waiting payment result page to the user, and simultaneously invokes the system redemption payment payment interface, and the system pays the payment order through the user's available fund;

   Step 11. The merchant application sends a system for sending an order payment result query request to the system, and after receiving the payment result of the order, the status of the payment order is updated and displayed to the user.
2. The daily payment method based on the share transfer according to claim 1, wherein the step 8 displays the cashier page to the user, and further includes the following steps: Step a, the merchant application invokes a third-party fund company fund. The share query interface sends the fund share query request to the third-party fund company; the fund share query request includes user login information; step b, the third-party fund company queries the user's available fund share according to the user login information, and generates The fund query result is sent to the merchant application; the fund query result includes the redeemable amount into which the available fund share is converted; step c, the merchant application receives the fund query result, and determines whether the redeemable amount is less than the payment The amount, if yes, the merchant application displays the message "The fund balance is insufficient, cannot be paid" to the user, and ends the method; otherwise, the user displays the cashier page and displays the redeemable amount.
3. The daily payment method based on share transfer according to claim 1, wherein the step 10 comprises the following steps: Step A: The system calls a third party fund company payment interface, generates and sends to a third party fund company. a fund payment request; the fund payment request includes user information and a payment amount; and step B, after the third party fund company receives the fund payment request, according to the user information, the user fund available share is equivalent to the payment amount The share is withheld and the payment result is returned to the system; step C, after receiving the payment result, the system updates the system order status.
4. The daily payment method based on share transfer according to claim 3, wherein the buckle in the step B comprises the following steps: the third party fund company locates according to the user information and the payment amount. The user can use the fund share to redeem the fund share equivalent to the payment amount, and pay the redeemed payment to the service provider, and return the payment result to the system.
5. The daily payment method based on the share transfer according to claim 3, wherein the step 11 comprises the following steps: Step 1101: The merchant application generates an order payment result query request every time interval and sends it to the system. Step 1102, the system queries whether the order payment result sent by the third-party fund company is received, and if yes, step 1104 is performed; otherwise, step 1103 is performed; step 1103, the system sends "query failure" information to the merchant application, and returns to execution. Step 1101: Step 1104: The system sends the order payment result to the merchant application, and after receiving the order payment result, the merchant application updates the merchant order status and displays the status to the user.
6. The daily payment method based on the share transfer according to claim 5, wherein the step 11 further comprises the following steps: Step 1201: The service provider generates a payment order inquiry request every time interval, and sends the request System 1202, the system queries whether the payment result sent by the third-party fund company is received, and if yes, step 1204 is performed; otherwise, step 1203 is performed; step 1203, the system sends a "query failure" message to the service provider, and returns to execution. Step 1201: Step 1204: The system sends the payment result to the service provider, and step 1205 is performed. Step 1205, the service provider determines whether the payment result is successful. If the payment is successful, step 1206 is performed; otherwise, the service provider will The payment order status is modified to "pending payment", and the user is notified; in step 1206, the service provider pays the payment to the operator, receives the payment result and updates the payment order status, and sends the payment result to the system; step 1207, the system receives the After the payment result, the system order status is updated as "paid".
7. The daily payment method based on the share transfer according to claim 6, wherein before the merchant application in the step 11 updates the status of the payment order, the method further includes the following steps: Step 1301: The merchant application is applied at regular intervals. Polling the system for order status inquiry, and receiving the system order query result; step 1302, determining whether the system order query result is "paid", if yes, the merchant application updates the merchant order status, and ends the method; Otherwise, return to step 1301.
8. The daily payment method based on the share transfer according to claim 1, wherein the step 8 comprises the following steps: Step i: The merchant application displays the cashier page to the user to determine whether the user leaves the cashier page. If yes, the merchant application invokes the service provider order details query interface, and queries the service provider for the order details, and performs step ii; otherwise, performs step iii; step ii, receives the order details sent by the service provider, and displays the order details page to the user. At the same time, in the display order details page, set the payment option, perform iii; step iii, determine whether the user clicks the payment option, and if so, generate a payment instruction, perform step 9; otherwise, the merchant application displays the cashier to the user The page continues to wait for user instructions.
9. A daily payment system based on fund share redemption and payment, characterized in that the system comprises a data extraction module, a data processing module and a universal module;

   The data extraction module is configured to extract and/or acquire files and data in the request, and perform query in other files according to the extracted data, and extract corresponding information; the data extraction module includes: a query module for querying data in files and information; and an extraction module for extracting and/or obtaining data and information in files and requests;

   The data processing module is configured to perform data filtering and data conversion operations according to the data extracted by the data extraction module, generate a request and a message notification, and perform parsing and determining the corresponding data; the data processing module includes: a processing module for generating each request, message notification, and status update; and an analysis and determination module for performing data analysis and determination operations and for performing a data filtering operation;

   The universal module is configured to perform a timing timing operation, invoke a third-party software interface and a page, and transmit and receive data and a request, and each message notification; the universal module includes: a timer for performing all timing and timing operations a module; and an invoking module for invoking a third-party software interface and a page; and an output module for outputting, transmitting system data, request, and message notification; and an input module for receiving data, message notification, and each request; And a database for storing all the files, information and data required for the execution of the method of the present application.
10. A computer readable storage medium, wherein the computer readable storage medium stores a program for executing a daily payment method based on a fund share redemption payment, and when the program is executed by the processor, performing the following steps Operation: Step 1. The merchant application receives the user login information, invokes the system interface, and sends the merchant channel parameter and the user login information to the system located in the background; Step 2, the system receives the merchant channel parameter, the user login information, and provides the service. Selecting a page for the user to select a service that needs to be paid. According to the service information selected by the user, the service provider joint login interface is invoked, and the user login information and service information are sent to the service provider; Step 3: The service provider receives the user login Information and service information, and joint login, display the payment account input window to the user; Step 4, the service provider receives the payment account information input by the user, generates a bill inquiry request, and sends it to the operator; Step 5, the operator generates and The billing result is sent to the service provider, and the service provider judges Whether the result of the billing query is empty, and if so, the service provider sends "no billing" information to the system, and the system sends "no billing" information to the user, and the method ends; otherwise, step 6; step 6, service The merchant displays the billing result to the user, receives and executes the user payment instruction, generates a payment order, sends the payment order information to the system synchronously, and invokes the system cashier interface; the payment order information includes the service information and the payment amount. Step 7, the system generates a system order, queries the cashier routing table according to the merchant channel parameter, obtains the merchant cashier interface address, and invokes the merchant cashier interface to send the payment order information to the merchant application; The cashier routing table includes the cashier interface address corresponding to different channel parameters of all merchants; in step 8, the merchant application receives the payment order information, generates a merchant order, and displays the cashier page to the user for the user to select a payment method. Step 9, the merchant application receives the user payment instruction, and displays the payment password. Enter the interface and check the password entered by the user. If the password is entered correctly, go to step 10; otherwise, display the “Password input error” message and repeat step 9; Step 10, the merchant application displays the waiting payment result to the user. The page simultaneously invokes the system redemption payment payment interface, and the system pays the payment order through the user's available fund; in step 11, the merchant application sends a system to send an order payment result inquiry request, and after receiving the order payment result, the payment order status is updated. And show it to the user.
11. The computer readable storage medium according to claim 10, wherein the step 8 displays the cashier page to the user, and further includes the following steps: Step a, the merchant application invokes a third party fund company fund share query interface, The fund share inquiry request is sent to the third-party fund company; the fund share inquiry request includes user login information; step b, the third-party fund company queries the available fund share of the user according to the user login information, and generates a fund query result to be sent to a merchant application; the fund query result includes a redeemable amount into which the available fund share is converted; step c, the merchant application receives the fund query result, and determines whether the redeemable amount is less than the payment amount, and if so, The merchant application displays the message "The fund balance is insufficient, cannot be paid" to the user, and ends the method; otherwise, the user displays the cashier page and displays the redeemable amount.
12. The computer readable storage medium according to claim 10, wherein the step 10 comprises the following steps: Step A: The system calls a third party fund company payment interface, generates and sends a fund payment request to the third party fund company; The fund payment request includes user information and a payment amount; step B, after receiving the fund payment request, the third party fund company, according to the user information, withholding the share of the user fund available share equivalent to the payment amount And returning the payment result to the system; Step C: After receiving the payment result, the system updates the system order status.
13. The computer readable storage medium according to claim 12, wherein the buckle in the step B comprises the following steps: the third party fund company locates the available fund shares of the user according to the user information and the payment amount, The fund share equivalent to the payment amount is redeemed, and the redeemed payment is paid to the service provider, and the payment result is returned to the system.
14. The computer readable storage medium according to claim 12, wherein the step 11 comprises the following steps: Step 1101: The merchant application generates an order payment result query request every time interval and sends it to the system; Step 1102: System Query whether the order payment result sent by the third-party fund company is received, if yes, go to step 1104; otherwise, go to step 1103; step 1103, the system sends "query failure" information to the merchant application, and returns to step 1101; step 1104 The system sends the order payment result to the merchant application, and after receiving the order payment result, the merchant application updates the merchant order status and displays it to the user.
15. The computer readable storage medium according to claim 14, wherein the step 11 further comprises the following steps: Step 1201: The service provider generates a payment order inquiry request every time interval and sends the payment order query request to the system; Step 1202 The system queries whether the payment result sent by the third-party fund company is received, and if yes, step 1204 is performed; otherwise, step 1203 is performed; step 1203, the system sends a "query failure" message to the service provider, and returns to step 1201; step 1204 The system sends the payment result to the service provider, and step 1205 is performed. In step 1205, the service provider determines whether the payment result is successful. If the payment is successful, step 1206 is performed; otherwise, the service provider modifies the payment order status to "Pending payment", and notifying the user; Step 1206, the service provider pays the payment to the operator, receives the payment result and updates the payment order status, and sends the payment result to the system; Step 1207, the system updates the payment after receiving the payment result The system order status is "paid".
16. The computer readable storage medium according to claim 15, wherein before the merchant application in step 11 updates the payment order status, the method further includes the following steps: Step 1301: The merchant application polls the system at regular intervals. The order status is queried, and the system order query result is received; step 1302, determining whether the system order query result is “paid”, if yes, the merchant application updates the merchant order status, and ends the method; otherwise, returns to the execution step 1301.
17. The computer readable storage medium according to claim 10, wherein the step 8 comprises the following steps: Step i: The merchant application displays a cashier page to the user to determine whether the user leaves the cashier page, and if so, the merchant application Calling the service provider order details inquiry interface, and querying the service provider for the order details, performing step ii; otherwise, performing step iii; step ii, receiving the order details sent by the service provider and displaying the order details page to the user, and simultaneously Displaying the order details page, setting the payment option, performing iii; step iii, determining whether the user clicks on the payment option, and if so, generating a payment instruction, performing step 9; otherwise, the merchant application displays the checkout page to the user and continues to wait for the user instruction.

Images