Web Development
Payment Gateway Integration
Taking a payment is a morning. Everything around it — refunds, disputes, retries, reconciliation — is the rest of the estimate.
Payment gateway integration connects Stripe, GoCardless, PayPal or a bank provider to your site. The Nexclick tests the failure paths — declines, refunds, partial captures, disputes, webhook retries — because those are the cases that lose money quietly rather than failing visibly.
Is this you?
What usually prompts the call
- You take payment by invoice and bank transfer and want to take it online.
- Orders occasionally appear paid in the gateway and unpaid on your site.
- Refunds are processed in the gateway and never reflected in your system.
- You need recurring payments and your current setup only handles one-offs.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Provider selection on your actual model
- Cards, direct debit, one-off or recurring, B2B or consumer, domestic or international. Fees and capability differ meaningfully and the cheapest headline rate is rarely the cheapest overall.
- Webhook handling with idempotency
- Gateways retry webhooks and send duplicates. Without deduplication you double-fulfil orders or double-credit accounts, and it is a common and expensive oversight.
- Failure path implementation
- Declines, 3D Secure challenges, abandoned checkouts, partial captures and timeouts. These are the cases that lose money without anyone noticing.
- Refunds and disputes
- Full and partial refunds reflected in your own system, and chargeback notifications surfaced to someone who can respond within the deadline.
- Strong Customer Authentication
- SCA and 3D Secure handled correctly, including exemptions where they apply. A UK regulatory requirement, not an optional enhancement.
- Reconciliation
- A way to compare gateway records against your own and surface discrepancies. Without it, small mismatches accumulate quietly for months.
- PCI scope kept minimal
- Hosted fields or redirect flows so card data never touches your server, which keeps your compliance obligation as small as it can be.
Comparison
The payment cases that must be tested before going live
Every one of these has, at some point, cost a business money quietly. Ask whoever is building your integration to demonstrate each in a test environment before you accept it.
| Case | What goes wrong untested | How to verify |
|---|---|---|
| Card declined | Order created as paid | Use the gateway’s decline test card |
| 3D Secure challenge | Customer stuck; payment abandoned | Test the authentication-required card |
| Duplicate webhook delivery | Order fulfilled twice | Replay the same webhook and confirm one effect |
| Webhook arrives before redirect | Race condition; inconsistent state | Simulate out-of-order delivery |
| Customer closes the tab mid-payment | Paid with no order record | Rely on the webhook, not the redirect |
| Partial refund | System shows fully refunded, or not at all | Issue a partial refund in the gateway |
| Refund issued directly in the gateway | Your system never learns about it | Confirm the refund webhook is handled |
| Chargeback raised | Deadline missed; dispute lost by default | Confirm dispute webhooks reach a person |
| Subscription payment fails | Access continues indefinitely | Test the dunning and access-removal path |
| Currency mismatch | Charged in the wrong currency | Test with a non-GBP presentment currency |
| Gateway outage during checkout | Order lost with no record | Confirm a retry or graceful failure path |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1
Model the payment flows
What is charged, when, by whom, and what happens on failure or refund. Includes the accounting side, since reconciliation is part of the requirement.
- 02Week 1–3
Build and handle webhooks
Integration built with idempotent webhook handling, tested against the gateway’s test environment including the failure scenarios.
- 03Week 3–4
Test the awkward cases
Declines, 3D Secure, partial refunds, duplicate webhooks and disputes, exercised deliberately rather than assumed.
- 04Week 4–5
Go live and reconcile
Live transactions monitored closely for the first fortnight, with reconciliation run against the gateway.
What you get
Reporting and ownership
- Idempotent webhook handling, so duplicate deliveries cannot double-fulfil or double-charge.
- Every failure path tested against the gateway’s test environment, evidenced.
- A reconciliation method comparing gateway records to your own.
- SCA and 3D Secure handled correctly, with exemptions applied where valid.
- PCI scope kept minimal through hosted fields or redirect flows, documented.
Tools and platforms
- Stripe
- GoCardless
- PayPal
- Webhook infrastructure with retry handling
- Gateway test environments
- Playwright (checkout journey tests)
Timeline
How long this actually takes
Four to five weeks for a standard integration including proper failure handling. Taking a card payment on the happy path is a morning; the rest is the estimate. One thing to be direct about: if you are on Shopify, WooCommerce or a similar platform, payment integration is largely a configuration job rather than a development one, and anyone quoting weeks for it should be asked why. Custom integration earns its cost on bespoke platforms, unusual charging models, or where payment state has to synchronise with your own systems.
Pricing model
Fixed-price project
Fixed price against the payment flow specification. Gateway fees are yours directly, and we will compare providers on your actual transaction profile rather than headline rates.
Questions
Payment Gateway Integration questions
Stripe, GoCardless or PayPal?
Stripe for cards and most online sales. GoCardless for recurring direct debit, which is materially cheaper than cards for subscriptions and B2B. PayPal as an additional option because some customers prefer it. Many businesses use two, and the right answer depends on your transaction profile rather than headline rates.
Why do webhooks need special handling?
Because gateways retry them and can deliver duplicates or out of order. Without idempotent handling you double-fulfil orders or double-credit accounts. It is the most common serious defect we find in existing payment integrations, and it is invisible until it happens.
What is SCA and does it apply to us?
Strong Customer Authentication is a UK and EU regulatory requirement adding an authentication step to many card payments. It applies to most online consumer transactions. Exemptions exist for low value and recurring payments, and applying them correctly reduces friction without breaching the rules.
Are we responsible for PCI compliance?
Your obligation depends on how card data is handled. Using hosted fields or a redirect flow, so card details never touch your server, keeps you in the simplest self-assessment category. Building your own card form dramatically expands the obligation and is almost never worth it.
How do we make sure the gateway and our records agree?
Scheduled reconciliation comparing gateway transactions against your own records and flagging discrepancies. Without it, small mismatches — a refund processed in the gateway, a webhook missed during an outage — accumulate quietly and surface at year end.
Can we take payment on Shopify or WooCommerce without development?
Largely, yes — on established platforms it is a configuration task. Anyone quoting weeks of development for a standard gateway on Shopify should be asked what specifically requires it. Custom work is for bespoke platforms and unusual charging models.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.