Payment Gateway & Third-Party Integration
I integrate payment gateways and third-party services — billing and subscriptions, WhatsApp Business API, Twilio, VoIP, transactional email and SMS — into products where the integration failing quietly would cost you money.
I have built a payment gateway from the inside, not only consumed one: multi-bank integrations, fraud rate limiting, and the reconciliation work that tells you when your records and the provider's disagree. That perspective changes how you write the integration.
Why do payment integrations go wrong?
Almost never in the happy path. A card charge on a working connection is the easy twenty percent, and it is the part every tutorial covers.
They go wrong in the failure cases: the webhook that arrives twice, the webhook that never arrives, the user who closes the tab between payment and confirmation, the refund issued from the provider's dashboard that your database never hears about, the subscription that renews on an expired card at 3am.
Every one of those has a correct handling, and each is a place where a rushed integration silently loses or double-charges money. Building for them is most of the actual work.
- Idempotency keys, so a retried request cannot charge twice
- Webhook signature verification on every inbound event
- Duplicate and out-of-order webhook handling
- Payment state machine in your database as the source of truth
- Reconciliation job comparing your records against the provider's
- Dunning and retry flow for failed renewals
Which payment provider should we use?
Mostly determined by where your customers and your bank account are, not by feature comparison. Stripe is the default where it operates and the developer experience is genuinely the best. Razorpay, PayU or Cashfree for India. PayPal where your buyers expect it, whatever you think of it.
I build the integration behind an interface in your codebase rather than scattering provider SDK calls through your business logic. Adding a second provider or switching later then costs days rather than a rewrite — which matters more than it sounds, because expanding into a new market almost always means a new provider.
What about PCI compliance and card data?
The short answer for most products: do not touch card data. Use the provider's hosted fields or checkout so the card number never reaches your server, and your compliance obligation drops to the lightest self-assessment tier.
I will tell you plainly where your setup sits and what it obliges you to do. I am an engineer, not a QSA — for a formal audit you need a qualified assessor, and I will say so rather than imply I can sign off on compliance.
What else do you integrate?
The messaging and communication layer that most products need and few build reliably: WhatsApp Business API for customer conversation and notifications, Twilio for SMS and voice, VoIP and call systems, and transactional email through SES or similar.
The recurring failure mode is identical to payments — these are all remote systems that will be down, rate-limited or slow at some point. I put them behind a queue with retries and a dead-letter path, so a provider outage delays a notification instead of throwing an error at your user or losing the message entirely.
What you get
- Payment or third-party integration, live in production
- Webhook endpoints with signature verification and replay protection
- Idempotent request handling
- Payment or message state machine in your own database
- Reconciliation job and an operations runbook for mismatches
- Sandbox environment and test coverage for the failure paths
- Admin visibility into failed transactions and retries
Tools I use for this
A good fit if
- A product adding paid plans, subscriptions or marketplace payouts for the first time
- An existing integration that double-charges, loses webhooks or drifts out of sync
- Expanding into a market that needs a second payment provider
- A business wiring WhatsApp, SMS or voice into its customer workflow
Not a fit if
- Becoming a payment processor or acquiring your own PCI Level 1 scope — that is a company-scale programme, not a contract
- Formal PCI DSS certification sign-off; you need a Qualified Security Assessor and I will refer you to one
- Crypto payment rails and custody — outside what I will take responsibility for
- A no-code checkout on a hosted store platform, where a plugin already does it
Work that shows this
Paymish Payment Gateway
A secure, low-latency payment gateway processing $2M+ monthly, with multi-bank integrations, fraud detection and 99.99% uptime.
Read the case studyMakanify CRM
A comprehensive real-estate CRM for builders and brokers: leads, clients, projects, tasks, documents and omnichannel communication in one place.
Read the case studyQuestions clients ask
How long does a payment integration take?
A straightforward one-off checkout on a modern provider is typically one to two weeks including the failure paths and sandbox testing. Subscriptions with plan changes, proration, dunning and reconciliation are usually three to five weeks. Marketplace payouts and multi-party splits take longer, because the money movement rules are genuinely complicated.
Can you fix an integration someone else built?
Yes, and it is a large share of this work. It starts with an audit: I trace every money path, compare your database against the provider's records for a sample period, and give you a written list of what is broken and what it is costing. Clients are frequently surprised by what the reconciliation turns up.
Do you handle refunds, chargebacks and disputes?
The engineering side, yes — refund flows, chargeback webhooks updating your order state, and admin tooling so your support team can act without a developer. Actually contesting disputes with the provider is your commercial process; I make sure your system records what you need to contest them.
How do we test payments without spending real money?
Every serious provider has a sandbox with test cards covering the interesting failures — declines, insufficient funds, 3D Secure challenges, expiry. I build against sandbox first, write automated tests for the failure paths, and then run a small set of real low-value transactions in production before you go live, because sandboxes always differ from production somewhere.
Need payment & third-party integrations?
Tell me what you're building and what's in your way. I reply within 24 hours with honest questions and a rough estimate — no sales sequence.