What does ecommerce payment integration actually involve?
Published: Oct 22, 2026 · Last updated: Oct 22, 2026
Ecommerce payment integration is the work of connecting your store to a payment gateway so money moves from the customer to your bank and your order system always knows the true state of every payment. The checkout button is the easy part. The hard part is everything after it: declines, payments stuck in pending, refunds, disputes and the compliance work that comes with card data.
Maybe you are seeing it already. Orders marked paid that never settled. Customers charged twice after a page refresh. A UPI payment that went through in the bank app while your site showed an error. Someone on your team spending an hour a day matching gateway reports to orders by hand.
If that sounds familiar, the gateway is rarely the problem. The integration around it is. This guide covers what to build around the gateway, not which logo to pick. If you are planning the whole store, start with our ecommerce development guide and come back here for the payments layer.
Why do payments break after the customer clicks Pay?
Payments break because a payment is not one event. It is a sequence of states that change over seconds, hours and sometimes weeks, and your store hears about most of those changes later, through a message from the gateway.
A typical card payment moves through created, authentication required, authorised, captured and settled. Any step can fail. The bank can ask for 3-D Secure verification and the customer can close the tab halfway. A UPI or wallet payment hands the customer to another app entirely, and your page has no idea what happened until the gateway tells you.
That message is a webhook: an HTTP call from the gateway to your server saying a payment changed. Webhooks are where most integrations go wrong, for four reasons:
• They can arrive late, after the customer has already seen a result page.
• They can arrive more than once, because gateways retry when your server is slow to answer.
• They can arrive out of order, so a refund event may land before the capture event.
• They can be faked if your server does not check the signature the gateway attaches.
Many stores, especially ones built quickly or with AI builders, mark the order as paid when the customer lands on the success page. That page is only a browser redirect. It can fail to load, be refreshed, or be opened directly by someone who never paid.
Your order system should follow the gateway's record, never the browser.
What does a weak payment integration cost you?
It rarely fails all at once. It leaks orders, support hours and customer trust, quietly, until the total is hard to ignore.
Orders you never see. When a pending payment later succeeds but your system already cancelled the order, the customer is charged with nothing on the way. Some will email you. Many will simply dispute the charge with their bank.
Double charges. Without idempotency (a unique key that tells the gateway this is the same attempt, so do not charge again), a double click or a network retry can create two payments. Each one becomes a refund to process and a customer who now doubts your store.
Chargebacks and gateway risk. Every dispute carries a fee and often the loss of the goods. If your dispute rate climbs, your gateway can hold payouts, add a reserve or close your account, and moving to a new gateway in a hurry is painful.
Compliance exposure. If card data touches your servers, or your payment page loads scripts you do not control, you carry more PCI DSS obligations than you probably realise. A breach traced back to your checkout is a far bigger problem than a failed questionnaire.
Reconciliation by hand. When orders and gateway payouts do not match, finance spends days each month matching them line by line, and small errors in refunds and tax pile up.
Do you need custom payment work at all?
Not always. If you run your store on Shopify, WooCommerce or a similar platform and use its built-in payments or an official gateway plugin, the platform already handles webhooks, retries, refunds and most of your PCI scope.
In that case your job is configuration, not code. Turn on 3-D Secure where it applies, set fraud rules, enable the local methods your customers use, and test one refund end to end. You do not need a development partner for that.
You need custom work when payments touch something the platform does not own: a custom-built store or app, subscriptions with proration, a marketplace that splits money between sellers, more than one gateway, B2B invoicing, or an ERP and warehouse system that must update the moment a payment clears.
How do you choose a payment gateway and checkout type?
Choose the gateway by the payment methods your customers actually use and the countries you sell in. Then choose the checkout type by how much PCI work you are willing to carry. Fee structure matters, but it is rarely the deciding factor once you compare like for like.
Questions to answer before you compare gateways:
• Which methods do your buyers expect? Cards, UPI, wallets, net banking, pay later plans, bank transfer, cash on delivery.
• Which currencies will you charge in, and where must payouts land?
• Do you need subscriptions, saved cards, split payouts to sellers, or delayed capture for made-to-order goods?
• How good are the gateway's webhooks, test mode, dispute tools and settlement reports?
The checkout type decides your PCI DSS scope. PCI DSS is the card industry's security standard, and every merchant that accepts cards has to validate against it, usually through a Self-Assessment Questionnaire (SAQ). Three common setups:
Gateway-hosted page or gateway-hosted card fields (a redirect, or card inputs that sit inside the gateway's own iframes): usually SAQ A, the lightest scope. Card data never touches your page or servers. You still have to protect the page that hands customers to the gateway from tampering.
Your page builds the card form and sends card data to the gateway with a script or a direct post: usually SAQ A-EP. Your website can now affect payment security, so you take on more requirements, including keeping an inventory of every script on the payment page and detecting changes to it.
Card numbers pass through your own servers: SAQ D, the heaviest scope, with network segmentation, logging, vulnerability scans and regular testing. Almost no online store should choose this.
Decision rule: if you have no strong reason otherwise, use a hosted checkout or gateway-hosted fields. If brand control matters, hosted fields give you a custom look while keeping card data off your page. Confirm your SAQ type with your gateway or acquiring bank in writing, because they decide which one applies to you.
How should your store handle declined, abandoned and pending payments?
Treat every payment as having three possible outcomes when the customer leaves your page: succeeded, failed, or not known yet. Most payment bugs come from forcing the third outcome into one of the first two.
Declines. The gateway returns a decline code, and you should sort codes into two groups. Soft declines (insufficient funds, authentication needed, a temporary issuer problem) deserve a clear message and an easy way to retry or switch method. Hard declines (lost or stolen card, closed account, invalid number) should never be retried. Repeated attempts on a declined card can get flagged by the card networks and your gateway.
Write decline messages for people, not engineers. "Your bank declined this payment. Try another card or pay with UPI" keeps the sale alive. A raw error code ends it.
Abandoned payments. The customer opened 3-D Secure or their UPI app and never came back. Keep the order pending, hold stock for a set window, then release it. If you send a reminder, link back to the same order rather than a new cart, so you do not create duplicates.
Pending payments. UPI, bank transfers and some wallets confirm minutes after the customer has gone. Show a "we are confirming your payment" screen that checks your own server, and let the webhook make the final call.
The webhook handler is the heart of all this. It should:
• Verify the gateway signature on every call and reject anything unsigned.
• Store each event ID and skip events already processed, so retries are harmless.
• Answer the gateway fast and push slow work (emails, ERP updates) to a background queue.
• Move orders only forward through allowed states, so a late event cannot undo a refund.
• Log every event, so support can see exactly what the gateway said and when.
Then add a safety net: a scheduled job that asks the gateway for the status of any payment still pending after, say, 30 minutes. Webhooks do fail. The job catches what they miss.
How should partial refunds and chargebacks work?
Refunds should be issued from your order system through the gateway's API, against the original payment, and recorded line by line. Chargebacks should open a case automatically, with the evidence already gathered.
Partial refunds are where store logic gets tricky. A customer returns one item from a three-item order that used a discount code and free shipping. Your system has to decide how much of the discount that item carried, whether shipping comes back, how tax is reversed and whether stock returns to the shelf. Write those rules down before development starts, not after the first angry email.
A good refund flow records:
• Which items and quantities were refunded, and the amount for each.
• The gateway refund ID, so finance can match it to the payout report.
• The running total refunded, so nobody can refund more than was paid.
• Who approved it and why, in case of a dispute later.
Refunds to cards, UPI and wallets can take several working days to reach the customer, depending on their bank. Put the expected window in the refund email. It prevents a lot of "where is my money" tickets.
A chargeback is different. The customer goes to their bank, the bank pulls the money back, and you get a fixed deadline to respond with evidence. Your gateway sends a dispute webhook. Use it to flag the order, stop fulfilment if it has not shipped, and build the evidence pack automatically: order details, tracking and proof of delivery, IP address and device, the 3-D Secure result, and your emails with the customer.
Prevention beats winning. A billing name customers recognise on their statement and fast refunds stop many disputes before they start.
UPI, wallets and local payment methods
Local payment methods are not just extra buttons. Each one has its own flow, timing and refund behaviour, and your integration has to handle each on purpose.
UPI in India usually runs as an intent flow on mobile (your page opens the customer's UPI app) or a QR code on desktop. The customer approves in another app, so the result nearly always arrives by webhook rather than through the browser. Design for pending first.
Wallets such as Apple Pay, Google Pay, Paytm and PhonePe can lift mobile conversion because nobody types a card number. Apple Pay on the web needs domain verification, and each wallet has its own rules for which devices and browsers show it.
Saved cards in India have to use tokenisation under RBI rules. Merchants cannot store card numbers, so saved cards work through network tokens created via your gateway.
Cash on delivery still matters in many markets. Treat it as unpaid until the courier confirms collection, and reconcile courier remittances like any other payout.
Pay later plans and bank transfers often settle later and refund through different paths. Check how each behaves before you switch it on.
Decision rule: add a method when customers ask for it or your checkout data shows people leaving at the payment step, not because the gateway happens to offer it. Every method you add is another flow to test and support.
What should you ask your developer to build and test before launch?
Ask for a payment flow that has been proven in the gateway's test mode against every failure case, not just one successful card payment. Here is the list to hand your team, with the reason for each item.
Build:
• Idempotency keys on every create-payment and refund call, so retries never double charge.
• A signed, deduplicated webhook handler with a background queue, so receiving an event twice is safe.
• An order state machine (pending, paid, partly refunded, refunded, disputed, cancelled), so late events cannot corrupt an order.
• A daily reconciliation job that matches orders to gateway payouts, so finance is not doing it by hand.
• An admin screen for refunds and dispute status, so support can help customers without gateway dashboard access.
• Secret keys in server-side environment variables, never in front-end code, with separate test and live keys.
Test:
• Success, soft decline, hard decline and 3-D Secure failure, using the gateway's test cards.
• The customer closes the tab during authentication, then returns.
• The same webhook delivered twice, and events delivered out of order.
• A UPI or wallet payment that confirms after the customer has left.
• A partial refund on a discounted order, followed by a second partial refund.
• A dispute webhook, and the evidence pack it produces.
• Your webhook endpoint down for an hour, then back, to confirm the reconciliation job catches up.
For the wider launch list, use our web app production readiness checklist. Built your store with an AI builder? Our guide to Lovable and Stripe payments covers the gaps those tools usually leave. To have a team run these tests for you, see our software testing and QA service.
Your next step: send us your store or checkout URL with a short note on your gateway and the payment methods you offer. Geminate Solutions will review your payment flow and send back a written list of the gaps in failure handling, webhooks, refunds and PCI scope, in the order we would fix them. We sign an NDA before we talk, and we reply within 24 hours.
