dan_manges

I wish developers could participate in the work, but unfortunately this is difficult because feature development on the client libraries is tied to feature development on the gateway. Until we release the corresponding features in the gateway, the client libraries wouldn't work.

I was thinking about your comment about seeing the progress of the project. While that is conventional for open source projects, it is unconventional for products. And since our client libraries are tied so closely to our product, progress of libraries is progress of our product. Anybody have thoughts/experiences/etc on sharing day-to-day development of their products? I know some companies do it, but it doesn't seem very common.

That's the implication is there is a DDoS attack on your DNS provider, but I think FooBarWidget was inquiring about the implications of a DDoS attack on your website, and specifically if you would be charged for the bandwidth consumed by the attack.

I used to vertically align things into columns in Ruby. It's easy to maintain when you're editing individual lines, but it can easily be messed up with a find-and-replace in file. At that point, it becomes harder to read with some lines off, and a pain to maintain the alignment.

If you're not sure how you want to do this, you could always wait until you need to implement version 2. You would then be forced to have omission of a version number indicate version 1, but waiting would allow you to make the decision when you're actually ready to begin implementation and might have a better idea or more information about how you want to approach it.

Are there any other disadvantages of this approach other than the problem with "Service Appliances"? Many REST APIs rely on HTTP headers for other things - do "Service Appliances" only remove non-standard headers?

If the header is missing you could return a 4xx response. You could document that the header is required or return a message in the response body indicating the cause of the 4xx.

I'm unsure of the specifics of your business, but we (Braintree) posted above about risk assessment generally. http://news.ycombinator.com/item?id=1494102

The business model that you explained is a true peer to peer payment system. As you know, it's essentially what Paypal is to ebay. It's presents perhaps the highest form of risk in the payments industry. This is especially true with new businesses because there is no track record and typically very little financial stability or backing. There is a graveyard in the payments industry dedicated to peer-to-peer payment startups, including some extremely well funded and connected companies, which is why it's so hard to find any payment provider willing to accept the risk. A lot of money has chased this for a long time now. Last time I checked, even Paypal won't allow provide payment services to other peer-to-peer providers, because, as they've stated, the "excessive risk". To date we've (Braintree) not approved any true peer to peer payment method as you described above, but we do process for a lot of merchants that use an aggregation model similar to Groupon, whereby the merchant accepts payment on behalf of another merchant. It's a small but significant difference.

In terms of revenue. It's always helpful if a business already has a track record and some external funding for validation as well as some stability. That also clearly presents a catch-22. Some providers are wiling to take substantial risks: new business, peer-to-peer track record and no funding while others are only willing to consider this type of high risk businesses who have an established track record.

I would offer a friendly word of caution. All too often new companies will find a provider to approve this type of business model only to be shut down at the worst possible time. This happens because sometimes the sales rep doesn't properly explain the business model to the underwriters, the underwriters don't understand it, and/or an application gets auto approval because it's new and has low expected volumes. I'm not suggesting that there are not providers that won't approve this type of business, and I'm also not suggesting that everyone approved for this type of payments model will eventually get shut down. What I am suggesting is that we see merchants getting shut down too frequently, so I'd be cautious if I were you.

Best of luck to you.

Aggregation more fully explained: http://www.braintreepaymentsolutions.com/blog/high-risk-mech... More information about payments and risk: http://www.braintreepaymentsolutions.com/services/new-to-pay...

It can also vary a lot within a type of service depending on the target market. At Braintree our churn rate is higher for the start-ups that we work with (because they sometimes go out of business) than it is for companies that have been around longer and are profitable.

Braintree offers this. We call it Transparent Redirect. We've worked with several QSA assessors who have verified that by using our TR API merchants do not fall in scope for the requirements for transmission of credit card data and can therefore complete SAQ A to become PCI compliant. http://www.braintreepaymentsolutions.com/credit-card-storage...

Our (Braintree) fees are competitive. We have a higher monthly minimum than some, if that's what you're referencing, but otherwise if a merchant is processing a few thousand dollars a month our fees are right in line. We are different than others in the industry. We engage in a meaningful way with our customers. We educate them on the risks, nuances and best practices. We try to properly assess risk upfront instead of surprising afterwards. We proactively help them lower fees. We assist with PCI Compliance and credit card data security. We don't hold stored credit card data hostage. We don't hide fees and then deny that we hid them in the first place. We answer our phones and respond to email very quickly. Our goal always been for our customers to conclude that we're the best payments provider they've ever worked with and many of our customers maintain that opinion which we're always very pleased to hear.

For application requirements, we (Braintree) work with Visa, MasterCard and the sponsoring banks to make sure that all our merchants are in compliance. There are other payment providers that will turn a blind eye to these requirements in addition to postponing proper due diligence and underwriting until it's a problem for a merchant. We regularly have merchants approach us that are in some sort of bind (e.g. violation of card association rules, account was frozen / shut down) because their previous payments provider didn't do things correctly. The payments industry is very complex with a lot of layers and nuances. We try our best to do things right even if it means more upfront effort.

An example: "With increased revenue, the merchant bank became concerned with the increase in liability. So, the bank closed the merchant account." And because they couldn't get their credit card data back, they had to ask all their customers to enter their payment information again. http://blog.recurly.com/2010/05/credit-card-portability/

Additional Info:

http://www.businessweek.com/smallbiz/running_small_business/...

http://whiteelephantmedia.com/

http://www.braintreepaymentsolutions.com/blog/paypal-reserve...

If you use an API like Braintree's Transparent Redirect ( http://bit.ly/d5wD4P ) you can host the payment form on your site without touching any credit card data. That way you won't have to deal with the drawbacks of redirecting your customers to a third party hosted page. Disclosure: I work for Braintree.

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 .

We (Braintree) have updated some things since AgileZen integrated: we now provide client libraries that simplify integration and also have much more robust recurring billing capabilities.

It can be difficult to get a credit card merchant account to do payments aggregation: http://www.braintreepaymentsolutions.com/blog/high-risk-mech...

It might be easier to have the buyer's entire payment transferred to the seller and then bill the seller for your cut separately.

I would recommend going with whichever language you're more proficient with. That way when you run into something that the framework can't handle for you, you'll be able to work through the problem more efficiently.

I use unit tests and puts statements to debug most of the time. It can be faster than stepping through an actual debugger.

I agree that it's not very secure, although as Schneier says in his post, the liquid ban is useless.

The worst that can happen is your company goes out of business. http://whiteelephantmedia.com/ - Paypal requested $600k to keep the account open.

Braintree offers managed recurring billing and is also a merchant account provider. http://bit.ly/braintree

We (Braintree) support over 100 currencies: http://bit.ly/braintree-currencies . We're less hassle than other gateways, but getting merchant accounts for international processing isn't completely hassle free. It's more of an industry problem than a gateway problem, but we're working on it.

Spreedly is a layer on top of gateways, so it can only support currencies that the underlying payment gateway supports. Gateways that Spreedly supports: http://spreedly.com/info/payment-gateways/

Our (Braintree's) pricing is actually very competitive. It probably looks higher because we disclose all our fees. Nearly every provider we know of obscures fees both during the sales process and in the monthly reporting statements so merchants never really understand what they're paying. Here's an example of pricing trickery http://bit.ly/9NSZCa . Prospective customers regularly do thorough pricing comparisons and we are consistently among the most competitively priced. Our objective has always been to provide the best value in the industry for a fair price.

We (Braintree) are currently only set up to provide merchant accounts for businesses with a legal U.S. presence. We do however have some international customers that work with our partners for the merchant account and us for the gateway, vault and recurring billing. Our partners don't maintain any hard and fast volume requirements but instead evaluate opportunities based either on current or expected volumes.

Braintree minimums depend on which of their services you use. See http://bit.ly/braintree-pricing