Sales Igniter’s Magento 2 rental extension is built from what rental businesses actually ask for. Nearly every feature below started as a customer request. This page is the public record: what has shipped, what customers are asking for now, what we are weighing up, and a form to add yours.
It covers the Magento 2 and Adobe Commerce rental booking extension. Running WordPress instead? The WooCommerce rental plugin has its own feature request page, on its own release cycle.
- Requested
- Under consideration
- Planned
- Shipped
Requests we have already built
Every item here is in a shipped release of the Magento 2 rental extension or one of its add-ons. Versions and dates come from the Magento 2 release notes. Open a card to read what the feature does.
Drive the rental system from your own software, or a headless storefront
Magento has had a GraphQL API for years, and none of it knew what a rental was. You could ask it for a product, its price and its stock level — but…
Read moreShow less
Magento has had a GraphQL API for years, and none of it knew what a rental was. You could ask it for a product, its price and its stock level — but a rental product has no single price, and "in stock" is meaningless without dates. So anyone building a headless storefront, a warehouse app or an integration with their own systems hit the same wall: the questions that actually matter to a hire business could not be asked.
There was no way to ask what a product costs for a particular set of dates, or whether it is even free on them. No way to paint a date picker without a request per day. And no way to take a booking at all, because Magento's own
addProductsToCarthas nowhere to put a start and end date — a rental line added through it arrives with no dates, prices at nothing, and fails at checkout. The back office was not much better served: two REST endpoints for sending and returning serials, and nothing else.Shipped in 1.2.198. The rental extension now adds its own GraphQL to Magento's existing
/graphqlendpoint. There is nothing to install or switch on.For a storefront
- Availability for real dates — whether a quantity can be booked over a range, how many units are free at the busiest moment inside it, and when the answer is no, a reason you can show a customer: booked out, shorter than the minimum hire, a closed day, past the maximum period.
- A whole calendar in one request — every day in a window with its free quantity, the fully booked days, the days the product cannot go out on at all, and the next available date. A month-long picker is one round trip, not thirty.
- Pricing for a date range, including date-based specials and surge periods, with the working shown — which tier or named pricing period produced each part of the total, so you can tell a customer why it costs what it does.
- Booking — a rental add-to-cart that carries the dates, re-checks availability before the line goes in, and reports per-line errors so one sold-out item does not lose the rest of the basket.
- Rental details on the product itself, so a picker knows whether to collect a time, what the minimum and maximum hire are, the turnover buffers and the price tiers — without a second query.
For a back office
- Orders by rental date, not order date — what is going out this morning, what is due back, what is out over a weekend, and what is overdue. Magento can only find orders by when they were placed, which is rarely the question a hire business is asking.
- Bookings — list, create, move, resize, cancel part of one, or delete. Turnover time is applied for you, and editing a booking no longer has it block itself.
- Serial numbers — the whole fleet, filtered and paged, with add, edit, delete and a bulk add for a delivery that either writes every unit or none of them.
- Sending and returning — the same actions as the Send and Return screens, so a scanner app and a member of staff cannot get out of step.
- Maintenance tickets — open, change and close them, with the same effect on the fleet the admin has: a unit in the workshop stops being bookable, and becomes bookable again when the ticket closes. This part needs the Maintenance extension at 1.2.48 or later.
Nothing new had to be invented for permissions. The back-office fields authorise against the same admin roles the matching screens already use, so an admin or integration token that can reach the REST API can reach these, and a role that cannot ship items cannot ship them through the API either. The storefront fields stay open, as the rest of the storefront schema is.
One thing worth knowing if you have a mixed catalogue: rental products previously came back as
nullfrom Magento's standardproductsquery, because the rental product type had no GraphQL type of its own. A headless listing silently lost exactly the products this extension exists to sell. That is fixed in the same release.Full documentation, with a worked example for every query and mutation, is in the GraphQL API section of the Magento 2 Rental docs.
Show the units that never go out, and get the percentages right
The utilization report only listed kit that had been sent out, so the units earning nothing were invisible - and several of the percentages it did show were measured against the wrong capacity.
Read moreShow less
The utilization report answered the wrong question. It told you how hard the kit you did send out had worked, and said nothing at all about the kit that never moved — because the per-unit rows were built from what had been shipped, a unit that earned nothing simply was not in the report. The one row worth reading was the one you could not see.
The numbers that were there could not always be trusted either. Once one unit had an acquisition date inside the period, every unit after it in the list was measured against that unit's shorter capacity and read too high. A unit's capacity stopped at its last booking rather than at the end of the report, so something that sat idle for the rest of the period still showed as fully used. And with the calculation method set to Product, anything bought recently could report well over 100% utilized, because the hires were counted over the whole period while the capacity started on the day you bought it.
Shipped in 1.2.198. Every unit is now measured on its own, over the same window its capacity is measured over, and units that never left the yard are listed at 0%. The report also no longer stops dead on a product with no rental stock — that used to end the run and leave the report stuck on "running" indefinitely — and the per-unit data is read once per product instead of once per unit per booking, so it builds considerably faster.
Refundable security deposits at checkout
Take a deposit with the rental payment, hold it against the order, and release it in full or in part when the item comes back in one piece.
Read moreShow less
A deposit is the customer's money, and treating it like a sale is what makes it go wrong. Taken as an ordinary line it is taxed, it lands in revenue, and getting it back to the customer is a manual refund that somebody has to remember weeks after the kit came back. Most shops ended up taking deposits off-system, or not taking them at all.
Shipped in the Deposits & Damage Waiver extension 1.0.0. The deposit is charged with the order so that it can be refunded, and is tracked as held money from that moment until somebody — or the clock — decides where it goes.
- Priced per product or per order — a flat amount, a percentage of the rental charge, or an amount per day, optionally multiplied by quantity, with a minimum and a maximum per line. Set it for the shop and override it on any product, or turn it off for the ones that never leave the yard.
- Its own line, and not revenue — kept apart from the hire charge, untaxed by default, and visible as a deposit to the customer rather than buried in the total.
- Released from the order page — give it all back, or give part of it back and keep the rest against a damage or late charge. Keeping any of it requires a reason, and the reason is stored on the order.
- Or released on a schedule, a set number of days after the hire comes back, so deposits do not sit on the books waiting for someone to remember them.
- The automatic release will not run early — it fires only once every unit on the order has actually been returned. Anything still out, overdue or lost keeps its deposit until a person decides.
- A refund the gateway keeps refusing stops and asks for help rather than retrying forever, and the order says so.
Every deposit is in one of five states — held, released, part released, retained, or failed — and which one is recorded rather than inferred. To a refund-shaped system, "we kept the money because the trailer came back with a bent drawbar" and "nobody has got round to it" look identical, and the difference between them is exactly what a dispute or a chargeback turns on.
Installing it changes nothing on your existing orders: the deposit panel renders only on an order that actually has one. Setup and the day-to-day handling are documented in the Magento 2 Rental docs.
Damage waiver at checkout
A waiver line the customer accepts or declines on the product page, priced as a percentage of the hire or a flat amount, and recorded against the order.
Read moreShow less
Hire trades that handle damage with a waiver had no way to sell one. The charge had to be added by hand after the order, which means it is missed on the orders that are busy enough to matter, and there is no record of the customer ever having been offered it — which is the only part that counts when there is an argument about a broken machine.
Shipped in the Deposits & Damage Waiver extension 1.0.0. The waiver is now a line the customer sees and decides on before the item is in the basket, and the decision travels with the order.
- Offered four ways — mandatory, optional and pre-ticked, optional and unticked, or not offered at all. Set it once for the shop and override it on any product.
- Priced the way your trade prices it — a percentage of the rental charge (10–15% is the equipment-hire norm), a flat amount per item, per day, or once per order, with an optional floor and ceiling per line.
- The customer is shown the rule, not a guess — the product page says "10% of the rental charge" rather than a figure, because on a percentage waiver the real amount is not knowable until the hire dates are picked. The amount appears in the basket as soon as they are.
- The decision is recorded on the order, as Accepted or Declined, and survives everything that rebuilds an order later — admin order edit, reorder, a request for quote, and extending a live hire.
- It is revenue, and it is taxed like revenue — its own line, its own tax class, invoiced with the order, and non-refundable unless you deliberately allow refunds.
- Mandatory means mandatory — a control the customer cannot untick is still one they can delete from the page, so acceptance is applied on the server rather than trusted from the browser.
A damage waiver limits what the customer owes for accidental damage under your hire contract. It is not insurance, the default wording on the product page says so, and selling insurance is a regulated activity in most countries. One setting deserves a second thought before you use it: an optional extra that arrives pre-ticked is restricted for consumer sales in the EU and the UK, so it is there for shops hiring to trade customers rather than as a default.
Setting it up, and what a member of staff does with it day to day, is documented in the Magento 2 Rental docs.
Four storefront date pickers, and the old one kept
Choose the calendar your storefront uses from one setting: an inline range picker, a popup range picker, separate start and end pickers, or the calendar that shipped before this release.
Read moreShow less
Stores › Configuration › Sales Igniter › Rental › Calendar Styler now has a single Date Picker setting with four options. In Line Range Picker is the new default. Previous Date Picker is the jQuery UI calendar that shipped before 1.2.197, kept unchanged, so a store can rule the new calendar out if anything misbehaves.
The setting replaces the old Calendar Engine and Always Show Calendar settings. Every store that had either of those is migrated to the equivalent picker on upgrade, so no store changes calendar by itself, and the per-product "Show the calendar in line" attribute still overrides the store setting.
A guided booking flow, one question at a time
The In Line Range Picker asks for one thing at a time — start date, start time, end date, end time — with a progress row across the top showing what has been chosen so far.
Read moreShow less
Rather than presenting two calendars and two time dropdowns at once, the picker moves the customer through the booking a step at a time and shows only what is relevant to the step they are on. The progress row across the top fills in as they go, and any completed step can be clicked to go back and change it.
Choosing a new start date clears the steps after it, so a range that is no longer possible is never left behind. A Start over control resets the whole selection, and the panel keeps the customer in one place instead of scrolling between fields.
Design the calendar with a live preview
A Calendar Styler settings group with the real calendar rendering beside the fields: style, main colour, corner radius, months shown, slot interval, legend and units left.
Read moreShow less
Style (airy, card, bold or classic), main colour with presets, corner radius, how many months are shown, the time slot interval, whether the progress row appears, whether the units left in each day are shown, and whether the legend is shown — each changes the preview as you set it.
The Date Picker and Style are chosen from picture cards that show what each option looks like rather than from a dropdown of names, and the preview can be switched between a product-column width and full width to check both.
Time of day as a slot grid, and a reason when a slot is greyed out
The chosen day’s times at your configured interval, grouped under Morning, Afternoon and Evening, with the store hours in the heading — and an unavailable slot says why it is unavailable.
Read moreShow less
Time of day was a dropdown; it is now a grid of the day's slots. A greyed slot is labelled with the reason: Booked for someone else's reservation, Disabled for an admin closure, before pick-up on a same-day return, or too short for the minimum rental period. The customer is not left guessing which of those it was.
Right-to-left locale support in the calendar
The calendar renders right to left in RTL locales, popup calendars included.
Read moreShow less
Popup calendars previously rendered left to right with Sunday on the left, while the inline calendar next to them was correct. Both now follow the store locale.
Rentals Dashboard
One screen for the day: units going out, due back, overdue and currently out, the next seven days, and a money card with revenue, average order value and the top five products.
Read moreShow less
Rentals › Dashboard shows units going out, due back, overdue and currently out for any chosen day, the next seven days, and an overdue list oldest first. The money card carries revenue this month, the last 30 days against the previous 30, the average rental order, orders awaiting payment, a 12-week paid-against-ordered chart and the top five products by revenue.
The whole page arrives in one request, so stepping a day or changing source is a single round trip rather than one per panel.
Inventory Availability report on the standard Magento grid
Keyword search, a filters popover with removable chips, a columns popover, paging and CSV export, over day, week, month and 90-day views.
Read moreShow less
The report now uses the same data grid toolbar as the rest of the admin, so it behaves the way every other Magento grid does. A heat map over the booked share has distinct sold-out and overbooked states, product and day headers stay put as you scroll, and a hover card breaks the reserved figure down by order, manual, maintenance and RFQ.
It is fully keyboard navigable, and any view can be exported to CSV.
Rental Calendar report with an Out / In view
The default view shows, per day, how many units go out and how many come back, the orders behind them and any overdue units, with Send and Return actions in the day popover.
Read moreShow less
Opening a day lists every pick-up and return for it with Send and Return actions beside each. By order, week and timeline-by-product views are there as well.
The FullCalendar library the old report loaded on every admin page that rendered it has been removed entirely, so the report is lighter as well as more useful.
Serial Numbers report: one row per physical unit
Each serial is a row with a bar for every booking, labelled with the order and customer, so a unit’s year reads without a click. Plus bulk actions, a record drawer and CSV export.
Read moreShow less
Adds a retired status; bulk send, return, new maintenance ticket and change status actions; a serial record drawer with cost, acquisition, utilisation and booking history; and a CSV export.
Rebuilding it turned up three faults worth naming. The report rendered blank on arrival because the first request carried no source or stock scope. The source and stock filters were swapped, so filtering by source silently filtered by stock instead. And the stored serial status and maintenance ticket were ignored, so a unit held in the workshop looked identical to one out on a customer booking.
A booked day can no longer show as free
Availability is now derived from the reservations table when it is read, instead of from a cached inventory array that could be up to 24 hours out of date.
Read moreShow less
The old design cached a serialized inventory array per product and only invalidated it when the product was saved — never when a reservation was written — so a day that had just been booked could keep showing as available for up to a day.
Availability is now built on read, with a date-windowed query and a sweep-line builder. The rental cache type, its cron job and its console command are gone with it, so there is one less thing to warm, flush or explain.
Moving between months no longer waits on the server
Everything the calendar needs is sent with the page, so stepping through days and months is instant.
Read moreShow less
Every month change used to make an availability round trip. The page now carries the availability the calendar needs, so navigation happens in the browser.
A faster storefront and admin
First phase of removing the HTML round-trip plugin that re-parsed rendered HTML on every block of every page. The admin order view went from 0.421s to 0.208s.
Read moreShow less
The extension used to place several pieces of its output by re-parsing already-rendered HTML, on every block of every page. Each behaviour that has been replaced keeps its own compatibility switch under Stores › Configuration › Sales Igniter Rental › Theme Compatibility, all off by default, so a heavily customised theme can put any one of them back.
Measured on the admin order view, 0.421s down to 0.208s. The product page is 37ms faster and the category page 57ms faster.
Magento 2.4.9 on PHP 8.3 and 8.4
Supported on the current Magento release and the current PHP versions.
Read moreShow less
Rental date storage also moves to the MySQL date format in this release. The conversion is scheduled by the upgrade and runs on the next cron passes in bounded chunks, so nothing long runs inside setup:upgrade. To convert immediately instead, run
bin/magento salesigniter:rental:migrate-dates --dry-runand then without the flag. It is idempotent and one way, and any row it cannot parse is reported and left untouched.Hyvä theme support, as its own extension
salesigniter/hyvarental supplies the Hyvä versions of the templates that depended on Luma’s JavaScript — one extra Composer command, and nothing changes for Luma stores.
Read moreShow less
Hyvä ships no RequireJS, no jQuery and no Luma JavaScript, and its product page markup is not Luma's. This optional companion extension supplies the Hyvä versions of the few templates that depend on that: the rental add-to-cart button with the Rent and Buyout labels, the pricing card, and the out-of-stock modal, rewritten with Alpine and Hyvä's own modal helper instead of emitting a RequireJS call on every page of the site. It also moves the pricing card next to the calendar, where the Luma layout instruction silently matched nothing and left the card down by the footer.
It requires rental extension 1.2.197 or later. Everything in it is wired through the Hyvä compatibility module fallback and Hyvä's own layout handles, so nothing in it can reach a Luma page. One known limitation: the Previous Date Picker needs jQuery UI and therefore RequireJS, so a Hyvä store always gets the new calendar whatever that setting says.
Stop rental and regular products being bought in one order
A setting that stops a rental and a regular sale product being combined in the same purchase, for businesses whose fulfilment cannot handle a mixed order.
Read moreShow less
Some hire businesses pick, book out and invoice a rental completely differently from a sale, and a basket holding both is a problem rather than a convenience. This setting refuses the combination at the cart, rather than letting it through to a warehouse that cannot process it.
Availability re-checked at checkout, not just at add to cart
A basket that sat open while someone else booked the same dates is caught at the checkout page, instead of becoming an order you cannot fulfil.
Read moreShow less
Availability was checked when the product went into the cart. On a busy catalogue that leaves a window: two customers can both add the last unit for the same dates, and whoever pays second gets an order that cannot be fulfilled. The check now runs again on the checkout page, so the conflict surfaces before payment rather than after it.
Hide the calendar per product when there is no inventory
The global setting existed; this adds the same control per product, so one out-of-stock line does not show a calendar with nothing bookable in it.
Read moreShow less
Showing an empty calendar on a product with no units left invites a customer to try every date and fail on all of them. This can now be decided per product rather than only for the whole store.
Customers can see their upcoming and past reservations
A reservations page in the customer account: what is coming up, and everything they have hired before.
Read moreShow less
A customer who wants to know when their booking starts, or what they hired last summer, no longer has to open old order emails or ring the counter.
Customer reservations tab in the admin
A Reservations tab on the admin customer page, so a phone call can be answered from the customer record instead of from the order grid.
Read moreShow less
Someone calls about their hire. You have their name. This puts their reservations on the customer page, rather than making you search the order grid for the right order first.
What customers are asking for
Requests sent through the form below, in the customer's own words, once we have read and approved them. Customers with a licence can vote, and votes decide the order.
The first requests are being reviewed. Yours could be the first one listed. Send it below.
On the table, not yet promised
These are candidates, not commitments, and there is no date on any of them. Demand decides the order: vote for the ones that would change how you work, or tell us on the form, and they move up.
Scan a barcode to return a rental
Point a keyboard-wedge scanner at each item on the return screen and it checks itself in, instead of picking serials from a list.
Read moreShow less
Each scan would look up the serial number, match it to the open reservation it belongs to and mark that unit returned, so a van full of kit is checked in as fast as you can point the scanner at it. Mis-scans and serials that are not currently out would be flagged rather than silently ignored.
Printed labels carrying the barcode for every serial would go with it. This already exists on the WooCommerce side, so there is a working design to follow.
Late return fees charged automatically
A rule per product or globally — a grace period, then a charge per hour or per day — applied when a unit is returned after its due time.
Read moreShow less
Late fees are usually decided at the counter and often not charged at all. A rule the system applies would make the charge consistent and defensible, calculated from the actual return timestamp and shown to the customer before it is taken.
Condition photos at send and return
Attach photos to a unit as it goes out and again as it comes back, kept with that serial’s history.
Read moreShow less
The argument about who caused the scratch is the most expensive five minutes in a hire business. Photos taken at both ends, held against the serial and the order, settle it.
SMS and WhatsApp reminders
Pick-up and return reminders sent to the phone rather than to an inbox nobody reads.
Read moreShow less
Email reminders exist. For a same-day or next-day hire an email is often read too late, and late returns cost availability. This would send the same reminders over SMS or WhatsApp through a provider of your choosing.
iCal feed per product
A subscribable calendar feed of a product’s bookings, so the yard, a driver or a partner can see what is out without an admin login.
Read moreShow less
A read-only .ics feed per product, or per source, that Google Calendar, Outlook or a phone can subscribe to. Importing the other way — blocking dates from an external calendar — would be the natural second half of it.
Webhooks for send and return
Fire an HTTP call when a unit goes out, comes back or goes overdue, so other systems can react without polling.
Read moreShow less
Accounting, a driver app, a maintenance system, or an automation tool. Today the only way to find out that a unit went out is to look. A signed webhook per event would let those systems be told instead.
Subscriptions and memberships for hire
Recurring billing for long-term hire, and membership plans that carry an allowance or a members’ rate.
Read moreShow less
Long-term hire billed monthly, and membership tiers that come with a number of hires, a discount, or priority on a queue. This exists on the WooCommerce side, so the data model and the billing flow have been worked through once already.
Rental queues and a waiting list
When everything is out, let a customer join a queue for the next free slot instead of leaving the site.
Read moreShow less
A queue per product with a position the customer can see, notified when a unit comes back, with a window in which to confirm before it passes to the next person. For high-demand stock this turns a sold-out page into a booking.
Delivery and collection routing
Group the day’s deliveries and collections into runs, with time windows the customer picks at checkout.
Read moreShow less
For businesses that deliver, the schedule is the hard part, not the booking. Delivery and collection windows chosen at checkout, a day view grouped into runs, and a driver sheet per run with the addresses and what is on each stop.
Pick-up branch chosen at checkout
Multi Source Inventory already holds stock per source. This would let the customer choose which branch they collect from, and check availability against that branch only.
Read moreShow less
A store with several depots can already hold rental stock per source. What is missing is the customer-facing half: choosing the branch on the product page or at checkout, seeing a calendar that reflects that branch's stock rather than the total, and returning to a different branch if you allow it.
Request a feature
Tell us what you are trying to do and how you handle it today. Concrete beats general: the requests that get built are the ones where we can picture the yard, the counter or the spreadsheet you are replacing. Say which Magento version and theme you are on if it matters. We read every one and reply, and approved requests are listed above in your own words.
Magento 2 and Adobe Commerce rental extension questions
Does Magento 2 have a rental system built in?
No. Magento Open Source and Adobe Commerce sell a product once and have no idea of a hire period, availability across dates or a return step. Renting is added with an extension. Sales Igniter puts an availability calendar, date-based pricing, quantity and serial-number inventory, send and return tracking and rental reports on top of the standard Magento catalogue, cart and checkout, so your theme, payment methods and shipping carriers keep working. See the Magento 2 rental booking extension features and pricing.
Does it work with Adobe Commerce as well as Magento Open Source?
Yes. It is one extension and it installs the same way on both, through Composer from our own repository. It is currently supported on Magento 2.4.x up to and including 2.4.9, on PHP 8.1 to 8.4. Multi Source Inventory is supported through a separate add-on, so a multi-branch hire fleet can hold stock per source.
What should a Magento 2 rental extension do?
At minimum: block dates that are already reserved, price by duration rather than per unit, hold or take a payment, and record when each unit went out and came back. Beyond that the needs differ by trade, which is why most of the list above exists: serial-number tracking for equipment hire, buffer time for cleaning and turnaround, a dashboard for the counter, and reports that tell you what is out and what is late. The full feature list shows what is covered today.
Does it work on a Hyvä storefront?
Yes, with the free companion extension. Hyvä ships no RequireJS, no jQuery and none of Luma's JavaScript, so the handful of templates that depend on those are supplied by salesigniter/hyvarental, installed with one extra Composer command. Nothing is needed on Luma or a Luma-derived theme. The one limitation is that a Hyvä store always gets the new calendar, because the older jQuery UI picker cannot run without RequireJS.
How do I request a feature, and what happens next?
Use the form on this page and leave the platform set to Magento 2. We read every request and reply. Requests we approve for listing appear under "What customers are asking for" with a status that changes as it moves through under consideration, planned and shipped. Nothing is published automatically.
Who can vote, and how do votes count?
Anyone logged in with a Sales Igniter licence for the Magento 2 rental extension or one of its add-ons can vote once per request. Votes order the open requests on this page and are the main input when we plan a release. Not a customer yet? The form still works, and you can vote once you have a licence.
Is the Magento roadmap the same as the WooCommerce one?
No. They are two products on two release cycles, built on two platforms, so a feature can land on one long before the other and some features only make sense on one of them. The WooCommerce side has its own page: WordPress / WooCommerce rental plugin feature requests and roadmap. If you want something on both, choose Both on the form and it is listed on both pages.
Already a customer with something urgent? Support requests go through the helpdesk rather than this form. Paid custom development is available too — see custom development.