API upgrades

Your API version controls the API and webhook behavior you see (e.g., what properties you see in responses, what parameters you’re permitted to send in requests, etc.). Your version gets set the first time you make an API request. When we change the API in a backwards-incompatible way, we release a new dated version, but to avoid breaking your code, we don’t change your version until you’re ready to upgrade.

If you make requests on behalf of other users using Connect, we’ll use your application’s API version, making it easy for you to write code that works for all your users no matter what API versions they’re individually running.

Backwards-compatible changes

Stripe considers the following changes to be backwards-compatible:

• Adding new API resources.
• Adding new optional request parameters to existing API methods.
• Adding new properties to existing API responses.
• Changing the order of properties in existing API responses.
• Changing the length or format of opaque strings, such as object IDs, error messages, and other human-readable strings.
  This includes adding or removing fixed prefixes (such as ch_ on charge IDs).
  You can safely assume object IDs we generate will never exceed 255 characters, but you should be able to handle IDs of up to that length. If for example you’re using MySQL, you should store IDs in a VARCHAR(255) COLLATE utf8_bin column (the COLLATE configuration ensures case-sensitivity in lookups).
• Adding new event types.
  Your webhook listener should gracefully handle unfamiliar event types.

Upgrading your API version

If you’re running an older version of the API, upgrade to the latest version to take advantage of new functionality or to streamline responses so the API is faster for you. Upgrading your API version will affect:

• The API calls you make without a Stripe-Version header: the parameters you can send and the structure of objects returned.
• The structure of objects received with Stripe.js methods such as confirmCardPayment.
• The structure of objects sent to your webhook endpoints (both Account and Connect ones.) If an endpoint has an explicit version set, it will remain unaffected.
• Automated Billing operations performed by Stripe (e.g., generating an invoice for a new subscription period) use your account’s default API version. See the API changelog for details about how your default API version will impact these operations.

To see what version you’re running and upgrade to the latest one, visit your Dashboard.

When performing an API upgrade, make sure that you specify the API version that you’re integrating against in your code instead of relying on your account’s default API version. To test a newer version for API calls, set the Stripe-Version header (in live or test mode). Learn how to manage versioning in our server-side libraries.

For webhooks, you can override the version of a single test webhook endpoint in your Dashboard. To safely upgrade your webhooks, Stripe recommends that you:

1. Check the API changelog to see which objects will be structured differently.
2. Update your webhook code to handle both the old and new version of each object.
3. Change the version of a test webhook endpoint to the version you want to test.
4. Trigger the event in test mode and validate that your code works for the new structure.

When you’re confident that your code can handle the latest API version, click the Upgrade version button in your Dashboard. This switches the version used by API calls that don’t have the Stripe-Version header and also switches the version used to render objects sent to your webhooks.

Rolling back your API version

For 72 hours after you’ve upgraded your API version, you can safely roll back to the version you were upgrading from in your Dashboard.

After you’ve rolled back, webhooks that were sent with the new object structure and failed will be retried with the old structure.

Stay informed

We send information on new additions and changes to Stripe’s API and language libraries in the Stripe Developer Digest. Be sure to subscribe to stay informed.

API changelog

The changelog is a list of backwards-incompatible updates in the API. As described above, new additions and forward-compatible changes don’t need a new API version and will not appear in this list.

2020-03-02

• MajorYou can now optionally number invoices sequentially across your account instead of sequentially for each customer. To use this feature, enable account level numbering in the Stripe Dashboard.
• To ensure invoices are numbered sequentially and without gaps, invoices that can be deleted (drafts) are only assigned numbers when finalized.

2019-12-03

• MajorThe id field of all invoice line items have changed and are now prefixed with il_. The new id has consistent prefixes across all line items, is globally unique, and can be used for pagination.
  • You can no longer use the prefix of the id to determine the source of the line item. Instead use the type field for this purpose.
  • For lines with type=invoiceitem, use the invoice_item field to reference or update the originating Invoice Item object.
  • The Invoice Line Item object on earlier API versions also have a unique_id field to be used for migrating internal references before upgrading to this version.
  • When setting a tax rate to individual line items, use the new id. Users on earlier API versions can pass in either a line item id or unique_id.
• When creating a post-payment credit note on an invoice:
  • out_of_band_amount is required if the sum of credit_amount and (refund or refund_amount) is less than the credit note total.
  • In previous API versions out_of_band_amount is optional and, in the case that the credit_amount and refund amounts are less than the credit note total, the difference will automatically be allocated to the out_of_band_amount.
• Customer balances applied to all invoices are now debited or credited back to the customer when voided. Earlier, applied customer balances were not returned back to the customer and were consumed.
  • To achieve this behavior in earlier API versions:
    • Set consume_applied_balance to false when voiding invoices in /v1/invoices/:id/void.
    • Set invoice_customer_balance_settings[consume_applied_balance_on_void] to false in /v1/subscriptions create or update to force this behavior for Invoices voided by a Subscription.
    • Set subscription_data[invoice_customer_balance_settings][consume_applied_balance_on_void] to false in /v1/checkout/sessions create to force this behavior for Invoices voided by Subscriptions created with Checkout.
• Deprecated tax information for Customers have been removed.
  • The deprecated tax_info and tax_info_verification fields on the Customer object are now removed in favor of tax_ids.
  • The deprecated tax_info parameter on the Customer create and update methods are removed in favor of tax_id_data.
  • For more information, view the migration guide.

2019-11-05

• In the Accounts API, the requested_capabilities property is now required at creation time for Custom accounts in all countries. See Account capabilities for more information.

• On subscription schedules, invoice_settings, default_payment_method, billing_thresholds and collection_method are now nested under default_settings.

2019-10-17

• There are changes to subscription schedules.
  • Rename renewal_behavior to end_behavior with values cancel and release.
  • Remove renewal_interval.
  • A side effect of this change is that if you wrote a renewal_behavior of none on an old API version, end_behavior will be converted to cancel when reading the value back.
  • In the event that you are upgrading your API and set renewal_behavior as renew, with this API version enabled you will see end_behavior as renew however you will not be able to update renewal_interval. Additionally you can not set end_behavior to renew, so it is in a read-only state.

• The start field on a subscription resource has been removed and is replaced by a start_date field which represents when the entire subscription started as opposed to when the current plan configuration started.

• The due_date property is always null on invoices with billing=charge_automatically.

• The billing attribute on invoices, subscriptions, and subscription schedules is renamed to collection_method.

• The customer object’s account_balance value has been renamed to balance. A new customer balance transactions API is available:
  • Update the customer’s balance by incrementing or decrementing its current value by a specified amount and attaching metadata to the change.
  • Retrieve history of changes to the customer’s balance.

2019-10-08

• The relationship[account_opener] field on a Person object has been renamed to relationship[representative].

2019-09-09

• In the Accounts API, the requested_capabilities property is now required at creation time for accounts in Australia, Austria, Belgium, Denmark, Finland, France, Germany, Ireland, Italy, Luxembourg, the Netherlands, New Zealand, Norway, Portugal, Spain, Sweden, Switzerland, and the United Kingdom. See Account capabilities for more information.

• Adds additional details_code values to the verification[document] hash on a Person object.

2019-08-14

• MajorThe platform_payments capability has been renamed to transfers, to better indicate the Stripe primitives that this capability supports.

• The card_payments capability has been updated to no longer imply transfers. You’ll now need to additionally request the transfers capability when creating an account.

• The relationship[executive] field on a Person object will no longer be automatically set to true when a Person object with relationship[account_opener] is created. The requirements hash on an Account object may require that you explicitly indicate that the account_opener is also an executive. If this is the case, you will need to indicate it by setting relationship[executive]=true.

2019-05-16

• Bank pull payments no longer expose internal system refunds on failure.

System refunds can still be accessed via the list refunds endpoint.

2019-03-14

• The application_fee parameter on invoice API methods and the application_fee field on the invoice object have both been renamed to application_fee_amount.

• MajorCreating a subscription succeeds even when the first payment fails. The subscription will be created in an incomplete status, where it will remain for up to 23 hours. During that time period, it can be moved into an active state by paying the first invoice. If no successful payment is made, the subscription will move into a final incomplete_expired state. Updates to a non-incomplete subscription that require a payment will also succeed regardless of the payment status. Prior to this version, all creations or updates would fail if the corresponding payment failed. For more details see our guide.

• There are a few changes to the invoice object:

  • A status_transitions hash now contains the timestamps when an invoice was finalized, paid, marked uncollectible, or voided.
  • The date property has been renamed to created.
  • The finalized_at property has been moved into the status_transitions hash.

2019-02-19

• MajorStatement descriptor behaviors for card payments created via /v1/charges have changed. See our statement descriptor guide for details.
  • Instead of using the platform’s statement descriptor, charges created with on_behalf_of or destination will now use the descriptor of the connected account.
  • The full statement descriptor for a card payment may no longer be provided at charge creation. Dynamic descriptors provided at charge time will now be prefixed by the descriptor prefix set in the dashboard or via the new settings[card_payments][statement_descriptor_prefix] parameter in the Accounts API.
  • If an account has no statement_descriptor set, the account’s business or legal name will be used as statement descriptor.
  • Statement descriptors may no longer contain *, ', and ".
• MajorMany properties on the Account API object have been reworked. To see a mapping of the old argument names to the new ones, see Accounts API Argument Changes.
  • The legal_entity property on the Account API resource has been replaced with individual, company, and business_type.
  • The verification hash has been replaced with a requirements hash.
    • The verification[fields_needed] array has been replaced with three arrays to better represent when info is required: requirements[eventually_due], requirements[currently_due], and requirements[past_due].
    • verification[due_by] has been renamed to requirements[current_deadline].
    • The disabled_reason enum value of fields_needed has been renamed to requirements.past_due.
  • Properties on the Account API object that configure behavior within Stripe have been moved into the new settings hash.
    • The payout_schedule, payout_statement_descriptor and debit_negative_balances fields have been moved to settings[payouts] and renamed to schedule, statement_descriptor and debit_negative_balances.
    • The statement_descriptor field has been moved to settings[payments][statement_descriptor].
    • The decline_charge_on fields have been moved to settings[card_payments] and renamed to decline_on.
    • The business_logo, business_logo_large and business_primary_color fields have been moved to settings[branding] and renamed to icon, logo and primary_color. The icon field additionally requires the uploaded image file to be square.
    • The display_name and timezone fields have been moved to settings[dashboard].
  • business_name, business_url, product_description, support_address, support_email, support_phone and support_url have been moved to the business_profile subhash.
  • The legal_entity[verification][document] property (now located at individual[verification] and at verification in the Person API object) has been changed to a hash.
    • The front and back fields support uploading both sides of documents.
    • The details_code field has new error types: document_corrupt, document_failed_copy, document_failed_greyscale, document_failed_other, document_failed_test_mode, document_fraudulent, document_id_country_not_supported, document_id_type_not_supported, document_invalid, document_manipulated, document_missing_back, document_missing_front, document_not_readable, document_not_uploaded, document_photo_mismatch, and document_too_large.
  • The keys property on Account creation has been removed. Platforms should now authenticate as their connected accounts with their own key via the Stripe-Account header.
  • Starting with the 2019-02-19 API, the requested_capabilities property is now required at creation time for accounts in the U.S. See Account capabilities for more information.

2019-02-11

• Some PaymentIntent statuses have been renamed
  • requires_source is now requires_payment_method
  • requires_source_action is now requires_action
  • All other statuses are unchanged

• save_source_to_customer has been renamed to save_payment_method.

• allowed_source_types has been renamed to payment_method_types.

• The next_source_action property on PaymentIntent has been renamed to next_action, and the authorize_with_url within has been renamed to redirect_to_url.

2018-11-08

• The closed property on the invoice object controls automatic collection. closed has been deprecated in favor of the more specific auto_advance field. Where you might have set closed=true on invoices in the past, set auto_advance=false.

• auto_advance now also defaults to false for one-off invoices, allowing you to control how long their status stays a draft. A longer explanation of these series of changes is in the documentation.

• Instead of checking the forgiven field on an invoice, check for the uncollectible status.

• Instead of setting the forgiven field on an invoice, mark it as uncollectible.

• The immutable_frozen_invoice error code was renamed to invoice_already_finalized
• The following changes only affect users of PaymentIntents as part of the private beta before November 15, 2018. If you did not use PaymentIntents before then, these don’t affect you.
  • The next_source_action dictionary on PaymentIntents previously contained a key called value. This has been replaced with the authorize_with_url and use_stripe_sdk keys.
  • When creating PaymentIntents, the attempt_confirmation parameter has been renamed to confirm.
  • The PaymentIntent confirm endpoint no longer supports the payment_intent parameter. To update a PaymentIntent’s source, pass source or source_data as a top-level parameter.
  • The return_url parameter is only allowed when confirming a PaymentIntent. Passing return_url when updating a PaymentIntent is no longer allowed.
  • When creating a PaymentIntent with transfer_data[destination], the on_behalf_of parameter must be provided and must match the account provided to transfer_data[destination]. This is because when you provide a destination, Stripe will settle charges in the country of the destination account.
  • The next_source_action dictionary on PaymentIntents no longer contains the source_type property. To view the source type when retrieving PaymentIntents, expand the source parameter.

2018-10-31

• The description field on customer endpoints has a maximum character length limit of 350 now. The name field on product endpoints has a maximum character length limit of 250 now. The description field on invoice line items has a maximum character length limit of 500 now.
• The billing_reason attribute of the invoice object now can take the value of subscription_create, indicating that it is the first invoice of a subscription. For older API versions, billing_reason=subscription_create is represented as subscription_update.

2018-09-24

• FileUpload objects have been renamed to File objects. Additionally, the url attribute now contains an authenticated URL (i.e. you will need to use your secret API key to download the file’s contents.) You can create a file link to obtain a publicly-accessible URL for the file.

2018-09-06

• When creating or updating a SKU, its attribute values no longer need to be unique. It is now possible to create multiple SKUs without attributes or with identical attribute values.

2018-08-23

• You can no longer set at_period_end in the subscription DELETE endpoints. The DELETE endpoint is reserved for immediate canceling going forward. Use cancel_at_period_end on the subscription update endpoints instead.
• The customer object’s business_vat_id was changed from String to Hash called tax_info, consisting of tax_id and type, in both requests and responses.
• The amount field field in the tiers configuration for plans was renamed to unit_amount.

2018-07-27

• The subscription endpoints no longer support the source parameter. If you want to change the default source for a customer, instead use the source creation API to add the new source and then the customer update API to set it as the default.
• When ending a trial on a subscription using trial_end=now the updated subscription will now receive a trial_end timestamp from the time of the request rather than being unset.
• The percent_off field of coupons was changed from Integer to Float, with a precision of two decimal places.
• When creating or updating a customer the email parameter must contain an email address of valid shape.

2018-05-21

• Products no longer have SKU lists embedded.
• MajorThe id field of invoice line items of type=subscription no longer can be interpreted as a subscription ID, but instead is a unique invoice line item ID. It can be used for pagination.
• Coupon, SKU, customer, product and plan ids may only contain alphanumeric and _- characters on creation.
• MajorWhen creating or updating subscriptions, the default value of trial_from_plan is now false, meaning that a subscription will not automatically inherit a plan’s trial_period_days. If a subscription is already trialing, switching to a new plan without specifying trial_from_plan will maintain the trial. We recommend setting an explicit trial per subscription instead of setting trials on plans.
• When changing the plan on a subscription to a new plan with a trial (together with trial_from_plan=true), the new plan’s full trial period will be added to the subscription, without subtracting already-used time from previous trials.

2018-02-28

• Updating a subscription set to cancel on a future date no longer clears the cancellation status. In order to clear the cancellation status, specify cancel_at_period_end=false when updating a subscription.

2018-02-06

• For a Source’s card[three_d_secure] property, adds recommended as a possible value. Previously, the only valid values were not supported, optional, and required.

2018-02-05

• MajorEach plan object is now linked to a product object with type=service. The plan object statement_descriptor and name attributes have been moved to product objects, and plan objects now have a nickname attribute. Creating a plan now requires passing a product attribute to POST /v1/plans. This may be either an existing product ID or a dictionary of product fields, so that you may continue to create plans without separately creating products.
• Products now have a required type, good for products used with Orders SKUs or service for products used with Subscriptions and Plans. Previous API versions will create a good type product if this field is omitted.
  • Products with type=service are omitted by default from GET /v1/products. You can list them by specifying type=service when listing products.
• MajorAllows a new subscription’s first full invoice to be on a future date, by specifying billing_cycle_anchor, with an optional proration up to that date.billing_cycle_anchor on its own is available retroactively to past versions, and starting in this version, billing_cycle_anchor can be combined with a trial, enabling a free trial to be followed by a prorated period, followed by a fixed billing cycle.
• Prorations on free plans now create $0 invoices. In past versions, these did not create invoices.

2018-01-23

• When being viewed by a platform, cards and bank accounts created on behalf of connected accounts will have a fingerprint that is universal across all connected accounts. For accounts that are not connect platforms, there will be no change.

2017-12-14

• Updates invoice payment attempts to return a card_error when the charge is declined. This aligns /v1/invoices/{INVOICE_ID}/pay with /v1/charges.
• Updates invoice line items to always have a description set, including invoice line items generated from subscription items.

2017-08-15

• Adds not_required as a possible redirect[status] value on the Source object. Previously, optional redirects were marked as succeeded.

2017-06-05

• Adds under_review as a possible verification[disabled_reason] value on the Account object. Previously, an under review status used the value other.

2017-05-25

• Replaces the managed Boolean property on Account objects with type, whose possible values are: standard, express, and custom. A managed value is required when creating accounts.
• Updates the previous_attributes property on Event objects to show entire sub-arrays when those arrays have changes. Previously, those sub-arrays only showed the specific fields that changed.
• Updates the request property on the Event object to be a hash containing the request ID and the idempotency key. Previously, request was just the ID.
• Renames the user_id property on Connect-related event objects to account.

2017-04-06

• MajorSplits the Transfer object into Payout and Transfer. The Payout object represents money moving from a Stripe account to an external account (bank or debit card). The Transfer object now only represents money moving between Stripe accounts on a Connect platform. For more details, see https://stripe.com/docs/transfer-payout-split.

2017-02-14

• Updates the dispute property on the Charge object to contain the ID of an associated dispute. Previously, dispute contained the entire Dispute object. You can expand this property when retrieving charges to render the full Dispute object as before.
• Updates the outcome[rule] property on the Charge object to contain the ID of the rule that blocked the charge. Previously, outcome[rule] contained the entire Rule object. You can expand this property when retrieving charges to render the full Rule object as before.

2017-01-27

• Removes the sourced_transfers property from the Balance Transaction object.

2016-10-19

• Returns the status code 403 when an API request is made with insufficient permission. Previously, the API returned a 401 status code.

2016-07-06

• Updates the list all subscriptions call to also return canceled subscriptions. The endpoint now supports fetching only canceled subscriptions by specifying status=canceled. You can now retrieve a single canceled subscription by providing its ID.

2016-06-15

• Updates the active property on the Product object so that setting active to false no longer marks the product’s SKUs as inactive.

2016-03-07

• Removes the currencies_supported property from the Account object. You can find a list of supported currencies by retrieving a Country Spec object for the country of the account.

2016-02-29

• Adds postal code validation for legal entity addresses when creating and updating accounts.

2016-02-23

• Updates the behavior of orders so that changing an order from paid or fulfilled to canceled or returned automatically refunds the associated charge. Previously, attempting to change an order from paid or fulfilled to canceled or returned raised an error if the associated charge had not already been refunded.

2016-02-22

• Returns an error on attempts to add more than 250 invoice items to an invoice.

2016-02-19

• Renames the name property on the Bank Account object to account_holder_name.

2016-02-03

• Updates the returned Account object to only show sub-properties of legal_entity that are applicable to the account’s country, or that were previously provided.

2015-10-16

• Returns an error if a tax_percent is provided without a plan during a customer update or creation.

2015-10-12

• MajorReturns an error when invalid parameters are passed in the card or bank account hash during token, source, or external account creation. Changes the error code returned for missing required parameters in the card or bank account hash to 400. Previously, a 402 code was returned.

2015-10-01

• Replaces the bank_accounts property on the Account object with external_accounts. Replaces the bank_account value in the fields_needed property with external_account.

2015-09-23

• Updates the charge property on the Invoice object to always show the invoice’s latest charge, regardless of the charge’s source (e.g, a card or a bank account). Removes the payment property, which previously reflected a non-card charge.
• MajorUpdates the list all charges call to return all charges, including those made to bank accounts and other non-card sources. Previously, it only returned charges made to cards. Updates the deprecated offset parameter to only be supported when filtering by source type.

2015-09-08

• Updates API rate limit errors to return a 429 HTTP status code instead of 400. They also no longer return a rate_limit error code.

2015-09-03

• Returns an error if a request reuses an idempotency token with different parameters than the original request. Previously, errors were only returned for reusing the same idempotency token across different API endpoints.

2015-08-19

• Updates the Balance Transaction object to provide the refund ID or dispute ID as the source value when the balance transaction is associated with a refund or dispute. Previously, the original charge ID was shown.

2015-08-07

• Adds date validation to the tos_acceptance[date] property on the Account object. Accepted values are timestamps after 2009 and before the current moment.

2015-07-28

• The balance.available event is now triggered when immediate transfers are processed.

2015-07-13

• Replaces the verification[contacted] Boolean property on the Account object with a verification[disabled_reason] string that describes why the account is unable to make transfers or charges.

2015-07-07

• Updates the status property on the Transfer object so that transfers not yet submitted to the bank are still pending and transfers submitted to the bank that have not yet arrived are in_transit. Previously, both states were described as pending.

2015-06-15

• Updates the payout_schedule[delay_days] property on the Account object to return an error if provided when the interval is set to manual. Manual payouts always use the minimum delay_days value.

2015-04-07

• Updates the period[end] property on proration invoice line items to reflect the subscription’s current_period_end property when the update and proration was made. A proration invoice line item’s period[start] and period[end] properties now represent the prorated adjustment interval. Previously, period[end] marked the time at which the proration was made, and was the same as period[start].
• Updates the Invoice object to change the order of the lines list: first invoice items in reverse chronological order, followed by the subscription, if applicable.

2015-03-24

• Updates coupons so they no longer apply to negative invoice items by default. Previously, coupons applied to all non-proration invoice items. To allow a coupon to apply to a negative invoice item, pass discountable=true when creating or updating the invoice item.

2015-02-18

• Updates the status property on the Charge object to have a value of succeeded for successful charges. Previously, the status property would be paid for successful charges.
• MajorReplaces the card property on the Charge object with source. Provide this parameter with a Card token, as before, or with a Source token that has an object value of card. Older API versions return both the card and source properties on Charge.
• MajorReplaces the cards and default_card properties on the Customer object with sources and default_source. Both properties can represent Card objects, as before, and Source objects with an object value of card. Older API versions return both the new and old properties on Customer. Replaces the customer.card.* and customer.bank_account.* events with customer.source.*.

2015-02-16

• Renames the transfer.canceled event to transfer.reversed.

2015-02-10

• Adds the value warning_closed to the status property on the Dispute object.
• Updates test mode transfers to require sufficient funds in your available test mode balance (for consistency with live mode transfers). Add funds directly to your available test mode balance—bypassing the pending balance—by creating a charge using the special test card number 4000 0000 0000 0077.

2015-01-26

• Updates the presentation of nested hashes in the previous_attributes property of events to only show the difference. For example, a change from {address: {line1: "Foo", line2: "Bar"}} to {address: {line1: "Foo", line2: "Baz"}} is represented as {previous_attributes: {address: {line2: "Baz"}}}. Previously, it was represented as {previous_attributes: {address: {line1: "Foo", line2: "Baz"}}}.
• Updates the canceled_at property on the Subscription object to always be the timestamp from the API call or invoice payment failure that canceled the subscription. Previously, canceled_at reflected “at period end” subscription cancellations, too. The ended_at property still reflects the time that the subscription actually stopped.

2015-01-11

• Removes the mimetype property from the File Upload object. Returns simplified file types in the type property and uses simpler naming conventions than mimetypes (e.g., type contains pdf instead of application/pdf).

2014-12-22

• Updates the Card object so a value of unchecked for the address_line1_check, address_zip_check, or cvc_check properties means the property has not been checked. Previously, it meant the issuing bank does not support the particular check. That state now shows as unavailable. Unchecked properties are checked when a card is charged or added to a Customer object.
• Removes the customer property from the Card object that appears on the Token object.

2014-12-17

• Replaces the statement_description property on the Charge, Invoice, Plan, and Transfer objects with statement_descriptor. To determine what appears on a customer’s transaction, statement_description is appended to your Stripe account’s statement descriptor while statement_descriptor sets the full statement value. If not on this API version or newer, providing a statement_descriptor still triggers the statement_description behavior. Regardless of API version, the statement_description behavior does not apply with PaymentIntents.
• Updates the Accounts API to require API version 2014-12-17 or newer.

2014-12-08

• Updates the Dispute object so evidence can be provided as a hash of typed fields rather than a single block of text. Replaces the evidence_due_by property with the evidence_details hash, which includes due_by and submission_count (for the number of times a dispute has been submitted).

2014-11-20

• Updates disputes that are won to return the status won even if the charge was refunded. Previously, a dispute won that had a refunded charge would transition to charge_refunded.
• Updates the metadata property of the Invoice Item object with a type of subscription to show the subscription’s metadata. Previously, it showed the plan’s metadata.

2014-11-05

• Renames the charge_enabled and transfer_enabled properties on the Account object to charges_enabled and transfers_enabled.

2014-10-07

• Prevents publishable keys from retrieving Token objects. When a card or bank account token is created with a publishable key, the fingerprint property is not included in the response.

2014-09-08

• Replaces the disabled, validated, and verified properties on the Bank Account object with a status enum property.

2014-08-20

• Adds three values to the status property on the Dispute object: warning_needs_response, warning_under_review, and charge_refunded. Replaces the balance_transaction property of the Dispute object with balance_transactions (this provides greater detail around funds withdrawn and reinstated as a result of disputes).

2014-08-04

• Removes the other_transfers, summary, and transactions properties from automatic transfer responses in favor of the balance history endpoint (/v1/balance/history).

2014-07-26

• Changes the refunds property on the Application Fee object from an array to a sublist object, which contains the data, has_more, and url properties. This makes application fee refunds consistent with charge refunds.

2014-07-22

• Updates proration line items on invoices to include the associated subscription’s plan and quantity.

2014-06-17

• Changes the refunds property on the Charge object from an array to a sublist object, which contains the data, has_more, and url properties.

2014-06-13

• Renames the type property on the Card object to brand.

2014-05-19

• Replaces the account property on the Transfer object with bank_account. The bank_account property is only included when the transfer is made to a bank account.

2014-03-28

• MajorRemoves the count property from list responses.

2014-03-13

• Renames the statement_descriptor property on the Transfer object to statement_description.

2014-01-31

• MajorReplaces the subscription property on the Customer object with the subscriptions property, as customers can have multiple subscriptions.
• Ignores trial dates on canceled subscriptions when automatically computing trial end dates for new subscriptions.

2013-12-03

• Replaces the user and user_email properties on the Application Fee object with an expandable account property.
• Updates the refunding of application fees to be proportional to the amount of the charge refunded (when setting refund_application_fee=true). Previously, the entire application fee was refunded even when only part of the charge was.

2013-10-29

• MajorChanges coupon behavior so that applying an amount-off coupon to an invoice does not increase the Customer account balance if the discount is greater than the invoice amount. Coupons are ignored—and not counted as redeemed—when applied to zero-cost invoices. This change does not apply to coupons created on earlier API version.

2013-08-13

• Removes the fee and fee_details properties from the Charge and Transfer objects. Fee information is in the corresponding balance transaction.

2013-08-12

• Allows the description property on Customer, Charge, InvoiceItem, and Recipient objects, and the email property on Customer and Recipient objects, to be set to null by providing empty string values in POST requests.

2013-07-05

• MajorReplaces the active_card property on the Customer object with a cards sublist and a default_card ID property.

2013-02-13

• Updates the Charge object so disputed charges include another stripe_fee object in the fee_details array, representing the dispute fees. Includes the dispute fees in the fee total on the Charge object.

2013-02-11

• MajorUpdates the pay invoice call to return an error when the charge is not successful. Previously, the API would return a 200 status and set the invoice’s paid property to false.

2012-11-07

• Replaces the disputed property on the Charge object with dispute.

2012-10-26

• Updates the Invoice object format. The lines property is now a sublist, a paginated list of all items that contribute to the invoice.

2012-09-24

• Removes the extraneous id property from the Discount object.

2012-07-09

• Removes the uncaptured property from the Customer object.

2012-06-28

• (Changes introduced in this version have since been removed.)

2012-06-18

• Removes the amount and currency properties from the Token object.

2012-03-25

• Removes the next_recurring_charge property from the Customer object. Use the upcoming invoice call instead.

2012-02-23

• Shows all response fields, even those with null values. Previously, the API hid fields with null values.

2011-11-17

• (Changes introduced in this version have since been removed.)

2011-09-15

• Updates the card validation behavior when creating tokens.

2011-08-01

• Updates the list format. New list objects have a data property that represents an array of objects (by default, 10) and a count property that represents the total count.

2011-06-28

• Removes the identifier property (duplicate of id) from the Plan object.

2011-06-21

• Raises exceptions on unrecognized parameters passed to the API instead of silently allowing and ignoring them.