CN115953156A - Payment processing method and device - Google Patents

Abstract

The embodiment of the specification provides a payment processing method and a payment processing device, wherein the payment processing method comprises the following steps: detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; submitting the order to be paid based on the organization code of the organization to which the organization member belongs; if the detection result is empty, reading order data of the order to be paid and acquiring payment extension data; determining the mechanism payment type of the order to be paid according to the order data and the payment extended data; and if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

Description

Payment processing method and device

Technical Field

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

Background

With the development of computers and the internet, more and more users pay for goods or services gradually in an online payment mode, under the condition that online payment is more and more popular, organization members of an organization pay for generated orders to be paid in an online payment mode, the organization provides a plurality of payment scenes for the organization members, such as catering payment scenes, and the organization members pay the orders to be paid according to different payment scenes.

Disclosure of Invention

One or more embodiments of the present specification provide a payment processing method, including: detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; and submitting the order to be paid based on the organization code of the organization to which the organization member belongs. And if the detection result is null, reading the order data of the order to be paid and acquiring payment extension data. And determining the mechanism payment type of the order to be paid according to the order data and the payment extension data. And if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

One or more embodiments of the present specification provide a payment processing apparatus, including: the identification detection module is configured to detect the participant identification of the order participant carried in the to-be-paid order of the organization member; and submitting the order to be paid based on the organization code of the organization to which the organization member belongs. And if the detection result is null, operating a data reading module, wherein the data reading module is configured to read order data of the order to be paid and acquire payment extension data. And the type determining module is configured to determine the institution payment type of the order to be paid according to the order data and the payment extension data. And if the payment type determination fails, operating a payment processing module, wherein the payment processing module is configured to perform payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

One or more embodiments of the present specification provide a payment processing apparatus comprising: a processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to: detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; and submitting the order to be paid based on the organization code of the organization to which the organization member belongs. And if the detection result is null, reading the order data of the order to be paid and acquiring payment extension data. And determining the mechanism payment type of the order to be paid according to the order data and the payment extension data. And if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

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: detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; and submitting the order to be paid based on the organization code of the organization to which the organization member belongs. And if the detection result is null, reading the order data of the order to be paid and acquiring payment extension data. And determining the mechanism payment type of the order to be paid according to the order data and the payment extension data. And if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the institution payment type selected by the institution member in the institution payment type set.

Drawings

In order to more clearly illustrate one or more embodiments or technical solutions in the prior art in the present specification, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present specification, and for those skilled in the art, other drawings can be obtained according to the drawings without inventive exercise;

fig. 1 is a processing flow diagram of a payment processing method according to one or more embodiments of the present disclosure;

fig. 2 is a processing flow diagram of a payment processing method applied to a restaurant payment scenario, provided by one or more embodiments of the present disclosure;

fig. 3 is a processing flow diagram of a payment processing method applied to a travel payment scenario according to one or more embodiments of the present specification;

FIG. 4 is a schematic diagram of a payment processing apparatus according to one or more embodiments of the present disclosure;

fig. 5 is a schematic structural diagram of a payment processing apparatus according to one or more embodiments of the present disclosure.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in one or more embodiments of the present disclosure, the technical solutions in one or more embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in one or more embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all embodiments. All other embodiments that can be derived by a person skilled in the art from one or more of the embodiments described herein without making any inventive step shall fall within the scope of protection of this document.

An embodiment of a payment processing method provided in this specification:

in an actual public consumption scene, a mechanism member utilizes a mechanism account to pay orders, and the payment scene can be divided into multiple scenes such as catering, traveling, accommodation and the like, so that the mechanism member often needs to select one or more payment scenes by oneself and carries out corresponding payment processing under the selected payment scene, which causes poor user experience and risks of misoperation.

In view of the above, in the payment processing method provided in this embodiment, a participant identifier of an order participant carried in an order to be paid of a mechanism member is detected, when a detection result is null, a mechanism payment type of the order to be paid is determined according to order data and payment extension data of the order to be paid, and when the determination of the payment type fails, the order to be paid is subjected to payment processing according to a funding policy corresponding to a mechanism payment type centrally selected by the mechanism member in the mechanism payment type, so that when the automatic determination of the mechanism payment type of the order to be paid fails, the payment processing is performed according to the funding policy corresponding to the mechanism payment type selected by the mechanism member, thereby improving flexibility of payment processing and improving user experience.

Referring to fig. 1, the payment processing method provided in this embodiment specifically includes step S102 to step S108.

And step S102, detecting the participant identification of the order participant carried in the to-be-paid order of the organization member.

In the present embodiment, the organization includes various types of organizations such as enterprises, institutions, and social groups, and further, the organization includes not only the present level organization but also an internal organization of the organization, such as a division or division of an enterprise. The organization members include organization personnel and related personnel.

The mechanism code of the mechanism refers to an identification code set by the mechanism for payment of mechanism members and the like, the mechanism code can uniquely identify the mechanism, the existence form of the mechanism code can be a two-dimensional code, a bar code, a sound code and other identification codes, and the mechanism members can realize payment through the mechanism code. In addition, the organization code can also be used for processing invoicing, reimbursement and the like, and can also be used for identifying the membership of the organization member in the organization, for example, the organization code is used as a digital employee card of an enterprise employee, and the enterprise employee can obtain benefits and subsidies issued by the enterprise for the voucher through the organization code.

Optionally, the institution code is bound with an institution funding account, the institution funding account includes a financial account opened by the institution on a payment platform, the institution account is used for order payment for an order to be paid of an institution member, and the institution account may also be a financial account opened by the institution at another financial institution.

The order to be paid comprises an order to be paid, the order to be paid has a corresponding order type, for example, the order type of the order to be paid comprises a dining order, a travel order, an accommodation order and the like, and the dining order further comprises a take-out order, a social order and/or a group meal order; optionally, the amount of the payment resource, the participant identifier of the participant of the order and/or the transaction time are recorded in the order to be paid.

The order participants carried in the order to be paid comprise participants providing commodities or services to organization members, for example, the order participants are merchants providing commodities under the condition that the order to be paid is an order of the commodities to be paid, and the order participants are service providers providing travel services under the condition that the order to be paid is an order of a trip to be paid.

The participant identifier of the order participant includes an ID (identity document) of the order participant; such as a merchant identification of a merchant or a provider identification of a service provider.

Optionally, the order to be paid is submitted based on the organization code of the organization to which the organization member belongs. In one case, an organization member may go to an offline store of a merchant or a service provider to pay, and submit an order to be paid through an organization code displayed by a member terminal of a code scanning device scanning organization member configured by the merchant or the service provider, and optionally, submit the order to be paid after the organization code displayed by the member terminal of the code scanning organization member configured by the order participant; in another case, the organization member may also submit the organization code based on the organization code service binding after scanning the identification code configured by the merchant or the service provider through the image acquisition component of the organization code service call member terminal, and optionally, the order to be paid submits the organization code based on the organization code service binding after scanning the identification code configured by the merchant or the service provider through the image acquisition component of the organization code service call member terminal.

The organization code service is a service for providing spreading codes of organization codes, generation of organization codes and the like; the organization code service includes an application level independently running on a member terminal of an organization member, or a sub program (applet) carried in a third-party application independently running on a member terminal of an organization member, or a web page.

In practical application, the institution may be provided with different institution payment types, such as a catering payment type, a trip payment type, and an accommodation payment type, and after the machine constituent member submits the order to be paid, since different institution payment types may correspond to different funding strategies, the institution payment type of the order to be paid may be determined, and payment processing under the institution payment type may be performed.

In specific implementation, the organization member submits an order to be paid, detects a participant identifier of an order participant carried in the order to be paid of the organization member, so as to detect whether the order to be paid of the organization member carries the participant identifier of the order participant, and if the detection result is empty, executes the following step S104; if the detection result is not null, the institution payment type of the order to be paid may be determined according to the detected participant identifier, and in an optional implementation manner provided in this embodiment, after the participant identifier of the order participant carried in the order to be paid of the detection institution member is executed, the following operations are further executed:

if the detection result is not null, determining the mechanism payment type of the order to be paid according to the detected participant identification;

and under the condition that the payment is successfully determined, performing payment processing on the order to be paid according to a funding strategy corresponding to the determined mechanism payment type.

The institution payment type refers to a payment type configured by an institution, such as a catering payment type, a trip payment type and a lodging payment type, and the institution pays an order to be paid in the institution payment type.

Specifically, if the detection result is not null, determining the type of the participant according to the detected participant identifier, determining the mechanism payment type of the order to be paid according to the type of the participant, and under the condition that the determination is successful, performing payment processing on the order to be paid according to a payment strategy corresponding to the determined mechanism payment type.

Wherein, the mechanism payment type determination of the order to be paid according to the participant type comprises: matching the participant type with the payment types of all the institutions in the institution payment type set to obtain the institution payment type of the order to be paid; or, according to the participant type, calculating the prediction probability of each institution payment type in the institution payment type set; and determining the institution payment type of the order to be paid in the institution payment types based on the predicted probability.

The payment processing of the order to be paid according to the determined funding strategy corresponding to the payment type of the institution comprises the following steps: if the funding strategy is the first funding strategy, determining the resource quota of the mechanism member at the order effective time of the order to be paid; transferring out resources from the mechanism funding account corresponding to the mechanism payment type based on the resource quota, and transferring the transferred-out resources to the resource account of the order participant; or if the funding strategy is a second funding strategy, transferring resources from the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid, and transferring the transferred resources to the resource account of the order participant; or if the funding strategy is a third funding strategy, performing accounting processing on the institution funding account corresponding to the institution payment type according to the payment resource amount of the order to be paid so as to perform periodic settlement on the order participant.

In addition, if the detection result is not null, the information of the participant of the order participant can be inquired according to the detected participant identification, the mechanism payment type of the order to be paid is determined according to the information of the participant, and the payment processing is carried out on the order to be paid according to the paying strategy corresponding to the determined mechanism payment type under the condition that the determination is successful.

In an optional implementation manner provided by this embodiment, after the determining and executing the institution payment type of the order to be paid is performed according to the detected participant identifier if the detection result is not null, the following operations are further executed:

and under the condition that the determination fails, skipping to the operation of reading the order data of the order to be paid and acquiring payment extension data for execution.

And step S104, if the detection result is null, reading the order data of the order to be paid and acquiring payment extension data.

In the step, if the detection result is null, reading order data of the order to be paid and acquiring payment extension data.

The order data of the order to be paid in this embodiment refers to data recorded in the order to be paid; the order data of the order to be paid comprises payment resource amount, order generation time, order payment time and/or boarding time; optionally, the order data of the order to be paid is determined according to the order type of the order to be paid, for example, the order to be paid is an order of a commodity to be paid, and the order data is payment resource amount, order generation time and/or order payment time; the order to be paid is a trip order to be paid, and the order data is payment resource amount, order generation time, order payment time and/or boarding time.

The payment extended data refers to extended data or auxiliary data in the process of carrying out payment processing on the order to be paid; optionally, the payment extension data includes order data in the to-be-paid order, related data related to the to-be-paid order, and/or historical order data of the organization member, for example, the to-be-paid order is a to-be-paid travel order, and the payment extension data includes an inbound order in the to-be-paid travel order, an outbound order in the to-be-paid travel order, inbound time, outbound time, and/or historical travel order data of the organization member, where the historical travel order data includes order data of travel orders of the organization member in historical inbound time and outbound time.

In specific implementation, if a detection result after the participant identification of the order participant carried in the to-be-paid order of the detection mechanism member is null, reading order data of the to-be-paid order and acquiring payment extended data; in addition, in the process of reading the order data of the order to be paid and acquiring the payment extension data, the following operations may be performed:

and reading a key field corresponding to the order type of the order to be paid, and reading an extension field corresponding to the order type.

For example, the order type of the order to be paid is a catering order type, and a key field corresponding to the catering order type is read: catering amount and order payment time, and reading an extension field corresponding to the order type: a place of dining; for another example, the order type of the order to be paid is a travel order type, and a key field corresponding to the travel order type is read: paying the amount and the payment time, and reading an extension field corresponding to the type of the travel order: historical order payment amount, historical order payment time, inbound site, inbound time, outbound site, outbound time.

It should be noted that, instead of reading the order data of the order to be paid or acquiring the payment extension data if the detection result is null, the step S104 may be implemented in a new manner with the other processing steps provided in this embodiment.

Step S104 may also be replaced by reading a key field corresponding to the order type of the order to be paid or reading an extension field corresponding to the order type if the detection result is null, and forming a new implementation manner with the other processing steps provided in this embodiment.

And S106, determining the mechanism payment type of the order to be paid according to the order data and the payment extended data.

In the step, the mechanism payment type of the order to be paid is determined according to the order data and the payment extended data.

The institution payment type in this embodiment refers to a payment type configured by an institution, such as a catering payment type, a travel payment type, and an accommodation payment type, and the institution may pay an order to be paid in the institution payment type.

In a specific implementation, in order to determine the mechanism payment type of the order to be paid, a mechanism payment type set may be configured in advance, where the mechanism payment type set is a set composed of one or more mechanism payment types, and the order data and the payment extension data are matched with each mechanism payment type in the mechanism payment type set to obtain the mechanism payment type, that is, the mechanism payment type corresponding to the order to be paid, in an optional implementation manner provided in this embodiment, in a process of determining the mechanism payment type of the order to be paid according to the order data and the payment extension data, the following operations are performed:

and matching the order data, the payment extension data and the payment types of the institutions in the institution payment type set to obtain the institution payment type of the order to be paid.

The operation executed in the process of determining the mechanism payment type of the order to be paid according to the order data and the payment extension data can be replaced by matching the order data and/or the payment extension data with the mechanism payment types in the mechanism payment type set to obtain the mechanism payment type of the order to be paid, and a new implementation mode is formed by the operation and other processing steps provided by the embodiment;

or the method can be replaced by matching the order data with the payment types of the institutions in the institution payment type set to obtain a first institution payment type matched with the order data, matching the payment extended data with the payment types of the institutions in the institution payment type set to obtain a second institution payment type matched with the payment extended data, determining the institution payment type of the order to be paid according to the first institution payment type and the second institution payment type, and forming a new implementation manner with other processing steps provided by the embodiment;

or the order data and the payment types of the institutions are centralized to carry out matching processing, if the matching is successful, the payment types of the institutions obtained by matching are used as the payment types of the institutions of the order to be paid; and if the matching fails, matching the payment extension data with the payment types of the institutions concentrated by the payment types of the institutions to obtain the payment types of the orders to be paid, and forming a new implementation mode with other processing steps provided by the embodiment.

In order to improve the accuracy of the mechanism payment type determination, the obtained prediction probability of each mechanism payment type may be calculated according to the order data and/or the payment extension data, the mechanism payment type is determined among the mechanism payment types, the mechanism payment type of the order to be paid is determined in a manner of calculating the prediction probability of each mechanism payment type configured for the mechanism for the order to be paid, and the comprehensiveness and the accuracy of the mechanism payment type determination are improved.

Calculating the prediction probability of each institution payment type in the institution payment type set according to the order data and the payment extension data;

and determining the institution payment type of the order to be paid in the institution payment types based on the predicted probability.

Specifically, according to the order data and the payment extension data, the forecasting probability that the mechanism payment type of the order to be paid is the mechanism payment type of each mechanism in the mechanism payment type set is calculated, the forecasting probabilities of the mechanism payment types are sequenced, and the mechanism payment type of the sequencing position at the preset position is determined as the mechanism payment type of the order to be paid.

In addition, in the process of determining the institution payment type of the order to be paid according to the order data and the payment extension data, in order to improve the type determination efficiency, a type determination model may also be introduced, and specifically, the institution payment type determination of the order to be paid may be implemented by adopting the following method: and inputting the order data and/or the payment extension data into the type determination model to determine the institution payment type, and obtaining the institution payment type of the order to be paid.

In a specific implementation process, after determining and executing the institution payment type of the order to be paid according to the order data and the payment extension data, in an optional implementation manner provided by this embodiment, the following operations are performed:

and if the payment type is determined successfully, performing payment processing on the order to be paid according to a funding strategy corresponding to the determined mechanism payment type.

The payment processing of the order to be paid according to the funding strategy corresponding to the determined mechanism payment type comprises the following steps: if the funding strategy is a first funding strategy, determining a resource quota of the mechanism member at the order effective time of the order to be paid; transferring out resources from the institution funding account corresponding to the institution payment type based on the resource quota, and transferring the transferred-out resources into the resource account of the order participant;

and if the funding strategy is a second funding strategy, transferring out resources from the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid, and transferring the transferred-out resources into the resource account of the order participant.

And if the funding strategy is a third funding strategy, performing accounting processing on the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid so as to perform periodic settlement on the order participant.

In practical applications, an organization may set a payment policy for organization members, and perform payment constraint verification on an order to be paid, for example, the organization performs payment processing after passing the verification for a daily meal fee of 30 yuan set by an employee of a department a and 50 yuan set by an employee of a department b, so as to avoid resource loss of the organization, in an optional implementation manner provided in this embodiment, before performing payment processing on the order to be paid according to a funding policy corresponding to a determined payment type of the organization, the following operations are further performed if the payment type is determined successfully:

performing payment constraint verification on the order to be paid according to the payment constraint strategy of the organization member under the determined organization payment type;

and if the verification is passed, executing the payment processing step on the order to be paid according to the funding strategy corresponding to the determined mechanism payment type if the payment type is determined successfully.

The payment constraint strategy comprises a payment control strategy, such as 30 yuan per day for employees in department a and 50 yuan per day for employees in department b; and the payment constraint verification comprises verification processing of the payment resource amount of the order to be paid.

Specifically, after the mechanism payment type of the order to be paid is determined, and under the condition that the payment type is successfully determined, the payment constraint verification is performed on the order to be paid according to the payment strategy of the mechanism member under the determined mechanism payment type, and if the verification is successful, the payment processing operation is performed on the order to be paid according to the funding strategy corresponding to the determined mechanism payment type.

It should be noted that step S106 may be replaced by determining the mechanism payment type of the order to be paid according to the order data or the payment extension data, and forming a new implementation manner with the other processing steps provided in this embodiment;

step S106 may also be replaced by determining the institution payment type of the order to be paid according to the key field corresponding to the order type of the order to be paid or reading the extension field corresponding to the order type, and forming a new implementation manner with the other processing steps provided in this embodiment.

And S108, if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

In this step, if the payment type determination fails, payment processing is performed on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set, so that flexibility of payment processing is realized.

The institution payment type set in this embodiment refers to a set composed of one or more institution payment types; the funding strategy refers to a strategy or a mode for transferring out resources in the process of payment processing of the order to be paid, and the funding strategy comprises a funding mode or a resource processing mode.

Optionally, the funding policy is configured in the following manner: acquiring payment types of all institutions configured for the institution codes through subprograms or webpages; and setting corresponding financing strategies for the payment types of the organizations.

Optionally, the funding policy includes at least one of: pre-funding policies, agreement funding policies, real-time funding policies.

The agreement financing strategy comprises a strategy of carrying out financing settlement according to a settlement period agreed by an institution and an order participant agreement, for example, the institution and a merchant carry out periodic settlement according to a settlement period of one month; the pre-funding policy includes a policy that the resource quota allocated to the mechanism member by the pre-support mechanism transfers resources to the order participants, for example, the resource quota pre-supported the next day transfers resources to the order participants waiting for paying the order on the same day; the real-time funding strategy comprises a strategy of carrying out resource transfer to the order participants in real time according to the institution funding account.

In practical application, the number of members of the institution may be large, and there are situations where a large number of institution members submit orders to be paid in institution payment types, and if an institution sets up an institution funding account, resources of account resources may be insufficient, resulting in poor experience of institution members.

Optionally, each institution payment type in the institution payment type set is configured with a corresponding institution funding account and/or funding account; optionally, the funding account is configured to perform resource transfer processing on the order to be paid after detecting that the resource amount of the account available resources of the institution funding account is smaller than the order resource amount of the order to be paid.

The institution funding account refers to a resource account for transferring resources to an order participant by an institution, and comprises a financial account opened by the institution in a financial institution or a payment platform; the bedding account comprises a resource account for bedding payment of the orders to be paid of the members of the organization.

In addition, in a scene that the number of institution members of an actual large institution is large, the institution payment type set target institution payment type can be configured with one or more institution funding accounts; the target institution payment type is determined according to institution payment types of historical payment orders of institution members of the institution and/or behavior preference data of the institution members. For example, if the institution payment types of the historical payment orders submitted by institution members of a large enterprise are concentrated in the trip payment type, a plurality of institution funding accounts can be set for the trip payment type, and one institution funding account is set for the rest catering payment types and accommodation payment types, so that the situation that the orders to be paid in the institution payment type concentration cannot be paid by using the institution funding accounts is effectively avoided, and the payment effectiveness of the orders to be paid is improved.

In order to improve the experience of the organization members and avoid that the order to be paid cannot be paid due to insufficient resource quota of the organization members, the organization members can pre-support own resource quota, for example, if the resource quota of the organization members in the current month is insufficient, the resource quota of the next month can be pre-supported in the current month, and the takeout order of the next month is pre-determined, but the takeout order is paid in the current month, or if the resource quota of the organization members in the current month is insufficient, the resource quota of the next day can be pre-supported to pay the takeout order, that is, the takeout order of the next day is pre-determined, and the takeout order is delivered in the next day.

In a first optional implementation manner provided by this embodiment, in the process of performing payment processing on an order to be paid according to a funding policy corresponding to an institution payment type selected by an institution member in an institution payment type set, the following operations are performed:

if the funding strategy is a first funding strategy, determining a resource quota of the mechanism member at the order effective time of the order to be paid;

and transferring out resources from the mechanism funding account corresponding to the mechanism payment type based on the resource quota, and transferring the transferred-out resources into the resource account of the order participant.

The order taking-in time refers to the time for taking the order to be paid into effect, and the order taking-in time includes delivery time of goods in the order to be paid or service providing time in the order to be paid, for example, the order to be paid is a takeout order, the takeout order is a number 1 payment order, and a number 2 delivery order. The first funding policy includes a pre-funding policy. The resource quota comprises the amount of the resource distributed to the members of the organization by the organization.

In addition to the above situation of the pre-paid resource quota, the resource quota of the mechanism member may also be sufficient for paying the order to be paid, in this case, in order to transfer the resource to the order participant in time, in a second optional implementation manner provided in this embodiment, in a process of performing payment processing on the order to be paid according to a funding policy corresponding to a mechanism payment type collectively selected by the mechanism member in a mechanism payment type set, the following operations are performed:

and if the funding strategy is a second funding strategy, transferring out resources from the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid, and transferring the transferred-out resources into the resource account of the order participant.

Wherein the second funding policy comprises a real-time funding policy. The payment resource amount refers to the resource amount to be paid recorded in the order to be paid.

In addition, the institution and the order participant may also have long-term cooperation, in this case, in order to improve the efficiency of payment processing, avoid that each order to be paid submitted by the institution members settles with the order participant in real time, and reduce the payment efficiency, thereby affecting the member experience of the institution members, the institution and the order participant may book an institution funding account of the institution payment type according to the payment resource amount of the order to be paid, and settle according to an agreed settlement period, in the third optional implementation manner provided in this embodiment, in the process of performing payment processing on the order to be paid according to the funding policy corresponding to the institution payment type centrally selected by the institution members in the institution payment type, the following operations are performed:

and if the funding strategy is a third funding strategy, performing accounting processing on the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid so as to perform periodic settlement on the order participant.

Wherein the third funding policy comprises an agreement funding policy.

Specifically, if the funding policy is the third funding policy, the mechanism funding account corresponding to the mechanism payment type may be booked according to the payment resource amount of the order to be paid, and a booked result may be generated and sent to the order participant of the order to be paid, so as to perform periodic settlement to the order participant according to the booked result.

In summary, in the payment processing method provided in this embodiment, first, a participant identifier of an order participant carried in an order to be paid of a mechanism member is detected, if a detection result is null, order data of the order to be paid is read and payment extension data is obtained, mechanism payment type determination of the order to be paid is performed according to the order data and the payment extension data, and if the payment type determination fails, if a funding policy is a first funding policy, a resource quota of the mechanism member at an order effective time of the order to be paid is determined; transferring out resources from the mechanism funding account corresponding to the mechanism payment type based on the resource quota, and transferring the transferred-out resources into a resource account of an order participant;

if the funding strategy is the second funding strategy, transferring out resources from the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid, and transferring the transferred-out resources into the resource account of the order participant; if the funding strategy is the second funding strategy, transferring out the resources from the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid, and transferring the transferred-out resources into the resource account of the order participant, so that the flexibility of payment processing is improved, and the user experience is improved.

The following further describes the payment processing method provided in this embodiment by taking an application of the payment processing method provided in this embodiment in a restaurant payment scenario as an example, and referring to fig. 2, the payment processing method applied in the restaurant payment scenario specifically includes the following steps.

Step S202, detecting a merchant identifier of a catering merchant carried in the to-be-paid catering order of the organization member.

Optionally, the order to be paid is submitted based on the organization code of the organization to which the organization member belongs.

And step S204, if the detection result is empty, reading a key field corresponding to the order type of the catering order to be paid and an extension field corresponding to the order type.

And step S206, matching the key fields and the extension fields with the payment types of the organizations in the organization payment type set to obtain the payment types of the organizations for catering orders to be paid.

And step S208, determining the resource quota of the order effective time of the restaurant order to be paid by the institution member.

And S210, transferring out resources from the mechanism funding account corresponding to the mechanism payment type based on the resource quota, and transferring the transferred-out resources to the resource account of the catering merchant.

The following further describes the payment processing method provided in this embodiment by taking an application of the payment processing method provided in this embodiment in a trip payment scenario as an example, and referring to fig. 3, the payment processing method applied in the trip payment scenario specifically includes the following steps.

Step S302, detecting the participant identification of the order participant carried in the to-be-paid travel order of the organization member.

Step S304, if the detection result is null, reading the order data of the travel order to be paid, and acquiring the order data of the historical travel order of the organization member.

Step S306, calculating the prediction probability of the payment types of each mechanism in the payment type set of the mechanism according to the order data of the trip order to be paid and the order data of the historical trip order.

And step S308, determining the institution payment type of the travel order to be paid in each institution payment type based on the prediction probability.

And S310, if the payment type is determined successfully, transferring out the resources from the institution funding account corresponding to the institution payment type according to the payment resource amount of the trip order to be paid, and transferring the transferred-out resources into the resource account of the order participant.

An embodiment of a payment processing apparatus provided in this specification is as follows:

in the above embodiments, a payment processing method is provided, and a payment processing apparatus is provided, which is described below with reference to the accompanying drawings.

Referring to fig. 4, a schematic diagram of a payment processing apparatus provided in the present embodiment is shown.

Since the device embodiments correspond to the method embodiments, the description is relatively simple, and the relevant portions may refer to the corresponding description of the method embodiments provided above. The device embodiments described below are merely illustrative.

The present embodiment provides a payment processing apparatus, including:

an identification detection module 402 configured to detect a participant identification of an order participant carried in an order to be paid by a member of the organization; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is null, operating a data reading module 404, where the data reading module 404 is configured to read order data of the order to be paid and obtain payment extension data;

a type determination module 406, configured to perform institution payment type determination of the order to be paid according to the order data and the payment extension data;

if the payment type determination fails, a payment processing module 408 is operated, and the payment processing module 408 is configured to perform payment processing on the order to be paid according to a funding policy corresponding to the institution payment type selected by the institution member in the institution payment type set.

An embodiment of a payment processing apparatus provided in this specification is as follows:

corresponding to the above-described payment processing method, based on the same technical concept, one or more embodiments of the present specification further provide a payment processing apparatus, where the payment processing apparatus is configured to execute the above-described provided payment processing method, and fig. 5 is a schematic structural diagram of the payment processing apparatus provided in one or more embodiments of the present specification.

The embodiment provides a payment processing device, which comprises:

as shown in fig. 5, the payment processing apparatus may have a relatively large difference due to different configurations or performances, and may include one or more processors 501 and a memory 502, where the memory 502 may store one or more stored applications or data. Memory 502 may be, among other things, transient storage or persistent storage. The application program stored in memory 502 may include one or more modules (not shown), each of which may include a series of computer-executable instructions in the payment processing apparatus. Still further, the processor 501 may be configured to communicate with the memory 502 to execute a series of computer-executable instructions in the memory 502 on the payment processing device. The payment processing apparatus may also include one or more power supplies 503, one or more wired or wireless network interfaces 504, one or more input/output interfaces 505, one or more keyboards 506, and the like.

In one particular embodiment, a payment processing apparatus 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 processing apparatus, and configured for execution by the one or more processors the one or more programs include computer-executable instructions for:

detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is empty, reading order data of the order to be paid and acquiring payment extension data;

determining the mechanism payment type of the order to be paid according to the order data and the payment extended data;

and if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

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

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

The present embodiment provides a storage medium for storing computer-executable instructions, which when executed by a processor implement the following procedures:

detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is empty, reading order data of the order to be paid and acquiring payment extension data;

determining the mechanism payment type of the order to be paid according to the order data and the payment extended data;

and if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

It should be noted that the embodiment of the storage medium in this specification and the embodiment of the payment processing method in this specification are based on the same inventive concept, and therefore, specific implementation of this embodiment may refer to implementation of the foregoing corresponding method, and repeated details are not repeated.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may 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 may also be possible or may be advantageous.

In the 30's of the 20 th century, improvements in one technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry for implementing the logical method flows can be readily obtained by a mere need to program the method flows with some of the hardware description languages described above and into an integrated circuit.

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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, apparatuses, modules or units described in the above embodiments may be specifically implemented by a computer chip or an entity, or implemented by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, 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 divided into various units by function, respectively. Of course, the functions of the various elements may be implemented in the same one or more pieces of software and/or hardware in practicing embodiments of the present description.

One skilled in the art will appreciate 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 description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.

The description has been presented with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the description. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams 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 a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

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 computer storage media 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 disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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 phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of other like elements in a process, method, article, or apparatus comprising the element.

One or more embodiments of the 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.

All the embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of this document and is not intended to limit this document. Various modifications and changes may occur to those skilled in the art from this document. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of this document shall be included in the scope of the claims of this document.

Claims (15)

1. A payment processing method, comprising:

detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is empty, reading order data of the order to be paid and acquiring payment extension data;

determining the mechanism payment type of the order to be paid according to the order data and the payment extended data;

and if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

2. The payment processing method according to claim 1, wherein the performing payment processing on the order to be paid according to a funding policy corresponding to an institution payment type selected by the institution member in the institution payment type set includes:

if the funding strategy is a first funding strategy, determining a resource quota of the mechanism member in order effective time of the order to be paid;

and transferring out resources from the institution funding account corresponding to the institution payment type based on the resource quota, and transferring the transferred-out resources into the resource account of the order participant.

3. The payment processing method of claim 1, wherein the performing payment processing on the order to be paid according to a funding policy corresponding to an institution payment type selected by the institution member in the institution payment type set comprises:

and if the funding strategy is a second funding strategy, transferring out resources from the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid, and transferring the transferred-out resources into the resource account of the order participant.

4. The payment processing method according to claim 1, wherein the performing payment processing on the order to be paid according to a funding policy corresponding to an institution payment type selected by the institution member in the institution payment type set includes:

and if the funding strategy is a third funding strategy, performing accounting processing on the mechanism funding account corresponding to the mechanism payment type according to the payment resource amount of the order to be paid so as to perform periodic settlement on the order participant.

5. The payment processing method of claim 1, the making of the establishment payment type determination of the order to be paid according to the order data and the payment extension data, comprising:

and matching the order data and the payment extension data with the payment types of all the institutions in the institution payment type set to obtain the institution payment type of the order to be paid.

6. The payment processing method of claim 1, the making of the establishment payment type determination of the order to be paid according to the order data and the payment extension data, comprising:

calculating the prediction probability of each institution payment type in the institution payment type set according to the order data and the payment extension data;

and determining the institution payment type of the order to be paid in the institution payment types based on the predicted probability.

7. The payment processing method according to claim 1, after the step of detecting the participant identifier of the order participant carried in the to-be-paid order of the institution member is executed, further comprising:

if the detection result is not null, determining the mechanism payment type of the order to be paid according to the detected participant identification;

and under the condition that the payment is successfully determined, performing payment processing on the order to be paid according to a funding strategy corresponding to the determined mechanism payment type.

8. The payment processing method of claim 7, wherein after the step of determining the institution payment type of the order to be paid according to the detected participant identity is executed if the detection result is not null, the method further comprises:

and under the condition of failure in determination, skipping to the operation of reading the order data of the order to be paid and acquiring payment extension data for execution.

9. The payment processing method of claim 1, further comprising, after the step of determining the institution payment type of the order to be paid is performed according to the order data and the payment extension data, the step of:

and if the payment type is determined successfully, performing payment processing on the order to be paid according to a funding strategy corresponding to the determined mechanism payment type.

10. The payment processing method of claim 9, wherein before the payment processing step is executed for the order to be paid according to the funding policy corresponding to the determined institution payment type if the payment type is determined successfully, the method further comprises:

performing payment constraint verification on the order to be paid according to the payment constraint strategy of the organization member under the determined organization payment type;

and if the verification is passed, executing the payment processing step of the order to be paid according to the funding strategy corresponding to the determined mechanism payment type if the payment type is determined successfully.

11. The payment processing method of claim 1, the funding policy configured as follows:

acquiring payment types of all institutions configured for the institution codes through subprograms or webpages;

setting corresponding financing strategies for payment types of all institutions;

wherein the funding policy includes at least one of: pre-funding policy, agreement funding policy, real-time funding policy.

12. The payment processing method of claim 1, wherein the set of institution payment types is configured with a corresponding institution funding account and/or funding account for each institution payment type;

the funding account is used for performing resource transfer processing on the order to be paid after detecting that the resource amount of the account available resources of the institution funding account is smaller than the order resource amount of the order to be paid.

13. A payment processing apparatus comprising:

the identification detection module is configured to detect the participant identification of the order participant carried in the to-be-paid order of the organization member; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is null, operating a data reading module, wherein the data reading module is configured to read order data of the order to be paid and acquire payment extension data;

the type determining module is configured to determine the mechanism payment type of the order to be paid according to the order data and the payment extension data;

and if the payment type determination fails, operating a payment processing module, wherein the payment processing module is configured to perform payment processing on the order to be paid according to a funding strategy corresponding to the institution payment type selected by the institution member in the institution payment type set.

14. A payment processing apparatus comprising:

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

detecting a participant identifier of an order participant carried in an order to be paid of a mechanism member; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is empty, reading order data of the order to be paid and acquiring payment extension data;

determining the mechanism payment type of the order to be paid according to the order data and the payment extension data;

and if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

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

detecting participant identifications of order participants carried in the to-be-paid orders of the members of the organization; submitting the order to be paid based on the organization code of the organization to which the organization member belongs;

if the detection result is empty, reading order data of the order to be paid and acquiring payment extension data;

determining the mechanism payment type of the order to be paid according to the order data and the payment extended data;

and if the payment type determination fails, performing payment processing on the order to be paid according to a funding strategy corresponding to the mechanism payment type selected by the mechanism member in the mechanism payment type set.

Images