Reputation: 4056
Scenario: I have a User
that has the option to subscribe to a plan (SaaS) to create a number of Posts
but also has the option to make a one time payment to create a Post
without subscribing.
I have trouble understanding how many controllers/models I need and if I should associate them to the post or to the user. Of course a Post
belongs to a User
.
Should I have a payments model and controller for single payments and a subscriptions controller/model? or is it more logical to have one Payment controller/model with a field :subscription for when the User chooses the subscription model?
Also, do I even need a model for payments since they are stored in stripe?
My credit card form would be the same for subscriptions and single payments so which model should I associate it with? or should I do a model-less form?
Thank you for any clarifications on the design.
Upvotes: 0
Views: 141
Reputation: 76774
It's not a question of stripe - it's about your system's structure
Rails
Although your payments details are stored in Stripe, you need to record & track them in Rails. This is especially true if you're handling payment plans, etc -- you need to be able to track whether someone's actually paid or not
This can only be done with Rails (I.E storing the time someone paid, etc)
Code
I'd do it like this (verrrrry basic):
#app/models/payment.rb
Class Payment < ActiveRecord::Base
belongs_to :user
end
#app/models/user.rb
Class User < ActiveRecord::Base
belongs_to :payment_plan
has_many :payments
end
#app/models/payment_plan.rb
Class PaymentPlan < ActiveRecord::Base
has_many :users
end
#app/controllers/payments_controller.rb
def new
#Order Page
end
def create
#Payment process / page
end
Schemas
users
id | payment_plan_id | created_at | updated_at
payments
id | user_id | created_at | updated_at
payment_plans
id | name | frequency | etc
Upvotes: 1