Attributes
- idstring
Unique identifier for the object.
- api_
versionnullable string The Stripe API version used to render
data
. This property is populated only for events on or after October 31, 2014. - dataobject
Object containing data associated with the event.
- requestnullable object
Information on the API request that triggers the event.
- typestring
Description of the event (for example,
invoice.
orcreated charge.
).refunded
More attributes
- objectstring
- accountnullable stringConnect only
- createdtimestamp
- livemodeboolean
- pending_
webhooksinteger
{ "id": "evt_1NG8Du2eZvKYlo2CUI79vXWy", "object": "event", "api_version": "2019-02-19", "created": 1686089970, "data": { "object": { "id": "seti_1NG8Du2eZvKYlo2C9XMqbR0x", "object": "setup_intent", "application": null, "automatic_payment_methods": null, "cancellation_reason": null, "client_secret": "seti_1NG8Du2eZvKYlo2C9XMqbR0x_secret_O2CdhLwGFh2Aej7bCY7qp8jlIuyR8DJ", "created": 1686089970, "customer": null, "description": null, "flow_directions": null, "last_setup_error": null, "latest_attempt": null, "livemode": false, "mandate": null, "metadata": {}, "next_action": null, "on_behalf_of": null, "payment_method": "pm_1NG8Du2eZvKYlo2CYzzldNr7", "payment_method_options": { "acss_debit": { "currency": "cad", "mandate_options": { "interval_description": "First day of every month", "payment_schedule": "interval", "transaction_type": "personal" }, "verification_method": "automatic" } }, "payment_method_types": [ "acss_debit" ], "single_use_mandate": null, "status": "requires_confirmation", "usage": "off_session" } }, "livemode": false, "pending_webhooks": 0, "request": { "id": null, "idempotency_key": null }, "type": "setup_intent.created"}
Retrieves the details of an event if it was created in the last 30 days. Supply the unique identifier of the event, which you might have received in a webhook.
Parameters
No parameters.
Returns
Returns an event object if a valid identifier was provided. All events share a common structure, detailed to the right. The only property that will differ is the data
property.
In each case, the data
dictionary will have an attribute called object
and its value will be the same as retrieving the same object directly from the API. For example, a customer.
event will have the same information as retrieving the relevant customer would.
In cases where the attributes of an object have changed, data
will also contain a dictionary containing the changes.
{ "id": "evt_1NG8Du2eZvKYlo2CUI79vXWy", "object": "event", "api_version": "2019-02-19", "created": 1686089970, "data": { "object": { "id": "seti_1NG8Du2eZvKYlo2C9XMqbR0x", "object": "setup_intent", "application": null, "automatic_payment_methods": null, "cancellation_reason": null, "client_secret": "seti_1NG8Du2eZvKYlo2C9XMqbR0x_secret_O2CdhLwGFh2Aej7bCY7qp8jlIuyR8DJ", "created": 1686089970, "customer": null, "description": null, "flow_directions": null, "last_setup_error": null, "latest_attempt": null, "livemode": false, "mandate": null, "metadata": {}, "next_action": null, "on_behalf_of": null, "payment_method": "pm_1NG8Du2eZvKYlo2CYzzldNr7", "payment_method_options": { "acss_debit": { "currency": "cad", "mandate_options": { "interval_description": "First day of every month", "payment_schedule": "interval", "transaction_type": "personal" }, "verification_method": "automatic" } }, "payment_method_types": [ "acss_debit" ], "single_use_mandate": null, "status": "requires_confirmation", "usage": "off_session" } }, "livemode": false, "pending_webhooks": 0, "request": { "id": null, "idempotency_key": null }, "type": "setup_intent.created"}
List events, going back up to 30 days. Each event data is rendered according to Stripe API version at its creation time, specified in event object api_
attribute (not according to your current Stripe API version or Stripe-Version
header).
Parameters
- typesarray of strings
An array of up to 20 strings containing specific event names. The list will be filtered to include only events with a matching event property. You may pass either
type
ortypes
, but not both.
More parameters
- createdobject
- delivery_
successboolean - ending_
beforestring - limitinteger
- starting_
afterstring - typestring
Returns
A dictionary with a data
property that contains an array of up to limit
events, starting after event starting_
. Each entry in the array is a separate event object. If no more events are available, the resulting array will be empty.
{ "object": "list", "url": "/v1/events", "has_more": false, "data": [ { "id": "evt_1NG8Du2eZvKYlo2CUI79vXWy", "object": "event", "api_version": "2019-02-19", "created": 1686089970, "data": { "object": { "id": "seti_1NG8Du2eZvKYlo2C9XMqbR0x", "object": "setup_intent", "application": null, "automatic_payment_methods": null, "cancellation_reason": null, "client_secret": "seti_1NG8Du2eZvKYlo2C9XMqbR0x_secret_O2CdhLwGFh2Aej7bCY7qp8jlIuyR8DJ", "created": 1686089970, "customer": null, "description": null, "flow_directions": null, "last_setup_error": null, "latest_attempt": null, "livemode": false, "mandate": null, "metadata": {}, "next_action": null, "on_behalf_of": null, "payment_method": "pm_1NG8Du2eZvKYlo2CYzzldNr7", "payment_method_options": { "acss_debit": { "currency": "cad", "mandate_options": { "interval_description": "First day of every month", "payment_schedule": "interval", "transaction_type": "personal" }, "verification_method": "automatic" } }, "payment_method_types": [ "acss_debit" ], "single_use_mandate": null, "status": "requires_confirmation", "usage": "off_session" } }, "livemode": false, "pending_webhooks": 0, "request": { "id": null, "idempotency_key": null }, "type": "setup_intent.created" } ]}
This is a list of all the types of events we currently send. We may add more at any time, so in developing and maintaining your code, you should not assume that only these types exist.
You’ll notice that these events follow a pattern: resource.
. Our goal is to design a consistent system that makes things easier to anticipate and code against. Events that occur on subresources like customer.
do not trigger the parent’s update event.
Events marked as Selection required are only created when a webhook has been configured to listen for that type of event specifically. A webhook set to listen to all events will not receive an event requiring explicit selection.
Event types
- account.
application. authorized data.
is an applicationobject Occurs whenever a user authorizes an application. Sent to the related application only.
- account.
application. deauthorized data.
is an applicationobject Occurs whenever a user deauthorizes an application. Sent to the related application only.
- account.
external_ account. created data.
is an external account (e.g., card or bank account)object Occurs whenever an external account is created.
- account.
external_ account. deleted data.
is an external account (e.g., card or bank account)object Occurs whenever an external account is deleted.
- account.
external_ account. updated data.
is an external account (e.g., card or bank account)object Occurs whenever an external account is updated.
- account.
updated data.
is an accountobject Occurs whenever an account status or property has changed.
- application_
fee. created data.
is an application feeobject Occurs whenever an application fee is created on a charge.
- application_
fee. refund. updated data.
is a fee refundobject Occurs whenever an application fee refund is updated.
- application_
fee. refunded data.
is an application feeobject Occurs whenever an application fee is refunded, whether from refunding a charge or from refunding the application fee directly. This includes partial refunds.
- balance.
available data.
is a balanceobject Occurs whenever your Stripe balance has been updated (e.g., when a charge is available to be paid out). By default, Stripe automatically transfers funds in your balance to your bank account on a daily basis. This event is not fired for negative transactions.
- billing_
portal. configuration. created data.
is a billing portal configurationobject Occurs whenever a portal configuration is created.
- billing_
portal. configuration. updated data.
is a billing portal configurationobject Occurs whenever a portal configuration is updated.
- billing_
portal. session. created data.
is a billing portal sessionobject Occurs whenever a portal session is created.
- billing.
alert. triggered data.
is a billing alert triggeredobject Occurs whenever your custom alert threshold is met.
- capability.
updated data.
is a capabilityobject Occurs whenever a capability has new requirements or a new status.
- cash_
balance. funds_ available data.
is a cash balanceobject Occurs whenever there is a positive remaining cash balance after Stripe automatically reconciles new funds into the cash balance. If you enabled manual reconciliation, this webhook will fire whenever there are new funds into the cash balance.
- charge.
captured data.
is a chargeobject Occurs whenever a previously uncaptured charge is captured.
- charge.
dispute. closed data.
is a disputeobject Occurs when a dispute is closed and the dispute status changes to
lost
,warning_
, orclosed won
. - charge.
dispute. created data.
is a disputeobject Occurs whenever a customer disputes a charge with their bank.
- charge.
dispute. funds_ reinstated data.
is a disputeobject Occurs when funds are reinstated to your account after a dispute is closed. This includes partially refunded payments.
- charge.
dispute. funds_ withdrawn data.
is a disputeobject Occurs when funds are removed from your account due to a dispute.
- charge.
dispute. updated data.
is a disputeobject Occurs when the dispute is updated (usually with evidence).
- charge.
expired data.
is a chargeobject Occurs whenever an uncaptured charge expires.
- charge.
failed data.
is a chargeobject Occurs whenever a failed charge attempt occurs.
- charge.
pending data.
is a chargeobject Occurs whenever a pending charge is created.
- charge.
refund. updated data.
is a refundobject Occurs whenever a refund is updated, on selected payment methods.
- charge.
refunded data.
is a chargeobject Occurs whenever a charge is refunded, including partial refunds.
- charge.
succeeded data.
is a chargeobject Occurs whenever a charge is successful.
- charge.
updated data.
is a chargeobject Occurs whenever a charge description or metadata is updated, or upon an asynchronous capture.
- checkout.
session. async_ payment_ failed data.
is a checkout sessionobject Occurs when a payment intent using a delayed payment method fails.
- checkout.
session. async_ payment_ succeeded data.
is a checkout sessionobject Occurs when a payment intent using a delayed payment method finally succeeds.
- checkout.
session. completed data.
is a checkout sessionobject Occurs when a Checkout Session has been successfully completed.
- checkout.
session. expired data.
is a checkout sessionobject Occurs when a Checkout Session is expired.
- climate.
order. canceled data.
is a climate orderobject Occurs when a Climate order is canceled.
- climate.
order. created data.
is a climate orderobject Occurs when a Climate order is created.
- climate.
order. delayed data.
is a climate orderobject Occurs when a Climate order is delayed.
- climate.
order. delivered data.
is a climate orderobject Occurs when a Climate order is delivered.
- climate.
order. product_ substituted data.
is a climate orderobject Occurs when a Climate order’s product is substituted for another.
- climate.
product. created data.
is a climate productobject Occurs when a Climate product is created.
- climate.
product. pricing_ updated data.
is a climate productobject Occurs when a Climate product is updated.
- coupon.
created data.
is a couponobject Occurs whenever a coupon is created.
- coupon.
deleted data.
is a couponobject Occurs whenever a coupon is deleted.
- coupon.
updated data.
is a couponobject Occurs whenever a coupon is updated.
- credit_
note. created data.
is a credit noteobject Occurs whenever a credit note is created.
- credit_
note. updated data.
is a credit noteobject Occurs whenever a credit note is updated.
- credit_
note. voided data.
is a credit noteobject Occurs whenever a credit note is voided.
- customer_
cash_ balance_ transaction. created data.
is a customer cash balance transactionobject Occurs whenever a new customer cash balance transactions is created.
- customer.
created data.
is a customerobject Occurs whenever a new customer is created.
- customer.
deleted data.
is a customerobject Occurs whenever a customer is deleted.
- customer.
discount. created data.
is a discountobject Occurs whenever a coupon is attached to a customer.
- customer.
discount. deleted data.
is a discountobject Occurs whenever a coupon is removed from a customer.
- customer.
discount. updated data.
is a discountobject Occurs whenever a customer is switched from one coupon to another.
- customer.
source. created data.
is a source (e.g., card)object Occurs whenever a new source is created for a customer.
- customer.
source. deleted data.
is a source (e.g., card)object Occurs whenever a source is removed from a customer.
- customer.
source. expiring data.
is a source (e.g., card)object Occurs whenever a card or source will expire at the end of the month. This event only works with legacy integrations using Card or Source objects. If you use the PaymentMethod API, this event won’t occur.
- customer.
source. updated data.
is a source (e.g., card)object Occurs whenever a source’s details are changed.
- customer.
subscription. created data.
is a subscriptionobject Occurs whenever a customer is signed up for a new plan.
- customer.
subscription. deleted data.
is a subscriptionobject Occurs whenever a customer’s subscription ends.
- customer.
subscription. paused data.
is a subscriptionobject Occurs whenever a customer’s subscription is paused. Only applies when subscriptions enter
status=paused
, not when payment collection is paused. - customer.
subscription. pending_ update_ applied data.
is a subscriptionobject Occurs whenever a customer’s subscription’s pending update is applied, and the subscription is updated.
- customer.
subscription. pending_ update_ expired data.
is a subscriptionobject Occurs whenever a customer’s subscription’s pending update expires before the related invoice is paid.
- customer.
subscription. resumed data.
is a subscriptionobject Occurs whenever a customer’s subscription is no longer paused. Only applies when a
status=paused
subscription is resumed, not when payment collection is resumed. - customer.
subscription. trial_ will_ end data.
is a subscriptionobject Occurs three days before a subscription’s trial period is scheduled to end, or when a trial is ended immediately (using
trial_
).end=now - customer.
subscription. updated data.
is a subscriptionobject Occurs whenever a subscription changes (e.g., switching from one plan to another, or changing the status from trial to active).
- customer.
tax_ id. created data.
is a tax idobject Occurs whenever a tax ID is created for a customer.
- customer.
tax_ id. deleted data.
is a tax idobject Occurs whenever a tax ID is deleted from a customer.
- customer.
tax_ id. updated data.
is a tax idobject Occurs whenever a customer’s tax ID is updated.
- customer.
updated data.
is a customerobject Occurs whenever any property of a customer changes.
- entitlements.
active_ entitlement_ summary. updated data.
is an entitlements active entitlement summaryobject Occurs whenever a customer’s entitlements change.
- file.
created data.
is a fileobject Occurs whenever a new Stripe-generated file is available for your account.
- financial_
connections. account. created data.
is a financial connections accountobject Occurs when a new Financial Connections account is created.
- financial_
connections. account. deactivated data.
is a financial connections accountobject Occurs when a Financial Connections account’s status is updated from
active
toinactive
. - financial_
connections. account. disconnected data.
is a financial connections accountobject Occurs when a Financial Connections account is disconnected.
- financial_
connections. account. reactivated data.
is a financial connections accountobject Occurs when a Financial Connections account’s status is updated from
inactive
toactive
. - financial_
connections. account. refreshed_ balance data.
is a financial connections accountobject Occurs when an Account’s
balance_
status transitions fromrefresh pending
to eithersucceeded
orfailed
. - financial_
connections. account. refreshed_ ownership data.
is a financial connections accountobject Occurs when an Account’s
ownership_
status transitions fromrefresh pending
to eithersucceeded
orfailed
. - financial_
connections. account. refreshed_ transactions data.
is a financial connections accountobject Occurs when an Account’s
transaction_
status transitions fromrefresh pending
to eithersucceeded
orfailed
. - identity.
verification_ session. canceled data.
is an identity verification sessionobject Occurs whenever a VerificationSession is canceled
- identity.
verification_ session. created data.
is an identity verification sessionobject Occurs whenever a VerificationSession is created
- identity.
verification_ session. processing data.
is an identity verification sessionobject Occurs whenever a VerificationSession transitions to processing
- identity.
verification_ session. redacted data.
is an identity verification sessionSelection requiredobject Occurs whenever a VerificationSession is redacted.
- identity.
verification_ session. requires_ input data.
is an identity verification sessionobject Occurs whenever a VerificationSession transitions to require user input
- identity.
verification_ session. verified data.
is an identity verification sessionobject Occurs whenever a VerificationSession transitions to verified
- invoice.
created data.
is an invoiceobject Occurs whenever a new invoice is created. To learn how webhooks can be used with this event, and how they can affect it, see Using Webhooks with Subscriptions.
- invoice.
deleted data.
is an invoiceobject Occurs whenever a draft invoice is deleted. Note: This event is not sent for invoice previews.
- invoice.
finalization_ failed data.
is an invoiceobject Occurs whenever a draft invoice cannot be finalized. See the invoice’s last finalization error for details.
- invoice.
finalized data.
is an invoiceobject Occurs whenever a draft invoice is finalized and updated to be an open invoice.
- invoice.
marked_ uncollectible data.
is an invoiceobject Occurs whenever an invoice is marked uncollectible.
- invoice.
overdue data.
is an invoiceobject Occurs X number of days after an invoice becomes due—where X is determined by Automations
- invoice.
paid data.
is an invoiceobject Occurs whenever an invoice payment attempt succeeds or an invoice is marked as paid out-of-band.
- invoice.
payment_ action_ required data.
is an invoiceobject Occurs whenever an invoice payment attempt requires further user action to complete.
- invoice.
payment_ failed data.
is an invoiceobject Occurs whenever an invoice payment attempt fails, due either to a declined payment or to the lack of a stored payment method.
- invoice.
payment_ succeeded data.
is an invoiceobject Occurs whenever an invoice payment attempt succeeds.
- invoice.
sent data.
is an invoiceobject Occurs whenever an invoice email is sent out.
- invoice.
upcoming data.
is an invoiceobject Occurs X number of days before a subscription is scheduled to create an invoice that is automatically charged—where X is determined by your subscriptions settings. Note: The received
Invoice
object will not have an invoice ID. - invoice.
updated data.
is an invoiceobject Occurs whenever an invoice changes (e.g., the invoice amount).
- invoice.
voided data.
is an invoiceobject Occurs whenever an invoice is voided.
- invoice.
will_ be_ due data.
is an invoiceobject Occurs X number of days before an invoice becomes due—where X is determined by Automations
- invoiceitem.
created data.
is an invoiceitemobject Occurs whenever an invoice item is created.
- invoiceitem.
deleted data.
is an invoiceitemobject Occurs whenever an invoice item is deleted.
- issuing_
authorization. created data.
is an issuing authorizationobject Occurs whenever an authorization is created.
- issuing_
authorization. request data.
is an issuing authorizationSelection requiredobject Represents a synchronous request for authorization, see Using your integration to handle authorization requests.
- issuing_
authorization. updated data.
is an issuing authorizationobject Occurs whenever an authorization is updated.
- issuing_
card. created data.
is an issuing cardobject Occurs whenever a card is created.
- issuing_
card. updated data.
is an issuing cardobject Occurs whenever a card is updated.
- issuing_
cardholder. created data.
is an issuing cardholderobject Occurs whenever a cardholder is created.
- issuing_
cardholder. updated data.
is an issuing cardholderobject Occurs whenever a cardholder is updated.
- issuing_
dispute. closed data.
is an issuing disputeobject Occurs whenever a dispute is won, lost or expired.
- issuing_
dispute. created data.
is an issuing disputeobject Occurs whenever a dispute is created.
- issuing_
dispute. funds_ reinstated data.
is an issuing disputeobject Occurs whenever funds are reinstated to your account for an Issuing dispute.
- issuing_
dispute. funds_ rescinded data.
is an issuing disputeobject Occurs whenever funds are deducted from your account for an Issuing dispute.
- issuing_
dispute. submitted data.
is an issuing disputeobject Occurs whenever a dispute is submitted.
- issuing_
dispute. updated data.
is an issuing disputeobject Occurs whenever a dispute is updated.
- issuing_
personalization_ design. activated data.
is an issuing personalization designobject Occurs whenever a personalization design is activated following the activation of the physical bundle that belongs to it.
- issuing_
personalization_ design. deactivated data.
is an issuing personalization designobject Occurs whenever a personalization design is deactivated following the deactivation of the physical bundle that belongs to it.
- issuing_
personalization_ design. rejected data.
is an issuing personalization designobject Occurs whenever a personalization design is rejected by design review.
- issuing_
personalization_ design. updated data.
is an issuing personalization designobject Occurs whenever a personalization design is updated.
- issuing_
token. created data.
is an issuing tokenobject Occurs whenever an issuing digital wallet token is created.
- issuing_
token. updated data.
is an issuing tokenobject Occurs whenever an issuing digital wallet token is updated.
- issuing_
transaction. created data.
is an issuing transactionobject Occurs whenever an issuing transaction is created.
- issuing_
transaction. purchase_ details_ receipt_ updated data.
is an issuing transactionobject Occurs whenever an issuing transaction is updated with receipt data.
- issuing_
transaction. updated data.
is an issuing transactionobject Occurs whenever an issuing transaction is updated.
- mandate.
updated data.
is a mandateobject Occurs whenever a Mandate is updated.
- payment_
intent. amount_ capturable_ updated data.
is a payment intentobject Occurs when a PaymentIntent has funds to be captured. Check the
amount_
property on the PaymentIntent to determine the amount that can be captured. You may capture the PaymentIntent with ancapturable amount_
value up to the specified amount. Learn more about capturing PaymentIntents.to_ capture - payment_
intent. canceled data.
is a payment intentobject Occurs when a PaymentIntent is canceled.
- payment_
intent. created data.
is a payment intentobject Occurs when a new PaymentIntent is created.
- payment_
intent. partially_ funded data.
is a payment intentobject Occurs when funds are applied to a customer_balance PaymentIntent and the ‘amount_remaining’ changes.
- payment_
intent. payment_ failed data.
is a payment intentobject Occurs when a PaymentIntent has failed the attempt to create a payment method or a payment.
- payment_
intent. processing data.
is a payment intentobject Occurs when a PaymentIntent has started processing.
- payment_
intent. requires_ action data.
is a payment intentobject Occurs when a PaymentIntent transitions to requires_action state
- payment_
intent. succeeded data.
is a payment intentobject Occurs when a PaymentIntent has successfully completed payment.
- payment_
link. created data.
is a payment linkobject Occurs when a payment link is created.
- payment_
link. updated data.
is a payment linkobject Occurs when a payment link is updated.
- payment_
method. attached data.
is a payment methodobject Occurs whenever a new payment method is attached to a customer.
- payment_
method. automatically_ updated data.
is a payment methodobject Occurs whenever a payment method’s details are automatically updated by the network.
- payment_
method. detached data.
is a payment methodobject Occurs whenever a payment method is detached from a customer.
- payment_
method. updated data.
is a payment methodobject Occurs whenever a payment method is updated via the PaymentMethod update API.
- payout.
canceled data.
is a payoutobject Occurs whenever a payout is canceled.
- payout.
created data.
is a payoutobject Occurs whenever a payout is created.
- payout.
failed data.
is a payoutobject Occurs whenever a payout attempt fails.
- payout.
paid data.
is a payoutobject Occurs whenever a payout is expected to be available in the destination account. If the payout fails, a
payout.
notification is also sent, at a later time.failed - payout.
reconciliation_ completed data.
is a payoutobject Occurs whenever balance transactions paid out in an automatic payout can be queried.
- payout.
updated data.
is a payoutobject Occurs whenever a payout is updated.
- person.
created data.
is a personobject Occurs whenever a person associated with an account is created.
- person.
deleted data.
is a personobject Occurs whenever a person associated with an account is deleted.
- person.
updated data.
is a personobject Occurs whenever a person associated with an account is updated.
- plan.
created data.
is a planobject Occurs whenever a plan is created.
- plan.
deleted data.
is a planobject Occurs whenever a plan is deleted.
- plan.
updated data.
is a planobject Occurs whenever a plan is updated.
- price.
created data.
is a priceobject Occurs whenever a price is created.
- price.
deleted data.
is a priceobject Occurs whenever a price is deleted.
- price.
updated data.
is a priceobject Occurs whenever a price is updated.
- product.
created data.
is a productobject Occurs whenever a product is created.
- product.
deleted data.
is a productobject Occurs whenever a product is deleted.
- product.
updated data.
is a productobject Occurs whenever a product is updated.
- promotion_
code. created data.
is a promotion codeobject Occurs whenever a promotion code is created.
- promotion_
code. updated data.
is a promotion codeobject Occurs whenever a promotion code is updated.
- quote.
accepted data.
is a quoteobject Occurs whenever a quote is accepted.
- quote.
canceled data.
is a quoteobject Occurs whenever a quote is canceled.
- quote.
created data.
is a quoteobject Occurs whenever a quote is created.
- quote.
finalized data.
is a quoteobject Occurs whenever a quote is finalized.
- quote.
will_ expire data.
is a quoteobject Occurs X number of days before a quote is scheduled to expire—where X is determined by Automations
- radar.
early_ fraud_ warning. created data.
is a radar early fraud warningobject Occurs whenever an early fraud warning is created.
- radar.
early_ fraud_ warning. updated data.
is a radar early fraud warningobject Occurs whenever an early fraud warning is updated.
- refund.
created data.
is a refundobject Occurs whenever a refund is created.
- refund.
failed data.
is a refundobject Occurs whenever a refund has failed.
- refund.
updated data.
is a refundobject Occurs whenever a refund is updated.
- reporting.
report_ run. failed data.
is a reporting report runobject Occurs whenever a requested
ReportRun
failed to complete. - reporting.
report_ run. succeeded data.
is a reporting report runobject Occurs whenever a requested
ReportRun
completed successfully. - reporting.
report_ type. updated data.
is a reporting report typeSelection requiredobject Occurs whenever a
ReportType
is updated (typically to indicate that a new day’s data has come available). - review.
closed data.
is a reviewobject Occurs whenever a review is closed. The review’s
reason
field indicates why:approved
,disputed
,refunded
, orrefunded_
.as_ fraud - review.
opened data.
is a reviewobject Occurs whenever a review is opened.
- setup_
intent. canceled data.
is a setup intentobject Occurs when a SetupIntent is canceled.
- setup_
intent. created data.
is a setup intentobject Occurs when a new SetupIntent is created.
- setup_
intent. requires_ action data.
is a setup intentobject Occurs when a SetupIntent is in requires_action state.
- setup_
intent. setup_ failed data.
is a setup intentobject Occurs when a SetupIntent has failed the attempt to setup a payment method.
- setup_
intent. succeeded data.
is a setup intentobject Occurs when an SetupIntent has successfully setup a payment method.
- sigma.
scheduled_ query_ run. created data.
is a scheduled query runobject Occurs whenever a Sigma scheduled query run finishes.
- source.
canceled data.
is a source (e.g., card)object Occurs whenever a source is canceled.
- source.
chargeable data.
is a source (e.g., card)object Occurs whenever a source transitions to chargeable.
- source.
failed data.
is a source (e.g., card)object Occurs whenever a source fails.
- source.
mandate_ notification data.
is a source (e.g., card)object Occurs whenever a source mandate notification method is set to manual.
- source.
refund_ attributes_ required data.
is a source (e.g., card)object Occurs whenever the refund attributes are required on a receiver source to process a refund or a mispayment.
- source.
transaction. created data.
is a source transactionobject Occurs whenever a source transaction is created.
- source.
transaction. updated data.
is a source transactionobject Occurs whenever a source transaction is updated.
- subscription_
schedule. aborted data.
is a subscription scheduleobject Occurs whenever a subscription schedule is canceled due to the underlying subscription being canceled because of delinquency.
- subscription_
schedule. canceled data.
is a subscription scheduleobject Occurs whenever a subscription schedule is canceled.
- subscription_
schedule. completed data.
is a subscription scheduleobject Occurs whenever a new subscription schedule is completed.
- subscription_
schedule. created data.
is a subscription scheduleobject Occurs whenever a new subscription schedule is created.
- subscription_
schedule. expiring data.
is a subscription scheduleobject Occurs 7 days before a subscription schedule will expire.
- subscription_
schedule. released data.
is a subscription scheduleobject Occurs whenever a new subscription schedule is released.
- subscription_
schedule. updated data.
is a subscription scheduleobject Occurs whenever a subscription schedule is updated.
- tax_
rate. created data.
is a tax rateobject Occurs whenever a new tax rate is created.
- tax_
rate. updated data.
is a tax rateobject Occurs whenever a tax rate is updated.
- tax.
settings. updated data.
is a tax settingsobject Occurs whenever tax settings is updated.
- terminal.
reader. action_ failed data.
is a terminal readerobject Occurs whenever an action sent to a Terminal reader failed.
- terminal.
reader. action_ succeeded data.
is a terminal readerobject Occurs whenever an action sent to a Terminal reader was successful.
- test_
helpers. test_ clock. advancing data.
is a test helpers test clockobject Occurs whenever a test clock starts advancing.
- test_
helpers. test_ clock. created data.
is a test helpers test clockobject Occurs whenever a test clock is created.
- test_
helpers. test_ clock. deleted data.
is a test helpers test clockobject Occurs whenever a test clock is deleted.
- test_
helpers. test_ clock. internal_ failure data.
is a test helpers test clockobject Occurs whenever a test clock fails to advance its frozen time.
- test_
helpers. test_ clock. ready data.
is a test helpers test clockobject Occurs whenever a test clock transitions to a ready status.
- topup.
canceled data.
is a topupobject Occurs whenever a top-up is canceled.
- topup.
created data.
is a topupobject Occurs whenever a top-up is created.
- topup.
failed data.
is a topupobject Occurs whenever a top-up fails.
- topup.
reversed data.
is a topupobject Occurs whenever a top-up is reversed.
- topup.
succeeded data.
is a topupobject Occurs whenever a top-up succeeds.
- transfer.
created data.
is a transferobject Occurs whenever a transfer is created.
- transfer.
reversed data.
is a transferobject Occurs whenever a transfer is reversed, including partial reversals.
- transfer.
updated data.
is a transferobject Occurs whenever a transfer’s description or metadata is updated.
Events are generated to keep you informed of activity in your business account. APIs in the /v2 namespace generate thin events which have small, unversioned payloads that include a reference to the ID of the object that has changed. The Events v2 API returns these new thin events. Retrieve the event object for additional data about the event. Use the related object ID in the event payload to fetch the API resource of the object associated with the event. Comparatively, events generated by most API v1 include a versioned snapshot of an API object in their payload.
Set up an event destination to receive events from Stripe across multiple destination types, including webhook endpoints and Amazon EventBridge. Event destinations support receiving thin events and snapshot events.
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
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.
A Mandate is a record of the permission that your customer gives you to debit their payment method.
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
- POST/
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
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.
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
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
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 about how to use ConfirmationToken, visit the related guides:
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 External accounts. Radar, our integrated solution for automatic fraud protection, performs best with integrations that use client-side tokenization.
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.
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:
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 guide: Payment method domains.
These bank accounts are payment methods on Customer
objects.
On the other hand External Accounts are transfer destinations on Account
objects for connected accounts. They can be bank accounts or debit cards as well, and are documented in the links above.
Related guide: Bank debits and transfers
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.
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.
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
Sources Deprecated
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.
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
Prices define the unit cost, currency, and (optional) billing cycle for both recurring and one-time purchases of products. Products help you track inventory or provisioning, and prices help you track payment terms. Different physical goods or levels of service should be represented by products, and pricing options should be represented by prices. This approach lets you change prices without having to change your provisioning scheme.
For example, you might have a single “gold” product that has prices for $10/month, $100/year, and €9 once.
Related guides: Set up a subscription, create an invoice, and more about products and prices.
A coupon contains information about a percent-off or amount-off discount you might want to apply to a customer. Coupons may be applied to subscriptions, invoices, checkout sessions, quotes, and more. Coupons do not work with conventional one-off charges or payment intents.
A Promotion Code represents a customer-redeemable code for a coupon. It can be used to create multiple codes for a single coupon.
A discount represents the actual application of a coupon or promotion code. It contains information about when the discount began, when it will end, and what it is applied to.
Related guide: Applying discounts to subscriptions
Tax codes classify goods and services for tax purposes.
Tax rates can be applied to invoices, subscriptions and Checkout Sessions to collect tax.
Related guide: Tax rates
Shipping rates describe the price of shipping presented to your customers and applied to a purchase. For more information, see Charge for shipping.
A Checkout Session represents your customer’s session as they pay for one-time purchases or subscriptions through Checkout or Payment Links. We recommend creating a new Session each time your customer attempts to pay.
Once payment is successful, the Checkout Session will contain a reference to the Customer, and either the successful PaymentIntent or an active Subscription.
You can create a Checkout Session on your server and redirect to its URL to begin Checkout.
Related guide: Checkout quickstart
A payment link is a shareable URL that will take your customers to a hosted payment page. A payment link can be shared and used multiple times.
When a customer opens a payment link it will open a new checkout session to render the payment page. You can use checkout session events to track payments through payment links.
Related guide: Payment Links API
Issue a credit note to adjust an invoice’s amount after the invoice is finalized.
Related guide: Credit notes
Each customer has a Balance value, which denotes a debit or credit that’s automatically applied to their next invoice upon finalization. You may modify the value directly by using the update customer API, or by creating a Customer Balance Transaction, which increments or decrements the customer’s balance
by the specified amount
.
Related guide: Customer balance
The Billing customer portal is a Stripe-hosted UI for subscription and billing management.
A portal configuration describes the functionality and features that you want to provide to your customers through the portal.
A portal session describes the instantiation of the customer portal for a particular customer. By visiting the session’s URL, the customer can manage their subscriptions and billing details. For security reasons, sessions are short-lived and will expire if the customer does not visit the URL. Create sessions on-demand when customers intend to manage their subscriptions and billing details.
Related guide: Customer management
A portal configuration describes the functionality and behavior of a portal session.
Invoices are statements of amounts owed by a customer, and are either generated one-off, or generated periodically from a subscription.
They contain invoice items, and proration adjustments that may be caused by subscription upgrades/downgrades (if necessary).
If your invoice is configured to be billed through automatic charges, Stripe automatically finalizes your invoice and attempts payment. Note that finalizing the invoice, when automatic, does not happen immediately as the invoice is created. Stripe waits until one hour after the last webhook was successfully sent (or the last webhook timed out after failing). If you (and the platforms you may have connected to) have no webhooks configured, Stripe waits one hour after creation to finalize the invoice.
If your invoice is configured to be billed by sending an email, then based on your email settings, Stripe will email the invoice to your customer and await payment. These emails can contain a link to a hosted page to pay the invoice.
Stripe applies any customer credit on the account before determining the amount due for the invoice (i.e., the amount that will be actually charged). If the amount due for the invoice is less than Stripe’s minimum allowed charge per currency, the invoice is automatically marked paid, and we add the amount due to the customer’s credit balance which is applied to the next invoice.
More details on the customer’s credit balance are here.
Related guide: Send invoices to customers
- POST/
Invoice Items represent the component lines of an invoice. An invoice item is added to an invoice by creating or updating it with an invoice
field, at which point it will be included as an invoice line item within invoice.lines.
Invoice Items can be created before you are ready to actually send the invoice. This can be particularly useful when combined with a subscription. Sometimes you want to add a charge or credit to a customer, but actually charge or credit the customer’s card only at the end of a regular billing cycle. This is useful for combining several charges (to minimize per-transaction fees), or for having Stripe tabulate your usage-based billing totals.
Related guides: Integrate with the Invoicing API, Subscription Invoices.
Invoice Line Items represent the individual lines within an invoice and only exist within the context of an invoice.
Each line item is backed by either an invoice item or a subscription item.
Invoice Rendering Templates are used to configure how invoices are rendered on surfaces like the PDF. Invoice Rendering Templates can be created from within the Dashboard, and they can be used over the API when creating invoices.
A billing alert is a resource that notifies you when a certain usage threshold on a meter is crossed. For example, you might create a billing alert to notify you when a certain user made 100 API requests.
A billing meter is a resource that allows you to track usage of a particular event. For example, you might create a billing meter to track the number of API calls made by a particular user. You can then attach the billing meter to a price and attach the price to a subscription to charge the user for the number of API calls they make.
Related guide: Usage based billing
A billing meter event represents a customer’s usage of a product. Meter events are used to bill a customer based on their usage. Meter events are associated with billing meters, which define the shape of the event’s payload and how those events are aggregated for billing.
Meter events are used to report customer usage of your product or service. Meter events are associated with billing meters, which define the shape of the event’s payload and how those events are aggregated. Meter events are processed asynchronously, so they may not be immediately reflected in aggregates or on upcoming invoices.
A billing meter event adjustment is a resource that allows you to cancel a meter event. For example, you might create a billing meter event adjustment to cancel a meter event that was created in error or attached to the wrong customer.
A billing meter event adjustment is a resource that allows you to cancel a meter event. For example, you might create a billing meter event adjustment to cancel a meter event that was created in error or attached to the wrong customer.
You can send a higher-throughput of meter events using meter event streams. For this flow, you must first create a meter event session, which will provide you with a session token. You can then create meter events through the meter event stream endpoint, using the session token for authentication. The session tokens are short-lived and you will need to create a new meter event session when the token expires.
A billing meter event summary represents an aggregated view of a customer’s billing meter events within a specified timeframe. It indicates how much usage was accrued by a customer for that period.
A credit grant is an API resource that documents the allocation of some billing credits to a customer.
Related guide: Billing credits
Indicates the billing credit balance for billing credits granted to a customer.
A credit balance transaction is a resource representing a transaction (either a credit or a debit) against an existing credit grant.
You can now model subscriptions more flexibly using the Prices API. It replaces the Plans API and is backwards compatible to simplify your migration.
Plans define the base price, currency, and billing cycle for recurring purchases of products. Products help you track inventory or provisioning, and plans help you track pricing. Different physical goods or levels of service should be represented by products, and pricing options should be represented by plans. This approach lets you change prices without having to change your provisioning scheme.
For example, you might have a single “gold” product that has plans for $10/month, $100/year, €9/month, and €90/year.
Related guides: Set up a subscription and more about products and prices.
A Quote is a way to model prices that you’d like to provide to a customer. Once accepted, it will automatically create an invoice, subscription or subscription schedule.
Subscriptions allow you to charge a customer on a recurring basis.
Related guide: Creating subscriptions
Subscription items allow you to create customer subscriptions with more than one plan, making it easy to represent complex billing relationships.
A subscription schedule allows you to create and manage the lifecycle of a subscription by predefining expected changes.
Related guide: Subscription schedules
You can add one or multiple tax IDs to a customer or account. Customer and account tax IDs get displayed on related invoices and credit notes.
Related guides: Customer tax identification numbers, Account tax IDs
Test Clocks Test helper
A test clock enables deterministic control over objects in testmode. With a test clock, you can create objects at a frozen time in the past or future, and advance to a specific future time to observe webhooks and state changes. After the clock advances, you can either validate the current state of your scenario (and test your assumptions), change the current state of your scenario (and test more complex scenarios), or keep advancing forward in time.
Usage records allow you to report customer usage and metrics to Stripe for metered billing of subscription prices.
Related guide: Metered billing
This is our legacy usage-based billing API. See the updated usage-based billing docs.
A usage record summary represents an aggregated view of how much usage was accrued for a subscription item within a subscription billing period.
Financing Offer Preview feature
This is an object representing an offer of financing from Stripe Capital to a Connect subaccount.
Financing Summary Preview feature
A financing object describes an account’s current financing state. Used by Connect platforms to read the state of Capital offered to their connected accounts.
This is an object representing a Stripe account. You can retrieve it to see properties on the account like its current requirements or if the account is enabled to make live charges or receive payouts.
For accounts where controller.requirement_collection is application
, which includes Custom accounts, the properties below are always returned.
For accounts where controller.requirement_collection is stripe
, which includes Standard and Express accounts, some properties are only returned until you create an Account Link or Account Session to start Connect Onboarding. Learn about the differences between accounts.
Login Links are single-use URLs for a connected account to access the Express Dashboard. The connected account’s account.controller.stripe_dashboard.type must be express
to have access to the Express Dashboard.
Account Links are the means by which a Connect platform grants a connected account permission to access Stripe-hosted applications, such as Connect Onboarding.
Related guide: Connect Onboarding
An AccountSession allows a Connect platform to grant access to a connected account in Connect embedded components.
We recommend that you create an AccountSession each time you need to display an embedded component to your user. Do not save AccountSessions to your database as they expire relatively quickly, and cannot be used more than once.
Related guide: Connect embedded components
When you collect a transaction fee on top of a charge made for your user (using Connect), an Application Fee
object is created in your account. You can list, retrieve, and refund application fees.
Related guide: Collecting application fees
Application Fee Refund
objects allow you to refund an application fee that has previously been created but not yet refunded. Funds will be refunded to the Stripe account from which the fee was originally collected.
Related guide: Refunding application fees
This is an object representing a capability for a Stripe account.
Related guide: Account capabilities
Stripe needs to collect certain pieces of information about each account created. These requirements can differ depending on the account’s country. The Country Specs API makes these rules available to your integration.
You can also view the information from this API call as an online guide.
External bank accounts are financial accounts associated with a Stripe platform’s connected accounts for the purpose of transferring funds to or from the connected account’s Stripe balance.
External account cards are debit cards associated with a Stripe platform’s connected accounts for the purpose of transferring funds to or from the connected accounts Stripe balance.
This is an object representing a person associated with a Stripe account.
A platform cannot access a person for an account where account.controller.requirement_collection is stripe
, which includes Standard and Express accounts, after creating an Account Link or Account Session to start Connect onboarding.
See the Standard onboarding or Express onboarding documentation for information about prefilling information and account onboarding steps. Learn more about handling identity verification with the API.
To top up your Stripe balance, you create a top-up object. You can retrieve individual top-ups, as well as list all top-ups. Top-ups are identified by a unique, random ID.
Related guide: Topping up your platform account
A Transfer
object is created when you move funds between Stripe accounts as part of Connect.
Before April 6, 2017, transfers also represented movement of funds from a Stripe account to a card or bank account. This behavior has since been split out into a Payout object, with corresponding payout endpoints. For more information, read about the transfer/payout split.
Related guide: Creating separate charges and transfers
Stripe Connect platforms can reverse transfers made to a connected account, either entirely or partially, and can also specify whether to refund any related application fees. Transfer reversals add to the platform’s balance and subtract from the destination account’s balance.
Reversing a transfer that was made for a destination charge is allowed only up to the amount of the charge. It is possible to reverse a transfer_group transfer only if the destination account has enough balance to cover the reversal.
Related guide: Reverse transfers
Secret Store is an API that allows Stripe Apps developers to securely persist secrets for use by UI Extensions and app backends.
The primary resource in Secret Store is a secret
. Other apps can’t view secrets created by an app. Additionally, secrets are scoped to provide further permission control.
All Dashboard users and the app backend share account
scoped secrets. Use the account
scope for secrets that don’t change per-user, like a third-party API key.
A user
scoped secret is accessible by the app backend and one specific Dashboard user. Use the user
scope for per-user secrets like per-user OAuth tokens, where different users might have different permissions.
Related guide: Store data between page reloads
An early fraud warning indicates that the card issuer has notified us that a charge may be fraudulent.
Related guide: Early fraud warnings
Reviews can be used to supplement automated fraud detection with human expertise.
Value lists allow you to group values together which can then be referenced in rules.
Related guide: Default Stripe lists
Value list items allow you to add specific values to a given Radar value list, which can then be used in rules.
Related guide: Managing list items
An Issuing Cardholder
object represents an individual or business entity who is issued cards.
Related guide: How to create a cardholder
You can create physical or virtual cards that are issued to cardholders.
- POST/
As a card issuer, you can dispute transactions that the cardholder does not recognize, suspects to be fraudulent, or has other issues with.
Related guide: Issuing disputes
Funding Instructions contain reusable bank account and routing information. Push funds to these addresses via bank transfer to top up Issuing Balances.
A Personalization Design is a logical grouping of a Physical Bundle, card logo, and carrier text that represents a product line.
- POST/
A Physical Bundle represents the bundle of physical items - card stock, carrier letter, and envelope - that is shipped to a cardholder when you create a physical card.
Tokens Preview feature
An issuing token object is created when an issued card is added to a digital wallet. As a card issuer, you can view and manage these tokens through Stripe.
Any use of an issued card that results in funds entering or leaving your Stripe account, such as a completed purchase or refund, is represented by an Issuing Transaction
object.
Related guide: Issued card transactions
A Connection Token is used by the Stripe Terminal SDK to connect to a reader.
Related guide: Fleet management
A Location represents a grouping of readers.
Related guide: Fleet management
A Reader represents a physical device for accepting payment details.
Related guide: Connecting to a reader
- POST/
Terminal Hardware Order Preview feature
A TerminalHardwareOrder represents an order for Terminal hardware, containing information such as the price, shipping information and the items ordered.
- POST/
Terminal Hardware Product Preview feature
A TerminalHardwareProduct is a category of hardware devices that are generally similar, but may have variations depending on the country it’s shipped to.
TerminalHardwareSKUs represent variations within the same Product (for example, a country specific device). For example, WisePOS E is a TerminalHardwareProduct and a WisePOS E - US and WisePOS E - UK are TerminalHardwareSKUs.
Terminal Hardware SKU Preview feature
A TerminalHardwareSKU represents a SKU for Terminal hardware. A SKU is a representation of a product available for purchase, containing information such as the name, price, and images.
Terminal Hardware Shipping Method Preview feature
A TerminalHardwareShipping represents a Shipping Method for Terminal hardware. A Shipping Method is a country-specific representation of a way to ship hardware, containing information such as the country, name, and expected delivery date.
A Configurations object represents how features should be configured for terminal readers.
Stripe Treasury provides users with a container for money called a FinancialAccount that is separate from their Payments balance. FinancialAccounts serve as the source and destination of Treasury’s money movement APIs.
Encodes whether a FinancialAccount has access to a particular Feature, with a status
enum and associated status_
. Stripe or the platform can control Features via the requested field.
Transactions represent changes to a FinancialAccount’s balance.
TransactionEntries represent individual units of money movements within a single Transaction.
Use OutboundTransfers to transfer funds from a FinancialAccount to a PaymentMethod belonging to the same entity. To send funds to a different party, use OutboundPayments instead. You can send funds over ACH rails or through a domestic wire transfer to a user’s own external bank account.
Simulate OutboundTransfer state changes with the /v1/test_
endpoints. These methods can only be called on test mode objects.
Related guide: Moving money with Treasury using OutboundTransfer objects
- POST/
Use OutboundPayments to send funds to another party’s external bank account or FinancialAccount. To send money to an account belonging to the same user, use an OutboundTransfer.
Simulate OutboundPayment state changes with the /v1/test_
endpoints. These methods can only be called on test mode objects.
Related guide: Moving money with Treasury using OutboundPayment objects
- POST/
Use InboundTransfers to add funds to your FinancialAccount via a PaymentMethod that is owned by you. The funds will be transferred via an ACH debit.
Related guide: Moving money with Treasury using InboundTransfer objects
- POST/
ReceivedCredits represent funds sent to a FinancialAccount (for example, via ACH or wire). These money movements are not initiated from the FinancialAccount.
ReceivedDebits represent funds pulled from a FinancialAccount. These are not initiated from the FinancialAccount.
You can reverse some ReceivedCredits depending on their network and source flow. Reversing a ReceivedCredit leads to the creation of a new object known as a CreditReversal.
You can reverse some ReceivedDebits depending on their network and source flow. Reversing a ReceivedDebit leads to the creation of a new object known as a DebitReversal.
A feature represents a monetizable ability or functionality in your system. Features can be assigned to products, and when those products are purchased, Stripe will create an entitlement to the feature for the purchasing customer.
A product_feature represents an attachment between a feature and a product. When a product is purchased that has a feature attached, Stripe will create an entitlement to the feature for the purchasing customer.
An active entitlement describes access to a feature for a customer.
If you have scheduled a Sigma query, you’ll receive a sigma.
webhook each time the query runs. The webhook contains a ScheduledQueryRun
object, which you can use to retrieve the query results.
The Report Run object represents an instance of a report type generated with specific run parameters. Once the object is created, Stripe begins processing the report. When the report has finished running, it will give you a reference to a file where you can retrieve your results. For an overview, see API Access to Reports.
Note that certain report types can only be run based on your live-mode data (not test-mode data), and will error when queried without a live-mode API key.
The Report Type resource corresponds to a particular type of report, such as the “Activity summary” or “Itemized payouts” reports. These objects are identified by an ID belonging to a set of enumerated values. See API Access to Reports documentation for those Report Type IDs, along with required and optional parameters.
Note that certain report types can only be run based on your live-mode data (not test-mode data), and will error when queried without a live-mode API key.
A Financial Connections Account represents an account that exists outside of Stripe, to which you have been granted some degree of access.
Describes an owner of an account.
A Financial Connections Session is the secure way to programmatically launch the client-side Stripe.js modal that lets your users link their accounts.
A Transaction represents a real transaction that affects a Financial Connections Account balance.
A Tax Calculation allows you to calculate the tax to collect from your customer.
Related guide: Calculate tax in your custom payment flow
A Tax Registration
lets us know that your business is registered to collect tax on payments within a region, enabling you to automatically collect tax.
Stripe doesn’t register on your behalf with the relevant authorities when you create a Tax Registration
object. For more information on how to register to collect tax, see our guide.
Related guide: Using the Registrations API
A Tax Transaction records the tax collected from or refunded to your customer.
Related guide: Calculate tax in your custom payment flow
You can use Tax Settings
to manage configurations used by Stripe Tax calculations.
Related guide: Using the Settings API
A VerificationSession guides you through the process of collecting and verifying the identities of your users. It contains details about the type of verification, such as what verification check to perform. Only create one VerificationSession for each verification in your system.
A VerificationSession transitions through multiple statuses throughout its lifetime as it progresses through the verification flow. The VerificationSession contains the user’s verified data after verification checks are complete.
Related guide: The Verification Sessions API
A VerificationReport is the result of an attempt to collect and verify data from a user. The collection of verification checks performed is determined from the type
and options
parameters used. You can find the result of each verification check performed in the appropriate sub-resource: document
, id_
, selfie
.
Each VerificationReport contains a copy of any data collected by the user as well as reference IDs which can be used to access collected images through the FileUpload API. To configure and create VerificationReports, use the VerificationSession API.
Related guide: Accessing verification results.
A Crypto Onramp Session represents your customer’s session as they purchase cryptocurrency through Stripe. Once payment is successful, Stripe will fulfill the delivery of cryptocurrency to your user’s wallet and contain a reference to the crypto transaction ID.
You can create an onramp session on your server and embed the widget on your frontend. Alternatively, you can redirect your users to the standalone hosted onramp.
Related guide: Integrate the onramp
Crypto Onramp Quotes are estimated quotes for onramp conversions into all the different cryptocurrencies on different networks. The Quotes API allows you to display quotes in your product UI before directing the user to the onramp widget.
Related guide: Quotes API
Orders represent your intent to purchase a particular Climate product. When you create an order, the payment is deducted from your merchant balance.
A Climate product represents a type of carbon removal unit available for reservation. You can retrieve it to see the current price and availability.
A supplier of carbon removal.
Instructs Stripe to make a request on your behalf using the destination URL. The destination URL is activated by Stripe at the time of onboarding. Stripe verifies requests with your credentials provided during onboarding, and injects card details from the payment_method into the request.
Stripe redacts all sensitive fields and headers, including authentication credentials and card numbers, before storing the request and response data in the forwarding Request object, which are subject to a 30-day retention period.
You can provide a Stripe idempotency key to make sure that requests with the same key result in only one outbound request. The Stripe idempotency key provided should be unique and different from any idempotency keys provided on the underlying third-party request.
Forwarding Requests are synchronous requests that return a response or time out according to Stripe’s limits.
Related guide: Forward card details to third-party API endpoints.
You can configure webhook endpoints via the API to be notified about events that happen in your Stripe account or connected accounts.
Most users configure webhooks from the dashboard, which provides a user interface for registering and testing your webhook endpoints.
Related guide: Setting up webhooks