SiteMinder
SiteMinder Pay
Look at Payments Taken on the right: unpaid in red, paid in green, partial still outstanding. That is the front-desk question this product had to answer.
The job
Taking a booking payment was not one task in one product. Small and mid-sized operators in Wollongong, Kiama, and Sydney were moving between OTA portals, Channel Manager, a physical terminal, and a property system — and none of them had a fully integrated PMS, so the workarounds were fully visible.
4 of 4 still retyped card details into a payment terminal.
The current process
- Find the reservation in Channel Manager or an OTA portal.
- Retrieve or reveal the card details.
- Retype them into a payment terminal.
- Mark the booking paid in another system.
- Send a receipt, and reconcile later.
How might we reduce payment handling without forcing operators to abandon the reservation workflows they already trust?
Payment is a high-consequence action. Speed is not enough. Operators needed to know who had paid, what remained outstanding, whether a receipt had gone out, and how a refund would hit the record.
The bet
SiteMinder wanted payments in the product they already sold. We looked at three levels of integration. Two of them failed the workflow evidence.
Rejected
Fully integrated
Put history, payouts, and reconciliation inside Channel Manager. It would have overloaded a legacy booking summary with back-office finance.
Rejected
Standalone
Move the whole job into a separate SiteMinder Pay product. Operators would leave the reservation tools they already trust just to take a deposit.
Chosen
Hybrid
Initiate and track payment in the booking. Keep transaction history, refunds, payouts, and reconciliation in a dedicated Payments area.
Booking context answers “Has this guest paid?”
Payments holds finance work across many reservations.
The business bet was attach: if payment lives on the reservation, SiteMinder has a wedge into hotel finance — deposits taken, leakage reduced, time-to-charge shortened — without pretending Channel Manager is a ledger.
The proof
Four in-person sessions. We walked the current process, then asked operators to find an unpaid booking, take a payment, confirm it, issue a refund, and find the transaction later.
The charge
Worked
4 of 4 immediately understood the payment screen and processed a charge. Three named meaningful time savings.
4 of 4 understood the guest had been charged after the success state.
4 of 4 said they would try SiteMinder Pay.
Find / verify / recover
Failed
1 of 4 noticed payment status in the reservation list without prompting.
2 of 4 found the refund immediately. The other two needed about 15 seconds.
0 of 4 could intuitively find past transactions.
That shifted the design conversation. We stopped asking whether operators could process a payment, and started asking whether they could locate, verify, and recover one later.
What we designed
The charge lives inside the reservation they already open. The dedicated Payments product is for the work that spans many bookings.
Find the unpaid arrival
Check-in is where they already look. Payment Taken sits on the booking, in red when nothing has been collected.
Act from the booking they already trust
Card details are already on the reservation. Manage payments starts the charge without sending them to another product.
No retyping
Amount, surcharge, and the card on file. Process payment is the step that used to mean a terminal and a second system.
System state, not a toast
Branson Richardson has been charged AUD 403.90. A confirmation is on its way. 4 of 4 understood the customer had been charged from this screen.
Recover from the same booking
Past payments and a refund sit on the reservation. This is the path 2 of 4 found slowly, and where 0 of 4 expected to look for history.
Refund is an explicit action, with the amount available sitting next to the control.
Transaction detail is a record, not a navigation problem: status, fee, refund, and where the money is.
Payouts stay in Payments. That is the finance surface — money moving across many reservations — and the reason the booking summary does not try to be a ledger.
What the test changed
The charge was not the problem. Find, verify, and recover were. Three changes carried the weight; the rest were copy and control fixes.
1 of 4 saw list status
Make status the default view
Default Reservations to the next seven days, add a payment-status filter, and strengthen status in the list and the booking summary.
2 of 4 found refund slowly
Put refund on the booking
Refund is an explicit action on the paid reservation, not a hunt through a separate transactions page.
0 of 4 found history
Replace “transactions”
Direct receipt and print actions instead of ambiguous transaction navigation. History has to be reachable from the booking they just charged.
Plus a set of smaller fixes: surcharge disabled when it does not apply, internal note separated from the customer-facing one, receipt email and invoice under operator control, date-based sorting for daily reconciliation.
What we left with
This was concept validation, not a launch readout. Operators could complete an embedded payment. All four in the synthesis said they would try it.
What the team actually took into build was a hybrid architecture they could defend, and a ranked usability backlog pointed at find / verify / recover — not another pass on the charge button.
n=4. Five sessions were planned; one column is missing from the synthesis, so every ratio on this page uses four. No production analytics or launch results were in the source material.