Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Amazon FPS vs PayPal vs Google Checkout [closed]

I'm in the very early stages of planning a new website. I would like to offer payment processing for two distinct use cases:

  1. Accepting payments from users to me for SaaS functionality on a recurring basis.
  2. Facilitating payments between users of the website.

The ratio of users making payments to users receiving payments will be approximately 100:1. I mention this because I want to make sure it is very easy for users to make payments, but can live with some additional hassles for users who want to receive payments.

I have not settled on a business model, but I am considering charging a small middle-man fee in use case 2 above. I plan on using a python framework to implement the website (leaning towards django or web2py), so existing python module support would be a plus.

My question is this: should I use a particular payment gateway (and if so, which one) or should I provide support for multiple payment gateways (and which ones)?

EDIT: How much of a nightmare is it to roll your own payment gateway? In other words, would it be worth the trouble to accept and process Visa, MasterCard, Discover, etc directly? Anybody have any experience doing that? Liability/security concerns more hassle than they're worth?

like image 246
mwolfe02 Avatar asked Jun 28 '10 18:06

mwolfe02


1 Answers

I just came across the following service: BrainTreePaymentSolutions and they appear to be the Webfaction equivalent of payment gateways; ie, not necessarily the cheapest or biggest available but maybe the most honest and easiest to work with (at least based on their stated philosophy and--apparently--top notch python support).

I'm posting this as a separate answer, rather than an edit to my original question because I am especially interested to know if anyone has any experience with this specific company. They look like the kind of folks I'd like to do business with.

EDIT: I called and talked with a rep from BrainTree. He explained that use case 2 as I described it is Third-Party Payments Aggregation and it is high risk (follow the link for full explanation). This only means that it is (much) harder to get underwritten for a merchant account. It's not impossible, either. However, the other things they consider when underwriting an account (processing history, capital reserves, etc.) are not exactly going to help my case at the outset.

My plan now is to start out with use case 1 exclusively and to plan for future support of use case 2.

like image 68
mwolfe02 Avatar answered Oct 18 '22 03:10

mwolfe02