Pay Pad for Stripe | Hacker News Reader

Pay Pad for Stripe

pay-pad.com

68 pointsjamesjyu31 comments

Stripe gets a lot of love here on HN, and it's almost universally praised as having no faults and being better than Paypal in every single way. And yet I never see anyone discuss the experience for users. I actually really like the ability to use Paypal on a site to pay without entering my credit card information to yet another source of potential hacking. If a site that allowed Paypal payments moved to Stripe, I would actually find that frustrating and inconvenient. Developers seem quick to praise Stripe as perfect because it does seem to be close to that in the facet they deal with (on the development and merchant end); I understand that developers save a ton more time by switching to Stripe than users lose by having to enter their payment information, but your users really shouldn't have to be concerned with that detail. That being said, I do really like Stripe, but I worry that they'll grow complacent and never expand into the user-facing features because the huge success they've had in other aspects means no one is really pushing them to grow into those areas.

It might be convenient, but patio11's anecdata suggests using Stripe can dramatically outperform Paypal or Google Checkout: http://www.kalzumeus.com/2012/08/06/stripe-and-ab-testing-ma... (of course this will vary depending on the site)

I wonder if people are often scared of Paypal, even after it's become so entrenched in online payments. I would think the process for the average user (regardless of payment system used) is:

1. Do I want to purchase from this website 2. Do I trust this website to provide my payment info to it

If they use Stripe, there is no real "signal" that it is Stripe, the user thinks it is part of the website, the website they have already decided to trust. If a user answers yes to 1 and 2 with Stripe then they will purchase. With Paypal there is another step:

3. Do I trust Paypal to provide my payment info to it?

The user first has to trust the website and then trust Paypal, whereas with Stripe they only have to trust the website (because they don't know what Stripe is, and as long as they remain on the website they assume it's the same thing). So there is an extra step that the user can be turned off at, even if only 1 in 10 people answer yes to 1 and 2 but then no to 3 it can be significant.

Might be a crazy theory... but it seems plausible. Although at the same time quite a lot of people (my parents for example) trust Paypal and any website that uses Paypal, so it could be the case that the value of the Paypal brand negates the customer loss of people that have never heard of Paypal and decide they don't trust it.

I trust Paypal more than most websites. They take steps like using SSL site-wide (with HSTS) and X-Frame-Options, for example, which a lot of e-commerce websites don't. Of course, this is negated if the user doesn't trust Paypal, or doesn't understand what it does.

Website owners probably dislike the loss in branding when using Paypal, which makes them look less professional.

The best option might be have a branded checkout using Stripe, and an option to pay with PayPal for those who maintain PayPal accounts.

Not a bad idea. As a site owner, I prefer to have my checkout branded as my site. I'm not a fan of the paypal experience. It feels cheap. However I certainly understand that people prefer paypal over stripe or other payment systems. To say "use our checkout system, or pay with paypal" would be fine if the site owner wants to support it.

I've had a lot of people ask about integrating other payment platforms into Pay Pad. I'd love to build Pay Pad in a way that was platform agnostic. Just choose your payment provider/gateway and you're off.

We'll see what happens. If enough people want it, I'll do it I'm sure.

We launched with both Paypal and Stripe. Over about 70,000 transactions it has been an almost exact 50/50 split between the two payment methods.

I can't say for sure how many people would not have paid only given one of those options, but I'm sure it's a non trivial number.

Stripe and Paypal are 2 different payment options. It's not either / or - you can have both available for your users. Paypal users can chose Paypal, while the rest can enter use their credit-card without leaving your site - which is huge plus, considering Paypal's relatively high friction process for credit-card payments.

I dont consider stripe to be a paypal replacement. I consider it more of an authorize.net replacement. If I were to start using stripe we would probably still offer PayPal and CC through stripe.

Good point. Many here love to hate PayPal but you know what? It's a better checkout experience when integrated decently. I wouldn't be surprised if Stripe figures out a clever way to act as a "wallet".

WTF, Jesus what is up with all these professional websites with simple Alignment problems?! It's driving me crazy. Pay-Pad's header, body and footer are all different widths and unaligned.

Since so many "Show HN" sites have alignment problems I promise I'll write an article specifically to tackle them. For now just look at the 5th picture here and you'll get it: http://www.chrisnorstrom.com/2011/05/quick-fix-up-redesign-o...

The Pay-Pad logo text is 9px off to the left. Body is 54px wider than the header, making the body very noticeably jut out to the right by 63px. The element with "Developers love Stripe for its super simple API..." is 31 pixels too much to the right. The white-space gutters are so massive they're distracting to the eyes. And of course the worst design fad in 2010+ (other than the "everything is grey" (which I'm guilty of)) is the checkboard image+text layout. It's such a professional looking app (and VERY useful) but the website.. I almost can't take it seriously. I don't mean to hit on just Pay-Pad I've seen a lot of this lately. Little mistakes that shouldn't exist. It's driving me crazy.

You'll definitely want to avoid looking at the site of the developer, then: http://coovtech.com/about

Gotta admit, the guy may lack all design sense, but at least he's shipping software!

Very true. And shipping software is what matters. I've noticed the best programmers almost always lack design sense. They don't think in design, they think in code. While really good designers are code-phobic and see programming as babble. It's hard for them to visualize code.

Thanks for the feedback!

unfortunate domain name. paypad.com seems to be a competitor. probably should do a trademark search before you get too settled on it.

Access to your Stripe account information is cool but I can't imagine anyone filling out their credit card information on your iPad. It sounds awkward and difficult compared to the Square reader.

Integrate with www.card.io?

Until PayPal kills it....

Why would it be any different than the Square iPad app? I've been using that and entering people's credit card information for transactions and no one has had a problem with that. The feedback has been very positive.

Most of my experience with Square has been using the card reader. It feels more seamless

Massively risky. It always is when your proposition is 100% reliant on someone else's with no promises or contracts. What happens if Stripe suddenly say no (a la Padmapper), or they make their own? Just saying.

I didn't get the impression he's trying to make a living off this or anything. I just thought he decided to make something cool based on the Stripe API, and if they make their own, all the better. Whatever happened to making things because they were fun instead of because they had a good value proposition?

I don't think I'd characterize it as "massively risky" - it took him about a month to develop.

If Stripe decided to make their own iPad app, I would be fine with that. It's not going to put me out of business. In fact, I could save them the hassle of having to build their own... :)

Stripe may be a cool idea right now, but it won't survive a better pay-by-phone alternative without external devices.

You need my money? I'll tap an app, enter the amount to send, enter the receiver's id and presto, the transaction shows in the receiver's phone/desktop app as completed.

Somebody will crack it, and he will be the next king of the hill.

* Even though I was confused with 'Square' and their card swiping device, the premise of a mobile payment app still applies to the web. In the future your phone will be your wallet.

I think you're mistaking stripe, which handles online payments, for square, which accepts mobile payments with an external device.

Yep, sorry about that.

How would this be different than https://www.dwolla.com/personal ?

Sounds interesting. How does it work in real life? Can I go to starbucks and buy a latte with my phone? How does starbuck know they got their money? How easy it is for the customer? Type amount, receiver id (numbers only) and send?

Tell me more...

Searching for "paypad" results in a "did you mean paypal?" Of course, searching for "pay pad" works just fine.

I downloaded the free version because I don't need to create or charge customers from the app. A couple of things that would motivate me to pay:

• Graphs

• Payment forecasting for recurring payments ($X expected this week, month, etc.)

• Multiple accounts. Not a big deal, but if I could easily switch between stripe accounts [without re-logging in] I would.

Looks like a nice app though; thanks for putting this out there.

These are all on my short list :)

To do #1 and #2 require a larger backend system. I've been building that system for the last couple weeks...

Stripe allows you to pull 100 records at a time via the API, so what I've done is combined the API with WebHooks. I use the API to fetch historical data, and webhooks to capture anything new. To be clear, this is not part of Pay Pad today, rather it's part of another set of products I've got cooking.

I hope to launch some of these things over the next month.

regarding the multi-account... I started with that. I have 7 Stripe accounts and it was important that I have easy access to all of them. About halfway through the development of Pay Pad, I switched to OAuth and had to take the multi-account support out because the way I was doing it was not a good fit.

I'll add it back at some point. I'm just working on a way to make that process intuitive. I want it to be one or two taps at the most.

Reply on news.ycombinator.com