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.
More than likely that developer checked it in IE9 after seeing the great front-end design, and does not primarily browse the web in IE9 (what sane person would?)
Edit: he commented below saying it was IE11 with the IE9 emulation enabled.
IE11 has a feature, Emulation: Document Mode = IE9. No JS errors, so I assume it's a difference of how the "Document Mode = IE9" fails to actually emulate true IE9. Sorry for the false positive.
I recommend you look at image optimization. Loading the /nl flag page from NL takes > 9 seconds. On a connection with 20Mb/s down with one of the best ISPs available.
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.
You are talking about the home page, right? Images are double size for retina displays. Your JPEG version is pointless, the flags are placed on top of the background and need an alpha channel. The page is indeed a bit heavy but not enough to impair the experience, first paint is still under 3s. Remember the audience for this page is 90% software developers, with powerful machines and high bandwidth.
I tend to use a combination on pngquant and optipng on most png based graphics. I'm sure there are builds for OSX out there (probably homebrew recipes even).
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[1]... 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.
> flags are placed on top of the background and need an alpha channel
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).
I'm on a late-2013 rMBP running Yosemite. The page looks nice and animates smoothly in both Chrome and Safari. There may be some deeper problem on your system.
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.
Forced wait is definitely an irritating practice in web today. Not only is is distracting and usually valueless, it's delays what is important: information transfer.
I am not sure why i need to scroll through 6 screens to see the price instead of just being able to click an icon on the first screen and jump to where i want to jump to.
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.
It's running at 5 FPS for me on Chrome. 2013 MBP driving 2 non-retina monitors, lid closed. Seems to work a fair bit better on Safari for whatever reason.
I recently implemented a site with a feature similar to the spinning-globe in the International section[1]: a video element overlapped by text in an adjacent element. I ran into a vexing problem in some browsers where the the text that intersected the video appeared somewhat degraded, as if it were a lighter weight than what was actually specified. In Firefox, only the text directly overlapping the video was affected. But in Safari all text in the entire intersecting div showed this effect, even that not over the video. AFAICT, this is some kind of compositor bug, but I haven't been able to dig up any decent information about it.
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!
Usually happens when the text is above a section of the page that's being hardware accelerated. The browser basically rasterizes the text, which changes the aliasing properties.
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.
I was waiting for half an hour thinking that image will change and tell me something more. Then I figured out that I can scroll down. Stupid me.
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.
Looks very good. I just don't like how mesmerizing the meteor animation is. I wasn't even paying attention to the content. Also it could use a navigation bar once you start scrolling?
In retrospect, the global P2P marketplace that we've launched in 2010 on top of PayPal's API may have been 5 years too soon. Requiring all our buyers and sellers to have a PayPal account was detrimental to our brand. But, we concluded that we "didn't want to be in the nasty business of dealing with fraud, ID verification and international payments" so it made sense back then to leave that up to PayPal. But I would have given anything for a white label solution such as Stripe Connect. Also makes me wonder why PayPal wasn't able to come up with this in 5 freaking years. The technology, the platform and ecosystem was clearly there, just not the insight.
It's likely this was a conscious business decision; PayPal derives value through its brand, which is lost to consumers (buyers) using the platform if the platform becomes a white label solution.
PayPal wants customers to know they can pay with PayPal at business/merchant X, not just their credit card.
Indeed, Paypal doesn't want you to pay with your credit card, and won't let you change your default PayPal payment method. You have to go through a process to select it Every.Single.Time, if you remember, and if you overlook to do it - well, what do you know, PayPal just saved the CC fee...
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).
> However I still have one question: is it possible to delay payments to service providers? In other words to do escrow.
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 patrick@stripe.com."
We will, by default, send out 1099-Ks to the managed accounts. We'll likely provide some flexibility here depending on what the platform would prefer, but we're still talking to platforms to find out what's ideal for them.
We're getting rid of the $0.25 transfer fee and replacing it with 0.5% of funds paid out to managed accounts. We do more work (and incur more cost) if you're using managed accounts, so we think it makes sense.
> Seems like it would require the same amount of work to pay out $10,000 vs. $100,000.
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.
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.
Thanks for the response, Patrick. We run a platform with a large average transaction value, large enough that 0.5% is very meaningful. We would love to take over the onboarding process and entire user experience, but 0.5% is too much to swallow. Braintree provides us with the same functionality and a flat $0.25 payout fee, which is a better alignment of incentives for us.
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.
Specific to your case, if your transaction volume is very high you should contact us. We're certainly open to volume pricing depending on your specific situation, and would love to learn about how to best serve/price your specific use case. sales@stripe.com is the best contact there. bkrausz@stripe.com also works :).
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.
> We want our pricing to align with the best product experience, and a flat fee would encourage marketplaces to pay out less frequently.
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? [edit] 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.
> 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.
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.
Lots of great changes that make a world of difference for marketplace builders. From someone who used to use Authorize.net and spent a lot of money building tools around it... I love Stripe. So simple, so smart. Best YC company yet.
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)
Do you mean a situation where the service provider is not directly providing the service to the customer, like paying out a caterer for your office lunch? I'd love to better understand exactly what you're trying to use this for.
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.
We want to create a service that allows us to ship items on behalf of vendors who just upload artwork. Similar to CafePress. I've been trying to find out if Stripe's "special case transfer" could possibly be used for this but am not having much luck.
(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.
Does anyone know if Stripe have plans -in the rather short term- to come to Asia? Japan, or maybe Singapore?
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...
Check out Webpay for payments in Japan.
Their API was originally supposed to be a clone of the Stripe API, but have gone off with their own API updates based on the JP market.
https://webpay.jp/
I know webpay, but it only issues payments in JPY while I charge my customers either in USD or EUR... It's great for Japanese companies targeting the Japanese market, but my customers are mostly in North America and Europe.
Did you just merge "Connect" and "Marketplaces" so that there is no "Marketplaces" anymore? I saw that stripe.com/marketplaces is a redirect to stripe.com/connect
Yes, they're the one product now. We didn't want divergent products for similar use cases. One feature we think is neat is you can mix-and-match standalone accounts (where the seller uses a regular Stripe account) and managed accounts (where the seller never goes to Stripe).
I'd love to use managed accounts to white label my onboarding, but I don't think my users will be able to absorb the 0.5% and our margins are far too low to do it for them. I don't really need control over the transfer schedule, is there any way to get the white label benefits without the cost? Or is standalone my only option for now?
All of the links on rotation images and company text go to DoorDash for me. Also, only a short line of text is shown and the rest is cut off. "Lyft uses connect to Create an integ"
This is on IE10 Version: 10.0.9200.17267 (work machine).
I'd like to be able to capture someone's credit card for a given amount (deposit), and then charge it later (manually) if certain terms are met. Is this possible under this new system?
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.
If you attach the card to a customer object[0], you can create one off charges whenever you'd like. Stripe will even update the card's details on the customer if the card is reissued[1]. You can then create charges against the card manually through the dashboard (which seems to be what you were looking for based off of your original comment).
No. Creating the customer will charge the card $0.00 or $1.00 (depends on country/bank) and immediately refund the charge to verify the card itself, the CVC, the address, etc. In most cases, this tiny charge won't be noticed because of the refund.
Does this require people who want to be paid to sign up for accounts on stripe? Or can the application initiate bank transfers to the seller, on behalf of the buyer or from escrow.
You have two options: you can have sellers link a Stripe account (and we'll do all the downstream work, like collecting their bank account info and verifying their identity). Or you can create a managed account via API, where the seller does everything from within your app and never needs to go to Stripe.
Can you do the following (in this order): 'Provision' a standalone account with just an email address (with zero work by the account holder to-be) > Initiate a charge (to a buyer) that will ultimately be paid out to that standalone account > Have the seller setup their standalone account (so it's then capable of receiving funds)
I'm trying to figure the work flow that has the least toing and froing for both parties.
Is there any plan to offer some kind of in-between option where the seller links their stripe account, but the application is "sandboxed" in a way that prevents the user for creating, updating and deleting resources like cards, customers,etc? I like the idea of users linking their own accounts, and Stripe taking control of the identity verification, etc, but I don't like keeping all my data in sync with stripe via web hooks.
What does this mean for those of us who already use Stripe Connect? Do we get support for more countries automatically - do we have to change our code - will the v1 API stop working soon? Please send out an announcement current to Stripe Connect API users with upgrade information!
The new site is very pretty, but also very sluggish in Firefox.
Existing Connect integrations will still work: no changes are necessary. Connect has always allowed you to connect directly to accounts in other countries, so no major changes there either.
We're getting some emails out now with more specific "what can I do not"-style information.
Any stripe engineers here to explain how the new multi-party payments work? The documentation has a new "destination" field but doesn't explain if it can be used as a third party in a normal Stripe Connect charge.
I see a new Stripe-Stripe programmatic transfer, but is that the only way to do multi-party setups?
I was just looking at Connect a few days ago and had one issue - the fact that the customer account needed to bear the fees. Very happy to see the option for the platform account to bear the fees. Much simpler for the customer to understand!
So the blog post on connect says "Managed Accounts" are available to anywhere that stripe is supported. However, on the docs, it says that it can only be used in the US and Canada. Which one is it?
probably OT: Is it possible to link Stripe to a credit card so I can perform an online shopping transaction on behalf of my customer without handling their credit card data?
What I was imagining is stripe issuing a credit card that my system can use to perform credit card payments on any generic webshop (either manually or some web scraper) and have that linked to a payment into my stripe account by a specific customer. I am not aware of anyone offering this service.
Charging through the platform has you pay all of the fees and take on chargeback liability, whereas charging directly passed those on to the managed account. This also affects the default statement descriptor and contact info on statements.
Hmm correct me if i'm wrong, but it doesn't seem like it would be that advantageous to take on the chargeback liability just for the statement description unless 'charging thru the platform' also provides a escrow system for the safety of the buyer.
When you charge through the platform we issue the charge on behalf the connected account, so you are never actually in the flow of funds.
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.
In our defense, they keep adding new EU countries. But no, we're not in all of them yet. We're in 13 EU countries, Norway, and Switzerland: https://stripe.com/global
I work at Stripe. We're looking to expand as soon as we can in the 18 countries we support (https://stripe.com/global), but no ETA yet I'm afraid. If you're interested in helping us test a private beta, shoot us a note at connect@stripe.com.
I want to start a code marketplace using Stripe connect. someone posts a job, people bid on it, someone pays the person doing the job, I take the payment and release it when the work is confirmed to be done.
Is there an existing script that I can use and integrate stripe connect with?
