You built an app with AI tools, and now you want it to take money. That is a good problem to have. It is also the point where a lot of solo builders freeze, because the fear is real: paste a key in the wrong place and you could hand a stranger the ability to move money through your account.
Here is the reassuring part. Adding Stripe to an AI-built app is mostly one skill, repeated carefully: keeping your secret key on the server and out of every place it could leak. If you get that one thing right, most of the scary scenarios never happen. This is a test-first, detection-first walkthrough. We will build in a mode where mistakes cost nothing, verify the AI put things where they belong, and stop at a clear line where you should bring in a professional.
A quick boundary before we start. This is educational, not legal or PCI advice. Payments touch other people's money and card data, so treat everything here as a way to reduce risk and ask better questions, not a guarantee. When you get to the go-live section, you will see exactly where expert review belongs.
What a payment key actually is, and why leaking one is the real risk
When you sign up for Stripe, you get a pair of API keys. Think of a key as a password your app uses to talk to Stripe. The important idea: some of these keys are safe to show the world, and one of them absolutely is not.
Your secret key is the dangerous one. It can create charges, issue refunds, read customer details, and generally act as you. If someone copies your live secret key, they can potentially move money and pull data until you notice and rotate it. That is why the entire job here is placement: the secret key lives on your server, in a protected slot, and never travels anywhere a browser, a chatbot, or a curious visitor can read it.
A leak usually is not a dramatic hack. It is mundane. A secret key gets hardcoded into frontend code and shipped to every visitor's browser. It gets committed to a public code repository. It gets pasted into a chat window to ask for help. None of those feel risky in the moment, which is exactly why they happen. Treating your secret key with the same care you would a bank password is the whole mindset.
If you have read things to never paste into a chatbot, this will sound familiar. A Stripe secret key belongs at the top of that never-paste list.
Publishable vs secret keys: which goes where, and never the reverse
Stripe gives you two kinds of keys for a reason. Understanding the split removes most of the guesswork.
| Key type | Where it belongs | Can it be in the browser? | What it can do |
|---|---|---|---|
| Publishable key | Frontend (browser) | Yes, safe by design | Identify your account so Stripe can safely collect card details on the client |
| Secret key | Server only (backend, environment variable, secret manager) | No, never | Create charges, refunds, read customer and payment data |
The publishable key is meant to be visible. It is built to sit in the code that runs in your user's browser so Stripe's own components can collect card details safely on your behalf. Seeing it in "view source" is fine.
The secret key is the opposite. It should exist only where your server code runs, tucked into an environment variable or your platform's secret manager. A user should never be able to find it by inspecting your page, reading your app's downloaded files, or poking at network requests.
The mistake that causes real damage is putting the secret key where the publishable key goes. If your secret key ends up in frontend code, in a config file that ships to the browser, or in a client-side variable, treat it as exposed even if nobody has abused it yet. Hardcoding either key directly into your source is a bad habit, but hardcoding the secret key into anything the browser can reach is the emergency version.
One more note on card details themselves. With Stripe's standard hosted and embedded checkout components, card numbers are collected by Stripe's code and sent to Stripe, so the raw card number generally does not pass through or get stored on your server. That design is a big part of what keeps your compliance scope smaller. How much smaller depends on exactly how you integrate, which is a question for the compliance section and the professional review below, not something to assume.
Build in test mode first, so a mistake costs nothing
Before a single real dollar is involved, do all of this in Stripe's test mode. This is the single best safety habit for a non-technical builder, because it turns "what if I mess up" from a scary question into a free experiment.
Test mode gives you a separate set of keys (clearly marked as test keys) and a separate world where no real money moves. You use special test card numbers instead of a real card. Payments "succeed" or "fail" on demand so you can see how your app behaves, but nothing hits an actual bank.
Here is the workflow:
- Switch your Stripe dashboard to test mode and copy the test publishable and secret keys. These are the only keys that should exist anywhere in your project right now.
- Wire up your payment flow using only these test keys.
- Use Stripe's official test card numbers to run through a purchase. Verify the exact test values in Stripe's own documentation rather than trusting any number an AI hands you. AI tools sometimes state card numbers or amounts from memory, and you want the current, official list.
- Try the unhappy paths too: a declined card, an incomplete form, a page refresh mid-checkout. You are looking for how your app reacts when things go wrong, not just when they go right.
Staying in test mode until everything works removes the fear entirely. A misplaced key here can leak nothing valuable, because a test key cannot touch real money. You get to make every beginner mistake safely, which is the whole point.
Directing the AI to add Stripe without pasting your secret key
Now the part where the AI helps you write the integration. The rule is simple and non-negotiable: you never paste your secret key into the chat. Not the test one out of habit, and definitely not the live one. The AI does not need the actual key to write correct code. It only needs to know that a key will be supplied through a secure slot.
This fits the broader pattern from the direct-review-extend loop: you direct the work with clear instructions, review what comes back, then extend. Directing well here means telling the AI how to handle the secret without ever revealing it.
Instead of pasting the key, ask the AI to read it from an environment variable or your platform's secret manager. Most no-code and app-building platforms have a dedicated "secrets" or "environment variables" panel for exactly this. You put the key there, in the protected slot, and your code refers to it by name. The key value stays out of your source code, out of the chat, and out of anything shipped to the browser.
Useful ways to phrase your request to the AI:
- "Add a Stripe payment flow. Read the secret key from an environment variable named
STRIPE_SECRET_KEY. Do not hardcode any key value. I will set the value myself in the platform's secrets settings." - "Put all Stripe calls that use the secret key in server-side code only. The frontend should use the publishable key and Stripe's client components, nothing more."
- "Do not print, log, or echo the secret key anywhere, including debug output."
If the AI ever responds by asking you to paste your secret key so it can "test" or "configure" it, decline. There is no legitimate reason it needs the real value. You supply the value once, yourself, directly into the secure slot your platform provides.
Verify keys are server-side only before you accept the change
The AI wrote some code. Do not merge or publish it on trust. This is the review step, and for payments it matters more than anywhere else. You are checking one thing above all: is the secret key confined to the server?
You do not need to be an engineer to run these checks. You need to be a careful reader.
- Search the code for your key. Look for the actual key value and for the words "secret" and the key prefix Stripe uses for secret keys. If the literal key value appears anywhere in the code, that is a hardcoded key and it needs to move into the environment variable or secret manager. It should never appear as text in a file.
- Confirm the frontend only uses the publishable key. Any file that runs in the browser (the visible pages, client-side scripts) should reference the publishable key or Stripe's client component, never the secret key or its variable.
- Check that secret-key work lives in server code. Charges, refunds, and customer lookups should happen in backend or server-side functions. If you cannot tell which files are server-side, that itself is a signal to slow down and ask.
- Look at what ships to the browser. After the change, open your running app, view the page source, and glance at the network requests during checkout. You are confirming the secret key does not show up. The publishable key showing up is expected and fine.
- Ask the AI to explain, then verify independently. You can ask "which files here run in the browser, and does any of them reference the secret key?" Use the answer as a guide, but confirm with your own search rather than taking it as final.
If any check fails, do not go live. Have the AI move the key into a secure variable and run the checks again. A single clean review here prevents the most common and most damaging leak.
The go-live checklist, and the hard stop before it
Everything works in test mode, keys are placed correctly, and you are ready to accept real payments. Before you flip to live mode, walk this list. Then read the hard stop, because it is the most important paragraph in this post.
Go-live checklist:
- Test mode is fully working, including declined-card and error behavior.
- The live secret key is stored only in an environment variable or secret manager, never in code, never in the chat, never in a config file that ships to the browser.
- The frontend uses only the publishable key.
- Your code repository has no keys committed to it. If a key was ever committed, even briefly, rotate it in the Stripe dashboard so the exposed one stops working.
- If your integration uses webhooks (Stripe notifying your app about events), keep signature verification on. Do not let the AI disable it to "make it work." That check exists to confirm the message genuinely came from Stripe.
- You have a plan to rotate keys and know where the "roll key" button is, in case a key is ever exposed.
The hard stop: when to get professional review
Here is the line. Before you accept real payments, get your payment setup reviewed by a qualified professional if any of the following is true, and honestly, a review is worth it even if none of them is:
- You store, or your code touches, raw card numbers anywhere. This is the biggest red flag. If card data lands in your database, logs, or server, stop and get help before going live.
- You are unsure of your PCI scope, meaning which set of security requirements applies to you. Your scope and the self-assessment questionnaire (SAQ) that goes with it depend on how you integrate, and getting this wrong has consequences. This is not something to guess at.
- You are handling other people's personal data alongside payments and are unsure of your obligations.
- Anything in the verification step above came back unclear and you could not resolve it.
Payments are exactly the situation the guide on when to hire a security professional is written for. A short paid review before your first real charge is cheap compared to the alternative. No checklist, including this one, makes your payment flow "secure" or "PCI compliant." Those are outcomes a qualified professional helps you work toward for your specific setup, not a box you tick.
For the compliance side of this, read the PCI basics in plain English before you go live. It explains what PCI is and why your integration method changes what you are responsible for. This post keeps compliance deliberately shallow so that the other one can go deep. And to be clear one more time: educational, not legal advice. Verify with a qualified professional for your situation.
In Plain English
What this means: Adding Stripe safely comes down to keeping your secret key on the server and out of your frontend, your code, your repo, and any chat window. Build and test everything in Stripe test mode first, verify the AI placed keys correctly, and treat going live as a decision that deserves a real checklist and often a professional's eyes.
Who this helps: Solo founders and non-technical builders who shipped an app with AI or no-code tools and now want to charge money, without accidentally exposing keys or wandering into compliance they do not understand.
When to use it: The moment you decide to add payments, and again right before you switch from test mode to live mode. The verification step and the hard stop are meant to be re-read at go-live, not just once.
What to do next: Do the whole build in test mode. Direct the AI to read keys from a secret manager and never paste your secret key into the chat. Run the server-side-only verification. Then, before live mode, run the security self-audit and get payments reviewed if you touch card data or are unsure of your PCI scope.
A few quick questions
Is it safe that my publishable key is visible in my page's source? Yes. The publishable key is designed to be public and to sit in the browser. The secret key is the one that must never appear there.
The AI asked me to paste my secret key to configure Stripe. Should I? No. The AI never needs the actual key value. Supply it yourself through your platform's environment-variable or secret-manager settings, and have the code reference it by name.
I accidentally committed a key to my repository. What now? Rotate it. Go to your Stripe dashboard and roll the key so the exposed one stops working, then update the value in your secret manager. Assume any key that was ever exposed is compromised.
Does using Stripe mean I am PCI compliant? No. Using Stripe can reduce your compliance scope depending on how you integrate, but compliance is your responsibility and depends on your setup. Read the PCI basics and get professional review before going live.
You have a safe path now: test mode first, secret key on the server, verify before you accept. Before you flip to live mode, run the Security self-audit in the toolkit, read the PCI basics in plain English, and, if you touch card data or are unsure of your scope, get a professional review. When you are ready to keep building on solid ground, the Extend safely hub picks up from here.
Some tool links on this site may be affiliate links, disclosed on our disclosure and policies page.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.