Your first customer is ready to pay. The product works, the checkout button is live, and then the anxiety kicks in. Which provider? Which fees? How long until the money lands? And why does every payment page sound like it was written for a bank, not a startup founder trying to ship before Friday?
That's the awkward bit nobody tells you about. Taking money online sounds simple right up until you have to choose the plumbing. For founders in New Zealand and Australia, payment processing solutions aren't just a checkout choice. They shape cash flow, support load, failed payments, subscription retention, and eventually your margin. That last one matters more than people admit.
A lot of generic guides treat payments like a feature checklist. Cards, wallets, refunds, done. Real life is messier. You need to think about settlement timing, local support, GST workflows, recurring billing, disputes, and whether your stack will still make sense once you sell across borders. If you're selling software, the economics can get surprisingly sharp, surprisingly fast.
The first dollar is memorable because it proves someone wants what you built. It's also when your payments setup stops being theory. A test card in staging is one thing. A real customer with a real wallet and very little patience is another.
That pressure is rising because the market here is already heavily digital. In New Zealand, digital wallet usage became the primary payment method for over 60% of consumers in cities like Auckland and Wellington, and digital transactions are projected to account for over 90% of all retail payments by 2027, according to Testlio's New Zealand payment statistics summary. So this isn't a side decision anymore. It's core product infrastructure.
If you run an ecommerce or SaaS business, payments sit right next to product and growth. They affect conversion, support tickets, and trust. A rough checkout flow feels like a bug, even when the app itself is fine. That's why local context matters. NZ and AU customers already expect tap, wallet, card, and smooth mobile checkout as normal behaviour, not fancy extras.
For founders sizing the local opportunity, New Zealand ecommerce market context helps frame why payment decisions show up so early in the company build. You don't need a huge company before this becomes painful. You just need real transactions.
Most founders start with one question. “Can I take payments?” Fair enough. But the better question is, “Can I take payments well?”
That means a few things at once:
Payments feel boring until they break. Then they become the only thing anyone talks about.
Founders often lump everything together as “the payment provider”. That's understandable, but it hides where fees, delays, and failures occur. The money takes a route. Once you see the route, the jargon starts to behave.
Consider it a courier run.
Customer starts payment
They enter card details or use Apple Pay, Google Pay, or another wallet.
Gateway passes the request securely
The gateway is the secure front door. It collects and encrypts payment data.
Acquirer receives it
Your merchant-side banking partner, or the provider acting in that role, sends the request onward.
Card network routes it
Visa and Mastercard act like the switching layer between banks.
Issuing bank decides
The customer's bank checks the details, available funds, and risk signals, then approves or declines.
Settlement happens later Approval is not settlement. Approval says “yes, this can go through.” Settlement is when funds move and show up for you.
That's the simple version, but it's enough to explain why one provider may approve more transactions while another settles faster or gives better reporting.
If approval rates are weak, the issue might be routing or data quality. If payouts are slow, the issue might be settlement cadence or reserve settings. If reconciliation is chaos, the problem might be your ledger design, webhook handling, or how your provider batches reports.
This is also why comparisons between providers can be slippery. Some companies offer a tidy all-in-one package. Others give you a gateway plus acquiring relationships plus add-ons for fraud and subscriptions. The sales page makes it sound simple. The operational model usually isn't.
If you sell through Shopify, it helps to understand Shopify payments in merchant account terms, not just storefront terms. A lot of founders mix up the checkout brand they see with the acquiring and settlement mechanics underneath.
The payment page is the shopfront. The hard part sits behind the wall, in routing, risk rules, settlement, and reconciliation.
By this point, most founders want a winner list. Stripe, Adyen, eWAY, Pin Payments, maybe a bank-backed setup. But before names, get your questions straight. A weak question gets you a weak stack.
Here's a practical comparison lens to use early.
| What you're judging | What to ask | Why it matters |
|---|---|---|
| Cost | What do we pay beyond the obvious transaction fee? | Hidden charges creep in through disputes, FX, platform extras, and support overhead |
| Settlement | When do funds land, and how visible is the payout trail? | Cash flow problems often start here, not in sales |
| Integration | Is this a clean API and SDK job, or a project with sharp edges? | Your dev team pays for complexity one sprint at a time |
| Business fit | Does it support subscriptions, marketplaces, wallets, refunds, and tax reality? | The wrong model creates manual workarounds everywhere |
| Performance | What actually gets approved, and what gets declined? | Revenue leaks when good customers fail at checkout |
| Operations | How good are reporting, webhooks, dispute tooling, and support? | Payments live with finance and support long after launch |
If you only track one payments metric seriously, make it authorisation rate. Global ecommerce guidance cited by Gr4vy puts general card-not-present transactions around 85% to 92%, while a well-optimised NZ or AU merchant should aim for 90% to 95%, as outlined in Gr4vy's payment performance guide.
That gap matters. It's the difference between “customers changed their mind” and “our stack declined a real sale”. Founders often obsess over page conversion and barely inspect payment approval patterns. That's backwards.
A few things get missed because they're not sexy:
A lower sticker price can still cost more. Maybe the provider has weak subscription controls. Maybe the reporting is awful. Maybe support only wakes up when your issue fits their script. You save on paper and lose in labour, failed renewals, and finance cleanup.
Practical rule: Don't choose on fees alone. Choose on revenue kept, time saved, and operational mess avoided.
Once you've got your criteria, the shortlist usually splits into two camps. Global players with broad platform depth, and regional players with local focus. Neither camp is “better” in the abstract. They solve different headaches.
If you're looking at Stripe, Adyen, or Braintree, the appeal is obvious. Strong APIs, broad documentation, recurring billing tooling, global wallets, international currency support, and mature developer ecosystems. For internet-native companies, that's catnip.
Stripe, for example, tends to win early because it removes friction for engineers. Good docs, sensible SDKs, decent dashboard ergonomics, and products like Stripe Billing and Stripe Connect that fit SaaS and marketplace models neatly. Adyen often shows up when companies want more enterprise-style control, deeper omnichannel thinking, or broader international complexity under one roof. Braintree can be attractive when mobile and wallet support are central to the product.
The big upside is speed to market. You can often get live without negotiating directly with banks or stitching together multiple vendors. For a startup, that's not trivial. Fast launch matters.
The trade-off is that global platforms can feel distant when something odd happens in your local market. Their systems are broad by design. Your edge case may be one tiny ticket in a huge global queue.
Regional providers like Pin Payments and eWAY often make more sense than they get credit for. They may not have the same universe of add-ons, but they understand the day-to-day shape of AU and NZ commerce. Local support teams, local banking familiarity, and a simpler setup can be a relief.
For domestic-heavy businesses, that can be enough, or more than enough. If most of your customers are in Australia or New Zealand, and your product doesn't need exotic payout flows or complex multi-entity logic, local specialists can be the calmer choice. Less platform sprawl. Less overbuying.
Some founders also prefer having support in roughly their time zone, talking to people who know local bank behaviour and regional operational quirks. That sounds soft until a payout issue lands on Thursday afternoon and your finance lead needs a useful answer, not a knowledge-base loop.
| Provider type | Usually stronger at | Usually weaker at |
|---|---|---|
| Global giants | Developer tooling, international reach, broad product suites, complex platform models | Local nuance, personalised support, sometimes pricing clarity |
| Local champions | Regional support, straightforward setup, local business familiarity | Global expansion paths, feature depth, complex marketplace tooling |
The usual mistake is buying for the company you hope to be, not the company you are. A local B2B SaaS with mostly AU invoices doesn't always need a giant global stack on day one. On the other hand, a marketplace that expects cross-border sellers and split payouts can waste months trying to force a simple local processor into a complex shape.
There's also the non-US founder problem. A lot of global payments advice assumes Delaware, US banking, and US tax flows as default. That's not your life. If you want a broader read on that angle, this overview of payment platforms for non-US founders is useful because it frames setup choices from outside the American happy path.
You're choosing what kind of pain you prefer.
Both can be right. Wrong usually comes from mismatch, not brand quality.
If your payments setup needs a custom diagram to explain a basic sale, you may be overengineering. If your business model needs split payouts and you chose a simple checkout tool, you've underbought.
There isn't a universal winner. There's only fit. The processor that feels brilliant for a Wellington SaaS company may be wrong for a Melbourne mobile app, and both may be wrong for a marketplace trying to juggle multiple sellers.
If you run SaaS, your payment stack is part of your retention stack. Recurring billing, card updates, failed renewal handling, invoices, tax support, and usable reporting matter far more than shiny checkout customisation.
Stripe often fits this model well because Billing and Connect cover a lot of common SaaS and platform scenarios. Not perfectly, but cleanly enough. If your finance workflow is still maturing, that simplicity helps.
What doesn't work? A cheap provider with weak recurring billing controls. You'll feel it in failed renewals, support tickets, and finance cleanup.
For ecommerce, speed and trust rule. Wallet support matters. Mobile checkout matters. Fraud controls matter, but not if they start declining legitimate buyers too aggressively.
A stack tied neatly into your storefront can be worth more than a theoretically better processor that adds implementation drag. Good ecommerce payment processing solutions remove taps, fields, and hesitation. That's the whole game.
If your team is still shaping the customer journey, this piece on designing an ecommerce website is a useful companion because checkout pain often starts with interface choices, not only processor choice.
Marketplaces are where founders get humbled. Taking one payment and splitting it across parties sounds simple until compliance, KYC, reserves, refunds, and dispute ownership enter the room.
Stripe Connect is strong here for a reason. It was built for this kind of mess. Some other providers can support variants of the model, but you need to get very specific about your flows. Who owns the customer? Who gets paid first? Who eats the refund? Who handles disputes?
That's why a broader guide to embedded payment processing can be worth reading, especially if your product starts moving from “we accept payments” to “payments are part of the platform experience”.
If the product is mobile-first, the stack has to respect the thumb. Wallets, SDK quality, retry flows, and app-store realities matter more than desktop-era assumptions. Braintree and Adyen often come up here because mobile support and international capabilities can be strong, especially when you've got more than one region in play.
The wrong move is forcing desktop checkout habits into a phone-sized journey. Customers won't explain why they left. They'll just vanish.
Changing providers is half technical migration, half paperwork slog. Neither part is glamorous, and both can bite if rushed.
Start with KYC and account setup. Company details, directors, bank evidence, identity checks, tax details. Founders often treat this as admin they'll tidy up later. Bad move. It can hold up go-live even when the integration is finished.
Also decide early who owns the relationship internally. Engineering should not be the only team touching this. Finance, support, and ops all need visibility because each sees a different failure mode.
The happy path is easy. The ugly paths are what matter:
A sandbox is useful, but don't trust it blindly. Sandboxes rarely reproduce every production quirk. You need live monitoring after launch.
Once live, monitor approval patterns, payout timing, support tickets, and anything odd in your ledger. If you're migrating subscriptions, pay close attention to token behaviour and recurring charge outcomes. Small cracks become monthly churn later.
Launch day isn't the finish line. It's when payments start generating real evidence.
A phased rollout helps. Start with a slice of traffic or a subset of customers if your setup allows it. It lowers blast radius and gives your team time to spot bad assumptions before they hit everyone.
Most founders treat payments as a tax on revenue. Something to minimise, negotiate, and grumble about. Fair enough. But software businesses can sometimes turn payments into part of the product, and that changes the maths.
Bain's view is worth paying attention to here. It notes that software platforms increasingly bundle payments with their product to create new revenue streams, but becoming a payment facilitator also means taking responsibility for merchant rules and settlement flows. For NZ founders, it's not a question of whether you can accept cards. It's what margin is left after fees, risk, and operational overhead, as discussed in Bain's analysis of integrated payments.
If you embed payments into your SaaS, you may earn a slice of transaction activity across your customer base. That can be attractive. It can also fool founders into thinking payments revenue is clean money. It isn't automatically clean.
You have to model the ugly bits:
Margin leakage hides not in one dramatic fee, but in a dozen small dents that chip away at take-rate.
For the right SaaS company, embedded payments become more than a checkout feature. They become infrastructure your customers rely on. That can improve retention and create a stronger commercial relationship, especially in sectors where taking payment is central to the workflow.
Open banking adds another angle worth watching locally. If you're thinking beyond cards and into account-to-account experiences, open banking in New Zealand is relevant background because the strategic shape of payment rails is widening, even if the operational details still need careful handling.
The point isn't that every founder should become a payfac. Many shouldn't. The point is simpler. Don't think about payments only as cost control. For some NZ and AU software companies, the smarter question is whether payments should sit in your revenue model at all.
If you're building for the NZ or AU market and want practical founder-focused coverage, NZ Apps is worth a look. It tracks the regional app and software space with the kind of local context global tech media usually misses, which is handy when you're choosing tools, sizing markets, or trying to grow with a bit more signal and a bit less noise.
Add your NZ or Australian app or tech company to the NZ Apps directory and get discovered by founders and operators across the region.
Get ListedReach tech decision-makers across New Zealand and Australia. Sponsored and dofollow editorial links, permanent featured listings, and sponsored articles on a DA30+ .co.nz domain.
See Options