Rental Software with Stripe: Taking Deposits, Payments and Refunds Online

Every hire has three separate points where money changes hands, and most rental businesses handle each one differently. There is the deposit taken, or held, before the equipment goes out the door, the payment for the hire itself once the job is confirmed or completed, and — often — a refund or a partial recharge once the item comes back, depending on what state it's in.

On paper that sounds tidy. In practice, the deposit gets taken on a card machine at the counter, the invoice gets emailed and chased separately, and if a refund is due someone logs into a payment dashboard days later and processes it by hand, hopefully against the right customer and the right order. None of these three moments talks to the other two. The card machine doesn't know which order the deposit belongs to. The dashboard doesn't know the invoice is now settled. And the office finds out only when someone asks, "did we ever get that deposit back to them?"

This is not really a technology problem, it is an order-tracking problem that happens to involve money. A hire order already carries a customer, a set of items, dates out and back, and a value. If payments live in a separate system from that order, someone has to reconcile the two by memory or by spreadsheet, every single time. That reconciliation is where deposits get forgotten, refunds get missed and invoices get chased twice.

The three payment moments in a hire are only useful if each one is attached to the order it belongs to, not floating as a separate transaction that someone has to match up later.

A deposit that sits against the order record means anyone looking at that hire — not just the person who took the payment — can see it was taken, how much it was, and whether it has been returned or kept. A payment for the hire itself, linked the same way, means an invoice does not sit "unpaid" in the accounts when the customer has, in fact, paid; the finance team is working from the order's real state rather than a card machine receipt roll.

The refund or recharge at the end matters most of all, because it is the one most likely to go wrong when it is handled separately. If a damage deduction is taken from a deposit outside the order, there is no record on the hire itself of what was kept, what was returned, or why — only a note in someone's inbox, if that. Keeping all three moments against the order is less about neatness and more about being able to answer, without a phone call, exactly what happened to a customer's money on any given hire.

Not every payment moment happens with the customer standing in front of you. A lot of hire business is booked by phone, by email, or through an online inquiry, and the traditional way to collect payment for that — a card machine at the counter — simply isn't there.

The general alternative, common across online payments now, is a payment link or hosted checkout page: rather than reading a card number down the phone or waiting for a bank transfer, the customer gets a secure link, enters their own card details on a page run by the payment provider, and the payment is confirmed without the office ever seeing the card number. Renttix connects to Stripe for exactly this, so an order that has been quoted or confirmed can be taken to payment natively, inside the platform, rather than through a separate invoice-and-dashboard process bolted on afterwards. That is the point of the Stripe integration — the payment is a step in the order's own workflow, not a parallel task someone has to remember to do.

For a rental business this closes a gap that a card machine cannot: it lets you take a deposit or a payment before the item ever leaves the yard, from a customer who is nowhere near you, without asking them to read a card number aloud or trust a bank transfer reference to land in the right place.

Plenty of hire is a single transaction: book it, take it, bring it back, pay for it. But a growing share isn't — long-term equipment on an open-ended rental, welfare units on a subscription-style cycle, or a customer who hires from you every month and doesn't want to key in a card every time.

For that kind of arrangement, Renttix supports storing a card on file so open-ended rentals and subscriptions can be billed on a recurring cycle without someone manually taking payment each time. The same card-on-file approach underpins metered usage billing, where charges depend on actual use rather than a flat period, and it is what lets accruing late fees be collected without a separate step chasing them down. The customer authorizes the card once, and the billing cycle takes care of itself from there.

This matters for cash flow as much as convenience. A business that has to actively chase a card payment every month for a long-running hire is a business that will, sooner or later, miss a cycle — through a member of staff being off, a customer being hard to reach, or simply the invoice slipping down the list. Card-on-file billing removes that dependency on someone remembering to ask.

The end of a hire is where separate systems cause the most damage, because it's the point with the most exceptions: the item comes back a day late, something is missing, there's a scratch that needs recharging, or everything is fine and the deposit just needs to go back.

Renttix lets you raise a credit note against the original invoice and issue a full or partial refund from there, synced back to your accounts rather than processed as a standalone transaction that finance has to notice and match up separately. That distinction — full or partial — is what makes recharges workable in practice. A damaged item does not have to mean either refunding the whole deposit and writing off the repair, or keeping the lot and arguing about it; a partial refund lets you return what is owed and account for what is kept, against the same invoice the deposit was taken on.

Because the credit note and the refund both reference the original order, anyone reviewing that hire later — a manager checking a dispute, an accountant closing the month — can see the full sequence: deposit taken, hire invoiced, deduction made, remainder refunded. That is a materially different position from a note in an inbox saying "sorted it, refunded them most of it."

Every one of the payment moments above still assumes someone in your office is initiating them. The customer portal removes that assumption for the transactions that don't need a human on your side at all.

Through the portal, customers can manage their own saved cards, pay an invoice that's outstanding, sign a hire agreement, and request an off-hire when they are finished with the equipment — without phoning the office to do any of it. For a straightforward payment on an invoice that is already correct, there is no reason that should require a conversation; the customer can settle it themselves, at whatever time suits them, and a call at 7pm to ask if a card payment "went through" is a call your office does not need to take.

This does not replace the deposit, payment and refund flows described above — it just moves who presses the button. The order, the invoice and the payment record stay exactly where they were; the portal is another way in, not a different destination.

To make this concrete: imagine a party hire business taking bookings for marquees, tables and chairs — a useful illustration, not a claim about how every hire business must operate.

A customer inquires about a marquee for a weekend event, six weeks out. At booking, the business takes a deposit online through a payment link, rather than asking for a bank transfer and waiting to see if it arrives. That deposit sits against the order from the moment it's paid. In the week before the event, the balance for the hire is invoiced and paid the same way — a link, not a card machine, since nobody from the business is standing in front of the customer until delivery day itself.

After the event, the marquee comes back with a torn panel. Rather than keeping the whole deposit or refunding it in full and absorbing the cost, the business raises a partial refund: the repair cost is deducted, and the rest goes back to the customer's card as a credit note against the same invoice the deposit was taken on. The customer sees a clear reason for what was kept, the business has a record attached to the order rather than a conversation nobody wrote down, and nothing had to be reconciled by hand between a card machine, a bank statement and an invoice.

None of this requires choosing a single payment method for every customer. Stripe is one of several payment providers Renttix connects to, alongside options like PayPal, Square, Razorpay, Xendit, Mercado Pago, Alipay+ and Airwallex, and payments taken through any of them can carry tax calculated by classes, zones and exemptions where that applies — a separate subject in its own right, covered on the global payments and tax page, rather than something this article tries to explain in full.

What matters for the deposit-payment-refund cycle specifically is that each of the three moments sits against the order it came from, whichever provider takes the money. Set up correctly, a Stripe integration means a deposit, an invoice payment and a refund are three entries on the same hire record, not three separate stories that only line up if someone remembers to tell them to each other.

If your current setup involves a card machine that doesn't know about your bookings and a payment dashboard nobody checks until month end, that gap is worth closing before it costs you a missed refund or a disputed deposit. Get in touch to see how it fits your own hire operation.