E-commerce Development in Newcastle & the Hunter

Roughly a third of Australian businesses take orders online. That leaves a large number who have a perfectly good website and still process every sale by phone, email or a form that lands in an inbox — which works, until it is Sunday night, the customer is ready to buy, and the only thing standing between them and paying you is somebody's working hours.

The gap between those two states is rarely the shopfront. Building a page with products on it is the easy part and always has been. The hard part is everything the customer never sees: whether the payment actually cleared or merely appeared to, whether stock came down when it sold, whether the order reached your accounting system without someone retyping it, whether the confirmation email landed in an inbox or a spam folder, and where the card number went on its way through.

That is why an online store is closer to an integration project than a design project. It touches your payment provider, your accounting, your stock, your shipping, your email and your hosting all at once — and it is a public payment form on the open internet, which is a different security proposition from a brochure site. We build the store and we run the parts underneath it, because the failures that cost real money live in the joins.

Most of the stores we have built run on WordPress and WooCommerce, and that is not inertia. For a business selling a recognisable catalogue of products, it does the job well, your team can already use half of it, and it leaves you owning the platform rather than renting it.

Every plugin you add is another thing that has to be kept current. That is manageable — but only if somebody owns it.

The practical arguments are worth stating plainly. WooCommerce itself is open source, so there is no platform subscription and no cut of each sale going to a store vendor — you pay for hosting, for whichever paid extensions you genuinely need, and for someone to keep it maintained. Your payment provider still charges its own per-transaction fee, and that is true on every platform in this comparison. It runs on hosting you control, so the site, the database and the content can move. And the ecosystem is deep enough that most accounting, shipping and stock systems an Australian small business runs already have a supported connection.

The honest cost is maintenance. A WooCommerce store is a WordPress site with commerce bolted through it, and every plugin you add is another thing that must be kept current. One common way a small business site gets compromised is an unpatched component: something carrying a publicly known vulnerability that nobody was assigned to update. That is a manageable problem, but it is only manageable if somebody owns it, which is exactly why we do not hand over a store and walk away.

• →Good fit — a recognisable catalogue of products, with variants, stock and shipping
• →Good fit — you already run WordPress and your team can edit it
• →Good fit — you want to own the platform and keep the option to change anything later
• →Good fit — you need a specific accounting, shipping or stock integration that exists in this ecosystem
• →Less good — nobody will own the patching, and the site will sit untouched for a year
• →Less good — what you sell is not a catalogue at all, in which case see the next section

A growing share of the payment work we do has no store platform underneath it. The business is not selling twelve products in three sizes; it is taking a deposit against a booking, billing a membership monthly, collecting a staged payment on a job, converting an accepted quote into a paid invoice, or charging for something whose price is worked out by a form rather than picked off a shelf. Forcing any of that into a catalogue produces a store that is fighting its own software, usually held together by two plugins doing something they were not designed for.

Trusting the customer's browser to report a successful payment is a classic way a bespoke checkout ends up shipping goods nobody paid for.

The alternative is to write the checkout. In practice that means a payment flow built into your own site, with card entry handled by the payment provider's own hosted fields so the card number goes directly to them, and the payment confirmed server-side by a webhook from the provider before anything is treated as paid. That last detail matters more than it sounds: trusting the customer's browser to report a successful payment is one of the classic ways a bespoke checkout ends up shipping goods that were never paid for.

We use Stripe for this work. Concretely, that gives you card and mobile-wallet payments, recurring billing without a subscription plugin, stored payment methods where you have a reason to hold one, refunds and dispute handling in a dashboard your bookkeeper can be given access to, and an API that can be driven from whatever your business actually does. The Stripe account is opened in your business's name, so settlement, payment history and customer records belong to you and not to your web provider.

• →Deposits and part-payments against a job, booking or order
• →Recurring billing — memberships, retainers, subscriptions, payment plans
• →Quote-to-payment: an accepted quote becomes a payment link rather than an invoice somebody chases
• →Prices calculated by a form — measurements, hours, tiers, options that multiply out
• →Bookings taken against real availability, where the payment and the calendar have to agree
• →Paid registrations for courses, events and intakes with limited places
• →A checkout that has to write into an existing system as the source of truth, not into a store database

Three routes cover almost every store we are asked about, and the right one is decided by what you sell and who has to maintain it — not by which platform a provider happens to sell. What follows is the comparison as we would give it to you in a meeting, including the parts that do not favour us.

We are light on Shopify. That is a preference, not a limitation — and you should ask any provider what they actually run before you choose them.

We are light on Shopify, and it is worth being straight about why. That is a preference, not a limitation. Shopify and platforms like it are genuinely good at what they do: for a conventional product catalogue it is the fastest route to selling, the hosting, certificates and platform patching are theirs rather than yours, card handling sits inside their environment, and the app ecosystem covers most of what a straightforward retail store needs. If you are already running one and it is working, moving for the sake of it is usually a bad trade. What we build and support day to day is WooCommerce and custom builds on Stripe, because that is where we can do the deeper work — bespoke checkout logic, integration into the systems you already run, and no platform vendor sitting between you and the sale taking a subscription or a percentage. If a hosted platform is genuinely the better fit for your store, we will tell you that, and we will also tell you that we are not the Shopify specialists in this region — you should ask any provider what they actually run before you choose them.

Where we would steer you away from a hosted platform is when the checkout has to do something unusual, when the store has to integrate deeply with a system you already run, or when platform fees on top of your payment provider's own start to matter at your volume. Where we would steer you towards one is a conventional catalogue where speed to launch outweighs bespoke behaviour.

Any business that takes card payments is subject to the card industry's security standard, PCI DSS. The useful question is not whether it applies to you — it does — but how much of it applies, and that is decided almost entirely by one design choice: whether card numbers ever touch systems you are responsible for.

A public checkout is a public payment form. It is exposed to whatever comes past it, not only to someone who set out to target you.

Built the way we build them, they do not. Card entry is handled by fields the payment provider serves and controls, so the number travels from the customer's browser straight to the provider. Your site receives a token and the result of the payment, and that is all it ever holds. The practical consequence is that the storage, encryption and audit obligations sit with a provider whose entire business is meeting them, and your own obligations shrink to the smallest version available to a merchant. The failure mode we are avoiding is the store that quietly posts card details through its own server to be helpful — at which point your hosting, your database and your backups are all in scope, and so is everyone who can reach them.

The obligations that do remain are worth knowing about, because they are operational rather than paperwork. Recent versions of the standard expect merchants to keep track of what scripts run on the page where customers enter their card, even when card data never reaches the merchant's server — which is a hosting, patching and change-control job, not a form to fill in once a year. A store that nobody is maintaining fails that quietly.

Fraud is the other half. A public checkout is a public payment form, and automated card testing — running stolen card numbers through anybody's checkout in small amounts to find which ones still work — is a pattern any store should be configured against from day one. The controls that matter are unglamorous: address and security-code verification, step-up authorisation where the issuer or provider calls for it, provider-side risk rules, rate limits and blocks on repeated failed attempts, and a review queue so orders that are unusual for your business get held for a person to look at instead of going straight through. Those controls are configured when the store is built. What decides whether they earn their keep afterwards is whether the declines and disputes your provider reports reach someone in your business who acts on them, rather than surfacing at month end.

This is where running the store and running the rest of the business's technology stop being separate jobs. Order confirmations only arrive if your email authentication is right. The certificate and DNS the checkout depends on are the same DNS your mail runs on. Refund and payment-detail fraud does not have to touch the store at all — a compromised mailbox is enough to intercept an invoice or redirect where a payment is sent. Store admin accounts need multi-factor authentication for the same reason your email does — and if the store, the email, the DNS, the backups and the security are held by four different suppliers, the gaps between them are unowned. We hold all of it, which is the argument for having your store built by the team that also runs your security rather than beside it.

The diagram below is the whole argument in one picture. A customer fills a cart and goes to checkout on your website. When they enter their card, those details go directly to the payment provider — they do not pass through your server and they are never written to your database. What comes back to your site is a token and the result of the payment, which is what the order record is built from.

Your server receives a token and a result. It never receives a card number, so it never has to defend one.

Because card data never enters your environment, the storage and processing obligations stay with the payment provider, and your PCI-DSS scope stays small. That is not a technicality you can retrofit later; it is decided by how the checkout is built on day one.

One point the picture does not show and we will say instead: the result should be confirmed by the provider talking to your server directly, not by the customer's browser reporting good news. Anything else can be edited by whoever is sitting at the keyboard.