LeBlanc

A lot of this research is going towards developing neuro-prosthetics. The primary application of neuro-prosthetics in humans is to give paraplegics either the ability to control a cursor with their mind (a huge improvement in standard of living) OR the ability to control a prosthetic arm or leg with their mind (the long term goal).

Currently, this is only available with invasive brain surgery that can often have complications. So money spent on better imaging and implant technologies will have a strong positive impact on the field.

Interestingly, the researchers I know in this area are confused about why such a big deal is being made about this "Brain Initiative" because the amount ($70M) is actually not a lot given how capital intensive this type of research is and how many labs it will be spread amongst. Still, any funding is better than no funding.

There's not a lot you can to do prevent your site from being targeted by a DDoS attack.

If you are unfortunate enough to get DDoS'd you probably have enough money to pay for a service like Prolexic, etc that will shield you almost entirely from DDoS attacks. DDoS protection services are used to people signing up during an attack, so they are usually pretty quick to implement. The downside is that services like this tend to be expensive and can mess up regular traffic (especially if you are providing an API).

Unfortunately, it is not that easy because you are just one part of a larger financial system and have to deal with horribly outdated banks, etc.

I used to work at WePay and a lot of the complex technical work we did was to make sure that the craziness and unreliability of the entities lower in the chain never reached our customers. In a credit card transaction there are multiple parties including the issuing bank, the acquiring bank, the processor, the gateway, the card network, etc. Issuing banks in particular often return bogus error codes, time out, or have provide inconsistent results. I remember Delta SkyMiles rewards cards being particularly problematic.

And with payments there is very little margin for error because you are dealing with people's money. Customers get very upset when you cannot charge their card, and it is not helpful to try to explain that the problem is downstream (for example the issuing bank is returning bogus error codes). The worst is the dreaded "general decline"; which is when an issuing bank declines a CC transaction but doesn't tell you why.

The ACH network is even worse. There is no synchronous way to determine if an ACH transaction was actually successful. NSF errors (not sufficient funds) can come in 3 days after the initial transaction. I hope that Dwolla's planned ACH replacement actually takes off because it would be a huge improvement.

Kohana is a very solid framework.

The best parts about it are that the source is very readable and it's extremely easy to override the default behavior of many modules. I would strongly recommend doing this as much as you need to because Kohana's defaults may not make sense for your usecase. The biggest downside is that v3 is very different from v2 and a lot of the documentation and help still assumes v2 (this is why easy to read source code is important.

Sorry, I should have made it more clear that with stripe you aren't liable for all of the PCI spec (I edited my comment to reflect that).

Either way, I think Stripe is doing awesome work and I hope you keep kicking ass!

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the PCI spec (just part), which is one of the awesome things about the service]

With the iframe, the checkout form is served from WePay's domain, so javascript on your page can't directly access elements on the checkout form. There are still potential vulnerabilities such as clickjacking (we do some things to protect against this), but since the CC form is served from our domain, only we are liable for PCI compliance.

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service.

The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account based system.

Unfortunately, even with Stripe, you are still liable for most of the PCI spec (our iframe checkout gets around this). We made a bet that there are a lot of developers out there that who are willing to give up a little on the customization side to not have to deal with the headache of PCI compliance (we've gone through that process ourselves and it is complicated and expensive).

I highly recommend olark or a similar onsite live chat feature.

olark is great because its much lower barrier of effort than email, so your customers often come with questions they might not have bothered with via email. You can get some great insights into how people use your site, and you'll learn about bugs much faster.

We do accept international credit cards, but unfortunately the person accepting money has to be in the United States. We're working hard to expand internationally though!