dan_manges

got it. thank you!

dan.manges@gmail.com

There's a service available called Account Updater that provides merchants with updated credit card numbers. It's intended to be a convenience for both merchants and consumers.

http://usa.visa.com/merchants/products-services/processing-s...

I'm the former CTO of Braintree and one of the founding employees. I was there when Bryan Johnson hired Bill Ready as CEO and decided to move to Chairman. The authors of the TechCrunch article were either misinformed or speculating when they said that Bryan "lost his position" and that Bill joining was a "decision made by Accel." Bryan made the decision to hire Bill and move into the Chairman role without pressure from anyone.

Based on their description of the bug, it sounded like the code was modular, but they called the function twice: once when the password reset request was generated, and again when the link in the email was clicked.

  However, when the link was used, canonical_username was once again applied

So after they sent the password reset link, they called "fetchUserIdByName" again, but they passed in a username that had already been canonicalized once. Because of this bug, I wonder if password resets worked at all for users with unicode characters in their names.

They gave one reason in the post. They wanted usernames to be case insensitive, so that if there's a user named BigBird, somebody else can't sign up as bigbird. Case insensitive usernames are also helpful to minimize support issues when somebody forgets the exact case they used when they created their account.

A lot of people rely on other features of GitHub for their workflow: issues, pull requests, comments.

One of my friends did the same thing in high school, except he put too much in the bottle. When he out the cap on, it instantly exploded. He had severe burns on his face, and if he wasn't wearing glasses, he might have ended up blind.

While I don't think Kiera should be charged with a felony, the encouragement to experiment needs to be tempered with an understanding of risks and proper safety procedures.

I would expect most companies serving pages over SSL to already be serving assets over SSL to avoid the mixed content warnings that most browsers currently give when loading non-SSL assets on an SSL page.

Knowing that there is a vulnerability might motivate them to look for it, but given the size of the software, I doubt they'll be able to find it without knowing more.

It's much harder to find somebody who is really good at design and development than it is to find somebody good at just one of the two. As soon as you have enough fulltime design and fulltime development work, you can have people who specialize in each rather than people who split their time between the two.

They likely have separate servers running on the same network. The DDoS might be saturating their network infrastructure rather than causing load on any particular servers.

The previous title on this HN post was more informative without context on what Venmo or Touch is: "Braintree Launches Venmo Touch: One Touch Payment Across Apps"

There's a walkthrough of how it works along with screenshots at https://touch.venmo.com/

I'm a developer at Braintree. The challenge with maintaining backwards compatibility on the server side is handling the wide variety of possible inputs into the system. It's hard to write tests that account for all of them.

I've seen a couple of cases where backwards compatibility can be broken in unexpected ways. For one application that we built at Braintree, we had a client that was sending us an application/x-www-form-urlencoded POST body without the Content-Type request header. We upgraded the version of Rails that this app was using, and it broke that integration because Rails made a change where it wouldn't parse the POST body without the Content-Type header. Unfortunately, we didn't have any test cases in our test suite that made POSTs without a Content-Type. We were able to identify the issue and resolve it quickly, but it was a surprising bug. With client libraries, we can test every version against the upgraded app and know that all clients will continue to work.

Are there interesting request profiling techniques that can be executed on production traffic to analyze requests? I think the challenging part of backwards compatibility is making sure unintentional use cases, that were never intended to be supported, continue to work.

That's not universally true. Unfortunately, the PCI DSS is somewhat subjective and enforced inconsistently, so it's difficult to definitively answer what's required for PCI compliance for a certain type of payments integration.

Even for merchants that use third-party hosted payment forms, it's still common to need to complete SAQ A (a short self-assessment questionnaire) and have quarterly network scans. For example, with PayPal[1]: "Our hosted solution takes a lot of the work out of meeting these standards. The only remaining requirements are a Security Self-Assessment Questionnaire (SAQ) and Quarterly Security Scans."

According to MasterCard[2]: "All merchants that store, process, or transmit cardholder data must be PCI compliant." It's subjective whether using Stripe.js could be considered transmitting cardholder data.

Visa[3] holds Acquirers responsible for ensuring their merchants are PCI compliant. Requirements vary depending on processing volume: "In addition to adhering to the PCI DSS, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants." Notice that for Level 4 merchants, validation only may be required, although those merchants should still be adhering to the PCI DSS.

Stripe has several PCI requirements in their terms of service[4], and their FAQ does seem to indicate[5] that merchants have some responsibility for PCI compliance. According to the TOS "It is your responsibility to comply with these standards." and according to the FAQ: "Most Qualified Security Assesors (QSAs) will want to talk through many of the implementation details before giving an opinion"

Disclosure: I work for Braintree.

Disclaimer: This response is my opinion; I'm not speaking for Braintree.

[1] https://merchant.paypal.com/us/cgi-bin/?cmd=_render-content&...

[2] http://www.mastercard.com/us/company/en/whatwedo/determine_m...

[3] http://usa.visa.com/merchants/risk_management/cisp_merchants...

[4] https://stripe.com/terms/US

[5] https://answers.stripe.com/questions/what-exactly-do-i-need-...

If you're writing your code to work against multiple schemas, how do you test it? Do you run your test suite twice, once with the pre-migration schema, and again with the post-migration schema?

We’re not surprised to see other companies entering the payments market. There are two primary service providers that a tech start-up needs: a hosting provider and a payments provider. There have been good hosting options for a while, but as Braintree identified a few years ago, the choices for payments were not that great.

On the price points, it will depend on your volumes for which pricing is more competitive. Here’s some insight into the approach that we took with our pricing as we bootstrapped Braintree:

http://www.braintreepayments.com/inside-braintree/reaching-y...

http://www.braintreepayments.com/inside-braintree/three-less...

Regarding the customer signup process, we think there is value in getting to know our clients and their business when they sign up with Braintree. It helps to make sure we can deliver the rave-worthy support our customers have come to expect. As with everything we do at Braintree, nothing is ever good enough for us and we’re constantly striving to make things better for our customers.

That is probably how you would do it in this case, but in more complex scenarios, a simple association wouldn't be sufficient. In those cases, putting the code into a service instead of the controller will make the code easier to test and reuse.

I like using service classes for things like this.

  class StoryService
    def self.assign_story(params)
      story = Story.find(params[:story_id])
      user = User.find(params[:user_id])
      story.assign_to(user)
    end
  end

This example is fairly minimal, but with service classes handling workflow and object coordination instead of the controller, the code is easier to test and reuse.

Regarding vendors or business opportunities, I usually respond and politely tell the person that I'm not interested. It only takes a few seconds.

Chicago, IL - Braintree (http://www.braintreepayments.com)

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, and an above market salary.

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

Apply at http://joinbraintree.com or email me if you have any questions (address in profile).

Since their revenue was up, this doesn't mean much without knowing more about "higher than normal spend on hiring, acquisitions and international growth."

git is a great vcs, and github a great hosting platform, even if you don't intend to use features like forking and pull requests

Chicago, IL - Braintree (http://www.braintreepayments.com)

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 or email me (address in profile).

It's not apparent if the 9 million+ daily hits number is taking into account that peak hours will be higher than off hours. It would take 100 reqs/sec if the traffic is even throughout the day, but 375 reqs/sec if 15% of the day's traffic is in the peak hour.

Some interesting techniques in here (e.g. Faking Dynamic Features Using Inline Caching), but otherwise it seems easy to scale to this level when the majority of page content can be cached.

Interesting project, but based on the title of the post I expected more thought and analysis about the challenges of building an application in 48 hours. It'd be interesting to hear about the experience from that perspective, especially for those of us working on weekend or side projects who try to get a lot done in a short period of time.

Code that has been written and/or audited by cryptographers would qualify as 'real crypto.' I don't think anybody has a problem with someone putting together this package; the only problem is with the lack of a proper notice that the code hasn't been audited.

Here's an in depth blog post from Nate Lawson explaining why JS crypto is a bad idea:

http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...