SysPad › Lessons › payments lessons › Stripe
How Stripe works
Stripe payments API - a synchronous third-party dependency on the request path. Adds external API latency and is subject to API rate limits.
Taking card payments yourself means storing card numbers, and inheriting brutal PCI compliance. Stripe’s core trick is to make sure the card never touches your server: the browser sends it straight to Stripe, which hands you back a safe token. From there it’s an API you call and a set of webhooks it calls back, the architecture of nearly every modern payment flow.
What you will learn
- How does tokenisation keep card data off your servers (and shrink PCI scope)?
- What is a PaymentIntent, and why isn’t a payment always instant?
- Why are webhooks essential, and what must your endpoint handle?
- What do idempotency keys protect against?
The card never touches your server
With Stripe’s client libraries (Stripe.js / Elements), the customer’s card details go directly to Stripe from the browser. Stripe returns a token (a PaymentMethod id), and your server works only with that handle.
Because raw card data never reaches your systems, your PCI compliance burden shrinks dramatically, that’s the single biggest reason teams use Stripe.
PaymentIntents: payments take time
A payment isn’t one instant yes/no. A PaymentIntent models the whole lifecycle, requires confirmation, processing, possibly extra authentication (3D Secure), then succeeded or failed. Your server creates it for the amount; Stripe drives it forward.
Some payment methods settle asynchronously (bank debits, vouchers), so the final result can arrive seconds, or days, later.
Webhooks: how Stripe calls you back
Because outcomes can be asynchronous, you can’t just read the HTTP response. Stripe sends webhook events (e.g. payment_intent.succeeded) to an endpoint you expose. That event is the source of truth for fulfilling the order.
⚓ The backbone of e-commerce, SaaS billing, marketplaces, and subscriptions.
Idempotency keys
Networks fail mid-request, so clients retry, which risks charging a customer twice. An idempotency key attached to a request tells Stripe "if you’ve seen this key, return the original result." A retried create-charge with the same key won’t double-charge.
Flashcards
- How does Stripe shrink your PCI compliance burden?
- Card data goes directly to Stripe (tokenisation); your server only handles a token, so raw card numbers never enter your systems.
- What is a PaymentIntent, and why does it exist?
- An object modeling a payment’s full lifecycle (confirm → authenticate → succeed/fail), because payments aren’t always instant or synchronous.
- Why can’t you rely solely on the API response to confirm a payment?
- Outcomes can be asynchronous; Stripe sends a webhook event (the source of truth) when the payment’s final state is known.
- Two things your Stripe webhook endpoint must do?
- Verify the signature (reject forged events) and be idempotent (events can arrive more than once).
- What does an idempotency key protect against?
- A retried request double-charging, Stripe returns the original result for a repeated key.