Which gateway should I be on?

It depends on where your business is registered, where your buyers are, what you sell and your average order value, and it is a decision we make with you rather than announcing. What we can tell you is that the cheapest headline rate is often not the cheapest outcome once you account for the platform's own surcharges, payout timing and how the provider treats your product category.

Why is my platform charging me on top of my gateway's fee?

Because you are not using the platform's own payment product. Shopify in particular adds its own transaction fee when a store takes payments through a third-party gateway, so the merchant pays that fee and the gateway's fee together. A surprising number of stores have been paying both for years without noticing. We will work the arithmetic on your actual volume before you decide.

Will you need my gateway or bank login?

No. Accounts are created and connected by you, on your screen, with us on a call walking through each field while you type. We never hold your banking or gateway credentials and there is no situation in which we would ask. Where API keys are needed for the integration, we use restricted keys with only the permissions the work requires.

What happens if my payment account gets frozen?

It happens more often than people expect, particularly in categories providers treat as high risk — supplements, anything with a high refund rate, some subscription models. The provider can hold funds while they review. If your category is exposed to that, we will tell you before launch and set up a secondary route so a freeze is an inconvenience rather than a stopped business.

Do you test refunds as well as payments?

Yes, including partial refunds, which is where most implementations quietly fail. A full refund is usually handled. A partial refund that has to reconcile with the order record, the stock count and the customer email is a different code path and it is frequently untested until a real customer needs one.

Can you set up cash on delivery properly?

Yes, and properly means more than switching the option on. Cash on delivery brings its own problems — refused parcels, a courier reconciliation cycle that pays out days after delivery, and the temptation to take a small advance to reduce refusals. Each of those has consequences for how orders are marked, when revenue is recognised and what the customer is told, and they get designed rather than assumed.

E-commerce

Payment gateway integration

Taking money reliably — cards, wallets, local gateways and cash on delivery, tested against every failure state and not only the one where it works.

From: $300–$2,000
Typical time: 3–10 days
Usually bought by: Any store

What is actually broken when someone calls

Two versions of this problem arrive, and the second one is the expensive one.

The first is simple. The shop cannot take money. The gateway was never connected, or it was connected in test mode and never switched, or the account was approved and nobody finished the setup. Nothing is being lost except every sale, which is a straightforward brief with an obvious deadline.

The second is worse because the shop appears to be working. Money is arriving, orders are being fulfilled, and something in between is broken. An order exists with no payment attached to it. A payment arrived with no order behind it, so nobody ships anything and the customer eventually disputes the charge. Refunds have to be issued by hand in two systems because the store and the gateway do not agree. Or — the most costly version and the hardest to see — cards are being declined and the customer is shown a blank screen or the words technical error, so they leave and never come back, and the owner never hears about any of it. That last one does not produce a support ticket. It produces a slow leak in revenue that is invisible on every report the owner looks at.

Payments are also the part of a store where the cost of an error is immediate and denominated in money rather than aesthetics. A layout mistake looks bad. A payment mistake charges someone twice, or ships goods that were never paid for, or leaves an order stranded in a state the fulfilment team does not check.

How the work runs

Choose the route before touching anything. Your country of registration, your buyers' countries, your product category and your order values decide this, along with how the platform surcharges third-party gateways. Where the category carries a real risk of the account being reviewed or frozen, a secondary route is planned now rather than during the incident. One day.
Sandbox first, with webhooks proven end to end. The gateway goes in on test credentials, the webhook endpoint is wired up, and it is verified by firing real test events rather than by assuming. With Stripe that means running the CLI in listen mode against the local endpoint and triggering events until each one is seen arriving and handled. A webhook nobody has watched arrive is not an integration, it is a hope. One to three days.
Run the full test matrix. Successful card. Declined card. A card that forces 3D Secure so the shopper leaves for a bank page and comes back. Full refund. Partial refund. Webhook delivery failure. Double-clicked submit. For each one, four things are checked, not one — was the order created correctly, did stock move, did the email go, and does the gateway record agree with the store record. Stripe's test cards make several of these deterministic — 4242 4242 4242 4242 always succeeds, 4000 0000 0000 0002 always declines, 4000 0025 0000 3155 forces 3D Secure and 4000 0000 0000 9995 declines for insufficient funds. One to two days.
Design what the customer sees when it fails. Every decline reason mapped to a message that tells the shopper what to actually do next — try another card, contact their bank, check the billing address — with the cart preserved so a second attempt is one tap rather than a restart. This step gets skipped almost everywhere and it is where the recovered revenue is. One day.
Go live and prove it with real money. Live keys installed, then a real order placed on a real card and refunded, end to end, before the store is handed back. The order status map and the test matrix results are documented so you can hand them to anyone who takes this over later. Half a day to a day.

What moves the price

The range is $300–$2,000 over 3–10 days.

Settings work or engineering work. A mainstream gateway on Shopify or WooCommerce is largely configuration and testing, and it sits at the bottom of the range where it belongs. That is a genuinely small job and it should be priced like one.

How many moving parts share the checkout. Multiple gateways running side by side, several currencies, wallets alongside cards, cash on delivery with its own order states, or a marketplace that has to split a single payment between sellers — each of those multiplies the test matrix rather than adding to it.

The quality of the provider's documentation and SDK. Some processors are a pleasure and are documented better than most software. Others ship an outdated SDK, an undocumented sandbox and support that answers in days. That difference is worth several times the integration effort and it is assessed before quoting, not discovered afterwards.

Where integrations go wrong

Only the successful payment is ever tested. One order is placed, the money appears, and it is declared done. Two weeks later somebody's card is declined, they get a blank page, and they leave. The store owner never learns this happened because a failed payment generates no order, no email and no notification — it generates silence. Testing the failure states matters more than testing the success, because success is the path that gets exercised by real customers anyway.

The in-between states are never exercised. What happens when the webhook does not arrive? Does the payment sit in the gateway with no order behind it, so nothing ships and the customer disputes? What happens when an impatient buyer clicks submit twice — two orders, two charges, or one of each? These states are not exotic. They occur weekly on any store with volume, and they are the ones that produce chargebacks and refund work rather than error logs.

Partial refunds are assumed to work. Full refunds are usually fine because they are the simple path. A partial refund has to return the right amount at the gateway, mark the order correctly, leave the remaining items in a sensible state, adjust stock if anything is going back, and send a customer email that reflects reality. When that path is untested, the first real partial refund produces a support conversation, a manual adjustment in two systems, and a customer who now has a reason to call their bank instead.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Which gateway should I be on?: It depends on where your business is registered, where your buyers are, what you sell and your average order value, and it is a decision we make with you rather than announcing. What we can tell you is that the cheapest headline rate is often not the cheapest outcome once you account for the platform's own surcharges, payout timing and how the provider treats your product category.
Why is my platform charging me on top of my gateway's fee?: Because you are not using the platform's own payment product. Shopify in particular adds its own transaction fee when a store takes payments through a third-party gateway, so the merchant pays that fee and the gateway's fee together. A surprising number of stores have been paying both for years without noticing. We will work the arithmetic on your actual volume before you decide.
Will you need my gateway or bank login?: No. Accounts are created and connected by you, on your screen, with us on a call walking through each field while you type. We never hold your banking or gateway credentials and there is no situation in which we would ask. Where API keys are needed for the integration, we use restricted keys with only the permissions the work requires.
What happens if my payment account gets frozen?: It happens more often than people expect, particularly in categories providers treat as high risk — supplements, anything with a high refund rate, some subscription models. The provider can hold funds while they review. If your category is exposed to that, we will tell you before launch and set up a secondary route so a freeze is an inconvenience rather than a stopped business.
Do you test refunds as well as payments?: Yes, including partial refunds, which is where most implementations quietly fail. A full refund is usually handled. A partial refund that has to reconcile with the order record, the stock count and the customer email is a different code path and it is frequently untested until a real customer needs one.
Can you set up cash on delivery properly?: Yes, and properly means more than switching the option on. Cash on delivery brings its own problems — refused parcels, a courier reconciliation cycle that pays out days after delivery, and the temptation to take a small advance to reduce refusals. Each of those has consequences for how orders are marked, when revenue is recognised and what the customer is told, and they get designed rather than assumed.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Payment gateway integration All E-commerce services