It looks modern yet very readable thanks to great typography. Loads fast. Fully usable on mobile as well. E.g. Gets a hamburger menu on Mobile. The featured client animation is simpler. The spinning globe icon is replaced by a static image. They have absolutely top notch front end engineering talent.
This is in huge contrast to the current trend where they want to hijack browser's scrolling behavior for absolutely no gain to the end user.
Edit: he commented below saying it was IE11 with the IE9 emulation enabled.
There are 3MB of images on the page; the problem seems to be the high-res map, which weights in at 1.5MB. This image is 2290x798 and it's in an element of 1145x399. I've halved the resolution and converted it to a JPEG, now it's 0.2MB. To make it even easier for you to show the designers I've uploaded it here: http://imgur.com/XcGllGz.
EDIT: it's worse, almost every image in the carousel is double-sized and unoptimized.
Otherwise it's pretty.
This will bring the color palette down to less than 256, some images will work better than others, in this case I didn't notice a difference and the size went from 434KB to 133KB in size using the batch file I normally use for this... I haven't checked recently to see if there are newer tools/versions for use, I keep several utils inside my dropbox for windows usage.
Ok, that explains the huge PNGs; can't they be rendered as-is (i.e. include part of the background in the foreground picture?
> first paint is still under 3s
That's really slow. The jankey animation (yay Apple) and rasterized image rendering is horrible; it's a throwback to the late-90s internet.
> the audience for this page is 90% software developers,
> with powerful machines and high bandwidth.
I.e. me, and I find it horribly slow. I'm using a year old rMBP and I have a pretty good internet connection (20MB/s, 10x what I could get in the UK and I actually get pretty close to the max all the time; for a comparison: http://www.webanalyticsworld.net/2014/08/internet-speed-gap-...).
Sure, I'd love fiber, but that's not exactly broadly available (though if I could move my house 1km to the east I'd have it).
1. Forced waiting for transitions everywhere. For a page I'll probably only ever visit once. You want to ease-in to things. I get it. But you shouldn't hide them. If you want a dithering transition as you scroll, do that. Don't fade-in. There's almost never an excuse for that.
2. What's the point of the "meteor"? To look cool? Is there any point at all to the businesses scrolling in it? Because I don't know how many there are. There's no link to view them all. There's no points to click to go back a pin and re-read one that caught my eye.
I don't know. It just feels like people are obsessed with having the coolest Flash splash screens again.
Maybe there is a way that I just couldnt figure out. Why is it folks would never today implement a 6 or 7 step wizard with a bunch of next buttons. but its considered a good idea to do so with scrolling is involved...
would also like to see a big down arrow or some kind of standard indicator when a desktop page has this scroll behavoir... i was waiting a the starting screen for quite a while and then clicked on the 4 little icons before i figured out i just had to scroll down forever.
I do note that Stripe's page isn't exhibiting this issue, but don't see anything that appears to be a workaround or otherwise unconventional.
Anyone have any color on this? Is this a font-specific rendering issue, e.g. so Stripe's fonts don't exhibit this problem? Or perhaps the presence of a background image on the li tags forces the compositor to behave? TIA!
Either move the text off to a separate sister div, or move the animation to a div with a higher z-index. Or you can set -webkit-font-smoothing: anti-aliased - that will set all of the text to same antialiasing settings as GPU accelerated text.
Then it occurred to me that we do the same thing on our home page: we have animation which makes people (stupid like me) wait a little thinking that we will tell them more info - even that info is available only if you scroll down. Stupid me x 2.
But, it is very nice and well formatted. 10/10 would refresh again.
The whole page is slow to load, solutionyogi must benefit from different optimisations, but on an ipad it seems to get the worse of both worlds.
Even after the page is loaded, the sections are mostly blank until the animations kick in.
Their features page  in comparison has a similar concept but is much clearer, simpler and very fast to load and navigate.
PayPal wants customers to know they can pay with PayPal at business/merchant X, not just their credit card.
The kids these days call it eBay.
However I still have one question: is it possible to delay payments to service providers? In other words to do escrow.
Here is our use case: a client books a service (maybe with 30 days in advance), we need to charge the client at that time, but we won't pay the service provider until 24 hours after the service has been provided (so that we've made sure everything went fine).
Yes: "You can control the transfer schedule for your recipients, which should effectively cover what you need to do. (Sorry this isn't clearer in the docs.) Feel free to email us, too. I'm firstname.lastname@example.org."
If so, you might want to make this reporting requirement more visible in your documentation.
Why scale the fee?
Does this apply to marketplaces/accounts migrating from Balanced? There was an assurance that Stripe would honor Balanced's pricing. https://www.balancedpayments.com/stripe/faq#will-our-pricing...
If you require marketplaces to use managed accounts then it's an extra tax, no?
We want our pricing to align with the best product experience, and a flat fee would encourage marketplaces to pay out less frequently. This pricing makes it easy to do daily transfers. In addition, there are actually reporting obligations and such that kick in at higher volumes, so it's not completely scale-independent.
> Does this apply to marketplaces/accounts migrating from Balanced? There was an assurance that Stripe would honor Balanced's pricing. https://www.balancedpayments.com/stripe/faq#will-our-pricing....
No; we'll grandfather both Stripe Transfers API (the old system) users and Balanced users. That said, this works out to be cheaper for most people -- most users aren't doing $100k payouts.
> If you require marketplaces to use managed accounts then it's an extra tax, no?
We don't require that they use managed accounts. Over time, I think standalone accounts will become the better option, since it's much less work for the marketplace.
If we were to use Stripe managed accounts we would start bearing all transaction risk plus a 0.5% fee. As a result our payout frequency would decrease drastically as we'd implement a huge delay, only paying out once we were positive the transaction was risk free.
Is Stripe's preference for platforms to continue to use standalone accounts vs managed account long term? We have a strong affinity to Stripe as a fellow YC company, but struggle with this offering.
More generally, international KYC and compliant payments are quite hard, and our pricing there is very competitive. Domestically we saw that many companies were already paying similar rates on our fixed-fee pricing, so we weren't actually hurting customers in the US (on the contrary, we were encouraging more frequent payouts for the same rate, which would help everyone by making a more efficient system). We felt that the benefits of consistent pricing were worth it here.
Re standalone vs. managed accounts: our preference is that we make standalone accounts such a great and easy-to-use experience that everybody starts using them, because dealing with things like information collection and tax reporting is annoying. However, we're letting our customers dictate that. If managed accounts become immensely popular, it means we haven't made standalone accounts easy enough to use, or we've made an incorrect assumption about the world (likely a combination of both). Regardless, we intend to support managed accounts for a very long time, and have already had them around in some less-built-out form for quite a while.
I don't understand how increasing pricing from a flat fee to a percentage encourages marketplaces to pay out less frequently. The cost is so nominal that it far outweighs any percentage fee.
> We don't require that they use managed accounts. Over time, I think standalone accounts will become the better option
Better for whom?  My customers are not tech savvy and only want to deal with one fintech vendor, exposing Stripe to my customers seems like it's Stripe's best interest.
Our goal, as Patrick said, is to allow people to pay out more frequently. A flat fee ties your costs to number of transfers, which seems unnecessary in a lot of cases. If a seller just earned $10, they should get their $10 (at a cost of a nickel).
> Better for whom?
For customers and platforms. If we do our job right, standalone accounts should be so easy to use and user-friendly, even for non-tech-savvy customers, that it's clearly the better option for everyone.
That being said, it's not like we'll kill off managed accounts: there'll always be a good reason to have a fully customized experience. Making standalone accounts good enough to be the better option more often is a goal we strive for, but that's for our customers to decide.
There's a temptation to just let the money sit in my Stripe account, then payout using a "Special Case Transfer"
But this approach seems non-compliant.
How long before we can payout service providers so the charge is seen as coming from my business, instead of from my customers? (This appears to be the compliance issue.)
An ACH "source" is potentially a good solution (and apparently in beta), but I imagine I'll incur additional fee. Perhaps using my own bank account as a source will be free, but using others will be paid? (Kinda like managed accounts)
The short answer is that we're also really excited about the "many-to-many" use case of moving money around. There are many hurdles to getting there, and we're checking them off one by one. This is a leap towards that eventual world.
Pretty much. But it's a little hard to envision at that scale.
Think instead about a large company with a set of approved vendors. Execs submit purchase orders to the vendors. The vendors get paid out by check.
Instead, you can payout the vendors through Stripe.
Edit: As I think about this more, I don't think it should be free from my own account, but it's hard to reason what ACH pricing should be. I can send an automated check for $1.50 with Lob today.
It'd be great to be able to do with Stripe what we can do with POs. Here are Three POs for three vendors associated with this purchase (80%, 10% & 10% respectively).
And then directly push the funds to each with separate transactions, without having to have a 'master account' that pulls in 100% (and takes the full fee structure on the nose), then internally/itself pushes out 80% and 10% to others.
(i.e. Accepting a $30 charge for a customer and doing two transfers using source_transaction, one for $10 to Vendor 1 and one for $20 to Vendor 2)
I know that it would be compliant if we setup a Stripe account for each vendor and created the charge directly with their Stripe account but we want to be able to have customers checkout with items from multiple vendors.
I know this question always comes up so it must be getting obnoxious, and I apologize for asking it yet again, but it's a testimony to how great Stripe is. I'd go further: I think it is a competitive advantage for a startup to be in a country supported by Stripe vs others.
I have a Japanese tea subscription service (https://tomotcha.com), so my business is anchored in Japan. Yet because there is no acceptable payment system here I take payments abroad with all the tax headaches that it entails... It's ok for now because Tomotcha is pretty small, but when it grows I will have to switch.
I'm looking forward to the growth of course, but not to the switch...
This is on IE10 Version: 10.0.9200.17267 (work machine).
There's a link to learn more about managed accounts:
Which just shows "An unexpected error occurred"
I've been looking at performing this functionality with utilizing a free trial; setup a subscription payment of one year with a three month trial.
If the client meets the requirements, let the subscription charge after three months (then cancel all subsequent subscription payments). If they fail to meet terms within the three month window, cancel the "trial" all together.
I'm trying to figure the work flow that has the least toing and froing for both parties.
Setting up managed accounts, including international accounts, ID verification, and 1099-Ks, costs just 0.5% of funds paid out.
Transfers to standalone accounts are free.
The managed account page appears to be down: https://stripe.com/docs/connect/managed-accounts
The new site is very pretty, but also very sluggish in Firefox.
We're getting some emails out now with more specific "what can I do not"-style information.
I see a new Stripe-Stripe programmatic transfer, but is that the only way to do multi-party setups?
Asking from New Zealand, any hints on the "more coming this year" countries?
Automating some shopping cases might be another.
Re: chargebacks, there are 2 situations where this becomes relevant:
- With managed accounts, you're responsible for losses in the end anyway. This mostly dictates which account balance the fee comes from.
- Generally if you're providing the customer support it can make sense to take on liability. Take Lyft for example: they don't debit driver bank accounts if they get a chargeback.
Best progress response I've seen.
Minuses: global financial earthquake
I've quickly developed a page to view the progress: http://0xff.lt/stripe-spread.html
Still more than 50% of EU left. And Switzerland does not seem to be moving anywhere, hehe.
I've quickly sketched a website with the current supported countries: http://0xff.lt/stripe-spread.html
very thrilled about this and being able to payout internationally as a marketplace!
Is there an existing script that I can use and integrate stripe connect with?