Hacker News new | comments | show | ask | jobs | submit login
Stripe: Relay (stripe.com)
363 points by coloneltcb on Sept 14, 2015 | hide | past | web | favorite | 77 comments



We've been looking at a few other players to do exactly this, i.e. TwoTaps (https://twotap.com/) and Cosmic Cart (https://cosmiccart.com/). The big problem we've seen is:

1) Having pricing and inventory data keep up to date.

2) Reliability and speed, TwoTaps has robots that fill in an order on retailers sites and checkout is slow as a result. Aside from the ugliness of it, I'm sure a lot of retailers don't like this process or necessarily are approving it.

3) Lack of wide number of retailers. Cosmic Cart does direct integration but the the numbers of partners they have right now is severely limited, Target being the big one.

Getting these direct partnerships integrations is hard, but to make this really compelling you really want a wide range of retailers. It will be interesting to see if Stripe, with the relationships it already has, will be able to do a better job of this and getting retailers to buy into losing the control of the full shopping experience.


Very thoughtful analysis! (Stripe engineer working on Relay here)

Getting retailers on-board is definitely core to the success of Relay. As announced today Saks and the SAP Hybris platform are live on Relay and we're working with numerous other retailers as we speak.

For apps, getting retailers to sell on their platform is a huge pain (custom integration to their APIs and payment systems) convincing them to do so. For retailers as well it's a pain. They have to create technical integrations with as many channel out there. That's why we think Relay make sense. We help both side of the equation.

Also, the relationship between a retailer and a channel app in Relay is opt-in today. This is literally a Stripe Connect (think OAuth) connection. But once a channel is onboard, it's nothing more than clicking a button for a Relay retailer to start selling there.

Also I wouldn't say they are losing control on the full shopping experience, they're merely enabling a better one on mobile. When you think of the shopping experience, a lot happen after the purchase (support, shipping, loyalty) as well and I think there are new experiences to create there, especially once the customer receive the receipt from the retailer.


Can I request a Shopify platform integration? My company (www.dodocase.com) would love to sell our products in mobile apps. Feel free to reach out to me at patrick at dodocase dot com.


Hey Patrick. We've just finished building a Shopify to Stripe integrator - it's in beta, but we're happy with how it's performing. Check it out: https://www.shoptorelay.com


Hey.. Does Stripe not offer a direct way to integrate with Relay for Shopify shops? Is there a page that describes this process?

Thanks.


Founder of Two Tap here. It takes an average of three minutes to send the order to the retailer via our platform. On the frontend we use a similar model to Amazon where tell the shopper we're confirming her purchase and handle the process in the background. It's working great for Amazon, and it works great for us for a thousand merchants.

Retailers are incredibly happy by the fact that they don't have to do a complicated integration where they have to maintain a new piece of infrastructure for potentially getting less than 1% of their orders.

That being said, we're huge fans of Stripe. Always have been. John Collison was our mentor during YC. We're looking forward to seeing how they handle the challenges in the space.


Is that a conflict of interest having your mentor launch a direct competitor to your company?


No hard feelings here. We mean it when we say we're big fans of Patrick, John, Stripe. It's unfortunate that we have to compete, we would have loved to work with them.

Our approach is completely different than theirs: light integrations vs deep integrations. We believe their approach will do more harm than good for the industry causing retailers/platforms to invest millions of dollars in building infrastructure that's not going to be ROI positive. Retailers will end up paying to build/maintain that infrastructure part, they will pay the merchant fees, and they will have to pay Twitter/any partner promoting them.


That's good. Market will decide!


  "We mean it when we say we're big fans of Patrick, John, Stripe."

  "We believe their approach will do more harm than good for the industry"
I can see what you're saying, but this was not as well worded as it could have been.


You're right. Can't edit it anymore. Would have deleted the second paragraph.


Also founder of Two Tap here. Just to clarify on the above:

1. Pricing and inventory are realtime with Two Tap -- taken live from the merchant site when a shopping session is started. If only a size S is available on the merchant site then that's what we make available for shoppers in our carts. Merchants don't have to do any integration or manage this process.

2. Reliability has been a non problem for a while, we have a guarantee that we don't lose orders. And the process to confirm orders is async like Amazon -- step 1: we've received your order; step 2: your order is confirmed.

3. Two Tap supports over 1000 retailer integrations.

Thanks for looking into the space!


Agree that the challenge is in obtaining partnerships, but not every retailer needs full control of the shopping experience, especially on mobile. And that's the win - alleviating the need for every retailer to solve the same technical problem.


The challenge for the developer is twofold; 1) Understanding the real time availability of the inventory at the retail partner and 2) Supporting the payment provider of the retailer. In the desktop world this was solved by a straight up affiliate redirect. You arrived at the retailer page and saw your product in a shopping cart or close to it. Of course if inventory was poorly synced you occasionally got an error. This is still pretty common with things like airline metasearch services where the cheap ticket can be gone. Either way inventory was managed. Then you entered your payment method on the retailer site and it was processed by their backend processor.

In the mobile world with mobile optimized apps those redirects don't work. So app developers want to make the payment experience feel like it's happening "within the app" Twitter, Facebook, Pinterest and others all then had to solve for the inventory + payments challenge. Defaulting to Stripe can be problematic if the retailer already has a different payment processor relationship in place. By solving for the inventory piece I suspect Stripe is hoping to help drive momentum around overcoming the processor objections.

Full disclosure I work at Spreedly where we help solve for the payment dilemma (not inventory) by allowing developers to work with a wide range of payment processors and/or affiliate API's.


re Inventory: we want to provide live product availability information to the developer through our API. We encourage app developers to GET latest product info from our API before even rendering a potential Buy Now button. To make that possible we keep product information extra-fresh from big retailers, and even update it on the fly when we see orders failing because the product is out of stock.

re Payments/Processor: So that's where it gets interesting. We have constructed for Pinterest a full payment distribution infrastructure to send payment information securely to large retailers or their processors. This infrastructure will also be used by Relay. Doing so, we believe we bring a ton of value to the ecosystem. But I'm sure you agree with that given your focus!


Congrats on the big day btw!


In other words, since the app system doesn't have links like browsers, a whole new system is needed to emulate them.


Well they could push out and invoke a browser session which is how it was done initially and is still sometimes done. But yes conversion is poor.


Somewhat unfortunately name conflict with https://facebook.github.io/relay/


At first glance I thought this was going to be a blog post about Stripe using Facebook's Relay internally...


Meh, there are only so many words. The two things are in quite different segments, so it should be fine.


Funnily enough, a new blogpost about Facebook's Relay was just posted. It's about 3 submissions below this one!


The animations on this page were not well tested. They run at about 0.5 fps in Firefox, but are completely smooth in Chrome.


Firefox here. Awful lag.


(Stripe engineer here)

Running firefox as well and indeed they run a bit slow. Mea culpa. I'll let the right person know!


Chrome on my MBPr is also dying in a fire here. Chrome on OSX is known for extremely shitty performance because it usually (always?) switches acceleration off.

If chrome://gpu/ says hardware rasterization is disabled, set chrome://flags/#enable-gpu-rasterization to enabled.

Chrome on Windows also will disable acceleration by default if it detects both an Intel and either AMD or Nvidia chipset enabled at the same time, thinking its a hybrid solution (even when it's obviously not, such as an extremely common desktop i5/i7 + high end GPU setup).


Experienced the same thing. Nearly had to kill my browser to unfreeze it, but fortunately I eventually got a Cmd+[ in there to get out.


Amazingly slow, all page movement lags, even closing the tab requires some patience.


People use other browsers than Chrome?

Kidding - but in all seriousness it's very hard to test in FireFox. I constantly find that things run super smooth in Chrome and then I test in FireFox and everything dies.


I take it you don't use a Mac, Chrome is a battery hog on OSX and I'd love to hear it isn't because I might try it again. For now it's Safari+FF for me. It's been a while since FF sucked.


I'm seriously surprised that you haven't switched back to Firefox yet


As another data point, FF Dev Edition averages 52fps. FF 40 is much worse at 40fps.


Also FF Dev Edition, averaging 0.94 fps. It's on Ubuntu though with Nvidia card.

Pretty sure it's all about whether HW acceleration is enabled or not.


super slow here in chrome :(


Blog post: https://stripe.com/blog/relay

This is interesting. How does this work with Apple not allowing purchases unless they go through them?

Edit: deleted the part where I confused square for stripe. My bad =/


Hi! Stripe engineer here. On Apple apps, if you're integrating Relay, you're encouraged to use Apple Pay for seamless transactions! Apple is perfectly fine with that if this is not an in-app virtual good purchase.

Also as pointed earlier Patrick (pc on HN) != Twitter CEO :)


Stripe and Twitter do not have the same CEO, you are thinking of Square.


Actually: twitter, square, and pied piper all have the same CEO.


You're right. I'm an idiot. Ugh


Apple doesn't allow purchases of digital products that don't go through the In App Purchase system and its 30% tax. Physical goods are just fine (hence the Amazon app where you can buy a book, but not a Kindle book).


We have subscription software for Windows where the number of paying authorized user for a customer account are managed via a web interface.

We were thinking about writing an iOS app to let the customer manage her users from an iPhone. Currently users extend their subscription by buying more subscription time via an interface.

Could I add an InApp purchase via Stripe at about 2,90% + 30c or because the Windows software is digital (although not consumed by users on iOS, only the user administrator might use iOS) I should then pay Apple a 30%?


I wonder if along the line Apple would make it mandatory for all payments, made physically (eg: Apple Pay) or digitally (eg: Stripe), to go through by then. I mean, since they are interested in the payments area, why shouldn't them?


30% will kill margins on many goods.


That didn't stop them with e-books.


Yeah, making a copy of e-book is very labor and time consuming.


Oh yeah you're right. But what if someone adds in a digital item into this mix? I wonder how that would work.


Then their app wouldn't be approved or if it's added after the fact would be removed from the App Store.


Physical product sales are fine. Obviously.


Forgive my stupidity but can someone explain why this is so neat?

I see examples that appear to be a links from a Tweet to a product buying page. Is that what's new?

I'm obviously missing something or maybe just not clever enough to get it... Thanks in advance.


If you view this tweet: https://twitter.com/WarbyParker/status/643472513297682432

You should see a buy button within the tweet itself allowing you to buy the product directly from the tweet.


Ah - thank you. I'm so used to viewing Tweets in an App which doesn't support that feature yet so I was just redirected to a Web page.

Many thanks for taking the time to answer.


The amazing thing about this to me is realizing how massively undervalued Stripe is if things like Relay are actually successful. The networks effects created by Relay would be massive.


"Massively undervalued" at $5b?

Stuff like this generally doesn't work because shoppers are less comfortable this far out of context. But I would never bet against Stripe.


Hard for me to imagine Stripe at anything short of a $20-$30b company, so yeah $5b seems super cheap. To me though, I'm bullish on them though I understand that.


This is pretty cool (I'm working on an ecommerce app now). What I'm not clear on is this:

Can apps selling relay products get a cut of the sale?

What incentive is there for a "product discovery app" (or whatever) to sell other products? Can they define some sort of fee %?

UPDATE: Chatted with Stripe on IRC and they clarified that there's currently no way to share sales revenue or let apps define a % commission.


(Stripe Engineer working on Relay here)

Indeed there is no way to do so at the moment. But we have that on our radar and we'd like to construct something that makes sense for apps and sellers.

Some questions related to that: How would you see it working? Isn't ads the new affiliation in the app world?


Its pretty common for Stripe Connect integrations to charge an application fee. With Relay, Stripe would allow some apps that use connect to "move" their products database from their own database to Stripe. Also it allows merchants to sell on more platforms. It just becomes "You can use Relay and Stripe to sell on our platform, however we'll take a 1% transaction fee"


Following in up on this we just rolled out `application_fee` on the Order Pay endpoint (https://stripe.com/docs/api#pay_order).

It'll behave as expected if you're familiar with the connect `application_fee`.

Thanks for the feedback and hope you'll make good use of it. Let us know how we can help with anything help!


So this confirms the approach that we have in mind: the ability to setup a fee at order creation as it is the case in Connect (per charge there). Very :+1: on this.


Following in up on this we just rolled out `application_fee` on the Order Pay endpoint (https://stripe.com/docs/api#pay_order).

It'll behave as expected if you're familiar with the connect `application_fee`.


Yeah, basically what matthewarkin said. You could theoretically do it either way: (a) an app could say "Sell your product with us and we'll take 2%" or a seller can say (b) "I'm willing to give 1% of GMV to apps who list our products"


I believe Two Tap can work with existing affiliate links.


I was looking for this in the API but couldn't find it.


Does not seem like this works off the box. One of our customers tweeted with a stipe buyable product link [1] (from stripe relay) and the buy buttons are not there on twitter.

Support from stripe on this has not been great either with one of their support staff confirming and the other asking us to write to twitter about it.

Has anyone else had success with buyable tweets and stripe relay ?

[1] https://twitter.com/lienielsen/status/646708462043402240


What's the difference between Relay and the Enterprise version of Shopify?


(Hi Stripe Engineer here)

Relay is a way for merchants to route products to channels. We certainly don't want to replace Shopify (with whom we're pretty close) but just give merchants an easy way to expose product information to apps and accepts orders directly from there. In particular, Relay will not provide you with store front, or complex shipping and taxes calculations and integrations.

Ideally Relay should work seamlessly with Shopify, and Shopify users should be able to start selling on Twitter and other apps directly from Shopify through Relay without even necessarily hearing the name Relay (as it is ~the case with their payments currently processed by us)


We've actually just finished a Shopify to Stripe integrator - check it out: https://www.shoptorelay.com - we're listening to feedback to at support@shoptorelay.com


tomasien: For some reason your comment is being marked as a [dupe], even though it's the only one of yours in this thread. There's another deleted thread[1]. What's going on here?

[1] https://news.ycombinator.com/item?id=10216136


I started a thread on this the same time this thread started. When I saw this one rising to the top I deleted it - I thought duplicate submissions were supposed to get merged in automatically and counted as upvotes instead of separate threads but I guess that didn't happen. I copied my comment from there to here.


Generally they do, but its a very simple match by URL, so yours might have a tracking query param or something that you didn't strip (or it might have been a link to the blog post)


I checked, it was an exact match. It was weird - thanks for helping!


We unkilled the comment in this thread.


Thanks!


Feel free to repost your comment here!



I did, it's being marked as a dupe I guess? To me it just looks like a comment but maybe it's invisible to others, I don't know.


We've made an mobile shop on iOS with integration to Shopify. We are planning to open source it once we release our own shop. Let me know if anyone is interested in trying it out.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: