The short answer
A Stripe integration connects your website or software to Stripe for payments, subscriptions, refunds and marketplace payouts. AR Digital Solutions builds them from Brisbane, with webhook handling, retry safety and card authentication tested before launch rather than discovered in production.
What we build with it
- One off payments, saved cards and authorisation holds.
- Subscriptions, plan changes, proration and cancellations.
- Refunds, partial refunds and the records that follow.
- Connect for marketplaces, with seller onboarding and payouts.
- Webhook handling with retries, replay and a visible failure queue.
- Reconciliation between Stripe payouts and your accounting file.
Webhooks, and the failure cases nobody tests
Most Stripe builds get demonstrated the same way. Card number, submit, green tick, order appears. That path works in every implementation ever written. The differences are in the payments that don't.
You cannot trust the browser to tell you a payment succeeded.
The success page is a UI event, not evidence. A customer pays on a phone, the train enters a tunnel, and the redirect never lands. They close the tab as the spinner appears. The money moved and your system never heard. The reverse happens too: a success page anyone can reach by guessing the URL will eventually create orders nobody paid for. The source of truth is Stripe's own record, reaching you by webhook or by asking Stripe for the payment's status.
Webhook handlers must be idempotent, because Stripe will retry.
If your endpoint is slow, errors or times out, the event comes again. Events can arrive out of order, and the same event can be delivered twice when nothing failed. A handler that creates a record every time it runs will send two receipts and dispatch two of something.
The pattern that works: verify the signature, store the event ID and check whether you've already processed it, do the work in a transaction keyed to that ID, and acknowledge quickly. Anything slow, like generating documents, belongs on a queue behind the handler.
Subscriptions fail quietly when cards expire.
Cards expire, get replaced after fraud, or have no money on them at 3am on the renewal date. That's involuntary churn, and it costs more customers than anyone expects. What happens next is a business decision, not a default to inherit.
Decide how many retries and over how many days. Decide whether access continues during that window, because cutting someone off on the first failed attempt turns a card problem into a cancellation. Make the card update path work from the email you send, on a phone, without six screens of login. Then decide what happens at the end of it.
Connect adds a second question: who is liable.
In a marketplace the money flows to sellers and the platform sits in the middle. Which entity is the merchant of record, who pays Stripe's fees, and who wears a chargeback when a buyer disputes after the seller has been paid out. That last one decides how you hold funds, and it follows from your Connect account type rather than from what feels fair. Answer it before the build, because it changes the schema.
Seller onboarding, payout schedules and refunds after a payout has gone out all follow from it. Our multi vendor marketplace work covers the rest of that model.
3D Secure and card authentication.
Some payments need the customer to confirm with their bank, triggered by the issuer, by fraud signals, or by rules that vary between markets and change over time. Your checkout has to handle a payment that isn't approved instantly, in the interface and in the data model, where the order sits pending. Saved cards bite hardest, because a later charge can still be challenged with nobody there to answer. Authorisation holds have their own version, and our car rental app work covers holds, releases and expiries.
Test the failures deliberately. Stripe's test cards simulate declines, authentication challenges and disputes, and a build that hasn't been through them isn't done.
How we do it
1. We map the money, refunds, disputes and who is liable for what.
2. We agree scope and price.
Fixed number, dates in writing.
3. We build in test mode and run declines, authentication challenges and duplicate webhooks.
4. We monitor it after launch, with alerts on failed and unhandled events.
Who it's for, and who it isn't
It suits software with subscriptions, marketplaces paying sellers, and businesses whose checkout does something a plugin doesn't.
It isn't necessary for a standard online store. Shopify and WooCommerce handle Stripe out of the box, and our eCommerce web design team sets that up without a custom build.
Why bring this here
Developers in house, who also run the servers taking the payments.
We stay after launch.
Payment integrations fail in the corners, which the custom integrations page covers. No lock in contracts, and the account stays in your name.
"Our payments work fine already."
Then the questions are what happens to a subscription when a card expires, and how you'd know today if webhooks stopped arriving. If both have answers, you don't need us.