Razorpay for a studio: test mode, test cards, and going live
Opening the account, what test mode does and does not prove, the documented test cards and UPI IDs, what the standard plan costs, a go-live checklist, and the one question worth asking any platform that sits between you and your fee.
- A gateway is worth having for one reason: it confirms the payment for you, so nobody is reading a screenshot and ticking a spreadsheet.
- Test mode uses separate keys and separate cards. Nothing you do in it touches real money, and nothing you do in it proves the live path works.
- In test mode, an OTP of four to ten digits succeeds and an OTP under four digits fails. That is the switch, not the card number.
- Trust the webhook, never the browser. A client whose connection drops after paying is the case that decides whether your setup is correct.
Most small practices collect fees by bank transfer, and most of them think the gateway question is about convenience. It is not. It is about who does the checking. With a transfer, the payment arrives as a claim: a screenshot on WhatsApp, a reference number, a client saying it has been sent. Somebody in the studio then has to open the bank, find it, match it to an invoice and mark it off, and until that happens the drawings either go out unpaid or sit waiting on an administrative task.
A gateway removes the checking. The payment confirms itself, against the invoice it was raised for, without anyone reading a screenshot. In India that usually means Razorpay, and what follows is the shape of setting it up, testing it honestly, and the parts that are worth knowing before rather than after.
Getting the account open
Onboarding is KYC, and the entity you practise as decides how straightforward it is. A sole proprietorship is the common case for a small studio and the quickest; a partnership, LLP or private limited adds constitution documents.
- Identity and PAN, of the proprietor or of the entity, matching the name the account will be held in.
- Bank account proof, usually a cancelled cheque or a statement. The account name has to match the registered entity, which is the single most common reason onboarding stalls.
- GST registration, where you are registered. Architectural services attract 18% GST, so most practising studios are.
- Business proof, which for a proprietorship can be a registration certificate, a professional licence or a utility bill in the business name, and for a company or LLP is the incorporation documents.
You can begin integrating before KYC clears. Test keys are issued immediately, and everything in the next section works while the account is still under review, which is worth knowing because the two processes run in parallel and waiting for one before starting the other costs a week for nothing.
Test mode, and the cards that work in it
Razorpay dashboards run in two modes, and each has its own pair of API keys. Test keys hit a simulator: real checkout, real flow, mock bank, no money. Live keys move money. The keys are not interchangeable, and using a test card against live keys returns an error along the lines of card issuer is invalid, which is the system working correctly rather than a fault.
Test cards
The standard domestic test card is a Visa number, and the fields around it are deliberately permissive.
| Field | What to enter |
|---|---|
| Card number | 4111 1111 1111 1111, the documented domestic Visa test card |
| Expiry | Any future date |
| CVV | Any three digits |
| Name | Anything |
| OTP, to succeed | Any random number of four to ten digits |
| OTP, to fail | Any random number under four digits |
Razorpay maintains the current list, including international, EMI and subscription test cards, in its own documentation. Check it there before relying on any number, including this one.
The detail worth internalising is that the success or failure of a test payment is controlled by the OTP length rather than by the card number. That means one card exercises both paths, and there is no excuse for testing only the happy one. Run the failure. Then look at what your own system did with it, because a payment that fails and a payment that never started should not leave the same trace.
Test UPI
UPI is how most Indian clients will actually pay, so it deserves more than a passing test. Two documented virtual IDs cover it: success@razorpay completes the payment immediately, and failure@razorpay declines it immediately.
What else test mode will not tell you
Three more gaps, all of which have bitten real integrations.
- The settlement path. Test mode simulates the payment, not the money arriving in your bank. The first live rupee is the first real proof that the account details are right.
- Bank-side declines. Insufficient funds, an issuer timeout, a 3-D Secure step the client abandons halfway. The simulator has one failure; the world has dozens, and they surface as a client saying it did not work with no further detail.
- Your own webhook, under real conditions. Duplicates, out-of-order delivery, retries after your server was briefly down. This is the part that decides whether payments are recorded correctly, and it is the part test mode exercises least.
That third one is worth stating as a rule, because it is where integrations go wrong quietly rather than loudly. The browser is not the source of truth. A client can pay and lose their connection before the page returns; another can be shown a success screen while the capture is still in flight. The only trustworthy signal is the signature-verified webhook from the gateway, handled idempotently so that a repeated or late event never counts twice. That is precisely how AtelierLab's Razorpay integration is built, and it is the first thing worth asking about any tool that sits between you and your fee.
What it costs, and when it arrives
Razorpay's standard plan is published with no setup fee and no annual maintenance charge, at 2% on domestic transactions, with GST payable on the fee itself. The standard settlement cycle is published at T+2 working days from capture. Both are worth reading on Razorpay's own pricing page before you commit, because a rate card is a live document and UPI in particular has been subject to zero-MDR regulation that does not apply to cards.
| Line | Amount |
|---|---|
| Fee invoiced to the client | ₹1,00,000 |
| Gateway charge at 2% | ₹2,000 |
| GST on the gateway charge, 18% | ₹360 |
| Settled to the studio | ₹97,640 |
Illustrative, at the published standard rate. Your actual rate depends on the plan and the payment method, and the GST on the gateway charge is generally creditable if you are registered.
Two per cent of a stage payment is a real number and it deserves an honest comparison rather than a defensive one. Set it against the alternative properly: the hours spent reconciling transfers, and more importantly the days between a payment being made and anyone noticing. On a fee schedule where drawings are released against payment, the difference between confirmation in a second and confirmation on Thursday afternoon is a difference in how fast your studio can work.
Going live: a checklist
Before the first real client sees a payment link, walk this. It takes twenty minutes and each line represents a way a studio has been caught out.
Swap the keys, everywhere
Test and live keys are different pairs. Check the server, any scheduled job, and anything that reads the key from an environment file. A live checkout backed by a test key fails in a way nobody can interpret.
Point the webhook at production and verify the signature
A webhook endpoint that accepts unsigned requests is an endpoint anyone can post a fake payment to. Verify every one, and reject anything that does not match.
Handle the same event arriving twice
Gateways retry. Your handling must be idempotent, so a duplicate or late event never releases a set of drawings a second time or double-marks an invoice as paid.
Run one real payment, then refund it
A small amount from your own card. It proves the live keys, the settlement details, the refund path and the cancellation behaviour that test mode could not show you.
Check the settlement actually lands
Wait out the settlement cycle and confirm the money reached the right bank account. The first live settlement is the only real proof the account details are correct.
Reconcile the tax side once
Your fee invoice carries 18% GST under the architectural SAC code; the gateway's charge to you carries its own GST, generally creditable. Get one cycle right with your accountant and the rest follow.
Where the money lands
One structural question is worth more than the whole rate card: whose account does the payment settle into? Two arrangements exist and they are frequently described in the same language.
| Platform wallet | Your own account | |
|---|---|---|
| Client pays | Into the platform's account | Into your Razorpay account |
| You are paid | On the platform's payout schedule | On the gateway's settlement cycle |
| If the platform fails | Your money is in the queue with everyone else's | Your money was never theirs to hold |
| Relationship | You are the platform's payee | You are the gateway's merchant |
Ask the question in exactly these words: does the client's payment enter your account or mine? An answer that takes more than one sentence is an answer.
AtelierLab takes the second arrangement, deliberately. You connect your own Razorpay account in one click through official OAuth, so no keys are typed or stored, and payments settle straight to you. We never hold or route the money, which also means we never have a float to lose or a payout schedule to negotiate. The checkout your client sees takes cards, UPI and netbanking with no account to create on their side.
The part a gateway does not solve
It is worth being clear about the limit. A gateway makes payment easy and confirmation instant. It does nothing whatever about the harder problem, which is that a client with the drawings already in hand has very little reason to hurry.
That problem is solved by sequence rather than by convenience: the invoice is attached to the set, the set stays sealed until the payment clears, and it then releases itself. Raise, pay, unlock, in that order, which is what payment-gated issue does and why the gateway matters at all. The reasoning behind the sequence, and the stage-by-stage schedule it runs on, is set out in the article on stage-wise fees.
Your gateway, your account, your drawings
AtelierLab connects your own Razorpay account through official OAuth, verifies every payment by signed webhook, and releases the set of drawings the moment the money clears. Nothing is held in the middle. We're onboarding our first studios now, with personal setup for each practice.
Questions, answered
The questions architects ask most about this, in plain language.
Ask us anythingThe documented domestic test card is the Visa number 4111 1111 1111 1111, used with any future expiry date, any three-digit CVV and any name. Whether the payment succeeds is controlled by the OTP rather than the card: a random OTP of four to ten digits succeeds, and one under four digits fails. These cards only work with test-mode API keys; used against live keys they return an invalid card issuer error. Razorpay maintains the current list, including international, EMI and subscription cards, in its own documentation.
Use the documented test virtual IDs in test mode: success@razorpay completes the payment immediately and failure@razorpay declines it immediately. One limitation matters, because it is easy to miss: in test mode a cancelled UPI payment is recorded as successful, so cancellation cannot be tested there at all. Verify that path with a small live payment instead, which is worth doing anyway before the first client sees a link.
They are separate environments with separate API key pairs. Test mode runs the real checkout flow against a simulated bank, so no money moves and test cards work. Live mode moves real money and rejects test cards. Nothing done in test mode proves the live path works: settlement to your bank account, real issuer declines, and your own webhook handling under duplicate or delayed delivery are only exercised live, which is why one real payment followed by a refund belongs on every go-live checklist.
Broadly, identity and PAN for the proprietor or entity, bank account proof such as a cancelled cheque or statement, GST registration where you are registered, and business proof appropriate to how you practise, which for a proprietorship can be a registration certificate or a utility bill in the business name and for a company or LLP is the incorporation paperwork. The most common cause of delay is a name mismatch between the PAN, the bank account and the business proof. Razorpay's onboarding lists the exact requirement for your entity type.
The standard plan is published with no setup fee or annual maintenance charge, at 2% on domestic transactions with GST payable on that fee, and a standard settlement cycle of T+2 working days from capture. Rates differ by payment method and plan, and UPI has been subject to zero-MDR regulation that does not apply to cards, so check the current published pricing rather than relying on a figure in an article. The GST on the gateway's charge is generally creditable if you are registered.
No. A surcharge line on an architectural invoice reads as petty for the amount involved, invites the client to ask whether they can just do a bank transfer instead, and thereby undoes the reason you added a gateway. Price it into the fee alongside every other cost of running the studio, in the same way you do not itemise your printer.
That depends entirely on the platform, and it is the most important question to ask any tool that sits between you and your fee. Some hold client payments in their own account and pay you out on their schedule, which puts your fee in a queue if anything goes wrong at their end. AtelierLab takes the other arrangement: you connect your own Razorpay account through official OAuth, payments settle directly to you, and we never hold or route the money.
Because the browser cannot be trusted with that question. A client can complete a payment and lose their connection before the page returns, or be shown a success screen while the capture is still in flight, and either case leaves your records wrong in a way that surfaces days later. The signature-verified webhook from the gateway is the only reliable signal, and it must be handled idempotently so that a duplicate or late event never marks an invoice paid twice or releases a set of drawings a second time.