Rentiva 6.1.0 — Cancelling a paid booking now returns the money

If a customer paid and then cancelled, Rentiva marked the booking as awaiting a refund and stopped there. No money moved. Somebody had to notice and refund it by hand. From 6.1.0 the cancellation carries the refund through to your payment gateway itself.

The refund actually happens now

This applies to both ways a booking gets cancelled: the customer cancelling their own booking, and you cancelling it from the deposit screen. Both now run the refund to the end.

Where the gateway can return the money, it does, automatically. Where it cannot — an offline payment, a gateway that does not support refunds — the booking is recorded as awaiting a manual transfer, and the customer is told that a person will transfer it rather than being promised an automatic return that is not coming. Which of the two happened is written on the booking and stated in the e-mail the customer receives.

A customer who cancels before the cancellation deadline now gets the whole refundable balance back automatically, with no step from you in between. Rentiva defines no cancellation fee, so a full refund is the only policy it can apply.

Several things that made refunds unreliable

While fixing the path above, a number of related faults came out. All of these are fixed in 6.1.0:

• Refunding a paid order failed. The refund screen refused any order that had actually been paid. It was asking whether WooCommerce still considered the order editable — which is only true while an order is pending, on-hold or a draft — instead of asking whether the gateway could send the money back.
• A deposit booking's second order was invisible to refunds. When a booking was paid in two parts, the remaining-payment order was not found at all, so only the deposit came back.
• One refund was counted twice. A single refund ran through two separate record-and-notify steps, so the booking's refunded total was doubled and the customer received two e-mails for it.
• The refund notice did not always reach the customer. It read an e-mail field that the contact form fills in and bookings do not. When that field was empty it skipped the notice silently. It now looks where the rest of the plugin looks: the booking's own customer e-mail, then the WooCommerce billing address, then the linked account.
• A refund nobody's gateway performed was recorded as completed. It is now recorded as awaiting a manual transfer, because the money has not moved until someone moves it.
• A part-card, part-cash refund told you to transfer the whole amount by hand. The two amounts are now named separately: what the gateway already returned, and what still has to be transferred.
• Cancelling one order on a two-part booking disturbed the other. Cancelling the unpaid remaining-payment order used to cancel or demote the whole booking even though the deposit order had been paid — with no refund anywhere. The paid order is now left alone, the dead order's link is cleared so you can issue a fresh payment link for what is still owed, and you are notified.
• Manually created bookings had no payment method at all, which left them unlabelled in the booking list and its filter, refused by the refund path, and grouped into a blank bucket in payment-method reports. They are now recorded as offline payments.
• The refund box on the booking screen shows its form for offline bookings with a balance — for the first time. The box was always there; in place of the form it printed "No refundable payment found for this booking," because the form needed a figure that nothing ever wrote.

Two refunds started at the same moment on the same booking — a cancellation and one you started from the admin screen — can no longer run at once.

Money conversion now follows your store's decimals

Rentiva converts between your currency and its smallest unit. It used to assume that unit was always one hundredth. It now reads your store's own setting: WooCommerce → Settings → General → Currency Options → Number of Decimals.

If your store uses the default of two decimals, nothing changes for you.

If your store is set to a different number of decimals, read this before updating: refund and payment amounts that Rentiva recorded before this release are re-read at the new scale rather than converted. There is no migration step for existing records, and none is planned. Currencies without minor units — the Japanese yen, for example, at zero decimals — are the case this affects.

Deposits taken outside WooCommerce

If a booking's deposit was taken outside WooCommerce, Rentiva no longer offers a WooCommerce payment link for the remaining balance.

For a manually created booking that never had a WooCommerce order, that link always failed anyway. For a booking that started at WooCommerce checkout and whose deposit was later marked as received offline, the link did work — and that was the fault: completing it built a WooCommerce order that quietly erased the earlier offline deposit from the booking's recorded paid amount.

The deposit screen now explains the situation instead of offering a button that would lose money. Process Remaining Amount, which records the balance as settled without going through WooCommerce, is unaffected and still works.

Screens

The vehicles list is rebuilt, with list, card and calendar views. There is a new monthly fleet occupancy calendar showing every vehicle's month at a glance. The Additional Services screen is new.

Updating

Rentiva is on the WordPress.org plugin directory, so the update appears on your Plugins screen on WordPress's own schedule — usually within half a day. You can also check for it immediately from Dashboard → Updates.

Tested up to WordPress 7.1. Requires WordPress 6.7 and PHP 8.1.