A payment method, device and system

Abstract

The present disclosure provides a payment method that can be used in the fields of financial technology and other fields, including: sending the registration information of a non-financial user to a financial client, so that the financial client generates authentication information for the registration information, and the authentication information is stored in a bank server; sending a payment request to a bank server, so that the bank server performs payment processing according to the payment request and the authentication information. The present disclosure reduces the financial security risks in the enterprise payment process from a system level by splitting and re-authorizing the existing online account movement permissions of enterprises. The present disclosure also provides a payment device and system, an electronic device, and a computer-readable storage medium.

Description

Technical Field

[0001] The present disclosure relates to the field of financial technology, and in particular to a payment method, device and system. Background Art

[0002] Under the original technical background, since corporate online payments require the company's U-Shield holder (usually the company's finance department) to insert the shield and verify the signature, as corporate operations and procurement transform online, the payment method under the limitations of the original technology has created obstacles for corporate online procurement, especially for large and medium-sized enterprises with sound financial systems. Procurement agents face payment process interruptions or employee advance payments when making online payments. Some companies hand over U-Shields to procurement agents for use, which is prone to public account fund security risks. Summary of the invention

[0003] 1. Technical issues to be resolved

[0004] In response to the above problems, the present disclosure provides a payment method, device and system for at least partially solving technical problems such as the proneness of payment process interruption and high fund security risk in traditional payment methods.

[0005] (II) Technical solution

[0006] On the one hand, the present disclosure provides a payment method, including: sending registration information of a non-financial user to a financial client, so that the financial client generates authentication information for the registration information, and the authentication information is stored in a bank server; sending a payment request to the bank server, so that the bank server performs payment processing according to the payment request and the authentication information.

[0007] Furthermore, sending a payment request to a bank server includes: retrieving a payment voucher, which is a voucher used by a bank for payment settlement; and sending a payment request to a bank server, which includes the payment voucher and transaction information, so that the bank server can process the payment.

[0008] Furthermore, sending the registration information of the non-financial user to the financial client includes: submitting the registration information to a bank server so that the bank server performs identity recognition on the registration information; after the recognition is successful, the bank server sends the registration information to the financial client.

[0009] Another aspect of the present disclosure provides a payment method, including: obtaining registration information sent by a non-financial client, generating authentication information for the registration information, and storing the authentication information in a bank server; and performing payment processing when the bank server receives a payment request from a non-financial user based on the authentication information.

[0010] Furthermore, obtaining the registration information sent by the non-financial client includes: obtaining the registration information sent by the non-financial client, performing authentication, and binding the relationship with the non-financial user.

[0011] Furthermore, after obtaining the registration information sent by the non-financial client, the method further includes: issuing payment authority to the non-financial user or approving the payment authority applied for by the non-financial user.

[0012] Another aspect of the present disclosure provides a payment method, including: storing authentication information, where the authentication information is generated by a financial client based on registration information sent by a non-financial client; obtaining a payment request sent by a non-financial user, and performing payment processing based on the payment request and the authentication information.

[0013] Furthermore, storing the authentication information includes: obtaining registration information sent by a non-financial client and performing identity recognition on the registration information; sending the registration information to a financial client, and the financial client generating authentication information for the registration information; obtaining and storing the authentication information.

[0014] Furthermore, obtaining the payment request sent by the non-financial user includes: obtaining the payment request sent by the non-financial client and verifying the identity information of the non-financial user; obtaining payment credential information and transaction information and verifying the payment authority of the non-financial user.

[0015] Furthermore, payment processing based on the payment request and authentication information includes: deducting funds based on the payment request and authentication information, and remitting the funds to a designated account based on the payment request.

[0016] In another aspect, the present disclosure provides a payment device, including: a non-financial client, used to send registration information of a non-financial user to a financial client, so that the financial client generates authentication information for the registration information, and the authentication information is stored in a bank server; send a payment request to a bank server, so that the bank server performs payment processing according to the payment request and the authentication information; the financial client, used to obtain the registration information sent by the non-financial client; the bank server, used to store the authentication information; and used to obtain the payment request sent by the non-financial user and perform payment processing.

[0017] In another aspect, the present disclosure provides a payment system, including: a user management module, used to receive registration information of a non-financial user and send it to a financial client, so that the financial client generates authentication information for the registration information; a payment authorization module, used for the non-financial user to apply for payment authority, and used for the financial client to issue payment authority to the non-financial user; a payment authentication module, used to verify the identity information and payment authority of the non-financial user; a transaction receiving module, used to identify transaction information; and an account processing module, used to deduct funds according to the payment request and the authentication information, and remit the funds to a designated account according to the payment request.

[0018] Another aspect of the present disclosure provides an electronic device, including: a processor; a memory storing a computer executable program, which, when executed by the processor, enables the processor to execute the aforementioned payment method.

[0019] Another aspect of the present disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the program implements the aforementioned payment method when executed by a processor.

[0020] (III) Beneficial effects

[0021] A payment method, device and system provided by the embodiments of the present disclosure, on the one hand, splits and re-authorizes the existing online account movement permissions, so that non-financial users of the enterprise can directly use the funds in the enterprise settlement account to complete payment when conducting online transactions and purchases, thereby solving the problem of long clearing paths in traditional payment methods for non-financial users and effectively improving payment efficiency; on the other hand, by allowing non-financial users to register with real names, bind them to the enterprise relationship, and then use payment authorization, the fund security risks in the enterprise payment process are controlled from the system level, thereby improving the security of the payment settlement business process. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 The exemplary system architecture of the payment method according to the embodiment of the present disclosure is schematically shown;

[0023] Figure 2 The flowchart of the payment method according to the embodiment of the present disclosure is schematically shown;

[0024] Figure 3 The diagram schematically shows the interaction process between the client and the bank server according to the embodiment of the present disclosure;

[0025] Figure 4 A flowchart of a payment method according to another embodiment of the present disclosure is schematically shown;

[0026] Figure 5 A flowchart of a payment method according to another embodiment of the present disclosure is schematically shown;

[0027] Figure 6 Schematically shows a flow chart of a bank server making payment according to a payment request according to an embodiment of the present disclosure;

[0028] Figure 7 The structure block diagram of each module in the enterprise payment system according to the embodiment of the present disclosure is schematically shown;

[0029] Figure 8 The unit structure diagram of the user management module according to the embodiment of the present disclosure is schematically shown;

[0030] Fig. 9 The unit structure diagram of the payment authorization module according to the embodiment of the present disclosure is schematically shown;

[0031] Fig.10 The unit structure diagram of the payment authentication module according to the embodiment of the present disclosure is schematically shown;

[0032] Fig.11 The unit structure diagram of the transaction receiving module according to the embodiment of the present disclosure is schematically shown;

[0033] Fig.12 The unit structure diagram of the account processing module according to the embodiment of the present disclosure is schematically shown;

[0034] Fig.13 A complete flow chart of the enterprise online payment processing method according to an embodiment of the present disclosure is schematically shown;

[0035] Fig.14 The block diagram of a computer system according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0036] In order to make the objectives, technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0037] The embodiments of the present disclosure provide an enterprise online payment processing method and system. By binding the relationship between users and enterprises, the enterprise finance sets payment permissions for users, and provides an online enterprise payment solution for systematic management, complete authorization, and secure payment of all employees of the enterprise. It effectively solves the pain points of offline transmission of original vouchers by procurement agents and finance, advance payment by agents, long payment process, and insecure account funds, and controls the fund security risks existing in the enterprise payment process from a system level.

[0038] Figure 1 The exemplary system architecture 100 of the payment method according to the embodiment of the present disclosure is schematically shown. It should be noted that: Figure 1 What is shown is merely an example of a system architecture to which the embodiments of the present disclosure can be applied, in order to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiments of the present disclosure cannot be used in other devices, systems, environments or scenarios.

[0039] like Figure 1 As shown, the system architecture 100 according to this embodiment may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0040] Users can use terminal devices 101, 102, 103 to interact with server 105 through network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only examples).

[0041] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0042] The server 105 may be a server that provides various services, such as a background management server (only an example) that provides support for websites browsed by users using the terminal devices 101, 102, and 103. The background management server may analyze and process the received data such as user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.

[0043] It should be noted that the payment method provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the system for payment provided in the embodiment of the present disclosure can generally be set in the server 105. The payment method provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the system for payment provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105.

[0044] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to the implementation requirements.

[0045] Figure 2 The flowchart of the payment method according to the embodiment of the present disclosure is schematically shown.

[0046] S11, sending the registration information of the non-financial user to the financial client, so that the financial client generates authentication information for the registration information, and the authentication information is stored in the bank server.

[0047] In step S11, those who directly use the enterprise account funds for online payment within the enterprise are usually financial personnel, and the non-financial users here are non-financial personnel with payment needs within the enterprise, such as purchasing agents. The traditional procurement process of purchasing agents includes application, advance payment by agents, transmission of original vouchers, review, financial payment and other processes, which takes a long time; some companies hand over U-shields to purchasing agents, which is prone to public account fund security risks. Based on this, the present disclosure proposes a method for splitting and re-authorizing the existing enterprise online account movement permissions, so that non-financial personnel with payment needs also enjoy partial payment permissions, and can directly use the enterprise settlement account funds to complete payment when conducting online transactions and purchases.

[0048] First, the enterprise needs to register on the bank payment client to obtain the enterprise's unique ID or the unique U-Shield ID after applying for U-Shield; secondly, non-financial users also need to register on the corresponding bank client and perform real-name authentication, and then associate with the enterprise through the enterprise ID, U-Shield ID or the basic positioning of the enterprise, and submit the application information. After receiving the application information, the client sends the information to the corporate finance client for authentication. After the corporate finance confirms and completes the binding of the non-financial user and the enterprise relationship. Corporate finance can further issue payment permissions to users, or approve payment permissions applied for by non-financial users. Here, payment permissions include not only the payment amount, but also information such as validity period and payment scope, and the user obtains the corresponding payment permissions.

[0049] S12, sending a payment request to the bank server, so that the bank server performs payment processing according to the payment request and authentication information.

[0050] Non-financial users can log in to the bank payment client to check the payment authority they enjoy. When logging in, the client will compare the login information with the registration information for login authentication. Non-financial users can submit payment applications to the bank payment system through bank transfer, QR code payment, or payment by presenting a payment code within their payment authority. The system determines whether the payment application information matches the pre-set non-financial user payment authority scope and performs payment authentication; if they match, payment transfer is performed and the payment authority scope information is updated to complete the entire payment process. For the interactive process diagram between the client and the bank server, please refer to Figure 3 The disclosed method solves the problem of payment process interruption or employee advance payment faced by procurement agents when making online payments, and reduces the security risk of public account funds.

[0051] Based on the above embodiment, sending a payment request to a bank server includes: retrieving a payment voucher, which is a voucher used by the bank for payment settlement; sending a payment request to the bank server, which includes the payment voucher and transaction information, so that the bank server can process the payment.

[0052] The payment voucher here is the voucher used by the bank for payment settlement, and has the function of settlement. Non-financial users can use the payment voucher to directly use the funds in the enterprise settlement account to complete the payment, solving the payment problem of the traditional method with complicated approval process and long application cycle. The bank server can deduct and enter the funds based on the payment voucher and transaction information.

[0053] Based on the above embodiment, sending the registration information of the non-financial user to the financial client includes: submitting the registration information to the bank server so that the bank server can perform identity recognition on the registration information; after the recognition is successful, the bank server sends the registration information to the financial client.

[0054] The process of registration and real-name authentication for non-financial users includes: the user enters the client, the client establishes a connection with the server, opens the socket file, and the connection is successfully established. The client submits a registration request to the server through the socket, submitting personal information such as mobile phone number, name, certificate type, certificate number, and validity period. After the client submits the request, it is transmitted to the server through the HTTP protocol. The server performs transaction processing and transmits the processing results back to the client. The non-financial user fills in the information and sends it back to the client. The server calls the public security network to verify and authenticate the customer's real-name information. After the authentication is passed, the client writes the information into the database and the registration is successful.

[0055] After the non-financial user successfully registers, the bank server will send the registration information to the financial client. The corporate financial personnel can log in to the dedicated client, view the registered personnel information through the server, and operate and bind the user and corporate information.

[0056] Figure 4 The flowchart of a payment method according to another embodiment of the present disclosure is schematically shown.

[0057] S21, obtaining registration information sent by the non-financial client, generating authentication information for the registration information, and storing the authentication information in the bank server; S22, based on the authentication information, the bank server performs payment processing when receiving a payment request from the non-financial user.

[0058] Financial personnel log in to the dedicated client, view the registered personnel information through the server, operate and bind the user and enterprise information. After receiving the real-name registration sent by the non-financial user, register the relevant identity authentication and management entities, record the user's identity details, and send the real-name user's enterprise authentication application information to the enterprise for authentication. After the authentication is passed, the real-name user and the enterprise are bound and stored in the bank server, providing an identity security authentication basis for subsequent authorization and authentication modules to process transactions.

[0059] Based on the above embodiment, obtaining the registration information sent by the non-financial client includes: obtaining the registration information sent by the non-financial client, performing authentication, and binding the relationship with the non-financial user.

[0060] The financial personnel log in to the client, receive the user transaction application sent by the server, and apply for access to the user's identity and other related information. After the server sends the information to the financial personnel's client, the financial personnel then decides whether to bind the relationship with the non-financial user and sends the feedback information back to the server. The server then sends the feedback information to the non-financial user's client.

[0061] On the basis of the above embodiment, after obtaining the registration information sent by the non-financial client, the method further includes: issuing payment authority to the non-financial user or approving the payment authority applied for by the non-financial user.

[0062] Here, the payment authority can be set with different payment authority ranges according to the different job roles of non-financial users. For example, the payment amount authority can be set according to the payment amounts involved in different positions. Raw material procurement is mainly large-amount payments, and its payment amount authority is correspondingly larger, while administrative procurement is mainly small-amount payments, and its payment amount authority is correspondingly smaller. The payment object range can also be set for non-financial users. For example, the payment object of raw material procurement is the raw material supplier, and the payment object of administrative procurement is Taobao, JD.com and other shopping websites. The payment validity period can also be set for non-financial users. For example, it can be a temporary one-month effective payment period or a long-term one-year effective payment period. If the effective payment period is exceeded, the system will automatically recognize and terminate the transaction, and the payment cannot be completed.

[0063] It should be noted that here, it can be that the finance department issues payment authority to non-financial users, or that non-financial users apply for payment authority online and the finance department approves it. Based on role authorization and authority setting, corporate finance proactively issues payment authority to the agent by specifying authorized persons, setting payee ranges, and defining payment amount ranges and other payment information; or non-financial users apply for payment authority online by reporting payment amounts, payees and other information, providing a basis for authority judgment for subsequent agent roles to use payment vouchers for payment. Corporate finance approves the payment authority applied for by the agent user, and after approval, the user can proceed with the payment process under this payment authority. When the agent user makes a payment, the system will compare the payment application information with the authority set by corporate finance. If the comparison is successful, the payment process will be entered, otherwise the payment will be terminated.

[0064] On the basis of the above embodiment, obtaining the registration information sent by the non-financial client includes: modifying, maintaining, terminating the payment authority of the non-financial user, and performing dynamic management.

[0065] After receiving the payment authority information issued by the corporate finance, the payment authority is modified, maintained, terminated and abolished throughout its life cycle based on the existing information. The corporate finance can adjust the payment authority amount, payment object scope, payment validity period and other information according to the changes in the user's job role, and terminate and abolish the payment authority at any time. That is, after issuing part of the payment authority to the company's procurement manager in advance, the procurement manager can directly use the company's settlement account funds for payment. The corporate finance mainly performs corresponding management and maintenance work on the decentralization of payment authority.

[0066] Figure 5 The flowchart of a payment method according to another embodiment of the present disclosure is schematically shown.

[0067] S31, storing authentication information, where the authentication information is generated by the financial client based on the registration information sent by the non-financial client.

[0068] The bank server receives the registration information of the non-financial user, and after the financial client passes the authentication, it stores the authentication information sent by the financial client to provide a basis for authority judgment for the subsequent payment process.

[0069] S32, obtaining a payment request sent by a non-financial user, and performing payment processing according to the payment request and authentication information.

[0070] After receiving the payment request from the non-financial user, the bank server verifies whether the payment request complies with the pre-set authority. If so, the funds are deducted and remitted; if not, the transaction is terminated.

[0071] Based on the above embodiment, storing authentication information includes: obtaining registration information sent by a non-financial client and performing identity recognition on the registration information; sending the registration information to a financial client, and the financial client generating authentication information for the registration information; obtaining and storing the authentication information.

[0072] Non-financial users send registration information to the bank server, which processes the transaction and transmits the processing results back to the client. The user fills in the information and sends it back to the client. The server calls the public security network to verify and authenticate the customer's real-name information. After the authentication is passed, the client writes the information into the database and the registration is successful. The server then sends the registration information to the financial client. The corporate financial staff logs in to the dedicated client, views the registered personnel information through the server, operates and binds the user and corporate information, and sends the authentication information to the bank server, which stores the authentication information.

[0073] Based on the above embodiment, obtaining the payment request sent by the non-financial user includes: obtaining the payment request sent by the non-financial client and verifying the identity information of the non-financial user; obtaining payment credential information and transaction information and verifying the payment authority of the non-financial user.

[0074] Obtain payment from non-financial users, authenticate the user's payment, and determine whether the payment request matches the user's payment authority; if so, deduct funds and credit the merchant to complete the online payment; otherwise, terminate the transaction, see Figure 6 . Specifically, a non-financial user sends a payment request to the server through the client, the server receives and identifies the transaction instruction, compares the user's authority with the set authority, and returns the feedback result to the client to perform payment authentication. It should be noted that payment authentication for users specifically includes: when the user logs in, confirm whether the user's login information is consistent with the registration information; when the user submits a payment application, confirm whether the user's payment application information is consistent with the payment authority. That is, payment authentication includes login authentication and payment authentication. Login authentication includes when the agent or financial logs in to the client, the information is transmitted to the server and compared with the registration information in the database, and the comparison result (correct or wrong) is returned to the client; payment authentication includes the agent user sending the application to the server through the client, the server compares the user's authority with the set authority, and returns the feedback result to the client.

[0075] Based on the above embodiment, payment processing according to the payment request and the authentication information includes: deducting funds according to the payment request and the authentication information, and remitting the funds to a designated account according to the payment request.

[0076] If the conditions are met, the transaction details are recorded, funds are deducted, and the funds processing information is transmitted back to the server. After the client receives the information of the funds deduction unit, it sends a remittance instruction to the server for funds transmission and completes the online payment; if the payment conditions are not met, the transaction is terminated and the payment failure information is returned. Here, the funds deduction and merchant account entry specifically include: after the transaction processing is completed, the funds in the corporate account are deducted, and the funds are remitted to the merchant account specified in the transaction instruction according to the payment plan. That is, after the client receives the transaction processing unit instruction, the funds are deducted and the funds processing information is transmitted back to the server; after the client receives the transaction processing unit instruction transmitted by the server and receives the information of the funds deduction unit, it sends a remittance instruction to the server for funds transmission.

[0077] Obtaining the payment request sent by the non-financial user also includes obtaining the transaction instruction: identifying the transaction instruction, and processing the transaction instruction that meets the conditions; wherein the transaction processing includes recording the transaction details, identifying and formulating the payment plan. The server receives the transaction instruction transmitted by the platform partner and retains the instruction and transmits it to the transaction processing unit. After receiving the transaction identification instruction, the transaction processing unit records the transaction details in the server, identifies and formulates the payment plan, and sends it to the client.

[0078] Another embodiment of the present disclosure provides a payment device, including: a non-financial client, used to send registration information of a non-financial user to a financial client, so that the financial client generates authentication information for the registration information, and the authentication information is stored in a bank server; send a payment request to a bank server, so that the bank server performs payment processing according to the payment request and the authentication information; the financial client, used to obtain the registration information sent by the non-financial client; the bank server, used to store the authentication information; and used to obtain the payment request sent by the non-financial user and perform payment processing.

[0079] For a diagram of the interaction process between the client and the bank server, see Figure 3 The detailed process has been explained in the payment method and will not be repeated here.

[0080] Another embodiment of the present disclosure provides a payment system. Figure 7 , including: a user management module 1, used to receive registration information of non-financial users and send it to a financial client so that the financial client generates authentication information for the registration information; a payment authorization module 2, used for non-financial users to apply for payment authority, and for the financial client to issue payment authority to non-financial users; a payment authentication module 3, used to verify the identity information and payment authority of non-financial users; a transaction receiving module 4, used to identify transaction information; an account processing module 5, used to deduct funds according to payment requests and authentication information, and remit funds to a designated account according to payment requests.

[0081] Figure 7 In order to schematically illustrate the structural block diagram of each module in the payment system, this disclosure adopts a new type of enterprise online payment user, authorization, and authentication model. Before the online purchase transaction occurs, the user and the enterprise relationship are bound through the development of a real-name registration mechanism; and the user role and authority settings are fully in line with the enterprise's business and authorization management rules; when online purchases occur, the purchasing agent can use the payment limit pre-approved by the finance department to complete the payment, and can also conveniently complete the payment authentication through face & fingerprint + static password and other methods.

[0082] The user management module 1 is used to receive the registration information of non-financial users and send it to the financial client so that the financial client can generate authentication information for the registration information. The user management module 1 is composed of a user registration unit 11, an enterprise authentication unit 12 and a role authorization unit 13. Figure 8 .

[0083] 1) User Registration Unit 11

[0084] The main function of the user registration unit 11 is to receive user registration and real-name authentication, establish the foundation of the enterprise mobile payment user identity recognition and authentication system, store user registration information, and transmit the user information after real-name authentication to the enterprise authentication unit 12 for further processing.

[0085] 2) Enterprise Certification Unit 12

[0086] The main function of the enterprise authentication unit 12 is to register relevant identity authentication and management entities, record user identity details, and send the real-name user's enterprise authentication application information to the enterprise for authentication after receiving the user real-name registration sent by the user registration unit 11. After the authentication is passed, the real-name user is bound to the enterprise, providing an identity security authentication basis for subsequent authorization and authentication modules to perform transaction processing.

[0087] 3) Role authorization unit 13

[0088] The main function of the role authorization unit 13 is to set role permissions for the real-name user after receiving the real-name user and enterprise binding authentication from the enterprise authentication unit 12, so as to provide a basis for subsequent payment and transaction authentication.

[0089] Payment authorization module 2 is used by non-financial users to apply for payment permissions, and is used by the financial client to issue payment permissions to non-financial users; users apply for payment permissions online, which includes payee information and payment amount information, and provides permission judgment basis for corporate finance to set payment permissions for users; corporate finance sets payment information for users, which includes payee range and payment amount range, and issues payment permissions. Payment authorization module 2 consists of financial authorization unit 21, application handling unit 22 and permission management unit 23, please refer to Fig. 9 .

[0090] 1) Financial Authorization Unit 21

[0091] The main function of the financial authorization unit 21 is to issue payment authority to the agent by the user with financial management authority on the basis of the role and authority setting of the role management unit 13, by actively specifying the authorized person, setting the payee range, and defining the payment amount range and other payment information. Or approve the payment authority applied for by the agent user, and provide the authority judgment basis for the subsequent agent role to use the payment voucher for payment.

[0092] 2) Application processing unit 22

[0093] The main function of the application unit 22 is to enable the authorized user to apply for payment authority online by reporting the payment amount, payee and other information based on the role and authority settings of the role management unit 13, so as to provide authority judgment basis for subsequent authorized roles to use payment vouchers for payment.

[0094] 3) Rights Management Unit 23

[0095] The main function of the authority management unit 23 is to send the final feedback information of the financial authorization unit to the financial personnel client for modification after receiving the payment voucher authority information issued by the financial authorization unit 21, and to perform full life cycle management of modification, maintenance and termination of payment authority based on the existing information.

[0096] The payment authentication module 3 is used to verify the identity information and payment authority of non-financial users. When a user logs in, it is used to confirm whether the user's login information is consistent with the registration information; when a user submits a payment application, it is used to confirm whether the user's payment application information is consistent with the payment authority.

[0097] The payment authentication module 3 is composed of a login authentication unit 31 and a payment authentication unit 32. Fig.10 .

[0098] 1) Login authentication unit 31

[0099] The main function of the login authentication unit 31 is to identify and authenticate the identity of the financial management authority role or the handling authority role when logging in, and use the user identity data of the user registration unit to log in to the system to perform relevant operations.

[0100] 2) Payment authentication unit 32

[0101] The main function of the payment authentication unit 32 is to enable the authorized user to make payment using the payment voucher within the scope of authority based on the role authorization unit 13. The unit verifies whether the user's identity and payment application are in compliance with the authority scope preset by the enterprise.

[0102] The purchasing agent can use the payment amount pre-approved by the finance department to complete the payment, and conveniently complete the payment authentication through face & fingerprint + static password, etc., and use the corresponding payment authentication method to complete the payment authentication according to the actual payment amount, see Table 1:

[0103]

[0104]

[0105] Table 1

[0106] The transaction receiving module 4 is used to identify transaction information, including identifying transaction instructions, and to process the transaction instructions that meet the conditions; wherein the transaction processing includes recording transaction details, identifying and formulating a payment plan.

[0107] The transaction receiving module 4 is composed of a transaction identification unit 41 and a transaction processing unit 42. Fig.11 .

[0108] 1) Transaction identification unit 41

[0109] The main function of the transaction identification unit 41 is to receive and identify the transaction instructions transmitted by the platform partner, and transmit the qualified reserved payment instructions to the transaction processing unit 42 for further processing.

[0110] 2) Transaction processing unit 42

[0111] The main function of the transaction processing unit 42 is to register the relevant transaction entities, record the transaction details, identify and formulate the payment plan after receiving the transaction instruction sent by the transaction identification unit 41, and provide index guidance for the subsequent account processing module to perform transaction processing.

[0112] The account processing module is used to deduct funds according to the payment request and authentication information, and remit the funds to the designated account according to the payment request. The account processing module 5 is composed of a fund deduction unit 51 and a merchant account entry unit 52. Fig.12 .

[0113] 1) Funds deduction unit 51

[0114] The main function of the fund deduction unit 51 is to complete the public settlement account positioning and fund deduction through the host after receiving the instruction from the transaction processing unit 42, and return the fund processing status information to the transaction processing unit 42.

[0115] 2) Merchant Account Entry Unit 52

[0116] The main function of the merchant account entry unit 52 is to complete information exchange with the funds deduction unit 51 to confirm that the funds have been deducted from the payer's settlement account after receiving the payment confirmation instruction from the transaction processing unit 42, and to remit the funds to the merchant account specified in the instruction according to the funds transfer instruction initiated by the transaction processing unit 42.

[0117] Fig.13 This is a specific embodiment of the enterprise online payment method disclosed in the present invention, schematically showing the enterprise mobile payment authorization, authentication, and payment workflow diagram designed in the present invention. The specific process is described as follows:

[0118] Step 701: User registration login information, public security face real-name authentication, storage and record the customer's login user name and bound mobile phone number.

[0119] Step 702: The user registration real-name information enters the enterprise authentication unit for processing, and the real-name user information is bound to the enterprise.

[0120] Step 703: The role authorization unit processes and stores the user's role and authority information.

[0121] Step 704: For users with enterprise financial management authority, proceed to step 705 and, through the payment authorization module, the financial authorization unit authorizes the payment amount and manages the authority of a certain handling authority user; for users without enterprise financial management authority, proceed to step 711 and enter the system through the login authentication unit to use the payment credentials within their authority.

[0122] Step 705: Perform payment limit authorization and authority management for a certain handling authority user through the financial authorization unit, or apply for payment limit authorization for the logged-in user through the handling application unit.

[0123] Step 706: Issue a payment voucher to the enterprise processing user through the financial authorization unit.

[0124] Step 707: Manage and maintain the issued payment voucher through the rights management unit.

[0125] Step 711: Authenticate the login authority of the login handling authority user through the login authentication unit.

[0126] Step 712: The authorized user queries the payment voucher that can be used within the authorized scope through the authority management unit.

[0127] Step 713: The authorized user uses the authorized payment voucher to make payment by scanning a code, transferring money, etc.

[0128] Step 714: The transaction processing unit processes the received transaction information.

[0129] Step 715: The payment authentication unit matches the transaction initiated by the processing user with his payment authority.

[0130] Step 716: The fund transfer unit deducts funds from the public settlement account according to the instruction of the transaction processing unit, and enters the funds into the account of the payee through the merchant account entry unit.

[0131] Step 717: Update the full life cycle status of the payment credential through the authority management unit.

[0132] To facilitate understanding of the present disclosure, another specific embodiment of the enterprise online payment processing method is proposed below.

[0133] S1. The user who handles the business registers with real name and is associated with the enterprise, and the financial staff authorizes the person who handles the business.

[0134] S101, the user submits personal real-name information on the client to register, and completes real-name authentication through public security network verification. The enterprise to be associated and bound is located through the U shield ID or enterprise basic location. The client program sends the registration information to our bank's server and pushes it to the enterprise to be bound;

[0135] S102, the financial management personnel checks the registered and confirms the binding relationship with the handling user through the client;

[0136] S103, the financial management user submits financial authorization on the client and sets the payment range, amount limit, validity period and other authorization information for the processing user;

[0137] S104, the financial management personnel view the authorized information through the client and dynamically manage the authorized information.

[0138] S2. The handling personnel use payment authority to make payment.

[0139] S201, the processing user logs in to the client and queries the available payment authority information;

[0140] S202, the agent scans the merchant's QR code or presents the payment QR code to the merchant;

[0141] S203, the system requires the user to perform payment authentication according to the order amount;

[0142] S204, after authentication is passed, payment is successful, and the system updates the available balance of payment authority and other information.

[0143] The present disclosure can split and re-authorize the existing online account movement permissions of enterprises. When enterprises conduct online transactions and purchases, they can directly use the funds in the enterprise settlement account to complete payment, effectively solving the pain points of enterprise advance payment, controlling the financial security risks in the enterprise payment process from the system level, and streamlining the process of online transactions and payments of enterprises.

[0144] Fig.14 A block diagram of an electronic device according to another embodiment of the present disclosure is schematically shown.

[0145] like Fig.14 As shown, the electronic device 800 includes a processor 810 and a computer-readable storage medium 820. The electronic device 800 can execute the method according to the embodiment of the present disclosure.

[0146] Specifically, the processor 810 may include, for example, a general-purpose microprocessor, an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 810 may also include an onboard memory for cache purposes. The processor 810 may be a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0147] Computer readable storage medium 820, for example, can be any medium capable of containing, storing, conveying, propagating or transmitting instructions. For example, readable storage media can include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices, devices or propagation media. Specific examples of readable storage media include: magnetic storage devices, such as magnetic tapes or hard disks (HDD); optical storage devices, such as compact disks (CD-ROMs); memory, such as random access memory (RAM) or flash memory; and / or wired / wireless communication links.

[0148] The computer-readable storage medium 820 may include a computer program 821 , which may include code / computer-executable instructions, which, when executed by the processor 810 , enable the processor 810 to perform the method flow according to the embodiment of the present disclosure and any variation thereof.

[0149] The computer program 821 may be configured to have, for example, a computer program code including a computer program module. For example, in an example embodiment, the code in the computer program 821 may include one or more program modules, for example, including 821A, module 821B, ... It should be noted that the division method and number of modules are not fixed, and those skilled in the art may use appropriate program modules or program module combinations according to actual conditions, and when these program module combinations are executed by the processor 810, the processor 810 may execute the method flow according to the embodiment of the present disclosure and any variation thereof.

[0150] The present disclosure also provides a computer-readable storage medium, which may be included in the device / system / system described in the above embodiments, or may exist independently without being assembled into the device / system / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0151] Although the present disclosure has been shown and described with reference to specific exemplary embodiments of the present disclosure, it should be understood by those skilled in the art that various changes in form and details may be made to the present disclosure without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents. Therefore, the scope of the present disclosure should not be limited to the above-mentioned embodiments, but should be determined not only by the appended claims, but also by the equivalents of the appended claims.

Claims

1. A payment method, characterized in that: include: Sending registration information of a non-financial user to a financial client so that the financial client generates authentication information for the registration information, and the authentication information is stored in a bank server; Sending a payment request to a bank server so that the bank server performs payment processing according to the payment request and authentication information; Wherein, the user logs in before sending the payment request, and logs in after the bank server authenticates the registration information; When sending a payment request, the bank server performs payment authentication based on the payment request and the preset payment authority.

2. The payment method according to claim 1, characterized in that: The sending of the payment request to the bank server comprises: Retrieve the payment voucher, which is the voucher used by the bank for payment settlement; A payment request is sent to a bank server, wherein the payment request includes the payment voucher and transaction information, so that the bank server performs payment processing.

3. The payment method according to claim 1, characterized in that: The sending of the registration information of the non-financial user to the financial client includes: Submit the registration information to the bank server so that the bank server can identify the registration information; after the identification is successful, the bank server sends the registration information to the financial client.

4. A payment method, characterized in that: include: Acquire registration information sent by the non-financial client, generate authentication information for the registration information, and store the authentication information in the bank server; Based on the authentication information, the bank server performs payment processing when receiving a payment request from a non-financial user; Wherein, the user logs in before obtaining the registration information, and logs in after the bank server passes the login authentication; When receiving the payment request, the bank server performs payment authentication based on the payment request and the preset payment authority.

5. The payment method according to claim 4, characterized in that: The obtaining of registration information sent by the non-financial client includes: The registration information sent by the non-financial client is obtained, authentication is performed, and a relationship with the non-financial user is bound.

6. The payment method according to claim 5, characterized in that: After obtaining the registration information sent by the non-financial client, the method further includes: Issuing payment authority to the non-financial user or approving payment authority applied for by the non-financial user.

7. The payment method according to claim 6, characterized in that: The obtaining of registration information sent by the non-financial client includes: Modify, maintain, and terminate the payment authority of the non-financial user to perform dynamic management.

8. A payment method, characterized in that: include: Storing authentication information, where the authentication information is generated by the financial client based on the registration information sent by the non-financial client; Obtaining a payment request sent by a non-financial user, and performing payment processing according to the payment request and the authentication information; When the non-financial user or the financial user logs into the non-financial client, a login authentication is performed; when a payment request from the non-financial user is received, a payment authentication is performed according to the payment request and a preset payment authority.

9. The payment method according to claim 8, characterized in that: The stored authentication information includes: Obtaining registration information sent by a non-financial client and performing identity recognition on the registration information; Sending the registration information to the financial client, and the financial client generating authentication information for the registration information; Acquire and store the authentication information.

10. The payment method according to claim 8, characterized in that: The obtaining of the payment request sent by the non-financial user comprises: Obtaining a payment request sent by a non-financial client and verifying the identity information of the non-financial user; Acquire payment credential information and transaction information to verify the payment authority of the non-financial user.

11. The payment method according to claim 10, characterized in that: The payment processing according to the payment request and the authentication information includes: Funds are deducted according to the payment request and the authentication information, and the funds are remitted to a designated account according to the payment request.

12. A payment device, characterized in that: include: The non-financial client is used to send the registration information of the non-financial user to the financial client, so that the financial client generates authentication information for the registration information, and the authentication information is stored in the bank server; Sending a payment request to a bank server so that the bank server performs payment processing according to the payment request and authentication information; Financial client, used to obtain registration information sent by non-financial client; The bank server is used to store authentication information; to obtain the payment request sent by the non-financial user and perform payment processing; to perform login authentication when the non-financial user or the financial user logs into the non-financial client or the financial client; and to perform payment authentication according to the payment request and the preset payment authority when receiving the payment request from the non-financial user.

13. A payment system, characterized in that: include: A user management module, used to receive registration information of non-financial users and send it to a financial client, so that the financial client generates authentication information for the registration information; A payment authorization module, used by the non-financial user to apply for payment authority, and used by the financial client to issue payment authority to the non-financial user; A payment authentication module, used to verify the identity information and payment authority of the non-financial user; A transaction receiving module, used for identifying transaction information; The account processing module is used to deduct funds according to the payment request and the authentication information, and remit the funds to a designated account according to the payment request.

14. An electronic device comprising: processor; A memory storing a computer executable program, which, when executed by the processor, enables the processor to execute the payment method as described in any one of claims 1 to 11.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the payment method as described in any one of claims 1 to 11 is implemented.

Images