Stripe, wired the way
it survives a bad Friday.

Taking a card payment is the easy part. What separates a payment integration that holds up from one that quietly loses money is what happens on the unhappy paths: a tampered basket, a duplicate webhook, a dispute six weeks later.

Start a project

The four rules we never break

The server re-prices everything

Price, delivery, distance and stock are recalculated on the server before a charge, and the basket the browser sent is treated as a request rather than a fact. Trusting the basket is how a £40 order gets paid for with £4.

The webhook is the only thing that marks an order paid

Verified against the raw body, idempotent, ignoring livemode mismatches. A customer closing the tab after paying must not be able to lose their order, and a retried webhook must not create a second one.

Stock is reserved before payment

Atomically, so two people cannot buy the last one. Releasing it again on an abandoned checkout is part of the same job.

Every order keeps what wins a dispute

The payment reference, the basket as charged, the authentication result and the timestamps. That is what answers a chargeback; a till roll and a memory answer nothing.

Wallets, and why they matter more than they look

Apple Pay and Google Pay as the default path

On a phone, a returning customer paying with a thumbprint converts far better than one typing sixteen digits at a bus stop. Apple Pay arrives through the card payment method rather than as a separate integration.

Domain registration is a real step

Apple Pay has to be registered per domain, and again at cutover and in live mode. It is the commonest reason a wallet button is missing on launch day.

Authentication that does not break the checkout

Strong Customer Authentication means the customer may be sent to their bank app and must come back to a checkout that remembers them. It is one of the things we test on a real phone rather than in a desktop browser.

Connect, for platforms that pay other people

Direct charges on the client’s own account

Where a platform takes a fee and the business takes the sale, the charge belongs on their connected account with an application fee, so they are the merchant of record and the money is theirs from the start.

Onboarding that the business can actually finish

Identity, bank details and verification are Stripe’s flow, and the job is getting the business into it with the right account type for how they trade.

Fees that survive a refund

What happens to the platform fee when an order is refunded is a commercial decision that has to be built deliberately rather than discovered at the first refund.

Questions

Before you ask.

Do you store card details?

No, and that is deliberate. Cards are handled by Stripe’s own fields, so card data never touches our servers, which keeps you in the lightest PCI bracket. Saved cards work through a token that is useless anywhere else.

Can customers pay with Apple Pay?

Yes, on any site we build that takes payments. It comes through the card payment method and needs registering per domain, which we do as part of launch.

Can we take a deposit, or hold a card?

Both. A charge now against a final bill, or a card held with a stated charge if somebody does not turn up. The terms have to be plain at the point of booking or a hold becomes a dispute.

Do you take a cut of our sales?

No. You pay Stripe’s fees and nothing per order to us. On platform builds, where a client is the one taking a fee from other businesses, that fee is theirs and is set by them.

Ready to get started?

Tell us what you need. We will scope it, price it and build it.

Start a project →

Stripe, wired the wayit survives a bad Friday.