Bank Transfer Extension for Spree

After we started using Spree for development of e-commerce stores for our clients, we often found the clients looking for different modes for achieving more conversion.

From statistics it was visible that end users need more convenience in their hands while shopping online, particularly in the developing nations where credit card penetration is relatively low. In such environment, Bank Transfer appears to be another practical way by which consumers shopping online can make payments for their order.

Vinsol is SpreeCommerce Premier Partner. View Vinsol’s Services

Bank Transfer or BT, is a payment method which gives user the freedom to do an offline/online transaction to the Merchant’s account directly. The user deposits the amount into Merchant’s bank account, which is specified on the checkout page. The end user, on the other hand, after transferring order amount into Merchant’s account, needs to login and provide the payment transaction details with the specific order.

After having BT as payment method for few e-commerce stores we decided to create an extension for it in order to help other SpreeCommerce developers. Since Vinsol has been releasing gems for Ruby on Rails too, this seemed to be a better idea to release extensions for Spree.

Visit Vinsol’s Github Page for this extension

BT extension is a simple yet powerful option, which adds a new Payment method into the system with in minutes of installing. In order to show how this extension can help the Merchants and the developers, we have added a screencast for it.

In case the developers want to make any changes in this extension, they can easily customize it per the business needs.

This screencast is the first in this series of extensions, to view more screencasts from Vinsol search for “screencast” tags.

Updated At: 15.07.2014


Custom model callbacks in RubyOnRails

RubyOnRails provides us with many model callbacks around the object’s lifecycle when object is being created, updated or destroyed. For example: before_create, after_create, before_update, after_destroy etc. We use them to write & run our code around the object’s lifecycle by defining a method and associating them as one of the callbacks.

But then how can we make a piece of code execute as a callback for any another defined method except create, update, save and destroy? For example, let’s say we have a model Article and we want to execute something just before and after an article is being published without hooking into model’s before_save and after_save callbacks?

RubyOnRails or more precisely ActiveRecord provides us with a module ActiveModel::Callbacks, which allows us to define and register custom callbacks using define_model_callbacks method. Lets have a look at the snippet below for the above scenario:

class Article 
  extend ActiveModel::Callbacks
  define_model_callbacks :publish, :only => [:before, :after]

  before_publish :check_publishability
  after_publish  :notify_subscribers

  def publish
    run_callbacks :publish do
      puts "Publishing article..."

  def check_publishability
    puts "Checking publishability rules..."

  def notify_subscribers
    puts "Notifying subscribers..."


By default define_model_callbacks provides with all three callbacks i.e. before, after and around, but here in our example we have chosen to have just before and after callbacks by specifying a hash :only => [:after, :before] since only those two were needed. By using define_model_callbacks :publish, :only => [:after, :before] we got two new callback before_publish and after_publish, which we then used to register our callback methods.

So now when we will call publish method on an article object, check_publishability will be executed as a before callback and notify_subscribers will be executed as an after callback for the publish method.

One point to note here is that the code in the publish method should be wrapped in run_callback :publish block, so that when it is called on an object, its callbacks are executed too.

For the snippet above run_callback triggers before callbacks, yield the block given and then trigger after callbacks.

More information on define_model_callbacks can be found here.

>> article = Article.last
>> article.publish
Checking publishability rules...
Publishing article...
Notifying subscribers...