While there are lots of antecedents (this is, after all, just a checkout page with a URL), and even though this was substantially inspired by the growth of the no-code ecosystem[0], the thing that's interesting to me about the payment link "space" is that it's a use case that really took off in other markets first -- Nigeria, India, Philippines, etc. I suspect that staying abreast of important new patterns emerging outside US/Europe will become more important for many businesses in the years ahead... there are a lot of legacy assumptions being questioned.
And feedback very welcome on our Payment Links product itself!
Hey there, I'm an American in the US I've done business over chat apps for several years. Mostly being around Chinese, Nigerian, Indian, Phillipine and Malaysian crowds on those apps. You just have to listen, the trend has been clear but in the US people derive clout from pretty irrelevant things, such as a domain name, domain name information, and people with ideas think they need SEO and other marketing gimmicks.
The biggest trick is the banks. When using fiat and opening a bank account for an incorporated business, the bankers often ask for information on the company like website presence of marketing materials.
For the past few years I've been able to point to articles about commerce in Asia being chat app based, to get past that. Bankers don't actually care, but you do need to know how to make them not begin to care.
I’m an English speaker currently in Mexico City. The webpage first opened in Spanish based on my location.
It only took a few seconds to figure that I could change the language just above the footer, but my UI recommendation would be to put the location/language switcher next to the upper right sandwich (I’m on mobile) in a circle with the flag of my default country/language.
That would be much faster to find and have the added benefit of displaying how many countries and languages Stripe works in.
Good feedback -- thanks. We've long struggled to find the right balance between "convenient/automatically correct" and "non-confusing" in site localization.
Accept-Language header, to me as a developer, has always been the better approach to this problem. It has language prioritization built-in to the value.
This reminds me of the recent uber post that talked about how uber SEEMS simple because it is just a few screens but it has to handle thousands of possible international language and location permutations. And keep the install under 100MB or whatever the app store not over-wifi limit is nowadays.
How does uber default the language for you? They've got the advantage of your registration so probably easier...
> And feedback very welcome on our Payment Links product itself!
The most useful addition would be another text box (or full form) in the payment link setup to specify sending some custom text to the payer upon payment (by email or on-page or both).
For example a "Thank You", but also a "here's the private link to the thing you bought, here are the details, here is the password, here is the timeframe for shipping, here's what to do next", etc.
Excellent idea, and one we're very excited to build soon. We have an initial prototype of what this may look like; would love your feedback. Drop me a note at jackerman@stripe.com if you'd be up for a quick chat!
I suppose the danger to this is minimized but will stripe always require an affirmative action confirming the transaction on the destination link? I can see some issues related to link unfurling and pre-fetching activating the link before the user intends to interact with it along with malicious sites that inject JS to automatically follow the link.
I'm curious if you have analytics collection on the first use case since it seems like a pretty risky privacy violation in terms of user tracking but honestly not far beyond shenanigans that bigger players pull (Facebook/Amazon).
But I'm really curious about the second use case - the no code approach is really nice and flexible for sending payment requests over alternative media (i.e. discord) but it feels like this might open the door a bit more to phishing users via redirection - do you happen to have any security ruminations on that topic that you've made public or be willing to share?
On the Stripe side, nothing is collected from the customer til they click.
We've thought a lot about the security side of things—one of the reasons why Payment Links has its own subdomain and the payment page is hosted by Stripe.
The link itself is global, not local to a transaction. So I can have the same link posted on my Github repo to support development or in my HN bio to buy me a coffee. That link then generates a checkout session when you visit it, and if the payment is actually made, then I see a payment entry in my dashboard. But the link is just a common global initiator.
The one feedback I'd give is that it's hard for a user to know they can adjust the quantity on mobile. You have to click the "Details" link in the top right, and it's not really obvious to a user this is where they should go do this. (i.e. they may well think that they can't update the quantity).
Thank you for this feedback, James. Totally agreed. We'll be making significant improvements to this flow on mobile coming soon. Drop me a note at jackerman@stripe.com if you'd like to give us feedback on an early prototype!
On the page you mention selling worldwide. But the simplicity of the paylink break down when you sell worldwide, as you have to both collect and remit taxes for each country (as in find a way to to fill the paperwork and pay taxes in separate countries).
That’s an additional service to find and connect if you use stripe, sadly.
That’s why when we launched Lab Surprise [0], with 19 apps from developers in several different countries, selling worldwide our bundles, we ended up using Paddle: they are the merchant of record, collect and remit the correct taxes in each country. Yes, it’s 5%+0.5cts but for us it was worth it.
I’m pretty sure many sellers using Stripe paylinks will just never do the proper remittances in countries that are not their country of origin, but that might end up bitting them hard.
Making tax remittance invisible is what can unleash instant worldwide micro-stores without hidden task risk
Congratulations on the launch! This looks super nice, and if I understand it correctly, it's _kinda_ like creating a Checkout Session and redirecting the user, but more direct.
About a year ago I was toying with the idea of creating a SaaS/product that worked completely without JS, and the only hurdle was that there currently is no way to simply answer redirect a client directly to the Checkout page after creating a Checkout Session in the backend. Currently, you have to create the Checkout Session, send this to the client, load StripeJS, and _then_ you can redirect to the Checkout page.
Seeing that the Payment Link is basically the same thing, only that instead of a backend, the seller can create the Payment Link ("Checkout Session") in a dashboard, it doesn't really seem like the StripeJS-step I mentioned above is strictly necessary.
I hope you'll add a way to get the URL when creating a Checkout Session in the backend, so that the dream of a fully-functioning noscript SaaS might one day come true :)
Thanks for the great feedback, Daniel! We'll be launching an API for Payment Links soon; drop me a note at jackerman@stripe.com and you'll be one of the first to try it out.
Hey pc! Is there a way to tie a digital delivery to the payment? Let's say you're selling an e-Book or an audio file or the latest collectable nonfungible (jk). Is there a way to have Stripe send a digital file or product upon successful payment completion without requiring a website backend to do that?
We don't have plans for Stripe to help with digital delivery today out-of-the-box (you may want to check out some of the many Stripe plug-ins that assist with that: https://stripe.com/partners/apps-and-extensions?q=digital). If you want to roll your own email solution, you can listen for webhooks to trigger an email after a payment: https://stripe.com/docs/webhooks.
Thank you for taking the time to come on here and discuss and answer questions! Its great to see someone like you taking the time to answer questions from random people on HN.
It really does make me want to consider working with stripe for my next project (or, consider working for stripe for my next job)
Hey there Patrick, congrats on this launch and Stripe's success thus far.
As to your reflections, I'm wondering how Stripe ingests these various emerging patterns around the world (especially as you expand to unfamiliar territory) and prioritize bringing them into your products?
IOW: if N trends at various stages of the adoption cycle are happening 7K miles away, how do you think about placing different bets on each, especially when the cultural moments may be wildly different than, as yet, Stripe understands?
No wonderfully structured answer, I'm afraid. We do now have engineering teams in Japan, Singapore, India, Ireland, Mexico, Nigeria (via Paystack), and elsewhere, and it helps a lot to have people "on the ground" who really get what's going on. Ultimately, we want to identify the patterns that should be globally popular but aren't yet. To do that, though, there's ultimately a lot of subjective judgment required.
I'm reluctant to hijack this thread, but please support payments in Panama. These payment links would be a big deal there. Panama uses the USD and has the best developed banking and financial services in all Central America. I've been hoping stripe would get here ever since you launched as a company.
When you launched Atlas I've considered it, but the accounting and taxes are complicated and expensive. I believe one even needs to charge state sales taxes in some states.
I couldn't be happier with Stripe, specially when collaborating with European projects, that made local payment integration a breeze.
I formerly lived in Sri Lanka, and the country lacks a payment provider worth their salt, let alone an innovative one like Stripe. Perhaps extending the countries that Stripe supports can have the biggest impact.
Not related to payment links... but I would love to see Stripe take on handling in app purchases. (basically a webhook and management layer over the terrible native APIs) Companies like RevenueCat are halfway there but have nowhere as nice of an API or dashboard as Stripe. I run a cross platform (web/ios/android) app and would love to do payments all under one platform (Stripe, that is). Apple and Google subscriptions have so many complexities and edge cases that companies like RevenueCat and Qonversion are enormously helpful, but they themselves have many bugs and issues that I've ran into.
This is a great idea! It's best to let buyers simply buy and move on with their lives. This seems to do that. Don't make them do anything when they already want to say yes.
I tried this out today and a few things went wrong for me.
First, the link that I was given to send to the other party was a tinyurl.com link. This concerns me because I don't think that Stripe or PayNowLink has control of tinyurl.com. If tinyurl.com is exploited then someone can reroute people to a totally different site.
Second, Privacy.com debit cards didn't work for me. I've reached out to support to see if that's something they can fix. Is that a known issue?
A bit of a non sequitur, but have you further pursued the investment/initial funding you made in Stellar some time ago? The cryptocurrency markets are of course highly inflated at the moment, but long-term, do you still see promise in the concept of "email for payments?" (This is how Stellar brands their technology.)
I would be super interested to know if there are any blockchain projects or related corollaries that Stripe is working on.
Congratulations on another cool product! I happened to build something to scratch the same itch a couple of weeks back, using Stripe Checkout, iOS Shortcuts, and serverless functions: https://baildon.co/writings/contactless-pos
This looks like a much simpler way to create subscriptions. On the back of that connivence will it also support calling webhooks? It would be great to have our backend systems be able to create a user so we can relate a subscription from Stripe with a user without needing to keep querying Stripe for new subscriptions.
Can you think of a most-popular use case you've seen payment links used for outside the US? Like, are people selling goods, or e-content, or services? And thank you for making e-commerce more seamless.
We've been live with Payment Links in beta to around a hundred sellers for the past few weeks, and we've seen businesses selling both digital goods/services, as well as physical goods. Sellers have been sharing Payment Links on social media, via email newsletters, and in support interactions. And we've also seen some sellers generate QR codes that send their customers to a Payment Link. Excited to see what you use Payment Link to sell!
You can use Paystack (which we acquired last year) in Nigeria today. You can sign up instantly for Stripe in India today and request an invite for access for Philippines over at https://stripe.com/global. Working on full availability of both as quickly as we can.
I thought about building this on top of Stripe (and after seeing this I am glad I didn't). My use case was to replace cashapp etc for all the musicians doing live stuff on the web. They all need logins which is unnecessary friction if you just want to give someone money.
It always amazes me when things like this happen. If you look at the comments on this post you'll see people responding as if this a terrific new idea/frontier. Others respond with links to existing solutions as you did; Gumroad was my first thought, too.
And to me, this is one of the main benefits of hackernews. I don't know everything, I don't know everything available, so I take value from everyone adding the options they know about.
Aren’t these quite different things with similar copy?
Gumroad seems to me to offer a way to eg sell copies of your pdf. This stripe service seems to be a way to make a link saying “that will be $79.82 please” and collect payment (and maybe some other details).
I.e. Gumroad provides some online store for a single digital product and stripe offer a way to collect money for anything but they don’t handle actually giving you the thing. Obviously there is some overlap but the pitch is different.
Edit: maybe I’m actually wrong and these are really similar. The thing I described above is more like an invoice for which this maybe isn’t suited (pay an invoice once/periodically but these links may be hit many times). So I’m not really sure now
I don't think so. Gumroad has a product delivery platform, where stripe only handles payment. I recently evaluated stripe vs gumroad for a product, and went with gumroad because they make getting the digital product to your customer VERY easy, while stripe leaves it all up to you
more than that. Gumroad also acts as a merchant of record (much much cleaner for international and EU/US taxes), provides social proof (reviews) and a discovery marketplace, together with a no code frontend with fulfilment (aka it hosts your files)
Stripe has a ways to go but certainly can clone these if they wish)
Gumroad deposits to bank accounts, but it might be regional. I have a section for ACH in my setup page. You can optionally also add a PayPal account to accept PayPal.
If the YC-adjacent scene stopped funding boring incremental startups maybe we'd dig our way out of the Great Stagnation.
Gumroad is something that should be a 0% fee opensource developer component, not an entire company.
The YC Facebook feed has been depressing lately: $6M funding for one of those links-on-a-page startups, $50M funding for a startup that wants to sell Pokemon cards on a livestream. The VCs are fuelling stagnation by funding these boring inconsequential projects.
Just look at the Show HN - YC batch companies, none of them are doing anything remotely groundbreaking or risky. A ton of them are solving minor workflow problems trying to skim shit off the top.
Does this support limited inventory? e.g. I want to sell only one item for a certain SKU. If two people have the link, only the first person to purchase should succeed, while the 2nd person should get a "This item is no longer available" message instead of being charged.
This is a use case we would have, too - the ability to, for example, create a unique payment link that can be used exactly once or for a specific customer.
I absolutely love this. Last year during the pandemic, we were using Eventbrite to process payments for events we were running. The cash we were getting was keeping our business going, until they decided to change their policy regarding pay outs (presumably due to cash flow issues of their own).
In the end we found that using Typeform with a Stripe integration was the best way to reliably and quickly transact with our customers, so I'm extremely pleased Stripe has released a no code checkout experience of their own. Really excited to use this. Thank you Stripe.
Lots of companies Stripe has replaced because of this. I can see new areas of businesses being launched because of how easy Stripe has made it to be paid online, all with no-code!
No more third parties or complex developer integrations or a cut, only get paid with a link with Stripe, That's it!
In general, yes. Now Stripe has it, and thus Stripe is now a viable competitor to these other payment providers, leading the competition landscape to shift further towards being based purely off of the percentage cut each service takes from transactions and not based on features.
That's the promise. However, I recently set up an e-commerce website for my wife. I was actually a bit shocked to discover that whilst Stripe's offerings are like 95% of the way there, that missing 5% means you can't take advantage of said offering at all.
1. I setup Stripe Checkout for subscriptions and thought I was good to go. However, my wife wanted to take sign-ups in anticipation of a set launch date in the future i.e. don't invoice until a specific date. Nope, no can do, the "billing_cycle_anchor" property can't be set with a checkout session.
You can add a trial period, but then Stripe's Checkout UI goes out of it's way to emphasise that you're giving the customer a free trial. Which is inaccurate and the incorrect messaging would likely run us afoul of consumer law in Australia.
So I had to ditch Stripe Checkout entirely and move to Stripe Elements. Then I realised another painful edge case. You can't set "billing_cycle_anchor" more than a month away (with monthly billing). So I did end up having to set a free trial period, but at least I could hide this information so my UI wasn't misleading customers into thinking they were getting something free when they weren't.
2. You can't create a trial period for less than 48 hours. So there's an edge case I need to handle as we approach the launch date i.e. I need to use "billing_cycle_anchor" sometimes, and free trial periods other times.
3. You can't attach shipping costs to subscriptions, at least, not without manually editing invoices i.e. somewhat reinventing the subscription logic.
4. You can't attach more than one coupon to a subscription. So you end up either manually messing with invoices, or creating weird amalgamation coupons. The latter seems simple, but it's not because if you want to offer a launch discount (for the first invoice) and indefinite free shipping, this simply cannot be represented using Stripe's coupon functionality.
5. Subscriptions don't have shipping addresses, only customers do. So if a customer wants to have multiple subscriptions delivering to different addresses then Stripe's Customer Portal offering becomes fairly useless. So we need to have our own UI and storage for shipping addresses for each subscription.
Basically I found that I needed to reinvent a bunch of stuff Stripe was already doing, in order to get that extra 5%. In which case I could almost as easily go with a different payment processor.
I am very much looking forward to when Stripe has time to iron out the kinks. Because wowee it was easy to get Stripe Checkout up and running. I really thought it was smooth sailing... but then it wasn't.
1. We're hoping to bring the `billing_cycle_anchor` property to Stripe Checkout in the near future. I'll keep you posted and let you know when this launches.
2. Good point, we will take a look into this.
3. We're launching shipping line items in Stripe Checkout's `subscription` mode in the coming months.
4. You're correct, we don't support coupon "stacking" today, and this is something we're excited to eventually support. Will keep you posted and let you know when this launches.
Sorry there isn't anything immediately actionable for you right now, but simply, we are working on all of this! Please feel free to drop me a note at jackerman@stripe.com – happy to chat further.
We used this link model in Brazil (custom made) for a client that has a B2B2C platform where vendors (shop owners for a specific industry) use the client's platform as an endless aisle option. We had a challenge for the payment side because:
- the payment needed to be to our client and not the vendor (to avoid double taxation);
- integrating to the POS machines of more than 100K vendors was unfeasible;
- The client wouldn't trust typing credit card info into the vendors computer/tablet/mobile.
So the solution was to use a link that could be send (whatsapp, sms) or read (QR Code), that would take the client to a checkout and payment secure site to finish the transaction.
With mobile wallets penetration increasing we can make more sophisticated solutions where the link would connect directly to the wallet. But for now we are working with link>payment.
Unfortunately I can't share a demo or docs as this is NDA work we did for the client (and the commerce is still in alpha).
But basically you're right. We would create a new checkout page (for the link) that would show the items of the cart (through the Commerce Platform API) and with the credit card fields shown (that would be later sent to the gateway). The link is for the checkout, so you'd have only one per cart/client and it has a timed session.
This is pretty great, but I think some people are overestimating the significance of this - PayPal.me has existed for a while and it hasn't exactly killed off small payment providers.
Yeah, for the last few years there's also been Zelle (at least in the US).
This is IMO a killer service because all you need is the person's email address or phone number, there's no fees, it's really fast and it's a feature built into most major banks' dashboard so there's no sign up process. It's like the best possible thing you could ask for, but small payment providers in the US still exist.
It's really handy for the use case of sending or accepting infrequent 1 to 1 payments (invoices, referral payouts, etc.). It supports recurring payments too.
Having a huge market player release a feature that seems to overlap with your business can seem like bad news, but hearken! it's not all downside.
The case study here is Facebook introducing the ability to schedule posts in Facebook directly, theoretically hurting Buffer et al.
Take a look at Buffer's publicly-available revenue data [1]. Can you see when this change occurred?
In general, by lowering the barriers to entry into an activity, MORE people participate in it. This makes the general market larger. A portion of those users have a measure of success and end up wanting more advanced functionality, so they move to a tool that will give them more advanced functionality.
In this case: Stripe Payment Links will enable a lot more people to conduct ecommerce, most of who would never have tried. Some of those people will be successful, find that ecommerce merchants need a lot of tools to manage their businesses, and will acquire those tools.
I believe this is good news for Shopify, rather than bad.
Shopify is aggressively and successfully expanding their e-commerce product offering... if you're running a business that sells physical goods, the checkout is one of the simplest parts of the whole thing, and I don't think this will matter either way to them.
Maybe for the very small sellers, yes. But Shopify will be fine without them. They provide a lot of value to medium size sellers with a lot of turn over, through their app marketplace and integrations.
And they can actually give you lower rates than 2.9% if you pay a higher subscription fee. Stripe won't drop below 2.9% unless you do $1M+ and even then it's not a guarantee.
Is it? Most people will still have a website of some sort to actually promote what they're selling. And if you hope to sell more than a handful of items a week, you have to start thinking about fulfillment and customer emails etc.
This is definitely very cool, but I think Shopify still offers a lot (and still has their simple checkout this for $9 a month of whatever, which has a bunch of useful features).
Shopifys success is largely due to the fact that they were willing to do the messy dirty work of making a Ecom CMS that works and doesn’t run on Wordpress.
Tech has changed and is catching up. With stripe handling the hardest part about ecom, other companies will sneak up behind Shopify because of better tech and replace traditional websites
Shopify has had the Buy Button for years. Combine with the Lite plan for $9 a month (https://www.shopify.ca/lite) and room to grow if the business takes off without replatforming.
Readit News
While there are lots of antecedents (this is, after all, just a checkout page with a URL), and even though this was substantially inspired by the growth of the no-code ecosystem[0], the thing that's interesting to me about the payment link "space" is that it's a use case that really took off in other markets first -- Nigeria, India, Philippines, etc. I suspect that staying abreast of important new patterns emerging outside US/Europe will become more important for many businesses in the years ahead... there are a lot of legacy assumptions being questioned.
And feedback very welcome on our Payment Links product itself!
[0] We were excited to have Ben Tossell, one of the original no-coders, as one of our beta users: https://twitter.com/bentossell/status/1397246339898093568
The biggest trick is the banks. When using fiat and opening a bank account for an incorporated business, the bankers often ask for information on the company like website presence of marketing materials.
For the past few years I've been able to point to articles about commerce in Asia being chat app based, to get past that. Bankers don't actually care, but you do need to know how to make them not begin to care.
It's not too long ago they would ask for information faxed using company letterhead, as a form of legitimization.
The signals they use to vet customers are, again, a decade or two behind what's technologically relevant.
A minor feedback for the marketing page.
I’m an English speaker currently in Mexico City. The webpage first opened in Spanish based on my location.
It only took a few seconds to figure that I could change the language just above the footer, but my UI recommendation would be to put the location/language switcher next to the upper right sandwich (I’m on mobile) in a circle with the flag of my default country/language.
That would be much faster to find and have the added benefit of displaying how many countries and languages Stripe works in.
How does uber default the language for you? They've got the advantage of your registration so probably easier...
The most useful addition would be another text box (or full form) in the payment link setup to specify sending some custom text to the payer upon payment (by email or on-page or both).
For example a "Thank You", but also a "here's the private link to the thing you bought, here are the details, here is the password, here is the timeframe for shipping, here's what to do next", etc.
I'm curious if you have analytics collection on the first use case since it seems like a pretty risky privacy violation in terms of user tracking but honestly not far beyond shenanigans that bigger players pull (Facebook/Amazon).
But I'm really curious about the second use case - the no code approach is really nice and flexible for sending payment requests over alternative media (i.e. discord) but it feels like this might open the door a bit more to phishing users via redirection - do you happen to have any security ruminations on that topic that you've made public or be willing to share?
Here's an example of a payment link: https://buy.stripe.com/dR6cOd9RJ8KS8nufYZ. It's a single link that can be shared with anybody (not unique to one customer).
On the Stripe side, nothing is collected from the customer til they click.
We've thought a lot about the security side of things—one of the reasons why Payment Links has its own subdomain and the payment page is hosted by Stripe.
The one feedback I'd give is that it's hard for a user to know they can adjust the quantity on mobile. You have to click the "Details" link in the top right, and it's not really obvious to a user this is where they should go do this. (i.e. they may well think that they can't update the quantity).
That’s an additional service to find and connect if you use stripe, sadly. That’s why when we launched Lab Surprise [0], with 19 apps from developers in several different countries, selling worldwide our bundles, we ended up using Paddle: they are the merchant of record, collect and remit the correct taxes in each country. Yes, it’s 5%+0.5cts but for us it was worth it.
I’m pretty sure many sellers using Stripe paylinks will just never do the proper remittances in countries that are not their country of origin, but that might end up bitting them hard.
Making tax remittance invisible is what can unleash instant worldwide micro-stores without hidden task risk
[0] https://uploadvr.com/app-lab-quest-marketing/
About a year ago I was toying with the idea of creating a SaaS/product that worked completely without JS, and the only hurdle was that there currently is no way to simply answer redirect a client directly to the Checkout page after creating a Checkout Session in the backend. Currently, you have to create the Checkout Session, send this to the client, load StripeJS, and _then_ you can redirect to the Checkout page.
Seeing that the Payment Link is basically the same thing, only that instead of a backend, the seller can create the Payment Link ("Checkout Session") in a dashboard, it doesn't really seem like the StripeJS-step I mentioned above is strictly necessary.
I hope you'll add a way to get the URL when creating a Checkout Session in the backend, so that the dream of a fully-functioning noscript SaaS might one day come true :)
Warning: shameless plug.
It's a no-code shopping cart that works with Stripe. We offer digital downloads that work as you describe.
You could check it out - https://trolley.link
(you can email me direct at rg@trolley.link if you want to know anything more)
It really does make me want to consider working with stripe for my next project (or, consider working for stripe for my next job)
As to your reflections, I'm wondering how Stripe ingests these various emerging patterns around the world (especially as you expand to unfamiliar territory) and prioritize bringing them into your products?
IOW: if N trends at various stages of the adoption cycle are happening 7K miles away, how do you think about placing different bets on each, especially when the cultural moments may be wildly different than, as yet, Stripe understands?
Cheers! SM
When you launched Atlas I've considered it, but the accounting and taxes are complicated and expensive. I believe one even needs to charge state sales taxes in some states.
I formerly lived in Sri Lanka, and the country lacks a payment provider worth their salt, let alone an innovative one like Stripe. Perhaps extending the countries that Stripe supports can have the biggest impact.
Deleted Comment
Also, there's no good way to share the original link. The one after you click (and page you end up on after purchase) is crufty: https://checkout.stripe.com/pay/cs_live_n1WDYJkCi1wp32H4Zlh8...
Versus: https://buy.stripe.com/dR6cOd9RJ8KS8nufYZ
Deleted Comment
Obviously, Stripe is the gold standard and I think we have a hard time, but we're hoping to improve the developer experience even more this year.
https://stripe.com/blog/accessible-color-systems
https://videos.ctfassets.net/fzn2n1nzq965/7GDaCnGLsYrdVIwXIq...
First, the link that I was given to send to the other party was a tinyurl.com link. This concerns me because I don't think that Stripe or PayNowLink has control of tinyurl.com. If tinyurl.com is exploited then someone can reroute people to a totally different site.
Second, Privacy.com debit cards didn't work for me. I've reached out to support to see if that's something they can fix. Is that a known issue?
I would be super interested to know if there are any blockchain projects or related corollaries that Stripe is working on.
e.g. we're looking into how to pair payment links with Jam (https://jam.systems | https://jamshelf.com), basically stand-alone Clubhouse-style audio rooms.
Unbundling of the payment feature of superapps.
Link page: "Get an email after every successful payment by managing your settings."
Settings page: "Successful payments. Receive a notification for every successful payment."
While I love this, is there a way to also programmatically create these links?
Happy to chat more via email if helpful as you get started with Stripe — I'm jackerman@stripe.com
So that a StripeLink buyer who is being charges can also later receive revenue ?
Is this all based on credit/debit cards? Are there any plans to incorporate mobile money payments?
Dead Comment
https://twitter.com/shl/status/1397254513627705345
And to me, this is one of the main benefits of hackernews. I don't know everything, I don't know everything available, so I take value from everyone adding the options they know about.
Gumroad seems to me to offer a way to eg sell copies of your pdf. This stripe service seems to be a way to make a link saying “that will be $79.82 please” and collect payment (and maybe some other details).
I.e. Gumroad provides some online store for a single digital product and stripe offer a way to collect money for anything but they don’t handle actually giving you the thing. Obviously there is some overlap but the pitch is different.
Edit: maybe I’m actually wrong and these are really similar. The thing I described above is more like an invoice for which this maybe isn’t suited (pay an invoice once/periodically but these links may be hit many times). So I’m not really sure now
Stripe has a ways to go but certainly can clone these if they wish)
Deleted Comment
Dead Comment
Gumroad is something that should be a 0% fee opensource developer component, not an entire company.
The YC Facebook feed has been depressing lately: $6M funding for one of those links-on-a-page startups, $50M funding for a startup that wants to sell Pokemon cards on a livestream. The VCs are fuelling stagnation by funding these boring inconsequential projects.
In the end we found that using Typeform with a Stripe integration was the best way to reliably and quickly transact with our customers, so I'm extremely pleased Stripe has released a no code checkout experience of their own. Really excited to use this. Thank you Stripe.
Lots of companies Stripe has replaced because of this. I can see new areas of businesses being launched because of how easy Stripe has made it to be paid online, all with no-code!
No more third parties or complex developer integrations or a cut, only get paid with a link with Stripe, That's it!
I welcome this!
1. I setup Stripe Checkout for subscriptions and thought I was good to go. However, my wife wanted to take sign-ups in anticipation of a set launch date in the future i.e. don't invoice until a specific date. Nope, no can do, the "billing_cycle_anchor" property can't be set with a checkout session.
You can add a trial period, but then Stripe's Checkout UI goes out of it's way to emphasise that you're giving the customer a free trial. Which is inaccurate and the incorrect messaging would likely run us afoul of consumer law in Australia.
So I had to ditch Stripe Checkout entirely and move to Stripe Elements. Then I realised another painful edge case. You can't set "billing_cycle_anchor" more than a month away (with monthly billing). So I did end up having to set a free trial period, but at least I could hide this information so my UI wasn't misleading customers into thinking they were getting something free when they weren't.
2. You can't create a trial period for less than 48 hours. So there's an edge case I need to handle as we approach the launch date i.e. I need to use "billing_cycle_anchor" sometimes, and free trial periods other times.
3. You can't attach shipping costs to subscriptions, at least, not without manually editing invoices i.e. somewhat reinventing the subscription logic.
4. You can't attach more than one coupon to a subscription. So you end up either manually messing with invoices, or creating weird amalgamation coupons. The latter seems simple, but it's not because if you want to offer a launch discount (for the first invoice) and indefinite free shipping, this simply cannot be represented using Stripe's coupon functionality.
5. Subscriptions don't have shipping addresses, only customers do. So if a customer wants to have multiple subscriptions delivering to different addresses then Stripe's Customer Portal offering becomes fairly useless. So we need to have our own UI and storage for shipping addresses for each subscription.
Basically I found that I needed to reinvent a bunch of stuff Stripe was already doing, in order to get that extra 5%. In which case I could almost as easily go with a different payment processor.
I am very much looking forward to when Stripe has time to iron out the kinks. Because wowee it was easy to get Stripe Checkout up and running. I really thought it was smooth sailing... but then it wasn't.
1. We're hoping to bring the `billing_cycle_anchor` property to Stripe Checkout in the near future. I'll keep you posted and let you know when this launches.
2. Good point, we will take a look into this.
3. We're launching shipping line items in Stripe Checkout's `subscription` mode in the coming months.
4. You're correct, we don't support coupon "stacking" today, and this is something we're excited to eventually support. Will keep you posted and let you know when this launches.
Sorry there isn't anything immediately actionable for you right now, but simply, we are working on all of this! Please feel free to drop me a note at jackerman@stripe.com – happy to chat further.
The things this will enable are endless.
This is truly headless e-commerce.
- the payment needed to be to our client and not the vendor (to avoid double taxation);
- integrating to the POS machines of more than 100K vendors was unfeasible;
- The client wouldn't trust typing credit card info into the vendors computer/tablet/mobile.
So the solution was to use a link that could be send (whatsapp, sms) or read (QR Code), that would take the client to a checkout and payment secure site to finish the transaction.
With mobile wallets penetration increasing we can make more sophisticated solutions where the link would connect directly to the wallet. But for now we are working with link>payment.
Here's a quick video walkthrough as well: https://www.youtube.com/watch?v=ypH78KUu4Jk
This is IMO a killer service because all you need is the person's email address or phone number, there's no fees, it's really fast and it's a feature built into most major banks' dashboard so there's no sign up process. It's like the best possible thing you could ask for, but small payment providers in the US still exist.
It's really handy for the use case of sending or accepting infrequent 1 to 1 payments (invoices, referral payouts, etc.). It supports recurring payments too.
A very large portion of SMBs want to sell a handful of things without the overhead of maintaining and paying over the top for a e-commerce cms.
This plus social media will be a huge win for a lot of businesses
The case study here is Facebook introducing the ability to schedule posts in Facebook directly, theoretically hurting Buffer et al.
Take a look at Buffer's publicly-available revenue data [1]. Can you see when this change occurred?
In general, by lowering the barriers to entry into an activity, MORE people participate in it. This makes the general market larger. A portion of those users have a measure of success and end up wanting more advanced functionality, so they move to a tool that will give them more advanced functionality.
In this case: Stripe Payment Links will enable a lot more people to conduct ecommerce, most of who would never have tried. Some of those people will be successful, find that ecommerce merchants need a lot of tools to manage their businesses, and will acquire those tools.
I believe this is good news for Shopify, rather than bad.
[1] https://buffer.com/revenue
This is definitely very cool, but I think Shopify still offers a lot (and still has their simple checkout this for $9 a month of whatever, which has a bunch of useful features).
Shopifys success is largely due to the fact that they were willing to do the messy dirty work of making a Ecom CMS that works and doesn’t run on Wordpress.
Tech has changed and is catching up. With stripe handling the hardest part about ecom, other companies will sneak up behind Shopify because of better tech and replace traditional websites
Shopify is the 2008 equivalent in the tech world. Hugely overvalued, no secret sauce (pretty web fronts that are powered by stripe)
Shopifys moat is nonexistent.