Name auth, capture, and settle before checkout ships.
Order placed, says the screen. Somewhere else the card hold may or may not exist and the stock may or may not be reserved. When those feel like one moment and are really several, you end up shipping what you never captured.

Before checkout ships, place authorize, capture and settle on a timeline alongside inventory hold and fulfillment start, and name the abort if any gate fails. A successful button press is not a capture, and a capture is not settlement. Leave a gate unplaced and you will promise goods or money you have not actually taken.
The button is not the money
A buyer confirms. The interface says the order is placed. Somewhere else, a hold on the card may or may not exist, the inventory may or may not be reserved, and fulfillment may or may not be allowed to start. If those are the same moment in people’s heads and different moments in the systems, you will ship what you did not capture, or capture what you cannot ship, or tell a buyer the sale is final while the money is still only a request.
This note is the TWIMCO Payment Capture Timing Spec. It places three money gates—authorize, capture, and settle—against two operational gates—inventory hold and fulfillment start—and writes the abort when a gate fails. It does not choose a processor, a fee, or an amount. It does not tell you a correct number of days. Those belong to your commercial terms and your provider’s actual states, which you must name from their documentation, not from this page.
There is no live timing tool to fill the spec. Do not treat any unpublished URL as a product you can open.
This is not a spec for whether the price on the page matches the price charged. That is a different argument about amounts. This page is about when each money state is allowed to become true relative to the goods. It is also not a deal-desk settlement clock for when a contract closes. Here “settle” means the provider state you are willing to call settled for this checkout, in your own words, after you have looked up what your provider means by that word.
On Paddle8, TWIMCO built the auction and marketplace, the real-time bidding, and a shipping API from route knowledge that had lived in spreadsheets. The public line is that the winning bid was only the beginning: the artwork still had to move, and the platform needed operational knowledge to do that. Payment timing is the commercial cousin of that lesson. The visible moment—the bid, the buy button—is not the end of the obligation, and it is not automatically the moment money is captured or the moment a crate may move. The public case does not describe Paddle8’s processor, auth windows, or capture rules. Do not invent them. Use the case as the reason to put post-sale gates on paper before checkout copy calls anything final.
If you cannot point to where authorize ends and capture begins in your own flow, you are not ready to label a button “Pay.”
Five gates, in an order you can abort
Put the gates on one page in the order they actually happen for one checkout path. A path that sells a physical good and a path that sells a registration may not share the page.
Authorize. The moment a payer’s instrument is asked to reserve funds, and what your system stores when the provider says yes, no, or “unknown, ask again.” Unknown is not yes. Write the inventory rule attached to this gate: hold stock on authorize, hold stock earlier, or do not hold stock yet. If you hold stock on authorize, write what releases the hold when auth expires or is voided. An unnamed expiry is a shelf of ghosts.
Capture. The moment reserved funds become a charge you intend to keep. Say what operational fact must already be true: fulfillment task created, goods picked, bid accepted, service started—whatever you mean, named as a state in your system. Capturing because the button was pressed, while the operational fact is still “maybe,” is the failure this line exists to prevent. Also write the reverse: you may not start that operational fact unless auth has succeeded, if that is your rule. Pick the direction on purpose.
Settle. The later provider state you will treat as settled, in the provider’s vocabulary, not as a synonym you hope is close enough. Say what you will and will not tell the buyer before that state. Many businesses must ship before settle. That is allowed if the spec says so and the buyer-facing language does not say “paid in full” when you only mean captured, or “captured” when you only mean authorized. The abuse is the synonym, not the delay.
Fulfillment start. The earliest action that is hard to undo: pick, label, hand to a carrier, start a job, transfer a ticket. Name it. If this can happen before capture, the abort section must say how you get the goods or the effort back, or who eats the cost. Silence means you have chosen an abort you have not staffed.
Abort. For each gate, the failure and the response. Auth declined: release any hold, do not start fulfillment, do not send a success message. Auth unknown: do not start fulfillment; a named role or job resolves the unknown before anyone tells the buyer it worked. Capture fails after fulfillment started: the spec names the compensating path—cancel the handoff if you still can, or a human exception if you cannot. Settle fails or reverses later: who is told, and which promise already spoken is now false. A page with gates and no aborts is a happy-path diagram.
The spec is incomplete if any of the five is blank or if two gates are described as “at checkout” without an order between them. “At checkout” is not a time. It is a pile.
Sequence of work
Place money gates against the goods
- Authorize
Record yes, no, or unknown. Unknown is not yes. Apply the hold rule you named.
- Hold or release
Stock reserved only at the gate you chose, and released when auth ends.
- Capture
Charge only after the operational fact you named, unless the spec says otherwise.
- Fulfillment start
The first hard-to-undo step, forbidden on decline and on unresolved unknown.
- Settle
Use the provider’s word, and do not let buyer copy treat it as a synonym.
Checkout is a sequence of gates, and a green button is not the name of any of them.
Walk one good and one failed attempt
Rehearse with a test instrument. Do not rehearse with a real customer’s card, and do not write down credentials. You are checking order, not collecting trophies.
Clean path. Button confirms only after auth has a recorded yes, if that is your rule. The buyer sees a word you chose for that state—accepted, authorized, charged—matching the spec, not a generic “you’re all set.” Inventory hold appears only at the gate you named, and a second session cannot buy the same last unit. Capture happens at the operational fact you named, and not before. Fulfillment does not start on a declined auth. Settle is visible to the role who reconciles, even if the buyer never sees that word.
Failed auth. Decline. Hold released if one was taken. No pick, no label, no “order confirmed” mail. The buyer sees the decline state you wrote, with a next action that is not “we’ll ship anyway.”
Unknown auth. Timeout or a provider state your spec called unknown. The order sits in a named waiting state. It does not fall through to capture because a worker retries blindly. Someone can find it.
Capture failure after a point of no return. Only if your spec allows fulfillment to start before capture. Show the compensating path with a test order. If you cannot show it, change the spec so fulfillment cannot start first. Do not leave a compensating path that exists only as a sentence in a channel.
Language check. Read the buyer message next to the spec. If the message says “paid” at authorize, fix the message or move capture. The spec’s job is to make that argument obvious while the words are still editable.
On work shaped like Paddle8, the visible event and the physical follow-through are different engineering problems that still belong in one scope. Treat authorize, capture, and the first hard-to-undo fulfillment step with that same suspicion of the glamorous moment. The crate does not move because the room applauded. It moves because a gate you named has passed.
Record the rehearsal on the spec: date, path, and which abort you actually saw. A spec with no rehearsal note is a proposal. You may ship only after the failed-auth case has been seen by someone who did not write the integration.
Timelines that collapse into one green word
Composites, not payment metrics and not a Paddle8 settlement report.
Success at authorize. The buyer is told the purchase is complete. Capture is a later job that sometimes fails. Support reads “complete” and argues with the ledger.
Fulfillment on the button. A label is bought when the user clicks, before auth returns. Declines become a pile of labels and a release problem nobody owns.
Hold without release. Auth expires. The unit stays reserved. The next buyer is told it is gone. The abort line for expiry was blank, so the hold is forever until someone notices a spreadsheet.
Settle used as a synonym. The team says “once it settles we’ll capture,” or the reverse, because the provider’s words were never copied onto the spec. Reconciliation and customer copy drift apart.
Blind retry. An unknown auth is retried into a second authorization. The spec did not say unknown must be resolved before a new attempt. The buyer sees one order and the provider sees two holds.
When you see these, do not add a friendlier confirmation. Separate the gates and write the abort. The unreproducible asset is the filled TWIMCO Payment Capture Timing Spec for one checkout path: your order of gates, your buyer-facing word for each, your abort for decline and for unknown, and the rehearsal note that a decline did not pick, label, or send success. A processor’s generic diagram is not that page. Your words and your test note are.
Keep the spec next to the returns and cancellation rules. A cancellation after capture is a different operation from a void before capture, and the spec should say which one the buyer is offered at each gate. If those rules are not written, do not imply them in the receipt.
Fulfillment operations is the conversation when the hard-to-undo step is physical. The marketplace lesson on Paddle8 is the one to carry into the review: build for the moment of the sale and for what the business must do after it, and do not let the first moment’s language swallow the later gates.
Decision guide
One green success versus separate gates
| Consideration | Sounds finished | Is a placed gate |
|---|---|---|
| Buyer copy | “You’re all set” at the click. | A word that matches authorize, capture, or settle as you defined them. |
| Stock | Reserved forever after a failed auth. | Released on decline, void, or expiry by a named path. |
| Unknown response | Retry and hope. | A waiting state a person can find; no second blind auth. |
| Shipping | Label bought on the button. | Fulfillment starts only after the gate the spec allows. |
Put this into practice
- Choose one checkout path that is about to call itself complete.
- Place authorize, capture, settle, inventory hold, and fulfillment start in real order. Attach the buyer-facing word to each money gate.
- Write the abort for decline, for unknown, and for expiry of an auth. Name who releases a hold.
- Rehearse a decline and an unknown on a test instrument. Confirm that no success message and no hard-to-undo fulfillment step ran.
- File the spec with the checkout change. If the systems cannot represent “unknown” without falling through, bring that gap to fulfillment operations or the application work that owns the checkout. Read Paddle8 as the public reminder that the winning moment is not the end of the operation—and do not borrow it as a payment-processor story it does not tell.
A green button can mean authorized, captured, or merely clicked. The spec is how you stop pretending those are the same.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.