Someone says yes to a commission and you need to take some money now and the rest later. Search for how to set that up and every result is a forum thread inside one platform — a Square seller asking how to split a sale, a Shopify thread about deposits on draft orders, a Miva merchant arguing with a plugin. Nobody has written the version that starts before you have picked a platform, which is the order the decision actually happens in.
The short version
A deposit system is not a feature you turn on. It is a mechanic for splitting one payment into two, plus a place that remembers what each half was for. There are four common mechanics — two invoices, a deposit product, a partial payment, a payment link — and a lot of this market simply uses chat and a bank transfer. All of them can take the money. Only one question decides whether you can answer "what's still owed on this order" in six weeks: does anything tie the two payments back to the same job.
What a deposit system actually has to do
Strip away the platform, and a deposit system has exactly three jobs. Take a partial payment now. Say clearly what that payment is for and what is still owed. Leave the rest of the money visible — as an amount, against a date, attached to a specific order — rather than as something you are trusting yourself to remember.
Every mechanic below does the first job. Most of them do the second badly, on a receipt or a listing description you have to write by hand. Almost none of them do the third at all, because the tool that took the payment usually was not built to track an order that stays open for weeks after the money moves. That gap — not the payment itself — is what this article is actually about.
The percentage is a separate decision from the mechanics, and it gets one line here on purpose: how much deposit to charge works through it by category and lead time. This piece assumes you already have a number and need a way to collect it.
Four ways to split a payment, and what each one leaves behind
Whatever platform or none you sell through, the mechanic you reach for is almost always one of these four. They differ in effort and in what they cost to run, but the column that matters is the last one: what exists afterwards, once the deposit has landed and you have moved on to the next order.
Two invoices
Send an invoice for the deposit when the order is agreed, and a second invoice for the balance when the piece is ready. It works on any invoicing tool, needs no special feature, and is the closest thing to a universal answer. What it leaves behind is two documents that reference the same job only if you typed the same reference on both — nothing enforces that, and nothing notices if you forget.
A deposit product
List the deposit itself as something the customer can buy — a product, a service listing, a fixed-price line item — separate from the finished piece. This is the standard workaround on marketplaces and storefronts that have no deposit field of their own. It leaves behind two ordinary sales, weeks apart, each looking like a complete transaction with no field anywhere saying one was half of the other.
A partial payment
Some platforms let you split one checkout into two charges natively — a percentage collected now, the rest collected or invoiced later, inside a single order record. Where it exists it is the cleanest of the four, because the platform's own admin keeps one order instead of two. It tends to be gated to a higher-tier plan, and it still stops at the payment: the order record it leaves behind knows what was collected, not what the piece cost you to build.
A payment link
Generate a link for whatever amount you set, and send it by email, chat or text. It is the most flexible option and the least structured one — nothing about the link itself says whether it is a deposit, a balance, or the full price, so that has to live in the message you send alongside it. What it leaves behind is a paid transaction with an amount and a date, sitting in your payment processor's dashboard with no reference back to the order unless you put one in the description field yourself.
| Mechanic | What it takes | What it leaves behind |
|---|---|---|
| Two invoices | An invoicing tool or template, sent once at order and once before delivery | Two documents referencing one job number, if you remember to reuse it — nothing ties them together automatically |
| A deposit product | A second product or listing priced at the deposit amount | Two separate sales in your storefront, weeks apart, with no field saying one was half of the other |
| A partial payment | A platform feature that splits one checkout into two charges | One order in that platform's admin, but usually gated to a higher plan and blind to what the piece cost you |
| A payment link | A link for whatever amount you set, sent by email, chat or text | A paid transaction with an amount and a date, and no built-in place to note what it was a deposit toward |
Read that last column again. None of the four mechanics answer "what is this order's balance, right now, without me checking" on their own. That is not a criticism of any of them — a payment tool's job is to move money, not to remember why it moved. It just means the mechanic you pick decides how much you have to remember by hand afterwards.
Whichever mechanic collects the money, see the deposit and the balance on one order — not scattered across invoices and links.
See how it worksChat and bank transfer: how most of this market actually gets paid
None of the platform threads mention this one, and it is the most common mechanic of all for independent makers. A customer messages you on Instagram, WhatsApp or email, you agree a price and a deposit in the conversation, and they send it by bank transfer. No invoice, no checkout, no product listing — just a number, an account, and a message describing what it is for.
It works because it costs nothing and asks nothing of the customer they do not already know how to do. It has one real weakness: the description of what the payment is for lives only in the chat thread, which is easy to lose and impossible to search across forty orders. The fix is not to abandon the mechanic — it is cheap and it works — it is to write down, at the moment the transfer clears, which order it belongs to and what it covers, somewhere other than the chat app. That single habit is the difference between a bank transfer system that scales to thirty open orders and one that quietly falls apart at twelve.
Shopify, Etsy, Square: what each one actually gives you
The mechanics above are generic. The moment you sell through a specific channel, that channel decides which ones are available to you and which are blocked.
On Shopify, native deposits and partial payments exist but are documented as a higher-tier feature; most stores on standard plans use the deposit-product workaround instead, and each route leaves a different mess behind in the admin. How to take a deposit on Shopify covers the plan line and the workarounds in full.
On Etsy, there is no deposit field at all — the platform's own tool for this is the private custom listing, and sellers take a deposit by sending two of them in sequence, one for the deposit and one for the balance. Taking a deposit on Etsy walks through what that costs in fees and what the split leaves in your Sold Items page.
On Square, sellers run into the same question on Square's own forums, and we have no page of our own on it. The four mechanics above are the answer there too: ask of any invoicing or checkout feature whether it splits one order into two payments, and what it calls the result afterwards.
The confirmation the customer gets
Whichever mechanic collects the deposit, the customer gets something back — a receipt, an emailed invoice, a payment confirmation from whatever processor moved the money. On a made-to-order piece, that confirmation matters more than it would on a retail sale, because it is often the only written record either side has of what was agreed.
A generic payment receipt says an amount and a date. It does not say what is being made, what is still owed, or when the piece is expected — and on a deposit paid in month one for a delivery in month three, those are exactly the details that get fuzzy in the customer's memory first. The receipt is doing the job a contract would do in a market where most sellers do not have one, so it is worth treating as more than a formality.
The other option is to send something that stays current rather than a document that is accurate only on the day it was issued. A link the customer can reopen at any point shows what has actually been paid and what remains — a snapshot that updates itself instead of a PDF that is quietly wrong the moment a second payment lands. This public order page is a live example: it shows the customer what has been paid, what is still owed, and the payment instructions for the rest — with any web address in those instructions rendered as a clickable link, rather than text they have to copy by hand.
When the deposit arrives short, or in two transfers
Two situations come up constantly and neither one is a failure of the system — they are the reason a "paid or not paid" checkbox stops working the moment real customers are involved.
- It arrives in two transfers. A customer sends part of the deposit now and the rest a few days later because that is what they have available. Record each transfer as it lands, against the same order, rather than waiting for the total before writing anything down. The order should show a partial amount collected the moment the first payment clears, with the remaining balance reflecting exactly what is left — not a blank entry until the second transfer shows up.
- It arrives short. The agreed deposit was $900 and $850 landed — a fee was deducted somewhere, a currency conversion rounded down, or the customer simply sent the wrong number. Confirm the real figure with the customer in writing before you decide whether production waits for the difference or starts anyway, and update the balance to reflect what was actually collected rather than what was quoted. The one mistake worth avoiding is treating the shortfall as close enough and letting the balance figure quietly drift from reality — it is exactly the kind of gap that surfaces months later as "why does this order still show $50 outstanding."
Both cases point at the same underlying need: a place that records a deposit and a balance as two separate, updatable facts against one order, rather than a single "paid" flag that only has two states. How to record a deposit and the balance goes through exactly that model — this article is about how the money gets split and collected; that one is about how it gets written down once it has.
A deposit paid in two transfers, or short by a rounding error — see it reflected on the order the moment it happens.
See how it worksThe bottom line
Pick the mechanic your channel makes easiest — two invoices, a deposit product, a partial payment, a payment link, or plain chat and a bank transfer all work. The choice between them is mostly about effort and fees, and none of them is wrong. What decides whether the system holds up past a handful of orders is whether anything ties the two payments back to one job once the money has moved, and whether a short or split deposit updates the balance instead of leaving it stale.
The mechanic takes the money. Something else has to remember what it was for — and that part does not come free with any of the four.
Frequently asked questions
What's the simplest way to start taking deposits if I have nothing set up?
Two invoices or two payment links, sent in sequence: one for the deposit when the order is agreed, one for the balance when the piece is ready. It needs no app, no plan upgrade and no new account. Everything else in this article is a way of making that same idea less manual once you have more than a handful of orders open.
Do I need a merchant account or a card processor to take a deposit?
No. A bank transfer against clear instructions is a complete deposit system on its own, and it is what most of this market actually uses. A processor buys you a card option and, on some platforms, a nicer checkout — it does not make the deposit more real or more enforceable than a transfer with a receipt.
Should the deposit invoice and the balance invoice be the same document?
No — keep them separate. One invoice per payment, both referencing the same order, is easier to reconcile than a single invoice you edit twice. What has to be consistent is the order reference on both, so a bank statement or an accounting export can be matched back to one job rather than two unrelated payments.
What if the customer sends the deposit in two transfers instead of one?
Record both as they land against the same order rather than waiting for the total to arrive before you write anything down. The order should show a partial amount collected and a smaller remaining balance the moment the first transfer clears, not a blank until the second one shows up.
What if the deposit arrives short of what was agreed?
Treat the shortfall as a fact about the order, not a rounding error to absorb. Confirm the number with the customer in writing, decide whether production waits for the rest or starts on what has cleared, and make sure the balance figure reflects the real amount still owed — not the amount you originally quoted the deposit at.
Is a payment link safer than a bank transfer for the customer?
It is usually more familiar, not more safe. A payment link runs through a processor with its own dispute and refund mechanics; a bank transfer settles directly and is harder to reverse either way. Neither replaces a clear written description of what the payment is for — that is what actually protects both sides if the order is ever questioned.
Do I need different systems for Etsy, Shopify and everything else, or can I use one?
The channel decides how the money is collected — Etsy and Shopify each have their own constraints — but it does not have to decide how the order is recorded. Whichever mechanic takes the payment, the order itself can carry the same two facts everywhere: what has been paid, and what is still owed.
Every deposit and balance, on the order they belong to, however the money was collected.
See Ordamo