Powr Pricing DB side

1 How subscription is being created 2 How transactions are being performed 3 Credits 4 Discounts

1 How subscription is being created

System has 2 type of subscriptions: Pro subscriptions and App subscriptions. Pro subscription is app_type based, so it affects all the apps with the same app_type, subscription is created in pro_subscriptions table. App subscription is app based, it is old and system won't create new ones any more, but it supports active ones. Subscriptions are stored in app_subscriptions table

Pro_subscription table:

id: integer
credit_card_id: integer - id from credit_cards table, basically it is a payment method information that      user used during purchase of subscription
price: Price of subscription, should never ever be 0, because this is the price that system uses for    creating transactions if promo_price is null. Price should be regular price without any discounts or   credit subscriptions. Price could be for monthly/yearly/2yr regular price only.
created_at: subscription created time
updated_at: subscription updated time
active: TRUE/FALSE status of subscription, Active subscription refers to paid subscription, Inactive subscriptions could be expired subscriptions and subscriptions that will be activated in the future accordingly to to_activate_at field 
last_invoice: is not used
level: Premium(Starter for user display)/Pro/Enterprise(Business for user display)

       Premium subscription - could be applied to one app_type apps
       Pro subscription - could be applied to one app_type apps
       Enterprise subscription - all app_type apps get upgraded if user purchases this type of subscription

subscription_type: refers to period: monthly/yearly/biennially
user_id: user that purchased subscription (user data is saved in users table)
downgraded_at: is filled by downgrade_pending_subscriptions worker when to_downgrade_at  < today
promo_price: if user has discount/credit this filed is filled with promotional price. Exp: regular price for FormBuilder Premium Monthly subscription is $8.99, but if user has discount 50% off for 3 months then promo_price = $4.49, transaction workers will charge this amount until promo_end field is > today. In this example promo_end will br purchased_time+3.month
promo_end: valid time for promo_price
app_type: purchased app_type, exception is for Enterprise, even user purchases as example Popup

Enterprise subscription, user will get full pack of POWr apps Enterprise level

to_downgrade_at:  is filled only if user/TSH cancels subscription, usually subscriptions valid until end of the subscription_type. Exp: user purchases monthly subscription 10th November and cancels it on 20th Nov, system updates to_downgrade_at to 10th of December, so user is able to use subscription until that time. When downgrade time comes system updates active field to FALSE and downgraded_at time with downgrade_pending_subscriptions worker.
to_activate_at: time of subscription activation date. Exp: User purchased monthly Pro subscription, but then changed mind and decided to downgrade to monthly Premium. System will keep Pro subscription until end of the month

After creating pro_subscription record (pro_subscriptions_controller) system will create records in credit_cards and transactions tables. Credit_cards store payment method used for subscription. 2 Transactions: Transactions stored in transactions table.

status => "charged" applied when price >0 and credit card is charged successfully 
          "pending" applied to transactions when it is just created
          "ignored" applied when user pays $0, if only user has discount/credit

Transactions are created in reconcile_payments.rb, method create_charge

3 Credits User can be assigned credits at: 1 by support at https://powr.io/admin/tech_support_helper (max $50, multiple times) 2 by referring other users https://www.powr.io/users/me/account?tab=referralProgram (max $10 for each upgraded user) 3 when user gives feedback for app at standalone https://www.powr.io/plugins/form-builder/standalone?id=17622965&&publish=rewards (max $5 one time only) 4 emails

Credits are stored in user_credits table.

  id: credit id
  user_id: credit assigned user
  referred_user_id: user who referred this user
  active:  status of credit TRUE/FALSE
  amount: credit amount
  assigned_user_id: user who manually assigned credit to user (could be support agent or user him/her self at rewards)
 credit_type: how credit was applied
 valid_until: credir expire time 

If credit is used or reserved for future payments it will be recorded in credit_pro_subscription_transactions table

 credit_id: credit id from user_credits table 
 pro_subscription_id: subscription id from pro_subscriptions table, will be filled when credit is reserved for particular subscription 
 transaction_id: transaction id, will be filled when credit user for particular transaction.

Credits are handled in pro_subscription.rb

4 Discounts Discounts are stored in subscription_discount table and assigned to user at user_notifications table.