Service 03 / Stripe Payments
Taking money is the start.
Reconciling it is the finish.
The hard part of payments isn't wiring Checkout.
It's duplicate webhooks shipping the same order twice, dropped events leaving
orders stranded, and month-end reconciliation that never quite matches.
Who this is for
- ·The site is live but the payment path was never tested against edge cases
- ·Stripe shows paid while your database still says pending
- ·A customer received two deliveries, or paid and received nothing
- ·You need subscriptions and don't know how proration, trials or cancellation behave
Does this sound familiar?
「Someone paid and never got their order」
「The same order sent two delivery emails」
「A customer cancelled their subscription and kept getting charged」
「Month-end reconciliation never matches Stripe and we can't find the gap」
What you get
What I don't do
Stating the limits saves both sides more time than listing capabilities.
No regulated payment business
Technical integration only. Settlement, splits and cross-border compliance need licensed providers; my job is getting the interface right.
I don't take your Stripe account
Keys stay with you. I provide steps or demonstrate in test mode. If I need direct access you grant temporary permission and revoke it after.
No zero-failure promise
Stripe can fail too. What I can do is make your local logic correct under duplicate, delayed and out-of-order events.
Stripe only
WeChat Pay and Alipay have different flows and aren't in this scope.
Timeline and pricing
Fixed pricing, not hourly. Under $2,200: 50% upfront, 50% on acceptance. Above: three instalments. Third-party costs (server, API, domain) are not included.
Why take my word
Three idempotency patterns and four traps
Written up: why event-ID deduplication beats boolean flags, why a state machine beats conditionals, and the four specific mistakes I made in a real project.
This site's store actually runs
Two digital products, Stripe checkout, automatic delivery of download links after payment. Production, not a sandbox demo.
The delivery path is checkable
Checkout page, success page, delivery email, refund path — all walkable end to end. You see the real flow, not a diagram.
Common questions
What does idempotency actually mean here?
Stripe may send the same event more than once (retries, network jitter). Your handler must produce identical state whether it runs once or five times. The standard approach: store the event ID as a unique key and skip if it already exists.
What if payment succeeds but the webhook never arrives?
You need a fallback: when the user hits the success page, actively query the Stripe session and write back the state. Two paths means one failing doesn't strand the order.
How is proration handled?
Stripe computes the prorated amount automatically, but your system must receive and display those events. I wire proration events into the notification logic so users don't see unexplained amounts.
Can we rehearse in test mode first?
Required. Stripe provides test cards and a test clock. I run every failure path — declined card, 3D Secure, refund, cancellation — in test mode before going live.
What's actually broken?
Can't take money, shipping twice, or numbers that don't reconcile? Each has a different fix. Describe the symptom and I'll tell you whether it's an hour or a rebuild.
Describe the problemOther services
Public pricing, written boundaries, and an honest no when it's not a fit. That saves more time than any promise.