A method, system and electronic device for ride fare deduction based on an account mode
By adopting an account-based fare deduction method, the system determines whether a user account has the right to ride and deducts the fare after the ride. This solves the problem that the traditional railway fare deduction method cannot adapt to the needs of public transportation operations, and enables users to switch to a fare deduction mode without being aware of it, thus improving the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA ACADEMY OF RAILWAY SCI CORP LTD
- Filing Date
- 2026-01-15
- Publication Date
- 2026-05-29
AI Technical Summary
The traditional railway fare payment model of "buy a ticket first, then ride" cannot flexibly adapt to the needs of passengers in intercity and urban rail transit systems operating like public transport, especially those who want convenient commuting and hope to "ride first, pay later" like taking a bus.
The system adopts an account-based fare deduction method, which identifies the user account through the travel voucher information, checks whether there is a valid ticket purchase record in the account, and if there is no record, determines whether the account has travel privileges, allows the user to travel, and deducts the fare after the travel is completed. It supports both prepaid and credit payment modes.
It enables unified management of pre-purchase and post-payment scenarios, simplifies the user's travel process, improves the flexibility of the fare deduction model, meets the needs of different travel scenarios, and enhances the user experience.
Smart Images
Figure CN122114911A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of railway transportation, and more specifically, to a method, system, and electronic device for deducting fares based on an account model. Background Technology
[0002] The traditional railway fare payment model is a "buy ticket first, then board" model, meaning passengers must select their train and complete payment in advance, and the system will generate a ticket voucher before they can enter the station and board the train. This model is suitable for seated travel and long-distance transportation.
[0003] However, with the increasing development of railway transportation networks and the diversification of operating models, especially the development of intercity and suburban railways towards public transport-like operations, the "buy now, ride later" fare collection model, which relies on ticket purchase, cannot flexibly adapt to passengers' needs for different travel scenarios. For example, for convenient commuting scenarios on intercity and suburban railways, passengers hope to be able to simply swipe their cards when entering and exiting the station, just like taking a bus—that is, a "ride now, pay later" model.
[0004] Therefore, improving the flexibility of fare payment models and enhancing user experience are technical problems that need to be solved by those skilled in the art. Summary of the Invention
[0005] To address one or more deficiencies in the existing technology, the present invention provides a method, system, and electronic device for fare deduction based on an account model.
[0006] A method for deducting fares based on an account model includes: The corresponding user account is determined based on the input travel voucher information; Check if there is a valid ticket purchase record in the user account; If not, determine whether the user account has ride privileges; If the user account has ride privileges, the user is allowed to ride, and the ride fare is deducted from the user account after the ride.
[0007] Optionally, determining whether the user account has ride-hailing privileges includes: Determine whether the user's account balance is greater than a first preset value; If so, then the user account is confirmed to have ride privileges; If not, determine whether the credit limit of the user account is greater than the second preset value; If the credit limit of the user account is greater than the second preset value, then the user account is determined to have ride privileges. If the credit limit of the user account is less than or equal to the second preset value, then it is determined that the user account does not have the right to ride.
[0008] Optionally, the method further includes: When it is determined that the user account does not have boarding privileges, the ticket gate is closed and a prompt message is displayed.
[0009] Optionally, deducting the fare from the user's account after the ride includes: Based on the entry and exit information corresponding to the travel voucher information, the travel information of the user account is generated; Calculate the travel fare based on the travel information; The fare will be deducted based on the user account type by selecting the corresponding deduction method.
[0010] Optionally, the step of selecting the corresponding deduction method based on the user account type to deduct the fare includes: Determine the type of the user account; If the user account is a registered account, then determine whether the account balance of the registered account is greater than or equal to the fare; If so, the fare will be deducted from the account balance of the registered account; If not, the fare will be deducted based on the payment channel linked to the registered account; If the user account is a temporary account, the fare will be deducted based on the payment channel linked to the temporary account; If the user account is a group account, the fare will be deducted based on the payment channel linked to the group account.
[0011] Optionally, the method further includes: A registered account is generated based on the input registration information; the registration information includes user identity information, ride voucher binding information, and payment channel binding information.
[0012] Optionally, the method further includes: A bill is generated based on all the aforementioned fare deductions.
[0013] A ride-hailing fare deduction system based on an account model includes: The determination module is used to determine the corresponding user account based on the input travel voucher information; The detection module is used to detect whether there is a valid ticket purchase record in the user account; The judgment module is used to determine whether the user account has travel privileges if there is no valid ticket purchase record in the user account. The deduction module is used to allow users to ride the bus if their accounts have ride privileges, and to deduct the fare from the user accounts after the ride.
[0014] An electronic device, comprising: A processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the account-based fare deduction method as described in any of the preceding embodiments.
[0015] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the account-based fare deduction method as described in any of the preceding claims.
[0016] The method for deducting fares based on an account model provided in this invention determines the corresponding user account based on the input travel voucher information; checks whether there is a valid ticket purchase record in the user account; if not, it determines whether the user account has travel authorization; if the user account has travel authorization, it allows the user to travel and deducts the fare from the user account after the trip. This invention, by determining whether the user account has a valid ticket purchase record and / or travel authorization, enables both pre-purchase and post-payment scenarios to be managed based on the same user account, simplifying the user's travel process. Simultaneously, allowing the user to travel when the account has travel authorization and deducting the fare from the user account after the trip improves the flexibility of the fare deduction model, meets the user's needs for different travel scenarios, achieves seamless switching between fare deduction models, reduces the complexity of user operations, and enhances the user experience. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating a method for deducting fares based on an account model, provided in an embodiment of the present invention; Figure 2 for Figure 1 A flowchart illustrating an actual implementation of S03 in a method for deducting fares based on an account model; Figure 3 for Figure 1 A flowchart illustrating an actual implementation of S04 in a method for deducting fares based on an account model; Figure 4 for Figure 3 A flowchart of one actual manifestation of step S13; Figure 5 This is a schematic diagram of a ride fare deduction system based on an account model provided in an embodiment of the present invention. Detailed Implementation
[0019] To better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.
[0020] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
[0021] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.
[0022] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.
[0023] The traditional railway fare payment model is a "buy ticket first, then board" model, meaning passengers must select their train and complete payment in advance, and the system will generate a ticket voucher before they can enter the station and board the train. This model is suitable for seated travel and long-distance transportation.
[0024] However, with the increasing development of railway transportation networks and the diversification of operating models, especially the development of intercity and suburban railways towards public transport-like operations, the "buy now, ride later" fare collection model, which relies on ticket purchase, cannot flexibly adapt to passengers' needs for different travel scenarios. For example, for convenient intercity and suburban railway commuting scenarios, passengers hope to be able to simply swipe their cards when entering and exiting the station, similar to taking a bus—a "ride now, pay later" model. Therefore, this invention provides an account-based fare collection method to solve the above problems.
[0025] Please refer to Figure 1 The flowchart below shows a method for deducting fares based on an account model provided by an embodiment of the present invention, which includes the following steps: Step S01: Determine the corresponding user account based on the input travel voucher information.
[0026] In this embodiment, the boarding pass information is the electronic information corresponding to the boarding pass presented by the user when entering and exiting the station, and it has a corresponding relationship with the user account in the system. After receiving the boarding pass information provided by the user, the system maps it to a unique, pre-registered or temporarily created user account. Through the user account, the system can understand the user's identity, credit limit, account balance, valid ticket purchase records, station entry and exit information, etc., in order to perform subsequent fare calculation and collection.
[0027] In some embodiments, the system can extract key identifiers from the ride pass information (such as QR code content, NFC card number, ID card number, etc.). Then, based on the key identifiers, it queries the database or local cache to find the associated user account information.
[0028] In some embodiments, the fare voucher information may include, but is not limited to, dynamic QR code information, NFC card (e.g., mobile NFC card, NFC transit card, etc.) identification information, physical card (e.g., bank card, bus card, subway card, etc.) identification information, identity document (e.g., ID card, passport, etc.) identification information, biometric information (e.g., facial information, fingerprint information, etc.), etc., wherein: Dynamic QR codes are the most common way to pass through railway stations. They can be generated by the official railway app, requiring passengers to register as railway customers. The dynamic QR code refreshes every 30 seconds and includes information such as a timestamp, key signature, and user mapping. Dynamic QR codes can also be generated by third-party apps, such as WeChat Pay, Alipay Pay, and UnionPay, without requiring passengers to register as railway customers.
[0029] It should be noted that the above embodiments are only one preferred embodiment provided by the present invention, and the present invention does not specifically limit the category of travel voucher information.
[0030] Step S02: Check if there is a valid ticket purchase record in the user's account.
[0031] If not, proceed to step S03.
[0032] In this embodiment, after identifying the user account, the system checks whether there is a valid ticket purchase record in the user account's database or cache. A valid ticket purchase record is one with a status of "paid" that matches the train and boarding station for this trip, proving that the user has paid for the current journey.
[0033] Checking for valid ticket purchase records in a user's account is to determine which travel mode the user is currently using. If there are no valid ticket purchase records in the user's account, it means that the user is using the "travel first, buy ticket later" mode. In this case, the system executes step S03 to further determine whether the user's account has travel privileges and, based on this, decides whether to allow the user to travel.
[0034] Furthermore, if there is a valid ticket purchase record in the user's account, it means that the user is using the "buy ticket first, then ride" model. The system should allow the user to pass accordingly, and no further fare calculation or deduction is required for this ride.
[0035] In some embodiments, the step S02, which involves detecting whether a valid ticket purchase record exists in the user's account, can specifically be: The system queries the database associated with the user's account to check if a ticket purchase record exists that meets the following criteria: the purchase has been completed (payment status is successful), the train / date / station information is valid, and the purchase record covers the current entry or exit operation. If a record exists, it proves that a valid ticket purchase record exists in the user's account.
[0036] Step S03: Determine whether the user account has ride-hailing privileges.
[0037] If so, proceed to step S04.
[0038] In this embodiment, when the system detects that there is no valid ticket purchase record in the user's account, it indicates that the user is not currently using the "buy a ticket first, then ride" mode. At this time, the system needs to determine whether the user's account has the permission to ride, that is, whether the user's account is eligible for the "ride first, pay later" mode, in order to decide whether to allow the user to ride.
[0039] In the absence of a valid ticket purchase record, users may wish to use the "ride now, pay later" model. In this case, the system needs to verify whether the account has ride privileges, i.e., whether it has sufficient credit limit or a valid payment method to complete the ride. This process is a prerequisite for implementing the "ride now, pay later" model and is used to reduce the risk of users refusing to ride and pay.
[0040] For example, the system can check whether the user's account credit limit is available and sufficient, or whether the linked payment method (such as Alipay, WeChat, or bank card) is valid and does not exceed the limit. If the user's account meets at least one of the conditions for ride permission (valid credit limit or payment method), it is determined that the user has ride permission.
[0041] Step S04 allows the user to take the ride and deducts the fare from the user's account after the ride ends.
[0042] In this embodiment, after confirming that the user's account has travel authorization, the system will allow the user to travel. Then, after the user completes the trip (from entering the station to exiting the station), the system will deduct the corresponding fare from the user's account based on the trip cost. This process ensures that the travel fare is accurately calculated and collected, guarantees the railway operator's revenue, and maintains the sustainability of the system's credit model.
[0043] In some embodiments, the process mentioned in step S04, which allows users to take the ride and deducts the fare from their accounts after the ride, can be as follows: The system controls the opening of ticket gates, allowing users to board the train and updating their travel status. After the trip, the system calculates the fare based on factors such as the actual travel distance, time, and train type, generating a travel bill. The system then deducts the fare from the user's available balance based on the travel bill.
[0044] In some embodiments, to achieve centralized management of all fare payments, scattered deduction records are integrated into structured billing information, facilitating user inquiry, verification, and payment, while providing operators with a unified financial settlement basis. The method may further include: A bill is generated based on all deducted fares.
[0045] In this embodiment, after deducting all fares, the system summarizes all deduction records generated by the user within a specific period (such as one month) and generates a structured bill. The bill may include key data such as user account information, number of rides / fare details, total deduction amount, and deduction time, to achieve centralized management of all fares and provide users with a clear consumption record.
[0046] Based on the above technical solution, the account-based fare deduction method provided in this invention determines the corresponding user account based on the input travel voucher information; detects whether there is a valid ticket purchase record in the user account; if not, it determines whether the user account has travel authorization; if the user account has travel authorization, it allows the user to travel and deducts the fare from the user account after the trip. This invention, by determining whether the user account has a valid ticket purchase record and / or whether it has travel authorization, enables both pre-purchase and post-payment scenarios to be managed based on the same user account, simplifying the user's travel process. Simultaneously, allowing the user to travel when the account has travel authorization and deducting the fare from the user account after the trip improves the flexibility of the fare deduction mode, meets the user's needs for different travel scenarios, achieves seamless switching between fare deduction modes, reduces the complexity of user operations, and enhances the user experience.
[0047] Please refer to Figure 2 ,for Figure 1 A flowchart illustrating an actual implementation of S03 in a method for deducting fares based on an account model.
[0048] Based on the above embodiments, in some embodiments, step S03, which involves determining whether a user account has ride-hailing privileges, may specifically include, for example... Figure 2 The steps shown are as follows: Step S11: Determine whether the user's account balance is greater than the first preset value.
[0049] If yes, proceed to step S12; otherwise, proceed to step S13.
[0050] In this embodiment, the system obtains the user's account balance and then compares it with a pre-set first preset value to determine whether the account balance is sufficient to meet basic prepayment requirements for transportation. If the account balance is greater than the first preset value, it indicates that the user has the ability to pay the fare immediately, and step S12 is executed to confirm that the user account has transportation privileges.
[0051] Step S12: Determine if the user account has ride privileges.
[0052] In this embodiment, if the user's account balance is greater than a first preset value, the system confirms that the user's account has the right to ride in the "prepaid" mode. This process confirms that the user's account at least meets the minimum financial requirements and can perform a prepaid operation without credit risk (i.e., the fare is automatically deducted from the user's account after the ride), thus avoiding the risk of arrears.
[0053] Step S13: Determine whether the user account's credit limit is greater than the second preset value.
[0054] If yes, proceed to step S14; otherwise, proceed to step S15.
[0055] In this embodiment, if the user account balance is less than or equal to a first preset value, the system will check the user account's credit limit and compare the user account's currently available credit limit with a second preset value to determine whether the user account has a credit basis, that is, whether the credit limit is sufficient to cover the travel expenses for this trip.
[0056] When the user's credit limit is greater than the second preset value, it proves that the user's credit limit is sufficient to cover the travel expenses for this trip. At this time, step S14 is executed to determine that the user's account has travel authorization.
[0057] When the credit limit of a user's account is less than or equal to the second preset value, it proves that the credit limit of the user's account cannot cover the travel expenses for this trip. At this time, step S15 is executed to determine that the user's account does not have travel privileges.
[0058] Step S14: Determine if the user account has ride privileges.
[0059] In this embodiment, if the credit limit of a user account is greater than the second preset value, it indicates that the user account is qualified in terms of bearing credit risk and can execute the ride process under the credit mode. Although there is still a certain credit risk, it is considered to be controllable by the system. At this time, the system confirms that the user account has the ride permission under the "credit-based postpaid" mode.
[0060] Step S15: Determine that the user account does not have ride-hailing privileges.
[0061] In this embodiment, if the credit limit of a user account is less than or equal to the second preset value, it indicates that the user account is not qualified in terms of bearing credit risk and is not allowed to execute the ride process under the credit mode. At this time, the system confirms that the user account does not have the ride permission under the "credit-based postpaid" mode.
[0062] In some embodiments, when it is determined that a user account does not have boarding privileges, the ticket gate can be closed and a prompt message can be output.
[0063] In this embodiment, when the system determines that a user's account is not eligible to board the train, the system will actively control the ticket gate to close and send a prompt message to the user to remind them to recharge their account or purchase a ticket to avoid affecting their travel.
[0064] By physically blocking access through ticket gates, potential credit risks or operational chaos caused by unauthorized accounts forcibly passing through are avoided. Outputting prompts guides users to take remedial measures in a timely manner, improving the overall reliability of the service.
[0065] Based on the above technical solution, this embodiment takes into account both prepaid and credit payment fare deduction modes. The structured judgment logic simplifies the system decision-making process, improves processing efficiency, and effectively prevents the abuse of credit limits.
[0066] Please refer to Figure 3 ,for Figure 1 A flowchart illustrating an actual implementation of S04 in a method for deducting fares based on an account model.
[0067] In some embodiments, the step S04 mentioned above, deducting the fare from the user's account after the ride, may specifically include the following steps: Step S21: Generate the user account's travel information based on the entry and exit information corresponding to the travel voucher information.
[0068] In this embodiment, users provide a boarding pass when entering and exiting the station. Based on the entry and exit information corresponding to the boarding pass, the system generates travel information for the user's account. This travel information may include data such as the origin, destination, train type, and travel time of the trip, and is the basis for calculating the travel fare. The system can accurately calculate the travel fare payable by the user based on the travel information.
[0069] Step S22: Calculate the fare based on the trip information.
[0070] In this embodiment, after determining the user's account trip information, the system can automatically calculate the fare that the user needs to pay for this trip based on the trip information and preset billing rules (such as mileage-based billing, interval-based billing, time-based discounts, etc.).
[0071] In some embodiments, the system can determine the applicable billing rules and fare standards based on trip information. For example, it can look up the corresponding fare table based on the origin and destination. Then, based on mileage, interval, or time-based discounts, the system applies the corresponding calculation formula (such as mileage × base fare × time-based discount) to obtain the final fare.
[0072] Step S23: Select the corresponding deduction method based on the user account type to deduct the fare.
[0073] In this embodiment, the user account type may include, but is not limited to, registered accounts, temporary accounts, group accounts, etc. Different types of accounts have different needs and acceptance levels for deduction methods. Therefore, the system can select the corresponding deduction method according to the user account type, which can improve the user experience, meet the needs of different user groups, and adapt to different payment scenarios and preferences.
[0074] For example, for registered accounts, deductions can be made primarily from the account balance; for temporary users, deductions can be made primarily from the linked third-party applications. It should be noted that this embodiment is only a preferred embodiment, and it does not specifically limit the type of user account or the deduction method.
[0075] Based on the above technical solution, this embodiment achieves automated calculation of fares and dynamic matching of payment methods, reducing manual intervention and improving payment efficiency. At the same time, selecting different payment methods based on account type simplifies the operation process and meets diverse user needs.
[0076] Please refer to Figure 4 ,for Figure 3 A flowchart of one actual manifestation of step S13.
[0077] In some embodiments, step S13, which involves selecting the corresponding deduction method based on the user account type to deduct the fare, may specifically include the following steps: Step S31: Determine the type of user account.
[0078] Step S32: If the user account is a registered account, determine whether the account balance of the registered account is greater than or equal to the fare.
[0079] If yes, proceed to step S33; otherwise, proceed to step S34.
[0080] In this embodiment, if the account balance of the registered account is greater than or equal to the fare, then step S33 is executed to deduct the fare from the account balance of the registered account; if the account balance of the registered account is less than the fare, then step S34 is executed to deduct the fare based on the payment channel bound to the registered account.
[0081] The registered account is an account that has been pre-registered in the system. When a user account is a registered account, the system checks whether the registered account's balance is sufficient to cover the fare. This process aims to prioritize using the registered account's own balance for deduction, reducing reliance on external payment channels and increasing the success rate of deductions.
[0082] In some embodiments, to achieve structured and standardized management of account information, ensure the uniqueness and traceability of accounts, and provide a reliable data foundation for subsequent authorization checks, credit assessments, and billing operations, the method may further include: A registered account is generated based on the input registration information; the registration information includes user identity information, ride voucher binding information, and payment channel binding information.
[0083] In this embodiment, the system receives registration information proactively provided by the user. This registration information includes user identity information (such as name, ID number, mobile phone number, etc.), information on the binding of travel credentials (such as ID card binding information, NFC card binding information, physical card binding information, biometric binding information, etc.), and information on payment channels (such as bank card number, third-party payment account, etc.). Based on the registration information, the system creates a new, unique registered account and stores this registration information in association with the registered account.
[0084] Step S33: Deduct the fare from the registered account balance.
[0085] In this embodiment, when the registered account has a sufficient balance to pay for the ride, the system will perform a deduction operation to deduct the ride fare from the account balance.
[0086] Step S34: Deduct the fare based on the payment channel linked to the registered account.
[0087] In this embodiment, when the registered account balance is insufficient to cover the fare, the system will deduct the fare based on the payment channel (such as a bank card, third-party payment account, etc.) pre-linked to the registered account. The linked payment channel is a source of funds pre-authorized by the user and can be used for subsequent deductions.
[0088] Step S35: If the user account is a temporary account, the fare will be deducted based on the payment channel linked to the temporary account.
[0089] In this embodiment, the temporary account is designed for one-time or short-term use scenarios (such as scanning QR codes to ride public transportation) and does not involve account balance management. Therefore, directly using the payment channel bound to the temporary account to deduct fees is the most direct implementation method, which simplifies the management logic of the temporary account.
[0090] In some embodiments, when a temporary account is used to enter or exit a station by providing a travel voucher (such as a QR code) through a third-party payment application, the system will automatically generate a temporary account and bind the third-party payment application to the temporary account. When paying the fare, the system will directly call the third-party payment application bound to the temporary account to deduct the fare.
[0091] Step S36: If the user account is a group account, the fare will be deducted based on the payment channel linked to the group account.
[0092] In this embodiment, a group account represents an account within a group (such as a company department or a tour group) for transportation. After the passenger is verified, the fare deduction for the group account is completed based on the payment channel linked to the group account (such as a company-designated account or a bank card linked to the tour group), which facilitates management and settlement.
[0093] In some embodiments, the system can verify passenger permissions based on passenger information associated with a group account. After the group account passes verification, the fare can be calculated according to the group ticket fare calculation rules. Different groups can calculate fares according to different fare calculation rules. For example, discounts can be set based on the importance level of the group to which the group account belongs. For instance, when calculating fares, if the group account belongs to a level 3 group, the fare is discounted by 10%; if the group account belongs to a level 2 group, the fare is discounted by 20%; and if the group account belongs to a level 1 group, the fare is discounted by 30%, and so on.
[0094] Based on the above technical solution, this embodiment simplifies the billing process, reduces user operation steps, and provides operators with a variety of charging model options, ensuring the efficient operation of the system in diverse application scenarios.
[0095] Please refer to Figure 5 The diagram below illustrates the structure of an account-based fare deduction system provided in an embodiment of the present invention. This account-based fare deduction system may include: The determination module 100 is used to determine the corresponding user account based on the input travel voucher information; The detection module 200 is used to detect whether there is a valid ticket purchase record in the user's account; The judgment module 300 is used to determine whether the user account has the right to travel if there is no valid ticket purchase record in the user account. The deduction module 400 is used to allow users to ride if their accounts have ride privileges, and to deduct the ride fare from the user's account after the ride.
[0096] Based on the above embodiments, in one specific embodiment, the determination module 300 is specifically used for: Determine whether the user's account balance is greater than a first preset value; If so, then the user account is confirmed to have ride privileges; If not, then determine whether the user's credit limit is greater than the second preset value; If the user's credit limit is greater than the second preset value, then the user's account is determined to have ride privileges. If a user's credit limit is less than or equal to the second preset value, then the user's account is determined not to have ride privileges.
[0097] Based on the above embodiments, in one specific embodiment, the determination module 300 is further configured to: When it is determined that the user account does not have boarding privileges, the ticket gate is closed and a prompt message is displayed.
[0098] Based on the above embodiments, in one specific embodiment, the deduction module 400 can be used for: Based on the entry and exit information corresponding to the travel voucher information, the user account's travel information is generated; Calculate travel costs based on trip information; The fare will be deducted based on the user's account type, using the appropriate deduction method.
[0099] Based on the above embodiments, in one specific embodiment, the deduction module 400 can be used for: Determine the type of user account; If the user account is a registered account, then determine whether the account balance of the registered account is greater than or equal to the fare; If so, the fare will be deducted from the registered account balance; If not, the fare will be deducted based on the payment channel linked to the registered account; If the user account is a temporary account, the fare will be deducted based on the payment channel linked to the temporary account; If the user account is a group account, the fare will be deducted based on the payment channel linked to the group account.
[0100] Based on the above embodiments, in one specific embodiment, the deduction module 400 is further used for: A registered account is generated based on the input registration information; the registration information includes user identity information, ride pass binding information, and payment channel binding information.
[0101] Based on the above embodiments, in one specific embodiment, the deduction module 400 is further used for: A bill is generated based on all deducted fares.
[0102] This embodiment provides an electronic device, including a processor and a memory. The memory is used to store at least one instruction. When the instruction is loaded and executed by the processor, it implements the above-described method for deducting fares based on the account model. Its execution method and beneficial effects are similar and will not be described again here.
[0103] This invention provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the above-described method for deducting fares based on an account model. The execution method and beneficial effects are similar and will not be described again here.
[0104] It should be noted that although the steps are described in a specific order above, it does not mean that the steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently, or even in a different order, as long as the required function can be achieved.
[0105] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for deducting fares based on an account model, characterized in that, include: The corresponding user account is determined based on the input travel voucher information; Check if there is a valid ticket purchase record in the user account; If not, determine whether the user account has ride privileges; If the user account has ride privileges, the user is allowed to ride, and the ride fare is deducted from the user account after the ride.
2. The method according to claim 1, characterized in that, The step of determining whether the user account has ride-hailing privileges includes: Determine whether the user's account balance is greater than a first preset value; If so, then the user account is confirmed to have ride privileges; If not, determine whether the credit limit of the user account is greater than the second preset value; If the credit limit of the user account is greater than the second preset value, then the user account is determined to have ride privileges. If the credit limit of the user account is less than or equal to the second preset value, then it is determined that the user account does not have the right to ride.
3. The method according to claim 1 or 2, characterized in that, The method further includes: When it is determined that the user account does not have boarding privileges, the ticket gate is closed and a prompt message is displayed.
4. The method according to claim 1, characterized in that, The process of deducting the fare from the user's account after the ride includes: Based on the entry and exit information corresponding to the travel voucher information, the travel information of the user account is generated; Calculate the travel fare based on the travel information; The fare will be deducted based on the user account type by selecting the corresponding deduction method.
5. The method according to claim 4, characterized in that, The step of selecting the corresponding deduction method based on the user account type to deduct the fare includes: Determine the type of the user account; If the user account is a registered account, then determine whether the account balance of the registered account is greater than or equal to the fare; If so, the fare will be deducted from the account balance of the registered account; If not, the fare will be deducted based on the payment channel linked to the registered account; If the user account is a temporary account, the fare will be deducted based on the payment channel linked to the temporary account; If the user account is a group account, the fare will be deducted based on the payment channel linked to the group account.
6. The method according to claim 5, characterized in that, The method further includes: A registered account is generated based on the input registration information; the registration information includes user identity information, ride voucher binding information, and payment channel binding information.
7. The method according to claim 1, characterized in that, The method further includes: A bill is generated based on all the aforementioned fare deductions.
8. A fare deduction system based on an account model, characterized in that, include: The determination module is used to determine the corresponding user account based on the input travel voucher information; The detection module is used to detect whether there is a valid ticket purchase record in the user account; The judgment module is used to determine whether the user account has travel privileges if there is no valid ticket purchase record in the user account. The deduction module is used to allow users to ride the bus if their accounts have ride privileges, and to deduct the fare from the user accounts after the ride.
9. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store at least one instruction, which, when loaded and executed by the processor, implements the account-based fare deduction method as described in any one of claims 1-7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the account-based fare deduction method as described in any one of claims 1-7.