All case studies
HQRentSaaS

One checkout, whether they found you or the marketplace did

Renting a trailer means dates, a deposit, a signed contract, and a card. HQRent runs that flow once and serves it in two places: an operator's own storefront, and the Big Rentals marketplace.

The HQRent online checkout feature page
Role
Full-stack development
Type
Checkout, payments, and contracts
Scope
Storefront, booking flow, payment, e-signature
Status
Live on both products

Front ends, one flow
2
Booking without a phone call
24/7
Contract signed in the flow
1
Double entry between systems
0
01The problem

A rental checkout is not a shopping cart.

Buying a product is one decision. Renting one is several, and they interact. The dates decide the price. The deposit depends on the asset. There is a contract that has to be agreed before anything leaves the yard, an ID or licence check on some categories, and add-ons that change the total after the customer thought they were done.

Bolting a generic cart onto that gets you a booking that is not really a booking. The money is taken, the calendar does not know, the contract is a PDF someone will email tomorrow, and the trailer is quietly still available to the next person who asks.

  • Price is a function of the date range, not a fixed number
  • Deposits, add-ons, and rules vary per asset and per operator
  • A contract has to be signed before handover, not after
02The flow

Dates, deposit, signature, card, in that order.

Choosing the pickup and return dates prices the rental and holds the asset in the same action, so the calendar is committed at the moment the customer thinks it is. Add-ons and services recalculate the total in place rather than surprising anyone on a confirmation screen.

The contract is presented and signed inside the flow, and stored against the booking rather than in an inbox. Payment runs last, through integrated processing, with the deposit handled as part of the same transaction. When it completes, one record holds the dates, the money, the signature, and the asset.

  • Date selection prices and holds in one action
  • Add-ons and services reprice before payment, not after
  • Contract signed and stored against the booking record
The online checkout flow: dates, options, and payment in a single sequence
03Payments

Take the money at the moment of intent.

Rental operators historically took a card over the phone, or nothing at all until pickup, which is where no-shows come from. Payments are integrated with the major processors, cards are stored against the customer for repeat bookings, and the deposit and the rental are handled in one flow rather than two conversations.

Because payment and booking write to the same record, reconciliation stops being a monthly chore. What was charged, for which asset, on which dates, against which signed contract, is one lookup.

  • Integrated processing with the major card providers
  • Deposits taken alongside the rental, not chased separately
  • Saved payment methods for repeat customers
The HQRent payments feature with integrated processing
04Two front doors

The operator's own store, and the marketplace.

An operator can point their own domain at a white-label storefront that carries their branding, or take bookings through the marketplace, or both. It is the same checkout underneath either way, which is the entire point.

That means a supplier does not maintain two inventories, two calendars, or two sets of prices. A trailer booked through Big Rentals blocks the dates on the operator's own site instantly, because there is only one calendar and it never had to be synced.

  • White-label storefront on the operator's own domain
  • Marketplace bookings write to the same calendar
  • No inventory sync, because there is only one inventory
Choosing how to set up an HQ, including the checkout web store
05The result

One booking record, however it started.

Whether a customer found the trailer through a Google search that landed on a Big Rentals city page, or through the operator's own website, the booking ends in the same place: dates held, contract signed, deposit taken, asset marked out.

Building it once and serving it twice is what makes the two products feel like one company rather than two tabs.


Tech stack

What we built it with

Production-proven tools chosen for performance, developer velocity, and long-term maintainability.

  • Next.jsNext.js
  • TypeScriptTypeScript
  • StripeStripe
  • PostgreSQLPostgreSQL
  • PrismaPrisma
  • VercelVercel
Outcome

What shipped

  • Dates, deposit, contract, and card in one uninterrupted flow
  • Asset held at the moment of date selection, not at payment
  • Contracts signed in the flow and stored against the booking
  • Integrated card processing with saved payment methods
  • White-label storefront on the operator's own domain
  • Marketplace and storefront sharing one calendar

Want results like these?

Book a free 30-minute call. We'll scope your project, recommend the right approach, and tell you honestly if we're the right fit.