Stripe Payment Links | Hacker News Reader

Stripe Payment Links

stripe.com

988 pointsjoeyespo312 comments

(Stripe cofounder.)

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

I'd like to help my father's business to go online with stripe but unfortunately his EU country (Croatia) for you to bother with.

Working on the rest of the EU!

EDIT: typo, missing; "is too small a market"

I love how this is a great (and "open" / web / link based!) complement to all kinds of digital products.

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.

When are you going to offer services to entrepreneurs in countries such as Nigeria, India and Philippines?

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.

Really excited to see your release on the Philippines. Godspeed!

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.

I think this is just a normal Checkout/Payment in the API, so there seems to be a webhoook for it.

Confirmed!

Yep, all webhooks still sent as normal.

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!

There's a lot of cool stuff that uses Paystack on Twitter, e.g.: https://twitter.com/spokenword_lag/status/139677392471373005.... You can search for paystack.com/pay.

Yep. The thing to understand is that a huge portion of emerging markets like ours is made up of informal vendors - often young people monetising a side hustle or two - not full-blown businesses per se. For example I have an acquaintance who takes banana bread orders during the week which she bakes and delivers each Saturday; Paystack's links have made the process super straightforward for her.

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?

Cheers! SM

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.

It'd be nice to know that a feature/product is widely used in Japan, say, so if you're in the US and considering implementing Stripe's version you can be more assured that it won't disappear suddenly.

Super sleek!

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.

Good feedback -- thanks. We've long struggled to find the right balance between "convenient/automatically correct" and "non-confusing" in site localization.

Slightly tangential, but when you localize a product for India, do not automatically translate it to Hindi.

Only 38% people of India has Hindi as their mother-tongue.

There is strong anti-Hindi-imposition sentiment in many places of India.

Just because someone's geolocation is set to India, don't automatically translate it to Hindi. It irks many.

If only there were a header browsers could send. Perhaps something we could call Accept-Language?

What would the compromise be?

English is actually the neutral compromise language in India.

This is true, too.

Especially where people willfully get arrested to wipe down Hindi marks from metro stations [0] and people who have fasted to death to not have Hindi as the national language [1].

[0]: https://www.thenewsminute.com/article/kannada-pride-wins-day...

[1]: https://en.wikipedia.org/wiki/Potti_Sreeramulu

Show a pop-up or pop-up like asking if they want to switch to an Indian language.

I never switch to another language other than English.

It is highly advisable that companies translate to eight most common Indian languages. Or even the top five [0].

People speaking all major languages of India are huge potential markets for companies. Google offers search in nine Indian languages. Amazon provides customer services in five languages.

For some services, you should not even want to translate to languages other than English. India has one of the largest English speaking populace of the world- 2nd only after the US [1].

[0]: https://en.wikipedia.org/wiki/List_of_languages_by_number_of....

[1]: https://en.wikipedia.org/wiki/List_of_countries_by_English-s...

> What is a good compromise for our international landing page in India?

> Translate to 8 Indian languages

That is not a compromise at all, that's a full solution

India has 22 constitutionally recognized languages, and some 440+ all together.

https://en.wikipedia.org/wiki/Languages_of_India

Content is worse.

It is frustrating to no end to visit sport sites in europe (for example, soccer) to have them default to MLS news or mexico news because of my IP

When i specifically go to a EU website to get EU sports news, why is does website forcing me to eat news about my home country sports???

It has gotten so bad that I've just dropped a few sites as a result.

Worse, it is never intuitive or easy to switch the content to the "default"

Born and raised in California, have lived abroad the past 10 years in various locations. The language I always want a website displayed in is the language my browser says I want it displayed in. Sure, make the content local, e.g. assume Chilean pesos if I'm in Chile, but please simply follow Accept-Language for language selection.

That is approximately what we do. (And then we remember any explicit selection that's made.)

Same, but I’m in South Africa now. I was impressed by how cool the banking is. But then, many countries were ahead of the US in that. My fave feature is being able to send cash by SMSing a one time pin.

Why not just use the Accept-Language header? stripe.com already does this – At least I get redirected to "https://stripe.com/en-de", seemingly based on the combination of header and geolocation

It's a tricky balance.

I'm building this myself with a product currently only in English in a Spanish speaking country, for speakers of both, so it's top of mind.

IMHO, the automatic detection being wrong is less of an issue with a greater ease of language selection.

Just remember that flags aren't languages.

That's a great point.

In that case, I'd suggest the first two letters of the language, an "En" for English, an "Es" for Spanish, a "De" for German, etc.

https://en.m.wikipedia.org/wiki/List_of_ISO_639-1_codes Not first two letters, two letter ISO codes. There are also complications with dialects, so not quite this simple.

Flags are the most easily-understood way to communicate languages to users, and I say this as someone who is often obliged to pick the flag of a foreign country (often an empire that wilfully starved millions of my countrymen) to get websites in my native language. "Flags are not languages" is one of those pedantic corrections that ends up doing more harm than good.

The easiest way is to state the language name in that language:

English

עִברִית

العربية

हिंदी

ไทย

etc

How do I find the language selector if the page is in a language I don't know?

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.

That's a good idea.

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!

Funny to recognize your account name. Love your twitter content Simon.

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.

Isn't it simpler to just have a single static web page, to show that presence? Even if it's just for western contacts such as banks.

Simpler? It's just "you can if you want".

The incorporated entity is just for limiting liability, having properties in its name instead of yours, and more easily convincing tax authorities that the universe of tax deductible expenses is so great.

You can be paid for goods and services immediately, these days.

> the bankers often ask for information on the company like website presence of marketing materials.

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.

Ironically, I just had a banker ask me for a document on my employer's letterhead today.

To which my boss replied "Wtf is letterhead?"

Faxes? Letterheads? To me, those sound almost like the "proof of work" idea behind some blockchain technologies. Essentially: "Prove to us that you're a legitimate entity, because clearly you have bothered to set up support for such legacy solutions."

Personally, i'd be more comfortable with the modern approach being something more along the lines of:

  You should put the token that we'll provide you with under your corporate website's page: https://<YOUR_DOMAIN>/.well-known/identity-challenge/<TOKEN>

A bit like what is done by Let's Encrypt for providing HTTPS (though there could be additional technical details).

Of course, this does almost nothing for the website being compromised, but still feels less nonsensical than using fax and using letterheads and such.

I think you're missing the point. The bank doesn't want you to prove ownership of a particular asset; they want you to prove that you are "carrying on a business".

Owning a website (or a printer, or a truck, or lots of money) doesn't mean you have a business. It's about the nature and purpose of your activities with those assets (or skills).

I can add an identity token to my personal website, but that doesn't make it a business any more than putting a saddle on a zebra makes it a horse.

This ruling from the Australian Tax Office lays out pretty clearly the defining characteristics of a business [1]. It's probably a bit different in the USA, but I'm sure it's not too dissimilar.

[1] https://www.ato.gov.au/law/view/document?docid=TXR/TR20191/N...

Is your boss your boss by position or an actual owner who deals with HR issues? I cannot fathom how anyone who runs or owns a business has never heard the term letterhead.

> It's not too long ago they would ask for information faxed using company letterhead, as a form of legitimization.

I had PayPal ask me for exactly this (emailed rather than faxed) recently for my PayPal business account!

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.

Would love to hear how we can improve the API to make you not want Stripe to do it better. :)

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.

My main issue is how the webhooks sometimes give incorrect info, which has led to many customer complains when their subscription gets messed up by some edge case that I would expect to be abstracted away by RevenueCat but isn't.

For example, when I implemented the PRODUCT_CHANGE event I expected it would notify me of the new product, but that is not the case on Android which led to bugs with some customers. It turns out that only iOS sends the new_product_id, so it is impossible to know from this event what the new product should be to display it in the app. Since upgrades/downgrades are immediate on Android, it turns out that the solution was just to not handle that event on Android since the renewal event would override the product anyways. (but sometimes the events came out of order, which is what led to bugs when PRODUCT_CHANGE was after RENEWAL).

There are a lot of cases where events in the dashboard are totally out of order and don't make sense, like showing a customer purchasing the lesser plan, then renewing for the upgraded plan, and then switching from the lesser to the upgraded plan 10 days later. How could that be possible? The switch should have been between the renewals, so it's very confusing to debug.

I've been told that now the recommended approach is to ignore all the webhook data, and simply call the RevenueCat API to get the entitlement and subscription status - however I asked how to parse this into something meaningful and didn't get a good answer. I would like to know the users current entitlement, and the current subscription (which can be different than the entitlement). For example, if the user downgrades, their entitlement may still be the upgraded plan for a while, but the app should reflect that they are no longer subscribed, or that they are subscribed to a different plan. For the entitlement it is easy I think, just choose the highest entitlement level to use. For the subscription, maybe choosing the last renewed one would work? But there are so many complexities with downgrades, upgrades, crossgrades I don't know if that is true. The answer from support was basically that they didn't know, yet this is an absolute must for almost any app - there has to be a way to display what the user is currently paying (or not paying) for, linking out to the native UI is not an option as it's not user friendly and cannot be displayed cross platform (I want the website to also reflect what they are paying for). My big concern with this is also, why does the API supposedly return the correct data but the webhook doesn't? If I am calling the API 10ms after receiving the webhook, why can't the webhook just deliver correct data instead?

Another current issue I discovered the other day was that grace periods are no longer working. The RevenueCat dashboard shows that they are getting a 7 day grace period (the expiration date in the dashboard is correct), yet in the webhooks I am getting the wrong expiration, one that is only a day away. Apparently this is due to a change by Google and a fix is (maybe?) on the way? But it caused a lot of issues that I didn't expect.

Basically RevenueCat's promise is great, it has saved a ton of time but isn't quite there on fully abstracting all these native edge cases away, they crop up in the API occasionally, and the proposed fix to use the API instead of the webhook data is half baked when support has no idea how to actually parse it to get the current subscription that should be displayed to the user (in the case that they upgraded/downgraded and have more than one). I love the idea but I'm hesitant to recommend it to anyone because lately it's been causing a lot of headaches with customers having billing issues due to these inconsistencies.

Thanks for the great feedback. These are all legit issues. We have on our roadmap a revisiting of our API this year and I think we need to have a lower tolerance for abstraction leakage.

Would you mind dropping me an email jacob@revenuecat.com? I think for our long term viability we need to have the trust of people who care about edge cases like this. I’d love to hear more.

Can you use Stripe in iOS and Android apps? I thought purchases had to go through Apple and Google?

You can but only for physical goods or a small handful of other uses (person to person and 1-2 other special carve-outs I can't remember).

Correct, I mean if Stripe developed a wrapper around the native APIs as other companies have done. Payment is still handled natively but Stripe would provide consistent webhooks without having to deal with Apple’s complex receipt API.

If it's IAP for digital items then you can't use Stripe for IAP on iOS/Android, it has to go through the respective store's IAP logic.

Yes, which is why I am asking for Stripe to do an IAP wrapper as other companies have tried. Apple and Android’s subscription APIs are terrible, essentially what is needed is an abstraction around them to keep user entitlements in sync without having to deal with the native APIs. The IAP is still handled natively, but the receipts and notifications are used to create a consistent experience.

Ahh, that’s an interesting proposition and the more I think about it, the more I like it. Just pass in some param to the “create payment intent” to indicate it’s a IAP-required purchase and they wrap the internal Apple/Google implementation. You’d still need to handle Apple/Google-specific errors but it’s be in one code-flow (the same way you have to handle secure-3D or whatever it’s called in the current Stripe payment flow).

Really they’d be smart to create an “External Payments” or “Off-platform payments” concept to support more than just Apple/Google. It could be a little odd to not get payouts on a portion of your invoices (like it could cause weird issues if you suck all the Stripe data into another tool/your platform, you’d have to take that into account) but it might be useful to enough people. It sets Stripe up to step in, with small code changes for the developer, if the walls weaken/come down around current IAP policies. Also, it provides only 1 API for a dev who wants to offer CC as well Apple Pay (not IAP) instead of 2 or just skipping CC (using only Apple Pay).

All that said, it will be a hard sell to Stripe execs who will probably see it as a large maintenance burden all to record stuff they don’t make money off of.

I do like the idea though!

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?

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.

In short, yes—confirmation is requried.

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.

Very cool. One quick thought: tapping the company name doesn’t seem to do anything at the moment.

It would be very cool if it would either (1) redirect to the company website or (2) a “store” or directory showing other available Payment Links.

Excellent work!

Aha! Thanks. Great ideas.

I don’t know what I expected but I guess I have a new sticker for my MacBook now.

Really nice and clean process though.

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.

Pleased to see this feature.

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!

Please add the possibility to programmatically create links with payment splits so I don't have to waste time re-re-re-re-re-inventing the wheel

Working on it right now! Drop me a note at jackerman@stripe.com if you'd like 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?

You can use Stripe Webhooks + a "no-code" solution like Zapier to make that happen in ~15 minutes.

But if you have a few hundred products then this doesn't become so easy. And where exactly does Zapier deliver that file from in a secure way?

If I'm going to go through all that trouble, I might as well just use a Wordpress electronic delivery solution or Woocommerce, in which case, what's the point of this website-less payment solution?

If I'm gonna go website-less, then it needs to do what the website would otherwise do.

pretty sure you can easily use shopify for 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.

Hi! Late to the party, but this is exactly the kind of problem that my startup, Trolley, solves.

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)

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.

> no code required

While I love this, is there a way to also programmatically create these links?

Working on it! A Payment Links API is coming very soon.

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.

Sorry, I'm not familiar with using Stripe yet. Is it possible to set a shipping fee depending on the customer's location?

Stripe Checkout does support shipping rates. Further details here: https://stripe.com/docs/payments/checkout/shipping

Happy to chat more via email if helpful as you get started with Stripe — I'm jackerman@stripe.com

Can this be (or will be) integrated with Stripe Connect?

So that a StripeLink buyer who is being charges can also later receive revenue ?

Indeed it can! Drop us a note at jackerman@stripe.com and tolu@stripe.com and we'll be happy to help you get started

Payments aside, will you release/open source your colour accessibility tool? Any chance?

https://stripe.com/blog/accessible-color-systems

https://videos.ctfassets.net/fzn2n1nzq965/7GDaCnGLsYrdVIwXIq...

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.

Totally! We couldn't agree with you more.

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.

Panama's on our list! (Assume you've already done so but you can sign up to get notified at https://stripe.com/global#PA.)

I did, but it's been 7 years? More? I lost faith that it might happen.

I can't wait to be wrong about that!

Has Panama fixed their money laundering problems yet?

Mostly, yes. The large banks are strict about know your customer rules and willing to divulge information to foreign states depending on tax treaties.

Keep in mind the Panama papers you probably are thinking of had little to do with Panama. The law firm was located in Panama, but the corporations and shady financial things were happening in the usual handful of island nations. If the law firm was located in New York it would have been the Manhattan papers - it didn't have much to do with Panama at all.

This is great. I've just implemented it to replace the clunky mess I had in place while waiting for this type of product from Stripe. Thank you!

Thrilled to hear it, and can't wait to hear your feedback!

So far I have no feedback other than how smooth it was to use. I had a subscription plan already in place. Chose option to create link. Put the link on my website where I used to have a 3rd party’s stripe front-end. Now it’s direct and clean and supports faster payment mechanisms. Awesome!

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

Thank you so much! Can't wait to hear your feedback about Payment Links.

Very interesting!

Is this all based on credit/debit cards? Are there any plans to incorporate mobile money payments?

Already works with Apple Pay and Google Pay automatically!

Would be nice if it accepted a customizable dollar amount input so that it could be used for donations, like Paypal's donate button.

We're excited to build donations support via Stripe Payment Links. Drop me a note at jackerman@stripe.com and I'll let you know as soon as it is live.

Could you please consider adding support for custom fields as part of this? For example, to be really useful in the in the UK, donation links would need to ask if the donor is eligible for Gift Aid (which increases donations by 25%). This then needs at least house/flat number and postcode to make a valid Gift Aid application (and some organisations may ask for more address details than that).

With those additional fields it would mean we could post donation links all over the place, and then get donor details out of Stripe for the donations team. Thanks :)

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)

Apple Pay worked great (one sticker purchased). Will you be integrating Chrome's equivalent?

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

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.

I guess like other services of stripe, it does NOT support developers from China mainland, right?

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

[0] https://uploadvr.com/app-lab-quest-marketing/

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?

I'd like to be able to enable PPP so that the page shows lower prices for those located in countries with less purchasing power.

I'd like to be able to enable email notifications for just payment link payments. Currently only option is all successful payments.

Link page: "Get an email after every successful payment by managing your settings."

Settings page: "Successful payments. Receive a notification for every successful payment."

Gumroad?

https://twitter.com/shl/status/1397254513627705345

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.

This IS terrific news if you are using Stripe and want to stick with them as your one payment solution.

Until adoption increases enough and they decide they can milk customers even more?

Really? What has stripe done in the past to make it feel like they’re being greedy? Besides, nobody is using stripe because it’s the cheapest option.

> What has stripe done in the past

Take VC funding.

I'm being glib, but honestly - it feels like every large vc funded company is actually some many-layered plan to take over existing markets, and then exploit their new monopoly

That’s exactly the point of VC largely - no really, that’s no secret at all.

VCs want unicorns. To get that big you often have to be the biggest in the space or big enough with enough moat to effectively be a monopoly. Monopoly status is the goal

So why is VC funding considered a Good Thing® and actively promoted as the way businesses should be created, when literally everybody agrees monopolies are a bad thing?

Because everybody wants to be a monopoly but nobody wants to be monopolized.

Not sure what you mean. It’s definitely glamorized, just like working a high paying finance job is (but I don’t think many would call Wall Street ethical or moral). Lots of people want to be VC backed because it’s great for you, but it’s more complicated whether it’s great for anyone else

They stopped refunding payment processing fees on refunds, for one.

Long after other comparable gateways had already stopped refunding those too.

Gumroad deposits to Paypal, Stripe deposits to bank account. Seems like a big difference, no?

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)

Update: I've done a 3 minute demo of Payment Links in case anyone is interested: https://www.youtube.com/watch?v=bLNFJNoL9e8

Great video - very well done. It's easy to follow and you explain things in simple terms!

ha, thanks very much! thats cause i dont have the curse of knowledge when it comes to payments haha

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.

According to https://help.gumroad.com/article/260-your-payout-settings-pa..., it depends on Stripe's availability for ACH payouts.

I was just referring to the marketing copy by SHL in the tweet.

Gumroad also deposits to bank account.

I was simply referring to the marketing copy in the linked Tweet.

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.

Alas the HN echo-chamber ensures these points are pushed out of the bubble.

Why is YC funding this sort of shit? https://techcrunch.com/2021/05/24/beacons-seed-round-creator...

Unfortunate that you're being downvoted for raising cogent points.

I do think companies like Airbnb, Dropbox, Stripe, Ginko Bioworks, etc. are doing pretty neat stuff. Even if these businesses don't seem groundbreaking, they clearly are, somehow. But the recent batches of YC startups seem disappointingly... competitive. As in the Thiel-ian sense of not doing much fundamentally different from other players in the market.

I wonder if this could be attributed to Paul Graham stepping back from the front lines.

Gumroad is in for a bit of direct competition by a behemoth. I'm sure they won't have good sleep in the coming months.

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

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

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.

Not yet, but this is something we're excited to build. Drop me a note at jackerman@stripe.com and happy to tell you more.

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.

Awesome! Can't wait to hear your thoughts/feedback on Payment Links; feel free to reach out at jackerman@stripe.com

This. is. going. to. be. HUGE!

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!

Yep yep yep.

The things this will enable are endless.

This is truly headless e-commerce.

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.

Thank you for all of your feedback, Benjamin.

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.

Thanks for your reply. It's appreciated.

I edited to add a 5th pain point, but I think it mostly comes down to subscriptions currently being geared toward digital offerings rather than physical products.

Needless to say, I'm very much looking forward to when I can throw away all my code and use Stripe Checkout + the Stripe Customer Portal :)

I'm gonna push in and ask a question of my own :D.

What's currently stopping Stripe from supporting Israeli merchants? There are a ton of Israelis that would jump on it if it was available.

Wasn't this available for years from other payment providers?

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.

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.

How is the link generated? So basically it is a deep link into the clients checkout page? Each product gets its own link? do u have a demo somewhere?

Each product gets its own Payment Link. Jump into the Stripe Dashboard and give it a try today: https://dashboard.stripe.com/payment-links

Here's a quick video walkthrough as well: https://www.youtube.com/watch?v=ypH78KUu4Jk

Thanks... But I meant his custom solution he made for his client - not Stripe Paymentlinks :)

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.

paypal.me is a bit different. But the original PayPal "Buy Now" buttons (from 2000) are similar.

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.

This is absolutely the worst news for Shopify.

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

Shopify is fine. They have a nice eco-system of devs and integrated apps. Gumroad should be worried.

Shopify is fine is the funniest thing I’ve ever heard.

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.

Shopify's moat is its ecosystem of developers and apps, for many of the same reasons WordPress still powers 39.5% of all websites in 2021. Shop Pay also provides many of the same benefits of Stripe -- global one-click payment across all their stores and more. I run into Shopify sites while shopping all the time and am always pleasantly surprised that I don't have to fill out anything to check out, it already knows me. Then those orders magically show up in the Shop app on my phone for order status and delivery tracking.

Here's a screenshot. I did not make an account with any of these completely independent websites. Yet I checked out on all of them without typing my address or payment info. And all my orders appear here with tracking.

https://i.imgur.com/D4XfvnJ.png

Wordpress is a free product. Shopify is not.

Shopify built a good ecom cms and they’ll be right for some companies, but they’ve also cornered themselves as that company that makes ecom software. Remember Shopify POS? Me either.

Anyways, consumer trends change. The way people buy online will change. There’s a future where ecom websites are basically the back catalogue of the future.

Shopify is $29 per month on the cheapest plan. That's not going to make or break anyone's online store.

I sort of agree with some of your points, but I think you're ignoring what shopify is actually good at.

It is one more software offering that lets you build a store online.

You can have a store up in an hour or something. You don't have to integrate software from various places. It's a one stop shop.

That's worth a fair amount.

I'm a web dev, and I've still chosen shopify in the past for side projects. I didn't want the headache of my own stack.

They have competitors, sure, but they're a solid option in the space.

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.

They provide me with 1.4% + $0.24 for European cards which is a whole lot less than even national banks offer me...

... don't they use stripe as their shopify-branded processor?

Yes but their contract with Stripe let's them give you lower rates. The catch is that Shopify's API can't be used like Stripe's API to handle payments, you're locked into Shopify's checkout page. If you get Shopify Plus ($2000+/month), you can use Shopify's API akin to Stripe's API and accept payments without using the Shopify checkout page.

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).

We’ll see for how long.

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

There are better solutions than wordpress. But the ecosystem - developers, plugins and those capable of developing for it - is huge. Same with Shopify.

I like this offering by Stripe but it won't attract any Shopify customers except the tiniest ones who are basically one product shops. Even then you want lots of features that Stripe Payment Links simply doesn't offer.

Now, if Stripe could offer their own hosted ecom solution... Hey, Stripe, get on this, it makes all the sense.

Is it? PayPal has offered the same service for nearly a decade; it even supports subscriptions (I'm not positive if this does or not).

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.

[1] https://buffer.com/revenue

No I don't see when the revenue got a hit? Pretty sure scheduling post has been around for a couple of years at this point?

That's his point: you can't see where revenue got hit, despite the functionality being replicated by Facebook.

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.

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.

I love watching Stripe going upmarket with e-comm streamlining offerings (links, subscriptions), the foresight shows (payment commodification eventually, Value Add Is The Way).

Thank you for the kind words! We're always working to improve our products; feedback welcome!

I'm in Mexico right now and the gif/video animation was in Spanish. A+ for polish.

My language, plus my currency. Pretty good job.

Off topic: can anyone recommend a Stripe alternative that's a bit less risk averse than stripe is?

I'm trying to test the water with a service in the crypto space (it's not about selling/buying cryptocurrency, but about automating some stuff regarding blockchain interaction). I got declined by Stripe based on their terms of service (i.e. don't mention the word blockchain).

I'm currently looking into payrexx (however seems way less polished than Stripe), and I've heard about Ayden and Mollie (don't know if they are equally conservative). Any recommendations?

Sorry in advance, I don't want to sound snobby, but did you mean 'risk averse'?

Yes, thank you Swype keyboard

I don’t know about their terms of service, but I’ve heard good things about Adyen. They also support more payment methods than Stripe: https://www.adyen.com/payment-methods.

Adyen has payment links too

The Paylink solution from Payrexx is very sophisticated and offers more options than almost any other solution. See: https://www.payrexx.com/en/products/paylink/

I quickly looked around but I couldn't get an idea on how Stripe handles the AML and similar complience stuff on this.

There have been similar services for years now, one is especially popular among people who sell illegal items and services like IP TV for pirated premium sports channels since they can quickly create per order link that is disguised as selling hamster supplies or drilling heads.

Shady transactions are never out of reach, I just stumbled upon on one here: https://twitter.com/charliehtweets/status/139686085069939507...

That's the interesting part of payment processors IMHO. Taking an order and making a transaction is a technical achievement maybe for a junior developer.

It's a shame that the material on the business and legal side of these things is limited. Only engineers like sharing their ways :)

The key thing to understand is the difference between the actual law, individual company's implementation of the actual law, individual company's policies that have nothing to do with the law and are just a shitty inconvenient business practice, and individual company's representatives that don't know the difference between any of that and just say any inconvenience or transaction limit is because of "anti money laundering compliance"

Once you know, there is a lot you can do.

But back to the actual law, AML is primarily the creation of a firewall between the physical bearer cash system and the electronic financial system conducted by banks and other financial intermediaries. Anything on the inside of the firewall has already passed AML, meaning that financial institutions and card processors can just assume AML has already occurred. Additionally, inside the firewall, some parts of the electronic financial system can be temporarily ostracized by sanctions. So the only check would be the OFAC list at that point to determine if you can accept payment or not.

Compliance for a payment processor has nothing to do with detecting fraud and is pretty much just the OFAC list.

So that's the answer. You wouldn't get an idea because there is nothing specific for them to do.

> Compliance for a payment processor has nothing to do with detecting fraud and is pretty much just the OFAC list.

I suspect that it's not that simple. I did some work for people in compliance, I have some idea on the work they do and it's not simply department of people simply checking against the OFAC list.

I'm a bit familiar with banks and not with money processors though. I have seen the bank side of the relationship and they can be very nervous when working with payment processors that bring bad money(scammers, pyramid schemes, drug money, terrorism financing etc).

I like the firewall concept but it feels incomplete. Stripe must be doing a lot of interesting work to not be the shady company that the banks don't like working with.

If you have more concrete knowledge on the topic, what is the hard part of running money transaction service, I.E. money processor? Atomic book keeping is not the challenge keeping every kid on the block from starting a money processor business, I would guess.

on the legal side with the banking regulators that's all it is.

the rest is to simplify the likelihood of being part of a department of justice criminal inquiry - not because they did anything wrong, only to prove that they had no part in doing it or having to assist prosecutors and defense. if they just ban customer transactions that don't match their risk matrix, then there isn't data to provide to a prosecutor.

outside of that is the relationship with other banks. basically the underlying financial institutions can arbitrarily cut their peers off or be cut off. like you pointed out.

I'm still drawing a distinction between voluntary "I think I know what I'm doing" compliance and the mandatory compliance that is pretty clear cut.

The result for customers is pretty crappy. None of this anti-money laundering dragnet stuff works and we're the ones burdened with arbitrarily low dollar amount stigmas and limits ($2,000, $10,000) and all the liability. While we occasionally hear about a $2bn decade long money laundering system from a single financial institution dealing drugs with the literal cartel. All to prevent terrorism, which isn't even that expensive. 200,000 9/11's, congratulations everyone. The reality, since apparently nobody actually wants to blow up buildings in the US, is the financial institutions have been tasked with data mining for the state.

The merchant should have passed through KYC and AML in order to set up a relationship with Stripe. And then transactions for that merchant would typically be monitored for both AML and fraud alerts. I'm not sure whether there's any AML requirements on processors as it relates to the purchaser.

I've seen this feature on Indian payment gateway companies for years now, so I guess I'm not terribly excited. Is this truly a new thing in the US?

I can't test it:

1. I'm logged into Stripe's default dashboard

2. I go to https://stripe.com/payments/payment-links and press "Start Now"

3. I get redirected to a registration page

4. I press "Have an account? Sign in"

5. I get redirected to Stripe's default dashboard

If you're logged into the Stripe Dashboard already, best to go to Products > Payment links. https://dashboard.stripe.com/payment-links

(https://stripe.com/payments/payment-links was originally intended for new users, but we'll look into making that Start button better.)

Ok, so time to abandon https://www.honorarium.cc/ ? At least it happened before all the polishing began...

So how does this differ from PayPal pay buttons from the 2000's?

Mollie has been providing this service under the Plink [1] brand name for quite a while, I was looking for something to get my clients onboard with Stripe without using Billing (main reason being Mollie having difficulty serving corporate US cards from time to time). Nice move, simple product, extremely useful!

[1] https://useplink.com/en/

There are other niche PSPs who have been doing exactly this for over a decade.

For context, in the Netherlands (where Mollie was founded) sending payment requests by text took off when one bank set up a service geared for consumers that provided this (Tikkie [1]). Mobile payments were common place before this, so customers were already used to this.

Taking this to the next level, by having businesses use this is a great and logical step.

[1] https://www.abnamro.nl/en/personal/internet-and-mobile/apps/...

Implemented a small app this, such a clean API. Love it and hope it goes pan-European. Although I think it may be the Dutch money culture that got it to blow up so bi, ha!

I'm curious, what is the "Dutch money culture"? I haven't used paper money in ages, is that specifically Dutch or are you hinting at something else?

The "I send you a tikkie for this .25ct tomato paste can"-meme.

I wish there was a "donation links" feature similar to this, that supported recurring donations. There are a lot of companies like DonorBox that offer this but shave a decent percentage off the top of every donation which is hard on non-profits.

PayPal has a donation link feature, but PayPal stinks in every possible other way.

We're excited to build donations support via Stripe Payment Links. Drop me a note at jackerman@stripe.com and I'll let you know as soon as it is live.

Hi! Late to the party, but this is exactly the kind of problem that my startup, Trolley, solves.

Warning: shameless plug.

It's a no-code shopping cart that works with Stripe. We offer Donations 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)

You take 2% off the top of what Stripe already takes. No different from DonorBox. You mention on your website that there are discounts for non-profits, but I assume it's not 100%.

The idea is that if Stripe offers it, they won't take anything off what they already take.

Hate to be a party pooper, but what about Sales Tax handling?

I'm also interested in this, and someone recently shared this with me: https://stripe.com/newsroom/news/taxjar

Apparently Stripe's acquisition of TaxJar is meant to expand their offerings in sales tax compliance.

From the article:

As the latest addition to Stripe’s revenue platform, TaxJar will help businesses automate tasks such as:

- Providing accurate sales tax rates at checkout, tied to the exact street address of the customer.

- Automatically submitting tax returns to local jurisdictions and remitting the sales tax collected.

- Producing local jurisdiction reports to show sales and sales tax collected—not only for each state, but for relevant counties, cities, and other special jurisdictions.

- Evaluating a company’s products and intelligently suggesting the right product tax code.

We have a number of exciting tax-related launches with Stripe coming soon. Drop me a note at jackerman@stripe.com and happy to give you early access.

"exciting" tax-related ...

You keep using that word, I do not think it means what you think it means. ;)

This sounds great! We switched to Paddle (https://paddle.com/) so we didn't have to do tax compliance ourselves. Might switch back...

Drop me a note at jackerman@stripe.com and happy to give you a sneak peak about some cool taxes-related features we're launching very soon.

Feel you on taxes = party pooper... but yes, Stripe can help handle sales tax: https://stripe.com/docs/payments/checkout/taxes. Much more on that front (VAT, Tax ID collection) coming very soon.

It would be great to have a dedicated page to display all the products, that have been created by Stripe Payment Links. So when I shared the link, customer also can have an option to navigate to that page and view other products, available right there to purchase.

https://buy.stripe.com/dR6cOd9RJ8KS8nufYZ

For this demo link for example, I wanted to see other stickers in "Stripe Sticker Shop". May be this more of a e-commerce feature, rather than a payment/checkout solution, but after all it is all about selling and buying.

Hey Patrick, this is cool.

Is payment link creation available as an API ? That would change everything

Coming soon! Could you email us and we'll let you know once it's available? jackerman@stripe.com + edwin@stripe.com

https://squareup.com/us/en/online-checkout

What is unique to this over what Square as already done:https://squareup.com/us/en/online-checkout

Awesome feature.

The first thing that comes to mind for me is fraud. Most obviously, what guarantees are in place that when I go to one of these links, that the seller company is who they say they are? I assume Stripe audits their customers and, for example, reviews the seller logo that's displayed to make sure it isn't misleading. But also, does Stripe give the seller any analytics about who (or how often) people are going to their sales link, even if they don't make a purchase? thanks :)

When a seller creates a Stripe account to use Payment Links, they go through the same review processes (and face the same stringent regulations from card networks and banks) as any seller who creates a Stripe account to integrate our Payments API directly with their website. They will be rejected by Stripe if they violate our terms of service (i.e., if they're fraudulent).

Sellers will be able to see if the buying process is started when a payment link is clicked: either through the Stripe Dashboard or through the API by listening for `payment_intent.created`.

Cool, thanks for the clarification!

My only suggestion would be to maybe put the name of the seller in the URL, that way you can see something about who you'd be paying before clicking the link. I'm not sure that helps any particular threat model but it would make me feel better about even navigating to the stripe link somehow.

Also, I recommend adding a "Report" button to the page, so that would-be buyers can report if they arrived at a checkout page through fraud/misrepresentation.

How do people handle taxes/accounting/receipts and invoicing for this kind of stuff. At least in the EU it would be a nightmare if you rely on a bunch of such links to sell.

Just use Paddle

Razorpay has had this for a while . Stripe seems to be catching up.

Are we able to create these via the API (specifically through Connect)?

I'd love to dig a bit deeper into the docs on integrating with this, but haven't managed to find them yet.

Not today, but a Payment Links API is coming soon. (Will shoot an email if you'd like to test it.)

That would be awesome, thank you!

A similar idea, but for periodic donations. Sites offer "subscription links" that get a share of your fixed donation budget per month, meaning that if you designate 50 usd per month for donations, all those you're donating to will have to split 50 usd. In addition to that, stripe lets you kick out any subscription from the list. Stripe can also aggregate these micropayments to reduce visa/ACH/whatever fees.

Conversational Commerce

Question: for those who run e-commerce sites, how common do you see Conversation Commerce gaining use by buyers? E.g. significant portion of sales, small portion of sales, gaining adoption, declining adoption?

Just curious since the demo on Stripe's site is exactly this use case where someone is provided the link to purchase via a chatbot.

What about an mpesa for the Western world? Paying money to bricks and mortar merchants by entering a short code?

Same as https://www.plugnpaid.com ?

In case it helps anyone, I've just put up a 3 minute demo of Stripe Payment Links: https://www.youtube.com/watch?v=bLNFJNoL9e8 (as a user of Stripe Checkout it was the natural next step)

I got scammed on a page like this recently through paypal. The page showed up on google shopping. It had the right picture and text. They mailed me one sock instead of the ~$100 item i wanted. luckily paypal refunded me but this was not a great experience

The significance of this is that now it is officially rubber-stamped by Stripe to just have a payment form on a website with shallow content (ie. no products or services).

Send a link to get paid even if your product isn't launched yet, is what this is all about.

The danger of this is that the rubber-stamp of Stripe may turn to a stamp to avoid if this becomes infamous for shady transactions

SumUp's had something like this for a while now, US included: https://sumup.com/remote-payments-usa/

I'm still trying to figure out a simple way to sell a DIGITAL product. How to prevent anybody who buys a copy to make a thousand copies from it and share them on the internet. Is there such a way?

Isn’t that what NFTs are for?

https://www.wired.com/story/nfts-boom-collectors-shell-out-c...

Nope, NFTs are for claiming that you own the “original” digital work. It doesn’t prevent people from copying and sharing it.

So NFTs are basically something like copyright? Only the person having the copyright can sell it.

So why do we need NFTs if we can own a copyright to some digital creation, and can sell that copyright as well?

Depends on the digital product, but usually you're looking at something like a license key and DRM.

If someone is determined enough, they _will_ distribute thousands of copies of it though.

I recently came across Fastspring, they let you generate a license key upon purchase. I'm not using it myself, but it might be helpful https://fastspring.com/docs/fulfillments/

Seems interesting, thanks

Depends on your product.

If you have a product that need support or updates, don't worry about some people that make copies. They are uninteressiting.

People pay you for an up to date product with support.

I run a SaaS for licensing: https://keygen.sh. To ensure the app isn't shared and used across many devices, you can use device activation. You can integrate it with Stripe pretty easily using webhooks. I'm working on adding a no-code Stripe integration for payments + licensing later on this year, if my roadmap holds up.

How do you handle a merchant in, say, Mexico and a customer in the US?

I'm going to set this up for one of my products tomorrow. There doesn't seem to be a way to request delivery information though. Hope I'm wrong.

There is! When creating a link, just check "Collect customers' addresses."

I built something like this way back in 2008, since paypal let you set a IPN dynamically. Was basically a pastebin behind a paywall. I found it incredibly difficult to market, but I think I was doing it wrong because gumroad took off many years later

https://www.redferret.net/tiny-checkout-very-cool-little-onl... https://web.archive.org/web/20090227044608/http://www.tinych...

1.4% doesn’t sound too bad. I believe chip and pin point of sale is .65% to .85%. What are MasterCard / Visa’s rates for online sales?

Which market are you in? In the US I'm seeing "Starts at 2.9% + 30¢ per successful charge"

Europe presumably where interchange fees are significantly lower than the US. I see:

1,4% + 0,25 € for European cards 2,9% + 0,25 € for non-European cards

In EU Stripe is 1.4% + €0.25 for European cards, 2.9% + €0.25 for foreign cards, https://stripe.com/en-fi/pricing. There have been no recent changes to this.

I’m seeing the UK rate on Stripe’s site and the comparison is with Barclaycard’s UK POS debit rates.

+ 25ct is pretty bad for EU cards and stripe does not support any other payment methods (important for the European market). I recommend you consider other PSPs like Adyen (a stripe clone; ~1% + 10ct) or Mollie, though I have tried neither.

Is this Zapier-able? This is brilliant. Thank you!

Yes: https://zapier.com/apps/stripe/integrations. Would suggest chatting with https://twitter.com/bentossell, who runs Makerpad (Zapier) and uses Payment Links!

The page's hero animation is so good though

This looks great! Will it be possible to create a link on a backend application and have all the frontend handled by Stripe?

We're excited to build an API for Payment Links soon. Drop me a note at jackerman@stripe.com and happy to add you to the early access beta when we launch!

This is off topic, but all of Stripes landing pages are a masterpiece of web design. Just so pleasent to browse.

TillyPay? https://tillypay.com/

Hey folks! This is great! Do you have plans to launch in more latin american countries other than BR and MX?

Do you have any plans to open a service in Korea? I'm looking forward to it.

Is there a way to automate emailing the user an ebook or any other digital good?

Yes! We've built a Zapier integration that'll help you do just that. Drop me a note at jackerman@stripe.com and happy to share further details with you.

We'll try this in lieu of PayPal invoices since those have become a pita.

Someone told me there will be free cupcakes along with this announcements :(

Stripe 1 - Paypal 0

I surely will be looking into this as Paypal fees are way more expensive

PayPal has had this for years with paypal.me

meh, maybe this is big outside the us, but people just ask to be paid on Venmo/Cashapp around here.

I don't see people wanting to share their numbers so they can get a clickable link.

Any chance of expanding this to be similar to PayPal add to cart?

Do you have any plans to open a service in S.Korea?

I just wish I could use regular Stripe. :'(

2.9% + $.30 is insane. I can’t believe such a simple product is apparently worth so much.

I guess this one’s going on Visa/Mastercard/etc as they are the ones charging the most of these fees[0].

[0] https://www.fool.com/the-ascent/research/average-credit-card...

Even more expensive if you're in Canada and want to accept USD.

Can someone tldr what PayPal has been doing for the past half decade. While startups has been eating their lunch.

So Gumroad is dead???

Different targets. And there can be multiplayers.

Gumroad is essentially a one-person company. Maybe they are impacted. I doubt they will be dead.

Are they setting foot outside USA yet? Just wondering.

Stripe has set foot in 44 countries—with many more countries on the roadmap. https://stripe.com/global

Yes.

https://stripe.com/global

Available in 38 countries, previewing in 6

Glad I am long $PSTH

How PayNowLink can create Stripe links without using an API ?

Hey pc! Fellow startup founder here - we're creating a decentralized metaverse platform in WebGL, and I'm thinking this would be perfect as a easy-to-use payment system for creators and indie game devs to take payments in our ecosystem.

I believe I patented this in 2016: https://patents.justia.com/patent/10664883

And you're posting it here because...why?

If you think there's a legal issue, this, obviously, isn't the forum.

If you want to tell people "I had this idea first!" this also isn't the forum; you're either wrong, or are pointing to the wrong thing (patents aren't particular readable or understandable); show us the thing you made.

Because I am excited that this idea got turned into a viable product. And what is wrong with sharing the excitement with my fellow nerds including the fact that I had this idea first? It is all about execution and kudos to stripe for taking this idea forward and turning into a viable product.

Gumroad had this since 2011, 5 years before you filed your patent.

Then perhaps a comment along the lines of "This is really neat! I'm so glad to see someone else doing this; I originally patented something akin to it and then (never used it/did and here's the thing I built), and it's awesome to see continued development in this area".

As it is, it's not clear what your intent is (hence my question). You aren't congratulating them. You aren't expressing excitement. To your credit, you also aren't claiming they're infringing, though it begins to approach it.

> If you want to tell people "I had this idea first!" this also isn't the forum

This is a good forum for it since it is for showing new products.

If this violates a patent, I definitely want to know.

If it doesn't, then there will be no problem, right?

Did you look at the patent? Did you understand it? Do you have the legal knowledge to both understand if the patent is valid (since plenty have been overturned in the past), and that this in fact violates it?

If not yes to all of those, the comment hasn't helped illuminate you in any way.

After reading the "Summary" of that patent twice, I believe you patented everything that ever is, has been, or will be done on a computer in 2016.

Oh yeah, that is what you get when you submit your diagrams and invention specifications and API to a team of lawyers :)

If you search the word click, it takes you to meat and potatoes but very well said. I was quite furious with the lawyers at the time but they had to navigate existing prior art and ability to defend this in future.

Gumroad does something similar for years.

Not a lawyer but you didn't patent this. A patent only covers what's described in its claims, and looking at Claim 1 (the only independent claim) there are lots of very specific features that would have to be present for your patent to cover this.

Even if one of these stripe payment links is posted to a public social media channel, presumably neither the person doing the posting or stripe is going to do this because there's no association between the social media channel and the checkout page that stripe creates:

> conducting, by the processor, predictive modeling using the activity information, purchasing likelihood based on a number of visits by the user to the channel, past purchases by the user, and demographic information of the user;

Even if stripe was doing everything else in Claim 1 of your patent, just not doing this one thing means they aren't infringing your patent. (Again, not a lawyer, so don't listen to me).

Also, I may be wrong about this, but I suspect that the way you are using "processor" in your claims actually makes your patent 100% worthless, because it's describing both actions that would take place on the client side and on the server, so it will literally never be the case that the same processor is going to perform all of these steps even if they were all occuring in some implementation.

Reply on news.ycombinator.com