razorpay Security Engineer Interview: Questions & Prep (2026)

Razorpay is one of India's most prominent fintech companies, powering payments for millions of businesses and developers across the country. Security sits at the core of what they do: protecting transaction data, preventing fraud, and maintaining trust with merchants and regulators. Right now, Razorpay has 42 open Security Engineer roles, signalling active hiring across application security, infrastructure security, cloud security, and compliance. The knok jobradar (July 2026) shows 628 Security Engineer openings across India, with Bangalore leading at 69 roles.

Candidates typically go through a recruiter screening, two or three technical rounds, and a final culture or leadership interview. Questions cover threat modeling, incident response, secure system design, and fintech-specific topics like PCI-DSS and API security. This guide walks you through the questions that come up most often and how to answer them well.

These are the questions Razorpay interviewers commonly focus on for Security Engineer roles. They test both technical depth and your ability to apply security thinking in a fast-moving payments company.

1. How would you design a threat model for a payment gateway handling millions of transactions?
2. A developer accidentally commits an API key to a public GitHub repo. Walk me through your response.
3. How do you prevent replay attacks in a payments API?
4. How do you secure inter-service communication in a microservices architecture?
5. What is your experience with PCI-DSS compliance, and what controls have you personally implemented?
6. A merchant reports suspicious withdrawals through the platform. Describe your incident response process step by step.
7. How would you handle a zero-day vulnerability in a third-party library that a core payment service depends on?
8. How do you manage secrets (API keys, credentials, certificates) across a cloud-native infrastructure?
9. A product team wants to ship a new feature in two weeks. How do you conduct a security review without blocking them?
10. How would you build rate limiting and bot protection for a public payments API?
11. How do you integrate security testing (SAST, DAST, pen testing) into a CI/CD pipeline?
12. How have you worked with engineering teams to raise security awareness without creating friction or delays?

Q: How would you design a threat model for a payment gateway?

*Situation:* At my previous company, we were launching a new payment collection API that would be exposed to third-party merchants.

*Task:* I was responsible for threat modeling the API before launch, covering data flows, trust boundaries, and attack vectors.

*Action:* I used the STRIDE methodology to identify threats across each component. I mapped data flows from the merchant integration layer to the payment processor, identified trust boundaries at the API gateway and internal services, and listed threats including spoofing merchant identity, tampering with transaction amounts, and information disclosure of card data. I worked with product and engineering to prioritise threats by likelihood and impact, then proposed controls: mutual TLS between services, input validation at every boundary, tokenisation of sensitive card data, and detailed audit logging for every transaction state change.

*Result:* We caught three high-severity gaps before launch. Two were fixed in the same sprint, and the third was mitigated with compensating controls. The feature launched on time with no security incidents in the months that followed.

---

Q: A developer commits an API key to a public GitHub repo. Walk me through your response.

*Situation:* This exact scenario came up during an on-call shift at a past job. A junior developer pushed a config file containing an internal service credential to a public repository.

*Task:* I needed to contain the exposure quickly while minimising disruption to running services.

*Action:* I immediately revoked the exposed credential and generated a replacement, injecting it via our secrets manager. I pulled access logs for that credential from the moment of the commit onward to check for any external use. I filed an incident report, confirmed the replacement propagated to all dependent services, and then ran a broader audit of the CI/CD pipeline to find other places where credentials might be embedded in code or config files.

*Result:* No unauthorised access was found in the logs. We rolled out a pre-commit hook and a secrets scanning step in the pipeline so the same mistake could not reach a remote repo again.

---

Q: How do you run a security review without slowing down product teams?

*Situation:* At a previous role, product teams felt that security reviews were a bottleneck and sometimes shipped features without them.

*Task:* I was asked to redesign the review process to be faster without reducing coverage.

*Action:* I created a lightweight security checklist covering the top risk areas for our product: authentication, authorisation, input validation, data exposure, and third-party dependencies. Teams could self-assess before coming to me. I introduced threat modelling templates for common feature types (new API endpoint, new data store, new third-party integration) so teams could start the analysis themselves. I reserved deep reviews for high-risk features and ran short training sessions so engineers could handle routine ones independently.

*Result:* Review turnaround dropped considerably. Security coverage actually improved because more engineers understood the basics and caught issues earlier in development.

Use these frameworks to structure your answers when you are not sure how to begin.

STAR for experience questions: Situation, Task, Action, Result. Always end with a concrete or observable outcome. Interviewers want to know what you personally did, not what 'the team' did.

STRIDE for threat modeling questions: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Mentioning this framework signals structured thinking. Walk through each category for the specific system in the question rather than listing generic threats.

Risk = Likelihood x Impact for prioritisation questions: When asked how you prioritise security work, frame your answer around this equation. A critical vulnerability in a rarely-used internal admin tool may rank lower than a medium-severity issue in the payment checkout flow.

Shift left for process questions: When asked about integrating security into engineering, talk about moving checks earlier: threat modeling at the design stage, SAST in the IDE, secrets scanning in pre-commit hooks, and DAST in staging rather than relying on a quarterly pen test.

Three audiences for communication questions: Security Engineers at Razorpay work with engineers, product managers, and executives. Prepare to explain the same issue three ways: technical detail for engineers, business risk for product, and regulatory or financial impact for leadership.

Razorpay interviewers look for a specific mix of skills and behaviours when hiring Security Engineers.

Fintech context: Generic security knowledge is not enough. Interviewers want to see that you understand payment flows, PCI-DSS obligations, fraud vectors in UPI and card networks, and India's regulatory environment. Connect your answers to the payments domain wherever possible.

Depth over breadth: Candidates who give surface-level answers to every question score lower than those who go deep on a few areas. Pick two or three domains where you have strong hands-on experience (cloud security, appsec, or incident response) and be ready to go into real detail.

Speed with safety: Razorpay moves fast. Interviewers want security professionals who work with engineering teams, not against them. Show that you understand business timelines and can propose pragmatic controls rather than blocking releases until everything is perfect.

Clear communication: You will work with engineers, product managers, and business stakeholders. Interviewers often ask you to explain a security concept to a non-technical person. Practice doing this without jargon and without losing the key point.

Ownership mindset: Razorpay values engineers who take end-to-end ownership. Do not frame past work as 'we did this.' Be specific about what you personally drove, decided, or built.

A focused plan for Razorpay Security Engineer interviews, spread across three to four weeks.

Week 1: Foundations and domain context
Review the fundamentals: OWASP Top 10, common API security flaws, TLS and certificate management, and secrets management best practices. Read about PCI-DSS requirements, especially those relevant to card data environments. Study how UPI, payment gateways, and acquiring banks interact so you can speak to fintech-specific threats with confidence.

Week 2: Technical depth
Pick two or three security domains to go deep on. Cloud security, application security, incident response, and identity and access management are most relevant for Razorpay. For each domain, prepare two or three stories from your own experience using the STAR format. Practice explaining STRIDE-based threat modeling out loud until it feels natural.

Week 3: System design and scenarios
Practice designing secure systems. Common prompts include: 'Design a secrets management system,' 'How would you secure a multi-tenant API,' or 'Walk me through your incident response plan for a data breach.' Time yourself and aim to cover threats, controls, and trade-offs in each answer.

Week 4: Mock interviews and company research
Do at least two mock interviews with a peer who can push back and ask follow-up questions. Research Razorpay's public security posture, their bug bounty programme, any publicly reported incidents, and their engineering blog. Prepare three or four questions to ask your interviewers that show genuine curiosity about the team's work.

While you are deep in prep, knok checks 150+ job sites nightly, applies to roles that match your resume, and messages HR on your behalf, so you are not losing ground on applications while you focus on interview practice.

Giving textbook answers without context: Saying 'I would use TLS' or 'I would follow OWASP' without linking it to a real scenario or trade-off signals shallow experience. Ground every answer in something you have actually done.

Ignoring fintech specifics: Candidates who treat this like a generic security interview miss the mark. If you do not mention payment flows, PCI-DSS, fraud prevention, or regulatory compliance at least a few times, interviewers will question how much you researched the company.

Over-engineering the solution: Proposing a complex, multi-layer security stack for a simple question about rate limiting suggests you cannot prioritise. Start with the simplest control that works, then discuss what you would add and why.

Claiming team credit as personal credit: Phrases like 'we implemented' without clarifying your specific role leave interviewers guessing. Be clear about what you personally owned, decided, or built.

Not asking clarifying questions: Security scenarios often have missing context (what is the data sensitivity? what are the compliance requirements? what is the threat model?). Asking before you dive in shows real-world thinking, not uncertainty.

Skipping the business impact: Always connect security decisions to business outcomes. Mention the risk or cost that a control addresses, not just the technical detail of the control itself.