Taking money is the one part of an application you can't get wrong quietly. I implement request signing, verify gateway responses with checksums, handle webhooks idempotently and add a fallback verification step for customers who never return from the gateway redirect.
For platforms with balances, such as wallets and subscriptions, I build the ledger underneath: balanced entries, transactions, reversals and reconciliation. FinCore, my public wallet API, shows how I approach that. I never store raw card data; the gateway handles card details and the application keeps references and statuses.
What you get
- Request signing and SHA256 / HMAC checksum verification
- Idempotent webhook handlers
- Fallback status checks for dropped redirects
- Wallet, balance and ledger logic
- Refunds, reversals and reconciliation
- Transaction logging and audit trails
Frequently asked questions
Which payment gateways do you work with?
I integrate gateways that expose an API and webhooks. Send me the gateway's documentation and I'll confirm fit and an approach.
Do you store card details?
No. Card data stays with the gateway. The application stores only references, statuses and the audit log.
Can you fix a broken or flaky payment integration?
Yes. Debugging payments from logs, signatures and webhook payloads is part of my day-to-day production work.
Can you build wallet or credit balances?
Yes: double-entry ledgers with atomic transactions, idempotent top-ups and refunds, and reconciliation so balances can be trusted.
