Idempotency
A retried request must not create a second charge. The single most important detail.
Payment Gateway Integration
Payment Gateway Integration Where the Failure Cases Are Handled
Taking a successful payment is the easy part, and it is what every tutorial covers. Payment gateway integration is really about everything else: declines worth retrying and declines that are not, webhooks arriving twice or out of order, refunds, disputes, and making certain a customer is never charged twice.
We Build for the Cases That Cost Money
A duplicate charge is a refund, a support conversation and usually a lost customer.
Webhooks Verified
Signature-checked, deduplicated and safe out of order, because they arrive that way.
Declines Distinguished
A soft decline is worth retrying; a hard one is not. Treating them alike loses money either way.
Scope Minimised
Card details handled by the provider so your compliance surface stays small.
Reconciliation
Your records and the gateway's should agree, and that is checked rather than assumed.
Payments, Explained
What Has to Be Right?
Four things, each causing real financial problems when wrong.
Discuss Your Payments →- 1
No Double Charges
Network retries and impatient clicks must not produce two payments.
- 2
Webhook Handling
The gateway reports outcomes asynchronously, and that message can repeat or arrive late.
- 3
Strong Authentication
Additional verification steps the flow must handle rather than break on.
- 4
Refunds and Disputes
Full and partial refunds, chargebacks, and what your system does about each.
What Payment Integration Covers
The payment flow, the asynchronous events, and reconciliation.
Marketplace payments have additional requirements — see marketplace development.
How We Integrate Payments
Map every state a payment can be in, then build for all of them.
Map Payment States
Pending, authorised, captured, failed, refunded, disputed.
Choose the Gateway
On markets, methods, fees and the features you genuinely need.
Build the Flow
With idempotency and authentication steps handled.
Handle Webhooks
Verified, deduplicated, and safe when replayed.
Test Failures
Declines, timeouts, duplicate webhooks and partial refunds.
Correctness
Why Idempotency Is Not Optional
Without it, an ordinary network timeout can charge a customer twice.
How does a double charge happen?
Your server sends a charge request. The gateway processes it successfully. The response is lost to a network problem, so your server sees a timeout and retries — and the gateway, with no way to know it is the same charge, processes it again.
An idempotency key solves this: the same key on a retry returns the original result instead of creating a second charge. Every major gateway supports it and it is frequently omitted.
The other route is the customer clicking submit twice. The same protection covers both.
Why are webhooks difficult?
They are asynchronous messages about events that already happened, and gateways guarantee delivery rather than order or uniqueness. The same event can arrive twice; a later event can arrive before an earlier one.
Handlers must therefore be safe to run repeatedly and must not assume sequence. Marking an order paid twice should be harmless; a handler that increments a balance is not.
They must also be signature-verified. An unverified endpoint accepts a forged message claiming a payment succeeded, which is a straightforward way to obtain goods for free.
Questions,answered.
Payment gateway integration connects your application to a payment provider — covering the payment flow, duplicate protection, webhook handling, refunds and reconciliation between your records and theirs.
It depends on your markets, the payment methods your customers use, the fee structure, and whether you need subscriptions or split payments. The differences that matter are usually commercial rather than technical.
Your scope is much smaller if card details never touch your servers, which is how modern gateway integrations work. That is the main reason to use the provider's hosted fields rather than collecting card data yourself.
With idempotency keys on every charge-creating request, so a retry returns the original result rather than creating a second payment. This covers both network retries and customers clicking twice.
Because they can arrive twice, out of order, or late. Handlers must be safe to run repeatedly and must not assume sequence — and the signature must be verified, or the endpoint accepts forged payment confirmations.
Still deciding if payment gateway integration is right for you?
Talk to UsThe Timeout That Charged Them Twice
A payment integration is usually tested by making a payment. It succeeds, the order appears, the money arrives, and the work is considered done.
What is never tested is the response that does not arrive. The gateway took the money and the confirmation was lost in transit, so the application retried a request that had already succeeded.
The customer sees two charges. Support issues a refund, the customer does not come back, and the cause was a single header that would have taken five minutes to add.
Free Payment Review
Talk Through Your Payment Requirements
Tell us what you need to charge for and in which markets. We will work through gateway choice and the failure cases that need handling.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists