API Reference

The Stripe API is organized around REST. Our API has predictable resource-oriented URLs,
accepts form-encoded request bodies, returns JSON-encoded responses, and uses standard
HTTP response codes, authentication, and verbs.
You can use the Stripe API in test mode, which doesn’t affect your live data or interact with
the banking networks. The API key you use to authenticate the request determines whether
the request is live mode or test mode.
The Stripe API doesn’t support bulk updates. You can work on only one object per request.
The Stripe API differs for every account as we release new versions and tailor
functionality. Log in to see docs customized to your version of the API, with your test key
and data.
Just getting started?
Check out our development quickstart guide.
Not a developer?
Use Stripe’s no-code options or apps from our partners to get started with Stripe and to do
more with your Stripe account—no code required.
BASE URL
https://api.stripe.com
CLIENT LIBRARIES
Ruby
Python
PHP
Java
Node.js
Go
.NET
By default, the Stripe API Docs demonstrate using curl to interact with the API over HTTP.
Select one of our official client libraries to see examples in code.

Authentication
The Stripe API uses API keys to authenticate requests. You can view and manage your API
keys in the Stripe Dashboard.
Test mode secret keys have the prefix sk_test_ and live mode secret keys have the
prefix sk_live_ . Alternatively, you can use restricted API keys for granular permissions.
Your API keys carry many privileges, so be sure to keep them secure! Do not share your
secret API keys in publicly accessible areas such as GitHub, client-side code, and so forth.
All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API
requests without authentication will also fail.
 Related video: Authentication
AUTHENTICATED REQUEST
Server-side language
cUR L
 curl https://api.stripe.com/v1/charges \
-u sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc:
# The colon prevents curl from asking for a password.
YOUR API KEY
A sample test API key is included in all the examples here, so you can test any example right
away. Do not submit any personally identifiable information in requests made with this key.
To test requests using your account, replace the sample API key with your actual API key
or sign in.

Connected Accounts
To act as connected accounts, clients can issue requests using the Stripe-Account special
header. Make sure that this header contains a Stripe account ID, which usually starts with
the acct_ prefix.
The value is set per-request as shown in the adjacent code sample. Methods on the returned
object reuse the same account ID.
 Related guide: Making API calls for connected accounts
PER-REQUEST ACCOUNT
Server-side language
cUR L

curl https://api.stripe.com/v1/charges/ch_3LmjFA2eZvKYlo2C09TLIsrw \
-u sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc: \
-H "Stripe-Account: acct_1032D82eZvKYlo2C" \
-G

Errors
Stripe uses conventional HTTP response codes to indicate the success or failure of an API
request. In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate
an error that failed given the information provided (e.g., a required parameter was omitted, a
charge failed, etc.). Codes in the 5xx range indicate an error with Stripe’s servers (these are
rare).
Some 4xx errors that could be handled programmatically (e.g., a card is declined) include
an error code that briefly explains the error reported.

Attributes

 typeenum
The type of error returned. One of api_error , card_error , idempotency_error , or invalid_request_error
Possible enum values
api_error

card_error

idempotency_error
 invalid_request_error

 codenullable string
For some errors that could be handled programmatically, a short string indicating the error
code reported.
 decline_codenullable string
For card errors resulting from a card issuer decline, a short string indicating the card issuer’s
reason for the decline if they provide one.
 messagenullable string
A human-readable message providing more details about the error. For card errors, these
messages can be shown to your users.
 paramnullable string
If the error is parameter-specific, the parameter related to the error. For example, you can use
this to display a message near the correct form field.
 payment_intentnullable object
The PaymentIntent object for errors returned on a request involving a PaymentIntent.
Show child attributes

More

Expand all

 chargenullable string
 payment_method_typenullable string
 doc_urlnullable string
 request_log_urlnullable string
 setup_intentnullable object
 sourcenullable object
 payment_methodnullable object
HTTP STATUS CODE SUMMARY
200 OK Everything worked as expected.
The request was unacceptable, often due to missing a required
400 Bad Request
parameter.
401 Unauthorized No valid API key provided.
402 Request Failed The parameters were valid but the request failed.
403 Forbidden The API key doesn’t have permissions to perform the request.
404 Not Found The requested resource doesn’t exist.
The request conflicts with another request (perhaps due to
409 Conflict
using the same idempotent key).
Too Many Too many requests hit the API too quickly. We recommend an
429
Requests exponential backoff of your requests.
500, 502,
Server Errors Something went wrong on Stripe’s end. (These are rare.)
503, 504
ERROR TYPES
API errors cover any other type of problem (e.g., a temporary problem with
api_error
Stripe’s servers), and are extremely uncommon.
Card errors are the most common type of error you should expect to
card_error handle. They result when the user enters a card that can’t be charged for
some reason.
idempotency_error Idempotency errors occur when an Idempotency-Key is re-used on a request
 API errors cover any other type of problem (e.g., a temporary problem with
api_error
Stripe’s servers), and are extremely uncommon.
that does not match the first request’s API endpoint and parameters.
invalid_request_erro
r
Invalid request errors arise when your request has invalid parameters.

Handling errors
Our Client libraries raise exceptions for many reasons, such as a failed charge, invalid
parameters, authentication errors, and network unavailability. We recommend writing code
that gracefully handles all possible API exceptions.
 Related guide: Error Handling
Server-side language
cUR L

# Select a client library to see examples of

# handling different kinds of errors.

Expanding Responses
Many objects allow you to request additional information as an expanded response by using
the expand request parameter. This parameter is available on all API requests, and applies to
the response of that request only. You can expand responses in two ways.
In many cases, an object contains the ID of a related object in its response properties. For
example, a Charge might have an associated Customer ID. You can expand these objects in
line with the expand request parameter. The expandable label in this documentation indicates
ID fields that you can expand into objects.
Some available fields aren’t included in the responses by default, such as
the number and cvc fields for the Issuing Card object. You can request these fields as an
expanded response by using the expand request parameter.
You can expand recursively by specifying nested fields after a dot ( . ). For example,
requesting invoice.subscription on a charge expands the invoice property into a full Invoice
object, then expands the subscription property on that invoice into a full Subscription object.
You can use the expand parameter on any endpoint that returns expandable fields, including
list, create, and update endpoints.
Expansions on list requests start with the data property. For example, you can
expand data.customers on a request to list charges and associated customers. Performing deep
expansions on numerous list requests might result in slower processing times.
Expansions have a maximum depth of four levels (for example, the deepest expansion
allowed when listing charges is data.invoice.subscription.default_source ).
You can expand multiple objects at the same time by identifying multiple items in
the expand array.
 Related guide: Expanding responses
 Related video: Expand
Server-side language
curl https://api.stripe.com/v1/charges/ch_3LmzzQ2eZvKYlo2C0XjzUzJV \
-u sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc: \
-d "expand[]"=customer \
-d "expand[]"="invoice.subscription" \
-G
RESPONSE
{
"id": "ch_3LmzzQ2eZvKYlo2C0XjzUzJV",
"object": "charge",
"customer": {
"id": "cu_14HOpH2eZvKYlo2CxXIM7Pb2",
"object": "customer",
// ...
},
"invoice": {
"id": "in_1LmzzQ2eZvKYlo2CpyWn8szu",
"object": "invoice",
"subscription": {
"id": "su_1LmzoG2eZvKYlo2Cpw6S7dAq",
"object": "subscription",
// ...
},
// ...
},
// ...
}

Idempotent requests
The API supports idempotency for safely retrying requests without accidentally performing
the same operation twice. When creating or updating an object, use an idempotency key.
Then, if a connection error occurs, you can safely repeat the request without risk of creating a
second object or performing the update twice.
To perform an idempotent request, provide an additional IdempotencyKey element to the
request options.
Stripe’s idempotency works by saving the resulting status code and body of the first request
made for any given idempotency key, regardless of whether it succeedes or fails. Subsequent
requests with the same key return the same result, including 500 errors.
A client generates an idempotency key, which is a unique key that the server uses to
recognize subsequent retries of the same request. How you create unique keys is up to you,
but we suggest using V4 UUIDs, or another random string with enough entropy to avoid
collisions. Idempotency keys are up to 255 characters long.
You can remove keys from the system automatically after they’re at least 24 hours old. We
generate a new request if a key is reused after the original is pruned. The idempotency layer
compares incoming parameters to those of the original request and errors if they’re the same
to prevent accidental misuse.
We save results only after the execution of an endpoint begins. If incoming parameters fail
validation, or the request conflicts with another request that’s executing concurrently, we
 don’t save the idempotent result because no API endpoint initiates the execution. You can
retry these requests. Learn more about when you can retry idempotent requests.
All POST requests accept idempotency keys. Don’t send idempotency keys
in GET and DELETE requests because it has no effect. These requests are idempotent by
definition.
 Related video: Idempotency and retries
Server-side language

curl https://api.stripe.com/v1/customers \
-u sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc: \
-H "Idempotency-Key: KG5LxwFBepaKHyUD" \
-d description="My First Test Customer (created for API docs at https://www.stripe.com/docs/api)"

Metadata
Updateable Stripe objects—
including Account, Charge, Customer, PaymentIntent, Refund, Subscription,
and Transfer have a metadata parameter. You can use this parameter to attach key-value data
to these Stripe objects.
You can specify up to 50 keys, with key names up to 40 characters long and values up to 500
characters long.
You can use metadata to store additional, structured information on an object. For example,
you could store your user’s full name and corresponding unique identifier from your system
on a Stripe Customer object. Stripe doesn’t use metadata—for example, we don’t use it to
authorize or decline a charge and it won’t be seen by your users unless you choose to show it
to them.
Some of the objects listed above also support a description parameter. You can use
the description parameter to annotate a charge-for example, a human-readable description such
as 2 shirts for [email protected] . Unlike metadata , description is a single string, which your users
might see (for example, in email receipts Stripe sends on your behalf).
Don’t store any sensitive information (bank account numbers, card details, and so on) as
metadata or in the description parameter.
 Related video: Metadata
Sample metadata use cases
 Link IDs: Attach your system’s unique IDs to a Stripe object to simplify lookups. For
example, add your order number to a charge, your user ID to a customer or recipient,
or a unique receipt number to a transfer.
 Refund papertrails: Store information about the reason for a refund and the
individual responsible for its creation.
 Customer details: Annotate a customer by storing an internal ID for your future use.
POST /v1/customers
Server-side language

curl https://api.stripe.com/v1/customers \
 -u "sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc:" \
-d "metadata[order_id]"=6735
{
"id": "cus_123456789",
"object": "customer",
"address": {
"city": "city",
"country": "US",
"line1": "line 1",
"line2": "line 2",
"postal_code": "90210",
"state": "CA"
},
"balance": 0,
"created": 1483565364,
"currency": null,
"default_source": null,
"delinquent": false,
"description": null,
"discount": null,
"email": null,
"invoice_prefix": "C11F7E1",
"invoice_settings": {
"custom_fields": null,
"default_payment_method": null,
"footer": null,
"rendering_options": null
},
"livemode": false,
"metadata": {
"order_id": "6735"
},
"name": null,
"next_invoice_sequence": 1,
"phone": null,
"preferred_locales": [],
"shipping": null,
"tax_exempt": "none"
}

Pagination
All top-level API resources have support for bulk fetches through “list” API methods. For
example, you can list charges, list customers, and list invoices. These list API methods share
a common structure and accept, at a minimum, the following three
parameters: limit , starting_after , and ending_before .
Stripe’s list API methods use cursor-based pagination through
the starting_after and ending_before parameters. Both parameters accept an existing object ID
value (see below) and return objects in reverse chronological order.
The ending_before parameter returns objects listed before the named object.
The starting_after parameter returns objects listed after the named object. These parameters are
mutually exclusive. You can use either the starting_after or ending_before parameter, but not
both simultaneously.
Our client libraries offer auto-pagination helpers to traverse all pages of a list.
 Related video: Pagination and auto-pagination

Parameters

 limitoptional, default is 10
This specifies a limit on the number of objects to return, ranging between 1 and 100.
 starting_afteroptional object ID
A cursor to use in pagination. starting_after is an object ID that defines your place in the list.
For example, if you make a list request and receive 100 objects, ending with obj_foo , your
subsequent call can include starting_after=obj_foo to fetch the next page of the list.
 ending_beforeoptional object ID
A cursor to use in pagination. ending_before is an object ID that defines your place in the list.
For example, if you make a list request and receive 100 objects, starting with obj_bar , your
subsequent call can include ending_before=obj_bar to fetch the previous page of the list.

List Response Format

 objectstring, value is "list"

A string that provides a description of the object type that returns.
 dataarray
An array containing the actual response elements, paginated by any request parameters.
 has_moreboolean
Whether or not there are more elements available after this set. If false , this set comprises the
end of the list.
 urlurl
The URL for accessing this list.
RESPONSE
{
"object": "list",
"url": "/v1/customers",
"has_more": false,
"data": [
{
"id": "cus_4QFJOjw2pOmAGJ",
"object": "customer",
"address": null,
"balance": 0,
"created": 1405641735,
"currency": "usd",
"default_source": "card_14HOpG2eZvKYlo2Cz4u5AJG5",
"delinquent": false,
"description": "New customer",
"discount": null,
"email": null,
"invoice_prefix": "7D11B54",
"invoice_settings": {
"custom_fields": null,
"default_payment_method": null,
"footer": null,
"rendering_options": null
},
"livemode": false,
"metadata": {
"order_id": "6735"
 },
"name": "cus_4QFJOjw2pOmAGJ",
"next_invoice_sequence": 25,
"phone": null,
"preferred_locales": [],
"shipping": null,
"tax_exempt": "none",
"test_clock": null
},
{...},
{...}
]
}

Search
Some top-level API resource have support for retrieval via “search” API methods. For
example, you can search charges, search customers, and search subscriptions.
Stripe’s search API methods utilize cursor-based pagination via the page request parameter
and next_page response parameter. For example, if you make a search request and
receive "next_page": "pagination_key" in the response, your subsequent call can
include page=pagination_key to fetch the next page of results.
Our client libraries offer auto-pagination helpers to easily traverse all pages of a search result.

Search request format

 queryrequired
The search query string. See search query language.
 limitoptional
A limit on the number of objects to be returned. Limit can range between 1 and 100, and the
default is 10.
 pageoptional
A cursor for pagination across multiple pages of results. Don’t include this parameter on the
first call. Use the next_page value returned in a previous response to request subsequent
results.

Search response format

 objectstring, value is "search_result"

A string describing the object type returned.
 urlstring
The URL for accessing this list.
 has_moreboolean
Whether or not there are more elements available after this set. If false , this set comprises the
end of the list.
 dataarray
An array containing the actual response elements, paginated by any request parameters.
 next_pagestring
A cursor for use in pagination. If has_more is true, you can pass the value of next_page to a
subsequent call to fetch the next page of results.
 total_countoptional positive integer or zero
The total number of objects that match the query, only accurate up to 10,000. This field is not
included by default. To include it in the response, expand the total_count field.
RESPONSE
{
"object": "search_result",
"url": "/v1/customers/search",
"has_more": false,
"data": [
{
"id": "cus_4QFJOjw2pOmAGJ",
"object": "customer",
"address": null,
"balance": 0,
"created": 1405641735,
"currency": "usd",
"default_source": "card_14HOpG2eZvKYlo2Cz4u5AJG5",
"delinquent": false,
"description": "[email protected] for Coderwall",
"discount": null,
"email": null,
"invoice_prefix": "7D11B54",
"invoice_settings": {
"custom_fields": null,
"default_payment_method": null,
"footer": null,
"rendering_options": null
},
"livemode": false,
"metadata": {
"foo": "bar"
},
"name": "fakename",
"next_invoice_sequence": 25,
"phone": null,
"preferred_locales": [],
"shipping": null,
"tax_exempt": "none",
"test_clock": null
},
{...},
{...}
]
}

Auto-pagination
Our libraries support auto-pagination. This feature allows you to easily iterate through large
lists of resources without having to manually perform the requests to fetch subsequent pages.
Server-side language

# The auto-pagination feature is specific to Stripe's

# libraries and cannot be used directly with curl.

Request IDs
 Each API request has an associated request identifier. You can find this value in the response
headers, under Request-Id . You can also find request identifiers in the URLs of individual
request logs in your Dashboard.
To expedite the resolution process, provide the request identifier when you contact us about a
specific request.
Server-side language

curl https://api.stripe.com/v1/customers \
-u sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc: \
-D "-" \
-X POST

Versioning
When backwards-incompatible changes are made to the API, we release a new, dated version.
The current version is 2023-10-16. Learn more about API upgrades and backwards
compatibility. For information on all API updates, view our API changelog.
You can upgrade your API version in the Developer Dashboard. As a precaution, use API
versioning to test a new API version before committing to an upgrade.
 Related video: Versioning
Server-side language

curl https://api.stripe.com/v1/charges \
-u sk_test_4eC39Hq...arjtT1zdp7dcsk_test_4eC39HqLyjWDarjtT1zdp7dc: \
-H "Stripe-Version: 2023-10-16"

Balance
This is an object representing your Stripe balance. You can retrieve it to see the balance currently
on your Stripe account.
You can also retrieve the balance history, which contains a list of transactions that contributed to
the balance (charges, payouts, and so forth).
The available and pending amounts for each currency are broken down further by payment
source types.
Related guide: Understanding Connect account balances
ENDPOINTS
GET/v1/balance
SHOW

Balance Transactions
Balance transactions represent funds moving through your Stripe account. Stripe creates them
for every type of transaction that enters or leaves your Stripe account balance.
Related guide: Balance transaction types
ENDPOINTS
GET/v1/balance_transactions/:idGET/v1/balance_transactions
SHOW

Charges
The Charge object represents a single attempt to move money into your Stripe
account. PaymentIntent confirmation is the most common way to create Charges, but
transferring money to a different Stripe account through Connect also creates Charges. Some
legacy payment flows create Charges directly, which is not recommended for new integrations.
ENDPOINTS
POST/v1/chargesPOST/v1/charges/:idGET/v1/charges/:idGET/v1/chargesPOST/v1/charges/:id/
captureGET/v1/charges/search
SHOW

Customers
This object represents a customer of your business. Use it to create recurring charges and track
payments that belong to the same customer.
Related guide: Save a card during payment
ENDPOINTS
POST/v1/customersPOST/v1/customers/:idGET/v1/customers/:idGET/v1/customersDELETE/v1/
customers/:idGET/v1/customers/search
SHOW

Customer Session
A customer session allows you to grant client access to Stripe’s frontend SDKs (like
StripeJs) control over a customer.
ENDPOINTS
POST/v1/customer_sessions
SHOW

Disputes
A dispute occurs when a customer questions your charge with their card issuer. When this
happens, you have the opportunity to respond to the dispute with evidence that shows that the
charge is legitimate.
Related guide: Disputes and fraud
ENDPOINTS
POST/v1/disputes/:idGET/v1/disputes/:idGET/v1/disputesPOST/v1/disputes/:id/close
SHOW

Events
Events are our way of letting you know when something interesting happens in your account.
When an interesting event occurs, we create a new Event object. For example, when a charge
succeeds, we create a charge.succeeded event, and when an invoice payment attempt fails, we create
an invoice.payment_failed event. Certain API requests might create multiple events. For example, if
you create a new subscription for a customer, you receive both a customer.subscription.created event
and a charge.succeeded event.
Events occur when the state of another API resource changes. The event’s data field embeds the
resource’s state at the time of the change. For example, a charge.succeeded event contains a charge,
and an invoice.payment_failed event contains an invoice.
As with other API resources, you can use endpoints to retrieve an individual event or a list of
events from the API. We also have a separate webhooks system for sending the Event objects
directly to an endpoint on your server. You can manage webhooks in your account settings.
Learn how to listen for events so that your integration can automatically trigger reactions.
When using Connect, you can also receive event notifications that occur in connected accounts.
For these events, there’s an additional account attribute in the received Event object.
We only guarantee access to events through the Retrieve Event API for 30 days.
ENDPOINTS
GET/v1/events/:idGET/v1/events
SHOW

Files
This object represents files hosted on Stripe’s servers. You can upload files with the create
file request (for example, when uploading dispute evidence). Stripe also creates files
independently (for example, the results of a Sigma scheduled query).
Related guide: File upload guide
ENDPOINTS
POST/v1/filesGET/v1/files/:idGET/v1/files
SHOW

File Links
To share the contents of a File object with non-Stripe users, you can create a FileLink . FileLink s
contain a URL that you can use to retrieve the contents of the file without authentication.
ENDPOINTS
POST/v1/file_linksPOST/v1/file_links/:idGET/v1/file_links/:idGET/v1/file_links
SHOW

Mandates
A Mandate is a record of the permission that your customer gives you to debit their payment
method.
ENDPOINTS
GET/v1/mandates/:id
SHOW

Payment Intents
A PaymentIntent guides you through the process of collecting a payment from your
customer. We recommend that you create exactly one PaymentIntent for each order or customer
session in your system. You can reference the PaymentIntent later to see the history of payment
attempts for a particular session.
A PaymentIntent transitions through multiple statuses throughout its lifetime as it interfaces with
Stripe.js to perform authentication flows and ultimately creates at most one successful charge.
Related guide: Payment Intents API
ENDPOINTS
POST/v1/payment_intentsPOST/v1/payment_intents/:idGET/v1/payment_intents/:idGET/v1/
payment_intentsPOST/v1/payment_intents/:id/cancelPOST/v1/payment_intents/:id/capturePOST/v1/
payment_intents/:id/confirmPOST/v1/payment_intents/:id/increment_authorizationPOST/v1/
payment_intents/:id/apply_customer_balanceGET/v1/payment_intents/searchPOST/v1/
payment_intents/:id/verify_microdeposits
SHOW

Setup Intents
A SetupIntent guides you through the process of setting up and saving a customer’s payment
credentials for future payments. For example, you can use a SetupIntent to set up and save your
customer’s card without immediately collecting a payment. Later, you can use PaymentIntents to
drive the payment flow.
Create a SetupIntent when you’re ready to collect your customer’s payment credentials. Don’t
maintain long-lived, unconfirmed SetupIntents because they might not be valid. The SetupIntent
transitions through multiple statuses as it guides you through the setup process.
Successful SetupIntents result in payment credentials that are optimized for future payments. For
example, cardholders in certain regions might need to be run through Strong Customer
Authentication during payment method collection to streamline later off-session payments. If
you use the SetupIntent with a Customer, it automatically attaches the resulting payment method
to that Customer after successful setup. We recommend using SetupIntents
or setup_future_usage on PaymentIntents to save payment methods to prevent saving invalid or
unoptimized payment methods.
By using SetupIntents, you can reduce friction for your customers, even as regulations change
over time.
Related guide: Setup Intents API
ENDPOINTS
POST/v1/setup_intentsPOST/v1/setup_intents/:idGET/v1/setup_intents/:idGET/v1/setup_intentsPOST/
v1/setup_intents/:id/cancelPOST/v1/setup_intents/:id/confirmPOST/v1/setup_intents/:id/
verify_microdeposits
SHOW
Setup Attempts
A SetupAttempt describes one attempted confirmation of a SetupIntent, whether that
confirmation is successful or unsuccessful. You can use SetupAttempts to inspect details of a
specific attempt at setting up a payment method using a SetupIntent.
ENDPOINTS
GET/v1/setup_attempts
SHOW

Payouts
A Payout object is created when you receive funds from Stripe, or when you initiate a payout to
either a bank account or debit card of a connected Stripe account. You can retrieve individual
payouts, and list all payouts. Payouts are made on varying schedules, depending on your country
and industry.
Related guide: Receiving payouts
ENDPOINTS
POST/v1/payoutsPOST/v1/payouts/:idGET/v1/payouts/:idGET/v1/payoutsPOST/v1/payouts/:id/
cancelPOST/v1/payouts/:id/reverse
SHOW

Refunds
Refund objects allow you to refund a previously created charge that isn’t refunded yet. Funds are
refunded to the credit or debit card that’s initially charged.
Related guide: Refunds
ENDPOINTS
POST/v1/refundsPOST/v1/refunds/:idGET/v1/refunds/:idGET/v1/refundsPOST/v1/refunds/:id/cancel
SHOW

Confirmation TokenPreview feature

ConfirmationTokens help transport client side data collected by Stripe JS over to your server for
confirming a PaymentIntent or SetupIntent. If the confirmation is successful, values present on
the ConfirmationToken are written onto the Intent.
To learn more or request access, visit the related guided: Finalize payments on the server using
Confirmation Tokens.
ENDPOINTS
GET/v1/confirmation_tokens/:id
SHOW

Tokens
Tokenization is the process Stripe uses to collect sensitive card or bank account details, or
personally identifiable information (PII), directly from your customers in a secure manner. A token
representing this information is returned to your server to use. Use our recommended payments
integrations to perform this process on the client-side. This guarantees that no sensitive card
data touches your server, and allows your integration to operate in a PCI-compliant way.
If you can’t use client-side tokenization, you can also create tokens using the API with either your
publishable or secret API key. If your integration uses this method, you’re responsible for any PCI
compliance that it might require, and you must keep your secret API key safe. Unlike with client-
side tokenization, your customer’s information isn’t sent directly to Stripe, so we can’t determine
how it’s handled or stored.
You can’t store or use tokens more than once. To store card or bank account information for later
use, create Customer objects or Custom accounts. Radar, our integrated solution for automatic
fraud protection, performs best with integrations that use client-side tokenization.
ENDPOINTS
POST/v1/tokensPOST/v1/tokensPOST/v1/tokensPOST/v1/tokensPOST/v1/tokensPOST/v1/tokensGET/
v1/tokens/:id
SHOW

Payment Methods
PaymentMethod objects represent your customer’s payment instruments. You can use them
with PaymentIntents to collect payments or save them to Customer objects to store instrument
details for future payments.
Related guides: Payment Methods and More Payment Scenarios.
ENDPOINTS
POST/v1/payment_methodsPOST/v1/payment_methods/:idGET/v1/customers/:id/
payment_methods/:idGET/v1/payment_methods/:idGET/v1/customers/:id/payment_methodsGET/v1/
payment_methodsPOST/v1/payment_methods/:id/attachPOST/v1/payment_methods/:id/detach
SHOW

Payment Method Configurations

PaymentMethodConfigurations control which payment methods are displayed to your customers
when you don’t explicitly specify payment method types. You can have multiple configurations
with different sets of payment methods for different scenarios.
There are two types of PaymentMethodConfigurations. Which is used depends on the charge
type:
Direct configurations apply to payments created on your account, including Connect destination
charges, Connect separate charges and transfers, and payments not involving Connect.
Child configurations apply to payments created on your connected accounts using direct
charges, and charges with the on_behalf_of parameter.
Child configurations have a parent that sets default values and controls which settings connected
accounts may override. You can specify a parent ID at payment time, and Stripe will automatically
resolve the connected account’s associated child configuration. Parent configurations
are managed in the dashboard and are not available in this API.
Related guides:
 Payment Method Configurations API
 Multiple configurations on dynamic payment methods
 Multiple configurations for your Connect accounts
ENDPOINTS
POST/v1/payment_method_configurationsPOST/v1/payment_method_configurations/:idGET/v1/
payment_method_configurations/:idGET/v1/payment_method_configurations
SHOW

Payment Method Domains

A payment method domain represents a web domain that you have registered with Stripe. Stripe
Elements use registered payment method domains to control where certain payment methods
are shown.
Related guides: Payment method domains.
ENDPOINTS
POST/v1/payment_method_domainsPOST/v1/payment_method_domains/:idGET/v1/
payment_method_domains/:idGET/v1/payment_method_domainsPOST/v1/
payment_method_domains/:id/validate
SHOW

Bank Accounts
These bank accounts are payment methods on Customer objects.
On the other hand External Accounts are transfer destinations on Account objects for Custom
accounts. They can be bank accounts or debit cards as well, and are documented in the links
above.
Related guide: Bank debits and transfers
ENDPOINTS
POST/v1/customers/:id/sourcesPOST/v1/customers/:id/sources/:idGET/v1/customers/:id/
bank_accounts/:idGET/v1/customers/:id/bank_accountsDELETE/v1/customers/:id/sources/:idPOST/v1/
customers/:id/sources/:id/verify
SHOW

Cash Balance
A customer’s Cash balance represents real funds. Customers can add funds to their cash balance by
sending a bank transfer. These funds can be used for payment and can eventually be paid out to
your bank account.
ENDPOINTS
POST/v1/customers/:id/cash_balanceGET/v1/customers/:id/cash_balance
SHOW
Cash Balance Transaction
Customers with certain payments enabled have a cash balance, representing funds that were
paid by the customer to a merchant, but have not yet been allocated to a payment. Cash Balance
Transactions represent when funds are moved into or out of this balance. This includes funding
by the customer, allocation to payments, and refunds to the customer.
ENDPOINTS
GET/v1/customers/:id/cash_balance_transactions/:idGET/v1/customers/:id/
cash_balance_transactionsPOST/v1/test_helpers/customers/:id/fund_cash_balance
SHOW

Cards
You can store multiple cards on a customer in order to charge the customer later. You can also
store multiple debit cards on a recipient in order to transfer to those cards later.
Related guide: Card payments with Sources
ENDPOINTS
POST/v1/customers/:id/sourcesPOST/v1/customers/:id/sources/:idGET/v1/customers/:id/cards/:idGET/
v1/customers/:id/cardsDELETE/v1/customers/:id/sources/:id
SHOW

SourcesDeprecated
Source objects allow you to accept a variety of payment methods. They represent a customer’s
payment instrument, and can be used with the Stripe API just like a Card object: once chargeable,
they can be charged, or can be attached to customers.
Stripe doesn’t recommend using the deprecated Sources API. We recommend that you adopt
the PaymentMethods API. This newer API provides access to our latest features and payment
method types.
Related guides: Sources API and Sources & Customers.
ENDPOINTS
POST/v1/sourcesPOST/v1/sources/:idGET/v1/sources/:idPOST/v1/customers/:id/sourcesDELETE/v1/
customers/:id/sources/:id
SHOW

Products
Products describe the specific goods or services you offer to your customers. For example, you
might offer a Standard and Premium version of your goods or service; each version would be a
separate Product. They can be used in conjunction with Prices to configure pricing in Payment
Links, Checkout, and Subscriptions.
Related guides: Set up a subscription, share a Payment Link, accept payments with Checkout, and
more about Products and Prices