Posts Tagged ‘gateway’

July 30 2010

Brainspreeby braintree

Dear Spreets,

We're psyched to announce that with commit d0fcd7b the 0-11-stable branch of Spree now supports integration with the Braintree payment gateway.

There's a great open-source community around Spree, a fact we got to see first hand as we worked on this code. Thanks to Mike Horn for the initial heads-up and implementation advice and to the Spree core devs for answering our questions and reviewing our patch.

The Braintree integration code is fully tested at the unit level and with end-to-end tests against our sandbox environment. It utilizes the latest version of ActiveMerchant and our own Braintree ruby gem, both acting together with Spree to form a credit card processing all-star team.

So, what are you waiting for? We love developers, and we'll give your data back to you, guaranteed. Hit us up for a sandbox account and get cracking with Spree & Braintree!


Editors Note: This is a guest blog post solicited by the Spree core team. Drop us a line if you have something to say that might be of interest to the Spree community.

November 04 2009

New on Edge: Improved Gateway Configurationby railsdog

The edge code now contains significant improvements to how payment gateways are configured. Gateways are no longer supported by database migrations, this scheme has been replaced by Active Record models that extend Gateway. The configuration of gateways is now done through standard Spree preference configuration. The documentation has also been updated and contains a detailed explanation.

One major improvement is that it is now possible to configure multiple gateways for each of your Rails environments. Its also possible to use the live production server in development mode when previously, you were required to run in test mode. One unfortunate side effect of this improvement is that your existing gateway configuration information will be lost and you will need to reconfigure your gateway in the admin interface.

You should make a note of your gateway configuration setting before upgrading since you will need to reconfigure your gateway when you're done.

This approach to implementing and configuring gateways is extremely flexible. It makes it trivial to implement a new gateway that is already supported by Active Merchant. There are other useful benefits to this approach that a developer may be interested in knowing.

Support of Non Active Merchant Gateways

This architecture allows Spree to support gateways that are not officially supported by Active Merchant. Many times a new gateway is donated by someone in the community but its languishing in the queue waiting for someone to test and accept the patch. You have the option of taking that code (or writing your own from scratch) and implementing it within Spree. Instead of delegating to an Active Merchant class, you can simply implement that functionality yourself. You could also include the new gateway code from an Active Merchant fork inside your implementation and delegate the standard authorize, capture, etc operations to it.

Ability to "Patch" Active Merchant Gateways

We've noticed that sometimes it takes a while for a crucial Active Merchant patch to be applied. That's certainly understandable, the Shopify guys have a business to run and its probably not a high priority for them to make sure that the latest obscure gateway patch is applied in a timely fashion. Fortunately, the Spree approach to wrapping these gateways provides you with a convenient option.

Lets say there is a bug with the authorize method. You could simply provide an implementation of the gateway that has the patched version of the authorize method and then delegates to the Active Merchant class for everything else (since that works just fine.)

Additional Functionality Beyond Active Merchant

Another benefit of the architecture is that it makes it possible for Spree to provide additional common functionality that was not envisioned by Active Merchant. Specifically, it is possible to provide an abstraction for storing credit card profiles to be used with recurring payments. There's a good reason for Active Merchant to not care about this functionality. Its designed for people who just want to drop a single gateway provider into their application. Most programmers don't need three different gateways at once. Spree is a specialized use case. Its providing multiple gateways for you to choose from and so its desirable to have a standard method for operations such as this.

Recurring payments are not yet supported in Spree although there are plans to provide this in the near future.