[HN Gopher] Stripe Payment Links
___________________________________________________________________
Stripe Payment Links
Author : joeyespo
Score : 493 points
Date : 2021-05-25 18:00 UTC (4 hours ago)
(HTM) web link (stripe.com)
(TXT) w3m dump (stripe.com)
| parhamn wrote:
| I'm in Mexico right now and the gif/video animation was in
| Spanish. A+ for polish.
| EastSmith wrote:
| My language, plus my currency. Pretty good job.
| gorgoiler wrote:
| 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?
| mfkp wrote:
| Which market are you in? In the US I'm seeing "Starts at 2.9% +
| 30C/ per successful charge"
| bjohnson225 wrote:
| Europe presumably where interchange fees are significantly
| lower than the US. I see:
|
| 1,4% + 0,25 EUR for European cards 2,9% + 0,25 EUR for non-
| European cards
| AnssiH wrote:
| In EU Stripe is 1.4% + EUR0.25 for European cards, 2.9% +
| EUR0.25 for foreign cards, https://stripe.com/en-fi/pricing.
| There have been no recent changes to this.
| MinorTom wrote:
| + 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.
| nfoz wrote:
| 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 :)
| edwinwee wrote:
| 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) as any seller who
| creates a Stripe account to integrate our Payments API directly
| with their website. They will be offboarded 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`.
| akomtu wrote:
| 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.
| RikNieu wrote:
| I just wish I could use regular Stripe. :'(
| purple_ferret wrote:
| 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.
| newsbinator wrote:
| 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
| edwinwee wrote:
| 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.)
| e_commerce wrote:
| Please reduce fees
| throwkeep wrote:
| Gumroad?
|
| https://twitter.com/shl/status/1397254513627705345
| pgrote wrote:
| 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.
| arkitaip wrote:
| This IS terrific news if you are using Stripe and want to
| stick with them as your one payment solution.
| loceng wrote:
| Until adoption increases enough and they decide they can
| milk customers even more?
| [deleted]
| giarc wrote:
| Gumroad deposits to Paypal, Stripe deposits to bank account.
| Seems like a big difference, no?
| swyx wrote:
| 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)
| Kye wrote:
| 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.
| __float wrote:
| According to https://help.gumroad.com/article/260-your-
| payout-settings-pa..., it depends on Stripe's availability
| for ACH payouts.
| aazaa wrote:
| Gumroad also deposits to bank account.
| treelovinhippie wrote:
| 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.
| foolfoolz wrote:
| 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
| toomuchtodo wrote:
| I love watching Stripe going upmarket with e-comm streamlining
| offerings (links, subscriptions), the foresight shows (payment
| commodification eventually, Value Add Is The Way).
| jackerman wrote:
| Thank you for the kind words! We're always working to improve
| our products; feedback welcome!
| soheil wrote:
| 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.
| cblconfederate wrote:
| 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
| lenitabinol wrote:
| Glad I am long $PSTH
| ecommerceguy wrote:
| We'll try this in lieu of PayPal invoices since those have become
| a pita.
| dakial1 wrote:
| 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.
| redindian75 wrote:
| 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?
| jackerman wrote:
| 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
| t7s wrote:
| Any chance of expanding this to be similar to PayPal add to cart?
| [deleted]
| symlinkk wrote:
| 2.9% + 30% is insane. I can't believe such a simple product is
| apparently worth so much.
| flarg wrote:
| What about an mpesa for the Western world? Paying money to bricks
| and mortar merchants by entering a short code?
| mixcocam wrote:
| 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.
| edwinwee wrote:
| There is! When creating a link, just check "Collect customers'
| addresses."
| ds wrote:
| 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...
| [deleted]
| samblr wrote:
| Hey Patrick, this is cool.
|
| Is payment link creation available as an API ? That would change
| everything
| edwinwee wrote:
| Coming soon! Could you email us and we'll let you know once
| it's available? jackerman@stripe.com + edwin@stripe.com
| paymentsstack wrote:
| https://squareup.com/us/en/online-checkout
| gmcquistin wrote:
| This looks great! Will it be possible to create a link on a
| backend application and have all the frontend handled by Stripe?
| jackerman wrote:
| 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!
| londons_explore wrote:
| So how does this differ from PayPal pay buttons from the 2000's?
| tmikaeld wrote:
| Same as https://www.plugnpaid.com ?
| renewiltord wrote:
| Is this Zapier-able? This is brilliant. Thank you!
| edwinwee wrote:
| Yes: https://zapier.com/apps/stripe/integrations. Would suggest
| chatting with https://twitter.com/bentossell, who runs Makerpad
| (Zapier) and uses Payment Links!
| collaborative wrote:
| Stripe 1 - Paypal 0
|
| I surely will be looking into this as Paypal fees are way more
| expensive
| grenoire wrote:
| 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/
| the-dude wrote:
| There are other niche PSPs who have been doing exactly this for
| over a decade.
| vincentkriek wrote:
| 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/...
| grenoire wrote:
| 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!
| vincentkriek wrote:
| 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?
| markus92 wrote:
| The "I send you a tikkie for this .25ct tomato paste
| can"-meme.
| yannoninator wrote:
| 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!
| notdang wrote:
| Wasn't this available for years from other payment providers?
| Benjamin_Dobell wrote:
| 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.
| jackerman wrote:
| 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.
| Benjamin_Dobell wrote:
| 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 :)
| throxwaway98123 wrote:
| Yep yep yep.
|
| The things this will enable are endless.
|
| This is truly headless e-commerce.
| Androider wrote:
| Hate to be a party pooper, but what about Sales Tax handling?
| amzans wrote:
| 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.
| jackerman wrote:
| 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.
| wilg wrote:
| This sounds great! We switched to Paddle
| (https://paddle.com/) so we didn't have to do tax compliance
| ourselves. Might switch back...
| jackerman wrote:
| 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.
| edwinwee wrote:
| 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.
| jordhy wrote:
| So Gumroad is dead???
| ergocoder wrote:
| Different targets. And there can be multiplayers.
|
| Gumroad is essentially a one-person company. Maybe they are
| impacted. I doubt they will be dead.
| LordAtlas wrote:
| 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?
| saltedonion wrote:
| Can someone tldr what PayPal has been doing for the past half
| decade. While startups has been eating their lunch.
| fukmbas wrote:
| I'll pretty much never trust this. Hard telling what's a scam
| [deleted]
| slig wrote:
| Is there a way to automate emailing the user an ebook or any
| other digital good?
| jackerman wrote:
| 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.
| paymentsstack wrote:
| What is unique to this over what Square as already
| done:https://squareup.com/us/en/online-checkout
| alberth wrote:
| _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.
| NonEUCitizen wrote:
| 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.
| jackerman wrote:
| 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.
| raviisoccupied wrote:
| 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.
| jackerman wrote:
| Awesome! Can't wait to hear your thoughts/feedback on Payment
| Links; feel free to reach out at jackerman@stripe.com
| thinkafterbef wrote:
| TillyPay? https://tillypay.com/
| astlouis44 wrote:
| 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.
| korijn wrote:
| Are they setting foot outside USA yet? Just wondering.
| edwinwee wrote:
| Stripe has set foot in 44 countries--with many more countries
| on the roadmap. https://stripe.com/global
| iou wrote:
| Yes.
|
| https://stripe.com/global
|
| Available in 38 countries, previewing in 6
| endisneigh wrote:
| 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.
| msencenb wrote:
| 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.
| edwinwee wrote:
| Not today, but a Payment Links API is coming soon. (Will shoot
| an email if you'd like to test it.)
| msencenb wrote:
| That would be awesome, thank you!
| throxwaway98123 wrote:
| 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
| zyang wrote:
| Shopify is fine. They have a nice eco-system of devs and
| integrated apps. Gumroad should be worried.
| throxwaway98123 wrote:
| 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.
| mod wrote:
| 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.
| dangrossman wrote:
| 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
| throxwaway98123 wrote:
| 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.
| thebean11 wrote:
| Shopify is $29 per month on the cheapest plan. That's not
| going to make or break anyone's online store.
| pc wrote:
| 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.
| picardo wrote:
| 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.
| theturtletalks wrote:
| 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.
| ThalesX wrote:
| They provide me with 1.4% + $0.24 for European cards which
| is a whole lot less than even national banks offer me...
| iamben wrote:
| 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).
| throxwaway98123 wrote:
| 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
| arkitaip wrote:
| 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.
| iamben wrote:
| There are better solutions than wordpress. But the
| ecosystem - developers, plugins and those capable of
| developing for it - is huge. Same with Shopify.
| Elidrake24 wrote:
| 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).
| CallMeJim wrote:
| 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
| orliesaurus wrote:
| 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?
| mediaman wrote:
| That's his point: you can't see where revenue got hit,
| despite the functionality being replicated by Facebook.
| Rafert wrote:
| 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.
| pc wrote:
| (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
| algo_trader wrote:
| Can this be (or will be) integrated with Stripe Connect?
|
| So that a StripeLink buyer who is being charges can also later
| receive revenue ?
| jackerman wrote:
| 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
| d0100 wrote:
| 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
| jackerman wrote:
| Working on it right now! Drop me a note at
| jackerman@stripe.com if you'd like to try it out.
| ithkuil wrote:
| 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.
| pc wrote:
| Working on the rest of the EU!
| IncRnd wrote:
| 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.
| jackerman wrote:
| Totally! We couldn't agree with you more.
| rexreed wrote:
| 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?
| edwinwee wrote:
| 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.
| leesalminen wrote:
| You can use Stripe Webhooks + a "no-code" solution like
| Zapier to make that happen in ~15 minutes.
| rexreed wrote:
| 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.
| tosh wrote:
| 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.
| vmception wrote:
| 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.
| benhurmarcel wrote:
| 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.
| vmception wrote:
| 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.
| athenot wrote:
| > 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.
| ethbr0 wrote:
| 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?"
| wftglf wrote:
| > 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!
| tmamic wrote:
| When are you going to offer services to entrepreneurs in
| countries such as Nigeria, India and Philippines?
| pc wrote:
| 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.
| vincentmarle wrote:
| > no code required
|
| While I love this, is there a way to also programmatically
| create these links?
| edwinwee wrote:
| Working on it! A Payment Links API is coming very soon.
| lloydatkinson wrote:
| 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.
| sudhirj wrote:
| I think this is just a normal Checkout/Payment in the API, so
| there seems to be a webhoook for it.
| pc wrote:
| Yep, all webhooks still sent as normal.
| bgilly wrote:
| 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!
| jackerman wrote:
| Thrilled to hear it, and can't wait to hear your feedback!
| flipnotic wrote:
| 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.
| jackerman wrote:
| 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!
| pc wrote:
| There's a lot of cool stuff that uses Paystack on Twitter,
| e.g.: https://twitter.com/spokenword_lag/status/1396773924713
| 73005.... You can search for paystack.com/pay.
| rorykoehler wrote:
| 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.
| samcgraw wrote:
| 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
| pc wrote:
| 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.
| bombcar wrote:
| 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.
| siruva07 wrote:
| 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.
| slivanes wrote:
| 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.
| mattbk1 wrote:
| Just remember that flags aren't languages.
| pc wrote:
| Good feedback -- thanks. We've long struggled to find the
| right balance between "convenient/automatically correct" and
| "non-confusing" in site localization.
| truth_ wrote:
| 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.
| amenghra wrote:
| If only there were a header browsers could send. Perhaps
| something we could call Accept-Language?
| philjackson wrote:
| What would the compromise be?
| truth_ wrote:
| 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_n
| umber_of....
|
| [1]: https://en.wikipedia.org/wiki/List_of_countries_by_E
| nglish-s...
| ceilingcorner wrote:
| English is actually the neutral compromise language in
| India.
| truth_ wrote:
| 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
| tvaughan wrote:
| 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.
| pc wrote:
| That is approximately what we do. (And then we remember
| any explicit selection that's made.)
| lutoma wrote:
| 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
| sbaildon wrote:
| 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
| jackerman wrote:
| Thank you so much! Can't wait to hear your feedback about
| Payment Links.
| danielskogly wrote:
| 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 :)
| jackerman wrote:
| 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.
| benhurmarcel wrote:
| Sorry, I'm not familiar with using Stripe yet. Is it possible
| to set a shipping fee depending on the customer's location?
| jackerman wrote:
| 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
| eloff wrote:
| 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.
| edwinwee wrote:
| 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.)
| eloff wrote:
| 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!
| zanethomas wrote:
| Stripe sucks because it 'deplatforms' those it disagrees with.
| cyral wrote:
| 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.
| joshstrange wrote:
| 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.
| cyral wrote:
| 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.
| joshstrange wrote:
| 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!
| [deleted]
| criddell wrote:
| Can you use Stripe in iOS and Android apps? I thought
| purchases had to go through Apple and Google?
| joshstrange wrote:
| 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).
| cyral wrote:
| 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.
| jeiting wrote:
| 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.
| simonsarris wrote:
| > 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.
| jackerman wrote:
| 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!
| pc wrote:
| That's a good idea.
| [deleted]
| jamesvnz wrote:
| 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).
| jackerman wrote:
| 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!
| rayrag wrote:
| 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...
| munk-a wrote:
| 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?
| sudhirj wrote:
| 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.
| edwinwee wrote:
| 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.
| abc11283 wrote:
| 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!
| edwinwee wrote:
| Aha! Thanks. Great ideas.
| sebmellen wrote:
| 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.
| farazbabar wrote:
| I believe I patented this in 2016:
| https://patents.justia.com/patent/10664883
| knuthsat wrote:
| Gumroad does something similar for years.
| lostcolony wrote:
| 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.
| farazbabar wrote:
| 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.
| ergocoder wrote:
| > 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?
| rspeele wrote:
| 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.
| farazbabar wrote:
| 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.
| resoluteteeth wrote:
| 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.
| agildehaus wrote:
| 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.
| jackerman wrote:
| 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.
| mrtksn wrote:
| 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
| :)
| jdmichal wrote:
| 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.
| vmception wrote:
| 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.
| mrtksn wrote:
| > 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.
| vmception wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2021-05-25 23:00 UTC)