Accept One-Time Payments on Any Website With Stripe

Is This the Right Fit?

Before adding Stripe, decide exactly what the customer is paying for. This Guide is designed for simple one-time payments.

Good examples include a consultation, a booking deposit, a service deposit, a fixed-price service, a digital product, an event ticket, a simple product, or a one-time fee.

IMPORTANT

If your website needs recurring monthly or yearly billing, use a Stripe Subscriptions workflow instead. Likewise, if a successful payment must automatically unlock an account, activate paid features, update credits, or change private database records, you may need a more complete server-side Stripe integration.

Check the Existing Website

Payment Readiness Audit

Identifies the framework, every existing Buy/Pay/Checkout/Deposit/Order/Purchase/Book button, any pricing section, checkout page, Stripe integration, Payment Link, server-side payment code, or payment-related env var names — determines whether a Stripe Payment Link is enough or whether something must happen automatically after payment (unlocking an account, updating a database, delivering content) — changes nothing, exposes no credentials, and recommends a Payment Link, reusing an existing integration, or a more advanced server-side setup.

Review this existing website specifically for adding a secure one-time payment with Stripe. Do not change anything yet. Identify: - the framework and project type - existing Buy, Pay, Checkout, Deposit, Order, Purchase, or Book buttons - existing pricing or product sections - any checkout or payment page - any existing Stripe integration - Stripe libraries or SDKs - existing Stripe Payment Links - server-side payment code - payment-related API routes - payment-related environment variables — names only - success or thank-you pages - cancellation or return pages - any existing order, booking, or payment-confirmation logic Determine whether the requirement can be handled safely with a Stripe Payment Link. A Payment Link is appropriate if the intended flow is essentially: Customer chooses a fixed product/service → clicks Pay → completes a secure Stripe-hosted checkout → receives confirmation Also determine whether anything must happen automatically after payment, such as: - unlocking an account - granting access to a paid feature - updating a private order or booking database - delivering protected content - adding credits - changing a user's subscription or account status If any of those requirements make a simple Payment Link insufficient, explain why before implementing anything. Do not expose Stripe secret keys or other private credentials. Do not change anything. Finish with: **Recommended payment setup:** 1. Stripe Payment Link 2. Existing Stripe integration should be reused 3. A more advanced server-side Stripe integration is required Then briefly explain why.

Create the Product or Service

Open your Stripe Dashboard. Create or select the product or service the customer will pay for.

Stripe Dashboard

Create or select the product/service to charge for.

https://dashboard.stripe.com

Example

Website Consultation — $99

or:

Example

Booking Deposit — $50

IMPORTANT

Make sure the payment is configured as a one-time price, not recurring.

Create the Payment Link

Create a Stripe Payment Link for that product. Review:

- Product/service name

- Amount

- Currency

- Product image if useful

- Customer email collection

- Billing information if required

- Payment methods

- Confirmation behavior

Stripe Docs

How to create a payment link.

https://docs.stripe.com/payment-links/create

NOTE

Only collect information you actually need. For a simple service payment, the Stripe checkout may only need the customer's payment details and email.

Decide What Happens After Payment

Choose a simple post-payment experience.

For example: Payment → Stripe confirmation → customer returns to a Thank You page.

Example

/thank-you

If the website already has an appropriate page like that, you can use it. Otherwise, the Stripe-hosted confirmation may be enough for a very simple setup.

Keep Private Stripe Credentials Out of the Website

For this workflow, the website generally only needs the public Stripe Payment Link.

IMPORTANT

The website does not need your Stripe secret key, webhook signing secret, account password, or other private Stripe credentials.

Example

https://buy.stripe.com/...

Copy the correct link and keep it ready for the next step.

Reuse the Existing Button

Now connect the existing website CTA to the Stripe Payment Link. Whenever possible, reuse the button that is already part of the design.

For example: Pay Deposit, Buy Now, Pay Now, Purchase, or Book & Pay.

Connect the Payment Link

Connect the Stripe Payment Link

Connects the existing payment CTA to the provided Stripe Payment Link, preserving the design, matching the displayed price/currency, and working on desktop, mobile, and keyboard — never exposes a secret key, never installs the Stripe SDK or a custom card form, never adds auth/database/webhooks unless genuinely needed, reuses an existing integration if one already works, runs the production build, and reports every file changed plus Payment integration: READY or NOT READY.

Connect this existing website to the following Stripe one-time Payment Link: [YOUR STRIPE PAYMENT LINK] First inspect the current pricing, product, service, booking, and payment-related UI. Preserve the existing design. Requirements: - reuse the existing payment CTA where appropriate - connect only the intended button or buttons - use the exact Stripe Payment Link I provided - make it clear what the customer is paying for - make sure the displayed price and currency match the Stripe checkout - make the payment CTA work on desktop and mobile - preserve keyboard accessibility - remove or replace broken placeholder checkout links only where relevant Do not: - expose a Stripe secret key in frontend code - install the Stripe SDK if a normal Payment Link already solves the requirement - build a custom credit-card form - collect card details directly on this website - create unnecessary API routes - add authentication - add a database - add webhooks unless the project genuinely needs automatic post-payment processing - redesign unrelated sections If this project already contains a working Stripe payment integration, reuse it rather than creating a duplicate implementation. Run the production build after making the change. Then report: - every file changed - every payment CTA connected - the final amount/currency shown by the website - whether any old payment integration remains Finish with: **Payment integration: READY / NOT READY**

Check the Customer Journey

The website and Stripe checkout should tell the customer the same thing. For example, a website that says "Website Consultation — $99" should not open a Stripe checkout showing "General Service — $149". Make sure the:

Product/service matches

Price matches

Currency matches

Payment purpose is clear

Test the Checkout

Do not consider the payment setup complete simply because the Stripe page opens. Test the complete flow before sending real customers through it. Use Stripe's test environment while configuring the payment flow whenever appropriate. Start from the website itself.

Open the relevant product, service, or pricing section. Click the payment button. Confirm the correct Stripe checkout opens. Confirm the product/service name. Confirm the amount. Confirm the currency. Complete a test payment. Verify the successful payment appears correctly in Stripe. Check the confirmation experience. Confirm any return or Thank You page works correctly.

Check What Happens After Payment

For many small businesses, this simple flow is enough: customer pays → Stripe confirms payment → business receives the payment → business handles the next step manually. For example, a consultation payment means you manually schedule the customer, and a deposit means the business confirms the booking.

NOTE

You do not need to build automation merely because Stripe supports it. However, if your website promises something automatically after payment, verify that a Payment Link alone can actually provide it.

Run the Final Production-Readiness Audit

One-Time Payment Production Audit

Verifies every payment CTA points to the correct Payment Link, no broken/placeholder URLs, the displayed product, amount and currency match Stripe, the checkout is one-time (not an accidental subscription), desktop/mobile/confirmation all work, no exposed secret keys or unnecessary SDK/API routes/backend, no leftover duplicate integration, and the production build succeeds — also flags when automatic fulfillment needs more than a Payment Link, never weakens security, never deploys, and answers Payment status: READY or NOT READY.

Run a final production-readiness audit for this one-time Stripe payment integration. Verify: - every intended payment CTA points to the correct Stripe Payment Link - there are no broken or placeholder payment URLs - the website displays the correct product/service - the displayed amount matches Stripe - the displayed currency matches Stripe - the Stripe checkout represents a one-time payment rather than an unintended recurring subscription - payment buttons work on desktop - payment buttons work on mobile - the confirmation or Thank You experience works - no Stripe secret keys or private credentials are exposed in frontend code - no unnecessary Stripe SDK, API route, custom checkout, or payment backend was added - no old duplicate payment integration remains where it could confuse customers - the production build succeeds - there are no important browser/runtime errors Also determine whether anything must happen automatically after a successful payment. If automatic fulfillment, access control, database updates, account activation, credits, subscriptions, or another trusted server-side action is required, clearly explain that a simple Payment Link is not enough and identify what additional integration would be needed. Do not weaken payment security. Do not deploy anything automatically. Finish with: **Payment status: READY / NOT READY** If NOT READY, list only what must be fixed before accepting real payments.

Switch to Real Payments

Once testing is complete, make sure the website uses the intended live Stripe Payment Link rather than a test payment link. Then check the flow one more time from the live website: Website → Pay → Stripe Checkout → Confirmation. If appropriate, complete a small real payment yourself and verify:

The correct amount was charged

Stripe recorded the payment

The customer confirmation works

The business receives the information needed to fulfill the purchase

Accepting Real Payments

Your website can now accept secure one-time payments without requiring a custom checkout backend.

Use a More Advanced Stripe Integration If You Need

- Monthly or yearly subscriptions

- Free vs Pro accounts

- Automatic feature unlocking

- User-specific purchases

- Automatic order fulfillment

- Credits or usage balances

- Subscription upgrades or cancellations

- A customer billing portal

- Trusted database updates after payment

- Complex checkout logic

IMPORTANT

For those cases, payment must be verified securely on the server rather than treating a browser redirect as proof that someone paid.