Payments
Payment gateway integration that survives the edge cases
Integrating a gateway is easy. Making sure a duplicated callback never double-charges a customer, and that a failed payment never leaves an orphaned order, is the part that takes experience.
You are probably here because
If two or three of these are true, this is a problem worth fixing properly.
- You need to add a payment method your customers in a specific market expect
- Customers have been double-charged, or orders fulfilled without payment
- Failed payments leave records in a half-finished state
- Nobody can reconcile what the gateway says against what your database says
- Adding a new provider means touching checkout and order creation at once
- Refunds are processed manually in the gateway dashboard
What you get
- End-to-end gateway integration
- Payment initiation, redirect or hosted flow, asynchronous confirmation handling, and order fulfilment that only happens once payment genuinely clears.
- Idempotent callback handling
- A replayed, duplicated or out-of-order notification from the gateway can never double-charge a customer or double-fulfil an order.
- Failure paths that unwind cleanly
- Timeouts, declines and abandoned payments roll back to a consistent state instead of leaving orphaned orders or subscriptions behind.
- Reconciliation and reporting
- A daily reconciliation between gateway settlement and your own records, so a mismatch is caught by a report rather than by a customer.
How it runs
-
Map the money
Every state a payment can be in, and what your system should do in each. Most integration bugs are missing states, not bad code.
-
Integrate against sandbox
Full flow in the gateway sandbox, including the failure cases that are hard to trigger in production.
-
Harden the callbacks
Idempotency keys, signature verification, replay handling and retry behaviour, each covered by tests.
-
Go live behind a flag
Released to a small share of traffic first, with reconciliation running from day one, before it becomes the default.
Questions we get asked
Which payment gateways do you work with?
We have integrated gateways in both Indian and international contexts — Razorpay, CCAvenue, Stripe, PayPal and others. The integration patterns are largely the same; what differs is the callback model, settlement timing and the local compliance requirements.
What does idempotency mean here, and why does it matter?
It means the same instruction can arrive twice without causing two charges. Gateways retry notifications when they do not get a clean acknowledgement, and networks duplicate messages. Without idempotency this shows up as customers being charged twice — which is the single fastest way to lose trust.
How long does a gateway integration take?
A straightforward integration into an existing, well-structured checkout is typically two to four weeks including testing. If the checkout flow itself needs untangling first, longer — and we will say so before starting rather than halfway through.
Can you add a gateway without disturbing our existing payment methods?
Yes. New providers should go in behind a feature flag and be released to a fraction of traffic first. Existing methods are not touched until the new one is proven.
Do you handle PCI compliance?
We design integrations so card data never touches your servers, using the gateway hosted or tokenised flows, which keeps your compliance scope as small as possible. We are engineers rather than auditors, so formal certification is something your QSA signs off.
Can you fix an integration somebody else built?
Often, yes. We start by reconciling a period of real transactions against gateway settlement data, which usually surfaces the actual problem faster than reading the code.
Tell us which gateway
Let us know which provider and what your checkout looks like today. We will come back with a scope and a figure.