If you're putting a lot of volume though Stripe, all those things are possible.
Notwithstanding Stripe's SaaS-y "all pricing and deals are public" branding, they definitely have a BD team who can set you up with more direct contacts for certain types of questions, different rates than are publicly posted, and APIs that aren't public (to name a few things).
I'm a hue PyCharm fan, but if this is true then vim and Sublime must be barely usable. Python, it's great at...but open a big JS file and it...will...take...forever...to do the JS syntax highlighting, if it ever finishes. CoffeeScript is even worse, and almost always crashes.
It's always a little weird, because I have no performance issues anywhere else in it, and it's got ~7GB of RAM it could use.
I use PyCharm every day and IntelliJ and I have never had this problem. Maybe it's a resource issue with your hardware though and your version of Java. I use the new versions that bundle OpenJDK on a newer Macbook Pro.
Stripe's terms say that "Marijuana dispensaries and related businesses" are prohibited. You're certainly not a dispensary, but reporting software designed and advertised for one sounds like a "related business" to me.
Up until last summer (when the Government won a case letting them change the law), having your expensive house owned by an offshore corporation was the canonical way to avoid a particular type of UK tax called Stamp Duty.
When you buy a property, you have to pay Stamp Duty [1] on the value it's sold at. Stamp Duty uses marginal tax brackets, and the highest one (for the portion of the transaction over £1.5M), is 12%...so it adds up if you're buying a large house.
Given that the tax rate for buying "shares in a foreign company that has a share register in the UK" is a flat 0.5%, the scheme was that you set up the house as the only asset of an offshore corporation registered in the UK, and instead of selling someone the house, you sell them the shares of the corporation. The buyer can now inhabit the house at their leisure (since they own the company that owns it), but the direct ownership of the house didn't change - so no Stamp Duty was triggered.
There are likely other tax benefits to having your expensive house owned by a numbered corporation, but Stamp Duty is/was a significant one.
Even with the new taxes, people were/are still purchasing through foreign companies (that way, you avoid the 0.5% stamp duty when the shares are sold?).
They do have to pay the Annual Tax on Enveloped Dwellings (ATED) then though, which is basically an annual tax that needs to be paid when a corporate entity (i.e not a person or a trust) owns a property.
On a (for example) £7M house you would have paid £750K Stamp Duty, or if sold though a corporate transfer, £35K of tax on the shares and £36K/yr ATED - so holding it for less than twenty years would have been a deal, assuming no other possible savings from the corporate option.
Even though this law should dissuade people from buying through corporate vehicles, all the existing housing stock (i.e. probably nearly all the property in Kensington & Chelsea, Knightsbridge, Belgravia, etc that is from the 1700-1900s) that is worth holding through SPVs is already held through SPVs, and will not be captured by this change.
Developers usually split up their new buildings in separate entities before they build anything, because I believe only stamp duty is payable on the land then. Instead of then selling the property, they sell the shares, which is taxed as capital gains (instead of corporate income) for them. Good times in the luxury market, since share sales in corporate vehicles tend to be tax free.
It's still very much a win-win situation for both seller and buyer (probably much less for new developments after this change), so no reason not to do it. I don't think this will raise significant amounts of tax any time soon. :)
The biggest thing to remember when dealing with PCI DSS is that it's not the law.
Your PCI obligations come out of a commercial agreement that you have with your processor, which comes out of commercial agreements they have with VISA/MC/et al. That's not to say that it's not a well-defined standard that you're going to end up having to follow in some way, but rather that statements like "Both Litle and Recurly flat out say that you need SAQ A-EP" have more wiggle-room than it would sound like, depending on the rest of the deal you're presenting them with.
If you're a Level 3, I'd argue the goal should be to keep yourself on SAQ-A - the methods of which are pretty well-understood now. Pick a vendor which has a tokenization service designed to be hit from JS (they all work the same way at their core - download JS which contains an implementation of RSA and a public key, browser-side encrypt the CHD using that, send it off, get back a token). Put your payment form inside an iFrame which is served from a PCI-compliant host (like S3). Once tokenization is complete, send the token from inside the form back out to the containing page using postMessage or in the querystring.
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the payment processor (often referred to as 'Direct Post')
Will they change PCI DSS again to remove the iFrame rules? Maybe, but given the speed the PCI council moves at (and the warnings they give before changing things), I'd deal with it then.
Lastly, if you're thinking of building a service which white-labels credit card processing and sells that processing as a service which your customers can then resell...don't forget about PCI PA-DSS
Can you highlight a few of the reasons you love it, in comparison to HipChat? When we ended our trial month and announced we were going back to HipChat, the biggest reactions was "OK".
Multi-team support is a big one. HipChat doesn't let you participate in multiple organizations. When you're doing B2B stuff, or contracting work, or just interfacing with some external team (eg., designers), being able to chat in the same room without having to jump through a bunch of hoops is super important.
For me, there is also a bunch of minor detail where Slack wins. Slack just looks better, behaves better with choppy connections, and has better code pasting support. It also does much better with automatic link extraction (HipChat's Linky is annoying and won't let you remove the automatic description). Lastly, Slack has integration playbooks that automatically uses APIs to configure stuff or (when that's not possible) gives you the recipe; for example, the Github and Zendesk integrations will automatically register the app and webhooks for you, almost no manual setup needed. HipChat is all manual.
And for the love of God, HipChat, fix your inane emojis. Immature 4Chan memes (trollface etc.) have no place in a business, not even among developers.
Do you find them that much better? We're a small HipChat-using company who moved three teams over for a month, and the communal response was "eh?". It's no-doubt prettier and easier to write integrations, but for the core competency of chatting, the two were very similar (and most people preferred the native HipChat apps to the Slack browser one). It's big selling point for us was integration with Google Docs, and in testing we found that it didn't work that well.
It's also 3.5x more expensive. In absolute terms that's not much (<$400 a month), but no one could point to $400 of incremental value in it. If we fully embraced it and turned off emails for those teams, would we see it? Maybe, but we'd still need emails to deal with external vendors, and there's no way that we'd get non-developers to see it as an email replacement.
If you're experimenting, use `git config --global credential.helper 'store'` to set git to store your credentials in a plain-text file. Then (if you're on GitHub), generate a personal access token (https://help.github.com/articles/creating-an-access-token-fo...), and then use that as the password - once you've entered it once, it should be stored and not prompted for again.
Examples of e-commerce implementations addressed by SAQ A include...[merchant] website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process...Examples of e-commerce implementations addressed by SAQ A-EP include...[merchant] website creates the payment form, and the payment data is delivered directly to the
payment processor (often referred to as 'Direct Post')
Right. Which is why SAQ A-EP was invented -- to prevent merchants from gaining compliance based on the loophole that they are using a js library or offsite link to collect payment.
Notwithstanding Stripe's SaaS-y "all pricing and deals are public" branding, they definitely have a BD team who can set you up with more direct contacts for certain types of questions, different rates than are publicly posted, and APIs that aren't public (to name a few things).