Deposit workflows usually show up when a business is trying to solve one of three problems:
- Reduce no-shows.
- Get commitment before work starts.
- Stop financing the job out of cash flow.
That is why deposits should be framed as a payment-flow problem, not just an invoicing problem.
The real job behind a deposit#
The deposit itself is rarely the hard part.
The harder questions appear one step later:
- How does the deposit connect to the final balance?
- What happens if the job scope changes?
- Where do cancellations and refunds live?
- Which record should support or finance trust later?
If those answers live in separate tools, spreadsheets, or internal notes, the workflow collapses as soon as volume grows.
Choose the payment channel by timing, not habit#
Best first move
Payment links
Payment links win when the main requirement is speed.
- Send a hosted deposit page by text, email, or proposal.
- Get commitment before the appointment, dispatch, or kickoff.
- Avoid building a frontend before you know the workflow is real.
Use for AR
Invoices
Invoices are stronger when the business expects delayed payment or receivables behavior.
- Net terms
- Back-office collections
- Payment after work is already underway
That is a different timing model than "pay before I show up."
Use onsite
Card readers
Card readers solve card-present collection.
They are useful when the money is supposed to move at the truck, at the counter, or immediately after the walkthrough.
They are not the cleanest default for pre-appointment commitment.
Use when custom UX matters
Embedded checkout
Embedded checkout is the right move when the product experience itself is the feature.
It is usually too much surface area when the immediate problem is just validating whether customers will pay a deposit before the work starts.
The design question that appears second#
Payment links solve the collection moment first.
The next question is whether the deposit remains an isolated payment or becomes part of a real commerce record that can also hold:
- The remaining balance
- Scope changes
- Cancellations
- Refunds
- Support history
Do not blur the surfaces
Today Flint's public Payment Links API creates hosted payment pages around line_items or plan_id.
If you need one long-lived record for deposit plus remaining balance, make the order your durable source of truth and use a hosted checkout surface around that order when needed.
A practical Flint pattern#
The cleanest progression is:
Validate the workflow with a hosted deposit link#
Use a payment link when the fastest way to prove the workflow is a shareable hosted page with a fixed deposit amount.
Capture the customer context you will need later#
Require email, use descriptive line-item names, and attach metadata so the deposit is not just an unlabeled money movement later.
Move the lasting state to the order when balances matter#
Once the deposit has to reconcile against a later balance, the order should hold the financial truth instead of a disconnected invoice or spreadsheet.
Keep the buyer flow hosted#
You can still use hosted checkout when the buyer needs a clean payment page. The important change is what object owns the state.
Handle reschedules and refunds against one timeline#
That is where teams stop losing confidence in what has been paid, what is still due, and what changed.
Fast path versus durable path#
Use the Payment Links API when the immediate job is getting a hosted deposit page live with minimal frontend work.
{
"name": "Booking deposit",
"description": "Confirms the appointment before dispatch",
"line_items": [
{
"key": "booking_deposit",
"name": "Booking deposit",
"quantity": 1,
"amount_money": { "amount": 7500, "currency": "USD" }
}
],
"customer": {
"require_email": true
},
"redirects": {
"success_redirect_url": "https://example.com/booking/confirmed"
},
"metadata": {
"workflow": "deposit",
"service_type": "onsite"
}
}
Use the Orders API when the deposit and the remaining balance both need to live on one lasting record.
{
"customer_id": "cus_xxx",
"line_items": [
{
"name": "Project deposit",
"quantity": 1,
"unit_price_money": { "amount": 50000, "currency": "USD" }
},
{
"name": "Remaining project balance",
"quantity": 1,
"unit_price_money": { "amount": 150000, "currency": "USD" }
}
],
"metadata": {
"job_id": "job_2041",
"deposit_stage": "booking"
}
}
What operations eventually need to see#
Collection surface
Hosted deposit link
The hosted link should stay fast and obvious:
- Clear link name
- Fixed deposit amount
- Buyer email required
- Reusable URL
- Completion count
That is what helps the team collect the deposit now.
Durable state
Order record
The lasting record should explain the workflow later:
- Subtotal
- Amount already paid
- Balance still due
- Activity history
- Refund context
That is what helps support, finance, and operations trust the workflow after the first payment lands.
Where this pattern shows up#
Calendar time
Appointments
Booking deposits for salons, wellness, consulting, and other schedule-driven services.
Truck roll
Field service dispatch
Commitment before a team drives to the site, then final balance collection after the walkthrough or completion.
Work begins
Project kickoff
Freelancers, contractors, and agencies collecting upfront commitment before the actual work starts.
Mobile service
Travel fees
Notaries and other mobile professionals collecting a non-trivial travel fee before they spend time on the road.
Build the workflow from these docs#
Payment Links API
Create hosted payment pages quickly when the immediate goal is proving the deposit workflow.
Orders API
Use orders as the durable source of truth once deposits need to connect cleanly to later balances.
Checkout Sessions API
Use hosted checkout around an existing order when the workflow grows beyond a standalone link.
Accept Your First Payment
The shortest implementation path for moving from an order into a working hosted payment flow.
Keep following the cluster#
The short version#
Use payment links when speed matters most.
When the deposit has to connect cleanly to a later balance, move the durable state to orders instead of layering more invoice logic on top of a hosted link.