Use case: collect deposits
Collect deposits before the work starts
Booking deposits, project deposits, travel fees, and retainers are not just a payment problem. They are an operations problem. Flint gives you a fast hosted path when speed matters, and a stronger order-backed path when the balance and lifecycle need to stay cleaner over time.
Reduce no-shows
If the customer has not paid anything yet, the appointment is still soft. Deposits turn vague interest into an actual commitment.
Start work after money moves
Freelancers, contractors, and mobile pros should not start a project, drive to a site, or reserve a slot before the buyer has skin in the game.
Stop financing the job yourself
Deposits protect cash flow when materials, labor time, or travel costs land before the final invoice ever gets paid.
Choose the right path
Deposit collection is not one workflow
The buyer intent is the same, but the implementation path is not. Some teams just need the fastest way to get money before the appointment. Others need the payment flow to stay tied to a stronger commerce record.
Reusable payment links
Best when the immediate problem is simple: collect money before the appointment, before dispatch, or before kickoff without building a custom checkout.
Orders plus hosted checkout
Best when the deposit and the remaining balance need a cleaner operational trail. Flint's order model is the stronger fit when you care about shared history, balances, and downstream reconciliation.
Real scenarios
Where deposit workflows actually show up
This intent cuts across multiple verticals. The common thread is simple: the business pays a real operational cost if the buyer does not commit early.
Why Flint
Built for deposit workflows that have to survive real operations
The first payment matters, but it is not the whole job. The harder part is what happens after the buyer pays, when you need follow-up collection, intake details, or cleaner records.
Hosted payment surfaces
Flint gives you shareable payment links and hosted checkout pages, so you can collect the deposit without building a checkout form first.
Structured line items
Represent the payment clearly: booking deposit, travel fee, kickoff retainer, or reservation payment instead of a vague memo field.
Buyer intake data
Collect email and custom checkout fields so the deposit flow captures the details you need, not just the payment.
Flexible checkout controls
Redirects, coupon support, tipping, quantity controls, and buyer-facing copy are already part of the payment-link and checkout-session surface.
Cleaner reconciliation
When you move beyond a one-off request, Flint's order model gives you a better foundation for balances, refund context, and payment history.
A more durable workflow
The goal is not just collecting the first payment. The goal is avoiding the cleanup work that happens when the deposit and the rest of the lifecycle drift apart.
How it stays clean
The operational problem is what happens after the deposit
Teams usually do not struggle with requesting money. They struggle with what comes next: remaining balances, follow-up collection, changed scope, cancellations, and refunds.
Decide whether you need speed or shared state
If you just need to collect money before the work starts, use a payment link. If the remaining balance and later lifecycle matter, start from an order-backed flow.
Collect the first payment on a hosted surface
Text or email the buyer a Flint-hosted payment page. They pay from their phone without creating an account or downloading an app.
Use the right record for the next step
Simple deposit flow: keep using the reusable payment surface. Connected commerce flow: use the order and hosted checkout path as the operational source of truth.
Handle changes without collapsing into spreadsheet work
Reschedules, refunds, and follow-up collection are easier when the payment flow is deliberate up front instead of improvised after the first charge succeeds.
For developers
Start from the workflow, then pick the surface
The docs app already organizes Flint around workflow paths. The deposit story should do the same. Payment links are the shortest route live. Orders and checkout sessions are the next step when you need more durable commerce state.
# Fastest path
POST /v1/payment-links
# More structured path
POST /v1/orders
POST /v1/checkout-sessions
GET /v1/orders/{order_id}
# Use the path that matches the workflow:
# payment links for speed
# orders + hosted checkout for cleaner shared statePayment Links API
Reusable hosted payment pages for the fastest route to deposit collection.
Orders API
The central commerce record when payment state, balances, and follow-up actions matter.
Checkout Sessions API
Launch hosted checkout from a quick-pay input or an existing order.
Accept Your First Payment
End-to-end guide when you want the shortest implementation path into production.
Common questions
Questions teams ask before they roll deposits out
Can I use Flint just to collect booking deposits?
Yes. That is one of the cleanest payment-link use cases. If the main job is confirming an appointment or reserving time, Flint can handle that without a custom frontend.
Can I collect the remaining balance later?
Yes, but the right path depends on how tightly you want the workflow tied together. Reusable payment links are the fastest path. Orders plus hosted checkout are the stronger fit when you want a more connected commerce record.
Do I need a website?
No. You can create a Flint-hosted payment surface and send it directly by text, email, or any other channel you already use with customers.
Can I collect customer details with the deposit?
Yes. Flint supports buyer email collection and payment-link custom fields, which is useful when the deposit is also the intake step.
Why not just send an invoice or a peer-to-peer payment request?
Invoices can work when the buyer expects formal approval or back-office processing, and Flint supports that path too. But for many deposit workflows, a payment link converts faster and keeps the collection moment closer to the actual booking event. Peer-to-peer payment requests usually fall apart first because they are hard to standardize and reconcile.
What if refunds or reschedules happen often?
That is exactly when the workflow matters. The more often you revisit a payment after the first charge, the more valuable a cleaner order-backed operating model becomes.
Keep Exploring
Related pages for deposits, commitments, and faster collection
These are the next pages to follow if the deposit workflow turns into a broader hosted-payments or service-business decision.