Choose the smallest integration surface that gives your business the control it needs. Start with Checkout Sessions for a complete payment page, then use Payment Intents when your application owns confirmation or capture state.

Compare integration modes

Use Accept a payment for the standard one-time flow. Use Payment intents when you need to separate authorization, confirmation, and capture.

Shared server-to-browser sequence

Every browser integration follows the same boundary:
  1. Resolve the customer, cart, amount, currency, and order on your server
  2. Create one resource with an idempotency key
  3. Return only the resource ID and short-lived client token to browser code
  4. Let the secure component collect payment details and handle customer action
  5. Keep the order pending until a verified event or authoritative retrieval confirms it
  6. Fulfill once, then reconcile refunds, disputes, and delayed events by resource ID
The server owns the API key and authoritative amount. The browser receives only the result needed to render checkout. See Authentication and Fulfill orders safely before connecting production orders.

Choose by control requirement

Hosted checkout reduces UI work and isolates sensitive fields. In-page checkout gives you control over the surrounding layout without moving sensitive data into your application. Payment Intents give you the most lifecycle control, but require explicit handling for action, processing, capture, cancellation, and recovery states. Do not select a lower-level flow only to recreate a higher-level checkout page. Keep method discovery dynamic, register webhooks for every payment flow, and use the flow’s documented test cases before launch.