Stripe Integration for Websites and Online Stores

Stripe is a common way to take cards, wallets, and subscriptions on a business website. Integration is a software project: Checkout or embedded payment fields, a customer and subscription model if you bill repeatedly, and webhooks that tell your server what actually happened. Opening a Stripe account is a separate underwriting project. Building the code does not approve the account, and forming a company does not force Stripe to accept you.

Scriplit is not a law firm or a CPA firm, and we are not Stripe. This article is general technical information. Account approval, payouts, reserves, and restricted-business decisions belong to Stripe. A US LLC, an EIN, or a finished website does not guarantee banking, Stripe, visas, or tax outcomes. Confirm current Stripe and tax rules for your situation.

What you are integrating

For most sites, three pieces cover the work:

• Checkout (hosted page or embedded Payment Element) to collect a payment method without putting raw PAN on your server.
• Subscriptions via Stripe Billing if the customer pays on a schedule.
• Webhooks so your database updates when a payment succeeds, fails, is refunded, or a invoice is paid — even if the customer closes the tab.

You can charge a one-off PaymentIntent without Billing. You should not invent your own recurring engine on top of stored tokens unless you have a reason Stripe Billing cannot cover. Recurring logic is where silent failures hide: expired cards, timezone-odd billing dates, and “we thought it renewed.”

Account and business identity

Stripe asks for the legal entity, beneficial owners, a bank account for payouts, and a site that matches what you sell. Non-resident founders often form a US LLC and obtain an EIN as part of presenting a coherent US business. That path is described in how to form a US LLC as a non-resident. It is a filing process, not a payment-processor guarantee.

Name matching matters. The Stripe account, the bank account, the website footer, and the charge descriptor should tell the same story. A personal bank account, a trade name that appears nowhere in formation documents, or a site that still sells a different product than the application, produces reviews.

Scriplit can implement payment gateway integration once you have (or are applying for) an account. We cannot promise approval, faster underwriting, or that a given country or product category will be allowed.

Checkout: hosted vs embedded

Stripe Checkout is a hosted payment page. You create a Checkout Session on the server, send the customer to Stripe (or use the embedded Checkout), and fulfill when you get a verified event that the session was paid. It is the fastest way to get 3-D Secure, wallets, and tax-ready line items without designing a card form.

The Payment Element (or similar embedded UI) keeps the customer on your domain. You still create a PaymentIntent or SetupIntent on the server. You still never log the card number. Embedded checkout is worth it when you need tight control of layout, multi-step wizards, or a logged-in account area. It is more work: you own more of the error states and the mobile keyboard behavior.

Either way, compute prices on the server. Do not trust a client-posted amount. If the browser can change the total, someone will.

Subscriptions

A subscription in Stripe is a Customer, a Product/Price, and a Subscription object that generates Invoices. Your app should store the Stripe customer ID and subscription ID, not a homemade “next charge date” as the source of truth.

Plan for:

• A customer portal or a support path to update the card.
• Webhook handling for invoice.paid, invoice.payment_failed, and subscription cancellation or pause events you actually use.
• What the product does when payment fails: grace period, read-only mode, or hard cut-off. Put that in the UI, not only in a policy PDF.
• Proration rules if people upgrade mid-cycle — decide them before the first paid user asks.

Trial periods and coupons are easy to mis-model. Test the first invoice, the first renewal, a failed renewal, and a cancel-at-period-end flow in test mode before you take a live subscriber.

Webhooks are not optional

The success URL after Checkout is a convenience for the human. The webhook is how your server learns the truth. Customers lose connectivity. Browser extensions block redirects. A second tab retries. If you mark an order paid only because the customer landed on /thanks, you will both miss real payments and fulfill unpaid ones.

Practical rules:

• Expose an HTTPS endpoint that reads the raw body and verifies the Stripe signature header with your endpoint secret.
• Handle events idempotently. Stripe can retry. Processing checkout.session.completed twice must not double-ship.
• Retrieve the object from the API if you need fields you do not trust from the payload alone for fulfillment decisions.
• Return 2xx quickly; do slow work (emails, warehouse) in a queue after you have stored the event ID.

In local development, use the Stripe CLI or a tunnel. Do not disable signature verification “just for now” on a server that can be reached from the internet.

Go-live checklist

1. Replace test keys with live keys only in the production environment; never commit live secrets.
2. Register the live webhook endpoint and confirm the events you handle.
3. Place a small live charge and a refund. Watch payout timing; do not promise customers an instant bank deposit.
4. Confirm receipts, tax IDs on invoices if you collect them, and the statement descriptor.
5. Document who in your team can log into the Stripe Dashboard and that 2FA is on.

Fees, Radar rules, and connected-account (Connect) setups are extra products. Do not turn them on because a tutorial mentioned them. Connect is for platforms that pay others; a single shop usually does not need it.

When integration is the wrong first step

If you do not yet have a legal entity, a payout account, or a site that describes a real offer, the API work will sit idle. If you only need invoices for a handful of clients, a Stripe Payment Link or invoice might be enough until volume justifies a custom PHP checkout.

When you are ready to wire Checkout, Billing, and webhooks into a site Scriplit maintains, send a brief via payment integration. Include whether you need one-off payments, subscriptions, or both, and which entity will hold the Stripe account. We will integrate against that reality, including the possibility that Stripe is still reviewing the business.