How to Add Stripe Payments to Your App on Creatr

By the end of this tutorial you will have a working checkout in your app that takes a real payment through Stripe - without touching the Stripe API, reading SDK docs, or copying secret keys into code. We will build it in Stripe test mode first, verify that the post-payment logic runs correctly, then walk through going live with real keys. The whole pattern - checkout session, success webhook, confirmation email, and edge cases - is handled through plain-English prompts.

Difficulty: Beginner. No code required.

Before you start

You need a Creatr account and a Stripe account. Stripe's test mode is on by default when you sign up - you do not need to activate your account or connect a bank to follow along. Keep your Stripe dashboard open in another tab so you can confirm events as you build.

If you want to send confirmation emails after payment, have your email domain or a transactional email provider available. See Send automated transactional emails for the full walkthrough on that side.

Step 1 - Describe the checkout you want

Start a new build on Creatr, or open an existing app. Tell Creatr what you want to charge for. Be specific: name the product, the price, the billing cadence (one-time or recurring), and what should happen once the payment goes through.

Add a checkout to my app that lets a customer buy a single "Pro plan" for $20 per month using Stripe. After a successful payment, mark their account as Pro and show them a confirmation screen.

That sentence contains the four decisions that drive the entire integration: the product name, the price, the cadence, and the post-payment action. The more specific you are here, the less back-and-forth you will need later.

If you are building an e-commerce flow rather than a subscription, the prompt looks different but the logic is the same.

Add a checkout that charges a customer $49 one-time for the "Starter Kit" product. After payment, grant them access to the download page.

For a broader store setup, see Build an online store without Shopify.

Step 2 - Connect Stripe

Creatr will prompt you to authorize your Stripe account. Click the connect button and complete the OAuth flow in the Stripe window that opens.

A few things happen in the background during this step. Creatr stores your Stripe credentials on the server side only - they are never written into your app's front-end code or exposed in the browser. The authorization scopes are scoped to what the integration needs: creating checkout sessions, reading payment events, and issuing refunds. You keep full ownership of your Stripe account.

If you already have a Stripe account connected from a previous project, Creatr can reuse it. You will be asked to confirm before any credentials are shared across builds.

Step 3 - Let Creatr wire the payment flow

Once Stripe is connected, Creatr builds the integration. What that actually means under the hood, in plain terms:

A checkout session is created on your server the moment a customer clicks "Buy." It tells Stripe the price, the product name, and where to send the customer after success or failure. Stripe then handles the payment page - card entry, 3D Secure authentication, Apple Pay, Google Pay - all on Stripe's own infrastructure, which is PCI compliant by default. Your app never touches raw card numbers.

A redirect back to your app happens after the customer pays. Stripe appends a session ID to the URL so your app can look up what was purchased and by whom.

A success webhook is the part people skip and later regret. When a customer pays, Stripe fires an event to a server endpoint in your app. That endpoint is where the real post-payment logic runs - upgrading the account, unlocking content, recording the transaction in your database. The webhook matters because the browser redirect alone is not reliable: customers close tabs, navigate away, or lose their connection before the redirect completes. The webhook fires server-to-server and does not depend on the browser staying open. Creatr wires this endpoint for you and signs the requests with a webhook secret so you know the event came from Stripe and not from someone guessing the URL.

You do not need to prompt Creatr separately for any of this - it sets up all three when you describe the checkout in Step 1.

Step 4 - Test the payment

Open your app and run the checkout. When the Stripe-hosted payment page appears, use Stripe's standard test card:

Card number 4242 4242 4242 4242 - any future expiry date - any three-digit CVC - any postal code.

Complete the payment. You should be redirected back into your app and the post-payment action you specified in Step 1 should have run - account marked Pro, access granted, or whatever you asked for. Then open your Stripe dashboard and look under Payments - the test transaction appears there with a status of "Succeeded."

Testing a failed card is worth doing before you go anywhere near real users. Stripe provides a test card that always declines:

Card number 4000 0000 0000 0002 for a generic decline.

Try it. Your app should handle the decline without breaking the customer's session. If it does not, describe the behavior you want:

If the payment is declined, show an error message that says "Your card was declined. Please try a different payment method." and keep the customer on the checkout page.

Creatr will adjust the error handling accordingly.

Step 5 - Verify what happens after payment

The point of a payment is the thing that happens next. Go check it. If you asked for an account upgrade, log in and confirm the account shows Pro status. If you asked for download access, verify the link is there. If you asked for a database record, look at the records.

If anything is missing or wrong, describe the gap:

The account is marked Pro but the billing date is not recorded. After a successful payment, also save the subscription start date to the user profile.

One of the most common gaps is that the app correctly handles a single payment but does not handle a subscription renewal correctly. For recurring billing, the webhook you care about is not just the first payment - it is every subsequent charge. Tell Creatr this explicitly:

When a monthly subscription renews, keep the user's Pro status active and update the renewal date on their profile.

Idempotency is worth mentioning here. Stripe can send the same webhook event more than once - it retries on network errors. A well-wired integration handles a duplicate event without creating duplicate records or charging logic. Creatr handles this by default, but if you add custom logic on top of the webhook, describe it in a way that makes the intent clear: "only once per payment, not per webhook delivery."

Step 6 - Add a receipt and confirmation email

A checkout without a confirmation email feels incomplete to customers and creates unnecessary support tickets. Tell Creatr to send one:

When the payment succeeds, send the customer an email confirming their purchase. Include the plan name, the amount charged, and a link to their account settings.

Stripe has its own built-in receipt emails, which you can enable from the Stripe dashboard under Settings - Emails. Those cover the bare minimum. If you want something branded or want to include specific content - an invoice attachment, onboarding instructions, a link to a getting-started guide - build it through the transactional email step and turn Stripe's default receipts off to avoid duplication. See Send automated transactional emails for the full setup.

For the receipt, the information you have available after a successful payment includes the customer's email address, the product or plan name, the amount charged, the currency, the payment date, and the Stripe payment ID. All of that can go into the email body without any extra API calls.

Step 7 - Handle refunds

Refunds are part of any payment flow. You can issue them from the Stripe dashboard manually, but if your app needs to trigger refunds programmatically - for example, when a user cancels a subscription - describe it:

Add a cancel subscription button to the account settings page. When a user cancels, immediately stop billing and refund the current month's payment.

A few things to specify when refunds are involved: whether the refund is full or partial, whether you want to notify the customer by email, and what happens to their access after the refund (immediate cutoff, or access through the end of the paid period). Stripe's refund object carries back the refunded amount and the reason, so Creatr can use that to update account status.

If you only want to cancel going forward without refunding the current period:

When a user cancels, cancel the Stripe subscription at the end of the current billing period. Keep their Pro access until that date, then revert them to the free plan.

Step 8 - Go live with real keys

When you are confident the flow works - you have tested a successful payment, a declined card, and the post-payment logic - it is time to switch from test mode to live mode.

In your Stripe dashboard, toggle out of test mode. Then return to Creatr and re-authorize your Stripe connection. The live-mode OAuth flow is the same as the test-mode one. Creatr will replace the test credentials with live credentials and update the webhook endpoint to point at Stripe's live event stream.

A few things to check before you flip the switch:

Your Stripe account needs to be fully activated - business details, bank account, and identity verification completed. Stripe will not process live payments without this. If your account is not activated yet, the dashboard will show a banner with the remaining steps.

Your webhook signing secret changes between test mode and live mode. Creatr handles the rotation automatically when you re-authorize, but if you have added any custom logic outside of Creatr that depends on webhook verification, update the secret there too.

Test one more transaction with a real card after going live - a small amount, on an account you control. Confirm the payment appears in Stripe's live dashboard, the webhook fires, and the post-payment logic runs. Then refund it from the Stripe dashboard.

Recap

You described a checkout, connected Stripe, and shipped a working payment flow with the webhook wired in, a confirmation email, declined-card handling, and a clear path to go live. The webhook is what separates a demo from a production billing system - it is the server-side confirmation that a payment actually settled, independent of what the browser does. The same pattern extends to subscriptions, metered billing, and refund flows - each one is a plain-English prompt away.

Related: Build an online store without Shopify - Send automated transactional emails - Stripe integration details.