

What Web Frameworks Are Missing - Credit Card Payment Out of the Box - jonnytran
http://plpatterns.com/post/85545826/what-web-frameworks-are-missing

======
patio11
ActiveMerchant, Rails SAAS kit, etc.

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.)

~~~
dasil003
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.

~~~
jonnytran
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.

~~~
dasil003
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.

------
jasonlbaptiste
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.

------
maccman
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

------
MartinKleppmann
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.

------
zhyder
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?

~~~
aston
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.

------
Brushfire
Hrmm. He forgot about ActiveMerchant.

<http://www.activemerchant.org/>

------
kortina
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.

------
truebosko
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.

~~~
naish
There is also Satchmo, which provides many of the pieces required to build an
online store using Django.

<http://www.satchmoproject.com/>

------
zdmc23
Why don't banks just open up their software offerings and give you an API to
accept transactions?

------
igorgue
django-cart and django-paypal ?

