Stripe ecommerce integration without fulfilling on a browser thank-you

The store already takes orders. Stripe already takes cards. The gap is PaymentIntents, webhooks, and the AU methods you actually want — EFTPOS, Afterpay, BECS, PayTo. We will tell you what Stripe should own, and what still belongs in Xero.

Book a free 30-minute discovery callTalk through your Stripe connection

Australian ecommerce team. We look at the store and the Stripe account before anyone talks about a connector.

Still running a store that needs Stripe?

The store still takes orders. Checkout still sometimes marks them paid because the browser said so. That is why finance is chasing payments that never landed, or refunds that never reached the gateway.

Stripe is payments and financial infrastructure. It launched in Australia in 2014. AU docs cover cards, EFTPOS least-cost routing, Apple Pay and Google Pay, Afterpay, BECS and PayTo. PaymentIntents support au_becs_debit and nz_bank_account. That is first-class AUD / AU BECS / Afterpay / NZ BECS — suitable as the payment integration on nopCommerce or another CMS (plugin or custom gateway). It is not an ERP.

You might recognise one of these:

  • Orders mark paid on the thank-you page, then Stripe shows a failed Intent
  • Afterpay or BECS was “coming next” and never made it into the Intent’s payment methods
  • Refunds are issued in the store and not in Stripe, or the other way around
  • B2B wants invoices and saved PaymentMethods, and the plugin only does a one-off card
  • Someone wants Stripe to be the GST ledger because it has an Invoices object
  • Webhooks were never wired, or they hit a URL that returns 500 and Stripe stopped retrying

You do not need a new storefront, or an accounting replacement pitch. You need a clear read on the Stripe account and the checkout you already have.

Why these connections stall

Stripe’s API is public and well documented. The stall is rarely “Stripe cannot take AUD”. It is webhooks, method list, and using the processor as the books.

PaymentIntents

Webhooks

AU methods

Not the ledger

The official surface is REST, with webhooks as the source of truth.

https://api.stripe.com, form-encoded requests, JSON responses, secret-key auth. Ecommerce objects: PaymentIntents, Customers, PaymentMethods, Invoices / Subscriptions, Checkout Sessions, refunds. Create the PaymentIntent at checkout. Save Customer and PaymentMethod if you will charge again. Refunds go through Stripe, not only through the store admin.

Fulfil on payment_intent.succeeded, not on client-side success.

Webhooks are an HTTPS POST of Event JSON. Verify Stripe-Signature. Return 2xx quickly. Stripe’s own rule: fulfil on payment_intent.succeeded, not only the browser success path. A customer can close the tab. A 3-D Secure step can finish after the store already said thank you. If you only trust the front end, you will ship unpaid orders and fail to ship paid ones.

Australian methods are a PaymentIntent configuration, not a logo in the footer.

Cards, EFTPOS least-cost routing, Apple Pay, Google Pay, Afterpay, BECS, PayTo — each has to be enabled on the account and requested on the Intent (including au_becs_debit, nz_bank_account). A card-only plugin on an AU account that already has Afterpay approved is how checkout looks older than the Stripe dashboard.

Stripe is not Xero, MYOB, or the warehouse.

Optional Stripe Invoices for B2B are still not the GST ledger of record unless you have designed it that way — and we will not tell you they replace Xero or MYOB. Stock does not live here. A paid PaymentIntent means money moved. It does not mean the item card in the ERP is right.

None of that makes the store or the Stripe account worthless. It does mean “the checkout plugin is green, so we are done” is how unpaid orders leave the warehouse.

How we work

We start with checkout and the Stripe account, not with a theme tweak.

1

Look at what you have

Store platform, Stripe account country and enabled methods, whether a nopCommerce (or other) plugin already exists, webhook endpoints, and where paid-and-unpaid orders go today. We will tell you whether to keep the plugin and fix webhooks, or replace the gateway path.

2

Decide the job

There are three honest outcomes. We recommend one, not all three.

3

Do the work in stages

PaymentIntent + webhook first, then Customers / PaymentMethods, then refunds, then AU methods and optional B2B invoices. A test mode endpoint beats a Friday go-live with no signature check.

4

Hand it back so the next person can run it

Source, webhook secrets, and a short record of which event marks an order paid.

Three honest outcomes

  • Connect the store to Stripe: PaymentIntent at checkout, webhook → mark paid on payment_intent.succeeded, Customer + PaymentMethod, refunds, optional Stripe Invoices for B2B, AU/NZ methods the account actually has. Custom gateway or a repaired plugin. No published CoSource Stripe case.
  • Fix a broken connector when a plugin still almost works: verify signatures, stop fulfilling on the browser, add Afterpay or BECS to the Intent, or stop double-capturing.
  • Decide not to connect when the platform’s maintained Stripe plugin already does PaymentIntents and webhooks correctly, when the merchant should stay on another AU gateway, or when the real pain is Xero, not card capture.

We will not tell you Stripe replaces Xero. We will not treat client-side success as fulfilment. If a current, maintained plugin already follows Stripe’s webhook model, that may be enough. If you want an honest fork in the road, talk to us.

What we need for the first call

A store URL and which Stripe account is enough to start.

  • Which store: nopCommerce, AbleCommerce, Shopify, or another CMS
  • Whether a Stripe plugin or custom gateway is already in checkout
  • Which methods you need: cards, EFTPOS, wallets, Afterpay, BECS, PayTo
  • Whether webhooks are configured, and which events you handle
  • Whether B2B invoices or saved cards are in scope
  • What “done” looks like: paid orders you can trust, refunds that match, or a clear picture first

The first call is 30 minutes. You leave with a recommendation you can take to a manager, not a payments estimate pulled from thin air.

Related work

We have not published a Stripe ecommerce case. NESS and Windsor are ERP and inventory store stories. Neither is a Stripe case, and we will not stretch them.

CoSource is a Sydney software firm and a nopCommerce Gold Partner. Services include custom ecommerce on nopCommerce, AbleCommerce, and Shopify. That is a capability, not a Stripe case study. A Stripe account still starts with its own assessment.

FAQ

Is the thank-you page enough to mark the order paid?
No. Stripe: fulfil on payment_intent.succeeded via a verified webhook. The browser can lie, stall, or close.
Can we take Afterpay, BECS, or PayTo?
On an Australian Stripe account, those methods are documented — including au_becs_debit and nz_bank_account on PaymentIntents. They still have to be enabled and requested. A card-only plugin will not grow them by itself.
Does Stripe replace Xero or MYOB?
No. Stripe moves money. The GST ledger stays in the accounting product unless you have a deliberate, unusual design. We will not sell that as the default.
Do you have a Stripe store case?
No. We will not invent one.
We already have the nopCommerce Stripe plugin.
Bring the version and whether webhooks are live. If it already does PaymentIntents correctly, the job may be configuration, not a rewrite.

Talk through the Stripe connection you already need

Thirty minutes. Bring a store URL and whether webhooks already fire. We will tell you whether to connect, fix the gateway, or leave Stripe as it is and fix the books instead.

Book a free 30-minute discovery call