CN116362735A

CN116362735A - Payment method and device

Info

Publication number: CN116362735A
Application number: CN202310345811.4A
Authority: CN
Inventors: 张楠; 廖洪; 吴江
Original assignee: Zhejiang eCommerce Bank Co Ltd
Current assignee: Zhejiang eCommerce Bank Co Ltd
Priority date: 2023-03-28
Filing date: 2023-03-28
Publication date: 2023-06-30

Abstract

The embodiment of the specification provides a payment method and a device, wherein the payment method comprises the following steps: receiving an order payment request sent by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated after the first type merchant is registered in the business payment platform; determining target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request; sending the candidate payment mode information and the target transaction information to the client so as to render a payment page; acquiring user input information of a first type merchant in a payment page sent by a client, and determining a target payment mode according to the user input information; and aiming at the target order corresponding to the target order identification, paying to the second type merchant in a target payment mode.

Description

Payment method and device

Technical Field

The present document relates to the field of data processing, and in particular, to a payment method and apparatus.

Background

With the development of electronic technology, electronic payment is increasingly widely applied, and the variety of electronic payment modes is also increasingly abundant. In practical application, a plurality of shops belonging to the same brand often need to regularly purchase raw materials to suppliers designated by the brand, funds of different shops are different, and each shop is likely to respectively transfer money to the suppliers by adopting different electronic payment modes. Brand parties often have financial auditing requirements for a store, which requires the store to provide relevant data for raw material purchase and manually audit the same, and the auditing process is cumbersome and inefficient.

Disclosure of Invention

One or more embodiments of the present specification provide a payment method. The payment method comprises the following steps: receiving an order payment request sent by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered. And determining target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request. And sending the candidate payment mode information and the target transaction information to the client so as to render a payment page. And acquiring user input information of the first type merchant in the payment page, which is sent by the client, and determining a target payment mode according to the user input information. And aiming at the target order, identifying a corresponding target order, and paying to the second type merchant in the target payment mode.

One or more embodiments of the present specification provide a payment device including: a request receiving module configured to receive an order payment request issued by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered. And the information determining module is configured to determine target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request. And the information sending module is configured to send the candidate payment mode information and the target transaction information to the client so as to render a payment page. The mode determining module is configured to acquire user input information of the first type merchant in the payment page, which is sent by the client, and determine a target payment mode according to the user input information. And the order payment module is configured to identify a corresponding target order for the target order and pay the second type merchant in the target payment mode.

One or more embodiments of the present specification provide a payment device including: a processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to: receiving an order payment request sent by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered. And determining target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request. And sending the candidate payment mode information and the target transaction information to the client so as to render a payment page. And acquiring user input information of the first type merchant in the payment page, which is sent by the client, and determining a target payment mode according to the user input information. And aiming at the target order, identifying a corresponding target order, and paying to the second type merchant in the target payment mode.

One or more embodiments of the present specification provide a storage medium storing computer-executable instructions that, when executed by a processor, implement the following: receiving an order payment request sent by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered. And determining target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request. And sending the candidate payment mode information and the target transaction information to the client so as to render a payment page. And acquiring user input information of the first type merchant in the payment page, which is sent by the client, and determining a target payment mode according to the user input information. And aiming at the target order, identifying a corresponding target order, and paying to the second type merchant in the target payment mode.

Drawings

For a clearer description of one or more embodiments of the present description or of the solutions of the prior art, the drawings that are needed in the description of the embodiments or of the prior art will be briefly described below, it being obvious that the drawings in the description that follow are only some of the embodiments described in the present description, from which other drawings can be obtained, without inventive faculty, for a person skilled in the art;

FIG. 1 is a flow diagram of a payment method process provided in one or more embodiments of the present disclosure;

FIG. 2 is a flow diagram of a business paymate workflow provided by one or more embodiments of the present disclosure;

FIG. 3 is a flow diagram of another payment method process provided by one or more embodiments of the present disclosure;

FIG. 4 is a flow diagram of yet another payment method process provided by one or more embodiments of the present disclosure;

FIG. 5 is a business architecture diagram of an industry checkout counter provided in one or more embodiments of the present disclosure;

FIG. 6 is a schematic diagram illustrating a merchant residence process in a business payment platform according to one or more embodiments of the present disclosure;

FIG. 7 is a schematic diagram illustrating an order payment process in a business paymate provided in one or more embodiments of the present disclosure;

FIG. 8 is a schematic diagram of a payment device provided in one or more embodiments of the present disclosure;

fig. 9 is a schematic structural diagram of a payment device according to one or more embodiments of the present disclosure.

Detailed Description

In order to enable a person skilled in the art to better understand the technical solutions in one or more embodiments of the present specification, the technical solutions in one or more embodiments of the present specification will be clearly and completely described below with reference to the drawings in one or more embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one or more embodiments of the present disclosure without inventive effort, are intended to be within the scope of the present disclosure.

An embodiment of a payment method provided in the present specification:

according to the payment method provided by the embodiment, the first type merchant initiating the order payment request is a merchant registered in the business payment platform, a corresponding first merchant identifier is generated after registration, the order and the payment can be associated through the first merchant identifier, business finance is automatically associated, bill verification is conducted on the order by business parties corresponding to the business payment platform, candidate payment mode information corresponding to the order payment request can be determined according to the order payment request carrying the first merchant identifier and the target order identifier, and the first type merchant can flexibly select a target payment mode based on the candidate payment mode information, so that payment is conducted to the second type merchant according to the target order in a target payment mode.

Referring to fig. 1, the payment method provided in this embodiment specifically includes steps S102 to S110. The payment method of fig. 1 may be performed by a payment device. The payment device may be a server-side device, such as a stand-alone physical server, a server cluster, or a cloud server capable of cloud computing, etc.

Step S102, receiving an order payment request sent by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by a first type merchant after the business payment platform is registered.

The first type of merchant may be a merchant that has successfully registered with the business paymate, and the first type of merchant may be a merchant that has a purchase demand. The first type of merchant to purchase may be a real item that is actually present, such as tea, milk, electronics, metal originals, and the like; the merchandise to be purchased may also be virtual items, such as game props, virtual decorative props, and the like; the goods to be purchased may also be services, such as cloud computing services, and the like.

The second type of merchant may be a merchant that has successfully registered with the business paymate, and the second type of merchant may be a merchant that provides goods to the first type of merchant. The goods offered by the second type of merchant may refer to the goods to be purchased by the first type of merchant.

The business payment platform can be a payment platform integrated in a business host platform, and the payment platform can have an aggregate payment function, namely, the payment platform can provide a plurality of different types of electronic payment modes for users.

Illustratively, in a brand supply chain scenario, the business paymate may be a paymate integrated in a business host platform of the brand party, the first type of merchant may be a store under the brand party flag, and the second type of merchant may be a vendor specified by the brand party. Often, stores require periodic raw material purchases to suppliers.

In addition, the first type merchant and the second type merchant may also be two different merchants participating in a transaction, wherein the first type merchant is the payer of the transaction and the second type merchant is the payee of the transaction.

For example, a business paymate may have a plurality of registered successful merchants, where each merchant may act as both a payer of a transaction and a payee of a transaction. For example, in one transaction, merchant 1 is a first type of merchant, i.e., the payer of the one transaction; merchant 2 is the second type of merchant, the payee for the transaction. In another transaction, merchant 2 is the first type of merchant, the payer of the other transaction, and merchant 3 is the second type of merchant, the payee of the other transaction.

And receiving an order payment request sent by the first type merchant to the second type merchant, wherein the order payment request carries a target payment identifier, and the order payment request can be used for requesting a target order corresponding to the target order identifier to pay to the second type merchant.

The target order may be an order for the first type of merchant to purchase a pre-set item from the second type of merchant.

For example, the first type of merchant is store 1 under the flag of milk tea brand M, the second type of merchant is milk provider a designated by milk tea brand M, the preset product may be milk, and the target order may be an order in which store 1 purchases 100kg of milk from milk provider a.

Each order may correspond to an order identification. The target order may correspond to the target order identification.

The order payment request may carry a first merchant identification generated by the first type of merchant after registration with the business payment platform.

After each merchant is successfully registered in the business payment platform, the business payment platform can generate a unique corresponding merchant identification for the merchant. After the first type merchant is successfully registered in the service payment platform, a merchant identifier generated by the service payment platform for the first type merchant can be determined as a first merchant identifier.

In a specific implementation, the payment method further includes: receiving a registration request of a first type merchant for a service payment platform; acquiring registration page information according to the registration request and sending the registration page information to the client so as to render a registration page; acquiring first merchant information input by a first type merchant on a registration page; under the condition that the first merchant information meets the preset registration condition, generating a first merchant identifier, and determining the first merchant identifier as a merchant identifier corresponding to the first type merchant in the service payment platform; and establishing an association relationship between the first merchant information and the first merchant identification.

The registration request of the first type of merchant for the business paymate may be a request for the merchant to camp on the business paymate.

In implementation, after receiving the registration request, the server may obtain the registration page information according to the registration request and send the registration page information to the client.

The client may render a registration page based on the registration page information. The client side can also receive first merchant information input by the first type merchant on the registration page and send the first merchant information to the server side.

The first merchant information may include user identity information corresponding to the first type of merchant, and may further include merchant feature information of the first type of merchant.

Illustratively, the first merchant information includes, but is not limited to: applicant's identity information, merchant name, merchant abbreviation, contact name, contact phone, business type, regional information, candidate payment means information, and so forth.

The candidate payment means information is used to represent candidate payment means that the first merchant information can use in the payment process.

The server may determine whether the first merchant information meets a preset registration requirement. If the preset registration requirement is not met, a first registration request result is generated and returned to the client, wherein the first registration request result is used for notifying the user of registration failure. If the preset registration requirement is met, a first merchant identifier is generated, and the first merchant identifier is determined to be a merchant identifier corresponding to the first type merchant in the business payment platform; establishing an association relationship between first merchant information and a first merchant identifier; and generating a second registration request result and returning the second registration request result to the client, wherein the second registration request result is used for notifying the user that the registration is successful.

For example, the first merchant information may include regional information, and whether the first merchant information satisfies the preset registration requirement may be determined by: judging whether the place corresponding to the region information is positioned in the appointed region range or not; if yes, determining that the first merchant information meets the preset registration requirement; if not, determining that the first merchant information does not meet the preset registration requirement.

For another example, the first merchant information may include a business type of the first type of merchant, and whether the first merchant information meets the preset registration requirement may be determined by: judging whether the business type of the first type merchant is one of a preset business type set; if yes, determining that the first merchant information meets the preset registration requirement; if not, determining that the first merchant information does not meet the preset registration requirement.

For the same technical idea, the payment method further comprises: receiving a registration request of a second type merchant for a service payment platform; acquiring registration page information according to the registration request and sending the registration page information to the client so as to render a registration page; acquiring second merchant information input by a second type merchant on a registration page; under the condition that the second merchant information meets the preset registration condition, generating a second merchant identifier, and determining the second merchant identifier as a merchant identifier corresponding to the second type merchant on the business payment platform; and establishing an association relationship between the second merchant information and the second merchant identification.

For example, in a brand supply chain scenario, both a store and a provider may register with a business payment platform, and in the event of successful registration, the server may generate a corresponding merchant identification for the store or provider. Then, the server may establish an association between the merchant identification of the store and the merchant information, or establish an association between the merchant identification of the provider and the merchant information.

In practical applications, the service host platform may be a client of the brand party, or may be a website of the brand party. The business payment platform can be an applet integrated in a client of a brand party, can be another client, and can also be a preset webpage. The jump from the business host platform to the business payment platform can be through code scanning or linking.

For example, the business host platform is a client 1, the business payment platform is an applet 1 integrated in the client 1, the client 1 displays a jump link, the client 1 receives input of a first type merchant for the jump link, and jumps to the applet 1 according to the input.

For another example, the service host platform is website 1, the service payment platform is webpage 1, and webpage 2 of website 1 is displayed with a two-dimensional code for page skip, and the first type merchant performs a code scanning operation on the two-dimensional code, so that webpage 2 skips to webpage 1.

In a specific implementation, the payment method further includes: receiving a registration request of a first type merchant for a service payment platform; the registration request carries a business merchant identifier which is pre-distributed by a business main platform for a first type merchant; acquiring registration page information according to the registration request and sending the registration page information to the client so as to render a registration page; acquiring first merchant information input by a first type merchant on a registration page; under the condition that the first merchant information meets the preset registration condition, generating a first merchant identifier, and determining the first merchant identifier as a merchant identifier corresponding to the first type merchant in the service payment platform; establishing an association relationship between the business merchant identification and the first merchant identification, and establishing an association relationship between the first merchant information and the first merchant identification; and sending the association relation between the business merchant identification and the first merchant identification to the business main platform.

The business host platform may have multiple types of business and the business host platform and the business payment platform may use different identities to determine uniquely corresponding merchants.

When a first type merchant registers a service payment platform, a server side can receive a registration request of the first type merchant for the service payment platform; the registration request carries a business merchant identifier which is pre-allocated by the business master platform for the first type merchant. The business merchant identification may be an identification assigned by the business host platform to the first type merchant after registration of the business host platform by the first type merchant. The business main platform can store the association relation between business merchant identifications and each registered merchant, and can determine the unique corresponding merchant through the business merchant identifications.

And acquiring the registration page information according to the registration request and sending the registration page information to the client. And the client renders the registration page according to the registration page information. And the client receives first merchant information input by the first type merchant on the registration page and sends the first merchant information to the server. And the server generates a first merchant identifier under the condition that the first merchant information meets the preset registration condition, and determines the first merchant identifier as a merchant identifier corresponding to the first type merchant in the business payment platform.

The server may establish an association between the business merchant identifier and the first merchant identifier, and establish an association between the first merchant information and the first merchant identifier.

When the service end sends the corresponding relation between the business merchant identifier and the first merchant identifier to the business main platform, and in the specific implementation, the service end of the business payment platform can send the corresponding relation between the business merchant identifier and the first merchant identifier to the service end of the business main platform under the condition that the service ends of the business main platform and the business payment platform are two different service ends.

By establishing the corresponding relation between the business merchant identification and the first merchant identification, the business party corresponding to the business main platform can inquire the first merchant information, transaction information, order payment flow record and the like of the first type merchant in the business payment platform according to the business merchant identification.

In a specific implementation, before receiving an order payment request sent by the first type merchant to the second type merchant, the payment method further includes: receiving a transaction order establishment request sent by a first type merchant to a second type merchant; the transaction order establishment request carries target transaction information; generating a corresponding target order mark according to the transaction order establishment request; and establishing a corresponding relation between the target order mark and the target transaction information.

The server may receive a transaction order establishment request sent by the first type merchant to the second type merchant, where the transaction order establishment request carries target transaction information, where the target transaction information may be information describing a transaction between the first type merchant and the second type merchant, and the target transaction information includes, but is not limited to: the first merchant identification, the second merchant identification, the type of merchandise the first type of merchant desires to purchase with the second type of merchant, the quantity of merchandise, the unit price of the merchandise, the total price of the merchandise, and discount information, among others.

For example, a first type of business is store 1 of milk tea brand a, a second type of business is milk provider 1, store 1 expects to purchase from the milk provider X pieces of packaged pure milk of a specified brand specified capacity, the packaged pure milk having a unit price of K, and the total price of X packaged pure milk pieces of K. X may be a natural number greater than 1. K and K may be real numbers greater than 0.

The server side can generate a target order identifier corresponding to the transaction order establishment request for the current transaction of the first type merchant and the second type merchant under the condition of receiving the transaction order establishment request.

The server may establish a correspondence between the target order identifier and target transaction information, where the target order identifier may be used to query the target transaction information corresponding to the target order identifier when the target order corresponding to the target order identifier is paid, so as to determine the amount of resources to be paid according to the target transaction information.

Step S104, determining target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request.

The order payment request carries a target order identification and a first merchant identification.

According to the order payment request, determining the target transaction information and the candidate payment mode information corresponding to the order payment request can be determining the target transaction information and the candidate payment mode information corresponding to the order payment request according to the target order identification and the first merchant identification in the order payment request.

The candidate payment means information may be used to represent candidate payment means that the first merchant information may use in the payment process. The candidate payment mode can be a lending resource payment mode, a storage resource payment mode or other payment modes successfully configured on a business payment platform.

For example, the storage resource payment may be a bank card payment, and the first type merchant may bind a plurality of deposit cards at the business payment platform, and make the payment through the balance of the deposit cards. The loan resource payment mode can be credit loan payment, and the first type merchant can bind the opened credit loan mode in the business payment platform, and pay through the resources obtained by the credit loan mode.

In a specific implementation manner, determining target transaction information and candidate payment mode information corresponding to an order payment request according to the order payment request includes: determining target transaction information corresponding to the order payment request according to the corresponding relation between the target order identification and the pre-stored order identification and the transaction information, and determining candidate payment mode information corresponding to the order payment request according to the corresponding relation between the first merchant identification and the pre-stored merchant identification and the candidate payment mode.

The server may pre-store a correspondence between the order identifiers and the transaction information, where the correspondence may reflect a plurality of order identifiers and the transaction information corresponding to each order identifier. The corresponding relation between the order mark and the transaction information can comprise the corresponding relation between the target order mark and the target transaction information, and the server side can inquire and obtain the target transaction information corresponding to the order payment request from the corresponding relation between the order mark and the transaction information according to the target order mark.

The correspondence between the target order identification and the target transaction information may be established after the first type of merchant issues a transaction order establishment request to the second type of merchant, and reference may be made specifically to the corresponding description section of the transaction order establishment request hereinabove.

The server may store a correspondence between the merchant identifier and the candidate payment method in advance, where the correspondence between the merchant identifier and the candidate payment method includes a correspondence between the first merchant identifier and the first candidate payment method. The server side can query and obtain a first candidate payment mode corresponding to the first merchant identification in the corresponding relation between the prestored merchant identification and the candidate payment modes according to the first merchant identification, and the first candidate payment mode is determined to be an initial candidate payment mode corresponding to the first type merchant.

The number of initial candidate payment methods may be one or a plurality.

In addition, the server may also store a correspondence between the merchant identifier and merchant information, where the merchant information includes candidate payment methods. The correspondence between the merchant identifications and the merchant information may reflect a plurality of merchant identifications and merchant information corresponding to each merchant identification. The corresponding relation between the merchant identification and the merchant information can comprise the corresponding relation between the first merchant identification and the first merchant information, and the server side can inquire and obtain the first merchant information corresponding to the first merchant identification from the corresponding relation between the merchant identification and the merchant information according to the first merchant identification, wherein the first merchant information comprises a first candidate payment mode, and the first candidate payment mode is determined to be an initial candidate payment mode corresponding to the first type merchant. The correspondence between the first merchant identifier and the first merchant information may be established after receiving a registration request of the first type merchant for the service payment platform, and specifically reference may be made to the corresponding description section of the foregoing "registration request of the first type merchant for the service payment platform".

It should be noted that, the step of determining the target transaction information corresponding to the order payment request according to the corresponding relationship between the target order identifier and the pre-stored order identifier and the transaction information and the step of determining the candidate payment mode information corresponding to the order payment request according to the corresponding relationship between the first merchant identifier and the pre-stored merchant identifier and the candidate payment mode may be performed simultaneously, or the target transaction information may be determined first and then the candidate payment mode information may be determined first and then the target transaction information may be determined first, which is not limited in particular to the execution sequence of the two steps in this embodiment.

In a specific implementation manner, determining target transaction information and candidate payment mode information corresponding to an order payment request according to the order payment request includes: determining target transaction information corresponding to the order payment request according to the target order identification and the corresponding relation between the prestored order identification and the transaction information; and determining candidate payment mode information corresponding to the order payment request according to the target transaction information and the first merchant identification.

According to the target transaction information and the first merchant identification, the candidate payment mode information corresponding to the order payment request is determined, namely, a first range of candidate payment mode sets are determined according to the first merchant identification, then the first range of candidate payment mode sets are screened according to the target transaction information to obtain a second range of candidate payment mode sets, wherein the first range is greater than or equal to the second range, namely, the number of the candidate payment modes included in the first range of candidate payment mode sets is greater than or equal to the number of the candidate payment modes included in the second range of candidate payment mode sets.

The target transaction information may include payment resource amounts, order payment methods supported by the second type of merchant, and staged payment information, among others.

The payment resource amount is used to represent the amount of resources that the first type of merchant needs to pay to the second type of merchant in order to purchase the item corresponding to the target order from the second type of merchant. For example, a first type of merchant purchases 500 boxes of milk from a second type of merchant, and totals S1, the amount of payment resources corresponding to the target order, that is, S1, to be paid for the second type of merchant. For another example, the first type merchant purchases 3000 virtual articles 1 from the second type merchant, and needs to pay to the second type merchant through the points on the service payment platform, the number of the points to be paid is S2, and the S2 is the payment resource number corresponding to the target order. S1 may be a real number greater than 0. S2 may be a natural number greater than 0.

The order payment means supported by the second type of merchant is used to represent the payment means used by the second type of merchant to allow the purchaser of the item to sell the item. The order payment means may include a loan resource payment means and a savings resource payment means, may also include a cash payment means and a payment means, may also include a real-time payment means and a pay-before-use payment means, and so on. The above-mentioned individual order payment methods are merely exemplary, and do not constitute a particular limitation on the present embodiment.

For example, a first type merchant purchases 200kg of tea leaves from a second type merchant, the total needs to pay for S3 yuan, the order payment mode supported by the second type merchant includes a deposit resource payment mode, but does not include a loan resource payment mode, and the first type merchant cannot use the loan resource payment mode which is pre-bound on a service payment platform when making payment. S3 may be a real number greater than 0.

The stage payment information included in the target transaction information is used for indicating whether the target order supports the stage payment mode, and in the case that the target order supports the stage payment mode, the stage times, the interest rate information and the preferential information corresponding to the stage payment mode, and the like.

For example, the number of installments corresponding to the target order may be one of 3, 6, and 12, the interest rate corresponding to the number of installments 3 may be x1, the interest rate corresponding to the number of installments 6 may be x2, and the interest rate corresponding to the number of installments 12 may be x 3. x1, x2, and x3 may each be real numbers greater than 0.

In a specific implementation, the target transaction information includes a payment resource amount corresponding to the target order; according to the target transaction information and the first merchant identification, determining candidate payment mode information corresponding to the order payment request, including: determining an initial candidate payment mode corresponding to the first type merchant according to the corresponding relation between the first merchant identification and the pre-stored merchant identification and the candidate payment mode; and screening the initial candidate payment modes according to the quantity of the payment resources to obtain candidate payment mode information corresponding to the order payment request.

The number of initial candidate payment methods may be one or a plurality.

Screening the initial candidate payment modes according to the quantity of the payment resources to obtain candidate payment mode information corresponding to the order payment request, wherein the maximum quantity of resources corresponding to each initial candidate payment mode in the multiple initial candidate payment modes can be determined under the condition that the first type merchant corresponds to the multiple initial candidate payment modes; comparing the numerical value according to the number of the payment resources and the maximum number of the resources corresponding to each initial candidate payment mode to obtain a comparison result corresponding to each initial candidate payment mode; and screening the plurality of initial candidate payment modes according to the comparison result to obtain candidate payment mode information corresponding to the order payment request.

According to the comparison result, specific implementation modes of screening the multiple initial candidate payment modes can include: deleting an initial candidate payment mode corresponding to the maximum resource number under the condition that the comparison result is used for indicating that the payment resource number is larger than the maximum resource number; and reserving an initial candidate payment mode corresponding to the maximum resource number under the condition that the comparison result is used for indicating that the payment resource number is smaller than or equal to the maximum resource number. Therefore, the candidate payment mode information corresponding to the order payment request can be used for representing at least one candidate payment mode, each candidate payment mode in the at least one candidate payment mode can be one of the plurality of initial candidate payment modes, and the maximum resource quantity of the candidate payment modes is greater than or equal to the payment resource quantity.

The maximum number of resources corresponding to each initial candidate payment means may be the maximum number of resources that can be used in the case of payment by such initial candidate payment means.

For example, the bank card stores cash Y element, Y is a natural number greater than 0, and Y can be the maximum resource number corresponding to the bank card; the number of points accumulated by the first type of merchant on the business paymate is Z, which may be the maximum number of resources corresponding to the points, and so on.

And screening the initial candidate payment modes according to the number of the payment resources to obtain candidate payment mode information, sending the candidate payment mode information to the client so as to render the payment page, wherein the candidate payment modes presented by the payment page to the first type merchant are all candidate payment modes with the maximum number of resources being greater than or equal to the number of the payment resources, and the payment modes which cannot be independently paid to the second type merchant can be filtered in advance, so that the payment page presents a small number of independently usable payment modes to the first type merchant in a limited page space, and the first type merchant can conveniently select the payment modes.

In practical application, under the condition that the number of payment modes bound by the business payment platform is large, the first type merchant may not be able to clearly record the maximum resource number corresponding to each pre-bound payment mode, if all the payment modes are presented to the first type merchant, the page space of a payment page is limited, only a part of payment modes can be presented at one time, and the first type merchant is required to actively turn pages and search for determining the payment mode which the first type merchant expects to use. The number of candidate payment methods presented to the first type merchant through the payment page can be reduced by screening the initial candidate payment methods in advance, so that the first type merchant can more conveniently select the payment method which is expected to be used.

In another implementation manner, the initial candidate payment manner may be classified according to the number of payment resources, so as to obtain candidate payment manner information corresponding to the order payment request. In the specific implementation, under the condition that the first type merchant corresponds to a plurality of initial candidate payment modes, determining the maximum resource quantity corresponding to each initial candidate payment mode in the plurality of initial candidate payment modes; comparing the numerical value according to the number of the payment resources and the maximum number of resources corresponding to each initial candidate payment mode to obtain a comparison result corresponding to each initial candidate payment mode; and classifying the plurality of initial candidate payment modes according to the comparison result corresponding to each initial candidate payment mode to obtain candidate payment mode information corresponding to the order payment request.

Based on the comparison result, specific implementation manners of classifying the multiple initial candidate payment manners may include: determining a classification result of the initial candidate payment modes with the maximum resource quantity smaller than the payment resource quantity as a first payment mode; and determining the classification result of the initial candidate payment modes with the maximum resource number being greater than or equal to the payment resource number as a second payment mode. The candidate payment means information may include a first payment means and a second payment means, and the candidate payment means information may be used to distinguish and display the second payment means which can be used independently by the first type merchant from the first payment means which cannot be used independently in the case that the payment page is rendered by the client, thereby enabling the first type merchant to more conveniently select a payment means which is desired to be used.

In one specific implementation, the initial candidate payment means comprises a loan resource payment means; screening the initial candidate payment modes according to the quantity of the payment resources to obtain candidate payment mode information corresponding to the order payment request, wherein the method comprises the following steps: acquiring a resource borrowing limit corresponding to a borrowing resource payment mode; and screening the initial candidate payment modes according to the payment resource quantity and the resource borrowing limit to obtain candidate payment mode information corresponding to the order payment request.

The loan resource payment method may be that the payment is performed on the resources currently provided by the loan institution, and the resource repayment is performed to the loan institution within the time range specified by the loan institution according to the resource repayment method agreed with the loan institution.

The "institution" in the "lending institution" includes organizations of various forms such as institutions, and social groups, and further, institutions include not only the present-level organization but also an internal organization of the institution, such as an institution department or a division.

In a brand supply chain scenario, a store needs to periodically purchase raw materials from a provider at a business host platform and pay orders through a business payment platform, and in the case that the number of payment resources involved in raw material purchase is greater than a preset resource number threshold, payment is likely to be needed through a loan resource payment mode. In practical application, the store can pre-conduct proxy loan authorization operation for various resource loan payment modes in the business payment platform. After the proxy loan authorization operation is executed, the store does not need to actively loan resources to a loan organization in the process of order payment through the business payment platform, receives the resources provided by the loan organization through the appointed bank card, and pays through the storage resources in the bank card, but the business payment platform proxy store performs the resource loan, so that the loan organization directly sends the resources borrowed by the store to the bank card appointed by the supplier, and order payment is completed. In the process of resource borrowing by a business payment platform agent store, a bank card appointed by a provider can be preset by the provider on the business payment platform, and the quantity of resources borrowed by the store can be determined by the quantity of payment resources in target transaction information corresponding to a target order.

The resource debit value unit corresponding to the debit resource payment method may be a maximum amount of resources permitted by the debit authority corresponding to the debit resource payment method for the first type of merchant debit.

The obtaining of the resource borrowing and lending amount corresponding to the borrowing and lending resource payment mode may be sending a first type of line inquiry request to a borrowing and lending mechanism corresponding to the borrowing and lending resource payment mode, or may be reading a pre-stored resource borrowing and lending amount corresponding to the borrowing and lending resource payment mode.

Screening the initial candidate payment modes according to the quantity of the payment resources and the resource borrowing amount, wherein if the quantity of the payment resources is larger than the resource borrowing amount, the resource borrowing mode corresponding to the resource borrowing amount is deleted from the initial candidate payment modes; if the amount of the paid resources is less than or equal to the resource borrowing amount, reserving a resource borrowing mode corresponding to the resource borrowing amount in the initial candidate payment mode. The candidate payment method information corresponding to the order payment request may be used to indicate a resource lending method for paying a resource amount equal to or less than the resource lending amount.

In a specific implementation, the initial candidate payment means comprises a storage resource payment means; screening the initial candidate payment modes according to the quantity of the payment resources to obtain candidate payment mode information corresponding to the order payment request, wherein the method comprises the following steps: acquiring the quantity of storage resources corresponding to a storage resource payment mode; and screening the initial candidate payment modes according to the payment resource quantity and the storage resource quantity to obtain candidate payment mode information corresponding to the order payment request.

The payment method of the storage resource can be bank card payment or other payment methods by using cash resources owned by the first type merchant. Cash may be a medium of exchange that may be placed in circulation immediately to a certain extent, with general acceptance, and may be effectively used immediately to purchase goods, merchandise, labor, or repayment liabilities.

And the storage resource payment mode corresponds to the storage resource quantity, such as cash currently stored in a bank card.

The obtaining of the storage resource amount corresponding to the storage resource payment method may be querying the cash resource amount corresponding to the storage resource payment method.

And screening the initial candidate payment modes according to the number of the payment resources and the number of the storage resources to obtain candidate payment mode information corresponding to the order payment request, wherein the value comparison can be carried out on the number of the payment resources and the number of the storage resources, and the screening process is carried out on the initial candidate payment modes according to the comparison result to obtain the candidate payment mode information corresponding to the order payment request. The candidate payment method information is used for indicating the storage resource payment methods with the number of storage resources being greater than or equal to the number of payment resources.

And step S106, sending the candidate payment mode information and the target transaction information to the client so as to render the payment page.

And the server side sends the candidate payment mode information and the target transaction information to the client side. And the client performs page rendering processing according to the candidate payment mode information and the target transaction information to generate a payment page.

The payment page may display one or more candidate payment methods for selection by the first type of merchant. The payment page may also display a merchant name of the second type merchant in the target transaction information, the goods corresponding to the target order, the number of goods, the number of payment resources, and the like, so that the first type merchant can confirm the target order.

If the first type of merchant finds that the target transaction information is wrong when viewing the payment page, for example, the amount of the payment resources exceeds the expected amount, the order payment can be cancelled.

Step S108, user input information of the first type merchant in the payment page sent by the client is obtained, and a target payment mode is determined according to the user input information.

The client may receive user input from the first type of merchant in the payment page, and thereby send user input information corresponding to the user input to the server. The server acquires user input information, and determines a target payment mode selected by the first type merchant according to the user input information.

The target payment means may be a candidate payment means selected by the first type of merchant for making a payment to the second type of merchant.

The number of the target payment methods may be one or a plurality of.

Step S110, aiming at the target order, the corresponding target order is identified, and payment is carried out to the second type merchant in a target payment mode.

The server side can pay to the second type merchant in a target payment mode, and responds to an order payment request sent by the first type merchant to the second type merchant. The second type of merchant may receive payment and then ship to the first type of merchant in accordance with the targeted transaction information.

The first type merchant pays the second type merchant with the amount of resources, namely the amount of resources paid by the target order identification in the corresponding target transaction information in a target payment mode.

In addition, in the case where the number of target payment methods is plural, a combined payment may be performed by the plural target payment methods in accordance with a pre-configured payment policy.

In particular, priorities of different types of payment methods may be preconfigured. According to a pre-configured payment strategy, the combined payment is performed by the multiple target payment modes, namely, the number of resources to be processed corresponding to each target payment mode in the multiple target payment modes is determined according to the priority and the number of payment resources of different types of payment modes, and then the combined payment is performed according to the number of resources to be processed corresponding to each target payment mode.

For example, the first type of payment method has a first priority, the second type of payment method has a second priority … …, the plurality of target payment methods include a first type of payment method p1 and a second type of payment method p2, the number of payment resources is N, the maximum number of resources of p1 is K1, the maximum number of resources of p2 is K2, k1+k2> N > K2> K1. The number of resources to be processed corresponding to p1 is K1, the number of resources to be processed corresponding to p2 is (N-K1), and in the combined payment process, K1 is paid through p1, and (N-K1) is paid through p 2.

In a specific implementation, the target transaction information includes a second merchant identification generated by a second type of merchant after registration with the business payment platform; the server stores the corresponding relation between the merchant identification and the merchant information; aiming at the target order corresponding to the target order identification, after the target payment mode is adopted to pay to the second type merchant, the payment method further comprises the following steps: determining first merchant information of a first type merchant according to the first merchant identification and the corresponding relation between the merchant identification and the merchant information, and determining second merchant information of a second type merchant according to the second merchant identification and the corresponding relation between the merchant identification and the merchant information; and establishing an association relationship among the target order, the first merchant information and the second merchant information.

The server may store a correspondence between merchant identifiers and merchant information, where the correspondence between merchant identifiers and merchant information includes a correspondence between a first merchant identifier and first merchant information, and a correspondence between a second merchant identifier and second merchant information.

According to the first merchant identification, the first merchant information corresponding to the first type merchant can be obtained by inquiring the corresponding relation between the merchant identification and the merchant information, and according to the second merchant identification, the second merchant information corresponding to the second type merchant can be obtained by inquiring the corresponding relation between the merchant identification and the merchant information.

The first type merchant and the second type merchant are registered in the service payment platform, and in the case that the first type merchant and the second type merchant have performed authorization operations about user privacy, the server may store first merchant information and second merchant information, where the first merchant information includes user identity information corresponding to the first type merchant, for example, a real name of an applicant, an identity feature number uniquely corresponding to the applicant, and the like, which relate to user privacy, and the second merchant information is the same.

And establishing an association relationship among the target order, the first merchant information and the second merchant information, which is beneficial to bill verification by combining the three flows of contract, bill and fund aiming at the target order under the condition that the user identity information is known by the business party corresponding to the business main platform. In this case, it is no longer necessary to manually dock and verify that the non-real-name payer matches the ticket generated after payment.

In summary, in the payment method provided by the embodiment, an order payment request sent by a first type merchant to a second type merchant is received; the order payment request carries a target order identifier and a first merchant identifier generated after the first type merchant is registered in the business payment platform;

determining target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request;

sending the candidate payment mode information and the target transaction information to the client so as to render a payment page;

acquiring user input information of a first type merchant in a payment page sent by a client, and determining a target payment mode according to the user input information;

aiming at a target order corresponding to the target order identification, paying to a second type merchant in a target payment mode;

in this way, in the application scenario that long-term transaction requirements may exist between merchants, the first type merchant serving as the purchasing party is a merchant registered in the service payment platform, the service payment platform is convenient to centrally manage the processing flow of each order payment of the first type merchant through the first merchant identification, bill verification is performed on each order by the service party corresponding to the service payment platform, and the first type merchant can flexibly select a target payment mode from multiple payment modes in an aggregation mode to pay.

Fig. 2 is a flowchart of a business payment platform according to one or more embodiments of the present disclosure.

As shown in fig. 2, the service payment platform includes the following functions: merchant residence, opening shortcut payments, order payments, wallet refill, operator authorization, subscription management, wallet management, background interfaces, and the like.

The merchant residence involves steps S202 to S210:

step S202, selecting the merchant type.

Step S204, the second family opens an account.

Step S206, perfecting merchant information.

Step S208, the merchant is resident.

Step S210, signing by shortcut buttons.

The business main platform can accept the application of the resident link through the resident pre-establishment of the merchant, and the merchant jumps to the applet of the business payment platform through the two-dimensional code scanning or the link to complete the resident operation.

Taking a merchant as a first type merchant as an example, after the first type merchant is in residence, the small program can return a pre-acceptance single number of the residence application, a business merchant identifier corresponding to the first type merchant, a first merchant identifier generated by a payment business platform for the first type merchant and an residence result to a business main platform, and the business main platform completes the association of the business merchant identifier corresponding to the first type merchant and the first merchant identifier.

The steps S212 to S214 are related to opening the shortcut payment:

step S212, the second family opens an account.

Step S214, signing by shortcut buttons.

The business main platform can apply for signing a contract through the authorization signing interface, and the merchant can finish authorizing payment signing through two-dimension code scanning or linking and skipping the applet.

The order payment involves steps S216 to S220:

in step S216, the payment instrument is selected.

Step S218, trade checking.

The core may be performing an authentication operation.

Step S220, paying to the sub-users of the business platform of the merchant.

The first type of merchant makes a payment to the second type of merchant. The "sub-home of merchant in business platform" in step S220 may be a second type merchant, referring specifically to the corresponding illustration of S110 in the embodiment of fig. 1.

The business main platform is linked with the order payment application of the business payment platform, and the merchant jumps to the applet of the business payment platform through the two-dimension code scanning or linking, so that the order payment operation is completed, and the combined payment is supported.

Taking a merchant as a first type merchant as an example, after the payment is completed, the applet can return the pre-acceptance single number, the business merchant identification corresponding to the first type merchant, the first merchant identification and the payment result to the business host platform, and the business host platform continues the follow-up operation according to the payment result.

Steps S216 to S220 involved in order payment may refer to corresponding description parts of steps S108 to S110 in the embodiment of fig. 1.

The recharging of the wallet involves steps S222 to S226:

in step S222, the payment instrument is selected.

Step S224, trade checking.

The core may be performing an authentication operation.

And step S226, recharging to the sub-user of the business payment platform.

The step may be that the first type merchant converts the owned storage resource into a storage resource corresponding to the service payment platform, or the service payment platform proxies the first type merchant to carry out loan operation to the loan institution, and converts the resource provided by the loan institution into the storage resource corresponding to the service payment platform. The corresponding storage resources of the service payment platform can be points, vouchers, or other forms of storage resources, and the like.

The operator authorization involves steps S228 to S232:

step S228, the administrator registers.

Step S230, an operator is added.

Step S232, delete the operator.

The business main platform can display a static link to a merchant, the merchant logs in an applet home page of the business payment platform through a two-dimensional code scanning or linking, and can perform operations such as balance inquiry, cash withdrawal, recharging, merchant information modification and the like, and can perform operations such as registration of an organization administrator, authorization of an organization operator and the like.

The subscription management involves steps S234 to S236:

step S234, directing payment authorization.

Step S236, balance payment is free of short tests.

The short-test-free means that the authentication is free from being carried out through a short message, namely the authentication is not required to be carried out through the short message when the balance resource is utilized by the authorized service payment platform for payment. The balance resource may be a storage resource corresponding to the business payment platform.

The wallet management involves steps S238 to S244:

and S238, inquiring the balance.

Step S240, mention is made.

Step S242, detail query.

Step S244, recharging.

The business payment platform can charge service fees, commissions and the like to the merchant through the balance payment interface, and supports recharging payment when the balance of the sub-user available to the merchant is insufficient.

The background interface refers to steps S246 to S252:

step S246, the resident application.

Step S248, order payment.

Step S250, authorizing the subscription.

Step S252, balance payment.

Since the technical conception is the same, the description in this embodiment is relatively simple, and the relevant parts only need to refer to the corresponding descriptions of the method embodiments provided above.

The present specification provides another payment method embodiment:

FIG. 3 is a flow diagram of another payment method process provided in one or more embodiments of the present disclosure.

Step S302, pre-paying the order.

Step S304, accepting the floor and generating an order number.

Step S306, APP clicks skip/PC scans skip payment.

Step S308, the cashier renders the request.

Step S310, order information inquiry.

In step S312, the payment instrument queries.

Step S314, rendering by the cashier.

Step S316, selecting a payment instrument and confirming.

Step S318, a request is made by the kernel.

Step S320, nuclear body.

In step S322, the payment is submitted.

In step S324, the payment logic processes.

Step S326, polling the query result.

Step S328, query the payment result.

Step S330, returning a payment result.

Step S332, notifying the payment result.

And the service end of the service payment platform returns payment result notification information to the service end of the service main platform, wherein the payment result notification information is used for notifying the service main platform whether the order payment is successful or not.

The present specification provides yet another payment method embodiment:

fig. 4 is a process flow diagram of yet another payment method provided in one or more embodiments of the present disclosure.

As shown in fig. 4, S402 applies for an order payment pre-acceptance.

Step S404, the payment order, and the receipt and payment side order details are dropped.

Step S406, a token containing order information is returned for generating a two-dimensional code.

A token may be a temporary token that represents an object of rights to perform certain operations. The token in the step is used for generating the two-dimensional code, and a user can enter the applet of the service payment platform by executing the code scanning operation on the two-dimensional code.

And step S408, generating and displaying a two-dimensional code by using the merchant identification and the token.

Step S410, the two-dimension code is scanned and enters a small program.

Step S412, identifying the two-dimensional code type as order payment.

In step S414, the background is requested by using the uid and token.

The uid may refer to a first merchant identification of a first type of merchant in the embodiment of fig. 1.

In step S416, the merchant with the uid binding checks the level of order information contained in the token.

Step S418, returning order information.

Step S420, displaying order information.

Step S422, query order tool

Step S424, go to the payment instrument available for payment acceptance consultation.

Step S426, returning to the payment instrument available to the user.

Step S428, a cash register is displayed.

The checkout counter illustrated in this step may refer to the payment page in the embodiment of fig. 1.

Step S430, selecting a payment mode, and confirming the payment.

Step S432, confirming the order payment.

Step S434, the verifyId is returned.

The verifyId may be used to trigger authentication and establish correspondence with the authentication. After the identity verification is finished, the processing flow and the verification result of the identity verification can be obtained by inquiring the verifyId.

Step S436, the nucleus is evoked with the verifyId.

The core may be performing an authentication operation.

Step S438, the nuclear body is completed.

Step S440, submitting order payment.

In step S442, if the security kernel passes, the asset exchange is initiated asynchronously.

The asynchronous initiation of the asset exchange may be a payment processing operation by a third party program, applet, or other tool.

Step S444, return to the process.

In step S446, the page is in display payment.

Step S448, a payment result is returned.

Step S450, rendering the processing result.

Fig. 5 is a schematic business architecture diagram of an industry checkout counter provided in one or more embodiments of the present disclosure.

As shown in fig. 5, the industry checkout counter may be a business paymate, which may be an applet.

The industry checkout counter may have the following functions: recharging, reflecting and order payment. Wherein order payment may include the following sub-functions: merchant order payment, standing-in order payment, transfer payment.

Specifically, the industry checkout counter may perform the following operations: the method comprises the steps of creating a bill, rendering the payment, confirming the payment, submitting the payment, paying the result and closing the bill. Creation refers to creating a trade order. Closing refers to closing an established trade order, i.e., canceling the trade order.

The flow engine of the industry cash register can realize scene recognition, asset decision, limit control, signing, authorization and security service.

For a unified checkout counter, asset decision and asset exchange can be realized; for the security of the master station, the security service and the back money laundering can be realized; for merchant products, merchant establishment and merchant authorization can be realized; for billing centers, transaction billing and receipt applications may be implemented.

In particular, the industry checkout counter may be applied to brand supply chain scenarios, where the merchant that resides may be a store, or may be a vendor specified by the brand party. The store and provider newly joining the brand side may submit a resident application to the business cash register, and the store and provider exiting the brand side may log off the merchant registered in the business cash register and revoke the corresponding authorization.

In a brand supply chain scene, each store under the same brand regularly performs raw material purchasing to a provider specified by the brand, if each store transfers money to a bank account specified by the provider through a bank app, the provider is notified after transferring money, and bill information needs to be provided for a brand party so as to facilitate the brand party to check out and check out bills, so that the brand party has complicated flow when performing financial management on transactions between each store and the provider, and a large amount of manpower and material resources need to be consumed. Under the condition that each store and each provider enter an industry cash register, the automatic association of orders and payment and the automatic association of business finance can be realized, and the finance of the brand party does not need to check and check bills manually, so that the financial management efficiency of the brand party is obviously improved.

Fig. 6 is a schematic diagram of a merchant residence process in a business payment platform according to one or more embodiments of the present disclosure.

As shown in fig. 6, in step S602, a merchant applies for residence.

The merchant submitting the merchant residence application may refer to both the first type of merchant and the second type of merchant in the embodiment of fig. 1.

Illustratively, in a brand supply chain scenario, the merchant that resides may be a store or a vendor.

Step S604, generating a resident two-dimensional code.

The resident merchant may jump through the code-sweeping applet.

Step S606, select merchant type.

In step S608, the merchant information is supplemented.

The merchant information may refer to the first merchant information in the embodiment of fig. 1.

Illustratively, merchant information includes, but is not limited to: merchant short, contact phone, business type, location area, detailed address, etc.

Step S610, binding a bank card.

Step S612, the entering of the home page is completed, and the home page is entered.

In step S614, the background notifies the result of the stay.

Fig. 7 is a schematic diagram illustrating an order payment process in a business payment platform according to one or more embodiments of the present disclosure.

As shown in fig. 7, in step S702, a merchant places an order on the platform side.

In step S704, the platform backend requests the network provider to order.

Step S706, generating an order payment two-dimensional code.

Step S708, entering an order payment page to select a payment mode.

Step S710, the payment is completed.

Step S712, the background notifies the platform that the payment was successful.

In step S714, the order is subsequently reconciled/subsidized.

The business party corresponding to the business payment platform can pre-negotiate with the second type merchant to determine an order accounting mode/an order subsidy mode. After the first type merchant pays the order for the target order to the second type merchant, the server side can perform payment resource allocation processing according to the predetermined order accounting mode and the payment resource quantity corresponding to the target order. Or after the first type merchant pays the order for the target order to the second type merchant, the server side can perform payment resource allocation processing according to a predetermined order subsidy mode and the payment resource quantity corresponding to the target order.

For example, a first type of merchant pays an a-ary, wherein an a 1-ary is assigned to a second resource merchant and an a 2-ary is assigned to a business party corresponding to a business payment platform.

The payment method provided in this embodiment is similar to the payment method provided in the above embodiment in the execution process, and reference is made to the related content of the above embodiment for reading this embodiment.

An embodiment of a payment device provided in the present specification is as follows:

in the above-described embodiments, a payment method and a payment apparatus corresponding thereto are provided, and the following description is made with reference to the accompanying drawings.

Referring to fig. 8, a schematic diagram of a payment device according to the present embodiment is shown.

Since the apparatus embodiments correspond to the method embodiments, the description is relatively simple, and the relevant portions should be referred to the corresponding descriptions of the method embodiments provided above. The device embodiments described below are merely illustrative.

The present embodiment provides a payment apparatus, including:

a request receiving module 802 configured to receive an order payment request issued by a first type of merchant to a second type of merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered;

an information determining module 804, configured to determine, according to the order payment request, target transaction information and candidate payment mode information corresponding to the order payment request;

an information sending module 806 configured to send the candidate payment means information and the target transaction information to a client to render a payment page;

A manner determining module 808, configured to obtain user input information of the first type merchant in the payment page sent by the client, and determine a target payment manner according to the user input information;

an order payment module 810 is configured to identify a corresponding target order for the target order, and pay to the second type merchant through the target payment mode.

in correspondence to the above-described payment method, one or more embodiments of the present disclosure further provide a payment device for performing the above-provided payment method, based on the same technical concept, and fig. 9 is a schematic structural diagram of the one or more embodiments of the present disclosure.

The payment device provided in this embodiment includes:

as shown in fig. 9, the payment device may have a relatively large difference due to different configurations or performances, and may include one or more processors 901 and a memory 902, where the memory 902 may store one or more storage applications or data. Wherein the memory 902 may be transient storage or persistent storage. The application program stored in the memory 902 may include one or more modules (not shown in the figures), each of which may include a series of computer-executable instructions in the payment device. Still further, the processor 901 may be arranged to communicate with the memory 902 and execute a series of computer executable instructions in the memory 902 on the payment device. The payment device may also include one or more power supplies 903, one or more wired or wireless network interfaces 904, one or more input/output interfaces 905, one or more keyboards 906, and the like.

In one particular embodiment, a payment device includes a memory, and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment device, and configured to be executed by one or more processors, the one or more programs comprising computer-executable instructions for:

receiving an order payment request sent by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered;

sending the candidate payment mode information and the target transaction information to a client to render a payment page;

acquiring user input information of the first type merchant in the payment page, which is sent by the client, and determining a target payment mode according to the user input information;

And aiming at the target order, identifying a corresponding target order, and paying to the second type merchant in the target payment mode.

An embodiment of a storage medium provided in the present specification is as follows:

corresponding to one payment method described above, one or more embodiments of the present specification further provide a storage medium based on the same technical idea.

The storage medium provided in this embodiment is configured to store computer executable instructions that, when executed by a processor, implement the following flow:

It should be noted that, the embodiments related to the storage medium in the present specification and the embodiments related to the payment method in the present specification are based on the same inventive concept, so the specific implementation of this embodiment may refer to the implementation of the foregoing corresponding method, and the repetition is not repeated.

The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

In the 30 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each unit may be implemented in the same piece or pieces of software and/or hardware when implementing the embodiments of the present specification.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that 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. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

One or more embodiments of the present specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, as relevant to see a section of the description of method embodiments.

The foregoing description is by way of example only and is not intended to limit the present disclosure. Various modifications and changes may occur to those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. that fall within the spirit and principles of the present document are intended to be included within the scope of the claims of the present document.

Claims

1. A payment method is applied to a server and comprises the following steps:

2. The method of claim 1, the target transaction information comprising a second merchant identification generated by the second type of merchant upon registration with the business payment platform; the server stores the corresponding relation between merchant identification and merchant information; the method further comprises the steps of, after the target orders corresponding to the target orders are identified and the second type merchant is paid in the target payment mode:

determining first merchant information of the first type merchant according to the first merchant identification and the corresponding relation between the merchant identification and merchant information, and determining second merchant information of the second type merchant according to the second merchant identification and the corresponding relation between the merchant identification and merchant information;

And establishing an association relationship among the target order, the first merchant information and the second merchant information.

3. The method of claim 1, wherein the determining, according to the order payment request, the target transaction information and the candidate payment manner information corresponding to the order payment request includes:

determining target transaction information corresponding to the order payment request according to the target order identification and the corresponding relation between the prestored order identification and the transaction information;

and determining candidate payment mode information corresponding to the order payment request according to the target transaction information and the first merchant identification.

4. A method according to claim 3, the target transaction information comprising a payment resource quantity corresponding to the target order; the determining the candidate payment mode information corresponding to the order payment request according to the target transaction information and the first merchant identifier includes:

determining an initial candidate payment mode corresponding to the first type merchant according to the corresponding relation between the first merchant identification and the prestored merchant identification and the candidate payment mode;

and screening the initial candidate payment modes according to the payment resource quantity to obtain candidate payment mode information corresponding to the order payment request.

5. The method of claim 4, the initial candidate payment means comprising a loan resource payment means; the step of screening the initial candidate payment mode according to the payment resource quantity to obtain candidate payment mode information corresponding to the order payment request, including:

acquiring resource borrowing limit corresponding to the borrowing resource payment mode;

and screening the initial candidate payment modes according to the payment resource quantity and the resource borrowing amount to obtain candidate payment mode information corresponding to the order payment request.

6. The method of claim 4, the initial candidate payment means comprising a storage resource payment means; the step of screening the initial candidate payment mode according to the payment resource quantity to obtain candidate payment mode information corresponding to the order payment request, including:

acquiring the quantity of the storage resources corresponding to the storage resource payment mode;

and screening the initial candidate payment modes according to the payment resource quantity and the storage resource quantity to obtain candidate payment mode information corresponding to the order payment request.

7. The method of claim 1, wherein the determining, according to the order payment request, the target transaction information and the candidate payment manner information corresponding to the order payment request includes:

determining target transaction information corresponding to the order payment request according to the corresponding relation between the target order identification and the pre-stored order identification and the transaction information, and determining candidate payment mode information corresponding to the order payment request according to the corresponding relation between the first merchant identification and the pre-stored merchant identification and the candidate payment mode.

8. The method of claim 1, prior to receiving an order payment request from a first type of merchant to a second type of merchant, the method further comprising:

receiving a transaction order establishment request sent by the first type merchant to the second type merchant; the transaction order establishment request carries the target transaction information;

generating a corresponding target order mark according to the transaction order establishment request;

and establishing a corresponding relation between the target order mark and the target transaction information.

9. The method of claim 1, the method further comprising:

receiving a registration request of the first type merchant for the business payment platform; the registration request carries a business merchant identifier which is pre-distributed for the first type merchant by a business main platform;

Acquiring registration page information according to the registration request and sending the registration page information to the client so as to render a registration page;

acquiring first merchant information input by the first type merchant on the registration page;

generating the first merchant identification under the condition that the first merchant information meets a preset registration condition, and determining the first merchant identification as a merchant identification corresponding to the first type merchant on the business payment platform;

establishing an association relationship between the business merchant identification and the first merchant identification, and establishing an association relationship between the first merchant information and the first merchant identification;

and sending the association relation between the business merchant identification and the first merchant identification to the business main platform.

10. The method of claim 1, the method further comprising:

receiving a registration request of the first type merchant for the business payment platform;

And establishing an association relationship between the first merchant information and the first merchant identification.

11. A payment device, applied to a server, comprising:

a request receiving module configured to receive an order payment request issued by a first type merchant to a second type merchant; the order payment request carries a target order identifier and a first merchant identifier generated by the first type merchant after the business payment platform is registered;

the information determining module is configured to determine target transaction information and candidate payment mode information corresponding to the order payment request according to the order payment request;

the information sending module is configured to send the candidate payment mode information and the target transaction information to the client so as to render a payment page;

the mode determining module is configured to acquire user input information of the first type merchant in the payment page, which is sent by the client, and determine a target payment mode according to the user input information;

and the order payment module is configured to identify a corresponding target order for the target order and pay the second type merchant in the target payment mode.

12. A payment device, comprising:

a processor; the method comprises the steps of,

a memory configured to store computer-executable instructions that, when executed, cause the processor to:

13. A storage medium storing computer-executable instructions that when executed by a processor implement the following: