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.
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.
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.
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.
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.
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.
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
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].
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].
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.
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.
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.
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.
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)
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!
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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 :)
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.
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?
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
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.
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.
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.
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 :)
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.
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).
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
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.
There are better solutions than wordpress. But the ecosystem - developers, plugins and those capable of developing for it - is huge. Same with Shopify.
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.
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 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).
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?
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.
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.
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.
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!
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.
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 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.
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.
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.
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.
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.
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`.
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.
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.
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.
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.
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