Payments

Status: contracted_test. Payment Intents are in the generated API Reference; only sk_test_* mode is promised.

A Payment Intent is the core object for taking a payment directly through the API (as opposed to hosted Checkout). It tracks a single payment from creation through authorization, capture, and any refunds.

Lifecycle

created → requires_confirmation → requires_action (3DS) → processing → succeeded
                                                                     ↘ canceled

A succeeded intent exposes its money movement as a read-only Charge via latest_charge. Refunds are issued against the payment. Internal event projections exist, but merchant-public Events and WebhookEndpoints are unavailable; do not depend on a charge.refunded delivery.

Hidden from the public API

Each item below is hidden because it does not follow the Stripe parity ADR (ADR 0004 as amended). The hidden public /v1 registry lists every hidden item. Public /v1 answers a hidden operation as an unknown URL, refuses a hidden request parameter or value with Stripe’s invalid_request_error, and omits a hidden response key.

• the request parameter payment_method_data[card] of POST /v1/payment_intents/{intent}/confirm (HIDE0-002)
• the value card of payment_method_data[type] on POST /v1/payment_intents/{intent}/confirm (HIDE0-003)
• the request parameter payment_method_data[card] of POST /v1/payment_intents (HIDE0-019)
• the value card of payment_method_data[type] on POST /v1/payment_intents (HIDE0-020)

Where to go next

• Quickstart — create → confirm → capture in a few calls.
• Authorize now, capture later — split auth and capture.
• Handle payment authentication — 3-D Secure and the requires_action step.
• Charges — the read-only projection of a succeeded payment.

The full field-level request/response shape is in the API Reference.