Stripe integration for web and mobile products

Stripe suits products that need to take payments inside their own software:

• You need subscriptions with trials, per-seat or usage-based pricing, invoices and retries. Stripe Billing covers these.
• You run a marketplace or platform that pays sellers. Stripe Connect splits payments, onboards the sellers and sends payouts.
• You want cards and local payment methods through one integration. Stripe lists the methods it supports; check that list for your countries.
• You want card details kept off your own servers. With Checkout or the Payment Element, Stripe.js sends them straight to Stripe.

Stripe is not the answer to every payment need:

• Your business is in a country Stripe does not support. Stripe publishes its list of supported countries, and some are in preview or served through a partner.
• Your business type is prohibited or restricted. Stripe publishes a restricted-businesses list and some categories need extra review.
• You must take raw card numbers on your own pages. That widens your card-security obligations a great deal, so use Checkout or Elements, or another provider.
• Your payment methods or markets are not on Stripe's list. Check the payment methods overview before committing to a design.

Stripe's documentation lists the building blocks. Checkout is a prebuilt payment page, hosted by Stripe or embedded in yours, for one-time and subscription payments. Elements and the Payment Element are prebuilt components for your own page; Stripe.js tokenises the card details so they do not pass through your server. Stripe recommends Checkout Sessions with the Payment Element for most integrations. Payment Intents suit flows you build yourself, where tax, discounts and shipping are yours to handle.

Around those sit Billing for subscriptions and invoices, Connect for marketplaces, Radar for fraud rules, Tax for calculating sales tax and VAT, and a Refunds API for full and partial refunds to the original payment method.

The checkout page is the easy part. The work that protects you is behind it:

• Webhooks: verify the signature on every event using the raw request body and the secret for that endpoint, answer quickly, and do the real work from a queue. Events can arrive twice or out of order, so we deduplicate on the event ID and re-read the object from the API.
• Idempotency: send an idempotency key on create requests, so a retried request does not charge twice.
• Test and live modes: test keys cannot process live payments. We run every path, including failures, in test mode, then switch keys at launch and keep keys out of source control.
• Strong customer authentication: cards used in or from the European Economic Area may need 3D Secure. Checkout, Billing and Payment Intents handle it; payments taken later without the customer present need extra care.
• Card-security scope: card data stays with Stripe when you use Checkout or Elements, which keeps most card-handling requirements off your servers. You still have your own compliance steps, and the Stripe Dashboard shows which apply.

1. Scope the money flow first: who pays whom, when, in which currencies and countries, and what happens on a refund or a failure
2. Build and test in test mode: every path, including failed and disputed payments, runs against Stripe's test environment before live keys are used
3. Make webhooks safe: signed, verified, deduplicated and processed from a queue, so a repeated event does no harm
4. Hand over properly: the code in your repository, the configuration documented, and notes on how to find and fix a stuck payment

Technology facts on this page are taken from the official documentation:

• Stripe documentation: payments overview
• Stripe documentation: Checkout
• Stripe documentation: Elements and the Payment Element
• Stripe documentation: Billing
• Stripe documentation: Connect
• Stripe documentation: webhooks, signatures and retries
• Stripe API reference: idempotent requests
• Stripe documentation: strong customer authentication
• Stripe: supported countries