Stripe's domain centers on money moving objects (customers, payment methods, PaymentIntents, charges, refunds, invoices, subscriptions) plus a large set of adjunct domains (products/prices, Connect accounts and external accounts, payouts/transfers, issuing/terminal, treasury, tax). Most real user requests involve a small subset: create a charge or PaymentIntent, attach a payment method to a customer, refund, invoice, and manage subscriptions. Understand how those resources relate and which IDs you must fetch first; where possible, prefer the PaymentIntent path for modern payment flows.

How the API models money and customers (high-level)

• Customer is the canonical buyer record. Many flows start from or attach to a customer id. Customers hold saved payment sources and PaymentMethods and own subscriptions and invoices.
• PaymentMethod and legacy payment sources (cards, bank accounts, sources) represent payment credentials. PaymentMethods can be attached to a customer or used directly with a PaymentIntent/SetupIntent.
• PaymentIntent is the central object for processing payments in current Stripe flows: create a PaymentIntent, confirm it, then (optionally) capture it. Charges still exist (returned on some endpoints) and older integrations use Charge directly; PaymentIntent is preferred for new payments.
• Refunds can be created against a Charge or via Refund endpoints; PaymentIntent and Charge objects will show resulting refunds.
• Subscriptions are built from Prices/Plans and create Invoices. Invoices are finalized and paid; you can preview, pay, finalize, and send invoices.
• Products and Prices are the catalog: subscriptions reference price ids; checkout sessions and payment links reference prices or products.
• Connect accounts (Accounts) are separate Stripe accounts you manage; many account-scoped endpoints require an account id and expose external accounts, persons, and capabilities.

Entry points — what to call first

Start from the resource the user mentions. Common entry calls to discover IDs you will need next:

• If the user names a customer or asks “work with my customer,” call GetCustomers or GetCustomersCustomer to obtain the customer id and inspect attached payment methods (use GetCustomersCustomerPaymentMethods and GetCustomersCustomerSources).
• If the user is asking to take a payment, create or inspect a PaymentIntent: PostPaymentIntents to create; GetPaymentIntentsIntent to retrieve. You will often need the payment_intent id for confirm/capture/cancel operations.
• For saved payment credentials, list the customer’s payment methods with GetCustomersCustomerPaymentMethods or retrieve a single PaymentMethod with GetPaymentMethodsPaymentMethod.
• For subscriptions and recurring billing, list GetSubscriptions or get a specific subscription with GetSubscriptionsSubscriptionExposedId. Subscription items are available via GetSubscriptionItems and GetSubscriptionItemsItem.
• For checkout pages or one-off links, use GetCheckoutSessions / GetCheckoutSessionsSession or GetPaymentLinks / GetPaymentLinksPaymentLink to inspect active sessions and line items.
• For Connect onboarding or account-level tasks, use GetAccounts / GetAccountsAccount and create an account link with PostAccountLinks for onboarding.

These list/get entry points return the IDs you will pass to subsequent calls (e.g., customer, payment_intent, charge, invoice, subscription_exposed_id, price, product, account).

Common tasks and the sequence of calls (quick recipes)

Create a modern card payment (recommended flow)

• Create a PaymentIntent: PostPaymentIntents (include customer if saving or associating).
• Confirm the PaymentIntent (if client-side confirmation is not used): PostPaymentIntentsIntentConfirm.
• If using manual capture, capture it with PostPaymentIntentsIntentCapture.
• To inspect the result, call GetPaymentIntentsIntent or list charges via GetCharges filtered by payment_intent.

Attach a PaymentMethod to a customer

• Create or fetch the PaymentMethod (PostPaymentMethods or GetPaymentMethods/GetCustomersCustomerPaymentMethods).
• Attach with PostPaymentMethodsPaymentMethodAttach (path parameter payment_method) and then list customer payment methods if needed.

Refund a payment

• Refund a Charge with PostChargesChargeRefunds (path charge) or create a Refund using PostRefunds (body can reference charge or payment_intent).
• Inspect refunds with GetRefunds or GetRefundsRefund.

Create a subscription for a customer

• Ensure a customer exists (PostCustomers / GetCustomers).
• Create the subscription with PostSubscriptions or PostCustomersCustomerSubscriptions (pass customer and items referencing price ids).
• Manage or cancel: retrieve with GetSubscriptionsSubscriptionExposedId and cancel with DeleteSubscriptionsSubscriptionExposedId or update with PostSubscriptionsSubscriptionExposedId.

Checkout / hosted payment

• Create a Checkout session with PostCheckoutSessions (or create a Payment Link with PostPaymentLinks).
• Inspect session with GetCheckoutSessionsSession and its line items with GetCheckoutSessionsSessionLineItems.

Invoice lifecycle (invoicing from subscriptions or one-off invoices)

• Create invoice items with PostInvoiceitems or create invoices with PostInvoices.
• Preview with PostInvoicesCreatePreview if needed.
• Finalize with PostInvoicesInvoiceFinalize then PostInvoicesInvoicePay to pay, or PostInvoicesInvoiceSend to email.

Manage Connect accounts

• List connected accounts with GetAccounts and inspect a specific account with GetAccountsAccount.
• Create onboarding links with PostAccountLinks.
• Manage external bank accounts/retrievals with GetAccountsAccountExternalAccounts, PostAccountsAccountExternalAccounts, and delete via DeleteAccountsAccountExternalAccountsId.

Payouts and transfers

• Inspect GetPayouts / GetPayoutsPayout for transfers to external accounts.
• Create transfers with PostTransfers, list with GetTransfers, and reverse with PostTransfersIdReversals.

Test helpers and simulation

• Use the test-helper endpoints (prefix PostTestHelpers...) to simulate card shipping, issuing authorizations, inbound/outbound treasury flows, and test clocks. If the user asks to simulate test outcomes, these endpoints exist and return the simulated object state.

Patterns and conventions you will reuse

• Many resources have paired list and get endpoints: call the list endpoint to discover ids, then call the get endpoint to inspect a single resource. Use query filters (e.g., customer, payment_intent, status) to narrow lists.
• Search endpoints (GetChargesSearch, GetCustomersSearch, GetPaymentIntentsSearch, GetPricesSearch, GetProductsSearch, GetSubscriptionsSearch) return a search_result structure with next_page (use page to fetch next results). Use search when you need field-level querying that lists cannot provide.
• Many endpoints accept expand so you can fetch nested objects in the same response (e.g., expand the PaymentIntent’s payment_method or a Checkout Session’s payment_intent). Use expand to avoid extra calls when you need nested data.
• Create/update flows are usually POST operations and deletion uses DELETE. Deletes commonly return a DeletedX object; retrieval endpoints sometimes return either the original resource or a Deleted... variant—inspect the object or response fields to detect deletions.
• For payment flows, note the three-step variants: create → confirm → capture. Some clients confirm on the frontend; you can run confirm server-side with PostPaymentIntentsIntentConfirm if necessary.

IDs and fields you will frequently need

These IDs show up across domains. When the user doesn't supply an ID, fetch it from the appropriate list/get endpoint.

• customer — used for payment methods, invoices, subscriptions, sessions.
• payment_intent / PaymentIntent id — used to confirm, capture, cancel payments.
• charge — older flows and some refund endpoints still target charges.
• refund — refunds are retrievable and updatable.
• invoice — for invoice lines, payments, finalization and sending.
• subscription_exposed_id / subscription — subscription resource id used for update/cancel operations.
• price / product — catalog ids for subscriptions and one-off items.
• account — Connect account id used when operating on connected accounts and external accounts.
• payment_method — saved credentials: attach/detach or use directly with PaymentIntents.

Non-obvious gotchas and quirks

• PaymentIntent vs Charge: modern integrations should use PaymentIntent. Charges still appear (and many endpoints accept or return charge ids), so inspect both if you’re reconciling a payment. Refunds may be attached to a charge even when you created the payment via a PaymentIntent.

• Responses for deleted resources: some retrieval endpoints return either the resource or a Deleted... variant (e.g., Customer | DeletedCustomer, TerminalConfiguration | DeletedTerminalConfiguration). Check the returned object shape rather than assuming deletion will mean a 404.

• client_secret exposure: some retrieval endpoints accept a client_secret query parameter when a publishable key is used to retrieve an object. When a user asks to return client-visible secrets, check whether client_secret is required/returned on that endpoint.

• expand is your friend: many objects embed references (payment method on a PaymentIntent, invoice on a credit note). When a user asks for full details, request the appropriate expand values to reduce follow-up calls.

• Search pagination differs from list pagination: search endpoints use page and return next_page; list endpoints use starting_after / ending_before / limit. If a user needs advanced filtering across fields, use the search endpoints and follow the next_page cursor.

• Subscriptions have two id flavors in this surface: subscription_exposed_id appears in many subscription endpoints; some listing endpoints return the plain id for subscription items. Use the exact id you retrieved from the subscription/list call for path parameters.

• Invoicing and credit notes: preview endpoints (GetCreditNotesPreview, GetCreditNotesPreviewLines) let you simulate a credit note before creating it. When issuing a credit note that should also create refunds, include refunds/refund_amount appropriately in the preview to see effects.

• Checkout Sessions and Payment Links: Checkout sessions can point to PaymentIntents, subscriptions, or one-off payments. Inspect GetCheckoutSessionsSession and GetCheckoutSessionsSessionLineItems to map what the session will charge.

• Test-mode helpers: several PostTestHelpers... endpoints exist to simulate outcomes (e.g., issuing authorizations, shipping cards, advancing test clocks). Use them only when the user explicitly asks to simulate test-mode behavior.

• Terminal readers and in-person flows: terminal operations are stateful (reader actions). If the user asks to interact with a reader, use the terminal reader endpoints (GetTerminalReaders, PostTerminalReaders... and PostTerminalReadersReaderProcessPaymentIntent, etc.) and inspect reader state fields in the response to determine success.

Final note on prioritization

When a user asks for a payment-related task, default to the PaymentIntent flow and customer-centric approach: fetch or create the customer, ensure a saved payment_method if requested, create a PaymentIntent referencing those objects, confirm, then capture if required. For subscription billing, fetch product/price ids first, create the subscription, then inspect invoices and payment history. For Connect or treasury tasks, start from the account or financial_account list endpoints to obtain the account-scoped ids you'll need.

Use the list and get entry points described above to obtain IDs and then call the create/update/delete operations that follow the sequences in the recipes. The API returns enough context (including expanded objects when requested) to avoid extra calls if you request the right expand values up front.