CreateSubscription is the single action responsible for provisioning a new billing relationship between a billable and a plan. When you call it — whether through the facade or directly — it contacts the configured gateway to create the subscription record there, then persists a Subscription model in your database. The package fires a SubscriptionCreated event after both operations complete successfully.
Calling styles
- Facade
- Direct action
The fluent facade is the recommended approach for most application code.
Subscribd::for($billable) returns a BillableContext, and subscribe() delegates to CreateSubscription internally.Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
$billable | Billable | Yes | The model being subscribed (e.g., User, Team) |
$plan | Plan | Yes | The resolved Plan model to subscribe to |
$options | array | No | Additional options (see below) |
Options array
| Key | Type | Default | Description |
|---|---|---|---|
name | string | 'default' | Subscription slot name — allows a billable to hold multiple subscriptions |
quantity | int | 1 | Number of seats or units (used for per_unit plans) |
Return value
CreateSubscription::execute() returns the newly created Subscription model, already persisted and loaded with its plan relationship.
Multiple named subscriptions
A single billable can hold multiple independent subscriptions by using differentname values. This is the recommended pattern when you sell add-on plans separately from a base plan.
The subscription
name is how Subscribd identifies which slot you are operating on in subsequent calls like swap(), cancel(), and resume().Events fired
SubscriptionCreated is dispatched after the subscription is persisted. Listen to it in EventServiceProvider to trigger onboarding workflows, send welcome emails, or provision resources.
Gateway override
To create the subscription on a specific gateway instead of the configured default, chain->on() before subscribe() when using the facade.