The real problem with deposits and card payments

When you take a card payment, the card network rules โ€” not your refund policy โ€” determine what a cardholder can dispute and when. A customer who paid a deposit three months ago for a custom piece of furniture can still file a chargeback claiming non-delivery. If you cannot prove delivery happened, you lose โ€” even if your contract says the deposit is non-refundable.

This is not a flaw in your policy. It is how card dispute rules work. Visa and Mastercard treat each transaction on its own merits. A signed contract helps, but it does not prevent a dispute from being filed.

When authorization / capture actually works

Auth/capture is the cleanest deposit-like mechanism if your fulfillment window is short. You put a hold on the funds at booking, then capture when you deliver. The customer's bank reserves the amount without it hitting their statement as a completed charge.

The catch: Visa's standard hold window for most merchant categories is 7 days. Mastercard can extend to 30 days in some categories, but this needs to be confirmed with your acquirer. If your production time is 6 weeks, auth/capture does not help you.

Helcim and Stripe both support manual capture via API and dashboard. Moneris supports it through their hosted payment page and API integration. Shopify Payments supports it natively with a fulfillment-trigger capture setting.

Pre-orders: what Shopify and Stripe actually allow

Both Shopify and Stripe acknowledge pre-orders as a legitimate use case, but both have terms that can bite you. Stripe's terms require that you notify customers promptly if a pre-order will be significantly delayed and give them cancellation rights. Shopify Payments risk review watches for accounts where unfulfilled orders pile up.

Third-party pre-order apps (PreProduct, Crowdfunder, etc.) typically capture to Stripe or Shopify under the hood. The risk is still yours.

Deposit + invoice: when it works and when it breaks

For service businesses โ€” contractors, consultants, photographers, event planners โ€” charging a deposit at booking and invoicing the balance at completion is a normal pattern. The key is documentation: written scope, written timeline, written cancellation terms, and a signed acknowledgment before the deposit is charged.

For product businesses, this pattern is riskier. If the item is never delivered or arrives damaged, the deposit transaction may be disputed as "services not rendered" or "item not as described," regardless of what your invoice says about the balance being separate.

When to collect deposits by e-Transfer instead

If the deposit is large, the fulfillment timeline is long, and the customer relationship is established, accepting the deposit by e-Transfer avoids card-dispute exposure entirely. There is no chargeback mechanism on Interac e-Transfer. The tradeoff: there is also no buyer protection, which some customers will push back on, and you lose the convenience of card checkout.

This works best for B2B or repeat-customer scenarios where trust is already established. It is less suitable for e-commerce or first-time customers who do not know you yet. See our Interac online payments guide for more context.

Bottom line

There is no universal right answer. The safest deposit route depends on how long the gap is between charge and delivery, how well you can document the customer's agreement, and whether your processor has explicit support for your model. Build the workflow to match the risk โ€” not the other way around.