Question: Why certain billable fields are added to the model, apart from processor and processor_id?

[doutatsu]

I was curious what is the need for adding fields apart from processor and processor_id, when running rails g pay User? I understand the need for those, as we need to store Stripe customer id, but isn't having subscriptions and charges tables is enough for the rest of the fields?

When subscribing, card details and trial info are stored on the other tables, but not on the user. only processor and processor_id are changed.

class AddPayBillableToUsers < ActiveRecord::Migration[6.1]
  def change
    change_table :users, bulk: true do |t|
      t.string :processor
      t.string :processor_id
      t.datetime :trial_ends_at
      t.string :card_type
      t.string :card_last4
      t.string :card_exp_month
      t.string :card_exp_year
      t.text :extra_billing_info
    end
  end
end

Hence I've been wondering if it's safe to remove all, but processor and processor_id from the users?

[excid3]

• Trials without a card require trial_ends_at
• VAT information is stored in extra_billing_info for EU customers and is applied to all receipts
• Card details are stored so we know what the default card that would be used on a new subscription if you didn't enter a new one.

[doutatsu]

Card details are stored so we know what the default card that would be used on a new subscription if you didn't enter a new one.

In which case would it get stored exactly? When I went through checkout to setup a subscription, card details got saved on charges, but not on the user itself. But makes sense for the other cases you mentioned

I suppose I shouldn't worry about it and just make a separate model to make a billable, as my issue here was just having too many fields on the User itself

[excid3]

Using Stripe Checkout for a subscription won't set the default card on the Stripe Customer, as far as I know. It just sets the payment method for the subscription itself.

Pay isn't really made for that situation at the moment, which is why we're going to add a PaymentMethod model to keep track of all the payment methods.

[doutatsu]

Sorry, I lost you - what specific situation? In my case, I am just using Pay for subscriptions -> setup a subscription through checkout and then using billing portal for any management, that's about it. For which it seems to work just fine as far as I can tell so far

[excid3]

Checkout won't set the Customer's default payment method afaik. It just sets the payment method for the subscription.

[doutatsu]

Ah, right, I've noticed that. But that's not a huge issue, the subscription would still be renewed correctly, as a card is associated with a subscription. The only issue, is that the person would need to type in their card details again, if they want to subscribe to something else, for example?

[excid3]

There is this under the customer docs for Stripe Checkout Sessions: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer

You can set payment_intent_data.setup_future_usage to have Checkout automatically attach the payment method to the Customer you pass in for future reuse.

It doesn't seem like that would set it as default, but you would at least have it saved on the Stripe Customer. Then you could set the default card on the checkout completed webhook I guess.

And I don't know much about this, but Link with Stripe works like Shop Pay from Shopify where you can have your card saved. https://support.stripe.com/questions/using-link-with-stripe-to-save-your-payment-information