Waslni is not an inDrive clone and does not promise identical bidding behaviour. It is a configurable white-label platform with one mobile app for rider and driver modes, permission-aware quick admin inside the app, and a full web dashboard. App Experience can run rides, delivery and shops, or both.
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 supports configurable service types, fares, commissions, and operating rules from the admin tools. Any negotiated-fare requirement must be confirmed against the current tenant configuration; the platform does not claim identical inDrive bidding behaviour or a guaranteed launch date.
Document whether the rider sees a fixed estimate, enters a proposal, receives a permitted range, or follows another scoped flow. Waslni uses the same branded app for rider and driver roles.
Specify which trip details are visible and whether the driver may accept, decline, or make another permitted response. Any counter-offer behaviour must be confirmed in the implementation scope.
Waslni supports configurable service types, fares, and operating settings. A negotiated or hybrid mode is not assumed; ask for a live demonstration and written confirmation.
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.
Enable cash or the optional wallet, and connect a supported card or wallet provider after the operator’s merchant account is approved.
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.
Do not assume this from the page title. Define the required offer and acceptance states, then ask for a current demonstration and written technical scope. Standard supported fare settings can be configured from the administration tools.
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.
That depends on the scoped product flow. A suggested range, manual proposal, or counter-offer mechanism should be treated as a specific requirement and verified before it appears in a launch plan.
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.