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.

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.

  1. 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.

  2. 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.

  3. 03Monthly

    Founding engineer contract

    I join as your hands-on technical owner: architecture, backend, front end, infrastructure and releases, working directly with you.

  4. 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

  1. 01

    A short call

    A no-obligation conversation about what you are building, what exists already and what success looks like.

  2. 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.

  3. 03

    Small, visible releases

    You see working software early and often, on a staging environment you can click through.

  4. 04

    Handover and support

    Source code, access, documentation and runbooks, with ongoing support if you want it.

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.

Other services