dan_manges

I agree. I think pg's equity equation[1] is applicable here. If Tim Cook keeps Apple on the trajectory it's on now, Apple's shareholders will get a great return on this investment.

[1] http://www.paulgraham.com/equity.html

I'd say he's going for being contrarian rather than PC. It didn't sound sexist to me, likely because the CEO was also female.

The difference is the price. Most talent acquisitions don't go for $85 million.

Could Google Huddle have influenced Skype to make this move? Google is clearly trying to enter the group messaging space and has the infrastructure to support both text and voice group communication.

It's helpful if you let people know as early as possible if you're going to go over the estimate by a substantial amount. In the example in the grandparent comment, I can understand why the client would be unhappy paying $30,000 for a project that was estimated at $15,000 if they didn't find out until the very end. Imagine if you had to get your car fixed and when you went to pay the bill it was twice as much as the estimate, and compare that to the experience of getting a call part way through to inform you that the fixes will be more expensive than originally estimated.

I think it's misleading to quote a day rate and then work less than a typically expected number of hours. The client will make an assumption that a day is approximately 8 hours and wouldn't be happy if he/she found out that you were only working 4 hours per "day."

I was at a conference recently and saw somebody start Firesheep -- HN profiles showed up. So the choices were: use HN on open wifi but risk having your session stolen, don't use HN, or connect to a VPN. The VPN is probably the smartest thing to do on an open wifi network, but it's nice to know that HN is now safe to use without it.

Yes, everybody prefers it to working in isolation

We have a dev team of 12 working with an open floor plan, pair programming. We get a lot done. There is no single right way to operate.

I actually liked some things in the "YC S11 Company Seeks Rails Architect" post. Not the hyperbole and fluff, but the details on growth, trajectory, culture, current team, etc. I'd be more specific, but since the post was deleted, I can't reference it.

The "Summer 2011 YC company seeks CoffeeScript drinking frontend engineer" post seems very generic to me. It's nice that they mention the industry they're working in, but otherwise, I didn't pick up on much differentiation in the job description from other companies looking to fill a similar role (and the post nearly admits that itself, at the end).

Chicago, IL - Braintree

We mostly work with Ruby/Rails. Our team is talented, our practices are collaborative (pairing, agile), we work on challenging problems (high availability, quality of service, scaling, security), and our devs have 10% time to work on whatever they want. Developers use and love our product. Although we mostly work with Ruby, we also work with Python, Node, Java, .NET, PHP, and Perl. Braintree is profitable, you'll have standard benefits (health/dental/vision), 401k match, ample vacation, an above market salary, and stock options.

More about our people, practices, and software: http://www.braintreepayments.com/inside-braintree/how-we-bui...

Apply at http://www.braintreepayments.com/braintree-careers . If you know somebody who might be a good fit, we'll pay you $10,000 for a hired senior dev referral.

Some processing companies include interchange as revenue and some don't. If Square does, then they still have ~$110,000 / day in revenue, and what you're calculating is their profit. But you're still right that they have high variable costs because of interchange and therefore may not be as profitable as one might think with that revenue.

As an example, Heartland includes interchange in their revenue. "Heartland reported $526 million in gross revenues for the quarter... Interchange accounted for $365.2 million of second-quarter revenues."[1]

At Braintree we don't include interchange in our revenue, so our processing volume is higher than Square's, but our revenue is lower.

[1] http://www.digitaltransactions.net/news/story/3138

Chicago, IL - Braintree

We mostly work with Ruby/Rails, but we'd be interested in a person without Ruby experience who is skilled with testing, software / web dev in general, and GNU/Linux.

More about our people, practices, and software: http://www.braintreepayments.com/inside-braintree/how-we-bui...

Dan from Braintree here. I think a QA team would be valuable; we just don't have one right now. To answer your rhetorical question, regression bugs aren't the only type of bug, but they're one of the most dangerous in a payments system. If there's a bug with an unanticipated use of a library, it will show up in our sandbox environment before merchants hit it in production. But if functionality that works in production breaks because of a change, that's a really serious problem.

We'd love to go into more detail on our thoughts about the future of payments, but we'd like to take adequate time to articulate them well. Maybe we'll do a blog post about this soon.

For a clear disclosure, you work for FeeFighters and as such your comments regarding our customers (I work for Braintree) may not be completely impartial.

Edit: thanks for the edit.

Chicago, IL

Braintree ( http://www.braintreepayments.com/braintree-careers )

challenging problems: a payment gateway is mission critical

web scale: we're growing quickly and working on scaling

amazing team: I'm working with 7 of the 10 best devs I've worked with in my career

top compensation: the best devs should have the best compensation

From link 2:

"I have only heard of one application of JS crypto that made sense, but it wasn’t from a security perspective. A web firm processes credit card numbers. For cost reasons, they wanted to avoid PCI audits of their webservers, but PCI required any server that handled plaintext credit card numbers to be audited. So, their webservers send a JS crypto app to the browser client to encrypt the credit card number with an RSA public key. The corresponding private key is accessible only to the backend database. So based on the wording of PCI, only the database server requires an audit."

The PCI DSS does differentiate between handling encrypted data and handling unencrypted data -- some requirements are only in scope if handling unencrypted data. It's important to note that Transparent Redirect doesn't remove the need for a merchant to become PCI compliant, it only reduces the scope of what's necessary to achieve compliance.

It's true that if your form is hacked it could be modified to send credit card details to an attacker. But that's also true even if you're redirecting the user to a third party page like Paypal to complete the payment. If hacked, somebody could change the Paypal button to redirect to a malicious page.

Chicago, IL - Braintree

Hiring Ruby developers, COO, and customer support

http://www.braintreepayments.com/braintree-careers

There are also many different ways that people pronounce -> and =>, although it might vary depending on programming language.

You can use Puppet without doing all of that. At Braintree, we use Capistrano to upload a tarball of our Puppet scripts and run the puppet command.

sudo puppet --templatedir $HOME/puppet/templates --factpath $HOME/puppet/facts puppet/puppet.pp

We're using it in production at Braintree.

I think that's more of a disclosure than a disclaimer.

How do you know?

At Braintree we pair program almost all of the time. There are some small tasks that people will do solo, but 99% of the development on our payment gateway ( http://getbraintree.com ) is done in pairs.

Chicago, IL

Braintree

http://jobs.github.com/companies/Braintree

Does anybody how much Multi-AZ synchronous replication affects performance? I searched, but I couldn't find any benchmarks. Amazon's FAQ[1] says "You may observe elevated latencies relative to a standard DB Instance deployment in a single Availability Zone as a result of the synchronous data replication performed on your behalf" but they don't quantify it.

[1] http://aws.amazon.com/rds/faqs/#39

What about cash for equity and then use the cash to pay for hosting?

failquicker and fredjiles both make some valid points. There are arguments for including as much billing information as possible, and arguments for collecting the bare minimum. The optimal approach varies from merchant to merchant, and industry to industry.

We generally recommend collecting at least a five digit postal code - this is the variable you have direct control over that helps a larger percentage of your transactions process at the lower qualified rate. Other information, such as the street address, can be helpful for other reasons, but does not effect your processing rate. Collecting the CVV is usually a good idea, as well, though again - this data does not effect your processing fees.

It's been our experience that for SaaS providers such as yourself, traditional fraud is lower than you would see for merchants shipping physical goods. You'll still want to protect against chargebacks, however, and there are a couple options outside of collecting a large amount of data from your customers.

You'll want to first be sure the descriptor that appears on your customer's statements is obviously tied to the product they've purchased. You'll also want to ensure that the number appearing on their statements is a number that they can call and quickly get information about what the charge relates to.

Once your chargeback rate gets much above 1% of total credit card volume, banks will begin to analyze your processing and conduct various risk reviews. However, unless you're experiencing an obscene chargeback rate out of the gate, the bank will usually work with you to lower this percentage before shutting you down completely. Should you start to see chargebacks approach that 1% figure, you can then look at additional options, like increasing the amount of information you're collecting.

Much of this is just good practice for any business - accurately describe your service, be responsive to customer issues, and provide a great product.