Waslni is not an inDrive clone, but it does support fixed and bidding service modes. In bidding mode the rider can adjust the fare, eligible drivers can submit a bounded price offer, and the rider can accept or reject it from the same role-aware app.
inDrive is commonly associated with a fare-proposal model in which riders and drivers can participate in agreeing the price. Treat that as product inspiration, not evidence that the same behaviour is available in every market or platform.
A negotiated-fare flow affects pricing, offers, assignment, receipts, reporting, disputes, and local compliance. Buyers should document the exact journey and ask the vendor to demonstrate or scope every state instead of assuming a generic “negotiated mode” behaves like inDrive.
Waslni implements fixed and bidding pricing modes. In bidding mode the rider can adjust the proposed fare within server-defined limits, drivers can submit bounded offers, and riders can accept or reject them. Exact copy, payment, and accounting behaviour still needs tenant testing; the platform does not claim identical inDrive behaviour.
A bidding service shows an adjustable fare instead of locking the quoted amount. The rider’s submitted price is stored with the order and remains bounded by the configured service rules.
For eligible bidding work, the driver can take the customer price or submit another allowed amount. The rider then accepts or rejects the specific driver offer; pending offers can also expire.
The service configuration determines fixed or bidding mode and the allowed rider and driver movement around the fare anchor. Server validation rejects offers outside those limits.
Authorised staff can reach quick permissioned controls inside the mobile app, while the full web panel handles configuration and wider operational oversight.
Configure supported commission rules for the service, then document driver communication, accounting, and any settlement process separately.
Cash or wallet flows can accompany bidding when configured. If a card trip has already captured the full fare, the backend requires the driver offer to match that locked customer price.
Apply the brand, select the initial App Experience, and document the exact pricing journey that needs to be demonstrated or scoped.
Configure service areas, supported commission rules, service types, and the dynamic driver-registration requirements.
Connect a supported provider after merchant approval, compose registration fields, and test the pricing and payment flows selected by the operator.
Complete store submission and operational testing, then open the service to a limited audience before expanding.
No. inDrive is a market reference, not a behaviour specification. Waslni provides one role-aware rider-and-driver app, quick permissioned administration inside it, a full web panel, and configurable operating settings under your brand.
Yes, by assigning fixed or bidding pricing mode to the relevant service configuration. Test each service and payment method: a fully prepaid card ride keeps its captured price locked even when the service normally allows bidding.
Commission settings depend on the supported service configuration and your commercial policy. Avoid copying another company’s percentage; model a rate that fits driver economics, customer pricing, tax, and local obligations.
The backend returns the fare and bidding bounds for the selected service, and the rider interface lets the customer adjust within those limits before confirming. The exact labels and range should be reviewed in the configured tenant.
When cash is enabled, the operator defines collection, recording, commission, reconciliation, and exception procedures. Waslni does not promise a particular shift or weekly settlement schedule.
The fixed-fare side of ride-hailing.
Operations and configurable fare settings.
The local Saudi and Jordan style ride-hailing angle.
The architecture behind every pricing mode.
Bring your required offer, acceptance, pricing, and cash scenarios to a live product and scope review.