Payment integration that never credits twice.
For fintech products, brokers and platforms that take deposits or pay out.
A payment that works in the demo is easy. One that never double-charges, never loses a callback and reconciles at month end takes care. I have shipped payment integrations for a live broker, a theme park and a multi-tenant payment gateway service.
Delivered in production
Payment gateway and PSP integration
Checkout.com, Octopus and other providers: payment sessions, 3-D Secure flows, webhooks and refunds.
Apple Pay and Google Pay
Wallet payments as separate methods, tested end to end before release.
Webhook safety
Signature verification before trusting a payload, idempotent processing, retries and alerts.
Reconciliation
Status polling and reconciliation jobs, so a missed callback never turns into lost revenue.
Payment microservices
A standalone, multi-tenant gateway with HMAC request signing, replay protection and key rotation.
Testable payment flows
Deposits and refunds that the team can run end to end on a laptop, with the traps written down.
What I can build next
Ledgers, wallets and stablecoin funding
Not yet delivered as a finished product
Designs I can build with you, grounded in the payment work above. I have not yet run a double-entry wallet or on-chain deposit detection in production.
Double-entry ledger
Append-only entries, balances derived from them, and one posting path with an idempotency key per money event.
Wallets and internal transfers
User, fee and clearing accounts, with locking so two withdrawals can never both pass the balance check.
Withdrawals with approval
Maker-checker payouts with a second approver and a record of who released what.
USDT and USDC funding
Through a crypto payment provider first. Direct on-chain detection, confirmations and matching are a later, larger piece.
Payment to trading account
A provider deposit credited to an MT5 balance exactly once, with the unknown outcomes handled by design.
Before it goes liveHolding client balances or moving stablecoins can be regulated activity. Get legal advice for your market before launch. I design the system so its controls can satisfy that advice.
Proof, not promises
- Payments and crypto back office at a live brokerJob · CFI FinancialApple Pay, Google Pay and Benefit deposits through Checkout.com, live in production at a multi-asset broker.
- Octopus payment gateway microserviceJob · AppnovationA standalone Octopus payment gateway microservice with HMAC-SHA256 signing, key rotation and webhook delivery.
- Ocean Park e-commerce ticketing platformJob · AppnovationType Approval compliant payment polling, idempotent fulfilment and reconciliation for Ocean Park ticketing.
How we can work together
Start small. Commit when it works.
Every engagement starts with a written scope. You know what you are getting, what it costs and what is left out before any work begins.
- 01Fixed fee · 1 to 3 weeks
Technical discovery sprint
I review your requirements, existing code and third-party access, then deliver a written architecture, a feasibility and risk report and a milestone plan. Yours to keep, whoever builds it.
- 02Paid by milestone
Fixed-scope MVP build
A defined first release, built in milestones on a staging environment you can use throughout. You pay for delivered milestones, not for hours.
- 03Monthly
Founding engineer contract
I join as your hands-on technical owner: architecture, backend, front end, infrastructure and releases, working directly with you.
- 04Part-time · monthly
Fractional technical lead
You already have a developer or a small team. I own the architecture and the risky parts, review the work and keep delivery honest.
I quote each engagement in USD after a first call. I work from Malaysia with no agency layer, so the budget goes into engineering, not account management. I price on scope and responsibility, and I am not the cheapest option.
- You work with the person doing the work
- Written scope and milestones
- Source code, access and documentation handed over
- NDA on request
How we would work
- 01
A short call
A no-obligation conversation about what you are building, what exists already and what success looks like.
- 02
A written scope
What I will build, what I will not, the risks and the price. Larger or unclear projects start with a short, paid discovery sprint.
- 03
Small, visible releases
You see working software early and often, on a staging environment you can click through.
- 04
Handover and support
Source code, access, documentation and runbooks, with ongoing support if you want it.
Related notes
- 11 Nov 2026Crediting a payment to an MT5 balance exactly once: claim, act, resolve, reconcileDesign proposal
- 11 Nov 2026Double-entry ledger design for fintech startups: the smallest version that is still correctDesign proposal
- 4 Oct 2026Payment webhooks that never double-credit: signatures, idempotency and reconciliationFrom production work
Questions
- Which payment gateways have you worked with?
- Checkout.com (cards, Apple Pay, Google Pay, Benefit), Stripe, Octopus in Hong Kong, and Malaysia's FIUU in sandbox. Most providers follow the same pattern, so a new one is mostly careful reading of their documentation.
- Some of our payments go missing or get credited twice. Can you fix that?
- Usually it is a webhook that failed, arrived twice or was never verified. I trace the exact payment through your logs and the provider dashboard, then add idempotency and reconciliation so it cannot happen silently again.
- Will you store card numbers?
- No. Card data stays with the payment provider through hosted fields and tokens, which keeps your PCI scope small.
- Can you add crypto or stablecoin payments?
- Through a crypto payment provider, yes, and that is the route I recommend first: the provider handles addresses and confirmations and you receive a signed callback. I have integrated one in my own prototype against its test API. Running your own on-chain detection is something I can design and build, and have not yet run in production.
- Can you build a wallet or ledger for our product?
- I can design and build it, and I will be clear that it would be my first double-entry wallet in production. The patterns it rests on (idempotent posting, reconciliation, approval flows, decimal precision) are ones I use in production today.
Tell me what you are building.
A few lines are enough: what it is, where it stands today, and what you need from an engineer. The form is just below, or email me if you prefer. I reply within two working days.