CreditCard

Attributes

Create

[:billing_address, :cardholder_name, :customer_id, :expiration_date, :expiration_month, :expiration_year, :number, :cvv, :options, :token]

Update

[:billing_address, :cardholder_name, :expiration_date, :expiration_month, :expiration_year, :options]

Readonly

[
  :bin, :card_type, :commercial, :country_of_issuance, :created_at, :debit, :durbin_regulated,
  :healthcare, :issuing_bank, :last_4, :payroll, :prepaid, :unique_number_identifier, :updated_at
]

Associations

Customer

credit_card = BraintreeRails::CreditCard.find('credit_card_id')
credit_card.customer # Loaded from customer_id for persisted addresses.

Transactions

credit_card = BraintreeRails::CreditCard.find('credit_card_id')
credit_card.transactions # lazy loaded collection through Braintree::Transaction.search
transaction = credit_card.transactions.build(:amount => '10.00') # initialize a transaction ready to be created using the vaulted card
transaction = credit_card.transactions.create(:amount => '11.00') # create a transaction using the vaulted card

Subscriptions

credit_card = BraintreeRails::CreditCard.find('credit_card_id')
credit_card.subscriptions # lazy loaded collection through Braintree::Subscription.search
subscription = credit_card.subscriptions.build(:plan_id => 'silver') # initialize a subscription ready to be created using the vaulted card
subscription = credit_card.subscriptions.create(:plan_id => 'gold') # create a subscription using the vaulted card

Default Validations

[:cardholder_name, :length => {:maximum => 255}],
[:customer_id, :presence => true, :length => {:maximum => 36}, :on => :create],
[:number, :presence => true, :if => :new_record?],
[:number, :numericality => { :only_integer => true }, :length => {:minimum => 12, :maximum => 19}, 'braintree_rails/luhn_10' => true, :if => Proc.new { Configuration.mode == Configuration::Mode::S2S }],
[:cvv, :presence => true, :if => :new_record?],
[:cvv, :numericality => { :only_integer => true }, :length => {:minimum => 3, :maximum => 4}, :if => Proc.new { Configuration.mode == Configuration::Mode::S2S }],
[:expiration_month, :presence => true, :if => Proc.new { |credit_card| credit_card.new_record? && credit_card.expiration_date.blank? }],
[:expiration_year, :presence => true, :if => Proc.new { |credit_card| credit_card.new_record? && credit_card.expiration_date.blank? }],
[:expiration_date, :presence => true, :if => Proc.new { |credit_card| credit_card.new_record? && credit_card.expiration_month.blank? }],
[:expiration_month, :numericality => { :only_integer => true, :greater_than_or_equal_to => 1, :less_than_or_equal_to => 12 }, :if => Proc.new { Configuration.mode == Configuration::Mode::S2S }],
[:expiration_year, :numericality => { :only_integer => true, :greater_than_or_equal_to => 1976, :less_than_or_equal_to => 2200 }, :if => Proc.new { Configuration.mode == Configuration::Mode::S2S }],

A little more explanation

By default, the validations only check the presence of number, cvv, expiration_month, expiration_year and expiration_date and does not validate the format of those attributes.

It's because BraintreeRails assumes Braintree.js is used, such that those sensitive credit card data are already encrypted on the client side.

However, if you do have a very strong reason for using the unencrypted S2S API, you should think again.

If you still insist you need to have the unencrypted data, you can set the BraintreeRails::Configuration.mode to BraintreeRails::Configuration::Mode::S2S. Then, format check, e.g. numericality, luhn10, length, range check will kick in for those values.

In addition to the above validations, associated billing_address will also be validated by default.

Default Callbacks

(before|after)_validate
(before|around|after)_save
(before|around|after)_create
(before|around|after)_update
(before|around|after)_destroy

A little more explanation

In addition to the above callbacks, BraintreeRails has an internal :persist callback that runs before :validate. In this callback, encrypted attributes on CreditCard will be cleared after every create/update attempt. This only triggers when BraintreeRails::Configuration.mode is JS. S2S mode will leave those untouched.

In the case of success, there's no reason to hold the encrypted values any way.

In the case of failure, most likely you are going to use the same object to render the payment form with error messages to the end user for correction. And you dont want the end user to see the strange strings (encrypted credit card number etc.) to be displayed in the form. So, it is better to clear those encrypted values before rendering the form again.

However, if you do have a legitimate case that this behavior is undesirable, let me know.

Simply calling credit_card.valid? will not clear the values.

Convenient Methods

CreditCard#id

To make the interfaces consistent with other models, the following is added to CreditCard.

def id
  token
end

Supported REST APIs

Create

Find

Update

Delete