CN110827014A

CN110827014A - Riding payment method and system based on enterprise account, enterprise terminal and user terminal

Info

Publication number: CN110827014A
Application number: CN201811140629.0A
Authority: CN
Inventors: 谌子奇; 卢祖传; 李继雄
Original assignee: Wuhan Xiaoma Liancheng Technology Co Ltd
Current assignee: Wuhan Xiaoma Liancheng Technology Co Ltd
Priority date: 2018-09-28
Filing date: 2018-09-28
Publication date: 2020-02-21

Abstract

The invention discloses a riding payment method based on an enterprise account, which comprises the following steps: the enterprise terminal receives a code sending request from the user terminal; generating a riding code containing the enterprise ID and feeding back the riding code to the user terminal; and the enterprise end receives the deduction condition returned by the background server after deducting the verification condition information of the bus code based on the POS end machine. According to the invention, the user terminal is associated with the enterprise terminal, when payment is required, the enterprise terminal sends the bus code to the user terminal, and the employee only needs to provide the bus code to the POS terminal machine, so that the background server can deduct money from the account of the enterprise terminal. When the reimbursement demand exists, the enterprise end is directly connected with the background server in a butt joint mode. The whole travel payment and subsequent reimbursement are very convenient, the staff is not required to pay the bus fee, the invoice is not required to be requested every time, and the bus taking record of the staff can be monitored. The invention can replace manpower and improve the working efficiency. The invention also provides a riding payment system based on the enterprise account, a client and a user terminal.

Description

Riding payment method and system based on enterprise account, enterprise terminal and user terminal

Technical Field

The invention relates to the technical field of mobile payment, in particular to a riding payment method and system based on an enterprise account, an enterprise terminal and a user terminal.

Background

In order to promote good development of economy, the country strongly advocates 'public entrepreneurship and public innovation', newly established enterprises are built like bamboo shoots in the spring after rain, and business staff goes on business, field service and the like, and related traffic charge reimbursement matters are more and more frequent. Because the expense reimbursement needs a corresponding invoice, at present, the passenger expense can only be paid by staff firstly, and then the expense reimbursement is applied to a company after the invoice is required on a bus or a subway station. In view of the characteristics of low public transportation cost, high frequency, troublesome invoice claim and the like, the whole reimbursement process easily consumes a large amount of manpower. In addition, a third party is often lacked to monitor in the business trip process, and the situation of multiple reimbursements cannot be avoided.

In recent years, the public transportation industry has become more and more popular with code-scanning payments. A code scanning payment system generally includes a user terminal (such as a mobile phone) located at a user side and a collection device at a bus or subway gate. The passenger can use client software in the user terminal device to generate a two-dimensional code for the collection device to read, and payment is realized after certain verification. The conventional cash register generally comprises a POS terminal machine (such as a card swiping machine of a bus or a subway gate) for identifying and verifying the two-dimensional code and a background server for completing operations such as deduction, and in some cases, the POS terminal machine and the background server can be integrated together. The mainstream client software supporting the code-scanning riding function on the user terminal comprises a payment treasure, a WeChat and the like, in order to guarantee the user code-swiping boarding experience and accelerate boarding speed, the payment treasure and the WeChat realize 'payment after code-swiping' of the user based on the existing personal account system of the user, namely after the user code-swiping boarding, the riding amount is automatically deducted from the user account, the user does not need to input a payment password, and the riding code-swiping operation steps are reduced. The scheme can improve the efficiency of bus payment, and the client software records the payment time and the corresponding amount after code scanning payment, so that a certain supervision effect can be achieved, and multiple reimbursements are avoided. However, these methods do not fundamentally solve the manual reimbursement mode, and people mostly have fixed thinking, which is considered as financial work, and never consider solving similar problems by technical means. In view of this, it is necessary to provide an intelligent solution to replace manual work and improve work efficiency.

Disclosure of Invention

In view of the above, the present invention has been developed to provide a method and system for corporate account based ride payment that overcomes, or at least partially addresses, the above-identified problems.

In a first aspect, an embodiment of the present invention provides a riding payment method based on an enterprise account, including the following steps:

the enterprise terminal receives a code sending request from the user terminal;

generating a riding code containing the enterprise ID and feeding back the riding code to the user terminal;

and the enterprise end receives the deduction condition returned by the background server after deducting the verification condition information of the riding code based on the POS terminal.

In a second aspect, based on the same inventive concept, an embodiment of the present invention further provides a riding payment method based on an enterprise account, including the following steps:

the user terminal judges the network condition of the user terminal, and if the user terminal is networked, the user terminal sends a code sending request to the enterprise terminal;

receiving a riding code containing an enterprise ID sent by an enterprise terminal;

and the user terminal requests the POS terminal equipment to verify the riding code.

In a third aspect, based on the same inventive concept, an embodiment of the present invention further provides a riding payment system based on an enterprise account, where the system includes an enterprise terminal, a user terminal, a POS terminal, and a background server, where:

the enterprise terminal is used for receiving a code sending request from the user terminal; generating a riding code containing the enterprise ID and feeding back the riding code to the user terminal; receiving a deduction condition returned by the background server after deduction is carried out on the verification condition information of the riding code based on a POS (point of sale) end machine;

the user terminal is used for judging the network condition of the user terminal, and sending a code sending request to the enterprise terminal if the user terminal is networked; receiving a riding code containing an enterprise ID sent by an enterprise terminal; requesting the POS terminal equipment to verify the riding code;

the background server is used for distributing enterprise IDs to the enterprise end, completing a money deduction operation according to received information of the verification condition of the POS end machine on the riding codes and sending the money deduction condition to the enterprise end;

and the POS terminal machine is used for verifying the riding code displayed by the user terminal, and sending the verification condition information to the background server after the verification is passed.

In a fourth aspect, based on the same inventive concept, an embodiment of the present invention further provides an enterprise side, including: code sending module, expense management module, wherein:

the code sending module is used for receiving a code sending request from a user terminal; generating a riding code containing the enterprise ID and feeding back the riding code to the user terminal;

and the fee management module is used for receiving a fee deduction condition returned by the background server after the fee deduction is carried out on the verification condition information of the riding code based on the POS terminal machine.

In a fifth aspect, based on the same inventive concept, an embodiment of the present invention further provides a user terminal, including:

the judging module is used for judging the network condition of the self-body;

the communication module is used for sending a code sending request and receiving a riding code generated by an enterprise terminal under the networking condition;

a code sending request generating module for generating a code sending request;

the storage module is used for storing the received riding codes;

and the display module is used for requesting the POS terminal equipment to verify the riding code.

The technical scheme provided by the embodiment of the invention has the beneficial effects that at least:

according to the invention, the user terminal is associated with the enterprise terminal, when payment is required, the enterprise terminal sends the bus code to the user terminal, and the employee only needs to provide the bus code to the POS terminal machine, so that the background server can deduct money from the account of the enterprise terminal. When the reimbursement demand exists, the enterprise end is directly connected with the background server in a butt joint mode. The whole travel payment and subsequent reimbursement are very convenient, the staff is not required to pay the bus fee, the invoice is not required to be asked every time, the riding record of the staff can be monitored, and the monitoring of the outwork condition of the whole staff is conveniently realized by the enterprise owner. The invention can completely replace manpower, and greatly improves the working efficiency.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

The technical solution of the present invention is further described in detail by the accompanying drawings and embodiments.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention and not to limit the invention. In the drawings:

fig. 1 is a schematic structural diagram of a bus taking payment system based on an enterprise account according to an embodiment of the present invention;

fig. 2 is an operation timing diagram of a bus taking payment system based on an enterprise account according to an embodiment of the present invention;

fig. 3 is an operation timing diagram of another riding payment system based on an enterprise account according to a second embodiment of the present invention;

fig. 4 is a flowchart of a bus taking payment method based on an enterprise account according to a third embodiment of the present invention;

FIG. 5 is a flowchart illustrating a bus taking payment method based on an enterprise account according to a different situation in step S301 in FIG. three;

FIG. 6 is a schematic structural diagram of an enterprise side according to an embodiment of the present invention;

fig. 7 is a flowchart of another method for payment by bus based on an enterprise account according to a fourth embodiment of the present invention;

fig. 8 is a schematic structural diagram of a user terminal in an embodiment of the present invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

In order to solve the problems of non-intelligent reimbursement and low efficiency of travel expenses in the prior art, the embodiment of the invention provides a riding payment method based on an enterprise account.

Example one

The embodiment of the invention provides a bus taking payment system based on an enterprise account, the structural schematic diagram of the system is shown in fig. 1, and the system comprises an enterprise terminal 10, a user terminal 20, a background server 31 and a POS terminal device 32, wherein:

the enterprise terminal 10 is used for receiving a code sending request from the user terminal 20; generating a riding code containing the enterprise ID and feeding back the riding code to the user terminal 20; and receiving the deduction condition returned by the background server 31 after deducting the check condition information of the riding code based on the POS terminal tool 32.

The user terminal 20 is used for judging the network condition of the user terminal, and if the user terminal is networked, the user terminal sends a code sending request to the enterprise terminal 10; receiving a riding code containing an enterprise ID sent by an enterprise terminal 10; and request verification of the ride code from the POS end-piece 32.

And the background server 31 is configured to allocate an enterprise ID to the enterprise terminal 10, complete a deduction operation after receiving the information of the verification condition of the riding code by the POS terminal tool 32, and send the deduction condition to the enterprise terminal 10.

And the POS terminal 32 is configured to verify the riding code displayed by the user terminal 20, and send the verification condition information to the background server 31 after the verification is passed.

With reference to fig. 2, the system works as follows:

step S101: the enterprise terminal 10 is connected with the background server 31 to complete information registration and cost recharging, and the background server 31 allocates enterprise ID to the enterprise.

Specifically, the enterprise terminal 10 submits the basic information such as the enterprise name, the contact person, the contact information and the like to the background server 31, and completes the fee charging. The background server 31 assigns the enterprise ID to the enterprise, and the subsequent bus payment process is executed according to the enterprise ID. The function of the background server 31 also includes clearing settlement, and can also be regarded as a clearing settlement mechanism.

Step S102: the enterprise terminal 10 assigns a user ID to the user.

The purpose of assigning the user ID is to help the enterprise terminal 10 accurately identify its own employee during the bus payment process, and the application does not limit the rule of assigning the user ID. For example, the user ID may be assigned in accordance with the order of employee attendance time, or the user ID corresponding to each department may be set in accordance with the corporate organization shelf. Of course, for better supervision and management of the travel situation of each employee, it is preferable that each employee is assigned a unique user ID.

The order of steps S101, S102 may be adjusted according to the actual situation. The steps S101 and S102 are only needed to be executed once, and when the bus taking payment is needed, the steps S103 to S106 are repeatedly executed.

Step S103: when the vehicle payment is needed, the user terminal 20 determines the network status thereof, and if the network is connected, executes step S104.

The user terminal 20 may be a mobile phone, an IPAD, etc., and the client software installed thereon may be mainstream code scanning payment software such as a payment treasure, a WeChat, etc., office software such as a nail that can implement associated payment, or customized software, which is not limited in this embodiment of the present invention.

Step S104: the user terminal 20 sends a code sending request containing the user ID to the enterprise terminal 10, and the enterprise terminal 10 generates a riding code containing the enterprise ID and feeds the riding code back to the user terminal 20.

Specifically, according to the user ID in the code sending request, the enterprise terminal 10 determines whether the received code sending request is from the employee of the company, and if so, generates a riding code and feeds the riding code back to the user terminal 20, otherwise, refuses to generate the riding code. The composition of the ride code can be determined according to actual conditions, but must contain the enterprise ID.

In some cases, if the enterprise terminal 10 considers that all the sending requests to the trusted user terminals 20 are sent, step S102 may not be needed, and the user terminal 20 may send the sending request without the user ID in step S104. But from a security, monitorability perspective, the enterprise end 10 is advised to assign a user ID to the user.

Step S105: the POS end tool 32 verifies the ride code shown by the user terminal 20.

The user terminal 20 displays the riding code, the POS terminal 32 scans the code, analyzes the content of the riding code, and generally needs to separate the identity information and verify the identity information to prevent the two-dimensional code shown by the payer from being a non-riding code.

Step S106: after the verification is passed, the POS terminal 32 sends the verification information to the backend server 31 for a deduction operation.

The information of the verification condition of the POS terminal 32 on the riding code at least includes the enterprise ID and the user ID if necessary to monitor the traveling condition of the employee. Of course, the verification information should also include some parameters required by the settlement procedure of the backend server 31, and can be generated by the POS terminal 32 in addition to being extracted from the vehicle code. For example, for subway fees, fare needs to be calculated according to recorded inbound and outbound geographic positions; the fare from some buses 23 to 5 am is more expensive than the rest of the time period, etc. Accordingly, the information of the verification status sent by the POS terminal 32 should also include information of a station, information of a bus route, information of time for code scanning payment, and the like.

Step S107: the background server 31 sends the deduction condition to the enterprise terminal 10.

The background server 31 sends the deduction amount condition, such as user ID, payment amount, payment time, or even bus line condition, to the enterprise terminal 10.

Example two

In other embodiments, the enterprise 10 is further configured to configure riding rule rights for employees to better manage the traveling condition of the employees compared to the first embodiment. After the enterprise terminal 10 receives the code sending request sent by the user terminal 20, it is first determined whether the application of the employee meets the right of the riding rule, and if yes, the riding code is generated and fed back to the user terminal 20.

And the user terminal 20 is configured to determine a network status of the user when receiving a payment application from the user, send a code sending request to the enterprise terminal 10 if the user terminal is networked, receive a riding code sent by the enterprise terminal 10, and search a pre-stored and cached riding code containing the enterprise ID if the user terminal is not networked.

It is understood that the backend server 31 and the POS end tool 32 are generally separate and owned by the operator, and in some special cases, there may be a case where the backend server 31 is integrated with the POS end tool 32.

In connection with the timing diagram of the present system shown in fig. 3, the operation of the enterprise account based ride payment system is as follows:

step S201: the enterprise terminal 10 is connected with the background server 31 to complete information registration and cost recharging, and the background server 31 allocates enterprise ID to the enterprise.

Step S202: the enterprise terminal 10 assigns a user ID to the user and configures ride rules rights.

For better supervision and management of the travel situation of each employee, each employee is preferably assigned a unique user ID.

The right of the riding rule is configured to limit the riding times, riding time, riding amount and the like of the staff, so that the traveling condition of the staff can be better managed. For example, an upper limit of the number of times each employee can take the vehicle per month is set, and after a certain employee takes the vehicle beyond the upper limit, the vehicle cannot take the vehicle again in the month. Or the riding time of the staff is set as the working day, and the riding on holidays is not allowed. As another example, an upper limit on the amount of single use is set.

The steps S201 and S202 are only needed to be executed once, and when the bus taking payment is needed, the steps S203 to S208 are repeatedly executed.

Step S203: when the bus taking payment is required, the user terminal 20 determines the network status thereof, and if the network is connected, step S204 is executed, otherwise, step S205 is executed.

Step S204: the user terminal 20 sends a code sending request containing the user ID to the enterprise terminal 10, the enterprise terminal 10 judges whether the current staff meets the right of the riding rule, and if so, the riding code containing the enterprise ID is generated and fed back to the user terminal 20.

Specifically, the enterprise terminal 10 determines whether the received code sending request is from the employee of the company according to the user ID in the code sending request, if so, determines whether the employee satisfies the condition according to the riding rule rights configured in step S202, and if so, generates a riding code and feeds the riding code back to the user terminal 20, otherwise, refuses to generate the riding code. For example, if the upper limit of the monthly riding amount of a certain employee is 200 yuan, and the total riding amount of the employee counted by the enterprise terminal 10 in this month is 100 yuan, the employee is allowed to take a car at this time, and thus a riding code including the enterprise ID is generated and sent to the user terminal 20.

In step S204, the structure of the car code is not limited, and can be determined according to actual conditions, but must include the enterprise ID, and table 1 shows a partial structure content of the car code.

In the embodiment shown in table 1, different riding codes of the same employee generally have 2 fields different from each other: (1) the two-dimensional code generation time is used for filling the current time (the time for obtaining the mobile phone when the mobile phone is off line) into the field of the bus code during code generation to regenerate the code. (2) The private key signature of the payment account user, namely the private key signature of the user at the enterprise terminal 10, is a key for verifying whether the riding code is valid, and the field of each code is different.

TABLE 1

Step S205: a locally pre-stored ride code containing the business ID is used.

In order to prevent the user terminal 20 from being unable to pay when in the no-network state, some riding codes may be cached in advance, and when the user terminal 20 finds that the cached riding codes are used up or become invalid after the validity time of the two-dimensional codes in table 1 is exceeded, a code sending request is sent to the enterprise terminal 10 in the network state, and the riding codes fed back by the enterprise terminal 10 are received.

Step S206: the POS end tool 32 verifies the ride code shown by the user terminal 20.

The user terminal 20 presents the ride code, and the POS terminal 32 scans the code to parse the content of the ride code, generally requiring separation of the identity information and verification of the identity information, such as verification of the private key signature of the payment account user in table 1.

Step S207: after the verification is passed, the POS terminal 32 sends the verification information to the backend server 31 for a deduction operation.

Step S208: the background server 31 sends the deduction condition to the enterprise terminal 10.

After the verification is passed, the background server 31 calculates the amount of money to be paid to complete deduction, and sends the deduction amount condition, such as the user ID, the amount, the payment time, and even the number of vehicles, lines, and the like, to the enterprise terminal 10, and the enterprise terminal 10 makes a record of the employee travel condition in combination with the specific requirements of the riding rule and interest.

For step S204: the user terminal 20 sends a code sending request containing the user ID to the enterprise terminal 10, and the enterprise terminal 10 may also first determine whether the current balance of the enterprise account reaches a threshold value, and refuse to generate a riding code if the current balance of the enterprise account reaches the threshold value; (of course, the riding code may be generated and fed back to the user terminal 20, and then the enterprise account is reminded of recharging, and the deduction is performed after the recharging is successful.) if the value is not reached, it is determined whether the current employee meets the riding rule right, and if the value is met, the riding code including the enterprise ID is generated and fed back to the user terminal 20.

For the application, the verification of the riding code can be completed no matter whether the POS end machine 32 is networked or not, but only under the networking condition, the POS end machine 32 sends the verification condition information to the background server 31 for deduction operation. The system associates the user terminal 20 with the enterprise terminal 10, when payment is required, the enterprise terminal 10 sends a bus code to the user terminal 20, and the employee only needs to provide the bus code to the POS terminal device 31, and the background server 32 deducts money from the account of the enterprise terminal 10. When there is a reimbursement demand, the enterprise terminal 10 directly interfaces with the backend server 32. The whole travel payment and subsequent reimbursement are very convenient, the staff is not required to pay the bus fee, the invoice is not required to be asked every time, the riding record of the staff can be monitored, and the monitoring of the outwork condition of the whole staff is conveniently realized by the enterprise owner. The invention can completely replace manpower, and greatly improves the working efficiency.

EXAMPLE III

Based on the same inventive concept, an embodiment of the present invention further provides a bus taking payment method based on an enterprise account, and as shown in fig. 4, the bus taking payment method includes the following steps:

step S301: the enterprise terminal 10 receives a code transmission request from the user terminal 20.

Step S302: a ride code including the business ID is generated and fed back to the user terminal 20.

Wherein, the code sending request includes the user ID pre-assigned to the user by the enterprise terminal 10. In addition, before generating the riding code containing the enterprise ID, the method further comprises the following steps: and the enterprise terminal 10 verifies the legality of the user identity according to the user ID, and executes the step of generating the riding code after verifying that the user identity is legal.

Step S303: the enterprise terminal 10 receives the deduction condition returned by the background server 31 after deducting the verification condition information of the riding code based on the POS terminal.

Some initialization steps are required before step S301, and step S300 includes: the enterprise terminal 10 is connected with the background server 31 in advance to complete information registration and cost recharging, and receives the enterprise ID distributed by the background server 31. Step S300 is performed only once, and steps S301 to S303 are repeatedly performed when the vehicle payment is required.

As shown in fig. 5, step S301 further includes the following steps:

in step S301A, the enterprise terminal 10 receives the code sending request from the user terminal 20, determines whether the current user meets the preset ride rule right, and if yes, executes step S302. The riding rule rights and interests comprise riding times limit, riding time limit, riding amount limit and the like of the user.

Or, in S301B, the enterprise terminal 10 receives the code sending request from the user terminal 20, determines whether the current balance of the enterprise account reaches a preset threshold, and if not, determines whether the current user meets the preset ride rule right, and if so, executes step S302.

Correspondingly, an embodiment of the present invention further provides an enterprise terminal 10 for executing the riding payment method based on the enterprise account, as shown in fig. 6, where the enterprise terminal 10 includes: code sending module 12, expense management module 13, wherein:

a code sending module 12, configured to receive a code sending request from a user terminal 20; a ride code including the business ID is generated and fed back to the user terminal 20.

And the fee management module 13 is configured to receive a deduction condition returned by the background server 31 after deducting the check condition information of the riding code based on the POS terminal tool 32.

It is understood that the enterprise terminal 10 further includes a user center 11, and the user center 11 is configured to obtain an enterprise ID after registering with the background server 31, manage enterprise user information, assign a user ID to a user, and set a ride rule right. The fee management module 13 is further configured to charge the background server 31 in advance, and receive an account balance threshold set by the background server 31.

With regard to the enterprise terminal 10 in the above embodiment, the detailed operation thereof has been described in detail in the embodiment related to the method, and will not be explained in detail here.

Example four

Based on the same inventive concept, an embodiment of the present invention further provides a bus taking payment method based on an enterprise account, and as shown in fig. 7, the bus taking payment method includes the following steps:

step S401: the user terminal 20 determines the network status, and if the network is connected, executes step S402, otherwise, executes step S403.

Step S402: sending a code sending request to the enterprise terminal 10, and receiving a riding code containing the enterprise ID sent by the enterprise terminal 10.

The code sending request contains the user ID which is previously assigned to the user by the enterprise terminal 10. The riding code is generated after the enterprise terminal 10 verifies that the user identity is legal based on the user ID.

Step S403: and searching a locally pre-cached riding code containing the enterprise ID.

Step S404: the user terminal 20 requests verification of the car code from the POS end-piece 32.

For step S401, before the ue 20 determines its own network status, the method further includes: the user terminal 20 firstly judges whether the user terminal meets the right of the riding rule, and if so, judges the network condition of the user terminal; correspondingly, before the user terminal 20 determines the network status of itself, the method further includes a step of receiving the ride rule right preset and sent by the enterprise terminal 10.

For step S403, when searching for the locally pre-cached riding code including the enterprise ID, the user terminal 20 further needs to determine whether there is any pre-cached riding code or whether it is invalid, and if the pre-cached riding code is used up or invalid, it needs to send a code sending request to the enterprise terminal 10 in the networking state and receive the riding code fed back by the enterprise terminal 10.

Correspondingly, an embodiment of the present invention further provides a user terminal 20 for executing the riding payment method based on the enterprise account, as shown in fig. 8, where the user terminal 20 includes:

and the judging module 21 is used for judging the network condition of the user.

And the communication module 22 is used for sending a code sending request and receiving a riding code generated by the enterprise terminal 10 under the networking condition.

A code sending request generating module 23, configured to generate a code sending request, where the code sending request includes at least a user ID.

And the storage module 24 is used for storing the received riding codes. The storage module 24 is also used for receiving the user ID assigned by the enterprise terminal 10.

And the display module 25 is used for requesting the POS terminal tool 32 to verify the riding code.

In some embodiments, the riding code stored in the storage module 24 includes a riding code generated according to a code sending request sent when the payment request is received, and a pre-stored riding code, and when the determining module 21 determines that the user terminal 20 is not networked, the pre-stored riding code in the storage module 24 is called for scanning by the POS terminal 32.

With respect to the user terminal 20 in the above embodiment, the specific working manner thereof has been described in detail in the embodiment related to the method, and will not be elaborated herein.

It should be understood that the specific order or hierarchy of steps in the processes disclosed is an example of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged without departing from the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not intended to be limited to the specific order or hierarchy presented.

In the foregoing detailed description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the subject matter require more features than are expressly recited in each claim. Rather, as the following claims reflect, invention lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. Of course, the storage medium may also be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. Of course, the processor and the storage medium may reside as discrete components in a user terminal.

For a software implementation, the techniques described herein may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in memory units and executed by processors. The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the aforementioned embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations of various embodiments are possible. Accordingly, the embodiments described herein are intended to embrace all such alterations, modifications and variations that fall within the scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim. Furthermore, any use of the term "or" in the specification of the claims is intended to mean a "non-exclusive or".

Claims

1. A bus taking payment method based on an enterprise account is characterized by comprising the following steps:

the enterprise terminal receives a code sending request from the user terminal;

and the enterprise end receives a deduction condition returned by the background server after deducting the verification condition information of the riding code based on the POS end machine.

2. A vehicle taking payment method as in claim 1, wherein the code sending request comprises a user ID pre-assigned by the enterprise terminal to the user; correspondingly, before generating the riding code containing the enterprise ID, the method further includes:

and the enterprise terminal carries out validity verification on the user identity according to the user ID, and executes the step of generating the riding code after verifying that the user identity is legal.

3. A vehicle payment method as recited in claim 1, wherein the receiving of the code sending request from the user terminal by the enterprise terminal further comprises: and judging whether the current user meets the preset riding rule rights and interests, and if so, generating a riding code.

4. A vehicle payment method as recited in claim 1, wherein the receiving of the code sending request from the user terminal by the enterprise terminal further comprises: and judging whether the balance of the current enterprise account reaches a preset threshold value, if not, judging whether the current user meets the right of the riding rule, and if so, generating a riding code.

5. A ride payment method according to claim 3 or 4, wherein the ride rules interests comprise a ride number limit, a ride time limit, and a ride amount limit for the user.

6. A ride payment method according to claim 1, further comprising an initialization step comprising: the enterprise terminal is connected with the background server in advance to complete information registration and cost recharging and accept enterprise ID distributed by the background server.

7. A bus taking payment method based on an enterprise account is characterized by comprising the following steps:

8. A vehicle payment method according to claim 7, wherein the code sending request comprises a user ID pre-assigned by the enterprise terminal to the user, and the vehicle code is generated by the enterprise terminal after verifying that the user identity is legal based on the user ID.

9. A ride payment method according to claim 7, wherein the determining by the user terminal the own network condition further comprises: and when the vehicle is not networked, requesting the POS terminal device to verify the vehicle code which is cached locally and in advance and contains the enterprise ID.

10. A ride payment method according to claim 9, wherein requesting verification of a locally pre-cached ride code containing a business ID from the POS terminal further comprises: the user terminal judges whether a pre-cached riding code exists locally or whether the pre-cached riding code fails, and if the pre-cached riding code is used up or fails, the user terminal sends a code sending request to the enterprise terminal in a networking state and receives the riding code fed back by the enterprise terminal.

11. A ride payment method according to claim 8, wherein the step of the user terminal determining the network status further comprises: the user terminal judges whether the user terminal meets the right of the riding rule or not, and judges the network condition of the user terminal if the user terminal meets the right of the riding rule; correspondingly, the method also comprises the step of receiving the ride rule right preset and sent by the enterprise terminal before the user terminal judges the network state of the user terminal.

12. The bus taking payment system based on the enterprise account is characterized by comprising an enterprise terminal, a user terminal, a POS terminal machine and a background server, wherein:

13. A vehicle payment system according to claim 12, wherein the code sending request sent by the user terminal includes a user ID pre-assigned by the enterprise terminal to the user, and the vehicle code generated by the enterprise terminal is generated after the enterprise terminal verifies that the user identity is legal based on the user ID.

14. A vehicle taking payment system as claimed in claim 12, wherein the enterprise terminal is further configured to determine whether the current user satisfies a preset vehicle taking rule right after receiving a code sending request from the user terminal, and if so, generate a vehicle taking code.

15. A vehicle taking payment system as claimed in claim 12, wherein the enterprise terminal is further configured to determine whether the current balance of the enterprise account reaches a preset threshold value after receiving a code sending request from the user terminal, and if not, determine whether the current user meets the vehicle taking rule right, and if so, generate a vehicle taking code.

16. A ride payment system according to claim 14, wherein the ride rules equity pre-set at the enterprise site includes ride times, ride time, and ride amount limits for the user.

17. A vehicle payment system according to claim 12, wherein the enterprise terminal is further configured to connect with a backend server in advance, complete information registration and fee recharging, and accept an enterprise ID assigned by the backend server.

18. A ride payment system in accordance with claim 12, wherein the user terminal is further configured to request verification of a locally pre-cached ride code containing a business ID from the POS terminal device upon determining that the own network condition is not networked.

19. A vehicle payment system according to claim 18, wherein the user terminal is further configured to send a code sending request to the enterprise terminal in a networking state after discovering that the vehicle-taking code cached in advance locally runs out or is invalid, and receive the vehicle-taking code fed back by the enterprise terminal.

20. A ride payment system according to claim 12, wherein the user terminal determines whether the user terminal meets a ride rule interest, and if so, determines the network status of the user terminal, and the ride rule interest is preset by an enterprise terminal and sent to the user terminal.

21. An enterprise side, comprising: code sending module, expense management module, wherein:

22. The enterprise as claimed in claim 21, wherein the enterprise further comprises a user center, the user center is configured to obtain an enterprise ID after registering with the backend server, manage enterprise user information, and assign a user ID to the user, and the fee management module is further configured to pre-load the backend server with a value.

23. A user terminal, characterized in that the user terminal comprises:

the judging module is used for judging the network condition of the self-body;

a code sending request generating module for generating a code sending request;

the storage module is used for storing the received riding codes;

24. The user terminal of claim 23, wherein the storage module is configured to receive a user ID assigned by the enterprise terminal, and the code sending request generated by the code sending request generating module at least includes the user ID.