CN116777543A - Aggregate payment method and system supporting support and verification integration - Google Patents
Aggregate payment method and system supporting support and verification integration Download PDFInfo
- Publication number
- CN116777543A CN116777543A CN202211709584.0A CN202211709584A CN116777543A CN 116777543 A CN116777543 A CN 116777543A CN 202211709584 A CN202211709584 A CN 202211709584A CN 116777543 A CN116777543 A CN 116777543A
- Authority
- CN
- China
- Prior art keywords
- payment
- information
- refund
- asset
- merchant
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 30
- 230000010354 integration Effects 0.000 title claims abstract description 17
- 238000012795 verification Methods 0.000 title claims description 19
- 238000004891 communication Methods 0.000 claims description 13
- 238000003032 molecular docking Methods 0.000 claims description 6
- 230000006798 recombination Effects 0.000 claims description 6
- 238000005215 recombination Methods 0.000 claims description 6
- 238000004806 packaging method and process Methods 0.000 claims description 4
- 229910052709 silver Inorganic materials 0.000 abstract 1
- 230000002776 aggregation Effects 0.000 description 6
- 238000004220 aggregation Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 4
- 238000012423 maintenance Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 101150096185 PAAS gene Proteins 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
-
- 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
-
- 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
- G06Q30/00—Commerce
- G06Q30/01—Customer relationship services
- G06Q30/015—Providing customer assistance, e.g. assisting a customer within a business location or via helpdesk
- G06Q30/016—After-sales
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Computer Security & Cryptography (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application discloses an aggregate payment method and system supporting support and core integration, wherein the method comprises the following steps: s1, receiving an order request initiated by a user aiming at a merchant; s2, inquiring member asset information of the user, caching the member asset information and returning a cash register link address to a merchant; s3, forming order information, caching the order information by unifying the order information and returning a link address of the reclaimed silver center to the merchant; s4, receiving a payment request initiated by a user, and calling a unified ordering interface after the cashier desk plug-in unit assembles the acquired payment channels, member asset information and cached order information, and calling a third party cashier desk to finish payment after the payment of all asset channels is successful; s5, the payment of all channels is successful, and the order state is updated. The application can provide a unified set of payment interfaces to the outside, and merchants can access the payment function at one time no matter what payment channel is used by the payment user, and freely use a plurality of payment channels to efficiently and rapidly complete transaction business on line and off line.
Description
Technical Field
The application relates to the technical field of computer application, in particular to an aggregate payment method and system supporting a support and a core integration.
Background
Aggregate payment: the integrated payment is referred to as "payment service" except for "payment, settlement and clearing" service, and depends on a bank, a non-banking institution or a clearing organization, and by means of the payment channel and clearing capability of the bank, the non-banking institution or the clearing organization, the payment services of more than one bank, the non-banking institution or the clearing organization are integrated together by utilizing the self technology and service integration capability, so as to provide service contents including but not limited to "payment channel service", "integrated reconciliation service", "technical docking service", "error handling service", "financial service guide", "membership account service", "operation flow software service", "operation maintenance service", "terminal providing and maintenance" for merchants, thereby reducing cost expenditure faced when the merchants access and maintenance payment settlement service, improving the operation efficiency of the merchant payment settlement system, and collecting payment services of value added income.
The aggregate payment system is a network payment settlement system interposed between a bank and a user, and an internet third party payment company (e.g., a payment treasure, a WeChat, etc.) who approves and issues a payment license plate carries a service. The third party payment company distributes retail traffic to fourth party payment company operations, also known as aggregate payments. For example, payment interfaces such as a payment precious scan code, a WeChat scan code, a QQ wallet, a Unionpay shortcut, gateway payment, and Beijing east payment are accessed into an aggregate payment system, and then the aggregate payment system re-unifies the interfaces and is used for the clients. No matter how the upstream party changes the channel, the customer does not need to follow the change, and the customer can access the aggregate payment interface for life only once.
However, in the course of payments commonly used today, the following is often the case: the user uses different third party application software on the device to scan the code, so that a merchant needs to present the two-dimensional code corresponding to the third party application software used by the user; the payee needs to check whether the payment is successful or not to the corresponding account; particularly, in the case that a merchant provides a specific kind of two-dimensional code, a user can only adopt third party application software which is in butt joint with an issuer of the two-dimensional code to conduct code scanning payment, so that user experience is poor, and even payment failure is possibly caused. Moreover, during the payment process, the system needs to frequently acquire order information associated with the transaction order from the merchant, resulting in a large amount of signaling consumption among the merchant, the user, the system and the acquirer.
Disclosure of Invention
At present, the problem of complex operation exists in the daily transaction process that different card and ticket system interfaces need to be docked.
In order to solve the technical problems, one aspect of the application discloses an aggregate payment method supporting support and core integration, which comprises the following steps:
s1, receiving an order request initiated by a user aiming at a merchant;
s2, inquiring member asset information of the user, caching the member asset information, and returning a cash register link address to the merchant;
s3, associating member asset information with order parameters to form order information, caching the order information through unified ordering and returning a link address of a recovery center platform to the merchant;
s4, receiving a payment request initiated by a user, calling a cash desk plug-in by the merchant, assembling the acquired payment channel, member asset information and cached order information by the cash desk plug-in, calling a unified ordering interface, sequentially uploading asset channels according to an asset verification rule, and calling a third party cash desk to complete payment after the payment of all asset channels is successful;
s5, the payment of all channels is successful, and the order state is updated.
According to an embodiment of the present application, the step S4 further includes the steps of: and the merchant interfaces in the form of calling the API, assembles the payment channel, the asset channel and the order information, and then calls the uniform ordering interface to pre-order.
According to an embodiment of the application, the application further comprises the steps of:
s6, the user initiates refund aiming at the merchant, and the server receives the refund request and sends the refund request to the cashier center;
s7, caching order information and marking refunds;
s8, assembling a refund mode by the cashier center, receiving refund results, and receiving refund;
and S9, packaging refund results, updating order information and finishing verification and marketing.
According to an embodiment of the present application, the step S8 further includes the steps of:
s81, the cashier center initiates a refund request to the asset server, and the asset server performs asset verification refund and returns refund results;
s82: the cashier platform initiates a refund request to the three-party payment channel end, the three-party payment channel end assembles refund parameters, refunds the refund, and returns refund results.
According to an embodiment of the present application, the payments in step S4 include an on-line aggregated payment and an off-line aggregated payment.
The offline aggregate payment is carried out by the following steps:
a scanned payment request;
finding a contracted company ID according to the store ID;
finding a code BIN packet route according to the code BIN;
reading a payment channel code of a current code BIN packet route;
if the payment account number is not configured, the payment channel codes and types corresponding to the grouping are sent to the asset channel in a transaction mode; if a payment account is configured, a payment mode code is found according to an APPID, a payment scene code and a recombination payment channel which are distributed to the store by a system, the payment mode configuration is obtained according to the payment mode code, and if the payment account is settled to a headquarter, a payment account record id is found, the collection information and key information corresponding to the account can be found; if the settlement is to the contracted company, the corresponding receipts account number and the key information are found according to the group id and the contracted company id.
The online aggregate payment is carried out by the following steps:
sending out an online payment request;
finding a contracted company ID according to the store ID;
finding a payment mode code according to the APPID, the payment scene code and the recombination payment channel distributed to the store by the system;
acquiring payment mode configuration information according to the payment mode code;
if the payment is settled to the headquarter, finding the record id of the payment account, and finding the corresponding collection information and key information of the account; if the settlement is to the contracted company, the corresponding receipts account number and the key information are found according to the group id and the contracted company id.
Another aspect of the present application also provides an aggregate payment system based on a cashier's desk system, including: the receiving module is suitable for receiving an order request initiated by a user aiming at a merchant; receiving payment and refund requests initiated by a user; the acquisition module is suitable for acquiring an order information list comprising member asset information and a payment channel list; the payment mode configuration module is suitable for finding a payment mode code according to the acquired order list and the payment channel list and determining payment mode configuration; and the payment verification module is suitable for finishing payment and refund verification according to the information for determining the payment mode configuration.
A third aspect of the present application also provides a computing device comprising: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface are communicated with each other through the communication bus; the memory is used for storing at least one executable instruction, the executable instructions cause the processor to perform operations corresponding to the aggregated payment method supporting a core unification as described above.
The present application also provides a computer storage medium having at least one executable instruction stored therein, the executable instructions cause the processor to perform operations corresponding to the aggregated payment method supporting the support of the core unification as described above.
According to an embodiment of the present application, the member asset information includes, but is not limited to, electronic coupons, cash cards, stored value cards, member scores, and the like.
Compared with the prior art, the technical scheme of the application has the beneficial effects that:
1. the application utilizes the aggregation capability of the cashing center to integrate the user private domain assets (cash card, electronic ticket, member points, stored value account balance) and the third party payment channel, abstracts the unified aggregate payment interface, adopts the aggregate payment interface to realize payment verification integration, reduces the docking cost of the docking party and realizes quick access; the aggregation of single asset channels is realized, and the pure asset consumption of multiple assets is supported; the multi-asset and payment channel aggregation is realized, and the consumption and payment channel payment of multiple asset channels are supported.
2. The application satisfies that the user only needs to dock once, can realize full channel access, can more efficiently and quickly realize the payment task, and avoids that certain merchants cannot pay by using other third party payment platforms under the condition that certain merchants only have specific types of two-dimension codes.
3. The transaction merchant accesses the payment function once, and can freely use a plurality of payment channels;
4. when the current payment channel can not meet the requirements of transaction merchants, a new payment channel can be quickly accessed without affecting the accessed payment;
5. some of the payment channels are unstable, other payment channels are not affected, transaction merchants cannot perceive the payment problem, and transaction business can be efficiently and rapidly completed on line and off line.
Drawings
FIG. 1 is a schematic flow chart of an aggregate payment method according to an embodiment of the present application;
FIG. 2 is a flow chart of an on-line and off-line aggregated payment according to an embodiment of the application;
FIG. 3 is a timing diagram of a refund initiation according to an embodiment of the present application;
FIG. 4 is a flow chart of a merchant opening aggregated payment according to an embodiment of the application.
The specific embodiment is as follows:
the application will be further described with reference to the drawings and the specific examples. The following examples are illustrative of the application and are not intended to limit the scope of the application.
The aggregate payment is a technology of integrating payment capabilities (payment treasures payment, weChat payment, unionpay cloud flash payment and the like) of a third party payment mechanism, and packaging the integrated payment into a unified payment interface or packaging an SDK. In short, aggregate payment does not require funds clearing, but is personalized and customized according to the needs of merchants, and provides various derivative services based on payment. Aggregate payments can be categorized into online and offline types, depending on the service object. The online aggregated network payment integrates various payment modes (gateway, weChat, payment treasures and the like) on own platform, such as a cash register of each e-commerce platform; the off-line is the aggregate payment receipt, and the receipt of different payment modes is collected in one two-dimensional code or one terminal, and is mainly used for the service of a physical store. Offline aggregate payments also include a transaction that can be made in combination with multiple asset channels and one payment channel.
Aggregate payment: multiple payment capabilities are integrated together for payment.
Channel: a bank or a third party payment mechanism providing payment capabilities.
Asset channel: means for generating, consuming or verifying electronic coupons, cash cards, stored value cards, membership points, and the like are provided.
The payment is completed by secondarily aggregating the aggregated payment channels and the asset channels, namely, one payment order is paid by combining a plurality of asset channels and a certain payment channel. Comprises an on-line support core integrated body and an off-line support core integrated body.
Referring to fig. 1, there is shown a schematic flow chart of an aggregated payment method supporting a core integration according to an embodiment of the application.
First, in step S1, a user, typically a consumer making consumer payments using a mobile device, places an order to a merchant that the system interfaces with. And the system receives transaction order information of the current order, and corresponding merchant information is obtained from the system according to the transaction order information.
In this embodiment, as shown in fig. 4, the docked merchant refers to an on-network merchant that opens the tenant and the application, and the merchant needs to maintain the infrastructure architecture through BD first: branding, contracting company, merchant. As shown in the figure, the specific flow of the merchant network access and aggregated payment is as follows: 1) Tenant and application opening: according to business scenes of merchants, managing and opening corresponding business scene applications after the PAAS system merchants; 2) The payment scene is opened: under this application, the corresponding payment scenario is opened. 3) And (3) payment mode configuration: editing the payment method to be used and associating the payment account number 4) the payment method configuration is completed: after the storage, the payment method under the application is associated with the payment account. When the payment account numbers are associated, if the payment account number records are not configured, performing payment account number management of tenant post-management and operation post-management; if the payment account records are configured, the payment account record ID is associated with the headquarter after settlement, the payment account group ID is associated with the contracted company after settlement, and finally, an application associated payment account list is formed in a unified mode.
In step S2, according to the transaction order information, member asset information of the user is obtained, the member asset information is cached and returned to a cash register link address to a merchant;
in step S3, the member asset information and the order parameters are associated to form order information, the order information is cached by unifying the order information, and the link address of the recovery center platform is returned to the merchant;
s4, receiving a payment request initiated by a user, calling a cash desk plug-in unit by a merchant, assembling the acquired payment channels, member asset information and cached order information by the cash desk plug-in unit, calling a unified ordering interface, uploading asset channels according to an asset verification rule sequence, and calling a third-party cash desk to complete payment after the payment of all asset channels is successful;
in this embodiment, step S4 further includes the following steps: and the merchant interfaces in the form of calling the API, assembles the payment channel, the asset channel and the order information, and then calls the uniform ordering interface to pre-order.
S5, the payment of all channels is successful, and the order state is updated.
In this embodiment, the member asset information includes, but is not limited to: cash cards, electronic coupons, membership points, and stored value account balances. A link address targeting request is sent by the user side or merchant side to the proxy service and then processed by the proxy service. Specifically, the step of generating link address information is performed in the proxy service, and then the link address information is transmitted to the merchant. The merchant sends, for example, a checkout page to the proxy service, which in turn sends the page to the third party application for subsequent payment steps.
Fig. 3 is a refund timing diagram of an aggregated payment method according to an embodiment of the application. In another embodiment of the present application, during the transaction, the aggregate payment server may determine the corresponding payment channel according to the user information and the order information, then call the corresponding payment interface, and then collect and refund operations each use the payment interface provided by the payment channel. In order to facilitate an understanding of the present application, aggregate payment order initiation refund/withdrawal will now be described in its entirety with reference to fig. 3. Firstly, in step S6, a user initiates refund to a merchant, a server receives a refund request, and sends the refund request to a cashier desk through a gateway; then in step S7, through idempotent examination of the cashier station, the order information of the refund is initiated by caching, and the refund is marked; in step S8, the cashier station performs the assembly of refund mode, receives refund result; finally, in step S9, the refund result is packaged, the order information is updated, and verification are completed.
In this embodiment, step S8 further includes the steps of: s81, the cashier center initiates a refund request to the asset server, and the asset server performs asset verification refund and returns refund results; s82: the cashier platform initiates a refund request to the three-party payment channel end, the three-party payment channel end assembles refund parameters, refunds the refund, and returns refund results. The aggregated payment order initiates refund/withdrawal, so long as one channel refund/withdrawal fails, other channels continue refund/withdrawal according to the anti-transaction sequence of the assets, all channels take refund results, package refund results and update the anti-transaction order state.
In this embodiment, referring to fig. 2, the payments include an on-line aggregate payment and an off-line aggregate payment. The aggregate payment method provided in this embodiment will be described below with reference to specific examples.
The offline aggregate payment is carried out by the following steps: the scanned payment request receives data content carried by a transaction request of a transaction merchant, for example, the data content comprises: parameters such as door store number, APPID, payment scene (e.g. sweep code and face), payment code, merchant order number, user payment code, order amount, cashier's desk version number and package name;
finding a contracted company ID according to the store ID; finding a code BIN packet route according to the code BIN; reading a payment channel code of a current code BIN packet route; if the payment account number is not configured, the payment channel codes and types corresponding to the grouping are sent to the asset channel in a transaction mode; if a payment account is configured, a payment mode code is found according to an APPID, a payment scene code and a recombination payment channel which are distributed to the store by a system, the payment mode configuration is obtained according to the payment mode code, and if the payment account is settled to a headquarter, a payment account record id is found, the collection information and key information corresponding to the account can be found; if the settlement is to the contracted company, the corresponding receipts account number and the key information are found according to the group id and the contracted company id.
The online aggregate payment is carried out by the following steps:
an online payment request is sent, and data content carried by a transaction request of a transaction merchant is received, wherein the data content comprises: parameters such as door store number, APPID, payment scene (e.g. scan code and face), payment code, merchant order number, user ID, payment field channel, etc.; finding a contracted company ID according to the store ID; finding a payment mode code according to APPID, payment scene code and recombination payment channel distributed to a store by the system; acquiring payment mode configuration information according to the payment mode code; if the payment is settled to the headquarter, finding the record id of the payment account, and finding the corresponding collection information and key information of the account; if the settlement is to the contracted company, the corresponding receipts account number and the key information are found according to the group id and the contracted company id.
Thus, in the payment process, the transaction merchant does not need to pay attention to the fact that the payer uses the payment device and the WeChat
The payment system is a Unionpay, and the aggregate payment system can judge according to payment channels, payment mode codes and the like reported by transaction merchants. And acquiring payment mode configuration information according to the payment mode codes, confirming the used payment channel, and finally sending the transaction request to the corresponding payment channel to finally finish the payment collection flow.
Specifically, the aggregate payment method of the application is applied to Haphda order applet aggregate payment, singapore fresh4all aggregate payment and the like
The second aspect of the application discloses an aggregate payment system based on a cashier's desk system, comprising: the receiving module is suitable for receiving an order request initiated by a user aiming at a merchant; receiving payment and refund requests initiated by a user; the acquisition module is suitable for acquiring an order information list comprising member asset information and a payment channel list; the payment mode configuration module is suitable for finding a payment mode code according to the acquired order list and the payment channel list and determining payment mode configuration; and the payment verification module is suitable for finishing payment and refund verification according to the information for determining the payment mode configuration.
A third aspect of the application discloses a computing device comprising: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface are communicated with each other through the communication bus; the memory is used for storing at least one executable instruction, the executable instructions cause the processor to perform operations corresponding to the aggregated payment method supporting the support of the core unification as described above.
In a fourth aspect of the present application, a computer storage medium is disclosed, in which at least one executable instruction is stored, where the executable instruction causes a processor to perform operations corresponding to the aggregated payment method supporting a core integration as described above.
The computer device 4 may be a desktop computer, a notebook computer, a palm computer, a cloud server, or the like
And (5) preparing. The computer device 4 may perform man-machine interaction with a user through a keyboard, a mouse, a remote controller, a touch pad, or a voice control device.
The memory comprises at least one type of readable storage medium including non-volatile memory or volatile memory, e.g., flash memory, hard disk, multimedia card, card memory (e.g., SD or DX memory)
Etc.), RAM, ROM, EPROM, EEPROM, PROM, magnetic memory, magnetic disk, optical disk, etc., which may include static RAM or dynamic RAM. In some embodiments, the storage 41 may be an internal storage unit of the computer device 4, for example, a hard disk or a memory of the computer device 4. In other embodiments, the memory may also be an external storage device of the computer device, for example, a plug-in hard disk, SMC, SD card, flash memory card, etc. provided on the computer device 4. In some examples, the memory may further comprise memory remotely located with respect to the computer device, the remote memory being connectable to the computer device via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof. In this embodiment, the memory is typically used to store an operating system and various types of application software installed on the computer device, such as program code for performing management methods for aggregate payments, and the like, and the processor executes these code. In addition, the memory may be used to temporarily store various types of data that have been output or are to be output.
In embodiments of the present application, the processor 42 may be a CPU, controller, microcontroller, microprocessor, or the like
And a data processing chip. The processor 42 may also be other general purpose processors, DSP, ASIC, FPGA or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like.
In summary, the technical scheme of the application has the following beneficial effects:
1. the application utilizes the aggregation capability of the cashing center to integrate the user private domain assets (cash card, electronic ticket, member points, stored value account balance) and the third party payment channel, abstracts the unified aggregate payment interface, adopts the aggregate payment interface to realize payment verification integration, reduces the docking cost of the docking party and realizes quick access; the aggregation of single asset channels is realized, and the pure asset consumption of multiple assets is supported; the multi-asset and payment channel aggregation is realized, and the consumption and payment channel payment of multiple asset channels are supported.
2. The application supports the payment of various third party payment platforms, satisfies that users only need to dock once, can realize full channel access, can realize the payment task more efficiently and quickly, and avoids that certain merchants cannot use other third party payment platforms to pay under the condition that only certain types of two-dimension codes are available.
3. The transaction merchant accesses the payment function once, and can freely use a plurality of payment channels.
4. When the current payment channel cannot meet the requirements of transaction merchants, a new payment channel can be quickly accessed without affecting the accessed payment.
5. Some of the payment channels are unstable, other payment channels are not affected, transaction merchants cannot perceive the payment problem, and transaction business can be efficiently and rapidly completed on line and off line.
The foregoing is merely illustrative of the preferred embodiments of the present application and is not intended to limit the embodiments and scope of the present application, and it should be appreciated by those skilled in the art that equivalent substitutions and obvious variations may be made using the description and illustrations of the present application, and are intended to be included in the scope of the present application.
Claims (10)
1. An aggregate payment method supporting a support and a core integration is characterized by comprising the following steps:
s1, receiving an order request initiated by a user aiming at a merchant;
s2, inquiring member asset information of the user, caching the member asset information, and returning a cash register link address to the merchant;
s3, associating the member asset information with order parameters to form order information, caching the order information through unified ordering and returning a link address of a recovery center platform to the merchant;
s4, receiving a payment request initiated by a user, calling a cash desk plug-in by the merchant, assembling the acquired payment channels, member asset information and cached order information by the cash desk plug-in, calling a unified ordering interface, uploading asset channels according to an asset verification rule sequence, and calling a third party cash desk to finish payment after the payment of all asset channels is successful;
s5, the payment of all channels is successful, and the order state is updated.
2. The aggregate payment method supporting a core integration according to claim 1, wherein the step S4 further comprises the steps of: and the merchant interfaces in the form of calling an API, assembles the payment channel, the asset channel and the order information, and then calls the uniform ordering interface to pre-order.
3. The aggregate payment method supporting a core integration according to claim 1, further comprising the steps of:
s6, the user initiates refund aiming at the merchant, and the server receives the refund request and sends the refund request to the cashier center;
s7, caching the order information and marking refunds;
s8, assembling a refund mode by the cashier center, receiving refund results by docking refund;
and S9, packaging refund results, updating the order information and finishing verification and marketing.
4. A method of aggregate payment supporting a core integration according to claim 3, wherein step S8 further comprises the steps of:
s81, the cashier center initiates a refund request to an asset server, and the asset server performs asset verification refund and returns refund results;
s82: and the cashier center initiates a refund request to the three-party payment channel end, and the three-party payment channel end assembles refund parameters, receives refunds and returns refund results.
5. The method of claim 1, wherein the payment in step S4 includes an on-line aggregated payment and an off-line aggregated payment.
6. The aggregate payment method supporting a core integration according to claim 5, wherein the offline aggregate payment is performed by:
a scanned payment request;
finding a contracted company ID according to the store ID;
finding a code BIN packet route according to the code BIN;
reading a payment channel code of a current code BIN packet route;
if the payment account number is not configured, the payment channel codes and types corresponding to the grouping are sent to the asset channel in a transaction mode; if a payment account is configured, a payment mode code is found according to an APPID, a payment scene code and a recombination payment channel which are distributed to the store by a system, the payment mode configuration is obtained according to the payment mode code, and if the payment account is settled to a headquarter, a payment account record id is found, the collection information and key information corresponding to the account can be found; if the settlement is to the contracted company, the corresponding receipts account number and the key information are found according to the group id and the contracted company id.
7. The aggregate payment method supporting a core integration according to claim 5, wherein the online aggregate payment is performed by:
sending out an online payment request;
finding a contracted company ID according to the store ID;
finding a payment mode code according to the APPID, the payment scene code and the recombination payment channel distributed to the store by the system;
acquiring payment mode configuration information according to the payment mode code;
if the payment is settled to the headquarter, finding the record id of the payment account, and finding the corresponding collection information and key information of the account; if the settlement is to the contracted company, the corresponding receipts account number and the key information are found according to the group id and the contracted company id.
8. An aggregate payment system based on a cashier's desk system, comprising:
the receiving module is suitable for receiving an order request initiated by a user aiming at a merchant; receiving payment and refund requests initiated by a user;
the acquisition module is suitable for acquiring an order information list comprising member asset information and a payment channel list;
the payment mode configuration module is suitable for finding a payment mode code according to the acquired order list and the payment channel list and determining payment mode configuration;
and the payment verification module is suitable for finishing payment and refund verification according to the information for determining the payment mode configuration.
9. A computing device, comprising: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete communication with each other through the communication bus;
the memory is configured to store at least one executable instruction, where the executable instruction causes the processor to perform operations corresponding to the aggregated payment method according to any one of claims 1 to 7.
10. A computer storage medium having stored therein at least one executable instruction for causing a processor to perform operations corresponding to the aggregated payment method supporting a core integration as claimed in any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211709584.0A CN116777543A (en) | 2022-12-29 | 2022-12-29 | Aggregate payment method and system supporting support and verification integration |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211709584.0A CN116777543A (en) | 2022-12-29 | 2022-12-29 | Aggregate payment method and system supporting support and verification integration |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116777543A true CN116777543A (en) | 2023-09-19 |
Family
ID=87990314
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211709584.0A Pending CN116777543A (en) | 2022-12-29 | 2022-12-29 | Aggregate payment method and system supporting support and verification integration |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116777543A (en) |
-
2022
- 2022-12-29 CN CN202211709584.0A patent/CN116777543A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11017393B2 (en) | Direct connection systems and methods | |
| US20170364890A1 (en) | System and method of payment of merchants on behalf of payment card system transaction acquirers | |
| US20180197167A1 (en) | System and method for person-to-person payments | |
| US20070005467A1 (en) | System and method for carrying out a financial transaction | |
| US20170004468A1 (en) | Multiple payor bill payments | |
| AU2018206736A1 (en) | Apparatus, method, and computer program for mobile open payment network | |
| US20110055079A1 (en) | Real time accounts payable web service | |
| US11972405B2 (en) | Systems and methods for point of sale deposits | |
| KR101729162B1 (en) | Apparatus, method and computer program for managing advanced payment based on financial open platform | |
| AU2016285425B2 (en) | Electronic incremental payments | |
| US7970673B2 (en) | Method, apparatus, and computer program product for repository data maximization | |
| US20130073462A1 (en) | Processing a Payment Transaction From a Mobile Device | |
| CN111213172A (en) | Accessing ACH transaction functionality through digital wallet | |
| CN115526730A (en) | Method and device for managing equity incentive funds, electronic equipment and storage medium | |
| US10621567B2 (en) | Electronic grace period billing | |
| US20100114760A1 (en) | Online interactive issued account acquired transaction information management | |
| CN116777543A (en) | Aggregate payment method and system supporting support and verification integration | |
| US9047637B1 (en) | Method and system for converting printed checks into pre-paid debit card funds | |
| US20130073461A1 (en) | Processing a Payment Transaction Involving a Merchant Account and a Customer Account Associated with the Same Enterprise |
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 |