Urban rental operations management system
Rental staff run daily operations — from issuing equipment to closing a shift — in one system.
Project
The system is built around a physical operation: inventory continuously changes state, and management needs one clear view of what is happening on site.
- Context
- An anonymized account of equipment rental across several service points in a city park, without naming the operator or the specific location.
- Business problem
- Bring rental activities into one workflow without slowing down service on site.
Chosen solution boundary
A focused operations interface that brings asset state, staff actions, and management context into one system.
Contribution
From problem boundary to production
- 01 On-site process discovery
- 02 Roles and workflow design
- 03 Custom system development
- 04 Foundation for integrations and growth
Business problem and context
Problem
- A single order can include several pieces of equipment and merchandise at once.
- Payment and fiscal receipt are separate operations that do not always complete at the same moment.
- A remote terminal result is not always known immediately and can stay unresolved.
- Equipment moves through issuance, replacement, repair, and battery maintenance, and that state has to be visible at the moment of serving a customer.
Users and context
- On-site staff scan equipment by QR code, create rentals and merchandise sales, take payment, and process returns or extensions.
- A location administrator manages staff, prices, and equipment, and closes shifts at their location.
- A root-level administrator sees all locations, users, and the overall operational and financial picture.
Solution
- QR verification with protection against double-issuing an already active rental.
- Order management creation, extension, editing, cancellation, and in-order equipment replacement.
- Payment and refunds through an external payment provider, with operation status tracked separately and an attention queue for unresolved results.
- Maintenance tracking repair and battery-charge tracking.
- Daily jobs closing shifts, resetting battery state, and exporting reports — protected against duplicate runs.
How it works
- Verification & order creation
Staff scan the equipment QR code and create an order with one or more equipment items and optional merchandise.
- Payment
A payment operation is created with an external payment provider; the result may arrive immediately or through a delayed status update.
- Unresolved result
If the payment status is not confirmed right away, the operation goes into an attention queue instead of being treated as automatically successful or failed.
- Service
An active order can be extended, edited, or completed, and equipment can be replaced if needed.
- Daily close
Daily background jobs close shifts, update battery state, and export reports exactly once per day.
Product surfaces
Architecture and reliability
A web application serves the rental points and connects to an external payment provider and a database; a separate scheduler process closes shifts, updates battery state, and exports reports once a day.
- Web application for rental points
- External payment provider
- Daily background-job scheduler
Reliability and security
- Access roles are scoped to a specific location; the root level sees all locations.
- Equipment maintenance and repair history is preserved as part of its lifecycle.
- Daily jobs do not stop entirely because one of them fails.
- A refund is full and single-use per operation: the system will not allow refunding more than was originally received.
Engineering decisions
An unresolved result moves the operation into a separate attention queue instead of being treated as an automatic success or failure.
Challenge The result of a remote payment operation is not always known immediately.
Why it matters A network error does not serve a customer without confirmed payment and does not block the location without reason.
A refund is calculated from the original operation and the amount already refunded, not as an independent action.
Challenge A refund has to account for what was already refunded earlier on the same order.
Why it matters A repeated refund cannot double the amount paid to a customer.
Each job is protected by a process-level lock and a unique record of that day's run.
Challenge Daily jobs must run exactly once per day even after a service restart.
Why it matters Shifts are not closed twice and reports are not duplicated after a restart.
A fallback issuance flow exists for situations when the main payment path is unavailable.
Challenge A payment terminal or provider can be temporarily unavailable, and a rental point should not stop serving customers because of it.
Why it matters An external service outage does not block service at the rental point.
A new sale on a device is blocked while an operation on that device is still in progress.
Challenge The same payment terminal should not start a new sale while a previous operation on it is still processing.
Why it matters Two payments on the same terminal cannot overlap or confuse the cash totals.
Technologies
- Python
- Flask
- PostgreSQL
- APScheduler
- Gunicorn