There is a nice article related to this topic on Smashing Magazine:
http://www.smashingmagazine.com/2010/06/02/getting-started-with-e-commerce-your-options-when-selling-online/comment-page-1/#comment-462851
Regards
Anand
On Jun 3, 10:23 pm, Richard wrote:
> I would also trust someone known like
I would also trust someone known like PayPal more than the average
website.
Hopefully a good PayPal solution can be implemented like PHP has. But
it's a lot of work for a hobby programmer.
What do you think about having some kind of bounty system where people
interested in a difficult feature lik
I use paypal "Website Payments Standard" and the *best* part about
that is that while the user experience is crappy with the redirection,
i *never* learn the user's credit card number, and therefore don't
have to worry about regulations in how that info is handled (which
extends to your server logs
Paypal has multiple workflows and products.
The simplest one is "*Website Payments Standard*" where you direct the user
to the paypal website for payment. Not great for the user experience but
workable and above all there is no monthly fee associated with it.
Another version is "*Website Payment
Both paypal and google require redirection to their sites. The
workflow is more complex that needs to be.
There is this:
http://www.scribd.com/doc/30661771/Web2py-Paypal-Integration
Massimo
On Jun 1, 8:54 pm, Richard wrote:
> would be great if web2py had a robust Paypal solution, which by
> ex
would be great if web2py had a robust Paypal solution, which by
extension would support credit cards too.
Though maybe this is more difficult than it sounds - I know Django has
not yet achieved this.
Recently I signed up for a conference that used a Django registration
system and the Paypal suppor
good point. I was not aware of that.
On Jun 1, 2:04 am, Richard wrote:
> was looking around the Authorize docs and found:
> "The merchant must have a U.S. based merchant bank
> account"http://developer.authorize.net/guides/AIM/Introduction_to_AIM/AIM_Min...http://developer.authorize.net/guides/S
was looking around the Authorize docs and found:
"The merchant must have a U.S. based merchant bank account"
http://developer.authorize.net/guides/AIM/Introduction_to_AIM/AIM_Minimum_Requirements.htm
http://developer.authorize.net/guides/SIM/Introduction_to_SIM/SIM_Minimum_Requirements.htm
darn...
paypal is definitely complex, but it is also popular!
On Jun 1, 12:16 pm, mdipierro wrote:
> Turns out that one has dependencies. Some in zope code.
> This one seems a simpler option. Authorize.net is one of the best
> options anyway.
>
> Paypal and google have more complex workflow.
>
> On May
Turns out that one has dependencies. Some in zope code.
This one seems a simpler option. Authorize.net is one of the best
options anyway.
Paypal and google have more complex workflow.
On May 31, 8:28 pm, Richard wrote:
> sms handling and credit card payments - neat!
>
> That onlinepayment API yo
sms handling and credit card payments - neat!
That onlinepayment API you linked earlier (http://pypi.python.org/pypi/
onlinepayment/1.0.0) offers more payment options, such as PayPal.
Would it be worth integrating that instead?
On May 31, 2:42 pm, mdipierro wrote:
> 1)
> mail.settings.server='l
11 matches
Mail list logo
