Stripe Integration Services
Taking a payment with Stripe is straightforward. Keeping your own records correct about what was charged, refunded, retried and cancelled is where the work is, and it is where most of the integrations we are asked to fix went wrong.
Discuss your projectTwo rules that prevent most Stripe bugs
The first: never fulfil an order based on the browser telling you the payment succeeded. A client-side confirmation can be lost if the customer closes the tab, and it can be forged. Fulfilment is driven by the webhook Stripe sends from its own servers, with the signature verified — which also means fulfilment still happens when the customer navigates away the instant they pay.
The second: every webhook handler must be idempotent. Stripe retries delivery, deliberately and more often than people expect, and the same event will arrive twice. A handler that creates an invoice or grants access without first checking whether it already processed that event ID will double-charge or double-provision. We record processed event IDs and ignore repeats, which is a few lines of code and the difference between a reliable integration and a mysterious one.
Almost every broken Stripe integration we have been called into fix violated one of those two. Neither is exotic; both are easy to skip when the happy path works in testing.
What we build
One-off payments
Payment Intents with proper handling of the authentication step European cards require, so a payment that needs a challenge completes rather than silently failing.
Subscriptions
Plans, trials, upgrades and downgrades with proration, and your own entitlement state kept consistent with Stripe's view rather than inferred from it.
Failed payment recovery
Stripe's retry schedule plus your own email sequence, and a defined answer to what access a customer keeps while a payment is being retried. That policy decision is yours; most teams have not made it until asked.
Usage-based billing
Metering in your application reported to Stripe for billing. Needs designing in from the start — retrofitting metering onto an application that never recorded usage means you cannot bill for the past.
Checkout or custom forms
Stripe's hosted Checkout where speed and minimal compliance scope matter, or Elements embedded in your own flow where the experience justifies the extra work.
Marketplaces and payouts
Stripe Connect where you take payment and pay third parties. Substantially more involved than standard payments: onboarding, verification, fee splitting and payout scheduling each need deliberate design.
Tax
Stripe Tax for automatic calculation, or your existing tax engine. Worth settling early, because retro-fixing tax on historical transactions is unpleasant.
How we test it
Subscription bugs appear weeks after launch, on renewal, which is the worst time to find them.
- Stripe's test clocks to simulate renewals, trial endings and failed payments months ahead, rather than waiting for real time to pass.
- Webhook replay for every event type we handle, including delivering the same event twice to prove idempotency.
- Card numbers that deliberately fail, require authentication, or dispute, so the unhappy paths are exercised.
- A reconciliation job comparing your records against Stripe on a schedule, reporting any subscription whose state has diverged.
- Testing against the API version your account is pinned to, so a Stripe release does not change behaviour without your knowledge.
Common questions
Tell us what you need
Describe the problem and we will come back with scope, timeline, and a rate. No obligation to proceed.
Get in touch