How do I take deposits or payments online without a developer wiring anything up?

This page may contain affiliate links from which Blur Studio earns commissions.

This is a case where the instinct to "build something" often gets ahead of the actual need. Most businesses asking this question don't need a custom payment system, they need customers to be able to pay them without a phone call, an invoice, or a trip to a physical terminal. That's a solved problem already, and it's worth ruling out the simple answer before reaching for anything custom.

Start with a payment link, not an app

It's worth being specific about why this is the right default rather than just a cheaper one. A payment link is, functionally, a hosted page someone else maintains, secures, and keeps compliant with card-network rules on your behalf. Building your own payment page, even a simple one, means taking on at least some of that responsibility yourself, security updates, compliance requirements, handling edge cases like a declined card gracefully. None of that is impossible to manage, but it's real, ongoing responsibility that a payment link quietly removes from your plate entirely, for free, which is a genuinely good trade for most small businesses, not just a corner being cut.

Stripe Payment Links is free to set up, with no monthly fee, just standard card processing starting at 2.9% plus 30 cents per successful transaction. You create a link for a specific amount or a product, and send it by text, email, or post it anywhere you'd post a URL. No code, no developer, no app. Square offers a comparable option, with its own processing rates that vary and are worth confirming directly on its current pricing page, since the exact figure wasn't clearly published at the time I checked.

For a huge share of businesses asking this question, this alone solves the actual problem. A deposit request, a booking fee, a one-off invoice payment, all of these work fine as a payment link sent at the right moment, with zero technical setup beyond creating a Stripe or Square account. To take a deposit together with a signature, see how contractors can collect deposits and signatures in one step.

The step-by-step version

One more thing worth deciding before you start: how you'll actually send the link to customers in practice, since that's often the part people haven't thought through. Texting it directly after a quote call tends to get paid fastest, since it's immediate and hard to miss. Including it in an emailed invoice works well for customers who prefer a paper trail. Posting a generic link on your website works for walk-in-style payment but loses the personal nudge a direct message gives. Pick whichever matches how you already communicate with customers, rather than adding a new channel just for this.

1. Set up a Stripe or Square account if you don't already have one. This takes minutes and doesn't require any technical skill.
2. Create a payment link for your most common deposit or fee amount. If amounts vary, most platforms let you create a link where the customer enters the amount, or you can generate a fresh link each time.
3. Test it yourself with a small real payment before sending it to a customer, so you know exactly what they'll see and experience.
4. Add it to your quote, invoice, or booking message wherever a customer would naturally need to pay.
5. Only consider building something custom if a link genuinely can't do the job, for example if payment needs to trigger a specific action inside your own booking system automatically, rather than you manually confirming payment yourself.

When a link genuinely isn't enough

There's a real point where payment links stop covering the need: when payment has to be tied directly to a specific booking record, trigger automatic confirmation emails, update availability in real time, or flow into a larger system without anyone manually reconciling it. That's the point where a custom app with payments built in, through a platform like Emergent, starts to make sense, since it can wire the payment directly into your actual booking or job logic rather than leaving a manual step in between. Emergent's own pricing page doesn't state a specific fee structure for its payment integrations separately from its general credit system, so if you go this route, confirm directly how payment processing costs interact with your plan. For a small shop or bookings without a full build, selling a few products or bookings on your website without a full store is a simpler step.

What actually happens after a customer pays

Worth knowing before you send your first link: the money doesn't land in your bank account instantly. Standard payouts from both Stripe and Square typically take a couple of business days to reach your account after a successful payment, which is normal and not a sign anything's wrong. If a customer pays on a Friday evening, don't be alarmed that it's not showing in your bank balance by Saturday morning. Faster, same-day or instant payout options exist on some platforms, usually for a small additional fee, worth looking into specifically if cash flow timing matters a lot to your business, but the standard few-day delay is the default and the normal case for most small businesses taking occasional payments this way.

A worked example of each path

A home-repair contractor who wanted a deposit before scheduling jobs started simply: a Stripe Payment Link for a flat $50 deposit, sent by text after each quote call. No app, no integration, and it solved the actual problem, fewer no-shows, within the first week of using it. Once the work is agreed, how to collect payment after a contract is signed covers the next step.

A booking-based business with variable pricing and real-time availability needed something a link alone couldn't do: payment that automatically confirmed a specific time slot and updated the calendar the moment the customer paid, with no manual step for staff. That business built a custom booking tool with payments wired directly into the logic, which cost more and took longer to set up than a simple link, but genuinely solved a problem a link structurally couldn't.

Recurring payments versus one-off deposits

Everything above covers a one-off payment, a deposit, a single invoice, which is the most common case. If you actually need recurring billing, the same customer charged automatically every month, that's a slightly different setup, still usually achievable without custom development through Stripe's or Square's own subscription/recurring billing features rather than a one-off payment link, but worth knowing as a distinct feature to look for specifically rather than assuming a basic payment link handles it. Confirm which type of payment you actually need before picking a tool, since the simplest solution for a one-off deposit isn't automatically the simplest solution for ongoing recurring billing. Invoicing apps that handle deposits are compared in invoicing apps for contractors.

Common mistakes to avoid

• Building a custom payment flow before trying a link. This is the most common overspend in this whole area: solving a problem with custom development that a free link would have solved in minutes.
• Not testing the actual customer experience yourself. Pay your own link with a real small amount before sending it out. Seeing exactly what a customer sees catches confusing wording or a broken redirect before it costs you a real customer's trust.
• Forgetting refund and dispute handling. Know how to issue a refund through whichever platform you use before you need to, not during an awkward live conversation with an unhappy customer.
• Mixing up processing fees with any platform subscription fee. A payment link itself is free; the processing fee applies only when money actually moves. Keep these two costs separate in your own head when explaining pricing to anyone else in the business.

How I'd approach this

When someone asks me about taking payments online, my first question is always whether a payment link alone would actually solve their real problem, because it's free, fast, and the honest answer most of the time. I only build custom payment logic into an app when there's a genuine automation need behind it, payment tied to a specific record, a workflow that has to trigger automatically, not just "a payment page that looks nicer." If a link does the job, I'll tell you that directly rather than building something you didn't need.

A note on trust and presentation

One underrated detail: a payment link from a recognized processor like Stripe or Square often reassures customers more than a custom-built payment page would, precisely because people already trust those names from using them elsewhere. A brand-new, unfamiliar-looking payment form, even a well-built one, can actually create more hesitation at the exact moment you want a customer to feel comfortable paying. This is a genuine argument in favor of the simple link approach beyond just cost and speed: sometimes the boring, familiar option converts better specifically because it's boring and familiar.

When to skip building anything

If a payment link solves it, stop there. The main risk in this whole area isn't picking the wrong tool, it's building more than the problem actually requires and paying for complexity you'll never use.