Pinax and pluggable apps for social ecommerce

[bobhaugen]

This is sortof a response to the "What web frameworks are missing"
thread (or not).
http://groups.google.com/group/pinax-users/browse_thread/thread/aa6d9117bdadc60e?hl=en

Anyway, I do think Pinax would be a great foundation for an Etsy-like
site, and will do one myself sometime this year.

But what I think that might require is a bunch of pluggable apps for
different aspects of a shopping site.

For example, two of the groups I have in mind need to be able to
associate particular product sales with particular suppliers, and
route some of the purchase price back to the supplier. (Might be
different suppliers for different items in the same shopping basket.)

They also have different inventory requirements (different from i.e.
Satchmo and different from each other).

Neither of them would want to touch PayPal at all.

And both would want some accounting and planning features, which I'd
guess many ecommerce sites would not need.

So I think part of the design challenge for people who want to do this
(including me) is how to factor the design space into pluggable apps.
I'm thinking about it, but have not worked it out in any detail.

[Adam Nelson]

I think the correct apps would be:

Inventory - Stock per warehouse (including third parties)
Fulfillment - Sending, Returns, etc...
Shopping Cart - Ability for users to maintain items through sessions and to save them
Billing - Connectivity to billing providers to facilitate payment, chargebacks, etc...

Inventory, Fulfillment, and Billing would all have special libraries for handling third party sellers, UPS/FedEx, PayPal/Google/Authorize.net

Pretty big project and I think Bob is right that these definitely need to be separate apps. 

--
Adam Nelson

http://www.varud.com
http://twitter.com/varud
http://www.linkedin.com/in/adamcnelson

[bobhaugen]

Adam, nice list. Additions below.

On Mar 12, 8:51 am, Adam Nelson <a...@varud.com> wrote:
> I think the correct apps would be:
>
> Inventory - Stock per warehouse (including third parties)
> Fulfillment - Sending, Returns, etc...
> Shopping Cart - Ability for users to maintain items through sessions and to
> save them
> Billing - Connectivity to billing providers to facilitate payment,
> chargebacks, etc...
>
> Inventory, Fulfillment, and Billing would all have special libraries for
> handling third party sellers, UPS/FedEx, PayPal/Google/Authorize.net
>

I also will need suppliers (which I think are seller accounts in Esty)
and the ability to pay suppliers based on customer payments. That
last feature takes a prohibitive amount of work if it is not well
automated, but not everybody will need it. Don't even know what to
call it yet.

And my inventories need supplier/owners, in addition to locations.
But we already made inventory a separate app, so I can plug my special
requirements in there.

Then there's accounting.

One major problem with any factoring is that a lot of these separate
apps will have accounting implications: inventory receipts and issues
(shipments), billing and payments from customers, payments to
suppliers, etc. So that's a cross-cut. If the users want some
accounting features, it would be nice if the various pluggable adhered
to a common format for economic events or transactions or whatever you
are used to calling them. I do not mean journal entries, I mean the
basic economic events, that is, increments and decrements to economic
resources like inventory and money. Actually, it would be nicer if
they subclassed from a common EconomicEvent model, but that's probably
too much too ask...

[armin...@gmail.com]

Has anyone checked out Google Checkout?

I've looked at their integration API, which is
http://code.google.com/apis/checkout/index.html,
and I think it would be relatively easy to implement quickly. It
would be great to have an integrated shopping cart/credit card
processing app integrated in pinax, but I think in the meantime
people
who want to avoid paypal could add google checkout to their site.
This would effectively outsource the shopping cart function and
credit
card processing to google, and they would charge accordingly (I think
it's about 2.9% + .30 cents per transaction). That might be too high
a price to pay for some, but it might be worth it for people who want
to get up and running quickly.

Any thoughts about the upsides and downsides of using a third-party
shopping cart app like Google Checkout with Pinax?

[bobhaugen]

On Mar 12, 10:01 am, "arminham...@gmail.com" <arminham...@gmail.com>
wrote:

> Any thoughts about the upsides and downsides of using a third-party
> shopping cart app like Google Checkout with Pinax?

Upsides: maybe a solved problem:

I googled and found:
http://code.google.com/p/django-cart/
http://code.google.com/p/gchecky/

But also, the downside:
http://www.djangoproject.com/weblog/2008/jul/14/support-the-dsf/

See in the comments:

Marijn July 16, 2008 at 4:59 a.m.
Paypal would make me do a donation as well. It's quite a hassle to set
up an account and transfer money from Europe to a thing like Google
Checkout which is in the U.S.

Jacob Kaplan-Moss July 16, 2008 at 2:01 p.m.
Shabda, Marijn: Other donations options, including Paypal are on the
todo list. I hadn't realize that Google Checkout was a pain for people
outside the US; sorry!

Oops!
Unfortunately, this merchant no longer accepts payments through
Google. We apologize for the inconvenience.

[David Merwin]

I've used Google checkout and it is pretty solid. Much easier to use than most solutions. Except maybe PayPal.

If you can wait a few weeks, I'll be launching an inventory project called Diki. I'm going to use it to replace Things in my Pinax project. It will be a Inventory Management app. It'll be available via github the end of march.

Dave

--
Dave Merwin
Join me for Beer and Blog.
Friday's 4 to 6 at 19th Street in Eugene.
http://eugene.beerandblog.com/

http://www.purebluedesign.com
http://www.davemerwin.com
My Profile: http://www.linkedin.com/in/merwin

Need a powerful communication and collaboration toolset? Ask me how Google Apps can help.

[bobhaugen]

P.S. I would like to take this thread off the subject of Google
Checkout and back to the subject of the factoring of pluggable apps
for social ecommerce using Pinax. Not that they ain't related in some
way, but probably Payment should be a separate app offering several
payment services.

[bobhaugen]

On Mar 12, 10:37 am, David Merwin <dave.mer...@gmail.com> wrote:
> If you can wait a few weeks, I'll be launching an inventory project called
> Diki. I'm going to use it to replace Things in my Pinax project. It will be
> a Inventory Management app. It'll be available via github the end of march.

Cool! I can wait for the app, but if you could say a bit about the
features it will and won't have (in the light of this app factoring
topic) that would be useful.

[Tom Longson (nym)]

Very cool. Hats off to you bobhaugen for taking this on. I think it
would be really good for the Pinax project.

Cheers,
Tom Longson (nym)
---------------------------------
Tackle Human Dilemmas.
http://stopthespin.com/

[Kless]

I've found that Amazon Flexible Payments Service (Amazon FPS) is more
inexpensive that both Google and PayPal, and it has a better
insfrastructure for developers:

http://aws.amazon.com/fps/
https://payments.amazon.com/sdui/sdui/business?sn=devfps/o
https://payments.amazon.com/sdui/sdui/business?sn=compareSolutions/o

An Amazon FPS Client for Python:
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1332

[David Merwin]

I've heard about that and wanted to try it. Nice catch.

[Adam Nelson]

Whatever is decided, it will have to be abstract anyway:

django-billing (or something like that)
 |
 L Authorize.net
 |
 L Amazon FPS
 |
 L Google Checkout
 |
 L PayPal

I personally have an aversion to PayPal and would +1 Amazon being the first one to be properly Django-ized.  Keep in mind that Authorize.net is one of the more common gateways for run of the mill ecommerce sites.  Something like that will probably have to be rolled out because it's more suited to companies with merchant accounts already.

[Armin Graf]

This sounds like a great idea, as this would make the code of the site independent of the billing service.  But would django-billing consist only of credit card billing, or would it include a shopping cart function?  If you have a shopping cart provided by google checkout but not authorize.net, is that going to pose a problem when you abstract?  WIll you be able to mix and match shopping cart functionality with billing services, or does it make more sense to do all inventory and shopping cart code in django and then only outsource/abstract the credit card billing service at the very end?

[bobhaugen]

Re run of the mill ecommerce sites:

If I had one of them, I would just use Satchmo or maybe LFS and be
done.

I will have something different: ecommerce sites with many sellers,
not in different "stores", but where their products can be mixed in
the same shopping cart.

And the inventories also need to identify the seller, and some of each
payment goes to the sellers of the products involved.

So it's really a Pinax social app with social ecommerce for the
sellers as well as the buyers.

A mashup of Pinax and Satchmo or LFS might still get the job done, I
don't know (yet).