Ayrad
Ayrad

Reputation: 4056

Stripe rails design choice

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

Answers (1)

Richard Peck
Richard Peck

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

Related Questions