Split into submodules

[jamescarr]

Currently the module is a little bit of a mess... users get braintree whether they want to use it or not. Plus there is no abstraction on top of the original payment modules as planned. I think the general direction we should take is build submodules with a coherent coding style and then build abstractions on top of those.

So instead of just paynode, we'd wind up with

• paynode-paypal
• paynode-chargify
• paynode-authorizenet

And turn paynode itself into an abstraction layer on top of these different modules. Thoughts?

[andyburke]

As someone looking around at solutions to this problem, I am fine with an all-in-one as long as I don't need to configure every one of them to get it to work. That is, I don't care if the npm module includes code for a service I don't use, as long as that code is safe for me to ignore in preference to the code I do need. I don't know that it's worth the time and effort of breaking things up into those specific modules.

[PawanWagh]

@jamescarr : I agree with you. We're also building a similar kind gateway service where you can opt for required payment provider, install corresponding adapter (to enforce a common interface for all providers) of that provider service and start using it.
So even if in future we decide to switch from paypal to braintree or from paypal to chargify, it makes our life easier for such migration.

Same architecture has been adopted by loopback where you can access data from Oracle, MySQL, PostgreSQL, MS SQL Server, MongoDB, SOAP and other with same REST APIs. It provides wrapper for mongodb, mysql, and other as separate packages & uses a datasource config to define which connector to use for current transaction.

I am forking your repo. Lets build it together.