WO2019196231A1 - 一种基于基金份额赎转付的日常缴费方法及系统 - Google Patents

一种基于基金份额赎转付的日常缴费方法及系统 Download PDF

Info

Publication number
WO2019196231A1
WO2019196231A1 PCT/CN2018/095734 CN2018095734W WO2019196231A1 WO 2019196231 A1 WO2019196231 A1 WO 2019196231A1 CN 2018095734 W CN2018095734 W CN 2018095734W WO 2019196231 A1 WO2019196231 A1 WO 2019196231A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
order
fund
merchant
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/095734
Other languages
English (en)
French (fr)
Inventor
王小刚
兰楠
唐冬雪
杨斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Publication of WO2019196231A1 publication Critical patent/WO2019196231A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4037—Remote solvency checks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • step 10 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.
  • a daily payment system based on fund share redemption 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.
  • 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.
  • Step 6 the service provider displays the billing result to the user.
  • 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.
  • step 10 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.
  • 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.
  • FIG. 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;
  • step S1000 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;
  • step S1100 is 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system automatically records the buried point information for data collection.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the merchant displays the message “Password input error” to the user, and executes S900 again.
  • 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.
  • the certain time may be 5 seconds, may be 5 minutes, and may be a preset time of any merchant.
  • 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.
  • 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.
  • the merchant 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:
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • the merchant displays the message “The fund balance is insufficient, cannot be paid” to the user, and ends the method.
  • the merchant 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.
  • 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.
  • the system in S1000 pays the payment order through the available funds of the user, and specifically includes the following steps:
  • 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).
  • the third-party fund company 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.
  • 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.
  • the system 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the system sends the payment result to the service provider, and executes S1205.
  • 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).
  • steps S1101-S1104 and steps S1201-S1208 are performed in parallel.
  • the method 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.
  • the S800 displaying the cashier page to the user in the daily payment method based on the share transfer includes the following steps:
  • 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.
  • the merchant calls the service provider order details query interface, and queries the service provider for the order details, and executes ii;
  • 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.
  • 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.
  • a database 3005 of all the files, information and data required to perform.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • CPU central processing unit
  • microprocessor microprocessor
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种基于份额转付的日常缴费方法，用于计算机网络技术服务领域，解决市面中没有利用基金来支付日常生活服务缴费的技术问题，包括如下步骤：系统通过与第三方基金公司以及服务商的对接完成并判断用户的基金份额是否足够缴纳日常生活服务账单；若足以缴纳，则系统通过对接第三方基金公司以及服务商完成利用基金份额的赎转付操作完成日常缴费；若不足以缴纳，则通知用户。方法的有益效果在于方便用户缴纳日常生活服务费用，提高用户体验，降低银行交易压力。

Description

一种基于基金份额赎转付的日常缴费方法及系统
本申请申明享有2018年4月10日递交的申请号为201810316253.8、名称为“一种基于基金份额赎转付的日常缴费方法及系统”的中国专利申请的优先权，该中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
本申请涉及互联网服务技术领域，尤其涉及一种基于基金份额赎转付的日常缴费方法及系统。
背景技术
随着社会的发展及科技的不断进步，人们消费以及支付方式越来越多。在当前电子商务、移动支付等服务功能迅猛发展的情况下，通过互联网进行各方面的支付已经变得非常普遍，一方面，用户通过各类软件绑定的银行卡，对所购买的产品进行支付；另一方面，平台软件亦会提供一些类银行账户的“钱包”来用户存放少额现金。
尽管这些年来，不少支付软件推出了通过绑定借记卡等方式为日常生活的服务进行缴费，但是，对于那些将自身多余的存款，应用于基金投资、理财中，用以收取一定收益的人们来说，往往不大方便。
而在此情况下，用户往往现需要提前进行基金赎回等操作，待银行交易中心将赎回的金额打至用户购买基金所绑定的银行卡中，用户再通过将该金额转账至与日常缴费软件绑定的借记卡中，再进行缴费。这一系列的操作过于繁琐及复杂，使得大大降低用户体验，从而亦给银行交易带来压力。
发明内容
基于此，为了方便用户，大大提高用户体验，降低银行交易压力。有必 要针对上述技术问题，提供一种基于份额转付的日常缴费方法及系统，该方法及系统通过对用户的基金进行赎回转支付的操作，使用户直接在软件上进行操作，即可达到利用基金进行日常缴费的操作，大大提高用户体验。
根据本申请的实施例，本申请提供了一种基于份额转付的日常缴费方法，其中，系统是指运行本方法的执行系统，商户是指负责与系统以及各第三方基金公司对接并管理各类第三方基金的软件平台，服务商是指管理用户日常缴费的软件平台，运营商是指为用户提供日常生活服务的公司，
所述方法包括如下步骤：
步骤1、商户接收用户登录信息，调用系统接口，并将商户渠道参数、用户登录信息发送给系统；步骤2、系统接收所述商户渠道参数、用户登录信息，并提供服务选择页面供用户选择需要进行缴费的服务，根据用户选择的服务信息，调用服务商联合登录接口，并将所述用户登录信息以及服务信息发送给服务商；步骤3、服务商接收所述用户登录信息以及服务信息，并进行联合登录，向用户显示缴费账户输入窗口；步骤4、服务商接收用户输入的缴费账户信息，生成账单查询请求，并发送给运营商；步骤5、运营商生成并将账单查询结果发送给服务商，服务商判断所述账单查询结果是否为空，若是，则服务商向系统发送“无账单”信息，并由系统向用户发送“无账单”信息，同时结束本方法；否则，执行步骤6；步骤6、服务商向用户显示账单查询结果，接收并执行用户缴费指令，生成缴费订单，将所述缴费订单信息同步发送给系统，并调用系统收银台接口；所述缴费订单信息中包含有服务信息以及缴费金额；步骤7、系统生成系统订单，根据所述商户渠道参数，查询收银台路由表，获取商户收银台接口地址，并调用所述商户收银台接口，将所述缴费订单信息发送给商户；所述收银台路由表中包含有所有商户不同渠道参数所对应的收银台接口地址；步骤8、商户接收所述缴费订单信息，生成商户订单，并向用户显示收银台页面，供用户选择支付方式；步骤9、商户接收用户支付指令，显示支付密码输入界面，并对用户所输入 的密码进行校验，若密码输入正确，则执行步骤10；否则，显示“密码输入错误”信息，重新执行步骤9；步骤10、商户向用户显示等待支付结果页面，同时调用系统赎转付支付接口，系统通过用户的可用基金支付所述缴费订单；步骤11、商户向系统轮询发送订单支付结果查询请求，在接收订单支付结果后，更新缴费订单状态，并向用户显示。
根据本申请的实施例，提供了一种基于基金份额赎转付的日常缴费系统，所述系统包括数据提取模块、数据处理模块和通用模块；
其中，所述数据提取模块，用于提取和/或获取文件以及请求中的数据，并根据所提取的数据，在其他文件中进行查询，并提取相应信息；
所述数据处理模块，用于根据数据提取模块所提取出来的数据，进行数据筛选以及进行数据转换操作，生成请求以及报文通知，并用于对相应数据进行解析判断；
所述通用模块，用于进行定时计时操作，调用第三方软件接口及页面，传送输出并接收数据、请求以及各报文通知。
根据本申请的实施例，提供了一种计算机可读存储介质，其中，所述计算机可读存储介质上存储有用于执行基于基金份额赎转付的日常缴费方法的程序，所述程序被处理器执行时，执行以下步骤的操作：
步骤1、商户接收用户登录信息，调用系统接口，并将商户渠道参数、用户登录信息发送给系统；步骤2、系统接收所述商户渠道参数、用户登录信息，并提供服务选择页面供用户选择需要进行缴费的服务，根据用户选择的服务信息，调用服务商联合登录接口，并将所述用户登录信息以及服务信息发送给服务商；步骤3、服务商接收所述用户登录信息以及服务信息，并进行联合登录，向用户显示缴费账户输入窗口；步骤4、服务商接收用户输入的缴费账户信息，生成账单查询请求，并发送给运营商；步骤5、运营商生成并将账单查询结果发送给服务商，服务商判断所述账单查询结果是否为空，若是，则服务商向系统发送“无账单”信息，并由系统向用户发送“无 账单”信息，同时结束本方法；否则，执行步骤6；步骤6、服务商向用户显示账单查询结果，接收并执行用户缴费指令，生成缴费订单，将所述缴费订单信息同步发送给系统，并调用系统收银台接口；所述缴费订单信息中包含有服务信息以及缴费金额；步骤7、系统生成系统订单，根据所述商户渠道参数，查询收银台路由表，获取商户收银台接口地址，并调用所述商户收银台接口，将所述缴费订单信息发送给商户；所述收银台路由表中包含有所有商户不同渠道参数所对应的收银台接口地址；步骤8、商户接收所述缴费订单信息，生成商户订单，并向用户显示收银台页面，供用户选择支付方式；步骤9、商户接收用户支付指令，显示支付密码输入界面，并对用户所输入的密码进行校验，若密码输入正确，则执行步骤10；否则，显示“密码输入错误”信息，重新执行步骤9；步骤10、商户向用户显示等待支付结果页面，同时调用系统赎转付支付接口，系统通过用户的可用基金支付所述缴费订单；步骤11、商户向系统轮询发送订单支付结果查询请求，在接收订单支付结果后，更新缴费订单状态，并向用户显示。
本申请的有益效果主要在于：针对市面上不同支付平台、基金公司、基金管理平台以及日常服务缴费平台、提供日常生活服务的公司等，通过用户与基金平台建立用户关系，使得用户可以直接利用相关软件，利用基金份额支付日常服务缴费，同时，大大提高用户体验，提高日常缴费的简便性。同时，整合日常生活服务缴费以及基金赎转付两大功能，易于后台维护，减少银行交易压力。
附图说明
图1为根据本申请的实施例的一种基于份额转付的日常缴费方法的基本流程示意图；
图2为根据本申请的实施例的一种基于份额转付的日常缴费方法的步骤S800向用户显示收银台页面同时并发执行的步骤流程示意图；
图3为根据本申请的实施例的一种基于份额转付的日常缴费方法中步骤S1000中系统通过用户的可用基金支付所述缴费订单的具体流程示意图；
图4为根据本申请的实施例的一种基于份额转付的日常缴费方法中步骤S1100之后的后续步骤具体流程示意图；
图5为根据本申请的实施例的一种基于基金份额赎转付的日常缴费系统架构示意图；
图6为根据本申请实施例的安装了应用程序的系统的运行环境的示意图。
具体实施方式
下面，结合附图对技术方案的实施作进一步的详细描述。
本领域的技术人员能够理解，尽管以下的说明涉及到有关本申请的实施例的很多技术细节，但这仅为用来说明本申请的原理的示例、而不意味着任何限制。本申请能够适用于不同于以下例举的技术细节之外的场合，只要它们不背离本申请的原理和精神即可。
另外，为了避免使本说明书的描述限于冗繁，在本说明书中的描述中，可能对可在现有技术资料中获得的部分技术细节进行了省略、简化、变通等处理，这对于本领域的技术人员来说是可以理解的，并且这不会影响本说明书的公开充分性。
下文中，将描述用于进行本申请的实施例。
1、发明构思的概要
本申请在于，由于用户在软件平台上进行日常生活服务缴费时无法直接通过基金操作进行缴费，使得如果用户借记卡或者软件中提供的“钱包”余额不足时，用户想要利用基金进行缴费这一系列的操作过于繁琐及复杂，大大降低用户体验，从而亦给银行交易带来压力，若无法如期完成缴费操作，亦会影响用户的日常生活。为解决前述技术问题，本申请提供一种基于基金 赎转付的日常缴费方法，整合基金以及日常生活服务缴费两大功能，用户只需利用基金管理平台，即可利用系统，进行日常生活服务账单的缴费操作，从而方便用户，大大提高用户体验，降低银行交易压力。
2、一种基于份额转付的日常缴费方法(图1至图4)
鉴于现有技术中，不能直接利用基金份额进行日常生活服务缴费操作，本申请的实施例提出了能够有效地帮助并提高用户体验的日常缴费方法。
在实施例中，如图1所示，上述一种基于份额转付的日常缴费方法主要包括以下步骤：
其中，系统是指运行本方法的执行系统，商户是指负责与系统以及各第三方基金公司对接并管理各类第三方基金的软件平台，服务商是指管理用户日常缴费的软件平台，运营商是指为用户提供日常生活服务的公司，
需要说明的是，商户实际是对接不同第三方基金公司的手机软件app，主要为用户提供基金的相关服务，如基金产品的介绍、购买、推荐、管理等。服务商是指在市场中现有的整合管理用户日常生活缴费的软件平台；而运营商是指具体的提供水、电、煤气等服务的运营公司，如各地的国家电网、自来水集团等。本申请中的系统，主要指的是运行本方法的主要执行系统，用于为商户提供日常缴费接口。
另外，本申请中所述日常缴费的方法和流程，是针对单个用户的单一服务中的日常缴费流程，如单个用户的水费缴纳等。
所述方法包括如下步骤：
S100、商户接收用户登录信息，调用系统接口，并将商户渠道参数、用户登录信息发送给系统。商户在接收用户登录信息后，对用户登录信息进行校验，查看是否是用户本人登录，具体为：商户接收用户输入的用户名及密码，对用户进行登录校验，查询商户数据库中的用户信息表，若所述用户名正确，密码输入错误，则向用户显示“密码错误”信息，同时要求用户重新输入，执行S100；若所述用户名错误，则向用户显示“无此用户”，同时要 求用户重新输入，执行S100；若所述用户名正确且密码正确，则商户接收用户登录信息，并将商户渠道参数、用户登录信息发送给系统，执行S200。同时，所述用户登录信息包括在商户app软件中注册的用户ID、用户手机号、用户密码等；所述商户渠道参数是由人工在本方法开始前，提前对不同商户设置的参数，内含渠道ID、商户类型等，用于区分是哪个商户，以及便于后续在收银台路由表中查询对应收银台接口，同时，便于后期进行对账等操作。
S200、系统接收所述商户渠道参数、用户登录信息，并提供服务选择页面供用户选择需要进行缴费的服务，根据用户选择的服务信息，调用服务商联合登录接口，并将所述用户登录信息以及服务信息发送给服务商。服务信息是指用户所选择的运营商的服务项目相关的信息，包含服务ID、服务项目、对应的运营商相关信息等。需要说明的是，系统所提供服务选择页面，用于给用户提供选择，选择其本次需要进行缴费的服务，其中，每个服务项目对应不同的服务ID，用户在点击服务项目后，系统接收用户指令，将用户所选择的服务项目的服务ID以及运营商信息，作为服务信息，调用服务商接口，发送服务信息和用户登录信息给服务商。另外，需要说明的是，当用户点击服务项目后，系统会自动记录埋点信息，用于数据采集。
S300、服务商接收所述用户登录信息以及服务信息，并进行联合登录，向用户显示缴费账户输入窗口。缴费账户输入窗口是让用户输入所选服务项目中所需要进行缴费的账户，如水费、电费缴费中，所需要进行缴费的账户信息。需要说明的是，服务商在首次接收当前用户登录信息时，需要在数据库中新建用户信息，并将该用户登录信息记入数据库中，如该用户登录信息中服务商所需的用户信息不全，还需要用户进行补充录入。当用户在后续使用时，系统直接调用服务商联合登录接口，将用户登录信息发送给服务商，服务商进行数据库用户查询后即可直接进行后续步骤，无需再进行密码校验等步骤。
S400、服务商接收用户输入的缴费账户信息，生成账单查询请求，并发 送给运营商。此步骤是服务商根据用户输入的缴费账户信息，生成账单查询请求，向运营商查询该用户此时是否有需要进行缴费的日常生活服务账单。所述账单查询请求中，有用户登录信息、服务信息、缴费账户信息以及运营商信息等。服务商根据运营商信息，将所述账单查询请求发送给相对应的运营商。
S500、运营商生成并将账单查询结果发送给服务商，服务商判断所述账单查询结果是否为空，若是，则执行S510；否则，执行S600。
S510、服务商向系统发送“无账单”信息，并由系统向用户发送“无账单”信息，同时结束本方法。运营商根据主账单查询请求中的服务信息、缴费账户信息以及用户登录信息等相关信息，对该用户名下该缴费账户的日常生活缴费账单进行查询，如果该用户有尚未缴费的账单，则继续执行S600；否则，如果该用户该缴费账户下已经没有任何需要缴费的账单，则运营商将该结果发送给服务商后，由服务商通知系统，并由系统通知用户。
S600、服务商向用户显示账单查询结果，接收并执行用户缴费指令，生成缴费订单，将所述缴费订单信息同步发送给系统，并调用系统收银台接口；所述缴费订单信息中包含有服务信息以及缴费金额。账单查询结果中包含有账单详情信息，如缴费项目以及缴费金额等。服务商在收到用户账单查询结果后，向用户进行显示，并等待用户点击缴费选项，如果用户点击缴费，则服务商生成缴费订单，所述缴费订单中包含有用户登录信息、用户缴费账户信息、运营商信息、服务信息、商户渠道参数、缴费项目、缴费金额等所有用户缴费的必需信息。
S700、系统生成系统订单，根据所述商户渠道参数，查询收银台路由表，获取商户收银台接口地址，并调用所述商户收银台接口，将所述缴费订单信息发送给商户；所述收银台路由表中包含有所有商户不同渠道参数所对应的收银台接口地址。系统根据缴费订单信息中的数据，生成系统订单，并根据所述商户渠道参数中的商户ID，在数据库中查询收银台路由表，获取商户收 银台接口地址，并根据该地址调用商户的收银台接口，将缴费订单信息发送给商户。需要说明的是，所述收银台路由表是系统在本申请方法执行前，由系统根据与不同商户之间的协议等，为商户分配商户渠道参数，并记入收银台路由表中。
S800、商户接收所述缴费订单信息，生成商户订单，并向用户显示收银台页面，供用户选择支付方式。优选地，商户在向用户显示收银台页面时，默认将所有支付方式均予以隐藏，只显示商户钱包。所述商户钱包中包含有用户在该商户中所购买、管理的所有基金份额。优选地，所述商户钱包在向用户显示时，将所有基金份额转换为可赎金额，向用户显示。
S900、商户接收用户支付指令，显示支付密码输入界面，并对用户所输入的密码进行校验，判断用户所输入的密码是否正确，若是，则执行S1000；否则，执行S910。在S800至S900之间，用户可以选择离开收银台页面，若用户离开收银台页面，则商户调用服务商订单详情查询接口，向服务商查询订单详情，并返回显示给用户，同时，用户可以选择重新进行支付，如果重新进行支付，则返回执行S800。
S910、商户向用户显示“密码输入错误”信息，重新执行S900。优选地，商户每次执行S910时，对执行S910的次数进行计算，如果用户多次输入密码均未成功，则商户不再重新执行S900，而是向用户显示“多次输入错误”信息，并将页面转至商户登录页面，并结束本方法。
S1000、商户向用户显示等待支付结果页面，同时调用系统赎转付支付接口，系统通过用户的可用基金支付所述缴费订单。商户前端向用户显示等待支付结果的页面的同时，后台向系统调用赎转付支付接口，后续由系统配合第三方基金公司、服务商以及运营商进行赎转付处理流程。在此期间，优选地，在该步骤中，向用户显示等待支付结果页面可以设置超时时间，如果系统经过长时间(一定时间)的处理，没有给商户返回支付结果的话，则由商户直接将页面跳转至订单详情页面。
S1100、商户向系统轮询发送订单支付结果查询请求，在接收订单支付结果后，更新缴费订单状态，并向用户显示。商户每间隔一定时间，即向系统发送订单支付结果查询请求，如果有结果，则商户更新缴费订单状态，并向用户显示，如果没有结果，则说明系统还在进行支付操作，则商户继续进行轮询。优选地，所述一定时间，可以是5秒，可以是5分钟，可以是任何一个商户所预先设定的时间。
进一步地，如果商户多次轮询系统，超过一定时间后，可以进行超时处理，即商户对该订单进行锁定，并通知后台管理人员对该订单进行异常处理。
需要说明的是，商户不仅需要判断支付的结果，同时也需要判断缴费的结果。支付结果有成功也有失败，还有未响应，对此需要商户进行不断轮询，根据支付结果的不同进行相应的判断。其中，支付是指系统进行赎转付处理操作的过程，缴费具体指服务商接收支付结果后，向运营商进行缴费的过程。
其中，在所述更新缴费订单状态前，商户需要对轮询的缴费结果进行判断，若缴费成功，则商户将订单状态修改为“缴费成功”，并向用户显示，结束本方法；若缴费失败，则商户将订单状态修改为“缴费失败，待退款”，并由通过后台发起订单退款，调用系统的退款接口，由系统运营人员确认后，系统回调商户的退款接口完成用户退款。
其中，系统通过调用商户退款接口完成的具体的基金退款流程如下：
(1)商户调用系统退款接口，生成退款订单，并发送给系统；(2)系统对所述退款订单进行合法性校验，若该订单合法，则执行iii；否则，向商户返回“退款发起失败”信息，并结束本流程；(3)系统调用商户退款接口，将所述退款订单发送给商户；(4)商户接收所述退款订单后，调用第三方基金公司的基金退款接口，将所述退款订单发送给第三方基金公司；(5)第三方基金公司在接收到所述退款订单后，将用户的基金份额进行退款处理，并生成退款结果发送给商户；(6)商户接收所述退款结果后，通知系统，由系统再通知服务商；(7)服务商接收所述退款结果后，更新订单状态，并 将订单状态同步发送给系统；(8)系统接收所述订单状态后，更新系统订单状态为“已退款”，并结束本流程。
根据本申请的实施例，上述一种基于份额转付的日常缴费方法中所述步骤S800向用户显示收银台页面同时，还包括如下步骤：
a、商户调用第三方基金公司基金份额查询接口，将基金份额查询请求发送给第三方基金公司；所述基金份额查询请求包含用户登录信息。其中，商户在向用户显示收银台页面的同时，在显示利用商户钱包进行缴费的支付方式中，可以显示用户基金的可赎金额。本步骤a-c即为了向第三方基金公司查询用户可赎金额。
b、第三方基金公司根据所述用户登录信息查询所述用户的可用基金份额，生成基金查询结果发送给商户；所述基金查询结果中包含所述可用基金份额转换为的可赎金额。其中，第三方基金公司根据所述基金份额查询请求中的用户登录信息，查询用户的可用基金份额，并将该用户可用基金份额转换成可赎金额，并将该可赎金额记入基金查询结果发送给商户。
c、商户接收所述基金查询结果，判断所述可赎金额是否小于所述缴费金额，若是，则执行d；否则，执行e。
d、商户向用户显示“基金余额不足，无法支付”信息，并结束本方法。
e、向用户显示收银台页面的同时，显示可赎金额。其中，商户在接收第三方基金公司发来的基金查询结果后，提取可赎金额，对该可赎金额与缴费订单中的缴费金额进行比对，若可赎金额小于缴费金额，则说明基金余额不足，无法进行支付；若可赎金额大于或者等于缴费金额，则向用户显示收银台页面的同时，在商户钱包中显示可赎金额。优选地，如果用户基金余额不足，则商户向用户显示“基金余额不足，无法支付”信息后，给用户提供其他支付方式，如网银支付、支付宝支付等。
在实施例中，如图3所示，上述一种基于份额转付的日常缴费方法中所述S1000中系统通过用户的可用基金支付所述缴费订单具体包括如下步骤：
A、系统调用第三方基金公司支付接口，生成并向第三方基金公司发送基金支付请求；所述基金支付请求中包含用户信息以及支付金额。其中，系统根据用户登录信息，缴费账单信息等数据，生成基金支付请求，所述基金支付请求中包含有用户登录信息以及所所需支付的金额(支付金额等于缴费金额)。
B、第三方基金公司接收所述基金支付请求后，根据所述用户信息，对用户基金可用份额等值于所述支付金额的份额进行代扣，并将支付结果返回给系统。其中，所述代扣具体包括如下步骤：第三方基金公司根据所述用户信息以及所述支付金额，定位用户可用基金份额，将等值于支付金额的基金份额进行赎回处理，并将所赎回的款项支付给服务商，同时将支付结果返回给系统。
C、系统接收所述支付结果后，更新系统订单状态。其中，支付结果有可能是成功，亦有可能是失败，也有可能支付结果为空，系统需要对该支付结果进行判断，如果支付结果是成功，则更新订单状态后，进行后续步骤；如果支付结果是失败，则更新订单状态后，通知后台管理人员；如果支付结果为空，即说明第三方基金公司代扣操作异常，则系统将该订单挂起，并通知后台管理人员进行异常排查。
在实施例中，上述一种基于份额转付的日常缴费方法中所述S1100具体包括如下步骤：
S1101、商户每间隔一定时间生成订单支付结果查询请求，并发送给系统。其中，商户轮询所间隔的一定时间，可以是5秒，可以是5分钟，可以是任何一个预先设定好的时间。商户每隔一定时间，需要在后台，根据用户登录信息、商户渠道参数、缴费订单信息等数据，生成订单支付结果查询请求，向系统查询订单支付的结果。
S1102、系统查询是否接收到第三方基金公司发来的订单支付结果，若是，则执行S1104；否则，执行S1103。其中，系统一旦接收到第三方基金 公司发来的订单支付结果，在商户进行轮询时，将会发送给商户。
S1103、系统向商户发送“查询失败”信息，并返回执行S1101。其中，商户可以设置定时器，对查询订单支付结果的时间进行判断，如果商户多次查询订单支付结果，均接收到“查询失败”信息，在超过一定时间后，系统将会变更订单状态，并通知后台管理人员，进行异常排查。
S1104、系统向商户发送所述订单支付结果，商户在接收所述订单支付结果后，更新商户订单状态，并向用户显示。其中，商户在收到订单支付结果后需要对该支付结果进行判断，如果成功，则更新商户订单状态为“已支付”，并向用户显示；如果支付结果是失败，则更新商户订单状态为“支付失败”，同时向系统后台管理人员协调退款事宜；如果商户长时间未收到支付结果，则需要通知系统后台管理人员进行订单异常排查。
在实施例中，如图4所示，上述一种基于份额转付的日常缴费方法中所述S1100之后还包括如下步骤：
S1201、服务商每间隔一定时间生成支付订单查询请求，并发送给系统。其中，服务商需要每间隔一定时间向系统轮询支付结果，如果支付成功，则服务商可以继续进行缴费操作，否则服务商需要通过系统进行异常排查以及人工介入。
S1202、系统查询是否接收到第三方基金公司发来的支付结果，若是，则执行S1204；否则，执行S1203。
S1203、系统向服务商发送“查询失败”信息，并返回执行S1201。其中，如果服务商长时间多次向系统轮询，系统均发送“查询失败”信使时，需要服务商的运营人员通知系统的后台管理人员进行人工介入。
S1204、系统向服务商发送所述支付结果，并执行S1205。
S1205、服务商判断所述支付结果是否成功，若是，则执行S1206；否则，执行S1208。
S1206、服务商向运营商进行缴费，接收缴费结果并更新所述缴费订单 状态，将缴费结果发送给系统，执行S1207。其中，当服务商得到支付成功结果后，会调用运营商的相关接口，进行账单销账亦或是充值。
S1207、系统接收所述缴费结果后更新所述系统订单状态为“已缴费”。其中，商户亦会不断轮询查询系统订单状态，一旦查询到系统订单状态为“已缴费”后，商户会通知用户，告知本次日常缴费流程顺利完成。
S1208、服务商将所述缴费订单状态修改为“待支付”，并通知用户。其中，如果缴费失败，服务商将会修改缴费订单状态并依次通知系统和商户，并向用户显示“缴费失败”，并唤起退款流程(1)-(8)。
需要说明的是，步骤S1101-S1104以及步骤S1201-S1208之间为并行执行。
在实施例中，上述一种基于份额转付的日常缴费方法中所述步骤S1100商户更新缴费订单状态前，还包括如下步骤：
S1301、商户每隔一定时间向系统轮询系统订单状态查询，并接收所述系统订单查询结果。其中，所述一定时间可以是5秒，可以是5分钟，亦可以是人工所预先设定的任何时间。商户每间隔一定时间向系统轮询订单状态，查询系统的系统订单的最新状态结果。
S1302、判断所述系统订单查询结果是否为“已缴费”，若是，则商户更新商户订单状态，并结束本方法；否则，返回执行S1301。其中，如果商户长时间均未查询到系统订单结果为“已缴费”，则需要进行人工介入。
在实施例中，上述一种基于份额转付的日常缴费方法中所述S800向用户显示收银台页面具体包括如下步骤：
i、商户向用户显示收银台页面，判断用户是否离开收银台页面，若是，则执行i-1；否则，执行iii。其中，此步骤是为了判断用户是否在显示收银台页面后，放弃缴费，如果放弃，则执行i-1；否则，继续缴费流程。
i-1、商户调用服务商订单详情查询接口，并向服务商查询订单详情，执行ii；
ii、接收服务商发送的所述订单详情并向用户显示订单详情页面，同时，在所述显示订单详情页面，设置支付选项，执行iii；
iii、判断用户是否点击所述支付选项，若是，则生成支付指令，执行S900；否则，商户向用户显示收银台页面并继续等待用户指令。其中，优选地，如果商户尝试件等待用户指令，用户没有任何操作，则商户会自动跳转页面返回显示订单详情。
3 、一种基于基金份额赎转付的日常缴费系统(图5)
参照图1至4，根据本申请的实施例，一种基于基金份额赎转付的日常缴费系统用于执行本申请中的任一个所述方法的步骤，如图5所示，所述系统包括数据提取模块1000、数据处理模块2000和通用模块3000；
其中，所述数据提取模块1000，用于提取和/或获取文件以及请求中的数据，并根据所提取的数据，在其他文件中进行查询，并提取相应信息；所述数据提取模块1000包括：用于在文件以及信息中查询数据的查询模块1001；以及用于在文件以及请求中提取和/或获取数据以及信息的提取模块1002；
所述数据处理模块2000，用于根据数据提取模块所提取出来的数据，进行数据筛选以及进行数据转换操作，生成请求以及报文通知，并用于对相应数据进行解析判断；所述数据处理模块2000包括：用于生成各请求、报文通知并进行状态更新的处理模块2001；以及用于进行数据解析及判断操作以及用于进行数据筛选操作的解析判断模块2002；
所述通用模块3000，用于进行定时计时操作，调用第三方软件接口及页面，传送输出并接收数据、请求以及各报文通知；所述通用模块3000包括：用于进行所有定时、计时操作的定时器模块3001；其中，需要说明的是，定时器模块3001中包含有众多子模块，如用于计时操作的定时子模块以及用于计数操作的计数子模块；以及用于调用第三方软件接口以及页面的调用模块3002；以及用于输出、传送系统数据、请求以及报文通知的输出模块3003； 以及用于接收数据、报文通知、各请求的输入模块3004；以及用于存储本申请方法执行所需的所有文件、信息和数据的数据库3005。
此外，本申请的不同实施例也可以通过软件模块或存储在一个或多个计算机可读介质上的计算机可读指令的方式实现，其中，所述计算机可读指令是当被处理器或设备组件执行时，执行本申请所述的不同的实施例。类似地，软件模块、计算机可读介质和硬件部件的任意组合都是本申请预期的。所述软件模块可以被存储在任意类型的计算机可读存储介质上，例如RAM、EPROM、EEPROM、闪存、寄存器、硬盘、CD-ROM、DVD等等。
4、根据本申请的实施例的安装了应用程序的系统(图6)
参照图6，其示出了根据本申请实施例的安装了应用程序的系统的运行环境。
在本实施例中，所述的安装应用程序的系统安装并运行于电子装置中。所述电子装置可以是桌上型计算机、笔记本、掌上电脑及服务器等计算设备。该电子装置可包括但不限于存储器、处理器及显示器。图6仅示出了具有上述组件的电子装置，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
所述存储器在一些实施例中可以是所述电子装置的内部存储单元，例如该电子装置的硬盘或内存。所述存储器在另一些实施例中也可以是所述电子装置的外部存储设备，例如所述电子装置上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器还可以既包括所述电子装置的内部存储单元也包括外部存储设备。所述存储器用于存储安装于所述电子装置的应用软件及各类数据，例如所述安装应用程序的系统的程序代码等。所述存储器还可以用于暂时地存储已经输出或者将要输出的数据。
所述处理器在一些实施例中可以是中央处理单元(Central Processing Unit，CPU)、微处理器或其他数据处理芯片，用于运行所述存储器中存储的 程序代码或处理数据，例如执行所述安装应用程序的系统等。
所述显示器在一些实施例中可以是LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。所述显示器用于显示在所述电子装置中处理的信息以及用于显示可视化的客户界面，例如应用菜单界面、应用图标界面等。所述电子装置的部件通过系统总线相互通信。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解，上述实施方式中的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件来实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。
也就是说，根据本申请的实施例，还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有用于执行一种基于基金份额赎转付的日常缴费方法的程序，所述程序被处理器执行时，执行根据本申请的实施例的所述日常缴费方法的步骤。
由上，将理解，为了说明的目的，这里已描述了本申请的具体实施例，但是，可作出各个修改，而不会背离本申请的范围。本领域的技术人员将理解，流程图步骤中所绘出或这里描述的操作和例程可以多种方式变化。更具体地，可重新安排步骤的次序，可并行执行步骤，可省略步骤，可包括其它步骤，可作出例程的各种组合或省略。因而，本申请仅由所附权利要求限制。

Claims (17)

  1. 一种基于基金份额赎转付的日常缴费方法，其特征在于，所述方法包括如下步骤：
    步骤1、商户应用接收用户登录信息，调用系统接口，并将商户渠道参数、用户登录信息发送给位于后台的系统；
    步骤2、系统接收所述商户渠道参数、用户登录信息，并提供服务选择页面供用户选择需要进行缴费的服务，根据用户选择的服务信息，调用服务商联合登录接口，并将所述用户登录信息以及服务信息发送给服务商；
    步骤3、服务商接收所述用户登录信息以及服务信息，并进行联合登录，向用户显示缴费账户输入窗口；
    步骤4、服务商接收用户输入的缴费账户信息，生成账单查询请求，并发送给运营商；
    步骤5、运营商生成并将账单查询结果发送给服务商，服务商判断所述账单查询结果是否为空，若是，则服务商向系统发送“无账单”信息，并由系统向用户发送“无账单”信息，同时结束本方法；否则，执行步骤6；
    步骤6、服务商向用户显示账单查询结果，接收并执行用户缴费指令，生成缴费订单，将所述缴费订单信息同步发送给系统，并调用系统收银台接口；所述缴费订单信息中包含有服务信息以及缴费金额；
    步骤7、系统生成系统订单，根据所述商户渠道参数，查询收银台路由表，获取商户收银台接口地址，并调用所述商户收银台接口，将所述缴费订单信息发送给商户应用；所述收银台路由表中包含有所有商户不同渠道参数所对应的收银台接口地址；
    步骤8、商户应用接收所述缴费订单信息，生成商户订单，并向用户显示收银台页面，供用户选择支付方式；
    步骤9、商户应用接收用户支付指令，显示支付密码输入界面，并对用 户所输入的密码进行校验，若密码输入正确，则执行步骤10；否则，显示“密码输入错误”信息，重新执行步骤9；
    步骤10、商户应用向用户显示等待支付结果页面，同时调用系统赎转付支付接口，系统通过用户的可用基金支付所述缴费订单；
    步骤11、商户应用向系统轮询发送订单支付结果查询请求，在接收订单支付结果后，更新缴费订单状态，并向用户显示。
  2. 根据权利要求1所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤8向用户显示收银台页面同时，还包括如下步骤：步骤a、商户应用调用第三方基金公司基金份额查询接口，将基金份额查询请求发送给第三方基金公司；所述基金份额查询请求包含用户登录信息；步骤b、第三方基金公司根据所述用户登录信息查询所述用户的可用基金份额，生成基金查询结果发送给商户应用；所述基金查询结果中包含所述可用基金份额转换为的可赎金额；步骤c、商户应用接收所述基金查询结果，判断所述可赎金额是否小于所述缴费金额，若是，则商户应用向用户显示“基金余额不足，无法支付”信息，并结束本方法；否则，向用户显示收银台页面的同时，显示可赎金额。
  3. 根据权利要求1所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤10包括如下步骤：步骤A、系统调用第三方基金公司支付接口，生成并向第三方基金公司发送基金支付请求；所述基金支付请求中包含用户信息以及支付金额；步骤B、第三方基金公司接收所述基金支付请求后，根据所述用户信息，对用户基金可用份额等值于所述支付金额的份额进行代扣，并将支付结果返回给系统；步骤C、系统接收所述支付结果后，更新系统订单状态。
  4. 根据权利要求3所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤B中的代扣包括如下步骤：第三方基金公司根据所述用户信息以及所述支付金额，定位用户可用基金份额，将等值于支付金额的基金份 额进行赎回处理，并将所赎回的款项支付给服务商，同时将支付结果返回给系统。
  5. 根据权利要求3所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤11包括如下步骤：步骤1101、商户应用每间隔一定时间生成订单支付结果查询请求，并发送给系统；步骤1102、系统查询是否接收到第三方基金公司发来的订单支付结果，若是，则执行步骤1104；否则，执行步骤1103；步骤1103、系统向商户应用发送“查询失败”信息，并返回执行步骤1101；步骤1104、系统向商户应用发送所述订单支付结果，商户应用在接收所述订单支付结果后，更新商户订单状态，并向用户显示。
  6. 根据权利要求5所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤11之后还包括如下步骤：步骤1201、服务商每间隔一定时间生成支付订单查询请求，并发送给系统；步骤1202、系统查询是否接收到第三方基金公司发来的支付结果，若是，则执行步骤1204；否则，执行步骤1203；步骤1203、系统向服务商发送“查询失败”信息，并返回执行步骤1201；步骤1204、系统向服务商发送所述支付结果，并执行步骤1205；步骤1205、服务商判断所述支付结果是否成功，若支付成功，则执行步骤1206；否则，服务商将所述缴费订单状态修改为“待支付”，并通知用户；步骤1206、服务商向运营商进行缴费，接收缴费结果并更新所述缴费订单状态，将缴费结果发送给系统；步骤1207、系统接收所述缴费结果后更新所述系统订单状态为“已缴费”。
  7. 根据权利要求6所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤11中的商户应用更新缴费订单状态前，还包括如下步骤：步骤1301、商户应用每隔一定时间向系统轮询系统订单状态查询，并接收所述系统订单查询结果；步骤1302、判断所述系统订单查询结果是否为“已缴费”，若是，则商户应用更新商户订单状态，并结束本方法；否则，返回执行步骤1301。
  8. 根据权利要求1所述的一种基于份额转付的日常缴费方法，其特征在于，所述步骤8包括如下步骤：步骤i、商户应用向用户显示收银台页面，判断用户是否离开收银台页面，若是，则商户应用调用服务商订单详情查询接口，并向服务商查询订单详情，执行步骤ii；否则，执行步骤iii；步骤ii、接收服务商发送的所述订单详情并向用户显示订单详情页面，同时，在所述显示订单详情页面，设置支付选项，执行iii；步骤iii、判断用户是否点击所述支付选项，若是，则生成支付指令，执行步骤9；否则，商户应用向用户显示收银台页面并继续等待用户指令。
  9. 一种基于基金份额赎转付的日常缴费系统，其特征在于，所述系统包括数据提取模块、数据处理模块和通用模块；
    其中，所述数据提取模块，用于提取和/或获取文件以及请求中的数据，并根据所提取的数据，在其他文件中进行查询，并提取相应信息；所述数据提取模块包括：用于在文件以及信息中查询数据的查询模块；以及用于在文件以及请求中提取和/或获取数据以及信息的提取模块；
    所述数据处理模块，用于根据数据提取模块所提取出来的数据，进行数据筛选以及进行数据转换操作，生成请求以及报文通知，并用于对相应数据进行解析判断；所述数据处理模块包括：用于生成各请求、报文通知并进行状态更新的处理模块；以及用于进行数据解析及判断操作以及用于进行数据筛选操作的解析判断模块；
    所述通用模块，用于进行定时计时操作，调用第三方软件接口及页面，传送输出并接收数据、请求以及各报文通知；所述通用模块包括：用于进行所有定时、计时操作的定时器模块；以及用于调用第三方软件接口以及页面的调用模块；以及用于输出、传送系统数据、请求以及报文通知的输出模块；以及用于接收数据、报文通知、各请求的输入模块；以及用于存储本申请方法执行所需的所有文件、信息和数据的数据库。
  10. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质 上存储有用于执行基于基金份额赎转付的日常缴费方法的程序，所述程序被处理器执行时，执行以下步骤的操作：步骤1、商户应用接收用户登录信息，调用系统接口，并将商户渠道参数、用户登录信息发送给位于后台的系统；步骤2、系统接收所述商户渠道参数、用户登录信息，并提供服务选择页面供用户选择需要进行缴费的服务，根据用户选择的服务信息，调用服务商联合登录接口，并将所述用户登录信息以及服务信息发送给服务商；步骤3、服务商接收所述用户登录信息以及服务信息，并进行联合登录，向用户显示缴费账户输入窗口；步骤4、服务商接收用户输入的缴费账户信息，生成账单查询请求，并发送给运营商；步骤5、运营商生成并将账单查询结果发送给服务商，服务商判断所述账单查询结果是否为空，若是，则服务商向系统发送“无账单”信息，并由系统向用户发送“无账单”信息，同时结束本方法；否则，执行步骤6；步骤6、服务商向用户显示账单查询结果，接收并执行用户缴费指令，生成缴费订单，将所述缴费订单信息同步发送给系统，并调用系统收银台接口；所述缴费订单信息中包含有服务信息以及缴费金额；步骤7、系统生成系统订单，根据所述商户渠道参数，查询收银台路由表，获取商户收银台接口地址，并调用所述商户收银台接口，将所述缴费订单信息发送给商户应用；所述收银台路由表中包含有所有商户不同渠道参数所对应的收银台接口地址；步骤8、商户应用接收所述缴费订单信息，生成商户订单，并向用户显示收银台页面，供用户选择支付方式；步骤9、商户应用接收用户支付指令，显示支付密码输入界面，并对用户所输入的密码进行校验，若密码输入正确，则执行步骤10；否则，显示“密码输入错误”信息，重新执行步骤9；步骤10、商户应用向用户显示等待支付结果页面，同时调用系统赎转付支付接口，系统通过用户的可用基金支付所述缴费订单；步骤11、商户应用向系统轮询发送订单支付结果查询请求，在接收订单支付结果后，更新缴费订单状态，并向用户显示。
  11. 根据权利要求10所述的计算机可读存储介质，其特征在于，所述 步骤8向用户显示收银台页面同时，还包括如下步骤：步骤a、商户应用调用第三方基金公司基金份额查询接口，将基金份额查询请求发送给第三方基金公司；所述基金份额查询请求包含用户登录信息；步骤b、第三方基金公司根据所述用户登录信息查询所述用户的可用基金份额，生成基金查询结果发送给商户应用；所述基金查询结果中包含所述可用基金份额转换为的可赎金额；步骤c、商户应用接收所述基金查询结果，判断所述可赎金额是否小于所述缴费金额，若是，则商户应用向用户显示“基金余额不足，无法支付”信息，并结束本方法；否则，向用户显示收银台页面的同时，显示可赎金额。
  12. 根据权利要求10所述的计算机可读存储介质，其特征在于，所述步骤10包括如下步骤：步骤A、系统调用第三方基金公司支付接口，生成并向第三方基金公司发送基金支付请求；所述基金支付请求中包含用户信息以及支付金额；步骤B、第三方基金公司接收所述基金支付请求后，根据所述用户信息，对用户基金可用份额等值于所述支付金额的份额进行代扣，并将支付结果返回给系统；步骤C、系统接收所述支付结果后，更新系统订单状态。
  13. 根据权利要求12所述的计算机可读存储介质，其特征在于，所述步骤B中的代扣包括如下步骤：第三方基金公司根据所述用户信息以及所述支付金额，定位用户可用基金份额，将等值于支付金额的基金份额进行赎回处理，并将所赎回的款项支付给服务商，同时将支付结果返回给系统。
  14. 根据权利要求12所述的计算机可读存储介质，其特征在于，所述步骤11包括如下步骤：步骤1101、商户应用每间隔一定时间生成订单支付结果查询请求，并发送给系统；步骤1102、系统查询是否接收到第三方基金公司发来的订单支付结果，若是，则执行步骤1104；否则，执行步骤1103；步骤1103、系统向商户应用发送“查询失败”信息，并返回执行步骤1101；步骤1104、系统向商户应用发送所述订单支付结果，商户应用在接收所述订单支付结果后，更新商户订单状态，并向用户显示。
  15. 根据权利要求14所述的计算机可读存储介质，其特征在于，所述步骤11之后还包括如下步骤：步骤1201、服务商每间隔一定时间生成支付订单查询请求，并发送给系统；步骤1202、系统查询是否接收到第三方基金公司发来的支付结果，若是，则执行步骤1204；否则，执行步骤1203；步骤1203、系统向服务商发送“查询失败”信息，并返回执行步骤1201；步骤1204、系统向服务商发送所述支付结果，并执行步骤1205；步骤1205、服务商判断所述支付结果是否成功，若支付成功，则执行步骤1206；否则，服务商将所述缴费订单状态修改为“待支付”，并通知用户；步骤1206、服务商向运营商进行缴费，接收缴费结果并更新所述缴费订单状态，将缴费结果发送给系统；步骤1207、系统接收所述缴费结果后更新所述系统订单状态为“已缴费”。
  16. 根据权利要求15所述的计算机可读存储介质，其特征在于，所述步骤11中的商户应用更新缴费订单状态前，还包括如下步骤：步骤1301、商户应用每隔一定时间向系统轮询系统订单状态查询，并接收所述系统订单查询结果；步骤1302、判断所述系统订单查询结果是否为“已缴费”，若是，则商户应用更新商户订单状态，并结束本方法；否则，返回执行步骤1301。
  17. 根据权利要求10所述的计算机可读存储介质，其特征在于，所述步骤8包括如下步骤：步骤i、商户应用向用户显示收银台页面，判断用户是否离开收银台页面，若是，则商户应用调用服务商订单详情查询接口，并向服务商查询订单详情，执行步骤ii；否则，执行步骤iii；步骤ii、接收服务商发送的所述订单详情并向用户显示订单详情页面，同时，在所述显示订单详情页面，设置支付选项，执行iii；步骤iii、判断用户是否点击所述支付选项，若是，则生成支付指令，执行步骤9；否则，商户应用向用户显示收银台页面并继续等待用户指令。
PCT/CN2018/095734 2018-04-10 2018-07-16 一种基于基金份额赎转付的日常缴费方法及系统 Ceased WO2019196231A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810316253.8A CN108573374B (zh) 2018-04-10 2018-04-10 一种基于基金份额赎转付的日常缴费方法及系统
CN201810316253.8 2018-04-10

Publications (1)

Publication Number Publication Date
WO2019196231A1 true WO2019196231A1 (zh) 2019-10-17

Family

ID=63574219

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/095734 Ceased WO2019196231A1 (zh) 2018-04-10 2018-07-16 一种基于基金份额赎转付的日常缴费方法及系统

Country Status (2)

Country Link
CN (1) CN108573374B (zh)
WO (1) WO2019196231A1 (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110874800A (zh) * 2019-11-08 2020-03-10 腾讯科技（深圳）有限公司 数据转移方法、装置、电子设备及计算机可读存储介质
CN112215589A (zh) * 2020-10-12 2021-01-12 中国民航信息网络股份有限公司 一种支付跳转控制方法、装置和电子设备
CN112258173A (zh) * 2020-10-22 2021-01-22 广州市汇聚支付电子科技有限公司 一种智能支付路由方法及系统
CN112308549A (zh) * 2020-10-23 2021-02-02 浪潮金融信息技术有限公司 一种对接银行支付后台的系统
CN113222583A (zh) * 2021-06-04 2021-08-06 北京树米网络科技有限公司 一种与物联网设备相关的个人账户管理方法
CN114399846A (zh) * 2021-11-30 2022-04-26 深圳市顺易通信息科技有限公司 一种停车费的支付方法、支付装置及储存介质
CN114612236A (zh) * 2022-03-10 2022-06-10 中国建设银行股份有限公司 一种定期赎回的处理方法及装置
CN114971605A (zh) * 2022-04-26 2022-08-30 平安国际融资租赁有限公司 一种线下支付的验证处理方法、装置、计算机设备及介质
CN115049454A (zh) * 2022-06-09 2022-09-13 中国工商银行股份有限公司 供需关系的匹配方法、装置及电子设备
CN117333177A (zh) * 2023-09-25 2024-01-02 艾体威尔电子技术(北京)有限公司 一种社保费用自助缴纳方法、系统、电子设备及介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109961279A (zh) * 2019-03-18 2019-07-02 厦门市易联众易惠科技有限公司 一种基于多策略的his支付状态获取方法及设备
CN112990901A (zh) * 2019-12-13 2021-06-18 腾讯科技（深圳）有限公司 支付处理方法、装置、终端、服务器及存储介质
TWI782888B (zh) * 2020-04-15 2022-11-01 華南商業銀行股份有限公司 基於圖面的資金贖回系統及其方法
TWI782889B (zh) * 2020-04-15 2022-11-01 華南商業銀行股份有限公司 依據支付期限執行資金贖回的資金贖回系統及其方法
TWI772779B (zh) * 2020-04-15 2022-08-01 華南商業銀行股份有限公司 資金贖回系統及其方法
CN111833058B (zh) * 2020-07-01 2024-10-22 中国建设银行股份有限公司 一种缴费管理方法和装置
CN112927102A (zh) * 2021-03-31 2021-06-08 中国建设银行股份有限公司 服务提供系统、方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101340452A (zh) * 2008-05-27 2009-01-07 北京爱奥时代信息科技有限公司 手机交费方法及系统
JP2011141853A (ja) * 2010-01-11 2011-07-21 Girunetto Kk 携帯端末を用いたオフライン取引の決済方法、プログラム、決済用近距離無線通信機器。
KR20120044330A (ko) * 2012-04-12 2012-05-07 주식회사 비즈모델라인 무선 거래 승인 방법
CN103164792A (zh) * 2011-12-14 2013-06-19 阿里巴巴集团控股有限公司 无线终端上的支付服务提供方法及相关设备和系统
CN106960334A (zh) * 2017-03-20 2017-07-18 泰华智慧产业集团股份有限公司 基于实名认证的公共事务账单关联方法及系统
CN107194683A (zh) * 2016-03-14 2017-09-22 阿里巴巴集团控股有限公司 在线支付方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102592367B (zh) * 2011-01-18 2015-02-04 中国联合网络通信集团有限公司 电信业务缴费处理方法、设备和系统
CN102968715B (zh) * 2012-11-02 2017-06-13 汇付天下有限公司 一种基于信用数据的支付控制方法和系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101340452A (zh) * 2008-05-27 2009-01-07 北京爱奥时代信息科技有限公司 手机交费方法及系统
JP2011141853A (ja) * 2010-01-11 2011-07-21 Girunetto Kk 携帯端末を用いたオフライン取引の決済方法、プログラム、決済用近距離無線通信機器。
CN103164792A (zh) * 2011-12-14 2013-06-19 阿里巴巴集团控股有限公司 无线终端上的支付服务提供方法及相关设备和系统
KR20120044330A (ko) * 2012-04-12 2012-05-07 주식회사 비즈모델라인 무선 거래 승인 방법
CN107194683A (zh) * 2016-03-14 2017-09-22 阿里巴巴集团控股有限公司 在线支付方法和装置
CN106960334A (zh) * 2017-03-20 2017-07-18 泰华智慧产业集团股份有限公司 基于实名认证的公共事务账单关联方法及系统

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110874800B (zh) * 2019-11-08 2023-10-20 腾讯科技（深圳）有限公司 数据转移方法、装置、电子设备及计算机可读存储介质
CN110874800A (zh) * 2019-11-08 2020-03-10 腾讯科技（深圳）有限公司 数据转移方法、装置、电子设备及计算机可读存储介质
CN112215589A (zh) * 2020-10-12 2021-01-12 中国民航信息网络股份有限公司 一种支付跳转控制方法、装置和电子设备
CN112258173A (zh) * 2020-10-22 2021-01-22 广州市汇聚支付电子科技有限公司 一种智能支付路由方法及系统
CN112308549A (zh) * 2020-10-23 2021-02-02 浪潮金融信息技术有限公司 一种对接银行支付后台的系统
CN112308549B (zh) * 2020-10-23 2024-06-07 浪潮金融信息技术有限公司 一种对接银行支付后台的系统
CN113222583A (zh) * 2021-06-04 2021-08-06 北京树米网络科技有限公司 一种与物联网设备相关的个人账户管理方法
CN113222583B (zh) * 2021-06-04 2024-03-08 广东树米科技有限公司 一种与物联网设备相关的个人账户管理方法
CN114399846A (zh) * 2021-11-30 2022-04-26 深圳市顺易通信息科技有限公司 一种停车费的支付方法、支付装置及储存介质
CN114612236A (zh) * 2022-03-10 2022-06-10 中国建设银行股份有限公司 一种定期赎回的处理方法及装置
CN114971605A (zh) * 2022-04-26 2022-08-30 平安国际融资租赁有限公司 一种线下支付的验证处理方法、装置、计算机设备及介质
CN115049454A (zh) * 2022-06-09 2022-09-13 中国工商银行股份有限公司 供需关系的匹配方法、装置及电子设备
CN117333177A (zh) * 2023-09-25 2024-01-02 艾体威尔电子技术(北京)有限公司 一种社保费用自助缴纳方法、系统、电子设备及介质

Also Published As

Publication number Publication date
CN108573374B (zh) 2023-03-31
CN108573374A (zh) 2018-09-25

Similar Documents

Publication Publication Date Title
WO2019196231A1 (zh) 一种基于基金份额赎转付的日常缴费方法及系统
US11238542B1 (en) Online interactive notification platform for exploring possible tax nexus and implications
CN108520461B (zh) 一种基于基金份额赎转付的信用卡还款方法及系统
US11423375B2 (en) Systems and methods for bill payment using transaction cards within a financial institution payment platform
US8738518B2 (en) Methods and systems for executing a plurality of money transfers having a fluctuating parameter
US8612348B1 (en) Systems and methods for interfacing merchants with third-party service providers
US20160335624A1 (en) Mobile device nfc-based detection and merchant payment system
KR20130135890A (ko) 지연 지불 및 선택적 펀딩 및 지불
CN108352020A (zh) 用于产品识别和计算机路由服务的方法和系统
WO2019205218A1 (zh) 贷款自动还款方法、系统、设备及存储介质
CN108520408B (zh) 一种基于基金份额赎转付日常缴费的自动代扣方法及系统
KR101729162B1 (ko) 금융 오픈 플랫폼 기반의 선불결제 관리 장치, 방법 및 컴퓨터 프로그램
CN113298512A (zh) 资金数据信息处理方法、装置及电子设备
US20220058600A1 (en) Systems and methods for virtual currency exchange
US12197950B2 (en) Cluster job submission
JP2018014106A (ja) 取引記録との関連付けのための取引額の識別
CN114358901A (zh) 临床试验项目账单数据处理方法、装置、设备和存储介质
US10915876B2 (en) Application program interface for conversion of stored value cards
JP6271063B1 (ja) 資金移動システム、資金移動システムによって実行される方法およびプログラム
CN111915285B (zh) 现金提取方法、装置和电子设备
WO2012127478A1 (en) System and method for rule-based presentment and payment of bills or invoices
US10217087B2 (en) Multicomputer processing of client device request data using centralized event orchestrator
JP2023033054A (ja) プログラム、システムおよび方法
EP4488909A1 (en) Electronic money service system and electronic money settlement method
US20250069050A1 (en) Systems and methods for an electronic transfer directory service for distillation or distribution of files

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18914090

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22/01/2021)

122 Ep: pct application non-entry in european phase

Ref document number: 18914090

Country of ref document: EP

Kind code of ref document: A1