When to Take the Buyer's Money: Payment Capture and Authorization

Between "the customer clicked Pay" and "the money is in your account" sit several days and at least one decision that nobody usually makes on purpose. If you do not make it yourself, the default configuration of your payment gateway makes it for you.

The bill for that arrives later, and it arrives in three forms: orders shipped against money that never came in; authorizations that expired before the seller managed to send the goods; and customers who see two holds on their account for a single purchase. All three come out of the same conceptual mix-up.

Payment capture is the moment the buyer's money leaves their account, and authorization is only the bank's consent for that to happen later. On a marketplace, the gap between the two is where the operational problem sits: an authorization lives for days, while an order can wait on a seller for longer than that. Capture at the wrong moment, and ordinary cancellations start arriving as refunds.

This article breaks down:

• What is payment capture, and how does it differ from an authorization?
• Which 4 moments can you capture the money at?
• Why is your operational clock longer than the authorization clock?
• Which payment methods have no authorization at all?

Key insights

• Payment capture is the moment the money leaves the buyer. An authorization only reserves it, and it expires.
• An authorization lives for days, and a marketplace's operational clock is usually longer than that.
• There are four moments to capture money at: order placement, seller acceptance, shipment, and delivery. Each shifts risk and cash flow somewhere else.
• A cart with several sellers forces a choice: one capture for the whole cart, or one per seller.
• Several payment methods have no authorization and capture split at all, so one policy for every method will break on them.

What is payment capture and how does it differ from an authorization?

Three different things happen inside a card payment, and only one of them is a movement of money.

1. Authorization is a question put to the customer's bank: is there €1,000 on this card, and do you agree to place a hold on it? An answer of "yes" does not move a single cent. It lowers the customer's available limit and creates a reservation that has an expiry date.

2. Capture is an instruction: take that money now. This is the first point at which money moves. Until then, you hold a promise rather than funds.

3. Settlement is the moment the money truly lands in the account. That usually happens a day or a few days after the capture.

The expiry date is the crux. An authorization lives for days rather than weeks.

For card payments online, the window is typically somewhere around a week; at a payment terminal it is shorter, and in some industries and for some methods it is longer. The exact number depends on the card scheme, on your business category, and on your payment provider.

That is a question for the vendor rather than for an article. What matters here is the order of magnitude, because that is what decides whether your operational process fits inside the window at all.

What happens once the deadline passes: the authorization expires, the hold on the customer's account disappears, and the capture can no longer be made. You have to authorize from scratch, which means asking the customer for the card a second time, a week after the purchase, and hoping it works this time.

On top of that, some card schemes charge a fee for authorizations that were never settled, so sloppy management of this cycle carries a unit price as well.

At which of the 4 moments do you capture the payment?

I run one example through the whole article: a €1,000 cart at a 12% commission, which is €120 of your revenue. There are two sellers in that cart: €700 and €300.

1. At order placement

The simplest option and the safest for you: you have the €1,000 before anyone has done anything. The price is that every cancellation and every rejection by a seller turns into a refund rather than just a void.

The money goes out and comes back, that costs a fee, it lands in your refund statistics, and the customer sees two lines on the statement instead of none.

2. At seller acceptance

A reasonable compromise: you capture only once someone has confirmed that the goods exist. There is one condition: the seller has to have a hard time limit for accepting, and that limit has to fit inside the authorization window.

3. At shipment

This is the default choice for goods sent to the buyer, and not by accident. Card scheme rules for shipped goods lean toward "capture when the goods leave", and a dispute over goods not received is one of the most common reasons for a chargeback.

A capture made at the moment of handover to the carrier is also the easiest one to defend with evidence.

4. At delivery

The friendliest option for the customer and the worst one arithmetically. The expiry date comes back here: more time usually passes between order placement and a confirmed delivery than an authorization stays alive.

In practice, you cannot do this on a single card authorization.

How do the 4 moments compare on risk and cash flow?

Why is your operational clock longer than the authorization clock?

This is where a marketplace differs from an ordinary store. In your own store, the road from order to shipment is yours, and it is short.

In a marketplace, it is made of three stretches that belong to other people: the seller's time to accept, plus the preparation time they declared, plus the time it takes your system to learn that the parcel actually left.

Let us count it on our order. The seller has two business days to accept, declares two days to prepare the shipment, and the tracking number reaches the system the next morning.

If the order came in on Thursday, you run the "at shipment" capture on Wednesday. That is seven calendar days after the authorization.

This is exactly the boundary at issue. One day of delay on the seller's side and you have an accepted order, goods on their way, and an authorization that can no longer be captured.

Capture at delivery comes out even worse if your delivery signal is an automatic status change after a timer runs out. Platforms do this as standard: two or three weeks after shipment, the order flips itself to "received", no matter what really happened to the parcel.

A capture wired to a signal like that means trying to take the money several weeks after the purchase, on an authorization that expired long ago. That is why integrating with parcel tracking is not a convenience for the customer but a condition for the moment of capture and the moment of payout to make any sense at all.

Three ways out of this trap:

1. Shorten the operational clock (hard acceptance limits, short preparation times, picking up the shipment event from the courier integration rather than from a manual click).
2. Move the moment of capture earlier: put it at seller acceptance instead of at shipment.
3. Extend the authorization, if your provider and your category allow it; that is something to check.

Do you take the money once, or per seller on a split order?

Our €1,000 cart is two parcels from two sellers, and they will leave on different days. There is one authorization for €1,000, because the customer paid once.

There are potentially two captures: €700 when the first parcel leaves, and €300 when the second one does. The default behavior of many payment providers is hostile here: a partial capture automatically releases the rest of the authorization.

You capture €700, and the cover on the remaining €300 disappears in the same second. The ability to run several captures against one authorization usually exists, but it is sometimes switched on by request, and not for every payment method.

This is one question you put to your software vendor and to your payment provider at the same time, because the answer has to match on both sides. There are three variants: several captures against one authorization (the cleanest), one capture of the whole amount at the first shipment (simple, but you are capturing for goods that have not left yet), or a separate authorization per seller already at the payment stage (the safest operationally, but the customer sees two holds on their account for one purchase and calls to ask why).

The same mechanism settles what happens when a single line is canceled. The customer drops the €300 item before anything has left.

If you have not captured yet, you reduce the capture to €700, and nothing has happened. If you have already captured the whole amount, you issue a refund, you pay for it, and you still have to settle what happens to the commission on that line.

The moment of capture therefore decides how many of your cancellations are cheap and how many are expensive.

Which payment methods have no authorization at all?

Everything above applies to cards and to some deferred payment methods. A good number of popular methods have no split between authorization and capture at all.

Instant bank transfers, paying with a code from a banking app, some local methods, and direct debit work in a way where the money is either taken right away or not there at all. There is nothing to hold and nothing to release; the only "undo" is a refund.

Two things follow from that.

First, you do not have one capture policy. You have as many policies as you have families of payment methods.

An order paid by card and an order paid by instant transfer sit on two different money timelines, even though they look identical in the panel. Canceling the first is free.

Canceling the second costs you a refund.

Second, and this is a real mistake from practice: with redirect-based methods, an order can come into existence before the payment is confirmed. The customer clicks Pay, drops into their bank, and vanishes there.

On your side, an order sits in an in-between state: not paid, but not rejected either. If the seller sees it as an ordinary order to fulfill, they will ship goods against money that never arrived.

The "paid" signal and the "you may ship" signal have to be the same signal, and the platform has to control it rather than the seller.

How does the moment of capture affect cash flow, payouts, and disputes?

1. Cash flow

Moving the capture three days later, on €3 million of monthly turnover, is roughly €300,000 permanently frozen in transit. That money is not lost, but it never sits in your account.

If you operate in a setup where the money passes through you, that is your working capital. If you operate in one where the payment provider splits the payment on their side, it is the sellers' working capital, and they will run that number.

2. Payouts to sellers

You cannot pay a seller money you have not captured. The moment of capture is therefore the lower bound of the entire payout cycle: a late capture, plus a payout cycle twice a month, plus a grace period for returns can stretch the road from purchase to a transfer landing at the seller into several weeks.

This is the most common reason sellers walk away from young platforms.

3. Revenue recognition

If the commission is charged at order placement and the capture happens at shipment, you have a window in which you are reporting your €120 on a transaction that may still not happen. Pulling the order back then has to reverse both entries at once.

4. Chargebacks

The further the moment of capture sits from the moment of shipment, the harder the dispute is to defend. The evidence is the capture date set against the shipping date.

How do you choose when to take the buyer's money? 8 questions

1. How long does the road from order to handover really take at your company? Count it in calendar days, in the worst case rather than on average. If that worst case comes close to the authorization window, capture at shipment is a choice in name only.
2. What share of orders is canceled or rejected before shipment? If it is high, capture at order placement is expensive. Every one of those cases is a refund with a fee and an entry in the statistics.
3. Can you detect a shipment automatically? If your signal is a seller clicking a button, your clock depends on somebody else's diligence.
4. Do you even know when an authorization has expired? If the system is not watching for that actively, you will find out from a customer complaint or from a shortfall in the settlement.

Four questions for the platform vendor, worth asking at the demo:

• Which moments of capture do you support natively, and can they be set differently for different categories or different sellers?
• What does the system do when an authorization expires before the moment of capture? Does it raise an alert, does it retry, or does it simply leave the order hanging?
• On an order split between two sellers, do you capture once or per parcel, and what happens to the rest of the authorization after a partial capture?
• Can a seller see the order and ship the goods before the payment is confirmed?

Which mistakes do operators make about payment capture?

1. Treating an authorization as money

And everything that comes with it: reporting sales off authorizations, promising a seller a payout from an order you have not captured, counting it as revenue.

2. Setting the moment of capture without counting the operational clock

"At shipment" is the textbook answer and the wrong one if your longest time to handover exceeds the authorization window.

3. Shipping before the payment is confirmed

A classic with redirect-based methods. It costs you the goods, and it is entirely avoidable on the status configuration side.

4. One policy for all payment methods

Methods with no authorization and capture split need different handling of cancellations, and no amount of terms and conditions gets around that.

5. Assuming that a void is instant

A released authorization usually disappears from the customer's account after a few days, depending on their bank. Your customer service has to be able to explain this before the first customer writes in to say you charged them twice.

What do you still have to settle yourself about payment capture?

It does not settle whether your model lets you hold the buyer's money between the capture and the payout to the seller. That depends on whose funds they are and whose account they pass through, and it is a question for a lawyer rather than for a software vendor.

It also does not settle the specific authorization windows and capture rules for your category and your payment methods. I have given orders of magnitude and mechanisms, because those are the only parts that do not change.

Confirm the values themselves with your payment provider, and the consumer consequences with a lawyer. They differ between card schemes, between seller categories, and between countries, and they are sometimes negotiable.

Two things stay outside the scope here and come back later in this series: refunds, meaning what happens once the capture has been made and has to be reversed, and chargebacks.

Summary: When should you take the buyer's money?

Count your operational clock in calendar days at its worst, compare it with how long an authorization survives at your provider, and capture at the last moment that still fits inside it.

Then check the methods that have no authorization separately, because they need their own cancellation path. Talk to a marketplace expert if you want to walk your own timings through.

Frequently asked questions on payment capture

What is payment capture?

Payment capture is the request that actually moves the money from the buyer's account. Before it, an authorization holds the amount and confirms the card can pay; after it, the funds are on their way to the payment provider.

The two are separate events with separate timings.

What is the difference between authorization and capture?

An authorization is consent with an expiry date. A capture is the charge.

An authorization reserves the amount for a limited window, typically days for an online card payment, and lapses if nobody captures it. Settlement, a third event, is when the provider actually pays out.

When should a marketplace capture the payment?

At the last moment that still fits inside the authorization window. Capturing at order placement is safest for cash flow and worst for cancellations; capturing at delivery is the opposite and frequently impossible, because delivery arrives after the authorization has expired.