What Web Frameworks Are Missing - Credit Card Payment Out of the Box(plpatterns.com)
plpatterns.com
What Web Frameworks Are Missing - Credit Card Payment Out of the Box
http://plpatterns.com/post/85545826/what-web-frameworks-are-missing
18 comments
The OA won't load so I'm basically just commenting on the headline. The purpose of a web framework is to abstract all the numerous nuts and bolts issues of building an application on the web which was never designed with applications in mind.
The reason Rails is so successful is because it identified the right interface to abstract for the maximum range of utility.
As a counter-example I often cite Drupal. Drupal is not just a CMS, but also a framework. It's incredibly well thought out and strikes an awesome balance of out-of-the-box functionality and customisability. The problem is that it comes with a lot of baggage, so you always end up with a lot of complexity that you don't need.
Adding high-level application features inevitably leads you down this road which—though appealing for projects without a proper budget (ie. most client work)—ends up forcing all kinds of small sacrifices in design, usability, performance, data modeling, and simplicity. Some projects could never get done without these sacrifices, so projects like Drupal are invaluable in terms of absolute value (especially to small businesses), but to add these features to something like Rails is to utterly destroy an incredibly useful general-purpose tool.
The reason Rails is so successful is because it identified the right interface to abstract for the maximum range of utility.
As a counter-example I often cite Drupal. Drupal is not just a CMS, but also a framework. It's incredibly well thought out and strikes an awesome balance of out-of-the-box functionality and customisability. The problem is that it comes with a lot of baggage, so you always end up with a lot of complexity that you don't need.
Adding high-level application features inevitably leads you down this road which—though appealing for projects without a proper budget (ie. most client work)—ends up forcing all kinds of small sacrifices in design, usability, performance, data modeling, and simplicity. Some projects could never get done without these sacrifices, so projects like Drupal are invaluable in terms of absolute value (especially to small businesses), but to add these features to something like Rails is to utterly destroy an incredibly useful general-purpose tool.
I didn't mean in the core, necessarily. But it should be dead-simple to do -- a flip of a switch and a config file maybe.
Drupal ecommerce module is the perfect example. It tries it's best to be everything to everyone. I doubt you'll see a better turnkey solution that's not a standalone application.
When setting up with e-junkie can you do it in such a way that their name doesn't show up anywhere? (on the payment page, on the credit card bill, etc)
I wouldn't want my customers seeing "e-junkie" anywhere where they are giving me a credit card number. It sounds shady and may make some customers put their credit card back in their wallet.
I wouldn't want my customers seeing "e-junkie" anywhere where they are giving me a credit card number. It sounds shady and may make some customers put their credit card back in their wallet.
e-junkie is just a wrapper around Paypal/Google Checkout/etc, so they don't show up on the credit card bill ever. I take minor steps to make sure their branding doesn't show on my website. See here:
http://www.kalzumeus.com/2008/06/12/how-to-use-e-junkie-with...
http://www.kalzumeus.com/2008/06/12/how-to-use-e-junkie-with...
You're right that the reporting stuff is hard to do and difficult to abstract. Google Analytics and Mint both seem like pretty good systems that work for wide userbases, though. I guess because payments are so intertwined with authentication/access levels is why just a custom reporting and easy to use credit card processor may still not be the entire answer.
Payment for web apps is a consistently difficult problem. Subscriptions are on an order of magnitude more difficult. Anniversary dates? Pro-rating? Compliance issues? Charging back only a portion of the order? Upgrading your pricing structure and tiers without modifying the code? Rebate codes? Yeah, to build a subscription billing system that can eventually scale with the business, it would be like building another product. With Publictivity, I spent an enormous amount of time trying to figure out a solution. We settled on Zuora over Aria Systems. They're a great team that knows SaaS like the back of their hand (first salesforce employees+early webex). They're not self service yet though.
I've said it to most of my entrepreneur friends: there is tremendous opportunity for a YC type startup that makes subscription billing painless + developer friendly. I'm talking API calls, plug in the merchant processor, and you're done. Get started instantly, with no need for "enterprise sales calls"+"integration strategy calls". If you're making a web app in a weekend for fun, and want to charge on a subscription basis, you're pretty much SOL. You talk about gaping hole problems? This is a hole so big it's a rip in the space time continuum.
Update: I JUST found this: http://spreedly.com via @ryancarson. Looks to be a start in regards to what I'm talking about.
I've said it to most of my entrepreneur friends: there is tremendous opportunity for a YC type startup that makes subscription billing painless + developer friendly. I'm talking API calls, plug in the merchant processor, and you're done. Get started instantly, with no need for "enterprise sales calls"+"integration strategy calls". If you're making a web app in a weekend for fun, and want to charge on a subscription basis, you're pretty much SOL. You talk about gaping hole problems? This is a hole so big it's a rip in the space time continuum.
Update: I JUST found this: http://spreedly.com via @ryancarson. Looks to be a start in regards to what I'm talking about.
Just to plug my own Rails SaaS framework:
http://github.com/maccman/saasy
== Features
* No local credit card storage * Automated billing script that should be run nightly * Configurable subscription plans (price/duration) * SSL protection for account creation (and when updating CC info) * Account can have multiple users, interface for adding more * Trial ending mailer * Invoice mailer * Automated notification and retry of failed renewals * Plan upgrade/downgrades * PDF invoices * OpenID support * Shared secret SSO * Credit card verification * REST API for users and subscriptions
http://github.com/maccman/saasy
== Features
* No local credit card storage * Automated billing script that should be run nightly * Configurable subscription plans (price/duration) * SSL protection for account creation (and when updating CC info) * Account can have multiple users, interface for adding more * Trial ending mailer * Invoice mailer * Automated notification and retry of failed renewals * Plan upgrade/downgrades * PDF invoices * OpenID support * Shared secret SSO * Credit card verification * REST API for users and subscriptions
I'm developing a free Ruby Gem called Invoicing -- http://ept.github.com/invoicing/ -- it basically provides a miniature accounting and invoicing system inside your app, it's very powerful (flexible tax handling, multi-currency, support for resellers/affiliates) but easy to get started with too. At the moment it doesn't include particular payment method implementations out of the box, but I want to start including those soon. I am also working on integrating it with OAccounts http://oaccounts.org/ -- a (work-in-progress) open standard for exchanging financial data between different accounting systems.
The important thing is though that with the invoicing gem, you end up representing the data in an accountant-friendly structure, without having to think like an accountant. And that makes things a hell of a lot easier when you start scaling the business and need to know what's going on in your accounts for tax, legal and management reasons. Just taking payments won't do; you also need to know who is paying for what, keep statements of accounts etc. If you're a business in the EU, selling to another EU country, tax is different from selling within your own country. And so on.
Would love to hear your opinions on the Invoicing Gem; I agree that a standard framework is needed, and this is my attempt to contribute one to the community.
The important thing is though that with the invoicing gem, you end up representing the data in an accountant-friendly structure, without having to think like an accountant. And that makes things a hell of a lot easier when you start scaling the business and need to know what's going on in your accounts for tax, legal and management reasons. Just taking payments won't do; you also need to know who is paying for what, keep statements of accounts etc. If you're a business in the EU, selling to another EU country, tax is different from selling within your own country. And so on.
Would love to hear your opinions on the Invoicing Gem; I agree that a standard framework is needed, and this is my attempt to contribute one to the community.
Somewhat off-topic, but we're using Authorize.net's Automated Recurring Billing (thru ActiveMerchant). The API is so simple, it's incomplete. There's no way to reattempt a declined transaction.
Here's what happens: (i) user signs up for paid account with 1-month free trial, but has a typo in the zip code (Authorize.net doesn't check this when the subscription is created); (ii) after the 1 month, the first charge is attempted and declined; (iii) we email user and user updates billing info, so future monthly charges should work but this current transaction is lost forever.
Authorize.net says we should manually charge the user but we (intentionally) don't save the credit card info. Any ideas? Or should we just switch to someone like TrustCommerce?
Here's what happens: (i) user signs up for paid account with 1-month free trial, but has a typo in the zip code (Authorize.net doesn't check this when the subscription is created); (ii) after the 1 month, the first charge is attempted and declined; (iii) we email user and user updates billing info, so future monthly charges should work but this current transaction is lost forever.
Authorize.net says we should manually charge the user but we (intentionally) don't save the credit card info. Any ideas? Or should we just switch to someone like TrustCommerce?
We're on Authorize, too, and we didn't mess around with ARB at all because we anticipated that we'd need more flexibility around retries. The best I can recommend short of changing providers is to let Authorize hold on to the credit card info with CIM, and then run your manual charges through that system.
Hrmm. He forgot about ActiveMerchant.
http://www.activemerchant.org/
http://www.activemerchant.org/
Just commented on the post, but I know there are tons of smart hackers here who are prolly also interested. I've been working on this with a friend and will have the beta version ready for developers sometime in April. Email me at gmail or dm @kortina to get on the beta list. Our goal is to make credit card payments so easy your little sister can swipe credit cards at a lemonade stand.
Not really. As a django user I've found many apps to help in this that are extremely easy to integrate, and for what I could not find I built my own.
I built a django-simple-cart for our works websites, and then integrated it with a modified django-paypal within a single day. There are other django cart solutions, but even with mine I can plug it into any of our django sites and within a matter of minutes that site has a working payment solution.
I built a django-simple-cart for our works websites, and then integrated it with a modified django-paypal within a single day. There are other django cart solutions, but even with mine I can plug it into any of our django sites and within a matter of minutes that site has a working payment solution.
There is also Satchmo, which provides many of the pieces required to build an online store using Django.
http://www.satchmoproject.com/
http://www.satchmoproject.com/
Why don't banks just open up their software offerings and give you an API to accept transactions?
django-cart and django-paypal ?
The hard part isn't doing credit card payment. It won't take you fifteen minutes to integrate, e.g., single purchases of Paypal content into a typical Rails app. Trust me.
The hard part is you just introduced requirements for users, authentication, logging, administration, bookkeeping, accounting, and reporting into your app. And those requirements are, necessarily, different for everybody.
Its the same reason Rails doesn't have a One Way To Do It user signup & administration feature: everyone's needs are different and the overhead added by standardization is greater than the engineering effort saved by it.
(Sidenote: if you don't need subscriptions www.e-junkie.com and don't look back. $5 a month, saves a lot of boring report & email integration when you're starting. It took me about ten minutes to set up "People click this button to pay me, e-junkie mails them a license key." when I started. I didn't add anything to their solution for about 2 years. These days they call a script on my server so I can do stat tracking to my own satisfaction, but the core loop hasn't changed much at all.)