What does a payment gateway integration developer actually build?
A payment gateway integration developer writes the code between your business system and a payment provider. The customer sees a checkout screen for a few seconds; behind it sit several steps that must happen in the right order: create an order on your server, request a payment session from the provider, send the customer to pay, receive the result, verify that the result genuinely came from the provider, update the order, send confirmation, and later match the payment to the money that arrives in your bank.
Each of those steps can fail independently. The customer can close the browser after paying. The UPI app can take a minute to confirm. The network can drop between the provider and your server. A good integration expects all of this. A weak one works in the demo and quietly loses orders in real life.
So the job covers back-end code, front-end checkout, webhook endpoints, admin tools for refunds, and reconciliation reports. It does not include negotiating fees with a provider or completing your merchant KYC; those are between your business and the provider, though we can tell you which documents are usually requested.
How online payments work in India: provider, bank and your server
When a customer pays on your site, the money does not come to you directly. A payment gateway or payment aggregator collects it on your behalf through its partner banks and card networks, then settles it into your current account after its settlement cycle, minus its fees. In India, online payment aggregators are regulated by the Reserve Bank of India, which is why onboarding asks for business documents and a live website with clear policies.
Your server never sees full card numbers when you use a standard checkout. The provider hosts or embeds the payment form, handles the card network and bank authentication, and gives your server a payment ID and a status. Your code’s job is to trust nothing until it has verified that status with the provider.
The accounts involved should all be yours: the merchant account on the provider’s dashboard, the API keys it issues, the bank account it settles into and the website or app that calls it. A developer should only ever receive test keys to build with and, at go-live, access you grant and can revoke.
UPI integration: intent, QR and what happens while a payment is pending
UPI is the method most Indian customers reach for first, so a payment gateway integration developer must get it right on both phones and desktops. On a phone the best flow is UPI intent: the checkout opens the customer’s UPI app directly, they approve with their PIN and come back. On a desktop the usual flow is a dynamic QR code for that exact amount, scanned with the phone. Asking customers to type a UPI ID and approve a collect request is increasingly discouraged across the industry, so intent and QR are the safer defaults.
The tricky part is time. A UPI payment can sit as pending for seconds or minutes while banks confirm it. The checkout must show a clear “waiting for confirmation” state, poll the provider for status, and rely on the webhook as the final word. If the customer closes the page, the order must still update when the webhook arrives.
There is also the case every seller meets eventually: the customer’s bank shows a debit but the payment failed. Usually the bank reverses it automatically. Your site should say so clearly on the failure page instead of leaving the customer to panic and call you.
- Intent flow on mobile, QR on desktop
- A visible pending state with automatic status checks
- Webhook as the source of truth for the final status
- Clear wording for failed-but-debited cases
Card payments: 3-D Secure, tokenisation and PCI DSS in plain words
Card payments in India add a second step, usually an OTP from the issuing bank, known as 3-D Secure or additional factor authentication. The provider’s checkout handles it; your integration simply waits for the final status like any other method.
Since RBI’s card-on-file rules took effect, merchants may not store customers’ full card numbers. Saved cards now work through tokens issued by the card networks, which the provider manages with the customer’s consent. For you, that means one simple rule: card numbers must never pass through or be saved on your server.
The global card-security standard is PCI DSS. If you use the provider’s hosted or embedded checkout, card data goes straight to them and your compliance burden stays small. If you want a fully custom card form on your own server, the burden grows sharply and the provider will ask for evidence of compliance first. For almost every small or mid-sized business, hosted or embedded checkout is the right choice.
Hosted, embedded or server-to-server: which checkout should you choose?
There are three broad ways to present checkout, and the choice affects conversion, effort and compliance.
Hosted (redirect) checkout
The customer is sent to the provider’s payment page and returned afterwards. Quickest and lightest on compliance; the brief jump to another page is familiar to Indian shoppers.
Embedded (pop-up or inline) checkout
The provider’s payment form opens over or inside your page. The customer stays on your site, conversion is usually a little smoother, and card data still never touches your server. This is our default for most projects.
Server-to-server (custom) checkout
Your own form collects details and your server calls the provider’s APIs. Maximum control, but it needs PCI DSS compliance for cards and provider approval. Rarely worth it for small businesses.
On mobile apps, providers offer SDKs for Flutter and React Native that behave like embedded checkout. For digital goods sold inside Android and iOS apps, Google Play and the App Store have their own billing rules, which we check before planning your flow.
Signature checks, webhooks and idempotency: the core of a safe integration
This is where a payment gateway integration developer earns their fee. The browser tells you a payment succeeded, but the browser is under the customer’s control and can be faked. So the rule is: never mark an order paid based on the browser alone.
Instead, the order is created on your server first with the exact amount. When the payment returns, your server checks the provider’s cryptographic signature using the secret key only your server holds, or fetches the payment status directly from the provider’s API. Separately, the provider calls your webhook endpoint with the final status; that endpoint also verifies the signature before updating anything.
Because webhooks can arrive late, twice or before the browser returns, every update must be idempotent: processing the same event twice must not create two orders, two invoices or two confirmation messages. And the amount paid must be compared with the amount expected, so nobody can pay one rupee for a thousand-rupee order.
- Create the order and amount on the server
- Verify the signature or fetch status server-side
- Verify every webhook before acting on it
- Compare paid amount and currency with the order
- Make every status update safe to run twice
- Keep secret keys in server environment variables, never in front-end code
Refunds, cancellations and disputes
Refunds should start from your own admin panel, not from a separate provider dashboard where nobody remembers to update the order. A good integration lets staff issue full or partial refunds against an order, calls the provider’s refund API, and records the refund ID and status so the order, the invoice and the stock all stay consistent.
Refunds take time to reach the customer’s account depending on the method and bank, so the customer should receive a message with the refund reference. Your refund and cancellation policy page should say plainly how and when refunds happen; providers check for it during onboarding.
Card disputes, or chargebacks, arrive when a customer tells their bank a payment was not authorised or the goods never came. The provider notifies you and asks for evidence. Keeping delivery proof, order logs and customer messages linked to each order makes these far easier to answer.
Subscriptions and recurring payments with UPI AutoPay and card mandates
Gyms, coaching institutes, SaaS tools and membership sites often want automatic renewals. In India this works through mandates: the customer authorises a recurring debit once, via UPI AutoPay or a card e-mandate, and later charges run within the approved limits. RBI rules require customers to be notified before each debit and to be able to cancel easily.
The integration has more moving parts than a one-time payment: creating plans, registering the mandate, handling renewal events by webhook, retrying failed renewals, pausing access when payment fails, and sending reminders. Access control must follow payment status automatically, or someone ends up checking spreadsheets every month.
If recurring card payments are not essential, a simpler pattern also works well: send a payment link by WhatsApp or email a few days before renewal, and extend access when the webhook confirms payment. See membership website developer for the wider build.
How to choose a payment provider without getting stuck later
We do not push any particular provider; choose on facts for your business. Compare the fee schedule for each method you expect (UPI and RuPay debit cards are generally zero-MDR under current government rules, though providers may charge other fees), the settlement cycle, which methods and international cards are supported, how onboarding works for your business type, the quality of API documentation and sandbox, and how quickly support replies when a payment is stuck.
Ask each provider about its rules for your category. Some categories need extra approvals, and some providers decline certain businesses entirely. Get approval before the developer finishes the integration, not after.
Build the integration so that switching providers later means replacing one module, not rewriting checkout. We keep provider-specific code behind a small internal interface for exactly this reason. It costs little upfront and saves a great deal if fees or service change.
On WooCommerce, Shopify and similar platforms, the provider’s official plug-in or app is usually the right starting point. The developer’s job is to configure it correctly, test every status, check that order emails and stock update as expected, and fix conflicts with other plug-ins. Custom code only enters when you need something the plug-in cannot do.
On custom sites in PHP, Node.js, Python or Next.js, we use the provider’s server SDK or REST API directly, with the order model, webhook handler and admin refund tools written to fit your existing database.
In Android and iOS apps built with Flutter or React Native, the provider’s mobile SDK opens checkout inside the app, while your server still creates orders and verifies results. For physical goods and real-world services this is standard; for digital content consumed inside the app, store billing rules apply and must be checked first.
Related: Shopify developer, WooCommerce developer and ecommerce app developer.
GST invoices, receipts and reconciliation after the payment
A payment is not finished when the customer sees “success”. Your accountant needs an invoice with the correct GST details, your team needs to know which orders were paid, and at month end someone must match what customers paid, what was refunded and what the provider actually settled into your bank after fees.
A payment gateway integration developer can automate most of this. Invoices are generated from the order when payment is confirmed, with GSTIN, HSN or SAC codes and tax split as your accountant specifies. Settlement reports from the provider are fetched and matched against orders, flagging anything that does not line up: a payment with no order, an order marked paid with no payment, or a refund never processed.
This matching is where businesses quietly lose money. A daily reconciliation report, sent automatically, catches problems while they are still easy to fix.
Security and fraud basics every payment integration needs
Most payment security comes from a few disciplined habits rather than clever tricks. Keep live API keys and webhook secrets in server environment variables, never in front-end code or the repository. Serve the whole site over HTTPS. Verify every webhook. Log payment events without logging sensitive data. Give staff individual admin logins so refunds are traceable to a person.
For fraud, watch for patterns that do not match normal buyers: many failed attempts from one device, unusually large orders from new accounts, or mismatched delivery details. Providers run their own risk checks, but your own rules, such as holding very large first orders for a phone confirmation, add a useful layer. Cash on delivery and prepaid options can be offered differently based on pin code or order value.
If your site has been compromised in the past, clean it before adding payments. See website security freelancer.
Testing checklist before you switch on live payments
Every provider offers a test mode with test cards and simulated UPI results. Use it to rehearse every path, not just a happy payment. Then do a few small live transactions with real money and refund them before announcing launch.
- Successful payment by UPI intent on Android and iPhone
- Successful payment by QR on desktop
- Card payment with OTP, and one with a wrong OTP
- Customer closes the page after paying: order still updates by webhook
- Payment stays pending, then succeeds; and pending, then fails
- Same webhook delivered twice: no duplicate order or email
- Tampered amount in the browser: payment rejected
- Full and partial refund from admin, reflected on the order
- Invoice generated with correct GST details
- Live keys only on the server; test keys removed
How much does a payment gateway integration developer cost?
It depends on whether payments are part of a new build or added to an existing system. With BtechWaleTech, a new online store including checkout starts at ₹50,000 (US$750); a custom web app or portal with payments starts at ₹60,000; an Android and iOS app with in-app checkout starts at ₹40,000. Adding payments to an existing site is quoted after we review the code, since a tidy order model takes far less work than one built without payments in mind.
Quotes in the market vary widely for “payment gateway integration” because some cover only installing a plug-in while others include webhooks, refunds, reconciliation and testing of failure paths. When comparing, ask each developer exactly which of those are included.
Remember that the provider’s transaction fees, any setup charges and your bank charges are separate from development cost and paid to them directly.
Example: a coaching institute moving fee collection online
This is a hypothetical example. A coaching institute in Vijayawada collects fees in instalments by cash and bank transfer, and staff spend hours each month matching payments to students. It wants parents to pay by UPI or card from a link, with receipts and a dues report.
The institute opens a merchant account in its own name. We build a small fee portal: each student has instalments; the office sends a payment link by WhatsApp; the parent pays by UPI intent on their phone; the webhook marks the instalment paid, generates a receipt and notifies the office. Pending payments show as pending, not failed. A daily report lists payments received, settlements from the provider and anything unmatched.
After launch, the office asks for partial payments, which are added as a change. Cash payments are still recorded manually in the same portal so the dues report stays complete.
Payment integration for sellers and institutions across India
Payment integration is done entirely online, so your location does not matter. We work remotely with businesses in every state; the city pages below describe what local sellers and institutions usually need.
Examples: Banarasi saree sellers in Varanasi, leather and footwear makers in Agra and Kanpur, sports goods brands in Meerut, jewellers in Thrissur, food and textile sellers in Amritsar, handloom and flower traders in Madurai, gem and handicraft exporters in Jaipur and coaching institutes in Vijayawada. For the full list see India.