Take payments by UPI, card and wallet

Payment gateway integration is everything between “Pay now” and the money arriving in your bank, done so your software always knows where each payment stands. The checkout is the visible part. Behind it, your server has to confirm each payment with the gateway, mark the order paid, send the invoice, handle refunds and failures, and match what the gateway settles to your bank with the orders it covers.

Most payment problems we are asked to fix live behind the checkout: orders stuck as unpaid, customers charged twice, renewals that silently stopped, refunds that never reached the customer, and settlements nobody can explain.

We work inside the software you already run, whether it is an online store, a booking system, membership or school software, an ERP or your own app. Where it has a good plugin, we set it up and test it properly. Where it doesn’t, we write the integration ourselves.

It pays off first at the checkout and in the accounts. A checkout that offers the methods your customers prefer, and works on a phone without errors, turns more visitors into paid orders. In India that means UPI first, with cards, wallets and net banking close behind. Abroad it means cards and wallets, plus the local methods people trust, such as iDEAL in the Netherlands.

The second payoff is time. When every payment is confirmed by the gateway and matched to its order automatically, nobody spends Monday morning working out which payments came in, chasing customers who already paid, or matching bank lines to invoices.

The third is recurring revenue. Memberships, subscriptions and instalments collected on AutoPay or mandates stop depending on reminders and phone calls.

The right gateway depends on where your customers are, what you sell and how you want to be paid. In India, gateways such as Razorpay cover UPI, cards, wallets, net banking, EMI and AutoPay in one integration. Abroad, Stripe covers cards, Apple Pay, Google Pay and many local methods, and PayPal is still expected in some markets.

We compare the options with you: methods covered, fees, how quickly money settles, recurring payments, split payouts if you run a platform, international cards, and how good the gateway’s reports and support are. Some businesses use two gateways, one as a fallback.

The merchant account is opened in your business’s name. The gateway checks your business first, usually asking for your registration and tax details, a bank account, and a website with clear terms, privacy, refund and contact pages. We prepare those pages with you so approval isn’t held up.

UPI is the method most Indian customers reach for first, and it works differently on each device. On a phone, the checkout opens the customer’s UPI app directly, with the amount filled in. On a desktop, it shows a QR code to scan. At a counter, a dynamic QR on the customer display carries the exact amount for that bill.

The tricky part is what happens next. The customer approves the payment in another app, and may never come back to your page. So we confirm every UPI payment from the gateway’s side, by webhook and status check, and treat “pending” as its own state with its own timeout, rather than guessing.

Payment links extend the same idea beyond the checkout: a link by WhatsApp, SMS or email for an invoice, a fee or a balance due, marked paid in your software the moment the money arrives.

Recurring payments turn renewals into something that happens on its own. With UPI AutoPay, the customer approves a mandate once in their UPI app. Card mandates work the same way for cards, and e-mandates through the bank suit larger or longer-running payments such as loan instalments.

The rules in India are clear about the customer’s rights: a pre-debit notice before each charge, and the freedom to pause or cancel the mandate. We build those notices in, along with what happens when a charge fails: a retry, a message to the customer with a link to pay, and a clear status for your team.

Abroad, subscriptions run on saved cards through the gateway, with strong customer authentication in Europe where it applies.

The browser is never trusted with the truth about a payment. When the gateway takes a payment, it sends a signed webhook to your server. The server checks the signature, confirms the amount and order, and only then marks the order paid. If a webhook is late or lost, a scheduled status check catches the payment anyway.

Each payment attempt carries its own key, so a double tap or a retry can’t charge twice. Payments that arrive after an order expired, partial captures, amounts that don’t match and duplicate notifications each have a rule, so nothing ends up in a state nobody understands.

Before launch, we test every failure we can create in the gateway’s test mode: declined cards, abandoned UPI requests, timeouts and refunds.

Refunds start from your own software, not from the gateway’s dashboard. A cancelled order or a returned item triggers the refund, full or partial, and it goes back the way the customer paid. The customer is told, and the order shows the refund.

Settlements are where finance spends its time. The gateway pays out in batches, minus its fees and the tax on them, with refunds and disputes taken off. We match each settlement to the orders it covers, line by line, and flag anything that doesn’t match. The matched figures go to Tally or your accounting software, so the books agree with the bank without a spreadsheet in between.

The safest card number is one your servers never see. We use the gateway’s hosted checkout or secure fields, so card details go straight to the gateway. That keeps your share of PCI DSS small, often a short self-assessment, with the gateway confirming which form applies.

In India, card numbers can’t be stored by merchants; saved cards work through network tokens the gateway manages. Card payments go through the extra authentication the rules require, and in Europe strong customer authentication applies to most online card payments.

Live keys stay in a secrets store, not in the code, and can be replaced at any time. Every payment, refund and payout is logged with who started it and when.

We need access to your current setup and a few decisions. Access means your website or software, your gateway dashboard if you already have one, and a few weeks of recent payments and settlements, including the ones that went wrong.

The decisions are yours: which methods to offer, refund rules, what happens to unpaid orders, how renewals work and what customers are told. Someone from finance should be involved from the start, because reconciliation is built around how your accounts work.

The merchant account, its checks and its keys stay in your business’s name.

Payments need watching after launch, because banks, apps and gateways change. We track success rates by method and by bank, pending and failed payments, refunds and settlement mismatches, and alert your team when something drops.

When a gateway has a bad day, a second gateway can take over. When customers start asking for a method you don’t offer yet, or you start selling in a new country, we add it to the same integration, tested the same way.

Each month you get a short report: how many payments succeeded by method, where customers dropped out, refunds and how long they took, and any settlement that needed a person to explain it. It is the quickest way to see whether a change at the checkout actually helped.