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.
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.
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.
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.
"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"
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!
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 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!
Running firefox as well and indeed they run a bit slow. Mea culpa. I'll let the right person know!
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).
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.
Pretty sure it's all about whether HW acceleration is enabled or not.
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 =/
Also as pointed earlier Patrick (pc on HN) != Twitter CEO :)
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 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.
You should see a buy button within the tweet itself allowing you to buy the product directly from the tweet.
Many thanks for taking the time to answer.
Stuff like this generally doesn't work because shoppers are less comfortable this far out of context. But I would never bet against Stripe.
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.
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?
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!
It'll behave as expected if you're familiar with the connect `application_fee`.
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 ?
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)