Online payments on a business website: what changes

“Can I accept UPI payments on my website?” is nearly always answered “yes”, and the answer hides the real question: what are you taking on when you do? A payment is not a button. It is a chain of parties and duties, and each link has a cost. This note describes the chain so you can decide whether you need it now.

I should say plainly where I stand: online payments, shopping carts, customer accounts and similar features are not part of any of my packages unless they are agreed in a written proposal, because they need a backend and ongoing responsibility. This note is guidance, not a sales page.

What taking payment actually involves

A payment gateway or provider. A company that handles the money movement between your customer and your bank. Providers in India commonly offer UPI, cards and net banking, but which methods, fees and settlement times apply is set by each provider and changes. Read their current terms.
An account with checks. Gateways ask for business documents and verify them. This can take time and is outside the website.
A checkout. Prices, quantity, address, an order summary and a confirmation. It must work on a phone.
A backend. Something that creates the order, talks to the gateway, receives its confirmation and records the result. Without one, you cannot tell whether a payment succeeded.
Order handling. A way to see orders, fulfil them, send updates, handle failed or duplicate payments and issue refunds.
Policies. Pricing, shipping, returns, refunds and privacy statements that match what you actually do.
Tax and invoicing. What invoice you must give and how tax applies is a matter for your accountant, not for the website.
Security and privacy. Card details are handled by the provider, but your site still handles customer names, addresses and orders. If you store personal data, data-protection law may apply to you; take advice.

Simpler routes to try first

Take the enquiry, then collect payment yourself. Customers message you on WhatsApp or call, you confirm price and availability, and send a payment request through the method you already use. For many service and B2B businesses this is how it works anyway. It also lets you check each order before money moves.
A payment link from your provider. Some providers let you create a link for a specific amount and send it to a customer, without any checkout on your website.
A marketplace. If you sell small, standard items, a marketplace handles payment and delivery, at the cost of fees and of owning the customer relationship. Own website or IndiaMART listing compares.
A store platform. If selling online is the main job, a platform built for it can be more sensible than a custom build; see website platforms compared.

Questions to ask any developer who offers payments

Which provider, and in whose name is the account?
Who receives the money, and how fast?
What happens when a payment fails or is duplicated?
Who can see orders, and how do I get a record for my accounts?
What does it cost to build, and what does it cost every month?
Who fixes it, and how fast, when it stops working at night?
What is not included?

If the answers are vague, you are being sold a button.

Do you need a store at all?

If customers need to see products, specifications and prices and then ask for a quotation, a catalogue site may be enough, and it is lighter to run. Catalogue website or online store helps you decide. Frontend, backend and what your site needs explains why the backend is where the cost and the responsibility sit.

If you are weighing a site that only presents your business and takes enquiries, my packages and prices are on the pricing page. If you need payments, tell me early in a message so any such work is scoped separately and honestly.