Frontend Beauty
ESC

Type to search the knowledge base.

Razorpay Frontend Interview

How payment-product frontend loops usually mix JS problem solving, machine coding, and product sense. Composite guidance, not a personal diary.

advanced6 min read
  • interview-experience
  • razorpay

Composite guidance based on publicly shared candidate reports and common hiring patterns for frontend / UI roles at payment products. Processes vary by role, level, team, and year. Always confirm with your recruiter. Not a personal diary, and not affiliated with Razorpay.

A Razorpay frontend interview is easy to misread as “build a pretty checkout.” The miss is usually a double submit. You wire a Pay button, the network is slow, the candidate clicks twice, and now you have two client-side attempts for one user intent. Payment UIs are scored on whether you treat clicks, retries, and failure copy as the product, not as CSS polish.

Gateway and merchant-dashboard teams still run JavaScript problem solving and a machine-coding slice. Product sense shows up as questions about amounts, idempotent requests, and what the user sees when a bank page never returns.

Key takeaways

  • Expect a JS round, a timed UI build, and a conversation about money-safe interaction, not a leetcode-only loop.
  • Idempotent clicks, disabled states, and honest errors beat a pixel-perfect card form.
  • Stay in frontend scope: PCI and settlement ledgers are not yours to invent.
  • Confirm screens, languages, and whether machine coding is pair or take-home.

Typical loop for UI engineers at payment companies

Stage Focus Format
Recruiter Role, level, stack, notice Call
JS / problem-solving screen Language, async, small utils Shared editor or OA
Machine coding Checkout-like or dashboard slice 45–90 min
Product / web depth Money UX, a11y, browser Conversation + code
Hiring manager Ownership, tradeoffs Call

Some teams insert an online assessment before the first live round. Others go straight to a pair session. Senior loops add a frontend design conversation (checkout steps, payment-method list, refund status). Do not memorize a four-round script. Ask the recruiter what you will actually sit.

What they score across those stages is consistent even when the labels change:

  1. Correct JS under time, with edges named out loud.
  2. A working UI path, not a component library demo.
  3. Respect for money: no silent retries, no lost amounts, no unlabeled errors.

JavaScript problem solving

Payment-company screens often look like general frontend JS: closures, the event loop, this, array transforms, debounce, and promise combinators. You might implement a small util rather than a graph problem. You might still get medium DSA in JavaScript.

Practice the pattern set, not a dump of company-tagged puzzles:

Delivery: restate inputs, give one example, code a standalone function, dry-run a failure case (empty list, rejected promise, double click). Silent perfect code is a weak signal.

Machine coding on money-shaped UI

Typical shapes (not claimed Razorpay transcripts):

  • Multi-step checkout: method → amount confirm → processing → success/fail
  • Payment-method list with one selected instrument
  • OTP / PIN boxes
  • Merchant dashboard table: status filters, pagination
  • Amount input with validation and a disabled Pay state

Build those muscles with OTP input boxes, multi-step wizard, shopping cart drawer, and accessible modal. Timebox with the machine coding interview framework: happy path first, then loading/error/empty, then keyboard.

A tiny client-side guard is fair game to mention while you code. It is not a substitute for server idempotency keys.

function createPayOnce(pay) {
  let inFlight = null;
  return function payOnce(payload) {
    if (inFlight) return inFlight;
    inFlight = Promise.resolve()
      .then(() => pay(payload))
      .finally(() => {
        inFlight = null;
      });
    return inFlight;
  };
}

Talk through the rest: disable the button, keep the amount in state so a rerender cannot swap it, show a processing status that is not a blank screen, and do not innerHTML a gateway error string.

Product sense without inventing PCI

Interviewers in this domain listen for whether you know the boundary.

Topic Frontend owns Do not overclaim
Card data Hosted fields / never log PAN Homegrown card vault
Retries UX + idempotency key you were given “Just POST again”
Amounts Display, locale, integer minor units Float rupee math
3DS / UPI redirect Return URL, timeout copy, resume Bank protocol design
Refunds Status list, empty states Ledger consistency

Money math belongs in integer paise/cents or a decimal library. 0.1 + 0.2 is not a joke here. See number precision. Forms need names, errors next to fields, and keyboard submit. See accessible forms.

If the prompt is a dashboard, talk list virtualization, status enums, and filters that do not refetch on every keystroke (debounce the search, abort the previous fetch).

Design conversation (mid+)

Possible surfaces: hosted checkout, payment links, subscription settings, settlement reports. Structure the answer the same way you would Design YouTube:

  1. Users (payer vs merchant) and the one job of the screen
  2. Component tree and source of truth for amount and status
  3. Network: timeouts, abort, retry policy
  4. Failure UI and support-facing copy
  5. Perf and a11y on the critical path

Footguns

  • Enabling Pay while the amount is still being edited
  • Using GET for a charge, or putting secrets in the query string
  • Treating finally as “always success”
  • Skipping empty states (no saved methods, bank timeout, declined)
  • Building a design-system from scratch in a 60-minute MC round

Preparation plan (5–7 weeks)

  1. Weeks 1–2: Teach-back JS: event loop, promises, closures. Write polyfill-style functions by hand.
  2. Weeks 3–4: Timed DSA in JS (Two Sum, Valid Parentheses, LRU Cache) plus one MC rebuild per weekend.
  3. Week 5: Checkout and OTP from memory. Practice a 15-minute design outline for payment status.
  4. Week 6–7: Mocks. After each, write three concrete fixes. Confirm the loop with the recruiter.

Out loud: “I would ship a checkout that cannot double-fire from the button, keeps amount and order id in one place, and shows processing, success, and a retryable failure. Retries reuse an idempotency key from the server. I would not store card PAN in app state. For the JS screen I start with a standalone function, edges, then complexity.”

Further reading