Hacker News new | past | comments | ask | show | jobs | submit login
Unexpected challenges of making money on the internet (kapwing.com)
359 points by jenthoven on Mar 8, 2018 | hide | past | web | favorite | 161 comments

> Relying on Google and Facebook Identity is not sufficient for some professional users...We like that accounts have mostly real names and verified email addresses,...but I do think the validity of emails will decrease. Takeaway: If you’re creating a sign up flow for your app, you should think about these trade offs between social and email-based auth.

This is absurd and shows that they aren't thinking from the perspective of their users (even though they have an "I really don't want to pay" option).

There are many reasons why people might want not to link everything together; in fact this is a reason why many prefer paypal (more transactional) to linking directly to their CC. This is also especially true for low-intensity sites like this one (you may see the justification for linking Tinder to your FB account, but you likely use this service much less than you use TInder!).

Secondly, and again related to low-intensity sites: why should they care about real names?

I would (almost) never use a site that only allowed this as a means to login... it's so absurd that these are the only options. There should be two things they are interested in: 1. Is the email valid? 2. Is the credit card and details for that valid? Anything else is a distraction to making money.

I would (almost) never use a site that only allowed...

If you're a business customer, you'll use whatever auth system is presented. And 80% of the time Google login is perfect; the other 20% will deal.

"Oh, your product will save me thousands of dollars? But it requires a Google account? Sorry, can't use it"... said nobody, ever.

There's a huge difference between B2B and B2C customers, and you need to understand which business you're in. Yeah, if you're trying to accommodate the mass market, you need all the options. If you have a niche product that makes money for people, you should spend all your time working on features that make people money. Auth is not one of them.

> "Oh, your product will save me thousands of dollars? But it requires a Google account? Sorry, can't use it"... said nobody, ever.

You've clearly never worked in China. All people are not living your circumstance.

I run a one person business and I often feel bogged down by little things. If I need auth and I can let some huge companies take care of auth for me and they’ve got simple APIs, I may choose that over some kind of roll my own. Personally I wouldn’t want to force my customers to participate in these surveillance platforms but I have also never made money on my businesses - perhaps because I put too much effort in to the little details.

Edit: I also imagine fraud is costly, and if the big platforms can save me dev time on auth and reduce problems with fraud, that adds up to a significant savings.

Fraud and auth are two orthogonal things. The only thing this does is save you from implementing a really basic login system which is really not much code to implement if you use something like devise or some other auth library. if fraud is a goal to prevent use something like paypal or stripe which is better than small shops at detecting it over some generic merchant account. All this does is tie people into one closed system identity which most people have more than one functional identity(e.g. my business identity is different than my personal identity is different than my family identity). If you force me into using facebook to login to a system where I might legitimately want to separate personal, business and family accounts you lose me as a customer. Also, you may be using some service on behalf of someone else and then what? the customer has to give you access to their facebook account? it's just shortsighted and, frankly, dumb to only allow facebook/google to control auth. use it as an additional auth mechanism if you want to but don't solely make that your only method.

> why should they care about real names?

Exactly. What is it about technologists that makes them feel so entitled to everyone's personal information?

She wants to know the "real names and verified email addresses" of everyone who uses her video editor, but I wonder how she would feel about giving the same information to manufacturers of stationary or household supplies she uses or to every restaurant she visits.

Google Accounts are free and simple to create, so if a user doesn't want to "link everything together" they can create a new separate account that they only use for Kapwing. Plus, we're aren't "linking" to your Facebook/Google data; we're just reading your name and email from your account.

We decided to rely on Google and Facebook for three reasons: 1. It's technically easier, and since so few users care about needed to sign in with one of them it's a low-priority feature request to add email sign in. 2. My co-founder and I worked on Google's identity team for a year. The fact is that passwords SUCK - people hate them and they lead to a huge amount of friction in UX. Reducing the number of passwords that a user needs to remember is a huge benefit. 3. Having user's "real" identity helps with validating credit card transactions, sending follow-up receipts and confirmations, and personalizing the site. If we do one day become a social network, we're less likely to be taken over by bots.

>Google Accounts are free and simple to create, so if a user doesn't want to "link everything together" they can create a new separate account that they only use for Kapwing. Plus, we're aren't "linking" to your Facebook/Google data; we're just reading your name and email from your account.

I don't know about Kapwing, but the problems with this:

1. Simple to create? I just went to the page and it wants birthday, gender, phone number, among other things. And then on top of that, I'm sure there will be a bit more work to confirm my identity (text message or email). Certainly not trivial. And will I need to go yet one more step to confirm anything from Kapwing?

2. Do I need to now monitor this new account for stuff from you? Overhead for me to maintain yet another account, in order to maintain yet a third account (Kapwing).

Benefits of email for me:

1. It's easier to create a throwaway temporary email account than to create a Google account. It is intentionally easier. They exist just for this purpose. Not sure if you've tried it.

2. Clicking on a confirmation link is easy for me.

>Having user's "real" identity helps with validating credit card transactions, sending follow-up receipts and confirmations, and personalizing the site.

This is where creating a separate Google account just for your site would be a negative. I'd have to set it up to forward to my email. I'd rather just get the email from you directly.

Google accounts are not really simple to create if you want to keep things separate.

I have had to create a number of separate Google accounts (for cheap tablets I do not really trust), and it seems Google randomly locks them, requires phone number verification, and does other annoying things.

Your blog post already explained why you thought this would be a good idea from your POV; I was pointing out that it's not uniformly a good idea from your customer's POV. But your reply to me was also from your perspective, not from a wide spectrum of customers'. That's a limit to growth. The friction of "simply" creating a new account on a different site in order to use yours? Forget it!

If your business runs the way you want it to then what I'm saying doesn't matter to you, and shouldn't. I don't mean this as criticism

(BTW I doubt you know about the failure rate because people who don't want to do that are most likely to silently go away without becoming customers. It's like a paywall, or those horrible splash screens that you have to click-away that try to get me to sign up before showing me the content. I simply refuse to visit those sites (I have a blacklist keystroke) so the people who deploy those antipatterns don't even know they are missing out on pageviews. Instead the collect only the positives and reason from there.)

I'm of the same mindset. I won't make a Google account just for a website login, and I won't use Facebook login for anything at all after an experience with winding up in "Facebook Jail" after they decided an image I posted "violated community standards" and then unable to log into another account I had tied to Facebook. I don't know if it was a transient issue or what, but it made me step back from using anything that required such logins.

I run my own email still, and I won't manage to get locked out of my own stuff. The same cannot be said of Google or Facebook.


[This is Julia, the OC] If you're interested, we wrote a blog post on why we included the "I don't want to pay" option and our reflection on the results. It's the first blog article on our website. Also the fact that you would call this "information rape" is kind of disgusting...The user doesn't have to give us information, can create a new Google Account if they want to, and are only asked for read-only access to their name and email. Happy International Women's Day!

> 6. Many users prefer Paypal to credit cards:

I've had the same experience with my customers. I think Stripe is leaving a lot of money on the table by not promoting their brand to end users more. As an informed technical person, I would much rather hand my CC to Stripe than to PayPal, but Joe Sixpack doesn't feel the same way. Their impression is that they're giving randome websites their CC information, when actually Stripe's architecture is very reasonable.

If this affected conversions in a meaningful way for my business, I would have a hard time justifying not using PayPal instead of Stripe.

Having done both, multiple times, at scale: Implementing Paypal is about an order of magnitude harder than Stripe.

Paypal's documentation is horrid; they have several competing APIs (the most obvious choice - the REST API - has been silently abandoned); there are many active bugs; their support is slow and unreliable; the admin UX is horrid (finding transactions can be very hard); you will find yourself discovering the hard way how the system behaves on error; and oh there will be lots of errors.

Stripe is stupid simple by comparison, and impeccably reliable.

I pushed thousands of transactions per day through each. Paypal practically required a dedicated engineer to follow up on all the chaos. They periodically lost transactions (and fessed up to it after hours of debugging and support). They lost support tickets too. It's maddening.

If you aren't in a high volume business, Paypal is NOT worth the development headache. You can probably get 20% more users by spending the time building features your users care about.

That's one reason we chose Braintree over Stripe. They both take about the same amount of work to implement, but Braintree gives you the ability to accept PayPal in addition to credit cards with almost no extra effort.

[This is Julia, the OC]: We started integrating with Paypal and basically gave up because of the engineering effort required. Vs Stripe, which has a great web and iOS app and has been seamless from day 1.

Congratulations on dodging a bullet!

Paypal is one of the hidden mines that await startups - you could have had your smartest engineers working on it for months, possibly sinking the whole endeavor as other (actually important) things fail to get done. Unless you have engineering assets to burn, Paypal is absolutely toxic.

The actual bullet dodged is PayPal's tendency to freeze your account and the funds within for six months without warning, explanation or appeal. That'll kill a startup real quick.

We never had problems with PayPal freezing account, but I agree with stickfigure that PayPal API is bad (high maintenance).

I really hate when I see "Payments by Stripe" yet I have to type in my CC details. Stripe has them already, many times over.

Also, I don't necessarily see Stripe as more secure. I see Stripe as the same as handing my CC details to the one-off site. Because, while my info is in their DOM, their JS can do whatever it wants with it. It should just send it off to Stripe and get the callback. But how do I know that? For that reason, I do feel more secure when I get redirected off to a paypal.com site. I know Stripe offers this, but I never see it implemented that way. I always see the use of Stripe.js which allows my info to be in their page/DOM.

As a programmer AND a Joe Sixpack, I already have Paypal. They already have my bank/cc. I'm not going to get rid of it. By going to Stripe, now my attack vector has doubled.

That said, if there was an alternative that stored my CC info and let me do one-click buying (does Stripe do this??) that was integrated into 60%+ of payment systems, I'd gladly use it instead of Paypal, who I've grown to abhor.

You could also look at the new W3 Payment Request API [1] that stores card details securely in modern browsers.

Stripe has a Payment Request Button that enables one-click buying with Apple Pay, Google Pay, or the Payment Request API. [2] The button will choose whichever method is best and available for your specific browser.

[1]: https://www.w3.org/TR/payment-request/

[2]: https://stripe.com/docs/stripe-js/elements/payment-request-b...

Thanks, Mike! I'll check these out.

Why are you worried about unauthorized use of your credit card number? Under US law, you are liable for $0 of the charges. If you lost your physical card or had it stolen, you're liable for up to $50 of charges made before you reported it as such.

Legally and financially, if a malicious website uses my card number poorly, the consequences for me are "I notice an issue and Chase mails me a new credit card".

Debit card numbers, sure, that's a whole other ball game. But a credit card number? IDGAF if it gets stolen. It's not my problem, and I like it that way.

> Why are you worried about unauthorized use of your credit card number? Under US law, you are liable for $0 of the charges.

While you're correct, it's a huge PITA replacing a CC. I have almost all my bills going through my CC for points. Then there are places like my crap gym that charges a fee if the CC is ever denied for any reason.

Some (most) CCs will allow prior recurring charges to continue with an old/lost/stolen CC number for some period of time (potentially until the expiration date) so you can avoid that headache.

In the case of my AmEx, I have some monthly charges still using an old number from 3 years and 2 stolen cards ago. Discover used to offer this too, though I don't know if they currently do.

Except I think the vendor has to do something? I know some vendors immediately start failing and others seemingly work fine. Regardless of whose problem it is, it becomes a PITA for me.

I don't see why the merchant would have to do anything. If the card/bank allows the transaction, because they recognize the merchant using the "old" card info it'll go through.

I think the concern of losing money over a stolen credit card is very low. The concern of identity theft, OTOH, is very high and very costly. Suddenly being denied a loan to buy a house, and then having difficulty finding any place to rent - pretty bad. Took someone I know over a year to rectify.

With stripe checkout, you can click "remember me".


The sticking point for me was card expiry. Paypal consolidates my payments, so I don't have to chase around two dozen websites to update my card details every time my debit card is replaced. This issue has caused me to drop domain names in the past, so I have a strong preference for Paypal.

I only just learned that Stripe use some sort of voodoo to continue recurring payments after a card is replaced, which overcomes one of my main objections. If I were Stripe, I'd be shouting this from the rooftops.

Not Voodoo, just a service offered by the card brands. Banks notify the card brand of a new card, the card brand notifies the processor who then updates their database.

Generally processors charge $1/card updated, but stripe is pricey enough to include it for everyone.

We used to only use Stripe, but some users preferred PayPal and now it's 20% of our revenue.

As an informed technical person, aren't you bothered by Stripe insecurity? They have no separate domain and live entirely within vendor-controller DOM. It just takes one bad javascript include on vendor's site, and your CC details are stolen.

Yes, Paypal is pretty bad and I avoid using it on the websites I trust -- but if a random small store asks for the credit card, I start searching for alternatives.

Has anyone tried offering PayPal and Stripe to accept payments, but charge an additional x% for using PayPal or discount x% for using Stripe?

Just thinking about how some gas stations in the US do so to encourage cash/debit sales vs. credit card where they have to pay transaction fees.

In this use case the point would not be to avoid fees, because that's not possible here, but to avoid becoming a PayPal merchant horror story.

I wonder what's the impact of requiring Google/Facebook accounts to sign up. I never sign up for anything that requires either, but at the same time I'm not the target demographic.

I'm also surprised that users would ask for PayPal support. I've read too many PayPal horror stories to trust them, but apparently users like it.

In my experience, all the PayPal horror stories I have seen have been from merchants rather than users. PayPal tends to do a good job of protecting users, often to the detriment of merchants’ trust.

Also, PayPal services a niche of users who have bank accounts and/or PayPal credit, but no access to a widely accepted debit or credit card (such as Visa or MasterCard). Those users are often unable to use most other payment providers.

I'd rather pay with PayPal on a small web shop than input my card details. If anything goes wrong it's super easy to get it fixed through PayPal.

Stripe doesn't cut it because it's on the merchant's site, so I have no way to tell if it's actually stripe or if they're pretending to be stripe.

A lot of small tech-related web shops do take Bitcoin though- so if I think I can trust them (and if Bitcoin is an option) I will use that instead.

> A lot of small tech-related web shops do take Bitcoin though- so if I think I can trust them (and if Bitcoin is an option) I will use that instead.

So you will replace a payment method that has a method for recourse when you get fucked with one that is completely irreversible? That doesn't make any sense at all.

Even if Paypal or your CC isn't perfect, at least you have some form of recourse. With bitcoin, when you get fucked over, you are completely shit out of luck.

that's not praising paypal (or btc:), just picking the lesser of two evils

Can you explain your response to his comment. He was just making a statement of preference, and nothing to do with praising anybody.

It's just better off not to make the type of comments you made, tying to weave your personal preferences into some else's statement of preference by interjecting some form of relativity of "evilness".

The reason I use PayPal is when I use my credit card on small websites I get fraudulent charges and have to get the card replaced. This had happened at least 10-15 times since I've been buying stuff online and it's a huge hassle. Small website security is absolutely pathetic.

I’ve used my American Express card almost exclusively online (a lot) since the late ‘90s and have never had to replace it. On the other hand, I only use my Visa for offline charges and have to replace it every six months or so.

1. Use privacy.com.

2. Tie it to whatever payment method you like.

3. Generate one-time use or vendor-locked virtual credit cards, each with their own restrictions for how much can be charged, cancelled at any time, etc....

4. Sleep easy.

Paypal represents 21% of e-commerce transactions in the UK and 40% in Austria, similarly popular in many other European countries where debit/credit is widely accessible. I wouldn't call that niche.

[0]https://ecommercenews.eu/ecommerce-per-country/ecommerce-the... [1]https://www.statista.com/statistics/434121/online-shops-popu...

Sorry, I wasn’t trying to say that the only people who use PayPal fall into those categories - in fact, I don’t, but use PayPal semi-regularly for some purchases - just that there are some PayPal users who can’t use common alternatives.

I'm a sucker for PayPal.

Most of the time it's 2-3 clicks when I want to buy something off of a random website, worst case is I have to login again.

Compare that to reaching out for your credit card and putting in your info. Plus you'd have to trust them now with your CC data.

Exactly this. I just don't want to get up, find my wallet, enter the card number, choose the expiration date from a select, enter the CVV, hit submit, and after all this there is a chance it's not going to work, who knows why, I don't even care. I don't like paypal, but it's really convenient.

Is your browser so out of date or you dont like storing your cc info? As much as i remember few years ago chrome asked me already if i want to save the cc card i entered into the form for future use.

It still won't store the cvc, and plenty of sites do weird idiosyncratic labels on their forms that break the autocomplete.

I use my credit card online so often that I have the card number, expiration date, and CVC memorized.

With Chrome autocomplete it's even faster to put in my own CC.

Same here, plus a consistent and searchable email record.

>Plus you'd have to trust them now with your CC data.

This is a failure of the CC provider, not that the customer cares. If you use something like 3D secure, you don't have to worry about the merchant misusing your data.

Don't underestimate laziness; I've given up on buying stuff just to avoid getting up from the couch or bed to get my phone :D

It also made purchases with the company CC annoying - couldn't buy anything when the boss was in a meeting.

Last time I read about it, using 3D Secure changed your liability agreement with the credit card provider. Not to mention that its implementation is a confusing mess that bounces you between badly designed websites with questionable security.

I run a small SaaS (aimed at businesses and professional freelancers) application which originally only had GitHub and Facebook authentication. I'm now only giving the option of email for new users, and will eventually remove GitHub and Facebook for all users. For my target demographic third-party authentication was really the wrong choice, but I can see how in some cases it could be useful.

Many other parts of the signup flow changed at the same time, so it's hard to measure the impact, but from my side it's much better having an email - I can find out what account someone has when they email me for support, and I can send them account notifications and marketing emails.

In one case I had a company email me, as they had forgot how to access their account. The user who emailed didn't have an account in the system, so I had to ask them to forward an email they were receiving from the application, and eventually found they had signed up with an old GitHub account for the company, that was no longer used (after this I added the account name to all emails I sent).

I'm also currently evaluating the best way to add PayPal as a lot of my traffic is from countries where credit cards aren't so popular. I currently use Stripe, but am trying to find a service to outsource all billing, to avoid having multiple payment provider implementations. I can see how customers could feel uneasy giving their credit card details to a random website, where as with PayPal you don't have that risk.

> after this I added the account name to all emails I sent

Good takeaway: If you're using $randomThirdPartyAuthentication, then you should make it clear to the user how he's actually authenticated with you (in emails, but also the website, if sessions are long-lived).

A few years ago I accumulated a few stackexchange accounts because it wasn't quite clear what SSO was used, so I ended up with one account for each...

While I have been once on the receiving end of PayPal's wrath, I can see why people prefer it, especially with it's strong buyer protection program.

The very first site which I encountered with Stripe, about 3-4 years ago, dint get my money. It just looked odd design for a gateway, I was expecting a "seal" etc on the page with a proclamation about 128-bit encryption and what not. I emailed the website owner to include a "traditional" gateway or PayPal.

Since then I have paid with Stripe on some sites but I can also see why people feel uncomfortable with it.

Personally I wouldn't even think (but specifically it doesn't matter as I don't make/edit videos anyway) of using Google or Facebook access for anything.

BUT yes, I would rather prefer to have the Paypal option (again not relevant here) as it is faster/easier than having to input the credit card data and - as I see it - more secure than providing those numbers to a "stranger on the internet".

The credit card I have on Paypal is anyway a "rechargeable one" and has more or less at the most US$ 200 credit at any time.

And this - conversely - makes any kind of subscription or recurring payment a no-no for me.

If I want something, and it is reasonably priced, I buy it, and that's it, everything similar to Saas with monthly fees or similar I try to avoid.

I thought I was the exception, being older and grumpier than the average, but from the article it seems like I am not alone.

The insight about PayPal and the replies on this thread backing that insight up are so helpful to know. Definitely going to try using PayPal on any future paid projects I make.

Yeah it’s kind of like entering a weird world where everyone’s going to start mentioning they still like their trusty old Blackberry. I had no idea. Although, I’m in b2b so that may be that’s why I was caught unaware about the PayPal love. It seems the main use case is for small amounts on less well known b2c sites, at least in this thread.

This is Julia, the OC. I'm glad it was helpful! I've noticed that international (outside of the US) users especially tend to look for Paypal or alternatives to CC. Something to keep in mind.

Personally I prefer to use PayPal for small sites where offered. Yes there are some PayPal horror stories but I'm generally happy for PayPal to have my credit card details (almost every horror story I've heard has been for sellers not from people using it to pay). Saves me the bother of trying to decide if I actually want to trust a site I've only just encountered with them.

I also don't like linking sites to either my google or facebook accounts. If they don't offer email sign-up I'm almost certainly going to go elsewhere unless I really want to use that particular website.

roughly 70% of my ecommerce business comes via paypal, we give an option for paypal checkout or credit card at checkout. Average order is about 50 USD, demographics are females from 20-50, mostly in the UK

Have u made contingencies for one of these PayPal acount blocking disasters ?!

How often do u transfer the money out of the PP ?

Our business is very legit and customer service is top notch, so it's extremely unlikely, and we are going through shopify as well. Contingency is that we switch to shopify payments and credit cards only and measure topline impact (likely minimal). Rarely leave more than 1k in paypal at a time, we always try to get funds into our real bank.

> I've read too many PayPal horror stories to trust them, but apparently users like it.

Aren't the PayPal horror stories from the vendors not the customers?

Re: PayPal, the problem is that it is a nightmare for merchants but convenient for many consumers. On the merchant side, it’s only a matter of time before the account gets frozen (at least temporarily) and funds held for up to six months. It’s just what they do, seemingly regardless of chargeback rates or other risk indicators.

One other problem with offering PayPal as an option for a technical product/service isn’t as obvious, but is just as important. In my experience, the kind of skeptical user that insists on using PayPal because they don’t trust a given site with their credit card information tends to be more trouble than they are worth. They tend to require far higher levels of customer support than average, and will often eventually request a refund anyway because they have unrealistic expectations of either the product or its support. Also, many PayPal users abuse the deference that company pays to consumers when the consumer initiates even the most absurd dispute, and use the service with an eye toward disputing the charge from the outset.

In short, for a technical product/service, those that would insist on PayPal are the PIA (pain in the ass) type customers you should avoid at all costs anyway. If someone emails you asking why you don’t accept PayPal, remind them that all major credit/debit card issuers offer generous $0 fraud liability programs and move on with your life. Don’t go down the PayPal rabbit hole, as you will be sure to regret it in one way or another.

Happy paypal user here; don't like handing out credit card info and never contacted customer support or requested a refund of companies I dealt with. Don't give in to stereotypes so easily and do not call part of your customer base a pia just because they want support for an exceedingly common payment service.

I am referring not just to PayPal users, but those that would refuse to pay a given site for a service they need unless they offer PayPal. The combination of being a “difficult” customer along with the risks of using PayPal in general simply make it not worth it to allow those people to become customers. You may be an exception to the rule, but overall it’s simply a losing proposition for the merchant.

The world is maybe bigger and more diverse, than the bubble you know.

Here in germany for example, much more people have PayPal, than a credit card.

So what should those people do, if they want to use your service? Getting a CC, just for you? Then your service must be really good. I am also only now finally getting one, but because of flights, otherwise I never needed one.

Wow, that's very true!


Only 32% of Germans even own a credit card. The average German uses on only 39 times a year (I use mine that many times a month or more).

I guess it is because we have a different system, called EC Card. (or does the US also have it?) So we also pay with card mostly, just use a different system.

In the US they are called Debit cards, so yeah, we have something similar. But our debit cards are usually part of either the Visa or MasterCard networks, so they act pretty similar (different fee structures sometimes) as far as merchants are concerned.

You may not have a credit card, but I'm willing to bet you have debit cards that can be used in lieu of PayPal.

Germany has debit cards, but the German debit card system is entirely incompatible with the VISA/MasterCard system.

MC debit cards are pretty common even in Germany (and are everywhere elsewhere in EU). Source: no PayPal/card ratio difference among my German customers compared to the rest of EU.

These are my German debit cards:


The left one is a Maestro, the right one is a Visa Plus.

Neither of these cards has a number that works for online payment. The left one only has my IBAN on it, the right one only the BLZ and Kontonummer.

My bank requires me to pay 60€/year just to get a debit or credit card that works with online payment. There is only one bank offering these for free for students, and only 2 banks offering these for free for normal people.

Everyone else has to pay extra just to get a debit card that works with your online payment.

So either you've got very unusual customers, you're missing a major part of the German market, or you're counting wrong.

Re. frozen funds. As a merchant it is important to sweep the account regularly (daily/weekly) and avoid building up large balances.

Yeah, but the problem is that once they freeze an account, one of two things happens:

1) They only suspend withdrawals, which means payments continue to go in and all of that money is also held unless and until PayPal releases it.


2) They suspend both incoming payments and withdrawals. In this case, you’re back at square one, plus you’ve wasted the PayPal implementation time, plus they are withholding whatever funds you had when they arbitrarily decided to suspend the account. If your customers have recurring payments setup when this happens (as is the case with most SaaS companies), you’ve lost all of those customers, likely for good, because you have to contact them, explain that your PayPal account was shutdown, and then try to get them to give you a credit card directly.

Further, until you realize that they have suspended incoming payments and disable PayPal on your site, customers trying to pay you receive an error message from PayPal, and you’ve likely lost each and every one of those customers for good as well - regardless of the payment methods you offer.

So again, PayPal and many of its customers are nightmares.

You do realize that this can happen with any merchant gateway, don't you?

PayPal has a worse track record than most widely known alternatives. And at least in the US, they're less regulated than the banks from which one typically obtains merchant accounts. These two facts together are a bad combo.

I believe they are regulated as a bank in the EU. That said, their EU head office is in Luxembourg, which along with Ireland is one of the most pro-corporate locations they could have chosen and one of the least likely to take a pro-consumer stance where EU law allows them discretion.

As a general rule, I subscribe to the theory that businesses should make it as easy as possible for people to give them money!

Most of my business is billed through online invoices: PayPal makes it trivial for me to email an invoice to someone and have it paid by their credit card. So trivial in fact, that every time I've looked into switching, I've found no reason to.

Also, I'm finding that more and more customers are in locations where PayPal is more accessible than credit cards.

YMMV but in the 10 years or so that I've been taking PayPal, I can't think of a single bad thing to say about it.

It might be $0, but it's not free; it costs time to regularly check your extract and pore over every line. Frankly, I own a CC, yet I won't give it on any random site. Thankfully my bank also provides free virtual CCs with fixed limits, but otherwise, it's Paypal or I'll bail out.

As a user Paypal is much more convenient than entering credit card info. With Paypal One Touch it's usually as little as 2 clicks (one to say pay with Paypal, one to approve).

I always prefer to use PayPal when it's offered.

Last two insights alone make this a worthwhile read:

> 8. Customers are bad at telling you how much they would pay

> 9. People will pay for things you wouldn’t pay for: When we started charging $10/month for our video meme maker (the first Kapwing tool), some people on Product Hunt and Hacker News told us we were crazy.

9 seems mind-blowing to us all at first. When you unpack it a bit more, you realize that there are literally tens of thousands of different kinds of business selling so many different kinds of products and services. Ask yourself, how many of those tens of thousands of businesses are/would you be a customer of? Your immediate answer is that you're only ever going to be a customer of a very, very small percentage. Then you ask yourself why are all the others still in business, then? And it is because of this reason. There are so many different kinds of needs and wants people have that are unlike your own and therefore, what you might not pay for, many others very well might (and do).

> I knew that people’s credit cards failed and changed, but from my own anecdotal experience I considered this a rare edge case. Wrong.

This is one of the biggest surprises when you build SaaS. Delinquent customers average 25% of churn rates.

Banks must be rolling in lost/new card fees.

I'm a monthly subscriber to my local NPR station and I've had this happen twice when my card reached its expiration date. I got mailed a new card but the online subscriptions didn't automatically roll over (or some did? I don't know how this works. In any event, this subscription definitely didn't roll over.)

The first time it happened, I didn't notice for 3 years. Ended up costing the station (um, $5 * 36...) an absolute fortune. Still, I'm sure I'm not the only one whose donations have slipped through the cracks. And to renew, I basically had to sign up again as a new subscriber.

So anyway, I'm not surprised to hear this is a major factor for online payment processing. I'm just surprised it isn't something that can be handled more seamlessly on the consumer side.

And if anyone associated with KCRW is on this board: this is something you should look into fixing. Maybe it's not costing you millions of dollars, but I imagine it would pay back the dev team's cost to fix it relatively quickly.

> Banks must be rolling in lost/new card fees.

It's not like that at all. There are tons of exceptions that can occur when charging a card. Yes, cards get lost but more often than that, cards will get canceled or closed for various reason. Also, there many people who actually max their credit limits out regularly and therefore a credit limit is hit and the card can no longer be charged any further. Card accounts can be temporarily locked down due to fraud or irregular account activity. Charges can be blocked due to certain characteristics of the charge or the merchant. And yes, of course people do lose cards and get ones, with new numbers, etc. Cards also regularly expire, too, and the expiration number will change even if the card number does not and they must match in order to charge the card.

I get it, and agree with everything you said.

My comment was mostly in jest.

If you're in the UK / Europe, using Direct Debit is a big win here - bank accounts don't expire. Something to optimise once you're big, rather than as a startup, though.

We had a very different experience.

First of all, we had lots of issues with Direct Debit. And it takes a good few days (1-2 weeks) until things authorize. In the meanwhile, you have to provide free service in the hopes that it does.

Second, we had a potential gap with the equivalent of chargebacks. A customer could contact us for a refund, and we issued it. Then their bank (or them?) blocked the payment, which results in another refund + chargeback fees. So we can actually lose money...

Third, and take this with a grain of salt, because it could be specific to our audience, but we actually A/B tested it, and with/without Direct Debit option, our revenue was more or less the same. Some complained, but lots accepted using Paypal / CC.

We're still relatively small, so perhaps your comment applies and we're simply not big enough, but I'm really unsure how much of a big win this is. YMMV.

For European customers, you can make quick friends by offering payment via invoice and wire transfer. E v er y company is equipped to handle that efficiently; if you only offer credit cards, someone needs to get up and find "that guy with the company credit card for AWS".

Gocardless has an API to make direct debit fairly easy for most of europe.

It's only really good for subscriptions rather than one off payments though. Not knowing if the payment was successful for 5 days is probably the biggest downside. Very low fees and low churn is the upside.

If you're talking about B2B it's not just subscriptions - any continuous relationship can be a good fit for direct debits. For example many breweries in Ireland will sign up their clients (i.e. pubs and off-licenses) via direct debit. Then if they make a delivery the payment collection will be automated at the end of the month.

In this situation direct debit gives the vendor the comfort of delivering goods without payment, and it gives the customer the flexibility of ordering without having to go through a purchasing process.

Bank accounts don't, but debit cards do have an expiry date, same as credit cards.

Direct debit is a debit direct from your bank account, using your non-expiring account number.

Different from a debit card which is a debit from an expiring card.

I don't think Direct Debit is a thing in the US.

The nearest equivalent in the US is ACH - https://en.wikipedia.org/wiki/Automated_Clearing_House

I pay several persistent monthly bills using the equivalent of direct debit in the US, which is ACH. My electricity, natural gas, and auto insurance bills all pull out of my checking account via that. It's pretty common.

Cunningham's Law in action. Thank you.

Interestingly, banks offer a way for merchants/payment processors to roll subscriptions onto new cards issued to replace a fraud-affected card. Stripe apparently has this feature; my card was recently compromised, and I updated my subscriptions for most services, but not for my own account with my startup (which I used just for testing to make sure payments went through appropriately).

I was shocked to see a monthly payment hit on my new card, and I called the credit card company to find out how this was possible. They said that big merchants/processors have an agreement with them to automatically get the new numbers for subscribed customers. Also, Stripe recently made it very easy to have the system automatically email customers whose cards were declined. I turned this on for our account and have seen much better retention. I am not a huge fan of Stripe in general—mainly due to issues with their process for handling challenged transactions—but they do make it easier to retain customers.

Your bank charges you a fee for lost/stolen cards?

There is usually a fee to receive a new card

And here I am, month 4, still coding away and waiting for perfection before I launch.

Launch! If your experience is anything like mine with Dependabot, optimising for a big launch is a terrible idea - we spent days fretting about how our infrastructure would handle the load, only to get zero pickup. Lots of sales and hustle since then have got us to ramen profitability, but the time we spent building up to the launch was worse than a waste of time - it made us way too emotionally invested in an event that was basically pot luck.

Thanks for your story and advice.

Perfect is subjective. You can't tell what your customers think is the perfect product for them if they don't see it, and unless what you think is perfect aligns exactly with what your customers want you won't get any customers, and then you're dead.

This is exactly what killed my first startup.

You probably seen it many times, but it's worth repeating as mantra :)


Are you on Indiehackers? It's a whole community of people who'll tell you that you need to launch now - and how, and why.

I just joined indiehackers a few days ago but haven't really participated. But man, i think get the message lol.

What are you building?

Here: https://www.ottomon.net

It's coming out soon...

Also some feedback from me:

1)It tells me what it does and how it works. But what I want to know in the first place is why. Why would I need it?

2)https://imgur.com/a/kuZC3 here I would switch the order from left down and then right down, because the smart phone in the middle spaces this like a book, so I initially read the left side first, then the right side (1/3/2/4). Only then I realised the actual order.

3)Also I do not really understand its purpose.

PS: I am also unfortunately not in your target audience, but wish you the best luck!

Thank you for your valuable feedback.

I think the description above the fold should be more detailed about the purpose than just making things "smart".

I also doubt that whoever randomly comes across a tagged object will want to install your app to contact the owner, so I hope you're making sure that the QR code points to a website that can be used without the app.

But I'm not a potential customer, so if you have actual user studies then ignore what I said.

Thank you for your feedback. I'll try to clarify that description. It works fully on mobile browser. The app is an addition, since it allows to use the phone's flashlight in the dark.

Also any qr code reader will work as well.

I like it! Just chiming in to say that, to oppose all the nay-sayers you'll always get on HN. I think I heard a similar concept pitched on a Startup Weekend once. The problem then was to make it so easy to use (seems you're on the right path there), maybe even without having to scan the QR code (add a 'Get in touch with my owner right now: ottomon.net/3az4xy' under the QR code, or something).

And to repeat what the other commenter said, why wouldn't you just print your phone number or email on there? Privacy is the biggest (only?) reason, I guess. Maybe you should focus more on that on your landing page. You want people to contact you if you parked someone in, but you don't want them to know your name and show up at your house at weird times just because they wanted to be friends with 'that guy with the expensive car'. People are weird.

How will you make it profitable, though? Only obvious thing I'd pay for is to get a nice pack of customized stickers/iron-on-patches/etc in various sizes.

Thank you for the encouraging feedback. Yes, privacy is one of the reasons. And you got it, the high quality stickers and pre printed accessories is what i intend to sell.

Looks interesting.

One small piece of advice. Get rid of the three small steps selling point. From a developer perspective, you think you're explaining that the concept is simple and easy to use. From the end user stand point, they go: ugh, multiple steps. The end user's brain begins to shut down and moves into rejection mode right then and there. Steps = hassle, memorization, fear of screwing a step up, complication. It doesn't matter how many steps.

So in the three simple steps section:

Header: How Ottomon Works [have that be the bold text]

Drop the three simple steps part.

Under the header, turn it into two actions, even if in your mind it's really three steps. It's:

Place QR Code <-> Scan QR Code

If you need to include text about communicating with the owner of the code, put it in the last segment about scanning the QR code.

It's not: step 1, step 2, step 3, step blah.

It's: place codes, scan codes.

Thank you, that's a very good point. I'll update. Stick it, scan it!

First -- ship it! Go live now. You'll learn more.

Second -- 1. Decide what a conversion is (is it an app download? somebody ordering stickers? etc) 2. A/B test the hell out of that landing page with #1 in mind. Everything is fair game -- the car graphic, the layout, the text, etc.

Third -- measure everything. How many times are these codes scanned? How many codes get registered? How many are purchased and of those, how many get used? Do people who scan the codes go on to become active users themselves?

The more data you collect, the more you'll learn, and the better you'll get.

Thanks for the advice. I think it definitely makes sense. The best thing i did for this tool is to randomly talk about at 3 am. I'll ship it now.

It looks interesting. But why would I use this rather than, say, a QR code with my email or phone number on it?

The code on this website is invalid when I scan it - https://blog.ottomon.net/blog/what-is-ottomon - make your demos work :-)

Thank you for the feedback. The intention is that you don't have to show personal information. Also, anyone can add custom information to display when the code is scanned. So email and number can be that information.

Looks interesting, I think this could be useful in cheap inventory management. Have you validated the idea with somebody ready to pay you actually? I think you need some pitch stories to explain use cases better. I needed a minute with "About us" and here on HN comments to figure out what you offer.

Thanks. I'm currently pitching it in my neighborhood where people are constantly complaining about cars.

Yeah, I'll have to rework my top description to make it clearer.

Congrats, you just launched :)

Haha, it looks like. Though I haven't opened registration, i should have.

Why do users get the option to skip payment and remove the watermark for free? Stop doing that.

It may not be that bad of an idea if right now she really wants to show e^x growth (for investors) while still getting something tangible (quality feedback and community engagement).

It may not work for all ventures, but it may work for some.

Having this option makes me think that maybe the author is having a tough time being a capitalist. I've come across quite a few people who are uncomfortable making a profit off of someone else and instead provide the option to give things away so they don't "feel bad".

I think your pricing model, which includes a per use fee, a monthly fee, and an annual fee, is ideal.

I personally find the premise of recurring payments insulting when I want to try something or know I will only use it a few times. There are so many things that I have not tried, just because I don't want to have to go through the trouble to cancel it after I've tried it.

So I think your decision to allow me to pay a buck every time I use your service is very respectful of me and my finances!

If that's a screenshot of your actual pricing page, you should not highlight the $2 per video option in green, it makes it more likely people will choose it.

I don't even understand why have a $2 per video option, it doesn't seem to be great value to you after credit card processing fees and you say 75% of people skip the paywall through the "I can't pay" link.

Also if your demographic for monthly/annual payment is creators and social media marketers, you should focus your marketing site on the tools they might be interested in. It seems to be your meme maker might have been great for exposure but it probably doesn't pay the bills? I'd highlight the other tools.

Maybe think about offering integration with third party software that your paying users are likely to be using as well, as a feature only for the annual plans, or even as an entirely new plan so keep the current monthly/annual as a "Creators" plan (give the option to choose payment frequency and default to annual) and add a new plan at a higher cost (also with monthly/annual choices) with extra features for people who are putting it on the company card.

Just my 2c, might be completely off the mark because I don't know enough about your numbers from a blog article, but these are things I've done with my clients that have worked out.

I would personally never pay $10/month for Kapwing, but I’m also not a social media marketer and creator that needs the service.

Scratch your itch and all that.

Personal itch scratching is one strategy but scratching other people's itches is rather a good one too.

Great insights, thanks for the article. It inspires how you can grow incrementally with a relatively simple product. Could you share your tech stack?

Hey, we're using a basic MERN stack (MongoDB, Express, React, Node) and using FFMPEG on the back end

key point:

"Customers are bad at telling you how much they would pay"

been there, done it. Got users telling me they'd pay $100/year for the thing, only to launch the thing and have them waffle about features.

The only way of testing if customers will pay for something is to ask for the money.

Preferably before you build it.

As in get them to pay before they can get the product?

Seems like they'll then blame you for not making the product you said you'd make, if they pay for a product that's made they can't reasonably make that objection (but could argue misselling I suppose).

When you don't charge, users who say "I would buy that" are not actually saying yes to your marketing pitch. They're usually saying "hmm, seems interesting"

When you say "preorder now!" the users who pay you money have most definitely said yes.

Some will be disappinted, yes. But, if you actually have a product, some people will still be disappointed and want a refund. This is inevitable.

What asking for a preorder does is it filters down to people actually interested in paying money for your pitch.

no, the pattern is to ask them to pay, but not actually make them pay before it's built. If they're willing to click the buy button with the price clear, you've learned something valuable about the price/value you're presenting, and you can learn that before you spend the money building the product.

To be honest, I've never been 100% comfortable with this pattern - it seems deceitful at the surface. I'd prefer an alternative that makes it clearer the product isn't available yet, but allows you to capture that same information. But I think once you do that, lots of people that might be happy with the price simply won't bother letting you know they'd be willing to pay - they just go somewhere else.


Sibling comment talks about a 'pre-order' button, which is close to what I meant by the second option. I think you learn something really valuable with that approach, but I'm not sure it's the exact same thing you'd learn if the user thought it was available now. IDK, maybe it's _more_ valuable...

Depends on what the product is. Can you do some or all of it manually? Obviously not for a todo app on a phone (for example), so it doesn't apply in every situation.

But for some solutions you may be able to test the market via manual processes or a Zapier rube goldberg machine before spending engineering time.

It's about validation, not revenue. You can always refund them.

If anyone happens to like Python and wants to bypass a bunch of the challenges with accepting payments I do have a ~10 hour video course on building a SAAS app with Flask. The source code in that course has been used in production for years and is well tested / polished.

Details can be found at https://buildasaasappwithflask.com/

The course covers a lot of real world features but one thing we do is set up Stripe for both recurring subscriptions (multiple plans) and one off payments (microtransactions for the game we develop which is protected by the paywall). Everything you would expect such as changing subscriptions, billing history, etc. is included.

Lots of people have taken the course and then went on to build their own SAAS apps using the course's app as a base app for their project.

What are some of the SAAS apps that they have built?

User's feedback mentions some payment service PayPay in Europe. It's mispelled PayPal, or some European specific service of which I've never heard of?

Thanks for this article. I'm looking at adding payments to a small project I've been making so this is really helpful stuff to think about.

Congrats on Kapwing, and on some really great blog posts! 300% month-on-month is totally insane - fingers crossed things keeping going so well for you.

Unrelated to the main post, a website where you edit video is total SaaSS (see https://www.gnu.org/philosophy/who-does-that-server-really-s... ) — it shouldn't be a thing, people should run such software locally

It's ok. Little hacker news advertisement should help, right?

You do understand this is a forum run by a VC?

Probably not the place to hang out if you’re as deeply affected by plugs as your comment history suggests.

Advertisement or no, as a person who is still planning the payment model, this was quite useful.

Advertisement jes, but not in the form of traditional advertisement they have at best a 1% watch to pay rate so advertising by having people spread it in social media is way more money effective

If anybody is interested I'm making a new currency called the Points on the internet, so literally making money on the internet, it's called https://pointsproject.org

(A) I will almost never use a real facebook or google account on a small site like this since I will normally expect to be spammed to no end. So normally for signup I use some disposable gmail account

(B) I certainly prefer Paypal. First I never heard of Stripe before and I assume that the site will either: (a) try to store my CC info, will get hacked and I will have to deal with fraudulent charges or (b) keep trying to charge me after I completely forgot about this service and no longer need it.

(C) If I use a credit card on a site like this it will be a virtual account number with a single charge limit. This probably explains credit card charge failures

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact