A customer calls to put a deposit on a $6,000 order. The salesperson takes the card number over the phone, writes it on a sticky note, walks it back to the terminal, and keys it in. On a busy afternoon that sticky note gets lost, and someone has to call the customer back and ask for the number again. On a worse afternoon the amount gets keyed with an extra zero, and a $1,000 order runs as $10,000.
None of this means anyone did anything wrong. It’s what happens when the system that tracks the sale and the system that runs the card are two different systems. The sale lives in one place, the payment happens in another, and someone carries the details between them by hand.
It gets busier the more ways your customers want to pay. A deposit on a card today, the balance a different way on delivery, a service customer who needs to pay from home. In a lot of stores each of those is a separate tool, a separate login, sometimes a separate vendor.
HomeSource Pay works differently. Every payment your team takes runs through the order inside HomeSource, so the payment is part of the sale, not a separate event someone has to record against it later.
Every payment method on the same screen
Retailers don’t take just one kind of payment. A customer pays a deposit on a card today and the balance a different way on delivery. A service customer needs to pay from home. In most stores, each of those is a different tool, a different login, sometimes a different vendor.
HomeSource Pay handles them from the same place the order lives. Card, contactless, Apple Pay, and Google Pay all run at the counter, on the screen the order was built on. Bank-to-bank ACH payments can come off that same order too, a lower-cost option worth having on large tickets where card fees take a real bite out of margin.
Whatever method the customer chooses, the payment posts to the right order and the right customer record on its own. Open balances update the moment it processes, so accounts receivable reflects what’s actually owed right now, not what was owed at the last batch.
Deposits and balances without the phone call
Deposits and balance-due payments are where a lot of cash gets stuck. The unit is ready, the customer owes the balance, and now someone has to call them, read a card number over the phone, and key it in. It’s slow, it’s a security risk, and it’s easy to put off. Balances that should clear in hours sit for days.
Send for Payment changes that. From any order, your team sends the customer a secure payment link by text or email. The customer pays on their phone in a few seconds, and the payment lands on the right order automatically. Nobody reads a card number aloud. Nobody retypes anything.
It also fits how large-ticket sales actually run. Plenty of them start with a deposit and finish weeks later, when the unit comes in. Take the deposit today, collect the balance when the order is ready, and that second payment posts to the same order without chasing down card details all over again. The money you’d normally have to call for clears while the customer is still thinking about the purchase.
When money has to go back
Refunds are the other half of managing payments, and they’re usually where the manual work gets worst. A delivery shows up dented and you credit the customer fifty dollars. A customer changes their mind before the unit ships. In a disconnected setup, that means finding the original charge on the processor, running the refund there, then remembering to record it against the order so the account still lines up.
In HomeSource Pay the refund is tied to the payment it’s reversing, because the payment lives on the order. The money goes back to the same card, and the order and your accounts receivable update together. Partial refunds work the same way, so crediting fifty dollars against a fully paid order doesn’t mean unwinding the whole thing. The credit posts where it belongs on its own.
Why it all connects back to the books
Because HomeSource Pay lives inside HomeSource CBMS, the payment doesn’t stop at “approved.” It flows where it needs to go. The sale updates inventory, the balance updates AR, sales tax collected flows through to the general ledger, and a complete payment history sits on the customer’s profile where anyone can find it. One vendor, one place to look across every register and every location.
That’s the difference between a payment processor bolted onto a POS and a payment platform built into the system that runs the store. One leaves your team carrying payments between two places. The other keeps every payment on the order it belongs to, from the first deposit to the final receipt.
What this changes day to day
Think about the last week on your sales floor. Count the times someone read a card number off a sticky note, logged into a second system to run a different kind of payment, or called a customer to collect a balance that had been ready for days.
That’s the work that goes away when the payment and the order are the same record. Take the deposit at the counter, send a link for the balance, accept ACH on the large tickets, and handle the refund against the original charge. Every one of them from the order itself, posted where it belongs, without anyone keying it twice.
