CN116934311A - Aggregate payment system and payment method - Google Patents
Aggregate payment system and payment method Download PDFInfo
- Publication number
- CN116934311A CN116934311A CN202310978635.8A CN202310978635A CN116934311A CN 116934311 A CN116934311 A CN 116934311A CN 202310978635 A CN202310978635 A CN 202310978635A CN 116934311 A CN116934311 A CN 116934311A
- Authority
- CN
- China
- Prior art keywords
- payment
- merchant
- user
- judging whether
- management module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 238000012544 monitoring process Methods 0.000 claims abstract description 9
- 238000012795 verification Methods 0.000 claims description 26
- 230000006870 function Effects 0.000 claims description 5
- 238000012423 maintenance Methods 0.000 claims description 5
- 230000008014 freezing Effects 0.000 claims description 3
- 238000007710 freezing Methods 0.000 claims description 3
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 238000010257 thawing Methods 0.000 claims description 3
- 230000007547 defect Effects 0.000 claims description 2
- 230000007246 mechanism Effects 0.000 abstract description 7
- 238000003032 molecular docking Methods 0.000 abstract description 4
- 238000007726 management method Methods 0.000 description 34
- 230000008569 process Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000010354 integration Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000013467 fragmentation Methods 0.000 description 2
- 238000006062 fragmentation reaction Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 239000010800 human waste Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/407—Cancellation of a transaction
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention discloses an aggregate payment system and a payment method, wherein the aggregate payment system comprises an electronic wallet module, a merchant management module, a third party channel management module, a receipt and payment management module and an account checking management module; the merchant management module is used for storing and modifying basic information of each access merchant and adjusting payment and refund parameters and channels corresponding to the merchant; the third party channel management module is used for managing and configuring third party payment channel server information; the account checking management module is used for monitoring whether a difference exists between the payment system and the third-party channel; the aggregate payment platform integrates a plurality of payment channels, a plurality of payment scenes and a plurality of payment modes, and all payment modes can be used by each system only by accessing one SDK into the own cash system without searching for payment mechanisms which want to be docked one by one and without repeated docking to integrate complicated payment interfaces.
Description
Technical Field
The invention belongs to the technical field of network payment, and particularly relates to an aggregate payment system and a payment method.
Background
Nowadays, online payment is widely applied to various places due to good convenience. At present, a plurality of platforms and consumption adopt an aggregate payment method, for example, a plurality of payment platforms can be enabled to carry out code scanning deduction through two-dimension codes, and convenience is provided for consumers.
The aggregate payment is a payment mode which is produced by different payment interfaces of different third-party channel servers and simultaneously pre-charging and verifying the capability of the electronic wallet in the integrated company. The aggregated payment platform weakens the interface difference of channel service providers, interfaces of different or same payment modes are unified into a standard interface, different payment modes can use the same payment platform, and an access merchant does not need to call different payment interfaces to collect money. When the access merchant needs to add or change the payment service, the payment service which is added or changed on each system is not needed, and the cost for developing and maintaining the payment functions of different systems is reduced.
In the prior art, each system needs to be connected with each payment mechanism and the payment function of the self-research electronic wallet system, and needs to find the payment mechanism which is in butt joint, so as to realize the complex payment interface. Repeated docking and integration of different projects in different systems results in significant human waste. Therefore, the aggregate payment in the prior art has repeated integration of each service system, uneven interface documents provided by each payment mechanism, inconsistent technical requirements and different payment stability; payment scene fragmentation, and inconsistent requirements of various systems.
Disclosure of Invention
The invention aims to provide an aggregate payment system and a payment method, which are used for solving the problems that in the prior art, aggregate payment is repeatedly integrated by each service system, interface documents provided by each payment mechanism are uneven, technical requirements are inconsistent and payment stability is different; payment scene fragmentation, and inconsistent requirements of various systems.
In order to solve the technical problems, the invention adopts the following technical scheme:
an aggregate payment system comprises an electronic wallet module, a merchant management module, a third party channel management module, a receipt and payment management module and a reconciliation management module;
the electronic wallet module comprises payment mode management, payment and refund record management, payment and refund notification retry functions of the aggregate payment system;
the merchant management module is used for storing and modifying basic information of each access merchant and adjusting payment and refund parameters and channels corresponding to the merchant; the third party channel management module is used for managing and configuring third party payment channel service provider information, configuring and adjusting channel payment parameters; the payment receiving and paying management module is used for managing, monitoring and storing aggregated payment and refund records of all merchants; the account checking management module is used for monitoring whether the payment system and the third-party channel have differences, and can timely respond to management maintenance personnel when the differences exist.
According to the technical scheme, the payment comprises the following steps:
step S1, a user orders;
step S2, initiating pre-payment by an aggregate payment platform;
step S3, judging whether the merchant state verification is passed or not, if so, continuing, and if not, canceling the payment;
in step S3, the merchant status is the mark of merchant opening or closing in the aggregated payment system; if the merchant state is on, the merchant is effective, namely passing verification; and if the merchant state is closed, the merchant is invalid, i.e. the merchant is not authenticated.
S4, inquiring a payment mode supported by the aggregate payment platform;
step S5, the user selects a payment mode;
step S6, a user initiates a payment request;
step S7, judging whether the merchant configures a third party account, if so, requesting a third party channel to initiate payment; if not, ending;
step S8, requesting a third party channel to initiate payment;
step S9, judging whether the payment is completed, if so, notifying the business party that the payment is completed, if not, ending the payment when the payment time limit is exceeded and the payment is not successful yet;
step S10, end.
According to the technical scheme, the routing policy generation rule comprises a payment facilitator code, a payment mode and a payment control.
According to the technical scheme, the system further comprises a reconciliation difference early warning, and the reconciliation difference early warning specifically comprises the following steps:
step A1, downloading statement of account;
step A2, analyzing statement of accounts;
step A3, judging whether the statement is completely analyzed; if yes, continuing, and if not, sending an early warning to the user;
step A4, comparing bill data; bill comparison, namely, comparing daily payment data of the aggregate payment platform with daily bill data of each payment service provider; the comparison content comprises: a payment facilitator merchant number, a payment amount; the comparison association condition is that the payment single numbers are consistent; if the aggregate payment platform bill exists, the payment service provider bill does not exist, and the aggregate payment platform bill is recorded as a multi-account; if the aggregate payment platform bill does not exist, the payment service provider bill exists, and the aggregate payment platform bill is recorded as a short account; if the amounts are different, recording that the amounts are inconsistent;
step A5, judging whether the record has a defect or not; if yes, notifying the user, and if not, continuing;
and A6, judging whether the amounts are consistent, if so, ending, finishing checking, and if not, giving an early warning to the user.
According to the technical scheme, the system further comprises an electronic wallet recharging method, and the recharging method comprises the following steps:
step B1, a user initiates recharging;
step B2, judging whether the recharging amount exceeds the real authentication limit, if so, judging whether the user completes the real authentication; if not, judging whether the balance of the user exceeds the regulation limit;
step B3, judging whether the user completes the authentication of the real person, if so, judging whether the balance of the user exceeds the regulation limit, and if not, requiring the user to complete the authentication of the real person;
and B4, judging whether the balance of the user exceeds the regulation limit, if so, exiting, and if not, selecting online payment to finish recharging.
According to the technical scheme, the system further comprises an electronic wallet accounting method, and the electronic wallet accounting method comprises the following steps of:
step C1, judging whether an account of a user is frozen; if yes, thawing the account is needed; if not, the user inputs a password or a verification code to verify the account;
step C2, checking whether the user password or the verification code is correct, if so, continuing, and if not, judging whether the error times exceed the limit; if the limit is exceeded, temporarily freezing the account number of the user, and if the limit is not exceeded, re-inputting a password or a verification code;
step C3, judging whether the verification amount is larger than the balance, if so, continuing, and if not, exiting;
and C4, deducting the verification amount of the user and recording.
Compared with the prior art, the invention has the following beneficial effects:
the aggregate payment platform integrates a plurality of payment channels, a plurality of payment scenes and a plurality of payment modes, and all payment modes can be used by each system only by accessing one SDK into the own cash system without searching for payment mechanisms which want to be docked one by one and without repeated docking to integrate complicated payment interfaces.
And meanwhile, main stream payment tools such as WeChat, payment treasures, unionpay cloud payment and the like are supported. The payment link merchants and channels are aggregated, the access technology and communication threshold are reduced, the channel cost is reduced, the payment access is realized conveniently and rapidly, and the operation efficiency of a merchant payment settlement system is improved.
Drawings
FIG. 1 is a schematic diagram of a payment system module of the present invention;
FIG. 2 is a payment flow chart of the present invention;
FIG. 3 is a flow chart of the merchant collecting ability determination according to the present invention;
FIG. 4 is a flow chart of the reconciliation system of the present invention;
FIG. 5 is a flow chart of the pre-recharging of the electronic purse of the present invention;
fig. 6 is a flow chart of the electronic wallet accounting of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Example 1
As shown in FIG. 1, an aggregate payment system and payment method comprises an electronic wallet module, a merchant management module, a third party channel management module, a receipt and payment management module and a reconciliation management module;
the electronic wallet module comprises payment mode management, payment and refund record management, payment and refund notification retry functions of the aggregated payment system. The payment mode management is used for configuring the payment mode relation supported by each third-party channel. The payment and refund record management is used for recording and tracking all payment and refund transactions, including transaction amount, time, payment state and other information; while allowing the administrator to process refund requests and track the status and amount of refunds. The payment and refund notification re-try is used to manually re-send notification of the success or failure of the payment and refund to the accessed merchant.
The merchant management module is used for storing and modifying basic information of each access merchant and adjusting payment and refund parameters and channels corresponding to the merchant; the third party channel management module is used for managing and configuring third party payment channel service provider information, configuring and adjusting channel payment parameters; the payment receiving and paying management module is used for managing, monitoring and storing aggregated payment and refund records of all merchants; the account checking management module is used for monitoring whether a difference exists between the payment system and the third-party channel, and timely responding to management maintenance personnel when the difference exists;
the interfaces are unified, and the payment modes are unified.
The aggregate payment platform integrates a plurality of payment channels, a plurality of payment scenes and a plurality of payment modes, and all payment modes can be used by each system only by accessing one SDK into the own cash system without searching for payment mechanisms which want to be docked one by one and without repeated docking to integrate complicated payment interfaces.
And meanwhile, main stream payment tools such as WeChat, payment treasures, unionpay cloud payment and the like are supported. The payment link merchants and channels are aggregated, the access technology and communication threshold are reduced, the channel cost is reduced, the payment access is realized conveniently and rapidly, and the operation efficiency of a merchant payment settlement system is improved.
Example two
The embodiment provides a specific payment method. As shown in fig. 2, the payment includes the steps of:
step S1, a user orders;
step S2, initiating pre-payment by an aggregate payment platform;
step S3, judging whether the merchant verification is passed, if so, continuing, and if not, canceling the payment;
s4, inquiring a payment mode supported by the aggregate payment platform;
s5, selecting a payment mode;
step S6, a payment request is initiated;
step S7, as shown in FIG. 3, judging whether the merchant configures a third party account, and if so, requesting a third party channel to initiate payment; if not, ending; judging whether the merchant configures a third party account or not, namely judging the account opened by the merchant at the payment service provider;
step S8, requesting a third party channel to initiate payment;
step S9, judging whether the payment is completed, if so, notifying the business party that the payment is completed, if not, ending the payment when the payment time limit is exceeded and the payment is not successful yet;
step S10, end.
The routing policy generation rules include payment facilitator code, payment means, and payment controls, such as mybank: ALI: app.
Wherein mybank stands for payment facilitator, ALI stands for payment mode (payment treasures), app stands for payment control (payment is used at app end), i.e. the complete logic pays for payment treasures used at app end, and the configured payment facilitator is the internet banking.
The payment mode and the payment control are parameters transmitted from the front end, and the payment service provider configures information for the payment service provider acquired in the step S7.
In step S7, when judging whether the merchant configures the payment facilitator, that is, according to the payment mode and the payment control input by the user, the payment facilitator supported by the merchant is obtained, whether the facilitator account is configured is judged, if so, the payment is initiated, and if not, the payment is ended. According to normal logic, assuming that the matched service provider is a web vendor bank (mybank), the routing rule is mybank: ALI: app.
As shown in fig. 4, the system further includes a reconciliation difference early warning, which specifically includes the following steps:
step A1, downloading statement of account;
step A2, analyzing statement of accounts;
step A3, judging whether the statement is completely analyzed; if yes, continuing, and if not, sending an early warning to the user;
step A4, comparing bill data;
step A5, recording whether the deletion exists or not; if yes, notifying the user, and if not, continuing;
and A6, judging whether the amounts are consistent, if so, ending, finishing checking, and if not, giving an early warning to the user.
As shown in fig. 5, the system further includes an electronic wallet recharging method, and the recharging method includes the following steps:
step B1, a user initiates recharging;
step B2, judging whether the recharging amount exceeds the real authentication limit, if so, judging whether the user completes the real authentication; if not, judging whether the balance of the user exceeds the regulation limit;
step B3, judging whether the user completes the authentication of the real person, if so, judging whether the balance of the user exceeds the regulation limit, and if not, requiring the user to complete the authentication of the real person;
and B4, judging whether the balance of the user exceeds the regulation limit, if so, exiting, and if not, selecting online payment to finish recharging.
As shown in fig. 6, the system further includes an electronic wallet cancellation method including the steps of:
step C1, judging whether an account of a user is frozen; if yes, thawing the account is needed; if not, the user inputs a password or a verification code to verify the account;
step C2, checking whether the user password or the verification code is correct, if so, continuing, and if not, judging whether the error times exceed the limit; if the limit is exceeded, temporarily freezing the account number of the user, and if the limit is not exceeded, re-inputting a password or a verification code;
step C3, judging whether the verification amount is larger than the balance, if so, continuing, and if not, exiting;
and C4, deducting the verification amount of the user and recording.
Example III
The invention is characterized in that:
as shown in fig. 1, the present invention discloses an aggregate paymate, which includes: the system comprises an electronic wallet module, a merchant management module, a third party channel management module, a payment/refund management module and an account checking management module. The merchant management module is used for storing and modifying basic information of each access merchant and adjusting payment/refund parameters and channels corresponding to the merchants; the third party channel management module is used for managing and configuring third party payment channel service provider information, configuring and adjusting channel payment parameters; the payment/refund management module is used for managing, monitoring and storing aggregated payment and refund records of all merchants; the account checking management module is used for monitoring whether the payment system and the third-party channel have differences, and can timely respond to management maintenance personnel when the differences exist.
The electronic purse pre-charge verification is shown in figure 6.
The electronic wallet pre-charging verification and verification support APP, payment code, webpage and other multi-mode verification and verification. The verification interfaces are accessed by the aggregation platform in a unified way, so that the extra workload of an access party is not increased.
The pre-recharging and recharging logic of the electronic wallet is shown in fig. 6.
And (3) unified fusion of interfaces:
the business system is accessed to the aggregate payment platform to be unified in interface, only online and offline payment scenes are needed to be distinguished, and the payment mode finally used by the user is not needed to be concerned (the selection and adaptation of the payment mode are provided by the aggregate payment platform); the interface refers to public parameters of payment modes and capabilities of WeChat, payment treasures, cloud flash payment, four major lines and the like, and provides a set of indiscriminate unified payment access interface through inclusion integration.
The payment mode is unified:
the front-end page is accessed to the aggregate payment platform interface uniformly, parameters only need to be accessed according to the official front-end interfaces of the payment modes such as WeChat, payment treasures, cloud flash payment and the like, and channels used by the aggregate payment platform do not need to be considered. The aggregate payment platform integrates the response parameter differences of all channels, and front-end official parameters are adapted according to all payment modes, so that the front-end access technology and time cost are reduced.
The specific flow of the user from ordering to completing payment is as shown in fig. 2:
merchant management and payment channel routing policies:
the business system applies for accessing the aggregate payment platform, the platform can create a main merchant and a pair of appKey and appSecret according to the application, and the back end needs to use the appSecret for data signature in a subsequent series of interactions. Sub-merchants can be created under the main merchant according to different business requirements, and each sub-merchant has independent collection capability or inherited parent collection capability. The merchant checkout capability decision logic is as follows:
routing policy generation rules:
as shown in FIG. 3, the aggregate payment platform integrates different payment modes, different three-way channels and different use scenes, so that the back end uses a strategy mode to select a route (a routing rule: a payment scene: a payment mode: a payment channel) in actual payment. Such as: the user selects to use a payment device to initiate payment at the app end, a merchant configures to collect money by using an engineering channel, and related strategies are coded as icbc: ALI: app.
Accounting difference early warning:
as shown in fig. 4, each payment channel has provided a previous day transaction running bill interface, and the aggregate payment platform pulls the statement generated by the third party channel through a timed task and stores the resolved statement in the database. After the data storage is finished, whether the data of the sunset database is consistent with the statement data or not is detected. And comparing whether the aggregate payment platform data and the statement data are different according to the payment and refund respectively (the difference comprises the presence or absence of a payment bill and whether the payment amount is consistent or not), and if the difference exists, sending a nailing message to inform an operation and maintenance personnel to process and verify.
It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.
Finally, it should be noted that: the foregoing description is only a preferred embodiment of the present invention, and the present invention is not limited thereto, but it is to be understood that modifications and equivalents of some of the technical features described in the foregoing embodiments may be made by those skilled in the art, although the present invention has been described in detail with reference to the foregoing embodiments. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (6)
1. An aggregate payment system, characterized by: the system comprises an electronic wallet module, a merchant management module, a third party channel management module, a receipt and payment management module and an account checking management module;
the electronic wallet module comprises payment mode management, payment and refund record management, payment and refund notification retry functions of the aggregate payment system;
the merchant management module is used for storing and modifying basic information of each access merchant and adjusting payment and refund parameters and channels corresponding to the merchant; the third party channel management module is used for managing and configuring third party payment channel service provider information, configuring and adjusting channel payment parameters; the payment receiving and paying management module is used for managing, monitoring and storing aggregated payment and refund records of all merchants; the account checking management module is used for monitoring whether the payment system and the third-party channel have differences, and can timely respond to management maintenance personnel when the differences exist.
2. An aggregate payment method, characterized in that: using the system of claim 1, the payment comprises the steps of:
step S1, a user orders;
step S2, initiating pre-payment by an aggregate payment platform;
step S3, judging whether the merchant state verification is passed or not, if so, continuing, and if not, canceling the payment;
in step S3, the merchant status is the mark of merchant opening or closing in the aggregated payment system; if the merchant state is on, the merchant is effective, namely passing verification; and if the merchant state is closed, the merchant is invalid, i.e. the merchant is not authenticated.
S4, inquiring a payment mode supported by the aggregate payment platform;
step S5, the user selects a payment mode;
step S6, a user initiates a payment request;
step S7, judging whether the merchant configures a third party account, if so, requesting a third party channel to initiate payment; if not, ending;
step S8, requesting a third party channel to initiate payment;
step S9, judging whether the payment is completed, if so, notifying the business party that the payment is completed, if not, ending the payment when the payment time limit is exceeded and the payment is not successful yet;
step S10, end.
3. An aggregated payment method according to claim 2, wherein: the routing policy generation rules include payment facilitator code, payment method, and payment control.
4. An aggregated payment method according to claim 2, wherein: the system also comprises a reconciliation difference early warning, and the reconciliation difference early warning specifically comprises the following steps:
step A1, downloading statement of account;
step A2, analyzing statement of accounts;
step A3, judging whether the statement is completely analyzed; if yes, continuing, and if not, sending an early warning to the user;
step A4, comparing bill data; bill comparison, namely, comparing daily payment data of the aggregate payment platform with daily bill data of each payment service provider; the comparison content comprises: a payment facilitator merchant number, a payment amount; the comparison association condition is that the payment single numbers are consistent; if the aggregate payment platform bill exists, the payment service provider bill does not exist, and the aggregate payment platform bill is recorded as a multi-account; if the aggregate payment platform bill does not exist, the payment service provider bill exists, and the aggregate payment platform bill is recorded as a short account; if the amounts are different, recording that the amounts are inconsistent;
step A5, judging whether the record has a defect or not; if yes, notifying the user, and if not, continuing;
and A6, judging whether the amounts are consistent, if so, ending, finishing checking, and if not, giving an early warning to the user.
5. An aggregated payment method according to claim 2, wherein: the system also comprises an electronic wallet recharging method, and the recharging method comprises the following steps:
step B1, a user initiates recharging;
step B2, judging whether the recharging amount exceeds the real authentication limit, if so, judging whether the user completes the real authentication; if not, judging whether the balance of the user exceeds the regulation limit;
step B3, judging whether the user completes the authentication of the real person, if so, judging whether the balance of the user exceeds the regulation limit, and if not, requiring the user to complete the authentication of the real person;
and B4, judging whether the balance of the user exceeds the regulation limit, if so, exiting, and if not, selecting online payment to finish recharging.
6. An aggregated payment method according to claim 2, wherein: the system also comprises an electronic wallet accounting method, which comprises the following steps:
step C1, judging whether an account of a user is frozen; if yes, thawing the account is needed; if not, the user inputs a password or a verification code to verify the account;
step C2, checking whether the user password or the verification code is correct, if so, continuing, and if not, judging whether the error times exceed the limit; if the limit is exceeded, temporarily freezing the account number of the user, and if the limit is not exceeded, re-inputting a password or a verification code;
step C3, judging whether the verification amount is larger than the balance, if so, continuing, and if not, exiting;
and C4, deducting the verification amount of the user and recording.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310978635.8A CN116934311A (en) | 2023-08-04 | 2023-08-04 | Aggregate payment system and payment method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310978635.8A CN116934311A (en) | 2023-08-04 | 2023-08-04 | Aggregate payment system and payment method |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116934311A true CN116934311A (en) | 2023-10-24 |
Family
ID=88377182
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310978635.8A Pending CN116934311A (en) | 2023-08-04 | 2023-08-04 | Aggregate payment system and payment method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116934311A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117952606A (en) * | 2024-03-22 | 2024-04-30 | 杭州有云科技有限公司 | Aggregation payment method, device, equipment and storage medium based on security evaluation |
-
2023
- 2023-08-04 CN CN202310978635.8A patent/CN116934311A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117952606A (en) * | 2024-03-22 | 2024-04-30 | 杭州有云科技有限公司 | Aggregation payment method, device, equipment and storage medium based on security evaluation |
| CN117952606B (en) * | 2024-03-22 | 2024-06-11 | 杭州有云科技有限公司 | Aggregation payment method, device, equipment and storage medium based on security evaluation |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11531977B2 (en) | System and method for paying a merchant by a registered user using a cellular telephone account | |
| US7848736B2 (en) | Package billing for micro-transactions | |
| US7640212B2 (en) | Methods and systems for executing a plurality of money transfers having a fluctuating parameter | |
| KR101524957B1 (en) | Systems and methods for the payment of customer bills utilizing payment platform of biller | |
| US8738518B2 (en) | Methods and systems for executing a plurality of money transfers having a fluctuating parameter | |
| KR101961899B1 (en) | Method for providing auto-payment service considering exchange rate between virtual and flat money | |
| US20070005467A1 (en) | System and method for carrying out a financial transaction | |
| US20100191622A1 (en) | Distributed Transaction layer | |
| US20110196797A1 (en) | Wireless payment and barter platform | |
| US20090259576A1 (en) | Transaction processing with core and distributor processor implementations | |
| US20190318354A1 (en) | Secure electronic billing with real-time funds availability | |
| US20170300881A1 (en) | Secure electronic billing and collection with real-time funds availability | |
| WO2007084593A2 (en) | Package billing for micro-transactions | |
| US20030014362A1 (en) | System for managing inter-company settlement and the method therefor | |
| CN116934311A (en) | Aggregate payment system and payment method | |
| WO2009065278A1 (en) | System and method for realizing personal electronic check card | |
| KR20060093575A (en) | Method for settling using a portable phone | |
| CN105474244A (en) | Payment unification service | |
| US20030041024A1 (en) | System for managing inter-company settlement and the method therefor | |
| CN115879951A (en) | Polymerization payment platform | |
| JP2001297286A (en) | Authentication system | |
| KR20100107366A (en) | System and method for managing medical expenses settlement by installments using phone bill and recording medium | |
| WO2007049858A1 (en) | Pc-cafe direct payment system, and a method for the same | |
| KR20090081927A (en) | System and Method for Processing Card Settlement Approval Relay and Recording Medium | |
| JP2001283131A (en) | Price settlement substituting system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |