👋 Meet Smile Gupta:
Smile Gupta, Payments Engineer at Wayfair and ex-Razorpay, shared hard-earned lessons from years in the trenches of payments engineering. She sat down with CodeWalnut's Engineer Saumya to explore what it takes to build payment systems that hold up in the real world. Smile shared lessons on reverting a bad PR with three lines of code. She discussed why Safari and web views remain painful. She also explored the mindset shift junior engineers need today.
About the Company:
Wayfair is one of the world's largest online destinations for the home, serving millions of customers across the US, Canada, UK, Germany, and beyond with a catalog spanning furniture, decor, and appliances.
Behind the scenes, Wayfair's payments infrastructure handles billions of dollars in transactions across every browser, device, and network condition imaginable, from high-speed 5G in metros to 3G in smaller towns, from Chrome on the desktop to Safari inside a web view.
For engineers on Wayfair's payments stack, that scale is the everyday reality. Every optimization decision, every failure mode, and every browser quirk shows up multiplied across a global customer base, which is exactly the environment Smile operates in.
Before We Hit Record
I really enjoy meeting engineers who have built their craft the hard way, one payment flow, one edge case, one late-night debugging session at a time.
At React Nexus earlier this year, I attended one such engineer's talk. Smile Gupta walked the room through the messy reality of building payments for the web, and I ended up clicking pictures of nearly every slide. A few days later, I got the chance to sit down with her for a longer conversation.
Being both technically sharp and refreshingly candid, Smile painted a vivid picture of what payments engineering looks like from the inside. Here are excerpts from the chat...
Inside Payments Engineering at Wayfair
Smile leads payments engineering work at Wayfair, where she is building towards the payments team, working on a stack that quietly moves money for millions of customers every day.
Before Wayfair, she spent four years working on the payments team at Razorpay, one of India's leading payment gateways, going deep on gateway integrations, redirect flows, and the browser-level edge cases that decide whether a transaction actually completes.
Smile's career has been shaped as much by community work as by her day job. She leads the 'JS Lovers' community in Bangalore, and also founded a meetup series called "System Design Saturdays", and has spoken at React Nexus and React India.
She has seen firsthand how the smallest UI decisions in a payment flow can either build user trust or quietly erode it.
Key Takeaways From the Conversation
1. AI Agents Need Human Oversight (Especially in Debugging)
When a payment flow shows the wrong message, users don't blame the backend. They stop paying.
Key insights:
- Stale states, misleading spinners, and confusing error screens quietly erode trust and are the fastest way to lose a transaction.
- The rule cuts across every provider: whatever you build, do not break user trust. Provider APIs differ, this principle doesn't.
- As AI generates more UI, the trust bar goes up, not down. Users need to trust the response an AI-driven interface gives them.
2. Mature Engineers Don't Just Ship Happy Paths, They Design for the Edge Case
"Real engineering doesn't come from happy cases. It comes from the edge cases and handling things differently."
Key insights:
- System design is deeply underrated. Most engineers underestimate how complex designing a resilient system truly is.
- Developers who build on 5G never see the issues real users hit. Rule of thumb for payments: go two levels back on the network and test on 3G.
- A payment client is never one client. Safari, web views, Chrome, and poor devices all coexist, and every one of them is a place your flow can break.
Key insights:
"AI is overconfident. Even when it is doing the wrong thing, it tells it with such confidence that you think maybe I am wrong and AI is doing right."
Key insights:
- Agents hallucinate on error paths, over-complicate simple problems, and get stuck in debugging loops that require killing the session and starting fresh.
- Right judgment lives with humans. If you cannot describe the three approaches yourself, you cannot evaluate which one the agent should take.
- A three-line revert can turn into fifteen file changes if you ship what the agent hands you. Reading the code before you accept it is still the work.
3. Community is a Chain, and Somebody Started Yours
"Today we helped you, it would always be nice if you build your own chain. That's how I do community stuff."
Key insights:
- A single Hacktoberfest meetup attended for a free t-shirt was enough to change one engineer's trajectory. Communities compound in ways no roadmap plans for.
- Twitter, not LinkedIn, is where the real tech community lives. A feed built up since 2020 and 2021 surfaces trends earlier than any newsletter.
- Inspiring even one person per meetup counts as a win. One 'JS Lovers' member gave his first talk at React Nexus this year after being encouraged to present.
Interview Excerpts: Questions and Answers
Q: Is there a general principle you follow before applying any optimization to a payment flow?
Smile: A lot of things are provider-specific, but one rule of thumb I apply to any optimization we do or build around payments is: whatever you build, you don't break user trust. Sometimes you're just showing spinners. Sometimes you're showing stale states. Anything that shows wrong messaging to the user, anything that breaks user trust, that is the one principle I try to apply to all problems.
Q: With agents now able to write the happy path, where do you think the real skill gap for engineering is shifting to?
Smile: People blindly push stuff. If AI gives them option A, and AI is something which is overconfident, even when it is doing the wrong thing it tells it with such confidence that you think maybe I am wrong and AI is doing right, people just accept it. Agents hallucinate on the error parts. They are not trained enough on the right set of data to tell you the wrong parts.
The second thing is agents tend to write a lot of complex things. That is where designing systems comes into the picture. If you know what will work well in a situation, the right judgment, that is something the agent lacks. And I don't think right judgment is something the agent will get anytime soon, because that is where human intervention comes in. Agents are also pretty bad at debugging as of now. They end up writing a lot of complex things, and then they get stuck in a loop trying to debug the issues. A lot of times I have had to kill the agent session and start a fresh session for it to come out of the loop.
Q: If you were designing a payments course for junior engineers today, what would you make sure is taught in the very first week?
Smile: The very first thing is a right mindset, that payments is beyond clicking one button, and beyond just getting the status back from the backend payment service provider. It is about designing a scalable system. One client is not the only thing. You will have Safari, you will have web views, you will have Chrome, you will have people with bad internet connections, people with poor devices.
When developers build things, generally they build everything on high-speed 4G or 5G, and they never see the issues. Rule of thumb: if you are building a payment system and you are doing development on 5G, go two levels back on the network and try testing your system on 3G as well. The first week would be about adding the right mindset for core engineering, because you are the one who will try to gain that trust from a consumer to the merchant. The world runs on payments. Money movement is needed, and money movement needs to be seamless.
Q: Safari and web views are known to cause issues in payment flows even in 2026. Why do they continue to be the most painful environment?
Smile: Payments are designed on systems that depend on cross-system handoffs. Redirect flow is there, you redirect to a bank page, then you need to come back. Sometimes you need to read cookies, sometimes you need to read the session. In case of apps, you need to switch between apps.
Safari and web views are painful. I won't say they are bad browsers, but they are more aggressive on some things, privacy, tracking prevention, storage isolation, hard pop-up rules, cookie restrictions. In a nutshell, they have a lot of browser boundaries. They are optimizing different things, but it is not aligning towards payments. So yes, it will always be a pain. There was a time when IE9 and IE11 used to be the painful browsers. Some client restrictions will always be there, even beyond 2026.
Q: For engineers early in their careers who won't get the same years of hands-on manual coding experience, how should we go about building real expertise in this AI-driven environment?
Smile: AI is able to generate a lot of code, but I won't say that learning stops there. In the previous days there used to be Stack Overflow. People used to look at a lot of CodePens for inspiration, some blogs. That was their source of generated code. Today, that generated code, we don't need to search 10 different things, it is available with our LLM companion. If you understand what is getting generated from that LLM, that is good enough.
But you have to challenge it. If I tell you three approaches and ask what we should proceed with, if you don't know what those three approaches are, and you don't know what will perform better and what won't, how will you take the judgment call? Today people are not thinking twice. They are not challenging AI solutions. Someday that bubble will break. Recently I wanted to do a revert PR during a deploy lock at Wayfair. I asked AI to revert, it made 10 to 15 file changes. I was able to simply do it in three lines. Because I knew the system, I knew what the better revert strategy was. I read the code thoroughly, I don't trust it blindly, and yes, that comes with years of debugging.
Q: You've spent years deep in payments. What's your process for turning hands-on experience into expertise you can teach?
Smile: One thing we started last year as part of my meetup group is a new series called "System Design Saturdays". We ditch the cool stuff people are running behind, frameworks, nuances, optimizations, and we go ground-down on the more fundamental foundations of any thing, because foundations remain the same ignoring all the frameworks.
System design is very underrated. People don't think about how complex designing systems can be. People think of happy cases. They forget that real engineering doesn't come from happy cases. It comes from the edge cases, and from handling things differently.
Q: You lead JS Lovers and volunteer at every event. What motivates you to keep building that community?
Smile: It goes back to 2017 and 2018. I didn't know anything about tech communities. There was one event happening in my college, Hacktoberfest, and some seniors said do four pull requests and you will get a free t-shirt. That was my first meetup. Honestly, I wasn't able to make much sense of it that day. It was on Git and GitHub basics, and it went over my head. I just went for the free t-shirt and goodies.
But after that session I started reading more. A few people in the community helped, and they taught me what web development could be. Towards the end of the meetup, one thing was told to us: today we helped you, it would always be nice if you build your own chain. That is how I do community stuff. I try to build my own chain. Even if I do a meetup and I end up inspiring even one person, that is a win-win situation for me.
Wrapping Up:
Thanks to Smile for the clarity and candour. And for reminding us that when real money movement is at stake, code generation is the easy part. Engineering judgment is the real differentiator.
When to Hire CodeWalnut?
