Payment gateway integration that keeps card data out of your PCI scope.
I design payments so you can add or swap gateways without rewriting your product, keep card data away from your main platform and never take a payment twice. Hompay, the payments stack I shaped for Homhero, was built this way.
Remote across Australia and New Zealand. On-site in South East Queensland.
Who this is for
SaaS teams for whom taking payments is part of the product, not just a checkout page.
- You’re adding payments to your platform for the first time and want the design right before customers depend on it.
- You’re tied to one gateway and want a second, for pricing, coverage or resilience.
- Card data passes through your own servers today, and you want to shrink your PCI DSS scope.
- Customers are occasionally charged twice, or a payment succeeds at the gateway but never shows up in your system.
- Payments need to flow on into accounting, trust accounts or payouts, not stop at the gateway dashboard.
What I design and build
The layer between your product and the payment providers, and the systems on either side of it.
One payment interface
A provider interface your product talks to, with an adapter for each gateway. Adding or replacing a gateway becomes new code in one place, not a change to every checkout.
Card data out of scope
Tokenised cards held in a separate PCI vault, so your main platform only ever sees tokens and far less of it falls within PCI DSS scope.
No double charges
Idempotency from the pay button to the gateway call, so retries, timeouts and double-clicks can’t take a payment twice.
Events and reconciliation
Gateway webhooks handled asynchronously and safe to process twice, and payments matched against what actually settled.
The systems around payments
Accounting and business APIs such as Xero, PayPal and Zoho, and partner APIs with scoped permissions and event delivery.
How a payments engagement runs
Usually design and build, starting with one gateway done properly. If you already have payments in production, it can start as a review instead.
Map the flows
Who pays whom, when and through which gateway, and what happens on refunds, chargebacks, failures and timeouts.
Design the boundary
The provider interface, where card data lives and how payment state moves through your system, written up so your developers and your PCI assessor can follow it.
Build the first gateway end to end
Including the unhappy paths: timeouts, duplicate webhooks, partial refunds and payments that settle late.
Add the next gateway
A second gateway proves the interface. After that, your team can add more without me.
Where I’ve built this
Payments and integrations have been part of almost every platform I’ve worked on.
Property & channel management platform
Homhero takes payments for holiday-rental managers across Australia and New Zealand and connects to the major booking channels, so payments and integrations sat at the centre of the platform.
- Shaped Hompay: tokenised cards, a separate PCI vault and multiple Australian gateways behind one interface.
- Channel integrations with Airbnb, Booking.com, Vrbo, Expedia, Google Hotels and Marriott.
- AWS Lambda
- DynamoDB
- EventBridge
- Cognito
- Angular
- Ionic
Trust accounting SaaS platform
On Homtrust, money movement had to be exactly-once and reconcile with the bank. The same discipline applies to card payments.
- Idempotency keys and unique constraints so a double-submit or crash can never double-debit a ledger.
- CDR / Open Banking bank feeds with per-account consent and automated reconciliation.
- TypeScript
- NestJS
- GraphQL
- PostgreSQL
- MikroORM
- AWS CDK
Consulting engagements
Through DaTom I’ve connected client systems to the accounting and payment APIs they already use.
- Connected systems through Xero, WorkflowMax, PayPal, Zoho, Google and Apple APIs.
- Node.js
- Google Cloud
- AWS
- Mobile
Questions I’m often asked
Do you handle PCI DSS certification?
No. I design the architecture so that less of your system is in scope and work with your assessor on it, but certification is between you, your assessor and your payment provider.
Which gateways do you work with?
The design doesn’t depend on any one of them. Hompay put several Australian gateways behind a single interface, and the same approach works with global providers.
Can we start with a single gateway?
Yes, and most teams should. The interface costs little up front and turns the second gateway into a contained piece of work instead of a rewrite.
Other ways I help
Adding payments, or another gateway?
Tell me how payments work in your product today and where you want them to go. I’ll tell you what I’d change first.