When do you take the customer's money, and how much fraud are you willing to accept?

Group payment methods by how the money moves

A list of brands is not an architecture. What matters is the mechanics behind each method, because the mechanics determine what your order flow can assume.

Pull methods, meaning cards and direct debits, let you place a hold now and take the money later, and they come with a chargeback mechanism that lets the customer's bank reverse a settled payment months afterwards. Push methods, meaning bank transfers and the real-time transfer schemes used in many markets, give you funds that are effectively final, but there is no hold to place and no partial capture, so the amount must be exact at the moment of payment and any adjustment is a separate outbound refund. Deferred methods, meaning buy-now-pay-later and invoicing, put a third party between you and the customer, so you are underwritten but you inherit that provider's own decisioning and its rules about amendments. Stored-value methods, meaning gift cards and store credit, are your own liability rather than an external payment, which is why they need their own ledger and their own reconciliation. And cash on delivery, still substantial in several large markets, means the payment risk becomes a logistics risk: the failure mode is a refused delivery and a return leg you have already paid for.

The design consequence is that the order flow cannot assume a single sequence. It has to work when the amount is fixed up front and unadjustable, when the amount can be reduced at capture, and when funds arrive asynchronously hours after the customer left the site.

Authorise now, capture when the goods leave

For pull methods the default is settled and worth being able to justify. At checkout you request an authorisation, which asks the issuer to confirm the funds exist and to place a hold reducing the customer's available balance. It moves no money. When the goods actually leave the building, you capture against that authorisation, which is what moves the money.

The reason to separate them is asymmetry of reversal. An uncaptured authorisation that you void disappears quietly, and the hold falls off the customer's balance. A capture that you refund is a support contact, an accounting entry in a later period, a fee you may not get back, and a customer who watched money leave and come back. Since a meaningful share of orders never ship - stock shortfalls, fraud declines, cancellations, address failures - capturing at order time converts each of those into a refund you did not need to make.

There are two honest exceptions. Digital goods delivered instantly have nothing to wait for, so authorise and capture together. And some methods do not offer the split at all, in which case the amount charged must be final and any reduction becomes a refund by construction.

The subtlety worth volunteering is partial capture. An order that ships in two parcels should capture in two amounts against the same authorisation where the method supports it, so the customer's statement matches what she received. Whether multiple partial captures are permitted, and whether the residual authorisation survives the first one, depends on the acquirer and the card scheme, so this is something to confirm against your provider's documentation rather than assume.

Authorisations expire, and that is a real operational problem

An authorisation is not valid indefinitely. The hold lasts days rather than weeks, and the exact window varies by card scheme, issuer and merchant category, which means any order that despatches slowly will eventually try to capture against a hold that no longer exists.

So the flow needs a plan for it. Track the authorisation's age as a first-class attribute of the payment, and before it lapses either capture, void, or reauthorise. Reauthorisation is the awkward one, because it is a fresh request that can be declined - the card has been cancelled, the funds are no longer there, the issuer's risk model has changed its mind - and you now have picked goods with no valid payment. The order state machine therefore needs a payment-failed state that sits after allocation, which is exactly the state teams forget to model because it does not exist on the happy path.

For long lead times, ask whether authorising at order time was right at all. Where despatch is genuinely weeks away, a small verification authorisation at purchase plus a full authorisation shortly before despatch is often the better shape, at the cost of a second decline risk you have moved closer to fulfilment.

Fraud screening is a threshold, and the threshold has two costs

The framing that gets this question wrong is treating fraud as an enemy to be eliminated. Screening is a classifier, every classifier sits on a trade-off curve, and you are choosing a point on that curve rather than achieving correctness.

Both sides of the curve cost money, and they are not symmetric in the way people assume. A missed fraudulent order costs the goods, the outbound shipping, the chargeback amount, the scheme fee for the dispute, staff time to fight it or write it off, and pressure on the chargeback ratio that acquirers monitor and can penalise. That total is easy to see because it arrives as a documented loss.

A false decline costs the margin on the order, plus the future value of a customer who was told her legitimate purchase looked criminal and who is unlikely to come back or to try again elsewhere on your site. That total is larger than it looks and almost invisible in reporting, because a rejected good customer generates no ticket, no dispute and no line item. The result is a systematic bias: teams tighten rules because the loss they can see gets smaller, and never learn what the tightening cost. If you say one thing in this answer that marks you out, make it this.

Two further points sharpen it. The trade-off is category-specific, since a digital gift card is instantly resellable and effectively unrecoverable while a bulky appliance is neither, so a single global threshold is wrong for a mixed catalogue. And in Europe and the UK, strong customer authentication under PSD2 changes the arithmetic rather than only adding friction, because a successfully authenticated transaction generally shifts liability for fraudulent-use disputes to the issuer - so the decision is three-way between accept, decline and challenge, not two-way.

What the design needs beyond a score

A screening system that returns only accept or decline throws away its most useful output, which is uncertainty. Three outcomes serve better: accept, hold for manual review, decline. The review tier exists because a human with access to order history, the address, and a phone call resolves a large share of ambiguous cases correctly, and because it gives you labelled data at the boundary where your model is weakest.

Feed outcomes back. Every chargeback, every review decision and every confirmed-good order should return to the rule set as a label, with the caveat that chargebacks arrive with a lag of weeks to months, so this month's fraud rate is not knowable this month. Report it by order cohort rather than by settlement date, or you will congratulate yourself on a fraud reduction that is really just an immature cohort.

Finally, be careful what the rules are allowed to use. Screening on characteristics that correlate with protected attributes - a postcode standing in for something else, for instance - is both a legal exposure and a commercial one, and "the model chose it" is not a defence. Keep the features reviewable and keep decline reasons recorded, so that an unfair pattern is discoverable rather than emergent.

Chargebacks are measured, itemised and reported to you every month. False declines are not measured anywhere unless you build the measurement, which is precisely why most fraud thresholds sit too tight.