The California Corporation Code states that merely residing in the state does not mean you are required to register as a foreign (out of state) LLC and pay the $800. If your LLC is registered elsewhere, and your business is 100% internet only and doesn't have any employees, property, etc in the state, then you are probably fine. Obviously talking to a real lawyer about your specific case is a good idea.
Keep in mind though that you WILL still have to pay California income tax on whatever your share of the LLC's profits is.
Do you have the ability to execute JS on the parent page? If so, the easiest and most reliable way to do this is to use the postMessage API to send document.referrer from the parent to the iframe.
I would highly recommend that you contact the banks for whatever accounts the money went to. If you are able to prove fraud, you may be able to work with them to freeze the accounts and then recover enough funds to cover the chargebacks. You can use the routing numbers to figure out which banks to talk to.
When I was at WePay, we used this to help recover fraud losses. It's not 100% effective (because often the account has already been drained/closed), but it's better than nothing.
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 are a few for Django, but none that I know of that have the full range that ActiveMerchant does.
Another option is to look for processors with an iframe solution like Stripe Checkout or WePay Iframe Checkout (I think PayPal used to have one but they may have killed it). The nice thing about these solutions is that they take care of 100% of the payment form and annoying stuff like AVS, luhn validation, error response handling, etc.
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.
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.
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!
2) You can issue refunds for any payment in your marketplace with the /checkout/refund call. For chargebacks, we 1st attempt to get the money from the payee's WePay account, then from their bank account, and finally from the API application. We do a lot of really cool stuff that reduces the chargeback risk and fraud in general.
In order to accept credit card information directly on your site, you need to be PCI compliant. This involves paperwork, and once you have significant volume, audits.
WePay provides a simple checkout API that you can embed on your own site via iframe. This way you can have the entire checkout process on your own site (unlike most PayPal APIs), but without dealing with the PCI nightmare. http://stage.wepay.com/developer
The California Corporation Code states that merely residing in the state does not mean you are required to register as a foreign (out of state) LLC and pay the $800. If your LLC is registered elsewhere, and your business is 100% internet only and doesn't have any employees, property, etc in the state, then you are probably fine. Obviously talking to a real lawyer about your specific case is a good idea.
Keep in mind though that you WILL still have to pay California income tax on whatever your share of the LLC's profits is.
See 17708.03 10.c here:
http://www.leginfo.ca.gov/cgi-bin/displaycode?section=corp&g...