Privacy policy

This section is about us. It covers the people who OPERATE a rental business on this platform, not the customers who rent from them.

Staff accounts

Name, phone number and role for each person the company owner gives access to. The sign-in PIN is never stored: what is kept is a SHA-256 hash salted with that staff member own account id, so the same PIN chosen by two people produces two different hashes and a stolen table cannot be reversed with a precomputed list.Created by the company owner. Staff never register themselves.

Paired devices

One record per phone a staff member signs in on: a device label, when it was paired, when it was last seen, and the hash of that device current refresh token. The token itself is returned once and never stored.

Enquiries to us

If you write to us about buying or supporting the product, we keep what you sent and our reply for as long as we are dealing with you and a reasonable period afterwards. This website collects nothing on its own: it has no form, no newsletter and no sign-up, and its content policy forbids a browser from submitting one.

Technical error reports

When something fails, the software records a fault code, which screen it happened on, the software version, and the company it happened for where that is known. Repeats of the same fault increment a counter on one row rather than writing a new one. Every payload passes an allowlist filter before storage that strips phone numbers, names, identity-document values, tokens, PINs and file addresses.No customer record has ever been part of an error report by design.

This section describes information the rental company controls and RentnRide stores on its behalf. Everything listed is scoped to that one company: a company can only ever read rows carrying its own identifier, and that identifier is derived by the server from the address the request arrived on, never from anything the sender supplies.

Name and phone number

The renter name and mobile number, held once per company. This is the identity a booking is attached to; there is no customer account and no customer password anywhere in this product.

Identity and driving-licence numbers

The number itself is NEVER stored. What is stored is an HMAC-SHA256 fingerprint of it, computed with a secret key held only by the server, which lets the company recognise a returning customer and check its own barred list without ever holding the number. The number cannot be recovered from the fingerprint, including by us.

Photographs of an identity document

Stored as a file whose name begins with the company own identifier, and DELETED when the booking is closed at the return handover — the file and the pointer to it both. The single exception is a rider the company has barred, whose document is kept because it is the evidence for the bar.The deletion runs at the moment of return, not on a later sweep.

Handover records

For each give-out and take-back: the rider name and phone, an optional driver name and phone, the odometer reading, the fuel level, the accessories checked off, and any damage note. Rider identity is recorded here rather than on the booking because the person who rides away is not always the person who booked.

Condition and damage photographs

Files under the company own identifier, capped in size and in number per booking. Each handover is stamped, at the moment the photographs are taken, with the date they become due for deletion — the company own window, sixty days unless it sets another.

Bookings and the payment ledger

The vehicle, the period, the agreed figures, and one row per payment leg: what kind it was, how it was taken (cash, bKash, Nagad or card), an optional reference the staff member typed, the amount, and who recorded it when. Amounts are whole paisa, never a decimal.RentnRide takes no payment and holds no card number. A leg is a written record of money that changed hands elsewhere.

Enquiries from a company public page

The phone number and message a visitor types, the vehicle they were looking at, and a SHA-256 hash of their network address. The address itself is never written down; the hash exists only so an abusive flood can be capped, and it is salted per company so the same visitor is not linkable across two companies.

The audit log

Which staff account performed which action on which record, and when. The actor is taken from the signed session token, never from the request body, so it cannot be forged by the client. These rows are not deleted.

A rental company can put a QR sticker on a vehicle that opens a page on that company own web address WITHOUT a login. It exists for a roadside check: an officer scans the sticker and sees whether the vehicle papers are in order. A page reachable without a password has to be described in a privacy policy, so here is exactly what it shows.

It shows the vehicle description and registration number; whether the registration, tax token and insurance documents are on file; and for each one the date it is valid until, or that it has passed that date. If the vehicle is currently out on rent it also shows the rider FIRST NAME and the time the vehicle is due back.

It does NOT show a phone number, a full name, an identity or licence number, the fingerprint of one, an address, the booking, or the amounts. Where a company has published a media address, the three VEHICLE documents can be opened from that page behind a deliberate tap; those are the vehicle papers, not a person documents. The page asks search engines not to index it, and a vehicle belonging to another company returns nothing.

The rider first name and the due time are personal information, shown deliberately and narrowly: they are what makes the page answer the question a checkpoint is actually asking. A company that does not want that published should not put the sticker on the vehicle.

Different information has different clocks, and this policy names no statute for any of them. The obligation to keep business records belongs to the rental company under its own registration, not to us, and the right period depends on that registration — so the company sets it and we hold ourselves to what the software actually does.

Bookings, payments, deposits and refunds

Kept for as long as the rental company must keep its business records under Bangladeshi tax law. The company sets that period; where it has not, we treat it as six years. Financial records are excluded from a deletion request until that period ends — a company cannot erase its way out of its own bookkeeping, and neither can we on its behalf.

Identity document photographs

Deleted at the return handover that closes the booking, unless the rider is on the company barred list.

Condition and damage photographs

Due for deletion after the company dispute window, sixty days by default, and the due date is written onto the record when the photographs are taken so that shortening the window later cannot retroactively destroy evidence in an open dispute.Stated plainly: the scheduled job that acts on that due date is NOT yet running. Until it ships, a photograph past its date is removed when the company asks. We would rather write this sentence than imply an automatic deletion that does not happen.

The audit log

Not deleted. It is the record of who did what, and a record that can be erased by the person it describes is not a record. It is excluded from erasure requests for that reason.

Technical error reports

Held as one row per distinct fault with a count, not one row per occurrence, and containing no personal information by construction.

Three, and only three. Each is named because the product genuinely could not do its job without it, and each is a different kind of exposure.

Meta Platforms — WhatsApp

This product does not send text messages. Every customer enquiry and every reminder leaves as a WhatsApp link, so when a visitor or a staff member taps one, the phone number and the message text are handed to WhatsApp and handled under Meta own terms from that moment. This is the main channel between a rental company and its customers, and it is not optional to how the product works.

Telegram

Owner alerts and the nightly business summary are delivered over Telegram, each company to its own chat. Those messages carry counts and figures — how many vehicles are out, what is overdue — not customer records. Fault alerts about the software go to a separate operator chat and carry no customer information at all.

Cloudflare

The whole platform runs on Cloudflare: the servers that answer requests, the database the records sit in, the storage the photographs sit in, and the network in front of all of it.

There is no advertising network, no marketing platform and no analytics vendor in this product, on any surface. Renter information is never sold, never shared for advertising, and never handed to a data broker.

On Cloudflare infrastructure, which means the database and the stored files are NOT located in Bangladesh. Information about a Bangladeshi renter therefore leaves the country in the ordinary course of using this service.

This is stated plainly rather than buried because a cross-border transfer that a policy does not mention is exactly the one a regulator asks about later. A rental company that cannot accept it should not put its customers on this platform, and should tell us so before it does.

The Personal Data Protection Act 2023 gives a data subject in Bangladesh the following rights. They apply to a renter, to a staff member, and to a company owner alike — what changes is who answers.

• Access — a copy of what is held about you, and why (section 14).
• Correction — anything inaccurate or incomplete put right (section 15).
• Deletion — erasure of what is held, subject to the record-keeping periods described in section 5 above (section 16).
• Portability — what you gave, handed back in a form another system can read (section 17).
• Objection — the right to object to a particular use of your information (section 18).

A RENTER sends the request to the rental company they booked from — the controller. If that company needs us to act, we act for it, and we will help any company that asks us how. A STAFF MEMBER or a company owner asking about a platform account sends it to us directly.

We answer a request within thirty days. If we must refuse part of one — a financial record inside its retention period, an audit entry — we say which part and why rather than declining the whole request.

Section 22 of the Act requires notification of a personal data breach within seventy-two hours. If a breach affects a rental company data we notify that company without undue delay and in any case within seventy-two hours of becoming aware of it, with what we know, what we do not yet know, and what we are doing about it.

The rental company, as the controller, then notifies its own customers and the authority. We support that notification and will not delay it to finish an investigation first.

The two dates at the top of this page are the record. The effective date moves only when what a rental company agreed to actually changes; the updated date moves whenever the substance of the text does. A change that affects rental companies is notified to them through the console before it takes effect.