Unexpected challenges of making money on the internet
kapwing.com
kapwing.com
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?
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.
You've clearly never worked in China. All people are not living your circumstance.
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.
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.
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 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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
Generally processors charge $1/card updated, but stripe is pricey enough to include it for everyone.
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.
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.
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.
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.
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.
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.
It also made purchases with the company CC annoying - couldn't buy anything when the boss was in a meeting.
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.
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.
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".
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.
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.
[0]https://ecommercenews.eu/ecommerce-per-country/ecommerce-the... [1]https://www.statista.com/statistics/434121/online-shops-popu...
Aren't the PayPal horror stories from the vendors not the customers?
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.
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.
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.
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.
https://www.usatoday.com/story/news/world/2015/07/16/germans...
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).
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.
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.
Or
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.
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.
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.
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.
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.
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...
How often do u transfer the money out of the PP ?
> 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.
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.
Different from a debit card which is a debit from an expiring card.
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.
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.
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.
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.
My comment was mostly in jest.
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.
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.
It's coming out soon...
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.
Also any qr code reader will work as well.
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!
The code on this website is invalid when I scan it - https://blog.ottomon.net/blog/what-is-ottomon - make your demos work :-)
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.
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.
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.
Yeah, I'll have to rework my top description to make it clearer.
This is exactly what killed my first startup.
It may not work for all ventures, but it may work for some.
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!
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.
Scratch your itch and all that.
"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.
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 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.
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.
[edit]
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...
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.
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.
Probably not the place to hang out if you’re as deeply affected by plugs as your comment history suggests.
(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