Package com.stripe.service

Class SubscriptionService

java.lang.Object
com.stripe.net.ApiService
com.stripe.service.SubscriptionService
public final class SubscriptionService extends ApiService

  • Constructor Details

  • Method Details

    • cancel

      public Subscription cancel(String subscriptionExposedId, SubscriptionCancelParams params) throws StripeException
      Cancels a customer’s subscription immediately. The customer will not be charged again for the subscription.

      Note, however, that any pending invoice items that you’ve created will still be charged for at the end of the period, unless manually deleted. If you’ve set the subscription to cancel at the end of the period, any pending prorations will also be left in place and collected at the end of the period. But if the subscription is set to cancel immediately, pending prorations will be removed.

      By default, upon subscription cancellation, Stripe will stop automatic collection of all finalized invoices for the customer. This is intended to prevent unexpected payment attempts after the customer has canceled a subscription. However, you can resume automatic collection of the invoices manually after subscription cancellation to have us proceed. Or, you could check for unpaid invoices before allowing the customer to cancel the subscription at all.

      Throws:
      StripeException

    • cancel

      public Subscription cancel(String subscriptionExposedId, RequestOptions options) throws StripeException
      Cancels a customer’s subscription immediately. The customer will not be charged again for the subscription.

      Note, however, that any pending invoice items that you’ve created will still be charged for at the end of the period, unless manually deleted. If you’ve set the subscription to cancel at the end of the period, any pending prorations will also be left in place and collected at the end of the period. But if the subscription is set to cancel immediately, pending prorations will be removed.

      By default, upon subscription cancellation, Stripe will stop automatic collection of all finalized invoices for the customer. This is intended to prevent unexpected payment attempts after the customer has canceled a subscription. However, you can resume automatic collection of the invoices manually after subscription cancellation to have us proceed. Or, you could check for unpaid invoices before allowing the customer to cancel the subscription at all.

      Throws:
      StripeException

    • cancel

      public Subscription cancel(String subscriptionExposedId) throws StripeException
      Cancels a customer’s subscription immediately. The customer will not be charged again for the subscription.

      Note, however, that any pending invoice items that you’ve created will still be charged for at the end of the period, unless manually deleted. If you’ve set the subscription to cancel at the end of the period, any pending prorations will also be left in place and collected at the end of the period. But if the subscription is set to cancel immediately, pending prorations will be removed.

      By default, upon subscription cancellation, Stripe will stop automatic collection of all finalized invoices for the customer. This is intended to prevent unexpected payment attempts after the customer has canceled a subscription. However, you can resume automatic collection of the invoices manually after subscription cancellation to have us proceed. Or, you could check for unpaid invoices before allowing the customer to cancel the subscription at all.

      Throws:
      StripeException

    • cancel

      public Subscription cancel(String subscriptionExposedId, SubscriptionCancelParams params, RequestOptions options) throws StripeException
      Cancels a customer’s subscription immediately. The customer will not be charged again for the subscription.

      Note, however, that any pending invoice items that you’ve created will still be charged for at the end of the period, unless manually deleted. If you’ve set the subscription to cancel at the end of the period, any pending prorations will also be left in place and collected at the end of the period. But if the subscription is set to cancel immediately, pending prorations will be removed.

      By default, upon subscription cancellation, Stripe will stop automatic collection of all finalized invoices for the customer. This is intended to prevent unexpected payment attempts after the customer has canceled a subscription. However, you can resume automatic collection of the invoices manually after subscription cancellation to have us proceed. Or, you could check for unpaid invoices before allowing the customer to cancel the subscription at all.

      Throws:
      StripeException

    • retrieve

      public Subscription retrieve(String subscriptionExposedId, SubscriptionRetrieveParams params) throws StripeException
      Retrieves the subscription with the given ID.
      Throws:
      StripeException

    • retrieve

      public Subscription retrieve(String subscriptionExposedId, RequestOptions options) throws StripeException
      Retrieves the subscription with the given ID.
      Throws:
      StripeException

    • retrieve

      public Subscription retrieve(String subscriptionExposedId) throws StripeException
      Retrieves the subscription with the given ID.
      Throws:
      StripeException

    • retrieve

      public Subscription retrieve(String subscriptionExposedId, SubscriptionRetrieveParams params, RequestOptions options) throws StripeException
      Retrieves the subscription with the given ID.
      Throws:
      StripeException

    • update

      public Subscription update(String subscriptionExposedId, SubscriptionUpdateParams params) throws StripeException
      Updates an existing subscription to match the specified parameters. When changing prices or quantities, we optionally prorate the price we charge next month to make up for any price changes. To preview how the proration is calculated, use the upcoming invoice endpoint.

      By default, we prorate subscription changes. For example, if a customer signs up on May 1 for a 100 price, they’ll be billed 100 immediately. If on May 15 they switch to a 200 price, then on June 1 they’ll be billed 250 (200 for a renewal of her subscription, plus a 50 prorating adjustment for half of the previous month’s 100 difference). Similarly, a downgrade generates a credit that is applied to the next invoice. We also prorate when you make quantity changes.

      Switching prices does not normally change the billing date or generate an immediate charge unless:

      • The billing interval is changed (for example, from monthly to yearly).
      • The subscription moves from free to paid, or paid to free.
      • A trial starts or ends.

      In these cases, we apply a credit for the unused time on the previous price, immediately charge the customer using the new price, and reset the billing date.

      If you want to charge for an upgrade immediately, pass proration_behavior as always_invoice to create prorations, automatically invoice the customer for those proration adjustments, and attempt to collect payment. If you pass create_prorations, the prorations are created but not automatically invoiced. If you want to bill the customer for the prorations before the subscription’s renewal date, you need to manually invoice the customer.

      If you don’t want to prorate, set the proration_behavior option to none. With this option, the customer is billed 100 on May 1 and 200 on June 1. Similarly, if you set proration_behavior to none when switching between different billing intervals (for example, from monthly to yearly), we don’t generate any credits for the old subscription’s unused time. We still reset the billing date and bill immediately for the new subscription.

      Updating the quantity on a subscription many times in an hour may result in rate limiting. If you need to bill for a frequently changing quantity, consider integrating usage-based billing instead.

      Throws:
      StripeException

    • update

      public Subscription update(String subscriptionExposedId, RequestOptions options) throws StripeException
      Updates an existing subscription to match the specified parameters. When changing prices or quantities, we optionally prorate the price we charge next month to make up for any price changes. To preview how the proration is calculated, use the upcoming invoice endpoint.

      By default, we prorate subscription changes. For example, if a customer signs up on May 1 for a 100 price, they’ll be billed 100 immediately. If on May 15 they switch to a 200 price, then on June 1 they’ll be billed 250 (200 for a renewal of her subscription, plus a 50 prorating adjustment for half of the previous month’s 100 difference). Similarly, a downgrade generates a credit that is applied to the next invoice. We also prorate when you make quantity changes.

      Switching prices does not normally change the billing date or generate an immediate charge unless:

      • The billing interval is changed (for example, from monthly to yearly).
      • The subscription moves from free to paid, or paid to free.
      • A trial starts or ends.

      In these cases, we apply a credit for the unused time on the previous price, immediately charge the customer using the new price, and reset the billing date.

      If you want to charge for an upgrade immediately, pass proration_behavior as always_invoice to create prorations, automatically invoice the customer for those proration adjustments, and attempt to collect payment. If you pass create_prorations, the prorations are created but not automatically invoiced. If you want to bill the customer for the prorations before the subscription’s renewal date, you need to manually invoice the customer.

      If you don’t want to prorate, set the proration_behavior option to none. With this option, the customer is billed 100 on May 1 and 200 on June 1. Similarly, if you set proration_behavior to none when switching between different billing intervals (for example, from monthly to yearly), we don’t generate any credits for the old subscription’s unused time. We still reset the billing date and bill immediately for the new subscription.

      Updating the quantity on a subscription many times in an hour may result in rate limiting. If you need to bill for a frequently changing quantity, consider integrating usage-based billing instead.

      Throws:
      StripeException

    • update

      public Subscription update(String subscriptionExposedId) throws StripeException
      Updates an existing subscription to match the specified parameters. When changing prices or quantities, we optionally prorate the price we charge next month to make up for any price changes. To preview how the proration is calculated, use the upcoming invoice endpoint.

      By default, we prorate subscription changes. For example, if a customer signs up on May 1 for a 100 price, they’ll be billed 100 immediately. If on May 15 they switch to a 200 price, then on June 1 they’ll be billed 250 (200 for a renewal of her subscription, plus a 50 prorating adjustment for half of the previous month’s 100 difference). Similarly, a downgrade generates a credit that is applied to the next invoice. We also prorate when you make quantity changes.

      Switching prices does not normally change the billing date or generate an immediate charge unless:

      • The billing interval is changed (for example, from monthly to yearly).
      • The subscription moves from free to paid, or paid to free.
      • A trial starts or ends.

      In these cases, we apply a credit for the unused time on the previous price, immediately charge the customer using the new price, and reset the billing date.

      If you want to charge for an upgrade immediately, pass proration_behavior as always_invoice to create prorations, automatically invoice the customer for those proration adjustments, and attempt to collect payment. If you pass create_prorations, the prorations are created but not automatically invoiced. If you want to bill the customer for the prorations before the subscription’s renewal date, you need to manually invoice the customer.

      If you don’t want to prorate, set the proration_behavior option to none. With this option, the customer is billed 100 on May 1 and 200 on June 1. Similarly, if you set proration_behavior to none when switching between different billing intervals (for example, from monthly to yearly), we don’t generate any credits for the old subscription’s unused time. We still reset the billing date and bill immediately for the new subscription.

      Updating the quantity on a subscription many times in an hour may result in rate limiting. If you need to bill for a frequently changing quantity, consider integrating usage-based billing instead.

      Throws:
      StripeException

    • update

      public Subscription update(String subscriptionExposedId, SubscriptionUpdateParams params, RequestOptions options) throws StripeException
      Updates an existing subscription to match the specified parameters. When changing prices or quantities, we optionally prorate the price we charge next month to make up for any price changes. To preview how the proration is calculated, use the upcoming invoice endpoint.

      By default, we prorate subscription changes. For example, if a customer signs up on May 1 for a 100 price, they’ll be billed 100 immediately. If on May 15 they switch to a 200 price, then on June 1 they’ll be billed 250 (200 for a renewal of her subscription, plus a 50 prorating adjustment for half of the previous month’s 100 difference). Similarly, a downgrade generates a credit that is applied to the next invoice. We also prorate when you make quantity changes.

      Switching prices does not normally change the billing date or generate an immediate charge unless:

      • The billing interval is changed (for example, from monthly to yearly).
      • The subscription moves from free to paid, or paid to free.
      • A trial starts or ends.

      In these cases, we apply a credit for the unused time on the previous price, immediately charge the customer using the new price, and reset the billing date.

      If you want to charge for an upgrade immediately, pass proration_behavior as always_invoice to create prorations, automatically invoice the customer for those proration adjustments, and attempt to collect payment. If you pass create_prorations, the prorations are created but not automatically invoiced. If you want to bill the customer for the prorations before the subscription’s renewal date, you need to manually invoice the customer.

      If you don’t want to prorate, set the proration_behavior option to none. With this option, the customer is billed 100 on May 1 and 200 on June 1. Similarly, if you set proration_behavior to none when switching between different billing intervals (for example, from monthly to yearly), we don’t generate any credits for the old subscription’s unused time. We still reset the billing date and bill immediately for the new subscription.

      Updating the quantity on a subscription many times in an hour may result in rate limiting. If you need to bill for a frequently changing quantity, consider integrating usage-based billing instead.

      Throws:
      StripeException

    • deleteDiscount

      public Discount deleteDiscount(String subscriptionExposedId) throws StripeException
      Removes the currently applied discount on a subscription.
      Throws:
      StripeException

    • deleteDiscount

      public Discount deleteDiscount(String subscriptionExposedId, RequestOptions options) throws StripeException
      Removes the currently applied discount on a subscription.
      Throws:
      StripeException

    • list

      public StripeCollection<Subscription> list(SubscriptionListParams params) throws StripeException
      By default, returns a list of subscriptions that have not been canceled. In order to list canceled subscriptions, specify status=canceled.
      Throws:
      StripeException

    • list

      public StripeCollection<Subscription> list(RequestOptions options) throws StripeException
      By default, returns a list of subscriptions that have not been canceled. In order to list canceled subscriptions, specify status=canceled.
      Throws:
      StripeException

    • list

      public StripeCollection<Subscription> list() throws StripeException
      By default, returns a list of subscriptions that have not been canceled. In order to list canceled subscriptions, specify status=canceled.
      Throws:
      StripeException

    • list

      public StripeCollection<Subscription> list(SubscriptionListParams params, RequestOptions options) throws StripeException
      By default, returns a list of subscriptions that have not been canceled. In order to list canceled subscriptions, specify status=canceled.
      Throws:
      StripeException

    • create

      public Subscription create(SubscriptionCreateParams params) throws StripeException
      Creates a new subscription on an existing customer. Each customer can have up to 500 active or scheduled subscriptions.

      When you create a subscription with collection_method=charge_automatically, the first invoice is finalized as part of the request. The payment_behavior parameter determines the exact behavior of the initial payment.

      To start subscriptions where the first invoice always begins in a draft status, use subscription schedules instead. Schedules provide the flexibility to model more complex billing configurations that change over time.

      Throws:
      StripeException

    • create

      public Subscription create(SubscriptionCreateParams params, RequestOptions options) throws StripeException
      Creates a new subscription on an existing customer. Each customer can have up to 500 active or scheduled subscriptions.

      When you create a subscription with collection_method=charge_automatically, the first invoice is finalized as part of the request. The payment_behavior parameter determines the exact behavior of the initial payment.

      To start subscriptions where the first invoice always begins in a draft status, use subscription schedules instead. Schedules provide the flexibility to model more complex billing configurations that change over time.

      Throws:
      StripeException

    • search

      public StripeSearchResult<Subscription> search(SubscriptionSearchParams params) throws StripeException
      Search for subscriptions you’ve previously created using Stripe’s Search Query Language. Don’t use search in read-after-write flows where strict consistency is necessary. Under normal operating conditions, data is searchable in less than a minute. Occasionally, propagation of new or updated data can be up to an hour behind during outages. Search functionality is not available to merchants in India.
      Throws:
      StripeException

    • search

      public StripeSearchResult<Subscription> search(SubscriptionSearchParams params, RequestOptions options) throws StripeException
      Search for subscriptions you’ve previously created using Stripe’s Search Query Language. Don’t use search in read-after-write flows where strict consistency is necessary. Under normal operating conditions, data is searchable in less than a minute. Occasionally, propagation of new or updated data can be up to an hour behind during outages. Search functionality is not available to merchants in India.
      Throws:
      StripeException

    • resume

      public Subscription resume(String subscription, SubscriptionResumeParams params) throws StripeException
      Initiates resumption of a paused subscription, optionally resetting the billing cycle anchor and creating prorations. If a resumption invoice is generated, it must be paid or marked uncollectible before the subscription will be unpaused. If payment succeeds the subscription will become active, and if payment fails the subscription will be past_due. The resumption invoice will void automatically if not paid by the expiration date.
      Throws:
      StripeException

    • resume

      public Subscription resume(String subscription, RequestOptions options) throws StripeException
      Initiates resumption of a paused subscription, optionally resetting the billing cycle anchor and creating prorations. If a resumption invoice is generated, it must be paid or marked uncollectible before the subscription will be unpaused. If payment succeeds the subscription will become active, and if payment fails the subscription will be past_due. The resumption invoice will void automatically if not paid by the expiration date.
      Throws:
      StripeException

    • resume

      public Subscription resume(String subscription) throws StripeException
      Initiates resumption of a paused subscription, optionally resetting the billing cycle anchor and creating prorations. If a resumption invoice is generated, it must be paid or marked uncollectible before the subscription will be unpaused. If payment succeeds the subscription will become active, and if payment fails the subscription will be past_due. The resumption invoice will void automatically if not paid by the expiration date.
      Throws:
      StripeException

    • resume

      public Subscription resume(String subscription, SubscriptionResumeParams params, RequestOptions options) throws StripeException
      Initiates resumption of a paused subscription, optionally resetting the billing cycle anchor and creating prorations. If a resumption invoice is generated, it must be paid or marked uncollectible before the subscription will be unpaused. If payment succeeds the subscription will become active, and if payment fails the subscription will be past_due. The resumption invoice will void automatically if not paid by the expiration date.
      Throws:
      StripeException