Grant access with 4 vendor start rules before day one

• Stripe: Grant access using the customer's active entitlements, according to Stripe.
• Paddle: Sync your app with Paddle using webhooks and decide what access to grant based on the subscription state, according to Paddle.
• Recurly: A future start date means the customer is not invoiced until that date, according to Recurly.
• Chargebee: An invoice is generated on the date and time the subscription status changes to Active, according to Chargebee.

Understanding subscription statuses helps you know when to provision access, notify customers, and handle errors, according to Stripe. This guidance applies specifically to the statuses named in that documentation.

The core rule for your workflow is that the start condition on the vendor's page defines when access begins. Record creation is a data event, not a trigger for product access. You must verify the specific status or date condition listed on the vendor's page before enabling the customer's access. See the onboarding checklist.

For example, if a vendor's page states that access begins when a subscription status changes to a specific value, you wait for that status change. If the page states that access begins on a specific future date, you wait for that date. The moment you create the subscription record in the system does not automatically turn on the product.

Write the customer's start date next to the start sentence on that vendor's row before you turn access on. This ensures you are following the documented condition rather than assuming access is active upon record creation.

Check the vendor's documentation for the specific status or date that triggers access. Do not assume that creating the record activates the service. Use the start condition stated on the page as the sole trigger for enabling access.

When a customer accesses your services, use their active entitlements to grant them access to the features included in their subscription, according to Stripe. This instruction appears on the page titled "How subscriptions work | Stripe Documentation." It directs the customer success manager to look at the customer’s active entitlements at the moment of access. The entitlements define which features are included in the subscription. You do not grant access based on the moment the record is created. You grant access based on the features listed in the active entitlements.

The Subscription object includes a list of up to 20 subscription items, each with an attached price, according to Stripe. This limit appears on the page titled "The Subscription object | Stripe API Reference." The number 20 is a specific constraint on the subscription items within the object. It is not a limit on the number of customers or the duration of the contract. It is a structural limit on the items that can be attached to a single subscription object.

When you prepare to turn on access for a new customer, check the entitlements first. See Onboarding tools: compare 4 customer project plans. The entitlements tell you what the customer has purchased. The subscription items list tells you how many distinct items are attached to that subscription. If you are building a system that checks access, it should query the active entitlements. It should not assume that creating the subscription record automatically enables all features. The page explicitly says to use active entitlements to grant access. This means your access control logic must read the entitlements. It must not rely on the existence of the subscription record alone.

When a subscription record exists, do not assume the product is live. The page titled "Provision access and handle subscription state" directs you to use webhooks to keep your app in sync with Paddle, then decide what access to grant based on subscription state according to Paddle. This instruction separates the creation of the billing record from the activation of your software. You must wait for the state signal before enabling features.

The specific data you need to store is defined in the same guidance. Save the customer and subscription IDs against your user, and grant access according to Paddle. This step links the billing identity to the specific user account in your system. Without these IDs, you cannot verify which subscription state applies to which person. The instruction is explicit about what to save and what action follows that save.

Access is not a one-time switch. The page addresses what happens when the subscription state changes after the initial grant. Where subscriptions are paused or canceled, limit or stop access to your app according to Paddle. This rule covers the lifecycle beyond the first day. If a scheduled change is set, keep access until it takes effect, according to Paddle.

Your implementation should treat the subscription state as the single source of truth for access levels. Do not rely on manual updates or static flags. The webhook mechanism keeps your app in sync with Paddle, ensuring your access logic matches the current billing reality. This approach prevents the common error of granting access based on a record that was created but not yet activated or that has since been paused.

When a subscription record shows a future start date, the billing cycle has not yet begun. According to Recurly, future subscriptions have a start date in the future. This specific date marks the beginning of the billing period. The customer is not invoiced until the start date, as stated in the same documentation. It is a scheduling parameter for the first invoice, and the Recurly page does not decide product access. If you turn on product access before this date, you are acting on a decision that the Recurly page does not make for you. The page only says the customer is not invoiced until the start date.

For Chargebee, the trigger for billing is a status change. According to Chargebee, an invoice will be generated on the date/time the subscription status changes to Active. The status change is the event that initiates the invoice. The page does not describe what happens to product access when this status change occurs. It defines the billing event. If your internal process ties access to the "Active" status, you are building a rule that the Chargebee documentation does not state. The documentation states that the invoice is generated at that moment. It does not state that access turns on at that moment.

The difference between these two vendors is the nature of the trigger. Recurly uses a calendar date. Chargebee uses a status change. In both cases, the vendor page defines the billing event. Neither page defines the access event. Your job is to separate these two concepts. When you see a future start date in Recurly, note that no invoice will be sent until that date. When you see a status change to Active in Chargebee, note that an invoice will be generated at that time. These are billing facts. They are not access facts.

The documentation pages for these billing vendors do not instruct you to turn on product access when a subscription record is created. The start conditions are specific to the vendor's stated rules, not a universal trigger based on record creation. You must verify the exact condition on the vendor's page before enabling access.

Do not interpret the "three year question" found on the Chargebee page as a required contract length or a rule that mandates a three-year commitment for all subscriptions. The page asks, "How do I set up a 3-year subscription with annual billing in Chargebee?" according to Chargebee. Treat this as a specific inquiry about setup mechanics, not a universal requirement that defines when access turns on.

Similarly, do not treat the "history question" regarding fetching data more than 12 months old as an onboarding milestone or a limit on how long a customer can remain active. The page asks, "How to fetch historical subscription data that is more than 12 months data old?" according to Chargebee. Using this as a benchmark for when to turn on or off access misapplies the question, which addresses data retrieval rather than access timing.

This illustrative sheet has 4 rows and no company name. Each row gets 1 start sentence and 1 start date written beside it. Row 1 uses the status at access to decide features. Row 2 waits for a state signal and keeps access until a scheduled change takes effect. Row 3 keeps the first invoice waiting while the start date is still ahead. Row 4 marks the status change as the invoice time only. Turn access on only for a row that already has both the sentence and the date.

Open the vendor page and write the customer's start date next to the start sentence before you turn access on.

What does Paddle say to save when a subscription is created?

Save the customer and subscription IDs against your user, and grant access, according to Paddle.

What does Recurly say about the first invoice on a future start?

The customer is not invoiced until that start date, according to Recurly. The most common use case for a future subscription is a B2B contract where the subscription is agreed to start on a specific date, according to Recurly.

What does Chargebee say happens when the status changes to Active?

An invoice will be generated on the date/time the subscription status changes to Active. This is a billing event, not a statement that product access turns on, according to Chargebee.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.