Terms & Conditions

LOCAL RAHI

Terms & ConditionsPrivacy PolicyCarpool Cost-Sharing PolicyPayment, Cancellation & Refund PolicyCost-Sharing Reimbursement PolicySafety & Community GuidelinesProfile & Verification PolicyAccount & Data Deletion PolicySuspension & Termination PolicyGrievance & Dispute Resolution PolicyLocation & Live Location PolicyWebsite & App Disclaimer

Company

LOCAL RAHI PRIVATE LIMITED

Website

localrahi.com

Grievance Officer

Pravin Kumar, Director & Grievance Officer

Contact

hello@localrahi.com | 8884188741

Registered Office

I-1602, Hawelia Valencia Homes, Sector-1, Greater Noida (West), Bisrakh, Gautam Buddha Nagar - 201306, Uttar Pradesh, India

Core principle: Local Rahi facilitates private carpooling for sharing eligible journey/fuel costs. Offering a pool is not intended for commercial profit or operation as a taxi/passenger transport business.

Document Status and Interpretation

This document is the expanded master policy draft for the Local Rahi private carpool platform. It is intended to align the public-facing policies with the current product architecture described by Local Rahi. It should be checked against the final production application, payment configuration, verification process and support workflow before publication.

Where this document says Local Rahi 'may' perform an action, the action should only be represented publicly if the relevant operational capability or policy is actually implemented. Nothing in this document should be interpreted as creating an exemption from transport, tax, consumer, payment, privacy, insurance or other applicable law merely because Local Rahi characterizes its service as private cost sharing.

Key Defined Terms

User: a person holding a Local Rahi account.

Offer Pool: the action by which a user offers available seats on a genuine private journey.

Find Pool: the action by which a user seeks to join a compatible private journey.

User Offering the Pool / Car Owner: the user associated with an Offer Pool. This term does not by itself mean a commercial driver.

Rider / Co-traveller: a user seeking or joining an offered pool.

Cost-Sharing Contribution: the amount attributable to eligible journey/fuel cost sharing under Local Rahi's methodology.

Cost-Sharing Reimbursement: the eligible amount Local Rahi facilitates to the user offering the pool after applicable conditions are satisfied. It is not described by Local Rahi as salary or commercial-driver earnings.

Final Total Payable: the amount shown to the rider before payment authorization. Internal Local Rahi/platform/payment-processing components are not necessarily separately itemized.

Profile Unverified: optional Government ID or Corporate ID profile verification has not been successfully completed; this is separate from mobile OTP verification.

1. Terms & Conditions

1.1 Acceptance and Scope

These Terms govern access to and use of the Local Rahi mobile application, informational website and related services. By creating an account, accepting these Terms, or using applicable Local Rahi functionality, a user agrees to comply with these Terms and the policies incorporated into them.

1.2 Platform Role

Local Rahi provides technology that helps users discover and coordinate private carpools, communicate, manage bookings and, where enabled, facilitate payments, refunds and eligible cost-sharing reimbursements. Local Rahi does not itself become the driver, passenger, vehicle owner, insurer or emergency-response provider merely by facilitating an interaction.

1.3 Private Carpool / No-Profit Rule

An Offer Pool must relate to a genuine private journey that the user intends to make. Available seats are offered for permitted sharing of eligible journey/fuel costs with co-travellers, not for the purpose of earning commercial profit. Users must not use the carpool functionality as a taxi, commercial cab, chauffeur service or other profit-making passenger transport activity.

Local Rahi may calculate, constrain or review contribution amounts and activity patterns to support the private cost-sharing model. A user must not circumvent these controls through unauthorized off-platform charges, fabricated routes, false attendance or other manipulation.

1.4 Registration and Mobile Verification

A valid mobile number and successful OTP verification are required to create or authenticate a Local Rahi account. OTP verification confirms control of the registered mobile number; it does not by itself mean that the user's Government ID, Corporate ID, vehicle, driving licence, insurance, background or driving ability has been verified.

Users must provide genuine and current registration information and must not impersonate another person or use information they are not authorized to use.

1.5 One Account; No Permanent Rider/Driver Role

Local Rahi uses one user account for private carpooling. Registration does not permanently classify a user as a rider or driver. The same user may Find Pool for one journey and Offer Pool for another, subject to the requirements applicable to that action.

Users must not create or use multiple accounts to manipulate verification, ratings, promotions, payments, refunds, contribution limits, suspensions or other platform controls.

1.6 One Active Device / Session

For account security, Local Rahi may permit one active device/session for an account at a time. Successful authentication on a new device may revoke the previous active session and deactivate account-specific notification access on the previous device.

1.7 Optional Profile Verification

Government ID and Corporate ID profile verification are optional unless additional verification is specifically required for a feature, security control, payment requirement, legal requirement or risk-control process. A user who skips optional verification may be shown as 'Unverified' or 'Profile Unverified' while continuing to use otherwise permitted functionality.

1.8 Age and Eligibility

Local Rahi is intended only for individuals who are at least 18 years old. By creating an account and accepting the Terms & Conditions, each user confirms that they are 18 or older. Date of birth is not required during basic registration solely to enforce this confirmation. A user offering a pool must also hold a valid driving licence applicable to the vehicle and comply with all applicable vehicle, insurance and road-safety requirements.

1.9 Offering a Pool

The journey must be genuine and consistent with private cost sharing.

The user is responsible for being legally permitted to drive/use the vehicle and for applicable licence, registration, insurance, roadworthiness and other legally required documentation.

The user must provide materially accurate journey, vehicle and seat information.

The user must not knowingly exceed lawful or safe seating capacity.

The user must not transfer a confirmed pool to an unrelated person or materially different vehicle without appropriate disclosure and, where required, agreement.

The user must not demand unauthorized additional cash/UPI/off-platform amounts intended to create profit.

Local Rahi may require a Private Carpool Declaration immediately before publication and may record the accepted policy version and audit information.

1.10 Finding and Joining a Pool

Riders must provide materially accurate trip requirements.

Riders should arrive at the agreed pickup point within the applicable waiting arrangement.

Additional passengers should not be brought beyond the confirmed booking without appropriate agreement.

Riders must not misuse another user's contact, location or profile information.

Applicable payments must be completed through authorized Local Rahi flows where payment is required.

1.11 Requests, Invitations and Booking Status

A request or invitation is not the same as a paid confirmed booking. A typical flow may move from REQUESTED to ACCEPTED/PAYMENT_PENDING and then CONFIRMED after verified payment success. Local Rahi may reject, cancel or reconcile inconsistent or duplicate booking states.

1.12 Recurring Pools

Recurring functionality may create multiple dated occurrences from a recurring preference or series. Each occurrence can have its own matching, booking, payment, cancellation, attendance, completion, refund and reimbursement status. Cancellation of one occurrence does not automatically cancel all future occurrences unless the selected action expressly does so.

Recurring use remains subject to the same no-profit rule. A recurring schedule alone does not establish commercial use, but Local Rahi may review patterns reasonably inconsistent with genuine private carpooling.

1.13 Payments and Final Total Payable

The authoritative payable amount is determined or confirmed by Local Rahi's backend systems. Before payment authorization, the rider is shown the final total payable for the booking. Local Rahi does not necessarily separately display internal Local Rahi/platform or payment-gateway related charge components. Internal allocation may be maintained for accounting, processing, settlement, taxation, reconciliation and reimbursement, subject to applicable law.

Users must not manipulate client-side amounts or treat an unverified client-side payment message as proof of payment. A booking is considered successfully paid only after the applicable backend/provider verification.

1.14 Attendance and Ride Completion

Payment success does not mean that the rider has joined the ride. Attendance is tracked separately. Local Rahi may use PENDING, JOINED and UNJOINED attendance states and may retain relevant timestamps and location/audit evidence to resolve disputes.

A user must not falsify attendance to obtain an improper refund or reimbursement.

1.15 Cost-Sharing Reimbursement

After an eligible ride is completed, Local Rahi may initiate the applicable cost-sharing reimbursement for a rider whose payment is successful and attendance is JOINED, provided no applicable fraud, chargeback, legal or dispute hold exists. The reimbursement is intended to share eligible journey/fuel costs and is not represented by Local Rahi as salary or commercial-driver earnings.

1.16 Calling and Messaging

In-app messaging and calling are provided for legitimate ride-related coordination. Harassment, threats, unsolicited marketing, unlawful activity, scraping or unrelated solicitation are prohibited. Current direct calling may expose a telephone number to the other legitimate participant. Masked calling may be introduced in the future.

1.17 Ratings and Reviews

Ratings and reviews should relate to genuine interactions. Fake, retaliatory, manipulated, abusive, discriminatory, threatening, defamatory or privacy-invasive content is prohibited. Local Rahi may review or remove content that violates policy.

1.18 User Conduct and Prohibited Use

Fraud, fake rides, collusion or fabricated attendance.

Commercial/profit-making passenger transport through the private carpool feature.

Harassment, violence, stalking, threats or dangerous conduct.

Unauthorized extra charges or attempts to bypass platform payment/contribution controls.

Illegal goods, unlawful activity or prohibited dangerous materials.

Scraping, publishing, selling or misusing another user's personal/location information.

Attempts to bypass security, suspension, verification, payment, refund or contribution controls.

1.19 No Guaranteed Match, ETA or Journey

Local Rahi does not guarantee a match, acceptance, successful payment, pickup, journey completion, route, arrival time or continuous third-party service availability. Routes, distances and ETAs are estimates and may change because of traffic, road conditions, weather, GPS accuracy, user actions or other factors.

1.20 Accident, Emergency, Injury, Damage & Insurance Policy

Local Rahi is a technology platform facilitating private carpool coordination and cost sharing. Local Rahi is not the driver, vehicle owner, passenger, insurer, transport operator, emergency service, or party controlling the journey. Users participate at their own judgment and risk.

To the maximum extent permitted by applicable law, Local Rahi is not responsible for accidents, collisions, death, bodily or mental injury, medical expenses, vehicle or property damage, theft, loss of belongings, route conditions, traffic violations, unsafe driving, misconduct, insurance rejection, or any other loss arising during or in connection with a carpool journey.

The vehicle owner and driver are solely responsible for possessing a valid driving licence, registration, legally required motor insurance, pollution certificate, roadworthy vehicle, safe driving, lawful seating capacity, and compliance with traffic and motor-vehicle laws. Riders remain responsible for their personal safety and belongings.

Local Rahi does not provide motor, accident, health, life, travel, or property insurance and does not guarantee that a user's insurance will cover a particular journey, passenger, claim, or loss. Users must verify applicable insurance coverage themselves.

During an emergency, users must immediately contact police, ambulance, fire, medical, insurer, or other competent emergency services. Local Rahi support is not an emergency-response service.

Nothing in this clause excludes or restricts liability that cannot lawfully be excluded, including liability arising from Local Rahi's own proven fraud, wilful misconduct, gross negligence, or breach of a mandatory statutory obligation.

Local Rahi may preserve relevant platform records, accept incident reports or respond to lawful authority requests without thereby accepting liability or undertaking to compensate a user.

1.21 Lost Items

Users are responsible for personal belongings. Local Rahi does not guarantee recovery, replacement or reimbursement for items lost, forgotten, stolen or damaged. Local Rahi may facilitate reasonable communication about a lost item without accepting responsibility for it.

1.22 Suspension and Termination

Local Rahi may warn, restrict, temporarily suspend or permanently terminate access where it reasonably determines that a user materially violated policy, engaged in fraud, unsafe or unlawful conduct, misused payment/refund/attendance processes, provided materially false information, circumvented safeguards, used the service for prohibited commercial profit, or where action is reasonably required for safety, security, legal or regulatory purposes.

Immediate action may be taken where reasonably necessary to protect users, prevent harm/fraud, secure the platform, preserve evidence or comply with law. A terminated user must not create another account to circumvent the termination.

Suspension or termination does not automatically cancel legitimate refunds or cost-sharing reimbursements unless the relevant transaction is itself subject to a legitimate fraud, chargeback, legal, compliance or dispute hold.

1.23 Third-Party Services

Local Rahi may depend on third parties for OTP, maps, payments, notifications, hosting, verification and related services. Their availability, processing time and independent terms may affect the service.

1.24 Changes and Contact

Local Rahi may update these Terms as the product, policies or legal requirements change. Material changes may require renewed acceptance. Questions may be sent to hello@localrahi.com. These Terms are governed by the laws of India. Subject to applicable law, courts at Gautam Buddha Nagar, Uttar Pradesh shall have exclusive jurisdiction.

3. Carpool Cost-Sharing Policy

3.1 Purpose and Model

Local Rahi's carpool service is designed to facilitate genuine private journeys in which users travelling in the same or similar direction share eligible journey/fuel costs. The user offering a pool is not permitted to use the carpool feature as a profit-making passenger transport business.

3.2 Genuine Journey Requirement

An Offer Pool should correspond to a journey the user genuinely intends to make. Fabricated journeys, journeys created solely to collect money, or repeated activity reasonably indicating operation as a commercial passenger service are prohibited.

3.3 Platform-Controlled Contribution

Local Rahi may calculate or constrain the cost-sharing contribution using route, distance and other permitted journey-cost factors. The authoritative amount must come from Local Rahi's backend rather than a user-controlled client value.

3.4 No-Profit Safeguards

Contribution limits or formulas.

Anomaly and repeated-pattern review.

Restrictions on unauthorized extra payments.

Review of fabricated routes, seats or attendance.

Account action for prohibited commercial use.

3.5 Final Rider Amount vs Reimbursement

The rider is shown a final total payable amount before payment authorization. Local Rahi does not necessarily separately itemize internal Local Rahi/platform or payment-gateway related components. The amount reimbursed to the user offering the pool is the eligible cost-sharing reimbursement determined under the platform methodology and may be lower than the rider's final total payable.

Any difference between the final total payable and the eligible cost-sharing reimbursement is not an additional earning payable to the user offering the pool.

3.6 Off-Platform Charges

The user offering the pool must not demand unauthorized additional cash, UPI or other off-platform payments intended to circumvent Local Rahi's contribution controls or create profit.

3.7 Recurring Journeys

Recurring journeys remain subject to the same genuine-journey and no-profit requirements. Regular commuting can still be private carpooling; Local Rahi may nevertheless review patterns reasonably inconsistent with the platform model.

3.8 Declaration and Audit

Local Rahi may require a declaration before Offer Pool publication confirming that the journey is private and offered for eligible journey/fuel cost sharing, not commercial profit. Local Rahi may record policy version, timestamp and appropriate security/audit information.

3.9 Legal Qualification

This Policy defines Local Rahi's intended platform model and user rules. It does not by itself establish a statutory exemption from transport, tax, payment, licensing, insurance or other applicable requirements.

4. Payment, Cancellation & Refund Policy

4.1 Payment Trigger

Payment may become due after a ride request or invitation is accepted. Acceptance alone does not mean payment has succeeded or that the rider has joined the ride.

4.2 Final Amount

Before authorization, the rider sees the final total payable. Local Rahi may maintain an internal accounting breakdown without separately displaying Local Rahi/platform or payment-gateway charge components, subject to applicable law.

4.3 Payment Verification

Client-side success is not authoritative. Local Rahi should verify payment through the applicable payment provider/backend process before marking the payment SUCCESS and booking CONFIRMED. Duplicate webhook/provider events should be handled idempotently.

4.4 Payment Failure / Pending

A failed or pending payment does not create a successfully paid booking merely because the checkout interface was opened. If funds appear debited while status remains unresolved, Local Rahi may reconcile the transaction with the provider before confirming or refunding it.

4.5 Duplicate Payment

A verified duplicate payment for the same booking should be investigated and the appropriate duplicate amount refunded.

4.6 Rider Cancellation Before Ride Start

Where a rider has successfully paid and cancels before the ride starts, the applicable refund will follow the cancellation conditions shown for the booking. The current product baseline may provide a full refund where no different condition has been clearly established; the final production rule must be made consistent across app UI and this policy.

4.7 User Offering Pool Cancels

If the user offering the pool cancels an eligible ride, Local Rahi should initiate applicable refunds for successfully paid rider bookings, subject to provider processing and lawful exceptions.

4.8 UNJOINED Attendance

Where a paid rider is validly recorded UNJOINED, the corresponding cost-sharing reimbursement must not be released to the user offering the pool. Rider refund treatment follows the applicable attendance/refund rule after any necessary verification.

4.9 Refund Amount Presentation

Because Local Rahi may present one final total payable rather than separately itemizing internal cost components, the user should be shown the applicable refund amount/status. Internal accounting treatment may be handled separately for reconciliation and payment processing.

4.10 Refund Processing Time

A refund is considered initiated when Local Rahi successfully submits it to the payment provider. Actual credit time may depend on the provider, banking network, card issuer or UPI/bank system. Local Rahi should not guarantee an exact bank-credit time unless the provider supports that commitment.

4.11 Chargebacks and Reversals

Payments may be subject to chargeback, reversal or provider dispute. Local Rahi may investigate and reconcile affected bookings, refunds and reimbursements and may place a legitimate hold where necessary.

4.12 Fraud and Abuse

Local Rahi may investigate repeated improper refund claims, collusion, fake rides, manipulated attendance, account abuse or other suspicious activity. This does not remove rights that cannot lawfully be restricted.

4.13 No Sensitive Credentials

Users must never send Local Rahi their card CVV, UPI PIN, ATM PIN, online-banking password or OTP as part of a payment/refund complaint.

4.14 Final Cancellation Matrix - Launch Configuration

The exact production cancellation matrix (including any waiting period, cancellation cutoff, treatment of platform/internal components and dispute window) must be finalized before public launch and reflected identically in the app and published policy.

5. Cost-Sharing Reimbursement Policy

5.1 Nature of Reimbursement

A reimbursement under this Policy is the eligible cost-sharing amount facilitated to the user offering the pool. Local Rahi does not describe it as salary, driver earnings or commercial fare.

5.2 Eligibility

Ride is COMPLETED.

Applicable rider payment is SUCCESS.

Applicable attendance is JOINED.

No prior successful reimbursement exists.

No legitimate fraud, chargeback, legal, compliance or dispute hold prevents processing.

5.3 Status Flow

The reimbursement lifecycle may use ON_HOLD -> ELIGIBLE -> PROCESSING -> PAID, with FAILED or CANCELLED where applicable. Before ride completion, an otherwise successful payment can remain ON_HOLD.

5.4 Immediate Initiation vs Bank Credit

Where all eligibility conditions are satisfied, Local Rahi may initiate reimbursement promptly after completion. 'Initiated' does not mean guaranteed immediate bank/UPI credit; provider and banking processing time may apply.

5.5 Failed Reimbursement

If a reimbursement fails because of invalid bank/UPI information, provider rejection, beneficiary verification, banking failure or another processing issue, Local Rahi should keep it in an appropriate failed/pending state and retry or request corrected information rather than marking it paid.

5.6 Payout Information

Local Rahi may collect account-holder name, bank account/IFSC or UPI information and provider beneficiary/verification references where necessary to facilitate an eligible reimbursement. Such information should not be displayed to unrelated users.

5.7 Suspension/Termination

A legitimate eligible reimbursement should not be confiscated merely because an account is suspended or terminated. It may, however, be held where the relevant transaction itself is subject to a legitimate fraud, chargeback, legal, compliance or dispute investigation.

5.8 No Wallet

The current Local Rahi model does not require a stored-value Local Rahi wallet. Reimbursements are intended to be initiated through the configured payment/reimbursement provider to the eligible destination.

5.9 Provider Requirements

Actual reimbursement capability may depend on the payment provider's merchant, beneficiary, verification, KYC/KYB and payout requirements. Local Rahi should not promise a payout method that has not been approved or enabled by the provider.

6. Safety & Community Guidelines

6.1 Shared Responsibility

Users should exercise appropriate judgment before and during a carpool. Profile verification, ratings, maps and other platform features can support decision-making but cannot eliminate travel or interpersonal risk.

6.2 Vehicle and Driving

Do not knowingly drive without legally required permission/documentation.

Do not knowingly exceed lawful/safe seating capacity.

Do not provide materially false vehicle information.

Do not engage in unsafe, reckless or unlawful driving.

Do not substitute another person/vehicle in a misleading manner.

6.3 Respectful Conduct

No harassment, threats, violence, stalking or discrimination.

No intentional property damage.

No unlawful solicitation or marketing.

No illegal activity or prohibited dangerous materials.

No misuse of another user's phone number, live location, messages or profile data.

6.4 Pickup and Waiting

Users should make reasonable efforts to reach the agreed pickup point on time. The production app should define a reasonable waiting rule before UNJOINED can be recorded. The exact waiting duration remains a launch configuration and must be published consistently.

6.5 Luggage

Users should disclose unusual or substantial luggage where relevant. A user offering the pool may reasonably decline items that cannot be safely accommodated.

6.6 Accidents and Emergencies

Local Rahi support is not an emergency-response service. In an accident, medical emergency, immediate safety threat or other emergency, users should contact appropriate emergency services, police, medical providers, insurers or other relevant authorities.

6.7 Liability / No Insurance Promise

To the extent permitted by applicable law, Local Rahi does not assume responsibility for accidents, personal injury, death, vehicle/property damage, theft or lost belongings arising during or in connection with a journey, and does not provide compensation or insurance unless expressly stated for a particular service.

6.8 Lost Items

Local Rahi may facilitate communication about a lost item but does not guarantee recovery, replacement or reimbursement.

6.9 Reporting and Blocking

Local Rahi may provide Report User / Report Ride and blocking features. Reports may cover unsafe driving, harassment, fake rides, unauthorized payment demands, incorrect vehicle information, fraud or other misuse. Serious or repeated reports may lead to investigation, restriction or suspension.

6.10 Attendance Integrity

JOINED/UNJOINED status affects financial outcomes and must be truthful. Relevant pickup-location and timestamp evidence may be retained for dispute handling. Normal attendance states should not be manipulated after the fact without an auditable support/admin correction process.

9. Suspension & Termination Policy

9.1 Suspension

Suspension is a temporary restriction of some or all account functionality while a matter is investigated, a safety/security risk exists, or a material policy issue is addressed.

9.2 Termination

Termination is Local Rahi's permanent ending of a user's access to some or all Local Rahi services because of serious/repeated policy violations, fraud, unsafe/unlawful conduct, prohibited commercial use, circumvention or other valid grounds.

9.3 Possible Grounds

Fraud, fake rides or collusion.

Harassment, violence or serious unsafe conduct.

Materially false verification or account information.

Payment/refund/attendance/reimbursement abuse.

Commercial/profit-making misuse of private carpooling.

Unauthorized extra payment demands.

Multiple accounts used to bypass controls.

Misuse of personal/location information.

Legal, regulatory or security requirements.

9.4 Warning and Immediate Action

Depending on seriousness, Local Rahi may provide a warning or opportunity to respond. Immediate temporary or permanent action may be taken where reasonably necessary to protect users, prevent fraud/harm, secure the platform, preserve evidence or comply with law.

9.5 Financial Transactions

Suspension/termination does not automatically cancel legitimate payments, refunds or eligible cost-sharing reimbursements. A transaction may be held if it is itself under a legitimate fraud, chargeback, legal, compliance or dispute investigation.

9.6 Circumvention

A suspended or terminated user must not create/use another account to bypass the action.

9.7 Termination vs Deletion

Termination restricts service access and does not automatically erase personal information. A separate account-deletion request is governed by the Account & Data Deletion Policy and applicable retention requirements.

9.8 Review / Appeal - Operational Decision

Local Rahi should establish a practical review channel for users who believe a suspension/termination is incorrect. The final response process and any internal time target should be defined before launch rather than promised here without an operational workflow.

10. Grievance & Dispute Resolution Policy

10.1 Types of Issues

Ride/request/invitation disputes.

Incorrect JOINED/UNJOINED attendance.

Payment, duplicate debit or payment-status issues.

Cancellation/refund disputes.

Cost-sharing reimbursement disputes.

Verification/profile complaints.

Harassment, unsafe conduct or privacy complaints.

Suspension/termination review requests.

10.2 How to Report

Users should provide the registered mobile number, relevant ride/booking/payment reference, description of the issue and supporting information reasonably available. Users must not send payment secrets such as OTP, UPI PIN, CVV or banking password.

10.3 Evidence

Local Rahi may review booking state changes, payment-provider references, attendance events, relevant pickup/location evidence, timestamps, messages where appropriately available, verification records, reports and other platform audit information.

10.4 Attendance Disputes

Because attendance affects refunds and reimbursements, an incorrect JOINED/UNJOINED report may be reviewed before final financial treatment. Corrections should be auditable.

10.5 Payment Disputes

Local Rahi may reconcile payment/refund/reimbursement status with the applicable provider before reaching a final platform decision.

10.6 Safety Complaints

Serious safety reports may lead to immediate temporary restriction while investigated. Local Rahi support is not a substitute for police, medical or emergency services.

10.7 Grievance Officer

Pravin Kumar, Director & Grievance Officer, LOCAL RAHI PRIVATE LIMITED. Email: hello@localrahi.com. Phone: 8884188741.

10.8 Response Timelines - Legal/Operational Confirmation Required

The published grievance page should state response/acknowledgement timelines that Local Rahi can actually meet and that satisfy applicable legal requirements. This master draft intentionally does not invent a universal deadline before applicability and support capacity are confirmed.

10.9 Dispute Window

Local Rahi may encourage prompt reporting of ride/payment issues, but any platform reporting window should not be worded to unlawfully remove rights that cannot be restricted. The production dispute window remains to be finalized.

12. Website & App Disclaimer

12.1 Current Website Scope

localrahi.com currently serves primarily as an informational website for company/service information, policies and contact/support information. Carpool booking and related transaction functionality is currently intended primarily through the Local Rahi mobile application.

12.2 Future Website Features

Local Rahi may introduce booking, payment or other functionality on the website in the future. Policies and disclosures should be updated before or when those features launch.

12.3 Technology Estimates

Map routes, distances, ETAs, matching suggestions and other calculated information are estimates and may be affected by third-party data, traffic, device location accuracy, network conditions and user input.

12.4 No Guaranteed Availability

Local Rahi does not guarantee continuous app/site availability, a specific match, a particular user's availability, a successful payment, or completion of a journey.

12.5 Third-Party Links/Services

Where Local Rahi links to or relies on third-party services, those services may have independent terms and privacy practices. Local Rahi does not control all third-party systems.

12.6 No Emergency Service

Neither the website nor ordinary Local Rahi support should be relied upon as an emergency-response service.

13. Production Policy Decisions Still to Finalize

The following items should be decided before the public policies are published as final. They are intentionally marked rather than guessed:

Minimum age and eligibility are confirmed: every user must be at least 18 years old, and a user offering a pool must hold a valid driving licence applicable to the vehicle.

Exact pickup waiting period before an eligible UNJOINED decision.

Final rider cancellation matrix and any cancellation cutoffs.

Exact treatment of refunds in each booking/attendance state.

Dispute/reporting window and operational escalation path.

Suspension/termination review or appeal process.

Accepted Government ID and Corporate ID types.

Identity-verification provider/process and verification-data retention schedule.

Any vehicle/driving-document verification required by Local Rahi.

Production Cashfree or other provider requirements for cost-sharing reimbursements.

Final privacy retention schedule by data category.

Exact prominent disclosure wording if background/sensitive location is used.

14. Publication and Implementation Checklist

Publish Privacy Policy at /privacy-policy.

Publish Terms & Conditions at /terms-and-conditions.

Publish Carpool Cost-Sharing Policy at /carpool-cost-sharing-policy.

Publish Payment, Cancellation & Refund Policy at /cancellation-refund-policy.

Publish Account & Data Deletion page at /account-deletion.

Publish Safety & Community Guidelines at /safety.

Publish Profile & Verification information at /verification or within Terms/Help.

Publish Grievance & Dispute process at /grievance.

Make policies accessible without login and link them from the website footer.

Link relevant policies from registration, Offer Pool, payment, profile verification and account-deletion screens.

Record material policy/declaration acceptance with policy version and timestamp.

Ensure app behavior matches policy wording for final payable amount, refunds and reimbursement.

Ensure Google Play Data Safety answers match actual collection/sharing.

Ensure payment-provider onboarding description matches the real private cost-sharing flow.

Update policies before launching masked calling, website booking/payment, new analytics/advertising SDKs or materially new permissions.

15. Recommended In-App Notices

15.1 Registration

By creating an account, I agree to Local Rahi's Terms & Conditions and acknowledge the Privacy Policy.

15.2 Offer Pool Declaration

I confirm that this is a genuine private journey and that I am offering available seats for eligible journey/fuel cost sharing, not for commercial profit.

15.3 Profile Verification

Government ID / Corporate ID profile verification is optional. An Unverified profile means optional profile verification has not been completed; it does not by itself mean the user is unsafe or fraudulent.

15.4 Payment

Show the rider the final total payable before payment authorization. Do not describe internal Local Rahi/platform/payment-gateway components as separately itemized if the UI does not actually itemize them.

15.5 Safety

In an emergency, contact the appropriate emergency services. Local Rahi support is not an emergency-response service.

16. Final Drafting Note

This expanded master document is designed to be a source document from which individual public website policies can be produced. Before publication, Local Rahi should verify every operational statement against the production application and obtain qualified legal/compliance review for jurisdiction-specific conclusions, particularly transport/aggregator classification, consumer pricing disclosure, privacy/data retention, payment/payout requirements, insurance implications and age eligibility.

17. Detailed Registration, Eligibility & Account Rules

17.1 Registration Lifecycle

Registration begins with a valid mobile number and successful OTP verification. After OTP verification, Local Rahi may create the minimum account record needed to establish the user session. Basic profile information should then be collected only to the extent genuinely required for account operation. Optional verification, vehicle information and reimbursement information should not be presented as mandatory registration fields unless they are actually required for the feature the user is attempting to use.

17.2 Accuracy and Account Ownership

A user must register and operate an account for their own legitimate use. The registered mobile number must remain under the user's control. A user must not impersonate another person, knowingly provide materially false information, sell or transfer an account, or allow another person to use the account in a way that defeats identity, safety, payment or suspension controls. Local Rahi may request re-authentication when a material security risk is detected.

17.3 One Active Device

Local Rahi's intended security model is one active device and one active authenticated session per account. When the same account successfully authenticates on a new device, the previous active session may be revoked and its account-specific push token deactivated. A request from a revoked session should be rejected and the previous device should be directed to authenticate again. This rule is a security control and does not itself delete data from the previous physical device.

17.4 Account States

Operational account states may include ACTIVE, BLOCKED, SUSPENDED and DELETED. A BLOCKED or SUSPENDED state may restrict some or all functions while preserving transaction records. DELETED refers to the completed account-deletion process and should not be used merely because a user logged out or uninstalled the application. Financial, fraud, safety and legal records may have separate retention lifecycles.

17.5 Terms and Privacy Acceptance

Local Rahi should record acceptance of material policies using a policy identifier/version and timestamp, together with appropriate session/device audit information. Optional marketing consent should be separate from acceptance required to provide the service. If a material policy change requires renewed acceptance, the application should present the updated document or a clear summary and obtain the required acceptance before affected functionality continues.

18. Detailed Find Pool Rules

18.1 Creating a Find Pool Request

A Find Pool request should contain the rider's genuine pickup, destination, applicable via point, date/time or recurring schedule, seat requirement and other fields needed for matching. The rider must not create fabricated requests to obtain personal information, test another user's movements, manipulate ratings, generate false transactions or otherwise misuse the platform.

18.2 Matching

Matching may use route compatibility, pickup/drop proximity, date, weekday, time tolerance, available seats and other relevant factors. A match is a suggestion, not a guarantee of acceptance, safety, punctuality or journey completion. Local Rahi may change matching logic over time to improve relevance, safety, cost control or performance.

18.3 Rider Request vs Car-Owner Invitation

A rider may request to join an offered pool, and a user offering a pool may invite a compatible rider. These are distinct initiation paths but both should converge into the same controlled booking/payment lifecycle after acceptance. The UI should clearly distinguish an incoming invitation from a request the rider previously sent so that actions such as Accept, Cancel, Withdraw or Remind are not misleading.

18.4 Rider Responsibilities

A rider should review the ride, pickup point, destination, date/time, available profile/vehicle information and final amount before committing. A rider must not pressure another user to deviate materially from the agreed journey, carry prohibited items, exceed confirmed seats, or accept an unauthorized off-platform arrangement designed to bypass Local Rahi controls.

19. Detailed Offer Pool Rules

19.1 Genuine Private Journey

The user offering a pool should publish only a journey they genuinely intend to make. The carpool feature is not intended to create an on-demand commercial passenger service. Local Rahi may use contribution limits, activity review, route patterns and other proportionate controls to identify activity reasonably inconsistent with private cost sharing.

19.2 Vehicle and Seat Information

The user offering a pool is responsible for materially accurate vehicle and seat information and for not knowingly exceeding lawful or safe seating capacity. Where Local Rahi later implements vehicle-document verification, that verification should be separately described and should not be inferred from Government ID or Corporate ID profile badges.

19.3 Private Carpool Declaration

Before publishing an Offer Pool, Local Rahi may require the user to confirm: 'I confirm that this is a genuine private journey and that I am offering available seats for eligible journey/fuel cost sharing, not for commercial profit.' The system may store the user ID, ride ID, declaration/policy version, acceptance time and appropriate security audit information.

19.4 Contribution Integrity

The user offering a pool must not alter client-side values, demand undisclosed extra amounts, condition pickup on an unauthorized payment, or ask the rider to cancel a platform booking solely to settle privately. Genuine incidental arrangements should not be used as a mechanism to turn cost sharing into profit.

20. Detailed Recurring Pool Rules

20.1 Series and Occurrences

A recurring preference should be treated as a series/template from which dated occurrences are generated or represented. Each dated occurrence should have independent availability, matching, booking, payment, attendance, cancellation, completion, refund and reimbursement consequences. This avoids treating a month of commuting as one inseparable transaction.

20.2 Recurring Offer Pool

A recurring Offer Pool may include weekdays, start date, end date, departure time, route, vehicle and available seats. Users should be able to understand which future occurrences exist and whether a change applies to one occurrence, this-and-future occurrences, or the entire series.

20.3 Recurring Find Pool

Find Pool should also support recurring preferences before publication/matching. A rider may specify weekdays, date range, time and seats. A recurring request does not guarantee that the same user or vehicle will match every occurrence.

20.4 Cancellation Scope

Where supported, cancellation controls should distinguish 'This ride only', 'This and future rides' and 'Entire series'. A cancellation action must not silently cancel unrelated paid occurrences. Any affected paid booking should enter the appropriate refund workflow independently.

20.5 No Commercial Inference Solely From Recurrence

Regular commuting or repeated private travel does not, by itself, establish prohibited commercial use. Local Rahi may nevertheless review the total pattern of activity where there are reasonable indicators of fabricated journeys, excessive contribution collection, unauthorized charges or operation resembling a commercial passenger service.

21. Booking State & State-Transition Policy

21.1 State Separation

Ride, booking, payment, attendance and reimbursement states represent different facts and should not be collapsed into one status. For example, ACCEPTED means a request/invitation has been accepted; SUCCESS means payment has been verified; JOINED means attendance was confirmed; COMPLETED means the relevant ride/booking lifecycle reached completion.

21.2 Booking Transitions

A typical booking can move REQUESTED -> ACCEPTED/PAYMENT_PENDING -> CONFIRMED -> COMPLETED, with cancellation paths where applicable. A backend state transition should validate the current state, authorized actor and relevant ride state before writing the next state. Client UI must not be treated as authority for financial transitions.

21.3 Idempotency

Payment verification, provider webhooks, refund requests and reimbursement callbacks may be delivered more than once. Local Rahi should use provider references and internal idempotency controls so repeated events do not create duplicate confirmations, refunds or reimbursements.

21.4 Audit Trail

Material transitions should retain enough audit information to reconstruct what happened: actor/system source, previous state, new state, timestamp, relevant provider reference and reason where appropriate. Audit records support reconciliation, disputes, security review and support.

22. Pricing Methodology & User Presentation

22.1 Backend Authority

Flutter or another client may display a quote, but Laravel/backend systems should calculate or confirm the authoritative amount using trusted ride data and configured rules. The client should submit the booking identifier rather than a user-controlled authoritative payable amount.

22.2 Final Total Payable

Before the rider authorizes payment, Local Rahi should display the final total payable prominently. Under the current product decision, internal Local Rahi/platform and payment-related components are not separately itemized to the rider. This presentation must remain subject to any disclosure requirements that applicable law ultimately requires.

22.3 Internal Allocation

Local Rahi may internally allocate a transaction among eligible carpool cost contribution, platform/service economics, payment-processing cost, taxes or other legitimate accounting categories. Internal allocation exists for settlement, reconciliation and accounting and does not mean every component is payable to the user offering the pool.

22.4 Price Changes

Once a booking has been paid, Local Rahi should not silently increase the amount due for that same confirmed booking. If a material change requires a new price, the user should be informed and, where appropriate, asked to authorize a new transaction or change.

22.5 Example

Illustrative internal example only: if the eligible car-owner reimbursement is ₹100 and Local Rahi's internal allocation includes ₹5 of platform economics and ₹2 of payment-related cost, the rider may be shown a final total of ₹107 while the eligible car-owner reimbursement remains ₹100. The exact production formula and legal/tax treatment must be configured and reviewed separately.

23. Payment Processing Rules

23.1 Checkout Creation

After an accepted booking reaches PAYMENT_PENDING, the authenticated rider may request payment creation. Laravel should validate booking ownership, ride availability, seat availability, current state, duplicate payment risk and the authoritative amount before creating a provider order/session.

23.2 Provider Verification

The application should never mark a payment successful solely because the client displays success. Backend verification should rely on the configured payment provider's authenticated response/webhook/status mechanism. Signature/authentication checks and idempotency should be applied according to the provider integration.

23.3 Pending and Failed Payments

A PENDING payment should remain unresolved until verified, expired, failed or reconciled. A FAILED payment should not confirm the booking. If a user reports a debit while Local Rahi shows failure/pending, support should reconcile the provider reference rather than create a manual success without evidence.

23.4 Payment Security

Local Rahi should not request or store card CVV, UPI PIN, ATM PIN, net-banking password or similar secret credentials. API secrets, auth keys and signing credentials must remain server-side and must not be embedded in Flutter or public repositories.

24. Cancellation Matrix - Detailed Scenarios

24.1 Rider Cancels Before Start

Where a successfully paid rider cancels before ride start, the refund result should follow the production cancellation rule disclosed before or at booking. Until a more granular matrix is finalized, Local Rahi should not publish unsupported penalty percentages or cutoff times. The app, backend and policy must use the same rule.

24.2 User Offering Pool Cancels

When the user offering the pool cancels an occurrence, each successfully paid affected rider booking should be identified and moved into the appropriate refund workflow. No cost-sharing reimbursement should be released for a cancelled occurrence.

24.3 Cancellation Before Payment

If a request/invitation is cancelled or withdrawn before successful payment, there is normally no payment to refund. Any provider order/session may be expired or ignored according to the integration, while preserving appropriate audit data.

24.4 Recurring Cancellation

Cancellation of a recurring occurrence must respect the scope selected by the user. Paid future occurrences affected by a broader cancellation should be processed independently so that refund/reconciliation records remain accurate.

24.5 Fraud/Dispute Hold

A legitimate fraud, chargeback, court, regulatory or payment-provider hold may delay final settlement. A hold should be tied to a reason and should not be used as a general mechanism to avoid valid refunds or reimbursements.

25. Attendance, Check-In & Pickup Rules

25.1 Attendance Is Separate

Payment CONFIRMED is not attendance JOINED. Attendance should begin PENDING and transition only when the relevant pickup/ride event supports JOINED or UNJOINED. This separation is essential because attendance controls reimbursement and some refund outcomes.

25.2 Rider Self Check-In

After the user offering the pool has validly arrived within the configured pickup condition, the rider may be permitted to self check-in. A successful self check-in may directly set JOINED without requiring a second confirmation from the user offering the pool.

25.3 Car-Owner Attendance Action

The user offering the pool may mark JOINED where the rider has actually joined but did not self check-in. UNJOINED should only be available after the platform's valid arrival/waiting conditions are met. The exact waiting duration remains a launch decision.

25.4 Immutable Normal Transition

Normal transitions should be PENDING -> JOINED or PENDING -> UNJOINED. Routine users should not toggle JOINED back to UNJOINED or vice versa after the financial consequence is established. Genuine corrections should use an auditable support/admin process.

25.5 Evidence

For an UNJOINED decision, Local Rahi may record ride/booking ID, actor, timestamp, pickup coordinates, actor coordinates, distance from pickup and other proportionate evidence. Such evidence should be protected and retained only as reasonably necessary under the Privacy Policy.

26. Ride Start, Live Location & Completion

26.1 Ride Start

The Start Ride action should be available only to the authorized user offering the pool and under configured timing/state conditions. On start, the ride may move to STARTED and active-ride location/notification functionality may begin.

26.2 Active-Ride Location

Live location should be used only to support legitimate active-ride purposes such as pickup progress, ETA and ride coordination. Access should be limited to appropriate participants/systems and should not become a general mechanism for tracking users outside the relevant ride.

26.3 Pickup ETA Notification

Local Rahi may send a one-time approaching-pickup notification when the estimated arrival is around the configured threshold, such as approximately five minutes. ETA is an estimate and should not be represented as exact.

26.4 Completion

When the ride is validly completed, each rider booking should be evaluated independently for payment, attendance, refund and reimbursement. Completion must not cause a reimbursement for a booking that is unpaid, UNJOINED, already reimbursed or legitimately held.

27. Refund Processing & Reconciliation

27.1 Refund Initiation

A refund is initiated only after Local Rahi successfully submits the refund instruction to the configured provider or otherwise records a verified provider-side refund initiation. User-facing status should distinguish requested/pending/processing/refunded where useful.

27.2 Bank Credit Time

The time between refund initiation and the user's bank/card/UPI credit may depend on the provider and financial network. Local Rahi should communicate provider-supported expectations but should not guarantee a precise credit time it does not control.

27.3 Duplicate Debit

Where evidence confirms a duplicate successful debit for the same intended booking, support should reconcile all provider references and arrange the appropriate duplicate refund. Duplicate payment detection should be automated where feasible.

27.4 Refund Failure

If a provider rejects or fails a refund, the refund should not be marked complete. Local Rahi should retry, reconcile or escalate according to provider capabilities while preserving the user's underlying claim.

27.5 Refund Audit

Refund records should link the original payment, booking, reason, amount, provider refund reference, status and timestamps. Manual adjustments should require authorized access and an audit reason.

28. Reimbursement Processing & Reconciliation

28.1 Eligibility Engine

At ride completion, the backend should evaluate each paid booking. SUCCESS payment + JOINED attendance + COMPLETED ride + no prior reimbursement + no legitimate hold should become ELIGIBLE. SUCCESS payment + UNJOINED attendance should not become eligible for car-owner reimbursement.

28.2 Immediate Initiation

For an eligible booking, Local Rahi's intended policy is to initiate the cost-sharing reimbursement promptly after completion rather than impose an arbitrary one-day waiting period. Provider/bank processing time may still delay actual credit.

28.3 Beneficiary Information

Where the provider requires bank/UPI beneficiary details or verification, Local Rahi may collect the minimum required payout profile and reuse it for later eligible reimbursements subject to user updates, provider requirements and security controls.

28.4 Failed Transfer

A failed transfer must remain FAILED or pending retry; it must never be marked PAID merely because Local Rahi attempted it. The user may be asked to correct bank/UPI details where failure indicates invalid destination information.

28.5 Reconciliation

Local Rahi should periodically reconcile internal reimbursement records against provider transfer status to identify stale PROCESSING transactions, duplicate attempts, reversals and unmatched provider events.

29. Payment Disputes, Chargebacks & Reversals

29.1 Chargeback

A card/payment chargeback or provider dispute can occur after a booking appears paid. Local Rahi may preserve records and investigate the related ride, attendance, refund and reimbursement before determining internal treatment.

29.2 Reversal

If a provider reverses or invalidates a payment, Local Rahi should not treat the original SUCCESS state as permanently authoritative without reconciliation. Related financial records should preserve the history rather than simply overwriting it.

29.3 Reimbursement Already Paid

Where a reimbursement was legitimately paid before a later payment reversal/chargeback, Local Rahi should follow applicable provider, contractual and legal processes. The policy should not authorize arbitrary recovery methods or access to unrelated user funds.

29.4 Evidence and Cooperation

Users may be asked for non-secret supporting information. Local Rahi may provide transaction/ride records to payment providers or lawful authorities where reasonably necessary and permitted.

30. Safety Incident & Accident Response

30.1 Immediate Emergency

In an accident, medical emergency, violence or immediate threat, users should contact emergency services, police, medical providers or other appropriate authorities first. Local Rahi support is not an emergency dispatch service.

30.2 Platform Report

After immediate safety needs are addressed, a user may report the incident to Local Rahi with the relevant ride/booking reference and factual description. Local Rahi may preserve platform records and restrict an account where reasonably necessary for safety/security.

30.3 Insurance and Claims

Vehicle owners/users remain responsible for applicable insurance arrangements and for contacting insurers where appropriate. Local Rahi does not promise to pay an insurance claim or compensate accident losses unless a specific separately described program expressly provides that benefit.

30.4 Evidence Preservation

Local Rahi may preserve ride times, route/location audit, booking state, communications metadata and other relevant records where reasonably necessary for a serious incident, subject to privacy and lawful-request requirements.

31. Community Conduct & Harassment Enforcement

31.1 Respect

Users must communicate and travel respectfully. Harassment, sexual harassment, threats, intimidation, stalking, violence, discriminatory abuse and repeated unwanted contact are prohibited.

31.2 Communication Boundaries

Ride-related contact information and messaging must be used for legitimate coordination. A user must not continue contacting another participant for unrelated purposes after being asked to stop, except where communication is reasonably necessary for an unresolved ride/payment/lost-item issue.

31.3 Enforcement

Local Rahi may warn, restrict communication, block matching, suspend or terminate an account depending on severity, repetition and available evidence. Serious safety allegations may justify temporary restriction while investigated.

31.4 Retaliation

Retaliatory ratings, threats, harassment or false reports made because another user raised a legitimate safety or payment concern are prohibited.

32. Ratings, Reviews & Reputation

32.1 Genuine Experience

A rating/review should be based on a genuine Local Rahi interaction. Users must not buy, trade, fabricate or coordinate reviews to manipulate reputation.

32.2 Content Standards

Reviews must not contain threats, unlawful hate/harassment, unrelated advertising, payment secrets, full identity-document numbers or unnecessary sensitive personal information. Local Rahi may moderate content that violates policy.

32.3 Removal and Correction

Local Rahi may remove or restrict reviews that are demonstrably fake, abusive, privacy-invasive or unrelated. A poor but genuine opinion should not be removed merely because a user dislikes it.

32.4 Badge and Rating Separation

Ratings reflect user feedback; verification badges reflect a particular verification process. Neither should be presented as a guarantee of future safety or conduct.

38. Vehicle & Driving Responsibility Rules

38.1 User Responsibility

The user offering the pool remains responsible for legal permission to drive/use the vehicle and for required registration, insurance, roadworthiness and other applicable documentation. Local Rahi should not imply it has verified a document unless it actually did.

38.2 Vehicle Accuracy

Vehicle make/model/colour/registration display information used to identify the pickup vehicle should be materially accurate. Misleading substitution may be reported and can justify cancellation or enforcement.

38.3 Safe Capacity

Confirmed riders plus other occupants must not knowingly exceed lawful or safe capacity. Local Rahi seat settings should not encourage capacity beyond the vehicle's permitted configuration.

38.4 Unsafe Driving Reports

Reports of reckless, impaired or dangerous driving may be treated as serious safety matters. Local Rahi may temporarily restrict an account while reviewing credible evidence.

39. Fraud, Abuse & Cost-Sharing Integrity

39.1 Prohibited Manipulation

Fake rides, fabricated bookings, collusive attendance, payment/refund manipulation, multiple-account abuse, false location events and contribution circumvention are prohibited.

39.2 Commercial Misuse Signals

Potential indicators may include patterns of fabricated journeys, repeated unauthorized extra charges, activity designed primarily to collect money rather than share a genuine journey, or attempts to operate the private carpool feature as an on-demand passenger business. A single factor should not automatically prove misconduct without reasonable review.

39.3 Controls

Local Rahi may use rate limits, contribution ceilings/formulas, device/session controls, provider reconciliation, anomaly detection and manual review to protect users and platform integrity.

39.4 Fair Enforcement

Fraud controls should be proportionate and should not be described as infallible. Legitimate users should have a practical way to report an incorrect restriction.

40. Suspension, Termination & Review Procedure

40.1 Progressive Action

For lower-severity issues, Local Rahi may use education, warning or temporary feature restriction. Repeated or serious violations may lead to suspension or termination.

40.2 Immediate Restriction

Credible threats of violence, serious fraud, account compromise, dangerous conduct or a lawful requirement may justify immediate temporary restriction before a full review.

40.3 Notice

Where appropriate and lawful, Local Rahi should tell the user that access has been restricted and provide a general reason category. Detailed security/fraud methods need not be disclosed where doing so would undermine controls or another person's safety/privacy.

40.4 Review Channel

A user should be able to contact Local Rahi support/grievance channel to request review of an account action. The final operational response target remains to be configured and should not be promised until support capacity and applicable legal requirements are confirmed.

40.5 Financial Separation

Termination does not automatically confiscate a legitimate reimbursement or cancel a legitimate refund. Financial treatment should follow the underlying transaction unless that transaction is itself legitimately held or disputed.

41. Grievance Handling Workflow

41.1 Intake

A grievance should receive a case/reference identifier where practical. Intake should capture category, user/account reference, ride/booking/payment reference, description, evidence and urgency.

41.2 Triage

Safety threats, account compromise and active payment problems may require priority handling. Routine product feedback can follow a normal support queue. Emergency situations must be redirected to appropriate emergency authorities rather than treated as ordinary support.

41.3 Investigation

Support may review relevant logs, booking states, payment-provider data, attendance evidence, messages where appropriately available, verification status and prior reports. Access should be limited to staff with a legitimate need.

41.4 Decision and Record

A resolution should record the outcome and any refund, reimbursement, account correction or enforcement action. Where a user-facing response is appropriate, it should explain the result without disclosing another user's unnecessary personal information.

43. Third-Party Provider Governance

43.1 Payment Provider

Cashfree is the current planned payment provider, subject to production activation and approved functionality. Local Rahi should maintain a provider abstraction so business rules do not depend on Cashfree-specific field names.

43.2 OTP Provider

MSG91 is the current planned OTP provider. Provider credentials must remain server-side. Local Rahi should verify the provider's access/verification result server-side before issuing a Local Rahi authenticated session.

43.3 Maps

Google Maps Platform may provide route, distance, ETA, place and map functionality. API keys should be restricted appropriately and map-derived estimates should not be represented as guarantees.

43.4 Notifications

Firebase Cloud Messaging may deliver ride/account notifications. Push delivery is not guaranteed and should not be the sole mechanism for recording a legally/financially material state transition.

43.5 Provider Changes

If Local Rahi changes a provider or introduces a materially new processor, it should update contracts, security configuration, privacy disclosures and app-store declarations as applicable.

45. Notifications & User Communications

45.1 Transactional Notifications

Notifications may cover OTP/account security, requests/invitations, acceptance, payment status, ride start, approaching pickup, attendance, cancellation, refund, reimbursement and support events.

45.2 Source of Truth

Push notifications are informational. The authoritative status should remain in backend records because a push may be delayed, suppressed or never delivered.

45.3 Marketing

Promotional/marketing communication, if introduced, should use a consent/opt-out framework separate from essential transactional messages where required.

45.4 Sensitive Content

Push notifications should avoid exposing unnecessary sensitive personal, payment or precise-location information on a locked device screen.

46. Admin, Support & Manual Intervention Rules

46.1 Controlled Access

Admin/support tools should expose only information necessary for the staff member's role. High-risk actions such as manual financial state changes should require stronger authorization and audit logging.

46.2 No Silent Financial Editing

Support should not simply change SUCCESS/REFUNDED/PAID statuses to make a complaint disappear. Provider reconciliation or a documented authorized adjustment should support the change.

46.3 Attendance Correction

A genuine attendance error may be corrected through an admin/support workflow that records the original state, corrected state, reason, evidence, operator and timestamp.

46.4 User Reports

Reports should be associated with the relevant ride/user and should not automatically establish guilt. Serious credible safety reports may justify interim restriction while facts are reviewed.

47. Recordkeeping, Audit & Reconciliation

47.1 Financial Ledger Linkage

Payment, refund and reimbursement records should be linked to the ride booking and provider references so the full financial lifecycle can be reconstructed.

47.2 Daily/Periodic Reconciliation

Local Rahi should reconcile internal SUCCESS/REFUNDED/PAID records with provider reports/status on a periodic basis, with special attention to stale PENDING/PROCESSING states.

47.3 Policy Acceptance Audit

Material declarations and policy acceptances should record policy version and timestamp so Local Rahi can establish which wording applied to a transaction.

47.4 Immutable History

Where practical, state changes should preserve history rather than destructively overwriting the only evidence of the previous state.

48. User-Facing Scenario Rules

48.1 Rider Paid; Car Owner Cancels

The ride occurrence is cancelled, no cost-sharing reimbursement is released, and each successfully paid affected rider enters the applicable refund workflow. The user-facing app should show cancellation and refund status separately.

48.2 Rider Paid; Rider Cancels Before Start

Apply the disclosed production cancellation/refund rule. If the baseline is full refund, the backend initiates it and records provider status. If Local Rahi later introduces cutoffs/fees, the rule must be disclosed before it is enforced.

48.3 Rider Paid; JOINED; Ride Completed

Payment remains successful, attendance is JOINED, ride is COMPLETED, and the eligible cost-sharing reimbursement may move ON_HOLD -> ELIGIBLE -> PROCESSING -> PAID subject to provider result and legitimate holds.

48.4 Rider Paid; Valid UNJOINED

No car-owner reimbursement is released for that rider. The rider enters the applicable refund/dispute path under the final attendance/refund rule. Location/timestamp evidence may be reviewed if disputed.

48.5 Reimbursement Fails

The record remains FAILED/pending retry. Local Rahi may retry or ask the user to correct payout details. It must not be marked PAID until provider confirmation supports that state.

48.6 Account Terminated With Legitimate Reimbursement Pending

Termination alone does not confiscate the legitimate reimbursement. Process it according to the underlying eligible transaction unless that transaction is legitimately held for fraud, chargeback, legal, compliance or dispute reasons.

49. Public Disclosure & App-Screen Mapping

49.1 Registration Screen

Link Terms & Conditions and Privacy Policy. Clearly separate required acceptance from optional marketing consent. Do not imply OTP equals Government ID verification.

49.2 Offer Pool Screen

Show the private-carjourney/cost-sharing declaration before publish. Explain that unauthorized profit-making/commercial use is prohibited.

49.3 Payment Screen

50. Policy Decision Register

50.1 Minimum Age

Owner: Product/Legal. Status: CLOSED. Local Rahi is for users aged 18 or older. A user offering a pool must hold a valid driving licence applicable to the vehicle. The registration acceptance, Terms, safety guidance and app-store audience settings must remain consistent with this rule; date of birth is not mandatory during basic registration solely to enforce the contractual confirmation.

50.2 Pickup Waiting Period

Owner: Product/Safety. Status: OPEN. Decide the minimum arrival/wait condition before UNJOINED becomes available. Align backend geofence/timer logic, UI and refund policy.

50.3 Cancellation Matrix

Owner: Product/Finance/Legal. Status: OPEN. Decide rider cancellation cutoffs and refund treatment, including any legally required treatment of internal charges. Do not publish percentages until finalized.

50.4 Dispute Window

Owner: Support/Legal. Status: OPEN. Decide the recommended reporting window while preserving non-waivable rights. Configure support workflow and user-facing help.

50.5 Verification Retention

Owner: Privacy/Security. Status: OPEN. Confirm verification provider, accepted documents and whether Local Rahi stores document images or only verification results. Set retention accordingly.

50.6 Suspension Review Target

Owner: Support/Safety. Status: OPEN. Establish a review/appeal channel and realistic response target consistent with applicable requirements.

50.7 Payment/Reimbursement Production Approval

Owner: Finance/Engineering. Status: OPEN until production provider approval. Confirm actual provider architecture and beneficiary/KYC requirements before promising reimbursement availability.

51. Launch Compliance & Consistency Checklist

51.1 Product/Policy Consistency

Every material policy statement must match actual production behavior. Particular attention is required for final total payable, refunds, reimbursement timing, attendance, optional verification, direct calling and one-device enforcement.

51.2 Website

Publish accessible HTML policy pages and link them from the footer. Keep the account-deletion resource publicly reachable. The website should accurately state that booking/payment is currently primarily through the mobile app until website transactions launch.

51.3 Google Play

Ensure Privacy Policy URL, account-deletion resource, Data Safety declarations, location permissions/prominent disclosure and app behavior are consistent. Do not declare data collection/sharing based on planned features that are not actually in the release, and do not omit SDK behavior that is present.

51.4 Payment Provider

Production onboarding descriptions, app URL, policies, support information and transaction flow must match the real Local Rahi service. Do not use a fake Play Store URL or describe the private carpool feature as something materially different merely to pass onboarding.

51.5 Operational Readiness

Before public launch, test payment success/failure/pending, duplicate webhook, rider cancellation, car-owner cancellation, refund failure, JOINED/UNJOINED, reimbursement success/failure, recurring occurrence cancellation, account suspension, deletion request and dispute evidence.

52. Master Policy Governance

52.1 Ownership

Local Rahi should assign internal owners for Terms, Privacy, Payments, Safety and Grievance procedures. Engineering changes that materially affect data, money, permissions, verification or user rights should trigger policy review.

52.2 Versioning

Each public policy should have an effective/last-updated date and an internal version identifier. Material acceptance should be linked to the version in force when required.

52.3 Review Cadence

Policies should be reviewed before major launches and periodically thereafter, especially when payment providers, verification providers, permissions, website functionality, state/regulatory requirements or monetization change.

52.4 Legal Review

This master document is a product/policy drafting source and should receive qualified Indian legal/compliance review before publication as final legal terms. Legal review is particularly important for transport/aggregator classification, pricing disclosure, tax/accounting treatment, payment/payout structure, insurance, privacy retention and age eligibility.

53. Status Definitions - Engineering & Policy Reference

Ride: PUBLISHED

Ride occurrence is available/published subject to matching and booking rules.

Ride: STARTED

Authorized user has started the ride; active-ride functionality may operate.

Ride: COMPLETED

Ride occurrence has been validly completed.

Ride: CANCELLED

Ride occurrence has been cancelled; affected paid bookings require financial evaluation.

Booking: REQUESTED

Request/invitation exists but has not reached paid confirmation.

Booking: ACCEPTED / PAYMENT_PENDING

Request/invitation accepted; payment still required or being resolved.

Booking: CONFIRMED

Required payment has been verified successful.

Payment: PENDING / SUCCESS / FAILED

Provider-backed payment lifecycle states.

Payment: REFUND_PENDING / REFUND_PROCESSING / REFUNDED

Refund lifecycle states.

Attendance: PENDING / JOINED / UNJOINED

Independent attendance states.

Reimbursement: ON_HOLD / ELIGIBLE / PROCESSING / PAID / FAILED / CANCELLED

Cost-sharing reimbursement lifecycle.

54. Final Publication Note

This v4 expanded master is intentionally more detailed than the public pages need to be. It is designed as the controlling drafting source for website policies, app disclosures, support procedures and engineering state rules. Before publication, remove or resolve every item explicitly marked OPEN, Launch Decision Required, Operational Decision or Legal/Operational Confirmation Required. Do not turn an unresolved assumption into a user-facing promise.

The central Local Rahi rule remains: the carpool feature is intended for genuine private journeys and sharing eligible journey/fuel costs, not commercial passenger-transport profit. That product positioning must be supported by actual pricing controls, user declarations, transaction design, monitoring and enforcement rather than policy wording alone.