阅读说明：本技术 一种方便商户账务管理的聚合支付平台 (Make things convenient for commercial tenant account management's polymerization payment platform ) 是由 张江旭 于 2021-09-02 设计创作，主要内容包括：本发明涉及支付平台技术领域,具体为一种方便商户账务管理的聚合支付平台,包括聚合支付平台,所述聚合支付平台由运营管理Web子系统、移动收单POSP子系统、代理端Web子系统、商户端Web子系统、代理端App、商户端App组成,通过支付平台满足商户在账单管理、库存管理、会员管理、店面管理等不同维度的管理需求,彻底解决商家的记账难、对账难问题,实现场景化智能运营,支付平台全面整合商家的顾客流、资金流、商品流、信息流,让商家轻松实现智慧经营的美好愿望,通过一系列增值服务,赋能企业发展,结合大数据、人工智能等高新技术,提供交易数据分析、营销方案定制、精准广告投放等专业化服务,实现流量和营销资源的精准触达。(The invention relates to the technical field of payment platforms, in particular to an aggregated payment platform convenient for merchant account management, which comprises an aggregated payment platform, wherein the aggregated payment platform consists of an operation management Web subsystem, a mobile receipt POSP subsystem, an agent end Web subsystem, a merchant end Web subsystem, an agent end App and a merchant end App, the management requirements of merchants in different dimensions such as bill management, inventory management, member management, storefront management and the like are met through the payment platform, the problems of difficult bookkeeping and difficult account checking of merchants are thoroughly solved, scene intelligent operation is realized, the payment platform comprehensively integrates customer flow, fund flow, commodity flow and information flow of the merchants, the merchants easily realize the beauty and goodness of intelligent operation, the enterprise development is enabled through a series of services, and the transaction data analysis and marketing scheme customization are provided by combining high and new technologies such as big data, artificial intelligence and the like, Specialized services such as accurate advertisement putting realize the accurate touch of flow and marketing resource.)

1. The utility model provides a make things convenient for merchant account management's polymerization payment platform, includes polymerization payment platform, its characterized in that: the polymerization payment platform consists of an operation management Web subsystem, a mobile receipt POSP subsystem, an agent end Web subsystem, a merchant end Web subsystem, an agent end App and a merchant end App.

2. The aggregated payment platform for facilitating merchant accounting management as recited in claim 1, wherein: the aggregation payment platform is constructed in a service and componentization mode, each link in an aggregation payment key business process is abstracted into a technical component through a technical means, and the platform layer is driven by a process and a rule engine to be fused with the business components.

3. The aggregated payment platform for facilitating merchant accounting management as recited in claim 1, wherein: the polymerization payment platform is integrated with hardware devices such as intelligent Pos, cloud printing and cloud sound equipment and an IOT platform, and the software and the hardware are combined to provide integrated services of cash collection and subsequent cash collection for merchants.

4. The aggregated payment platform for facilitating merchant accounting management as recited in claim 1, wherein: the method comprises the following steps of using scene flow:

a login scene:

step 1: opening a browser and inputting a browsing address;

step 2: inputting the account password of the agent, clicking to login → entering the home page;

only supporting the operation center and the proxy account login;

agent management scenario:

the module can open the functions of proxy, editing proxy information, setting proxy rate and the like;

step 1: clicking a left menu bar (an agent list) → entering an agent list page;

terminal management scenario:

the module can perform functions of browsing terminal information, dialing down a terminal, dialing back a terminal, setting terminal deposit and the like, and can export terminal data;

step 1: clicking a left menu bar (terminal list) → entering a terminal list page;

step 2: appointed conditions can be input, and [ search ] is clicked → terminal data meeting the conditions are screened out;

commercial tenant service opening scene:

note: the following takes the enterprise legal person to private settlement business type as an example.

Step 1: clicking a left menu bar (merchant management) → entering a merchant management list page;

step 2: clicking (opening commercial tenant) → entering a page for filling in basic information;

step 3: inputting basic information of the merchant → clicking (I has read and agreed) button → clicking (submission) → submitting to return to the merchant list successfully;

step 4: click [ apply for filing ] → enter and select merchant type page;

step 5: filling in basic information; registering the service type;

step 6: filling in business license information and uploading a business license picture;

step 7: filling in the information of the legal person, and uploading the positive and negative faces of the identity card picture;

step 8: filling in settlement information and uploading a bank card identity card picture;

step 9: confirming the rate;

step 10: uploading the attachment, clicking (submitting) after signing → submitting successfully;

a transaction statistics scenario: the module can check the flow record of the merchant, transaction statistics, agent income statistics and team terminal number statistics;

step 1: clicking a left menu bar (transaction statistics) → entering a transaction statistics page;

step 2: selecting a specified statistical time interval, clicking [ search ] → counting a corresponding result;

agent revenue statistics scenario:

step 1: clicking a left menu bar (proxy income statistics) → entering a proxy income statistics page;

step 2: selecting a subordinate, clicking a [ search ] button → counting the income condition of the whole team;

commercial tenant transaction flow scene:

step 1: clicking a left menu bar (merchant transaction record) → entering a transaction flow page;

step 2: click [ search ] button → find out the current month flow record by default.

5. The aggregated payment platform for facilitating merchant accounting management as recited in claim 1, wherein: the payment business process comprises the following steps:

main scanning payment business process: start → user opens WeChat/Payment scanning → scanning merchant's fixed two-dimensional code for collection → cashier's station obtains authorization of user's geographic location → whether to receive authorized geographic location → input payment amount point to confirm payment (if merchant's fixed two-dimensional code is monetary, user doesn't need to input amount) → judge whether user's input amount is supported → error: amount is not supported, re-delivery → cash register station again acquires user geographic location → receives authorized geographic location → does not support payment, closes re-scanning code → judges whether merchant supports transaction (merchant state and transaction type state) → error report: merchant does not support transaction or merchant transaction type does not support → determine if merchant device is within tradable range → error report: the equipment is not in the payment range, does not support transaction → transaction information (the information is seen in an interface document) → success of uploading → 30S overtime or abnormity → transaction failure → transaction request acquisition, channel generation order number → success of transaction → transaction failure → transaction success → success of transaction → success of pushing result → failure of receiving payment success notification, abnormal order needs manual processing → order state is synchronized to the equipment after receiving the transaction success notification → pushing result is successful → receiving the transaction success notification, order completion → successful order differentiation is performed;

scanned payment business process: beginning → inputting amount of money received on the device, confirming money reception → judging whether the merchant supports transaction (merchant state and transaction type state) → merchant state exception, connecting manual processing → user shows payment two-dimensional code → judging whether valid two-dimensional code → invalid two-dimensional code, informing the user to change two-dimensional code → judging whether the money receiving device is in the location of the merchant address → whether the device is out of range of transaction, not supporting money reception → generating platform order back to send transaction information (send information see interface document) → success of sending up → 30S timeout or exception → transaction failure → success of sending up → obtaining transaction request → whether the user needs to input payment password → whether the password is correct → transaction failure, user cancel payment → if user cancels payment voluntarily when inputting password, WeChat has notice, Paibao has no notice, inquiry is once every 5S, and automatic cancellation and recovery when no result is obtained after 60S; whether the password is correct → whether the transaction request is received successfully → the user and the merchant receive the notification of the failure of the transaction → the transaction is successful → the order of the successful transaction is generated; whether the order is successfully uploaded → the order request state of the equipment → the order transaction result generated during the system polling → whether the order is successful → the transaction failure (error report of the synchronous channel) → the transaction success → the successful order is divided and moistened;

card swiping payment business process: start → input of amount of money to be collected on the device, confirmation of collection → determination of whether the merchant supports a transaction (merchant status and transaction type status) → merchant status exception, contact manual processing → presentation of bank card → card support of normal transaction → error notification: displaying the channel return result → inputting password → prompting the user to input password → initiating the order taking request → receiving order successfully → reporting error: the channel returns the result display → the deduction success → the order collection success, the transaction order → whether the order is collected and pushed → the order collection success → the end; whether to receive orders and push orders → synchronize to the system, and generate corresponding platform order numbers → push orders of all transactions at the end of the day → start reconciliation after obtaining channel reconciliation → whether reconciliation is successful → do reconciliation processing on the basis of channel reconciliation, supplement missed orders → finish reconciliation.

Technical Field

The invention relates to the technical field of payment platforms, in particular to an aggregation payment platform convenient for merchant account management.

Background

In order to solve the traditional services of small, medium and small chain merchant mobile payment, internet payment, bank card receipt, settlement, clearing and the like, the APP terminal provides an all-around and integrated solution scheme of clear settlement, statement of account and the like for the merchant boss, and therefore the aggregated payment platform convenient for merchant account management is provided.

Disclosure of Invention

The invention aims to provide an aggregation payment platform convenient for merchant account management, so as to solve the problems in the background technology.

In order to achieve the purpose, the invention provides the following technical scheme:

an aggregation payment platform convenient for merchant account management comprises an aggregation payment platform, wherein the aggregation payment platform consists of an operation management Web subsystem, a mobile receipt POSP subsystem, an agent end Web subsystem, a merchant end Web subsystem, an agent end App and a merchant end App.

As a preferable scheme of the invention, the aggregation payment platform is constructed in a way of servitization and componentization, each link in the key business flow of the aggregation payment is abstracted into a technical component by a technical means, and the platform layer is driven by a flow and a rule engine to be fused with the business component.

As a preferred scheme of the present invention, the aggregated payment platform provides integrated services of cash register and subsequent cash register for the merchant by integrating hardware devices such as intelligent Pos, cloud printing, cloud audio, and the like, and an IOT platform, and combining the hardware and software.

An aggregated payment platform facilitating merchant account management, comprising the following usage scenario flow steps:

a login scene:

step 1: opening a browser and inputting a browsing address;

step 2: inputting the account password of the agent, clicking to login → entering the home page;

only supporting the operation center and the proxy account login;

agent management scenario:

the module can open the functions of proxy, editing proxy information, setting proxy rate and the like;

step 1: clicking a left menu bar (an agent list) → entering an agent list page;

terminal management scenario:

the module can perform functions of browsing terminal information, dialing down a terminal, dialing back a terminal, setting terminal deposit and the like, and can export terminal data;

step 1: clicking a left menu bar (terminal list) → entering a terminal list page;

step 2: appointed conditions can be input, and [ search ] is clicked → terminal data meeting the conditions are screened out;

commercial tenant service opening scene:

note: the following takes the enterprise legal person to private settlement business type as an example.

Step 1: clicking a left menu bar (merchant management) → entering a merchant management list page;

step 2: clicking (opening commercial tenant) → entering a page for filling in basic information;

step 3: inputting basic information of the merchant → clicking (I has read and agreed) button → clicking (submission) → submitting to return to the merchant list successfully;

step 4: click [ apply for filing ] → enter and select merchant type page;

step 5: filling in basic information; registering the service type;

step 6: filling in business license information and uploading a business license picture;

step 7: filling in the information of the legal person, and uploading the positive and negative faces of the identity card picture;

step 8: filling in settlement information and uploading a bank card identity card picture;

step 9: confirming the rate;

step 10: uploading the attachment, clicking (submitting) after signing → submitting successfully;

a transaction statistics scenario: the module can check the flow record of the merchant, transaction statistics, agent income statistics and team terminal number statistics;

step 1: clicking a left menu bar (transaction statistics) → entering a transaction statistics page;

step 2: selecting a specified statistical time interval, clicking [ search ] → counting a corresponding result;

agent revenue statistics scenario:

step 1: clicking a left menu bar (proxy income statistics) → entering a proxy income statistics page;

step 2: selecting a subordinate, clicking a [ search ] button → counting the income condition of the whole team;

commercial tenant transaction flow scene:

step 1: clicking a left menu bar (merchant transaction record) → entering a transaction flow page;

step 2: click [ search ] button → find out the current month flow record by default.

An aggregated payment platform convenient for merchant account management, the payment business process comprises the following steps:

main scanning payment business process: start → user opens WeChat/Payment scanning → scanning merchant's fixed two-dimensional code for collection → cashier's station obtains authorization of user's geographic location → whether to receive authorized geographic location → input payment amount point to confirm payment (if merchant's fixed two-dimensional code is monetary, user doesn't need to input amount) → judge whether user's input amount is supported → error: the method comprises the following steps of money amount non-support, re-input → the cashier station acquires the geographic position of the user again → whether the geographic position is authorized is received → non-support of payment, close the re-scanning code → judge whether the merchant supports transaction (merchant state and transaction type state) → error report: merchant does not support transaction or merchant transaction type does not support → determine if merchant device is within tradable range → error report: the equipment is not in the payment range, does not support transaction → transaction information (the information is seen in an interface document) → success of uploading → 30S overtime or abnormity → transaction failure → transaction request acquisition, channel generation order number → success of transaction → transaction failure → transaction success → success of transaction → success of pushing result → failure of receiving payment success notification, abnormal order needs manual processing → order state is synchronized to the equipment after receiving the transaction success notification → pushing result is successful → receiving the transaction success notification, order completion → successful order differentiation is performed;

scanned payment business process: beginning → inputting amount of money received on the device, confirming money reception → judging whether the merchant supports transaction (merchant state and transaction type state) → merchant state exception, connecting manual processing → user shows payment two-dimensional code → judging whether valid two-dimensional code → invalid two-dimensional code, informing the user to change two-dimensional code → judging whether the money receiving device is in the location of the merchant address → whether the device is out of range of transaction, not supporting money reception → generating platform order back to send transaction information (send information see interface document) → success of sending up → 30S timeout or exception → transaction failure → success of sending up → obtaining transaction request → whether the user needs to input payment password → whether the password is correct → transaction failure, user cancel payment → if user cancels payment voluntarily when inputting password, WeChat has notice, Paibao has no notice, inquiry is once every 5S, and automatic cancellation and recovery when no result is obtained after 60S; whether the password is correct → whether the transaction request is received successfully → the user and the merchant receive the notification of the failure of the transaction → the transaction is successful → the order of the successful transaction is generated; whether the order is successfully uploaded → the order request state of the equipment → the order transaction result generated during the system polling → whether the order is successful → the transaction failure (error report of the synchronous channel) → the transaction success → the successful order is divided and moistened;

card swiping payment business process: start → input of amount of money to be collected on the device, confirmation of collection → determination of whether the merchant supports a transaction (merchant status and transaction type status) → merchant status exception, contact manual processing → presentation of bank card → card support of normal transaction → error notification: displaying the channel return result → inputting password → prompting the user to input password → initiating the order taking request → receiving order successfully → reporting error: the channel returns the result display → the deduction success → the order collection success, the transaction order → whether the order is collected and pushed → the order collection success → the end; whether to receive orders and push orders → synchronize to the system, and generate corresponding platform order numbers → push orders of all transactions at the end of the day → start reconciliation after obtaining channel reconciliation → whether reconciliation is successful → do reconciliation processing on the basis of channel reconciliation, supplement missed orders → finish reconciliation.

Compared with the prior art, the invention has the beneficial effects that:

1. in the invention, a plurality of business states such as large business superman, brand catering, hospital schools, hotel KTVs and the like are covered by the payment platform, payment hardware equipment such as a counter board, a cloud horn, a code scanning king and the like is pushed out, one code scanning and multiple scanning are realized, deep cooperation is carried out with each large bank, and a diversified payment solution and safe specialized collection service from online to offline are provided for large, medium and small enterprises.

2. According to the invention, the management requirements of merchants in different dimensions such as bill management, inventory management, member management, storefront management and the like are met through the payment platform, the problems of difficult bookkeeping and account checking of merchants are thoroughly solved, scene intelligent operation is realized, the payment platform comprehensively integrates the customer flow, the fund flow, the commodity flow and the information flow of the merchants, so that the merchants easily realize the nice desire of intelligent operation, professional services such as transaction data analysis, marketing scheme customization, accurate advertisement putting and the like are provided through a series of value-added services, enterprise development is enabled, and high and new technologies such as big data, artificial intelligence and the like are combined, so that accurate touch of flow and marketing resources is realized, and enterprises are assisted to establish an 'internet + business' closed loop of online marketing-store-online consumption-offline payment-social sharing.

Drawings

FIG. 1 is a diagram of a payment platform architecture of the present invention;

FIG. 2 is a flow chart of the main scan payment service of the present invention;

FIG. 3 is a scanned payment transaction flow diagram of the present invention;

fig. 4 is a card payment business process of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all embodiments, and all other embodiments obtained by a person of ordinary skill in the art without creative efforts based on the embodiments of the present invention belong to the protection scope of the present invention.

In order to facilitate an understanding of the invention, the invention will now be described more fully hereinafter with reference to the accompanying drawings, in which several embodiments of the invention are shown, but which can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete.

It will be understood that when an element is referred to as being "secured to" another element, it can be directly on the other element or intervening elements may also be present. When an element is referred to as being "connected" to another element, it can be directly connected to the other element or intervening elements may also be present. The terms "vertical," "horizontal," "left," "right," and the like as used herein are for illustrative purposes only.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items.

Referring to fig. 1-4, the present invention provides a technical solution:

an aggregation payment platform convenient for merchant account management comprises an aggregation payment platform, wherein the aggregation payment platform consists of an operation management Web subsystem, a mobile receipt POSP subsystem, an agent end Web subsystem, a merchant end Web subsystem, an agent end App and a merchant end App.

The aggregation payment platform is constructed in a service and componentization mode, each link in the aggregation payment key business process is abstracted into a technical component through a technical means, and the platform layer is driven by the process and the rule engine to be fused with the business components.

The polymerization payment platform is integrated with hardware devices such as intelligent Pos, cloud printing and cloud sound equipment and an IOT platform, and the hardware devices are combined to provide integrated services of cash collection and subsequent cash collection for merchants.

An aggregated payment platform facilitating merchant account management, comprising the following usage scenario flow steps:

a login scene:

step 1: opening a browser and inputting a browsing address;

step 2: inputting the account password of the agent, clicking to login → entering the home page;

only supporting the operation center and the proxy account login;

agent management scenario:

the module can open the functions of proxy, editing proxy information, setting proxy rate and the like;

step 1: clicking a left menu bar (an agent list) → entering an agent list page;

terminal management scenario:

the module can perform functions of browsing terminal information, dialing down a terminal, dialing back a terminal, setting terminal deposit and the like, and can export terminal data;

step 1: clicking a left menu bar (terminal list) → entering a terminal list page;

step 2: appointed conditions can be input, and [ search ] is clicked → terminal data meeting the conditions are screened out;

commercial tenant service opening scene:

note: the following takes the enterprise legal person to private settlement business type as an example.

Step 1: clicking a left menu bar (merchant management) → entering a merchant management list page;

step 2: clicking (opening commercial tenant) → entering a page for filling in basic information;

step 3: inputting basic information of the merchant → clicking (I has read and agreed) button → clicking (submission) → submitting to return to the merchant list successfully;

step 4: click [ apply for filing ] → enter and select merchant type page;

step 5: filling in basic information; registering the service type;

step 6: filling in business license information and uploading a business license picture;

step 7: filling in the information of the legal person, and uploading the positive and negative faces of the identity card picture;

step 8: filling in settlement information and uploading a bank card identity card picture;

step 9: confirming the rate;

step 10: uploading the attachment, clicking (submitting) after signing → submitting successfully;

a transaction statistics scenario: the module can check the flow record of the merchant, transaction statistics, agent income statistics and team terminal number statistics;

step 1: clicking a left menu bar (transaction statistics) → entering a transaction statistics page;

step 2: selecting a specified statistical time interval, clicking [ search ] → counting a corresponding result;

agent revenue statistics scenario:

step 1: clicking a left menu bar (proxy income statistics) → entering a proxy income statistics page;

step 2: selecting a subordinate, clicking a [ search ] button → counting the income condition of the whole team;

commercial tenant transaction flow scene:

step 1: clicking a left menu bar (merchant transaction record) → entering a transaction flow page;

step 2: click [ search ] button → find out the current month flow record by default.

An aggregated payment platform convenient for merchant account management, the payment business process comprises the following steps:

main scanning payment business process: start → user opens WeChat/Payment scanning → scanning merchant's fixed two-dimensional code for collection → cashier's station obtains authorization of user's geographic location → whether to receive authorized geographic location → input payment amount point to confirm payment (if merchant's fixed two-dimensional code is monetary, user doesn't need to input amount) → judge whether user's input amount is supported → error: amount is not supported, re-delivery → cash register station again acquires user geographic location → receives authorized geographic location → does not support payment, closes re-scanning code → judges whether merchant supports transaction (merchant state and transaction type state) → error report: merchant does not support transaction or merchant transaction type does not support → determine if merchant device is within tradable range → error report: the equipment is not in the payment range, does not support transaction → transaction information (the information is seen in an interface document) → success of uploading → 30S overtime or abnormity → transaction failure → transaction request acquisition, channel generation order number → success of transaction → transaction failure → transaction success → success of transaction → success of pushing result → failure of receiving payment success notification, abnormal order needs manual processing → order state is synchronized to the equipment after receiving the transaction success notification → pushing result is successful → receiving the transaction success notification, order completion → successful order differentiation is performed;

scanned payment business process: beginning → inputting amount of money received on the device, confirming money reception → judging whether the merchant supports transaction (merchant state and transaction type state) → merchant state exception, connecting manual processing → user shows payment two-dimensional code → judging whether valid two-dimensional code → invalid two-dimensional code, informing the user to change two-dimensional code → judging whether the money receiving device is in the location of the merchant address → whether the device is out of range of transaction, not supporting money reception → generating platform order back to send transaction information (send information see interface document) → success of sending up → 30S timeout or exception → transaction failure → success of sending up → obtaining transaction request → whether the user needs to input payment password → whether the password is correct → transaction failure, user cancel payment → if user cancels payment voluntarily when inputting password, WeChat has notice, Paibao has no notice, inquiry is once every 5S, and automatic cancellation and recovery when no result is obtained after 60S; whether the password is correct → whether the transaction request is received successfully → the user and the merchant receive the notification of the failure of the transaction → the transaction is successful → the order of the successful transaction is generated; whether the order is successfully uploaded → the order request state of the equipment → the order transaction result generated during the system polling → whether the order is successful → the transaction failure (error report of the synchronous channel) → the transaction success → the successful order is divided and moistened;

card swiping payment business process: start → input of amount of money to be collected on the device, confirmation of collection → determination of whether the merchant supports a transaction (merchant status and transaction type status) → merchant status exception, contact manual processing → presentation of bank card → card support of normal transaction → error notification: displaying the channel return result → inputting password → prompting the user to input password → initiating the order taking request → receiving order successfully → reporting error: the channel returns the result display → the deduction success → the order collection success, the transaction order → whether the order is collected and pushed → the order collection success → the end; whether to receive orders and push orders → synchronize to the system, and generate corresponding platform order numbers → push orders of all transactions at the end of the day → start reconciliation after obtaining channel reconciliation → whether reconciliation is successful → do reconciliation processing on the basis of channel reconciliation, supplement missed orders → finish reconciliation.

Example (b): a login scene:

step 1: opening a browser and inputting a browsing address;

step 2: inputting the account password of the agent, clicking to login → entering the home page;

only supporting the operation center and the proxy account login;

agent management scenario:

the module can open the functions of proxy, editing proxy information, setting proxy rate and the like;

step 1: clicking a left menu bar (an agent list) → entering an agent list page;

terminal management scenario:

the module can perform functions of browsing terminal information, dialing down a terminal, dialing back a terminal, setting terminal deposit and the like, and can export terminal data;

step 1: clicking a left menu bar (terminal list) → entering a terminal list page;

step 2: appointed conditions can be input, and [ search ] is clicked → terminal data meeting the conditions are screened out;

commercial tenant service opening scene:

note: the following takes the enterprise legal person to private settlement business type as an example.

Step 1: clicking a left menu bar (merchant management) → entering a merchant management list page;

step 2: clicking (opening commercial tenant) → entering a page for filling in basic information;

step 3: inputting basic information of the merchant → clicking (I has read and agreed) button → clicking (submission) → submitting to return to the merchant list successfully;

step 4: click [ apply for filing ] → enter and select merchant type page;

step 5: filling in basic information; registering the service type;

step 6: filling in business license information and uploading a business license picture;

step 7: filling in the information of the legal person, and uploading the positive and negative faces of the identity card picture;

step 8: filling in settlement information and uploading a bank card identity card picture;

step 9: confirming the rate;

step 10: uploading the attachment, clicking (submitting) after signing → submitting successfully;

a transaction statistics scenario: the module can check the flow record of the merchant, transaction statistics, agent income statistics and team terminal number statistics;

step 1: clicking a left menu bar (transaction statistics) → entering a transaction statistics page;

step 2: selecting a specified statistical time interval, clicking [ search ] → counting a corresponding result;

agent revenue statistics scenario:

step 1: clicking a left menu bar (proxy income statistics) → entering a proxy income statistics page;

step 2: selecting a subordinate, clicking a [ search ] button → counting the income condition of the whole team;

commercial tenant transaction flow scene:

step 1: clicking a left menu bar (merchant transaction record) → entering a transaction flow page;

step 2: click [ search ] button → find out the current month flow record by default.

Main scanning payment business process: start → user opens WeChat/Payment scanning → scanning merchant's fixed two-dimensional code for collection → cashier's station obtains authorization of user's geographic location → whether to receive authorized geographic location → input payment amount point to confirm payment (if merchant's fixed two-dimensional code is monetary, user doesn't need to input amount) → judge whether user's input amount is supported → error: amount is not supported, re-delivery → cash register station again acquires user geographic location → receives authorized geographic location → does not support payment, closes re-scanning code → judges whether merchant supports transaction (merchant state and transaction type state) → error report: merchant does not support transaction or merchant transaction type does not support → determine if merchant device is within tradable range → error report: the equipment is not in the payment range, does not support transaction → transaction information (the information is seen in an interface document) → success of uploading → 30S overtime or abnormity → transaction failure → transaction request acquisition, channel generation order number → success of transaction → transaction failure → transaction success → success of transaction → success of pushing result → failure of receiving payment success notification, abnormal order needs manual processing → order state is synchronized to the equipment after receiving the transaction success notification → pushing result is successful → receiving the transaction success notification, order completion → successful order differentiation is performed;

scanned payment business process: beginning → inputting amount of money received on the device, confirming money reception → judging whether the merchant supports transaction (merchant state and transaction type state) → merchant state exception, connecting manual processing → user shows payment two-dimensional code → judging whether valid two-dimensional code → invalid two-dimensional code, informing the user to change two-dimensional code → judging whether the money receiving device is in the location of the merchant address → whether the device is out of range of transaction, not supporting money reception → generating platform order back to send transaction information (send information see interface document) → success of sending up → 30S timeout or exception → transaction failure → success of sending up → obtaining transaction request → whether the user needs to input payment password → whether the password is correct → transaction failure, user cancel payment → if user cancels payment voluntarily when inputting password, WeChat has notice, Paibao has no notice, inquiry is once every 5S, and automatic cancellation and recovery when no result is obtained after 60S; whether the password is correct → whether the transaction request is received successfully → the user and the merchant receive the notification of the failure of the transaction → the transaction is successful → the order of the successful transaction is generated; whether the order is successfully uploaded → the order request state of the equipment → the order transaction result generated during the system polling → whether the order is successful → the transaction failure (error report of the synchronous channel) → the transaction success → the successful order is divided and moistened;

card swiping payment business process: start → input of amount of money to be collected on the device, confirmation of collection → determination of whether the merchant supports a transaction (merchant status and transaction type status) → merchant status exception, contact manual processing → presentation of bank card → card support of normal transaction → error notification: displaying the channel return result → inputting password → prompting the user to input password → initiating the order taking request → receiving order successfully → reporting error: the channel returns the result display → the deduction success → the order collection success, the transaction order → whether the order is collected and pushed → the order collection success → the end; whether to receive orders and push orders → synchronize to the system, and generate corresponding platform order numbers → push orders of all transactions at the end of the day → start reconciliation after obtaining channel reconciliation → whether reconciliation is successful → do reconciliation processing on the basis of channel reconciliation, supplement missed orders → finish reconciliation.

Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes, modifications, substitutions and alterations can be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.