I've used Ruby's ActiveMerchant (based off of Shopify) on several large projects. It is really simple to use, especially for someone that doesn't deal with payments often.

http://www.activemerchant.org/

Using a different gateway is a one-line change. Running test data is easy. It supports every major gateway and payment company. And it's free.

If you're using Ruby, I can't recommend it enough.

thank you for the kind words :-) . ActiveMerchant turned out to be one of those quick things I put together while making Shopify that took on a life of it's own. Amazing success. At one point Cody took a 2 week vacation after we shipped Shopify and while he was gone we got 3 new gateways contributed that all immediately became available in Shopify. Even if he would have stayed back and coded all day he couldn't have created so many production ready gateway backends.

How does it work with PayPal? Do I send the data like with any other provider and paypal will authorize it? or does the user still have to be redirected to them?

It is indeed possible to use PayPal as a gateway. I believe the product you want is Website Payments Pro (what used to be Verisign), but their offerings are completely indecipherable and I suggest just giving them a call. This also has the benefit of getting you to a person to help guide you through the set up process.

"Website Payments Pro" is the one that will accept payments into your PayPal account, and "PayFlow Pro" (nee Verisign) is the one which accepts payments into your merchant account at a bank.

IIRC, both will take money from a credit card (which can be entered directly onto your site) or via Paypal payments (which requires a redirect to some stuff on paypal.com).

This is a valid point. What benefits would PayFacade provide over ActiveMerchant?

I guess it's tough to build products where the customers are developers (anything with API in the description), because programmers don't like to pay for tools like CEO's do.

Not quite every major gateway/payment company. Unless I just missed it somehow, I don't see Bibit (or RBS Worldpay, which now owns Bibit) on the list.

Hadn't heard of this before, thanks for sharing. I will look into it.

I like the idea very much.

Offering both pay by subscription and pay by transaction. Both has it's use cases. If I was running an ecommerce platform I would prefer to pay by month and if I want to sell ebooks on my blog, I would choose the second option to reduce costs.

P.S: Why do I get a confirmation message that says just "powered by wufoo". Maybe you should add your own message in it :)

It's my first time with WuFoo :) Should be fixed now.

Thanks for pointing out and thanks for sharing your thoughts on payment options. We will make sure to appeal to both larger and lower volume merchants.

It still showed up for me just now ;)

Still broken for me as well.

It looks like an interesting concept, but if it truly is going to make it seamless to switch payment API providers they are going to have to store card details (assuming you don't want to store card details and you are currently storing card details on the gateway), since I don't think gateways let you dump the card details back out.

It seems like the main value proposition is you can switch payment gateway providers (or use multiple ones for say canadian/us transactions) without having to move payment APIs. If I'm really trying to avoid having to switch APIs, what sort of gaurantees do I have that you guys will be around next month?

One big concern for me is that it seems that if you fold I lose the ability to bill recurring customers unless I store CC data (something I'd rather avoid).

We perfectly understand your concern. Our way to deal with it is that we try to use payment gateways' built-in recurring billing as much as possible in order to make it easy for our customers to move off our platform. We also offer the possibility to export any data that you own.

A couple thoughts to improve the home page:

1. There are a few typos you should fix if you want to seem credible. "Don't wory" should be "Don't worry," there's no period in the first sentence of the small text, and there is an extra space before both exclamation points (I know that's a French thing to do, but it's not standard in English).

2. Don't use jpegs for this type of image, a PNG will be much more crisp. Right now there are clarity issues in the blue surrounding text.

3. If you use text in the HTML instead of using an image it will be much more friendly. The small text looks very odd on a Mac and in browsers that have good font rendering and anti-aliasing.

Good luck!

Thanks, I've fixed those issues. Good guess on the French thing, that's actually my mother tongue.

It looks very nice, but I'm wondering if it has support for paypal subscriptions?

There are a glut of payment gateway API services, but very few of them support good subscription-based processing.

Have you noticed z-billing: http://www.zuora.com/products/zbilling/index.html then? Though not startup friendly, I guess.

This looks like a MVP using mockups. How do you plan on competing against Recurly, Chargify, etc.?

Edit: http://news.ycombinator.com/item?id=1300500

We don't think we will have to compete with them as we offer a different service. They could actually become our customers to offload the pain of implementing different APIs for all of their supported payment gateways.

Are you going to help with PCI compliance, say, by letting us use JS to post card data direct to your site, and only returning an ID code?

This please. It doesn't have to be JS, if I can just POST my form to their server, and have the user redirected back with a token that'll work just as well.

Braintree does this, but they're rather pricey.

I've wanted this feature bad enough I've considered launching my own service to do it. Surely there are a decent number of sites out there that want to retain control of their payment form, but want to seriously reduce PCI scope.

We (Braintree) are priced competitively. We may look higher than others because we don't use any pricing trickery ( http://bit.ly/cUyJTa ) and bundle gateway services. We created a checklist for merchants to help them avoid getting duped http://bit.ly/9W57Pw .

I should clarify. Braintree is perfectly competitive as long as you're handling some volume (20K/mo or so), and are willing to roll your gateway and merchant account into one provider. For smaller ventures, not so much.

It's actually between 2-5k per month, depending on average ticket. For merchants looking to maintain volumes less than that for the long term, other providers will cost less in monthly fees (but may have a higher total cost when including other items such as pci compliance, recurring solutions, etc.).

Clicked 'Get Started' thinking that would give more info. In Chrome, there's no way to exit that dialog and return to the main screen (no exit button, no cancel button, Esc does nothing). Overlooking something so obvious makes me distrust anything else the service might offer.

Thanks for pointing this out! Have you tried clicking outside the box? Anyways, we will add a close button to make it more intuitive.

Do you have a beta ready, or are you just seeing if there is an interest for this (ala the lean startup methodology)?

Also, how is this different from chargify, recurly, spreedly, or even braintree?

We are indeed trying to see where to focus and get some very early feedback. That being said, a big chunk of the code is already done :) The private beta should launch in the next following weeks.

I would say our service operates at a lower level of abstraction than the services you mentioned. Our ultimate goal is to make it simple to integrate with any payment processor.

Nice concept. I dont have a site ready to use for a beta so don't need to sign up for that. Is there a Twitter feed or email list to stay updated on the progress?

If you click "Get Started", then click "Powered By Wufoo", then close the dialog by clicking in the shaded area, the back button breaks in FF 3.6.3.

How exactly is this going to work? Are you just going to be adding as many modules (different payment gateway APIs) as you can?

That's pretty much the idea. There will be only one external API that developers can use, but internally, we will make sure to make it work with as many payment gateways as possible. We will then implement other features but that should be our core service. I've had to implement many payment processors for different clients in the past years and it really is a pain. I'm basically building this for myself :)

I'm building something similar for myself at the moment as well, so when I saw your product on the front page of HN, I thought "wow, great timing." But looks like it's still conceptual (to everyone else.. I'm sure you've got code in the works already) ;)

So how are you going to be testing the payment gateway APIs that you choose to include? Live accounts or maybe you've got someone at each gateway who can set you up with a test account?

Also - a lot of gateways do include load balancing, so some people might be better off just going with their original gateway, instead of adding another layer of complexity (and costs).

But I definitly think you got a viable idea going here... there is money to be made, simply cause your startup is in an area which wouldn't exist if there wasn't any money being moved around.

Good luck.

So its a saas version of aMember?