Payment Gateway Integration for Australian Businesses: Stripe, PayTo, BNPL and the 2026 Surcharge Ban

Most businesses find out their payment gateway integration is fragile at the worst possible time — a BNPL provider changes its API, a webhook silently stops firing, or a regulatory deadline like the October 2026 card surcharge ban lands on a checkout that was never built to have surcharging removed cleanly. By then it’s not a quick fix, it’s an afternoon of someone staring at logs trying to work out why half of yesterday’s orders never hit the accounting system.

We get asked to untangle this a lot more than we get asked to build it from scratch. A business picked whatever gateway its ecommerce platform suggested on day one, bolted on Afterpay and Zip because customers asked for them, and never touched the integration again. That works fine until volume grows, a new sales channel gets added, or a regulatory change forces a rebuild of logic nobody fully remembers writing.

This guide is about how payment gateway integration actually works in Australia in 2026 — the real integration methods, where PCI compliance scope changes depending on which one you pick, how BNPL, PayTo and PayID fit into the architecture, and what the surcharge ban actually requires you to change in your checkout code rather than just in your pricing page.

What payment gateway integration actually means

“Integrating a payment gateway” gets used loosely to mean everything from pasting a plugin into WooCommerce to building a custom PCI-compliant card vault. Those are wildly different projects with wildly different risk profiles, and the method you choose determines how much compliance burden lands on your business versus your provider.

There are three broad integration patterns, and almost every Australian business sits somewhere on this spectrum.

Hosted checkout (redirect)

The customer clicks pay and is sent to a page hosted entirely by the gateway — Stripe Checkout, PayPal’s hosted page, or a bank-hosted 3DS page. Your server never sees card data at all; it just gets told whether the payment succeeded or failed. This is the fastest to implement and carries the lowest PCI DSS burden, usually a Self-Assessment Questionnaire A (SAQ A), because cardholder data never touches your systems or even your page.

The trade-off is control. The checkout looks and feels like the gateway’s page, not yours, and customisation is limited to logos, colours and a handful of layout options. For a lot of small and growing businesses that’s a fair trade for not having to think about PCI scope at all.

Embedded fields (tokenisation in an iframe)

Card fields render inside your own checkout page, but they’re actually iframes served by the gateway — Stripe Elements, Braintree Hosted Fields, Adyen’s Drop-in component. Visually it’s part of your site. Technically, the card number never enters your DOM in a way your own JavaScript can read, and it’s tokenised before it reaches your server. This usually qualifies for SAQ A-EP, a lighter compliance burden than handling raw card data, while still giving you full control over your checkout’s layout and flow.

This is the pattern we build for most ecommerce and SaaS checkouts now. You keep your brand, your conversion-optimised flow, and your analytics, without taking on the liability of storing or transmitting raw card numbers.

Direct API integration

Your server collects card details directly and sends them to the gateway’s API. This gives you complete control — useful for marketplaces, platforms taking payments on behalf of other merchants, or businesses with genuinely unusual checkout requirements — but it brings the full weight of PCI DSS with it, typically SAQ D, the most demanding self-assessment level, covering network segmentation, logging, access control and regular vulnerability scanning.

Most businesses that think they need this actually need embedded fields instead. Direct API integration is a genuine project with ongoing compliance overhead, not a weekend task, and we talk most clients with a normal retail or service checkout out of it unless there’s a specific reason — like building a platform that processes payments for other sellers — that the other two patterns can’t satisfy.

The Australian payment landscape you’re actually integrating against

Picking a gateway in Australia means supporting a payment mix that looks different from the US or UK defaults most payment SDKs are written for. A checkout that only handles Visa and Mastercard is leaving real conversion on the table here.

Cards, and what’s changing with interchange

Visa, Mastercard and Amex remain the baseline. What’s shifting is the economics underneath them: the RBA has confirmed interchange caps are being cut on consumer credit and debit cards, which flows through to lower merchant service fees over time. If your checkout logic calculates and displays surcharges based on card type, this is also the moment to revisit that logic — see the surcharge ban section below, because from 1 October 2026 that logic needs to come out of your checkout entirely for eftpos, Visa and Mastercard transactions.

Buy now, pay later

Afterpay, Zip and Klarna are now regulated credit products in Australia, not a payment method bolted on outside consumer credit law. Since the BNPL reforms commenced on 10 June 2025, BNPL contracts are brought under the National Consumer Credit Protection Act, with modified responsible lending obligations and fee caps that providers must comply with — see ASIC’s Regulatory Guide 281 on low cost credit contracts for the detail. As the merchant integrating BNPL, most of that compliance burden sits with the provider, not you — but it changes what you should ask a BNPL partner before integrating: how they handle affordability checks, what happens to a declined checkout experience, and how refunds and partial refunds flow back through their system into yours.

PayTo and PayID

PayTo is the real-time, account-to-account payment rail intended to eventually replace the ageing BECS direct debit system, and adoption is accelerating — PayTo payment volumes have been growing at close to 50% half-on-half as more banks and billers switch on support. PayID is the addressing layer that lets someone pay using a phone number, email or ABN instead of typing out BSB and account numbers, and tens of millions of PayIDs are now registered across Australian bank accounts.

For integration purposes, these matter most for subscription billing, utilities, and any business currently relying on BECS direct debit for recurring payments. PayTo agreements are set up once, give the customer visibility and control over what they’re authorising, and settle faster than the old direct debit batch files that can take days to clear and bounce. If you’re maintaining BECS integration today, budget a migration path — the direction of travel is clear even if there’s no hard cutover date forcing your hand yet.

BPAY, Apple Pay and Google Pay

BPAY still matters for invoice-based businesses and B2B payments where the customer wants to pay through their own banking app on their own schedule. Apple Pay and Google Pay are largely handled for you if you’re using embedded fields or hosted checkout through a modern gateway — they’re wallets layered on top of the card network, not a separate integration, though you do need to verify your domain with Apple and configure merchant capabilities correctly, which is a common source of silent failures in testing.

The October 2026 surcharge ban: what actually changes in your code

From 1 October 2026, surcharging on eftpos, Visa and Mastercard cards is banned in Australia under the RBA’s Conclusions Paper on merchant card payment costs. Amex and UnionPay are covered from the same date too — Amex withdrew its separate no-surcharge undertaking with the RBA to align with it. This is a genuine checkout engineering task, not just a pricing policy update, and it’s the main reason payment integration has landed back on a lot of technical roadmaps this year.

If your checkout currently calculates a surcharge — a percentage fee added at the payment step based on card type or BNPL provider — that logic has to come out for the covered payment methods. In practice that touches more of the stack than people expect:

• Checkout UI: remove the surcharge line item, the card-type detection that triggers it, and any “avoid the surcharge by paying with X” messaging.
• Order totals and tax calculation: if surcharge was treated as a taxable line item, removing it changes GST calculations on the order, which needs to flow through correctly to invoices and your accounting system.
• Pricing strategy: businesses that surcharged are mostly either absorbing the cost into base pricing or adjusting margins elsewhere — that’s a commercial decision, but your checkout and product pricing logic need to reflect whichever path is chosen before the deadline, not after.
• Reporting: any dashboard or reconciliation process that separates “surcharge revenue” from product revenue needs updating, or it will keep showing a line that no longer exists.

Around 16% of Australian businesses were surcharging at the time the reform was announced, so if you’re not one of them, the direct impact is limited to checking your gateway configuration doesn’t have a dormant surcharge rule sitting switched on. If you are, this is worth scoping properly rather than patching in September 2026 — it touches checkout, accounting sync and reporting in ways that are easy to half-fix and leave a mismatched ledger.

Choosing a gateway or payment service provider

The “best” gateway question doesn’t have a single answer, because the right choice depends on what you’re actually building. A few factors matter more than the marketing comparison pages suggest.

Local payment method coverage

Not every gateway supports PayTo, PayID or every BNPL provider natively. Stripe and Adyen have broad international coverage with growing Australian local method support; Australian-headquartered providers like eWAY, Zeller and eftpos-focused processors often have faster or more direct support for local rails and more Australian-based support staff, which matters when something breaks at 7am before a bank processes overnight settlement files.

Settlement timing and cash flow

Settlement speed varies by provider and by payment method, and it matters more to cash flow than most businesses account for upfront. A gateway that settles next business day versus one that settles in two to three days is a meaningfully different working capital position for a business doing six-figure monthly volume, especially one carrying BNPL settlement delays on top.

Developer experience and existing stack fit

If you’re on Shopify or WooCommerce, the practical shortlist narrows fast to whatever has a mature, maintained plugin, because a hand-rolled integration against a platform that releases frequent core updates is an ongoing maintenance cost most businesses underestimate. For custom web apps, SDK quality, sandbox/testing environments, and webhook documentation quality are the things that actually determine how long integration takes — not the headline feature list. This is exactly the kind of decision we work through with clients as part of API and integrations scoping, because the gateway choice has knock-on effects for everything downstream of it.

Fit with accounting and ERP

A gateway that reconciles cleanly against Xero or MYOB saves real bookkeeping hours every month. For businesses running an ERP, this is where payment integration stops being a standalone decision and becomes part of the broader systems architecture — our ERP integration work regularly touches payment reconciliation as one piece of a larger data flow between sales, inventory and finance.

A rough shape of the Australian market

We don’t think a vendor-by-vendor scorecard is honest — pricing changes, feature sets shift, and anyone claiming a definitive ranking is usually selling something. But the rough shape of the market is worth knowing before you start requesting demos.

• Stripe has the deepest developer documentation and the broadest international method support, and is the default choice for custom web apps and SaaS businesses that expect to scale or eventually sell internationally.
• Adyen targets larger merchants and enterprise ecommerce, with strong unified commerce features for businesses running both online and in-store payments through one platform.
• eWAY is Australian-founded and historically strong with local businesses that want AU-based support and straightforward integration with common local ecommerce platforms.
• Zeller has built a strong reputation in Australian in-person and card-present payments, with online payment capability extending out from that base.
• Westpac PayWay and similar bank-provided gateways suit businesses that already bank with the provider and want settlement and merchant services handled by the same institution, though developer experience tends to lag the dedicated payment companies.

None of these is universally “best.” A SaaS business building a custom checkout with international ambitions and a B2B supplier running mostly BPAY and EFT invoicing have almost nothing in common in terms of what matters in a gateway, which is why we always start a gateway decision from the actual payment mix and sales channels, not a feature comparison table.

3D Secure, tokenisation and fraud screening

Beyond choosing an integration method, there are three security layers worth understanding before you build, because they affect both your fraud exposure and your customer’s checkout experience.

3D Secure (3DS2) and the liability shift

3D Secure is the authentication step — sometimes a redirect to the bank’s app, sometimes invisible — that confirms the person entering a card is actually the cardholder. Under card scheme rules, successfully completing 3DS shifts fraud liability for that transaction away from the merchant and onto the issuing bank in most cases. Skip it to avoid friction and you keep full liability for chargebacks on fraudulent transactions; most gateways now default to “frictionless” 3DS flows that only interrupt the customer with an extra step when the issuing bank’s risk engine flags something, which keeps conversion high while still getting the liability protection on the transactions that need it.

Tokenisation for saved cards

When a customer saves a card for next time, what actually gets stored is a token — a reference your systems can use to charge the card again, issued by the gateway or, increasingly, a network token issued directly by Visa or Mastercard that survives card reissues and expiry updates automatically. Network tokens matter in practice because they quietly fix a problem that used to cause real revenue loss: a customer’s card expires or gets reissued after a fraud flag, and a subscription payment that would have failed instead keeps working because the network token updates behind the scenes. Not every gateway supports network tokenisation yet, and it’s a reasonable question to ask when you’re evaluating providers for any business with recurring billing.

Fraud screening before it becomes a chargeback

Most gateways include baseline fraud tools — velocity checks (too many attempts too fast from one card or IP), address verification, and device fingerprinting — switched on by default or with a simple toggle. For most small and mid-sized Australian businesses, the default rules from a mainstream gateway are genuinely sufficient; building custom fraud scoring is rarely worth it below a volume where chargebacks are a measurable cost. Where we do see it pay off is for businesses with a specific abuse pattern — digital goods that get resold, or a product category that attracts stolen-card testing — where tuning the existing rules against your own order data catches far more than generic defaults.

Recurring billing: cards, PayTo and the dunning problem

Subscription and recurring billing businesses have a payment integration problem the one-off checkout crowd mostly doesn’t: payments that are supposed to succeed automatically, on a schedule, without the customer present to retry anything. Card failures from expired cards, reissued numbers and simple insufficient funds are a routine, grinding source of lost revenue if nothing is actively managing them — we go into the retry logic, card-updater integration and communication sequencing in more depth in our guide to subscription billing automation, since it’s a large enough topic to deserve its own treatment.

What belongs specifically in the integration layer is making sure your gateway choice actually supports the retry and update mechanisms you’ll need: card account updater services, network tokenisation as covered above, and ideally PayTo support for businesses that want to move recurring billing off cards entirely. PayTo agreements for recurring payments tend to fail less often than card-based billing because there’s no card to expire, though the agreement itself needs to be re-established if the customer revokes it through their banking app, which your billing logic needs to detect and handle rather than silently retrying a dead agreement.

Webhooks, reconciliation and avoiding duplicate transactions

A payment gateway integration isn’t finished when the checkout works. It’s finished when a payment event reliably updates your order, your CRM and your accounting system exactly once, including when the gateway retries a webhook delivery because your server was slow to respond the first time.

Webhooks are the standard mechanism here — the gateway calls your endpoint when something happens (payment succeeded, payment failed, refund issued, dispute opened) rather than you polling its API for changes. We’ve written separately about how webhooks and polling compare as sync patterns, and the short version for payments specifically is: always use webhooks as the source of truth for payment status, and never rely purely on the redirect back to your site after checkout, because a customer closing their browser before the redirect completes doesn’t mean the payment failed.

The part that actually breaks integrations in production is idempotency. Gateways retry webhook delivery if your server doesn’t respond quickly with a 200 status, which means the same event can arrive more than once. Without a dedupe check keyed on the gateway’s event ID, a retried webhook creates a second order, a duplicate invoice sync, or a second confirmation email. We’ve covered the general pattern in detail in our guide to idempotency and retries — for payment webhooks specifically, store every processed event ID and check against it before acting, every time, with no exceptions for “it probably won’t happen twice.”

Reconciliation is the other half. A settlement from your gateway rarely matches a single order one-to-one once BNPL fees, refunds and chargebacks are in the mix — the amount that lands in your bank account on a given day is a net figure covering dozens of individual transactions. Reconciliation logic needs to match gateway transaction IDs through to orders and invoices, not just match totals, or discrepancies get written off as “rounding” when they’re actually a sign something’s double-processing or silently failing.

BNPL integration: what merchants need to get right

Most BNPL integration happens through the provider’s own SDK or plugin, which handles the regulatory-sensitive parts — affordability assessment, disclosure, the credit decision itself — on their side. Your job as the merchant is narrower but still has real failure modes.

• Handle declines gracefully. A BNPL decline isn’t the same as a card decline and shouldn’t be presented with the same generic error — customers need a clear path to another payment method without feeling like they’ve been flagged for something.
• Get refund logic right. BNPL refunds often need to go back through the BNPL provider rather than as a direct store credit, and partial refunds on an order split across instalments need testing, not assumption.
• Keep order status in sync during the authorisation window. Some BNPL methods authorise before fully confirming, which means your order management needs a “payment pending confirmation” state, not just paid or unpaid.
• Reconcile settlement timing separately. BNPL providers typically settle on a different schedule to card payments, so a reconciliation process built only around same-day card settlement will misreport BNPL orders as outstanding when they’re not.

Common mistakes we see in payment gateway integrations

• Treating the integration as finished at launch. Gateway APIs version, webhook event schemas change, and BNPL providers update their terms. An integration nobody owns after go-live quietly drifts out of date.
• No sandbox testing for failure paths. Most testing covers the happy path — payment succeeds. Declines, timeouts, partial refunds and disputed charges are where real integrations break, and they’re rarely tested before launch.
• Storing more card data than necessary. Even a “just for support purposes” habit of logging full card numbers or CVVs anywhere — error logs included — is a PCI violation and a serious data breach risk.
• Relying on the browser redirect instead of the webhook. If your order confirmation logic only fires on the customer landing back on your success page, abandoned redirects and network hiccups will leave you with paid orders marked as unpaid.
• No idempotency check on webhook handlers. Covered above, and still the single most common cause of duplicate orders we see when auditing an existing integration.
• Ignoring settlement currency and timing mismatches. Multi-currency stores in particular need to reconcile against the settlement currency the gateway actually pays out in, not the display currency shown to the customer.
• Building a bespoke direct API integration when embedded fields would have done the job. This one costs the most in ongoing compliance overhead for the least functional benefit, in our experience.

Frequently Asked Questions

Do I need to be PCI DSS compliant if I use Stripe or another gateway?

Yes, but the scope depends on your integration method. If you use hosted checkout or embedded fields, card data never touches your server, which qualifies you for a lighter self-assessment (SAQ A or SAQ A-EP) rather than the full SAQ D required for direct API integrations that handle raw card data. You still need to complete the relevant SAQ and maintain basic security practices — using a gateway doesn’t remove the requirement, it reduces its scope.

What does the October 2026 surcharge ban mean if I don’t currently surcharge?

If you’re not applying a card surcharge today, the direct impact is minimal — check your gateway dashboard to confirm no surcharge rule is configured and sitting dormant, and move on. The bigger relevant change for most businesses is the falling interchange cap, which should flow through to lower merchant service fees over time regardless of whether you ever surcharged.

Should I integrate BNPL providers separately or through my main gateway?

Many gateways (Stripe and Adyen among them) now offer BNPL options as payment methods within their own checkout, which is simpler to integrate and reconcile than adding each BNPL provider’s own SDK separately. The trade-off is slightly less control over presentation and occasionally a narrower set of BNPL providers than integrating directly. For most businesses, going through the primary gateway is the lower-maintenance option unless a specific BNPL provider’s direct terms are materially better for your margin.

How long does a payment gateway integration actually take?

A standard embedded-fields integration on an established ecommerce platform with an existing plugin can be live in days. A custom checkout flow with embedded fields, proper webhook handling, idempotency and accounting reconciliation typically runs two to six weeks depending on how many systems it needs to sync with. Direct API integrations with full PCI scope are a materially larger project and should be scoped like one, including the ongoing compliance workload, not just the build.

Can I switch payment gateways without disrupting existing subscriptions?

It’s possible but needs careful planning, particularly for stored card details and recurring billing, since card tokens generally can’t be transferred between gateways directly. Most migrations run both gateways in parallel for a period, migrating subscriptions at renewal or prompting customers to re-enter payment details, rather than attempting a single cutover date. A staged cutover with a rollback plan beats a hard switch every time.

Do I need PayTo if I already use direct debit through BECS?

Not immediately — there’s no mandated cutover date forcing existing BECS integrations to migrate right now. But PayTo adoption is growing quickly as banks roll out support, and it offers real advantages for recurring billing: faster settlement, lower failure rates than batch-based direct debit, and clearer customer visibility over what they’ve authorised. Treating it as a planned migration over the next year or two is more sensible than either ignoring it or rushing a cutover.

Where to start

If you’re auditing an existing payment integration, start with the webhook handler and the idempotency logic — it’s the part most likely to be quietly broken and the part that causes the most damage when it is. If you’re building new, the decision that matters most isn’t which gateway logo looks best on a comparison page, it’s matching the integration method (hosted, embedded or direct API) to how much compliance overhead your business can actually sustain long-term.

If the October 2026 surcharge ban touches your checkout, or you’re weighing up a BNPL addition, a PayTo migration, or a gateway switch alongside a broader ecommerce automation project, it’s worth scoping the whole payment flow rather than patching the one piece that’s currently causing pain. Happy to have a conversation about what that looks like for your systems specifically — no pressure, just a practical look at what needs to change and what doesn’t.