Travel fee generation method, terminal device and storage medium

Abstract

The invention relates to an itinerary fee generation method, terminal equipment and a storage medium, and the itinerary fee generation method comprises the steps: responding to a triggering instruction under the condition that the triggering instruction of a user for a payment entrance is received, and calling a payment application for payment, and the payment entrance is integrated on a user interface of a driver end application; payment information called back after payment succeeds is received, and the payment information comprises the payment amount; and backfilling the additional expense item of the current travel by using the payment amount, so that the total travel expense is generated according to the backfilled additional expense after the travel is finished, and a corresponding travel bill is generated. By implementing the travel cost generation method provided by the invention, the problems of time and labor waste, easiness in mistaken filling, high cost and the like in the prior art can be improved.

Description

Technical Field

[0001] This application relates to the technical field of operating vehicle trip cost generation, and in particular to a trip cost generation method, a terminal device, and a storage medium. Background Art

[0002] A third-party platform manages, schedules, and integrates resources for operating vehicles such as online car-hailing through a driver-side application. A driver can receive orders, navigate, and perform income statistics in real time on the driver-side application. After the trip ends, the driver-side application settles the trip cost based on basic fees, mileage fees, duration fees, etc.

[0003] However, in actual applications, the trip cost may also include other additional fees that need to be paid by passengers, such as road and bridge tolls, highway tolls, parking fees, etc. Whether other fees are generated depends on the actual situation. Therefore, this part of the fees is often not included in the trip cost, and this part of the fees needs to be advanced by the driver first.

[0004] The driver first opens the payment application to make a payment during the trip, and then confirms the fees with the passenger after the trip ends. However, it is very likely that due to differences in the understanding of the fee details or poor communication between the two parties, unnecessary misunderstandings and disputes will occur. After confirming that the fees are correct, the driver also needs to open the payment application again and manually fill in the advanced fees into the driver-side application. This process is not only time-consuming and laborious, but also extremely prone to situations such as incorrect filling, missing filling, or overfilling due to operation errors or unclear memory, resulting in contradictions between drivers and passengers, increasing the cost of customer complaints, and further increasing the complexity and cost of subsequent processing. Summary of the Invention

[0005] Based on this, this application provides a trip cost generation method, a terminal device, and a storage medium, which can improve some problems existing in the prior art, such as being time-consuming and laborious, prone to incorrect filling, and having a relatively high cost.

[0006] In a first aspect, this application provides a trip cost generation method, which includes: when receiving a trigger instruction from a user for a payment entry, in response to the trigger instruction, calling a payment application to make a payment, where the payment entry is integrated on the user interface of the driver-side application; receiving payment information called back after successful payment, where the payment information includes the payment amount; using the payment amount to fill in the additional fee items of the current trip, so that after the trip ends, the total trip cost is generated based on the filled-in additional fees, and a corresponding trip bill is generated.

[0007] In combination with the first aspect, in the first implementable manner of the first aspect, the foregoing steps of invoking a payment application for payment in response to a trigger instruction received from a user for a payment entry include: if the user is not authenticated or the authentication has expired, perform user authentication; after successful authentication, redirect to the corresponding mini-program of the driver application on the payment application to request the user to authorize the payment call function to the driver application, and perform payment after authorization.

[0008] In combination with the first aspect, in the second implementable manner of the first aspect, before backfilling the additional expense items of the current trip with the payment amount after receiving the payment information, the method further includes: determining the payment type according to the payment information, and comparing the payment type with a preset type, where the preset type includes at least one transportation expense such as road toll, highway toll, and parking fee; when the payment type belongs to the preset type, confirm that the payment type meets the backfilling condition, and backfill the additional expense items of the current trip with the payment amount.

[0009] In combination with the first aspect, in the third implementable manner of the first aspect, the foregoing payment information further includes merchant information. Before backfilling the additional expense items of the current trip with the payment amount, it further includes: obtaining the charging standard corresponding to the merchant information, and calculating the estimated amount according to the charging standard; comparing the estimated amount with the payment amount in the payment information, and when the comparison result is consistent, backfill the additional expense items of the current trip with the payment amount.

[0010] In combination with the second or third implementable manner of the first aspect, in the fourth implementable manner of the first aspect, when the payment type does not belong to the preset type, the charging standard is not obtained, or the comparison result is inconsistent, the method further includes: generating confirmation information including the payment type and / or the payment amount according to the payment information; pushing the confirmation information to the passenger's terminal device, and receiving and reading the feedback information; when the read feedback information indicates that the passenger has confirmed, backfill the additional expense items of the current trip with the payment amount.

[0011] In combination with the first aspect, in the fifth implementable manner of the first aspect, the payment information further includes merchant information. Before backfilling the additional expense items of the trip with the payment amount, it further includes: determining the vehicle position of the car at the time of payment according to the trip information of the vehicle; comparing the merchant address associated with the merchant information with the vehicle position; when they are consistent, backfill the additional expense items of the trip with the payment amount; when they are inconsistent, do not perform the step of backfilling the additional expense items of the trip.

[0012] In combination with the first aspect, in the sixth implementable manner of the first aspect, the foregoing payment information includes time information. Before backfilling the additional expense items of the trip according to the payment amount, it further includes: comparing the start time of the current trip with the time information in the payment information, where the time information in the payment information is used to indicate the generation time when the payment application generates a payment order; if the start time of the current trip is earlier than the generation time indicated by the time information, then backfill the additional expense items of the trip with the payment amount, otherwise, do not perform the backfilling step.

[0013] In a second aspect, the present application further provides a terminal device, which includes: a calling unit, configured to, when receiving a trigger instruction from a user for a payment entry, in response to the trigger instruction, call a payment application for payment, where the payment entry is integrated on the user interface of the driver-side application; a callback unit, configured to receive the payment information called back after payment success, where the payment information includes the payment amount; a generating unit, configured to backfill the additional expense items of the current trip with the payment amount, so that after the trip ends, the total trip expense is generated according to the backfilled additional expenses, and a corresponding trip bill is generated.

[0014] In an implementable manner, the calling unit is specifically configured to: if the user is not authenticated or the authentication has expired, authenticate the user; after successful authentication, redirect to the corresponding applet of the driver-side application on the payment application to request the user to agree to authorize the payment call function to the driver-side application, and make a payment after authorization.

[0015] In an implementable manner, the generating unit is further configured to: determine the payment type according to the payment information, and compare the payment type with a preset type, where the preset type includes at least one traffic expense such as road and bridge tolls, highway tolls, and parking fees; when the payment type belongs to the preset type, confirm that the payment type meets the backfilling condition, and backfill the additional expense items of the current trip with the payment amount.

[0016] In an implementable manner, the generating unit is further configured to: obtain the charging standard corresponding to the merchant information, and calculate the estimated amount according to the charging standard; compare the estimated amount with the payment amount in the payment information, and when the comparison result is consistent, backfill the additional expense items of the current trip with the payment amount.

[0017] In an implementable manner, the terminal device further includes a confirmation unit, and the confirmation unit is configured to: generate confirmation information including the payment type and / or the payment amount according to the payment information when the payment type does not belong to a preset type, the charging standard is not obtained, or the comparison result is consistent; push the confirmation information to the passenger's terminal device, and receive and read the feedback information; and backfill the additional charge items of the current trip with the payment amount when the read feedback information indicates that the passenger has confirmed.

[0018] In an implementable manner, the payment information further includes merchant information, and the generation unit is further configured to: determine the vehicle position of the vehicle at the time of payment according to the trip information of the vehicle; compare the merchant address associated with the merchant information with the vehicle position; backfill the additional charge items of the trip with the payment amount when they are consistent; and do not perform the step of backfilling the additional charge items of the trip when they are inconsistent.

[0019] In an implementable manner, the payment information includes time information, and the generation unit is further configured to: compare the start time of the current trip with the time information in the payment information, where the time information in the payment information is used to indicate the generation time when the payment application generates a payment order; backfill the additional charge items of the trip with the payment amount if the start time of the current trip is earlier than the generation time indicated by the time information, and conversely, do not perform the backfilling step.

[0020] In a third aspect, the present application further provides a terminal device, which includes a processor and a memory, and the processor and the memory are connected through a bus; the processor is configured to execute multiple instructions; the memory is configured to store multiple instructions, and the instructions are suitable for being loaded and executed by the processor to perform the trip cost generation method according to the first aspect or any implementation manner of the first aspect.

[0021] In a fourth aspect, the present application further provides a computer-readable storage medium, in which multiple instructions are stored, and the instructions are suitable for being loaded and executed by the processor to perform the trip cost generation method according to the first aspect or any implementation manner of the first aspect.

[0022] In summary, the present application provides a trip cost generation method, a terminal device, and a storage medium. Among them, the present application integrates a payment entry on the user interface of the driver-side application, enabling the driver to quickly obtain additional charges and generate trip costs and trip bills through the link of triggering the payment entry, calling the payment application to complete the payment, and backfilling the additional charges, greatly improving the generation efficiency of trip costs. There is no need for the driver to repeatedly switch applications and fill in manually. The user can also confirm the expense details through the trip bill, eliminating unnecessary misunderstandings and disputes between the driver and the passenger. Therefore, it greatly improves some problems existing in the prior art, such as time-consuming, easy to fill in incorrectly, and high cost. Brief Description of the Drawings

[0023] Figure 1 It is a schematic flowchart of a travel expense generation method in an embodiment of the present application;

[0024] Figure 2 It is a schematic block diagram of a terminal device in an embodiment of the present application;

[0025] Figure 3 It is a structural block diagram of a terminal device in an embodiment of the present application. Detailed Description of the Embodiment

[0026] In order to make the purpose, technical solution and advantages of the present application clearer, the present application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0027] Currently, when the driver-side application manually fills in additional expenses, there are still some problems such as time-consuming, laborious, easy to misfill, and high cost. In view of this, the present application integrates a payment entry on the user interface of the driver-side application, allows the driver to directly enter the payment application through the payment entry of the driver-side application for payment, and obtains payment information including additional expenses through a callback after successful payment, so that the driver-side application can quickly obtain the payment information, and automatically settle the travel expenses and generate a travel bill according to the payment information after the trip ends, without the driver repeatedly switching applications and manually filling in. The user can also confirm the expense details through this travel bill, eliminating unnecessary misunderstandings and disputes between the driver and the passenger, thus greatly improving some problems existing in the prior art such as time-consuming, laborious, easy to misfill, and high cost.

[0028] It should be noted that, in order to improve the foregoing problems, the present application creatively integrates a payment entry on the user interface of the driver-side application, and automatically obtains additional expenses and settles travel expenses through the payment information callback by the payment entry. Usually, the driver-side application does not have a payment function and will not be bound to the payment application, because the driver-side application has no payment need, and there are also considerations of security and laws and regulations. The specific reasons are as follows:

[0029] As a service provider, the third-party platform is responsible for recruiting, training, and managing drivers, and at the same time provides services such as car-hailing, payment, and complaint for passengers. When using the service, passengers actually establish a service contract relationship with the third-party platform, rather than directly with the driver. Therefore, passengers and drivers do not conduct direct contracting or money transactions. Instead, contracting and money transactions are carried out through the third-party platform. After the trip ends, the passenger pays the third-party platform. The third-party platform will not transfer the money to the driver immediately. Instead, it will count the income amount in the form of virtual numbers on the driver side. However, this amount cannot be directly used for operations such as payment or transfer. Only after the driver performs operations such as cash withdrawal on the driver-side application, will the third-party platform directly remit the money to the driver's bank account for auditing and tax processing. Therefore, the driver-side application has no payment requirements and does not need to be bound to a payment application.

[0030] In fact, the payment entry integrated on the user interface of the driver-side application in this application is used to call the payment application to conduct offline face-to-face transactions with merchants by displaying a payment code or opening a scanning code function, etc. However, the driver-side application itself still does not have the payment function because the driver-side application does not generate payment orders and does not use the income amount of the driver-side application for payment. Therefore, this application can improve some problems existing in the prior art, such as time-consuming, laborious, easy to fill in wrongly, and high cost, while ensuring the security of the driver-side application and meeting the requirements of laws and regulations.

[0031] The trip cost generation method provided by this application can be applied to the driver-side application of a terminal device. The terminal device can be a user terminal, a vehicle (or in-vehicle terminal). The user terminal can include a mobile phone, a tablet computer, a smart watch, etc. In addition, the terminal device can interact with other servers, terminal devices, controllers, processors, ECUs, etc. and execute the method proposed by this application.

[0032] For a better understanding of the trip cost generation method proposed by this application, this application also provides an embodiment of the trip cost generation method, as Figure 1 shown. Next, taking the driver-side application of the terminal device as the execution subject, this method will be described in detail:

[0033] 100: In the case of receiving a trigger instruction from the user for the payment entry, in response to the trigger instruction, call the payment application for payment;

[0034] 200: Receive the payment information called back after the payment is successful;

[0035] 300: Use the payment amount to backfill the additional cost items of the current trip, so that the total trip cost is generated based on the backfilled additional costs after the trip ends, and a corresponding trip bill is generated.

[0036] Among them, the payment entry is integrated into the user interface of the driver-side application. For example, the user interface can be the current trip interface, which includes a navigation route and an icon for confirming arrival at the destination. This application integrates an obvious payment entry on the current trip interface. That is to say, when the user enters the current trip interface, they can trigger the payment entry to call the payment application for payment. This is not only more convenient for the user to operate without having to exit the current trip interface but also ensures that the user can only use this function during the trip, reducing security risks as well as the financial security and rights of passengers. Therefore, while ensuring the security of the driver-side application and meeting the requirements of laws and regulations, it further improves some problems existing in the prior art, such as being time-consuming and laborious, prone to incorrect filling, and having a relatively high cost.

[0037] The user selects the payment entry through any one or more operations such as clicking, swiping, or long-pressing, causing the driver-side application to receive a trigger instruction from the user for the payment entry. In response to this trigger instruction, the driver-side application calls Alipay through an Application Programming Interface (API), Software Development Kit (SDK), payment gateway, etc., to conduct an in-person transaction with the merchant offline by showing a payment code, opening a scanning function, etc. For example, the transaction process includes the merchant scanning the collection code of the user's payment application for identity verification. After the identity verification is passed, an order is generated, and the user confirms the payment of the order on the payment application. After the payment is successful, the payment application generates payment information, which, in addition to the payment amount, may also include one or more information such as time information, merchant identification, etc.

[0038] After the payment application completes the payment, it notifies the application of the payment result through a callback function or callback URL provided by the driver-side application. After receiving the payment information, the driver-side application will call the callback function to process this payment information. For example, it backfills the additional fee item of the current trip according to the payment amount. For example, it obtains the payment amount in the payment information and backfills it into the attachment amount input box of the driver-side application to automatically use the payment amount input as the additional amount, so that the total trip cost is generated based on the backfilled additional fee after the trip ends, and a corresponding trip bill is generated. The trip bill can record the cost details of the trip. In addition, the payment information may also include, among other things, in addition to the payment amount, time information, payment type, payment result, merchant information, order number, and / or payment voucher, etc. The trip cost and trip bill will be pushed to the passenger's terminal device after the trip ends, that is, after arriving at the destination. After the passenger confirms that the trip cost and trip bill are correct, they make the payment, eliminating unnecessary misunderstandings and disputes between the driver and the passenger and improving some problems existing in the prior art, such as being time-consuming and laborious, prone to incorrect filling, and having a relatively high cost.

[0039] Regarding step 100, when the driver-side application receives a trigger instruction from the user for the payment entry, in response to the trigger instruction, calling the payment application for payment includes: if the user is not authenticated or the authentication has expired, authenticating the user's identity; after successful authentication, redirecting to the corresponding mini-program of the driver-side application on the payment application to request the user to consent to authorize the payment call function to the driver-side application, and making a payment after authorization. If the user is already authenticated and the authentication has not expired, directly calling the payment application for payment.

[0040] Among them, in this application, a mini-program is created in the payment application to undertake scenarios such as authorization binding, payment redirection, and payment failure. Before responding to the user's trigger instruction, if the user has not yet undergone identity authentication or the identity authentication has expired, first perform identity authentication and request the user's authorization, and then make a payment after successful identity authentication and authorization. For example, authentication includes guiding the user to verify their identity through methods such as mobile phone number and payment application account to ensure the security of operations. Authorization can include guiding the user to bind the payment code of the payment application to the driver-side application, and can also include authorizing the scanning function to the driver-side application, and can also include obtaining permissions such as payment permissions, account information access permissions, and transaction information query permissions, so as to ensure that the user can call the payment function of the payment application through the driver-side application and allow the payment information to be called back to the driver-side application after successful payment.

[0041] It should be noted that through the trip cost generation method of this application, the callback payment information can be summarized, so that the driver-side application can statistically analyze the payment information, manage and optimize the service, build a better market, and moreover, by developing a small software on the payment application, the payment information and more other information can be synchronized to the user's cloud account, enabling the cloud or the driver-side application to obtain the information for statistical analysis.

[0042] Regarding step 300, on the user interface of the driver-side application, for example, a delete icon is also integrated on the interface for calculating the total trip cost, allowing the user to manually delete the additional amount by selecting the delete icon. In response to the user's deletion operation on the backfilled attachment cost, the driver-side application deletes the erroneously backfilled additional cost to improve the accuracy of the additional cost. However, the additional amount cannot be manually modified to avoid human error modification.

[0043] Before performing step 300, the driver-side application can also identify the payment type. When it is identified that the payment type is a preset type such as transportation expenses, the payment amount can be directly filled back. Because for the driver-side application, transportation expenses are the most important and common additional expenses, such as road and bridge tolls, highway tolls, and parking fees, etc. Other expenses such as accommodation and food expenses are rare and usually occur in intercity transportation. If filling back is required, further verification is needed to ensure the accuracy and security of the filling back. Therefore, in this application, when it is identified that the payment type is a preset type, direct filling back is allowed to improve the filling back efficiency, quickly generate trip expenses and trip bills, save computing resources, and enhance the user experience. Specifically, after the driver-side application receives the payment information, before using the payment amount to fill back the additional expense items of the current trip, the driver-side application determines the payment type according to the payment information and compares the payment type with the preset type. Among them, the preset type includes at least one transportation expense such as road and bridge tolls, highway tolls, and parking fees; when the payment type belongs to the preset type, it is confirmed that the payment type meets the filling back condition, and the payment amount is used to fill back the additional expense items of the current trip.

[0044] Among them, the foregoing determination of the payment type according to the payment information includes obtaining the payment type in the payment information. The obtained payment information includes merchant information, or identifying the payment type according to the merchant information in the payment type, including determining the approximate payment type based on the business scope associated with the merchant information. Further, the time information in the payment information can be used to verify the payment type. If the payment occurs in the time period where the payment type usually is, the verification passes; otherwise, it fails. The obtained payment information includes time information, and this time information can indicate the generation time of the payment order generated by the payment application, rather than the payment time of the order, because the user may delay confirming the payment to further improve the accuracy of the verification process.

[0045] Before performing step 300, the driver-side application can also verify the payment amount in the payment information according to the merchant information in the payment information. If the verification fails, further confirmation is required before callback. If the verification passes, the payment amount is filled back without further confirmation to ensure the accuracy and authenticity of the callback and improve the callback efficiency. Specifically, the payment information also includes merchant information. Before the driver-side application uses the payment amount to fill back the additional expense items of the current trip, the driver-side application obtains the charging standard corresponding to the merchant information and calculates the estimated amount according to the charging standard; compares the estimated amount with the payment amount in the payment information, and when the comparison result is consistent, uses the payment amount to fill back the additional expense items of the current trip.

[0046] Among them, the charging standards corresponding to different merchants are different. Especially for transportation fees, the charging standards are very transparent and standardized. For example, merchants who charge road and bridge tolls or highway tolls usually charge according to mileage, number of passes, vehicle type, and / or vehicle weight, etc. The driver-side application can obtain the charging standards corresponding to the merchant through the wireless network in the cloud, and obtain vehicle information and trip information locally or in the cloud. Calculate the estimated amount based on the charging standard, vehicle information, and trip information, and then compare the payment amount in the payment information with the estimated amount to check the payment amount. When the payment amount is consistent with the estimated amount, it is determined that the check passes. In the case where the check passes, use the payment amount to fill in the additional expense items for the current trip.

[0047] In the above steps, if the payment type is not a preset type, or the payment amount cannot be checked because the charging standard is not obtained, or the payment amount check fails, then let the passenger assist in confirmation. Specifically, when the payment type of the driver-side application does not belong to the preset type, the charging standard is not obtained, or the comparison result is inconsistent, the method further includes: generating confirmation information including the payment type and / or payment amount according to the payment information; pushing the confirmation information to the passenger's terminal device, and receiving and reading the feedback information; when the read feedback information is that the passenger has confirmed, use the payment amount to fill in the additional expense items for the current trip.

[0048] Before executing step 300, the driver-side application can also identify false off-site payment behavior by comparing the merchant address with the vehicle location at the time of payment. In the case where no false off-site payment behavior is detected, use the payment amount to fill in the additional expense items for the trip. Specifically, the payment information also includes merchant information. Before the driver-side application fills in the additional expense items for the trip according to the payment amount, the driver-side application determines the vehicle location at the time of payment based on the trip information of the vehicle; compares the merchant address associated with the merchant information with the vehicle location; when they are consistent, use the payment amount to fill in the additional expense items for the trip; when they are inconsistent, do not execute the step of filling in the additional expense items for the trip.

[0049] Among them, in the case where the payment information does not include time information, the driver-side application records the triggering time when the user triggers the payment entry, and determines the vehicle location based on the triggering time and the trip information, that is, determines the location where the vehicle is at the triggering time; in the case where the payment information includes time information, determines the vehicle location based on the time information of the payment information and the trip information, that is, determines the location where the vehicle is at the time point indicated by the time information.

[0050] In addition, to prevent false payments in different locations, the driving speed of the vehicle at the time of payment can also be checked. The driving speed of the vehicle at the time of payment can be determined based on the vehicle's travel information, for example, the driving speed of the vehicle at the time of payment can be determined based on the aforementioned trigger time and travel information, or the driving speed of the vehicle at the time of payment can be determined based on the time information and travel information in the payment information. If the driving speed is less than the preset speed, the additional fee item for the trip is backfilled with the payment amount.

[0051] Before performing step 300, the driver-side application can also check whether the callback payment information belongs to the current trip according to the time information of the payment information or the aforementioned trigger time. Among them, the time information in the payment information is used to indicate the generation time when the payment application generates a payment order, and the trigger time is used to represent the time point when the payment entry is triggered. Specifically:

[0052] In some implementable ways, the payment information includes time information. Before backfilling the additional fee item for the trip with the payment amount, the driver-side application compares the start time of the current trip with the time information in the payment information. Among them, the time information in the payment information is used to indicate the generation time when the payment application generates a payment order; if the start time of the current trip is earlier than the generation time indicated by the time information, the additional fee item for the trip is backfilled with the payment amount, otherwise, the backfilling step is not executed.

[0053] In some other implementable ways, before backfilling the additional fee item for the trip with the payment amount, it also includes: comparing the start time of the current trip with the trigger time. If the start time of the current trip is earlier than the trigger time, the additional fee item for the trip is backfilled with the payment amount, otherwise, the backfilling step is not executed.

[0054] It should be noted that any combination can be made in combination with the embodiments, and this combination method should also be within the protection scope of this application. That is, the driver-side application can execute the aforementioned step of backfilling the additional fee item for the current trip with the payment amount when one or more of the payment type belongs to the preset type, the estimated amount is the same as the payment amount in the payment information, the read feedback information is that the passenger has confirmed, the merchant address associated with the merchant information is consistent with the vehicle location, and the start time of the current trip is earlier than the generation time indicated by the time information, so as to further improve some problems existing in the prior art such as time-consuming, easy to misfill, and high cost.

[0055] The present application also provides a terminal device. In the embodiments of the present application, the device can be divided into functional modules according to the above method examples. For example, each functional module can be corresponding to each function, or two or more functions can be integrated into one module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the embodiments of the present application is illustrative, only a logical function division, and there can be other division methods in actual implementation. Specifically, the terminal device includes: a calling unit 210, configured to, when receiving a trigger instruction of a user for a payment entry, in response to the trigger instruction, call a payment application to make a payment, where the payment entry is integrated on the user interface of the driver-side application; a callback unit 220, configured to receive the payment information called back after the payment is successful, where the payment information includes the payment amount; a generating unit 230, configured to backfill the additional expense items of the current trip with the payment amount, so that the total trip expense is generated according to the backfilled additional expenses after the trip ends, and a corresponding trip bill is generated.

[0056] In an implementable manner, the calling unit 210 is specifically configured to: if the user is not authenticated or the authentication has expired, authenticate the user; after the authentication is passed, redirect to the mini-program corresponding to the driver-side application on the payment application, to request the user to agree to authorize the payment call function to the driver-side application, and make a payment after the authorization.

[0057] In an implementable manner, the generating unit 230 is further configured to: determine the payment type according to the payment information, and compare the payment type with a preset type, where the preset type includes at least one traffic expense such as road and bridge tolls, highway tolls, and parking fees; in the case that the payment type belongs to the preset type, confirm that the payment type meets the backfill condition, and backfill the additional expense items of the current trip with the payment amount.

[0058] In an implementable manner, the generating unit 230 is further configured to: obtain the charging standard corresponding to the merchant information, and calculate the estimated amount according to the charging standard; compare the estimated amount with the payment amount in the payment information, and in the case that the comparison result is consistent, backfill the additional expense items of the current trip with the payment amount.

[0059] In an implementable manner, the terminal device further includes a confirmation unit 240, and the confirmation unit 240 is configured to: in the case that the payment type does not belong to the preset type, the charging standard is not obtained, or the comparison result is consistent, generate confirmation information including the payment type and / or the payment amount according to the payment information; push the confirmation information to the passenger's terminal device, and receive and read the feedback information; in the case that the read feedback information is that the passenger has confirmed, backfill the additional expense items of the current trip with the payment amount.

[0060] In an implementable manner, the payment information further includes merchant information, and the generating unit 230 is further configured to: determine the vehicle position of the vehicle at the time of payment according to the travel information of the vehicle; compare the merchant address associated with the merchant information with the vehicle position; in the case of consistency, backfill the additional charge items of the trip with the payment amount; in the case of inconsistency, do not perform the step of backfilling the additional charge items of the trip.

[0061] In an implementable manner, the payment information includes time information, and the generating unit 230 is further configured to: compare the start time of the current trip with the time information in the payment information, where the time information in the payment information is used to indicate the generation time when the payment application generates a payment order; if the start time of the current trip is earlier than the generation time indicated by the time information, backfill the additional charge items of the trip with the payment amount, otherwise, do not perform the backfilling step.

[0062] The present application also provides a terminal device, which may include: a processor 310 and a memory 320. The above-mentioned processor 310 and memory 320 are connected through a bus 330. The processor 310 is used to execute multiple instructions; the memory is used to store multiple instructions, and the instructions are adapted to be loaded and executed by the processor to perform the trip cost generation method as described in the above embodiments. Among them, the processor may be an Electronic Control Unit (ECU), a central processing unit (CPU), a general-purpose processor, a coprocessor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The processor may also be a combination for implementing computing functions, such as a combination including one or more microprocessors, a combination of 5SP and a microprocessor, and so on. In this embodiment, the processor may adopt a single-chip microcomputer, and various control functions can be realized by programming the single-chip microcomputer. The processor has the advantages of powerful computing ability and fast processing speed. Specifically, the processor 310 is used to execute the function of the calling unit 210, and is used to call the payment application for payment in response to a trigger instruction received from the user for the payment entry, where the payment entry is integrated on the user interface of the driver-side application; the processor 310 is also used to execute the function of the callback unit 220, and is used to receive the payment information called back after the payment is successful, where the payment information includes the payment amount; the processor 310 is also used to execute the function of the generating unit 230, and is used to backfill the additional cost items of the current trip with the payment amount, so that the total trip cost is generated according to the backfilled additional cost after the trip ends, and a corresponding trip bill is generated.

[0063] In an implementable manner, the processor 310 is specifically used to: if the user is not authenticated or the authentication has expired, authenticate the user's identity; after the authentication is passed, redirect to the corresponding applet of the driver-side application on the payment application to request the user to agree to authorize the payment call function to the driver-side application, and make a payment after the authorization.

[0064] In one implementable manner, the processor 310 is further configured to: determine the payment type according to the payment information, and compare the payment type with a preset type, where the preset type includes at least one traffic fee such as road and bridge toll, highway toll, and parking fee; in the case that the payment type belongs to the preset type, confirm that the payment type meets the backfill condition, and backfill the additional fee item of the current trip with the payment amount.

[0065] In one implementable manner, the processor 310 is further configured to: obtain the charging standard corresponding to the merchant information, and calculate the estimated amount according to the charging standard; compare the estimated amount with the payment amount in the payment information, and in the case that the comparison result is consistent, backfill the additional fee item of the current trip with the payment amount.

[0066] In one implementable manner, the processor 310 is further configured to execute the function of the confirmation unit 240, and is configured to: in the case that the payment type does not belong to the preset type, the charging standard is not obtained, or the comparison result is consistent, generate confirmation information including the payment type and / or the payment amount according to the payment information; push the confirmation information to the passenger's terminal device, and receive and read the feedback information; in the case that the read feedback information is that the passenger has confirmed, backfill the additional fee item of the current trip with the payment amount.

[0067] In one implementable manner, the payment information further includes merchant information, and the processor 310 is further configured to: determine the vehicle position of the vehicle at the time of payment according to the trip information of the vehicle; compare the merchant address associated with the merchant information with the vehicle position; in the case of consistency, backfill the additional fee item of the trip with the payment amount; in the case of inconsistency, do not perform the step of backfilling the additional fee item of the trip.

[0068] In one implementable manner, the payment information includes time information, and the processor 310 is further configured to: compare the start time of the current trip with the time information in the payment information, where the time information in the payment information is used to indicate the generation time of the payment order generated by the payment application; if the start time of the current trip is earlier than the generation time indicated by the time information, backfill the additional fee item of the trip with the payment amount, otherwise, do not perform the backfill step.

[0069] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0070] The above embodiments only represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A method for generating travel costs, applied to a driver-side application, characterized in that: include: Upon receiving a trigger instruction from a user for a payment portal, in response to the trigger instruction, calling a payment application to make payment, wherein the payment portal is integrated on a user interface of the driver-side application; Receive payment information returned after successful payment, wherein the payment information includes the payment amount; The payment amount is used to backfill the additional fee items of the current trip, so that after the trip is completed, the total trip fee is generated based on the backfilled additional fees, and a corresponding trip bill is generated.

2. The method according to claim 1, characterized in that In the case of receiving a trigger instruction from a user for a payment portal, in response to the trigger instruction, calling a payment application to make payment includes: If the user is not authenticated or the authentication period has expired, the user will be authenticated; After authentication, the user is redirected to the corresponding mini-program of the driver-side application on the payment application to request the user to agree to authorize the payment call function to the driver-side application and make payment after authorization.

3. The method according to claim 1, characterized in that After receiving the payment information, before backfilling the additional fee items of the current trip with the payment amount, the method further includes: Determine a payment type according to the payment information, and compare the payment type with a preset type, wherein the preset type includes at least one transportation fee of road and bridge fees, highway fees, and parking fees; In the case that the payment type belongs to the preset type, it is confirmed that the payment type meets the backfill condition, and the additional fee item of the current trip is backfilled using the payment amount.

4. The method according to claim 1, characterized in that: The payment information also includes merchant information, and before backfilling the additional fee items of the current trip with the payment amount, it also includes: Obtaining the charging standard corresponding to the merchant information, and calculating the estimated amount according to the charging standard; The estimated amount is compared with the payment amount in the payment information, and if the comparison result is consistent, the payment amount is used to backfill the additional fee item of the current trip.

5. The method according to claim 3 or 4, characterized in that: When the payment type does not belong to the preset type, the charging standard is not obtained, or the comparison result is consistent, the method further includes: generating confirmation information including payment type and / or payment amount according to the payment information; Pushing the confirmation information to the passenger's terminal device, and receiving and reading the feedback information; When the feedback information is read as confirmation by the passenger, the additional fee item of the current trip is backfilled with the payment amount.

6. The method according to claim 1, characterized in that The payment information also includes merchant information, and before backfilling the additional fee items of the trip according to the payment amount, it also includes: Determining the vehicle location of the vehicle when payment occurs based on the vehicle's travel information; comparing a business address associated with the business information with the vehicle location; In the case of consistency, the additional fee item of the trip is backfilled with the payment amount; In the event of inconsistency, the step of backfilling the additional fee items of the itinerary is not performed.

7. The method according to claim 1, characterized in that The payment information includes time information, and before backfilling the additional fee items of the trip according to the payment amount, also includes: Comparing the start time of the current trip with the time information in the payment information, wherein the time information in the payment information is used to indicate the generation time of the payment order generated by the payment application; If the start time of the current trip is earlier than the generation time indicated by the time information, the additional fee item of the trip is backfilled using the payment amount; otherwise, the backfilling step is not performed.

8. A terminal device, characterized in that: The terminal device is installed with a driver-side application and a payment application, wherein the driver-side application includes: A calling unit, configured to, upon receiving a trigger instruction from a user for a payment entry, call a payment application to make payment in response to the trigger instruction, wherein the payment entry is integrated on a user interface of the driver-side application; A callback unit, used to receive payment information called back after successful payment, wherein the payment information includes the payment amount; The generating unit is used to backfill the additional fee items of the current trip with the payment amount, so that after the trip is completed, the total trip fee is generated according to the backfilled additional fees, and a corresponding trip bill is generated.

9. A terminal device, characterized in that: The terminal device includes a processor and a memory, wherein the memory stores a program or an instruction, and when the program or the instruction is executed by the processor, the method according to any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes the program or the instructions, and when the program or the instructions are executed on a device, the device is caused to perform the method according to any one of claims 1 to 7.

Images