Migrate App Subscriptions

SPECS:

Scenario: User has one app_subscription

Given a user has just one active app_subscription

Then the user should have that app_subscription cancelled

And a new pro_subscription is immediately created

And the new pro_subscription's level should be Premium

And the new pro_subscription will have the same created_at date, app_type, subscription_type, promo_price, promo_end, to_downgrade_at and price as the previous app_subscription

(This means that all of the apps of that app_type in the user's account should show a premium_status of 'premium')

Scenario: User has multiple app_subscriptions for the same app_type with same subscription_type

Given a user has more than one active app_subscription for the same app_type

Then the user should have all of those app_subscriptions cancelled

And a new pro_subscription is immediately created

And the new pro_subscription's level should be Premium

And the new pro_subscription will have the same app_type, promo_price, promo_end, to_downgrade_at and subscription_type as the previous app_subscription

And the new pro_subscription will have use the earliest created_at date from the downgraded subscriptions as its created_at date

And the new pro_subscription's price is the sum of the downgraded app_subscriptions but no more than the current Premium price of a pro_subscription for that app_type

Example:

• User has 3 app subscriptions for Form Builder at $3.99/mo
• 3 * 3.99 = 11.97 => 11.97 > 8.99 so we'll use $8.99
• Moving forward the user will be paying $8.99/mo for one pro_subscription with the app_type Form Builder

Scenario: User has multiple app_subscriptions for the same app_type with different subscription_type

Given a user has more than one active app_subscription for the same app_type

Then the user should have all of those app_subscriptions cancelled

And a new pro_subscription is immediately created

And the new pro_subscription's level should be Premium

And the new pro_subscription will have the same app_type as the previous app_subscription

And the new pro_subscription will have use the earliest created_at date from the downgraded subscriptions as its created_at date

And the new pro_subscription will use whichever subscriprion_type is highest as its subscription_type

And the new prosubscription's price is the sum of the downgraded app_subscriptions’ _monthly price x 12 but no more than the current Premium price of a pro_subscription for that app_type

Example:

• User has 1 monthly app subscriptions for Form Builder at $3.99/mo
• User has 1 yearly app subscription for Form Builder at $43.09/yr
• 3.99 x 12 - 10% + 43.09 = $86.18 => $86.18 < $97.09 (current price) so we'll use $86.18/year
• Moving forward the user will be paying $86.18/year for one pro_subscription with the app_type Form Builder

Scenario: User has multiple app_subscriptions for multiple app_types

Given a user has more than one active app_subscription for different app_types

Then the user should have all of those app_subscriptions cancelled

And a new pro_subscription is immediately created for each app_type using the same created_at date, level, subscription_type, and price as the downgraded app_subscription

Scenario: User should not receive any emails regarding their subscription change

Given a user was migrated from an app_subscription to a pro_subscription

Then the user should not receive any emails confirming their app_subscription cancellation

And the user should not receive any emails confirming their new pro_subscription

Scenario: Subscription transfer is documented in Admin Note

Given an app_subscription is transferred to a pro_subscription

When the subscription has successfully migrated

Then we add a row to the AdminNotes table saying, “App Subscription [id] transferred to Pro Subscription [id]”

Scenario: Subscription transfer is documented in CancelFeedback

Given an app_subscription is transferred to a pro_subscription

When the subscription has successfully migrated

And the app_subscription has been cancelled

Then we add a row to the CancelFeedback table with the reason “Automatic downgrade because of subscription transfer”

Scenario: User visits POWr account dashboard

Given a user logs into powr.io

When the user navigates to “My Account” > “My Subscriptions”

Then the user should not see any active or inactive app_subscriptions listed

And the user will only see their active and inactive pro_subscriptions

And the user can still access invoices for app-subscriptions via the Billing History tab

Scenario: Transaction for active app_subscription is pending

Given an app_subscription is transferred to a pro_subscription

When the original app_subscription has any pending transactions

Then the subscription ID for the associated subscription should be updated in the transaction table

And use the ID of the new pro_subscription for the next payment attempt

Scenario: User has multiple credit cards on file

Given a user has multiple has multiple credit cards saved to their POWr user account

And the user’s app_subscription is being transferred to a pro_subscription

When the user’s subscription renews

Then the new default credit card used for the transaction should be the one that most recently had a successful charge