Stripe Fresher Interview Questions
Stripe builds the payment systems that online businesses plug into through an API, so a shop or an app can take a card payment without building that part itself. As a fresher, expect your basics to be tested where a mistake costs someone money. Practice explaining how to store amounts, how a request travels from a pay button to a server, and how to make sure a slow click never charges twice. What to show here: careful, exact thinking where a small bug costs someone money. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Stripe hires, in its own words, and its questions for every job →
1. Tell me about a project where you built something other people called from their own code, such as a small API or a library. What did they get wrong that you had not expected?
- Describe what you built and who used it.
- Share one way they used it that surprised you.
- Explain how you changed the interface or the documentation.
- Say what you check first now.
“For a hackathon I built your project, a small API that returned bus timings, and two other teams used it. I expected questions about the data. Instead, they struggled with the basics: one team sent the stop name in the wrong case, and my API answered with an empty list rather than an error, so they thought there were no buses. I changed it to return a clear error with the valid names, and I wrote an example request at the top of the readme. The outcome was your result. Now I write the first example before I write the code.”
Weak answers blame the users for not reading, or describe an interface nobody else actually used.
2. Describe a time you found a small mistake in your own code that could have caused serious harm if it had reached real users. How did you catch it?
- Describe the code and what the mistake was.
- Explain how you noticed it.
- Share what would have happened otherwise.
- Describe the habit you added.
“During an internship I wrote a script that sent reminder emails to customers with unpaid invoices. Before running it, I printed the list of people it would email. The list was far too long. My filter compared dates as text, so it matched almost everyone, including people who had paid. Had it run, thousands would have received a wrong demand for money. I fixed the comparison and added a test with paid and unpaid examples. Since then, anything that touches customers runs in a dry mode first that only prints what it would do. The result was your result.”
Weak answers claim never to have made a serious mistake, or describe catching it only after users complained.
3. Why should a payment amount be stored as a whole number of the smallest currency unit, and not as a decimal like a price on a shop shelf?
- Explain that floating point cannot store many decimal fractions exactly.
- Show how tiny errors add up over many payments.
- Store whole numbers of the smallest unit and the currency code.
- Mention currencies with different numbers of decimal places.
“Computers store decimal numbers in binary, and many simple fractions cannot be written exactly in binary, so a price can be stored as a value that is very slightly off. One payment would look fine after rounding, but adding many of them, or splitting a fee, can produce totals that are off by a small amount, and with money that is not acceptable. So I would store amounts as whole numbers of the smallest unit, such as cents or paise, together with the currency code. Not every currency has two decimal places, so the code is needed to display the amount correctly.”
Weak answers say a decimal type is fine everywhere, or do not know why floating point is inexact.
4. A shopper clicks the pay button, the page is slow, so they click again. How would you make sure the shop charges them only once?
- Explain why two requests reach the server.
- Give each payment attempt a unique key created before the first click.
- Have the server remember the key and its result.
- Return the same result for the repeated request.
“Both clicks reach the server as separate requests, and disabling the button in the page helps but is not enough, since the browser may retry by itself. So I would create a unique key for the payment attempt when the checkout page loads, and send it with every request for that attempt. The server stores the key with the result of the first request. When the second request arrives with the same key, the server does not charge again. It returns the stored result, so the shopper sees the same success page. The key must be saved before the charge is made.”
Weak answers only disable the button, or check for a recent payment of the same amount, which blocks honest repeat purchases.
5. Design tables for customers, payments and refunds, where one payment can be refunded in several parts. How would you stop the refunds from adding up to more than the payment?
- Define the three tables and their keys.
- Link each refund to one payment.
- Store amounts in the smallest unit with a currency.
- Enforce the total inside one transaction.
“I would have a customers table, a payments table with a foreign key to the customer, and a refunds table with a foreign key to the payment. Each payment and refund stores an amount as a whole number in the smallest unit, plus the currency, plus a status and a time. One payment can have many refund rows. To keep refunds from exceeding the payment, I would not trust the application alone. When a refund is requested, I would lock the payment row inside a transaction, add up existing refunds, check the new one fits, and only then insert it. I would keep a refunded total on the payment for quick reads.”
Weak answers put the refund amount as one column on the payment, or check the total without a transaction.
6. Walk me through what happens between a shopper pressing pay on a website and the business seeing that the payment succeeded. Where can it fail?
- Browser sends card details to the payment service, not to the shop.
- The shop's server asks the payment service to charge.
- The payment service asks the bank and replies.
- Name failures at each hop and how each side learns the result.
“The card details should go from the browser straight to the payment service over a secure connection, so the shop never handles them. The shop's server receives only a token that stands for the card. It then calls the payment service with the token and the amount. The payment service asks the card's bank, which approves or declines, and the answer comes back as a status code and a body. The shop's server then shows the result page. It can fail at any hop: the bank can decline, the network can drop, or the shop's server can crash after the charge. So the shop also listens for an event from the payment service.”
Weak answers send card numbers through the shop's own server, or cannot say how the shop learns about a charge whose reply was lost.
7. Your test integration takes payments fine on your laptop. A classmate tries it with a card from another country and it fails every time. What do you do?
- Get the exact error message and request from the classmate.
- Compare their request with yours field by field.
- Test the same case yourself with a test card.
- Fix the cause and add it to your tests.
“I would first ask for the exact error response, not just that it failed. Payment services return a code and a message, and that usually points to the cause. Then I compare the classmate's request with mine, field by field. A card from another country often means a different currency, a different postcode format, or an extra verification step that my code did not handle. I would reproduce it on my own machine using a test card for that country. Once I find the cause, I fix it, add the case to my tests, and ask the classmate to try again.”
Weak answers say it works on my machine, or change random settings without reading the error.
8. Why do you want to begin your career at Stripe, where the product is a payments API that other developers build on?
- Say what interests you about payments or developer tools.
- Link it to something you built or studied.
- Say what you hope to learn.
- Keep it about the work.
“I like the idea of building the piece that other builders depend on. When a developer adds payments to their app, they trust that every charge is right and every error is clear. I felt a small version of that pressure in your project, when a filter mistake could have emailed the wrong people, and it made me more careful than any course did. I want to learn how engineers make software correct when money is involved, and how to write an API and documentation good enough that a stranger gets it right the first time.”
Weak answers talk about the company being well known and never mention payments, APIs or correctness.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
The questions above are the prep. On the real call, ClapAssist helps with the ones you did not practice.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.