billycoover

I had the same question "What's this even about?" but I decided to read the article and magically my question was answered.

I never heard of this until just now and this is my good friend that wrote the post.

It reminds me of Halo from the show Continuum. The early alpha version before it gets deeply integrated into your physical being.

Fast-forward 10 years and we'll be wearing these things, only they'll be called iBod and it will be a combination iWatch and iGlasses and freakishly integrated in our lives.

Ready Player One!

Congrats on the launch!

It looks great @rscherf. Happy to see some competition for Pay Pad!

I've got 99 problems but too many push notifications telling me I made money, ain't one. :)

I have a couple things in the works that can help reduce the number of push notifications you get. For example, for my account, I'm only getting notifications for charges over $100.

Ping me (billy@pay-pad.com) and do some wizardry behind the scenes for you if filtering on the dollar amount would help you out.

1) No it's not open-source but I do plan on opening up the Stripe lib I've built. 2) Negative. That would be a great option but some Pay Pad users want the full featured access, including accepting payments from the device.

I think about this a lot... For example, from Pay Pay, what would be the ramifications if someone stole your phone and had access to your Stripe account?

Well there are three things that are pretty scary. They could 1) add new charges to your existing customers 2) refund existing customers, and 3) get names and email addresses of your customers.

Could you prevent this? Yes. Password protect your phone. If it does get stolen, go to Stripe and revoke access to the third party apps.

But I want to do better. One user left a review the other day and asked for the ability to "lock" the app. I haven't decided yet how I'll implement it but I do want to add an "optional" locking feature that adds yet another layer of protection to your Stripe account from the Pay Pad app.

Ping me if you have any thoughts on alternatives.

Fixed. Thanks for pointing that out!

Parse is cool, but the pricing is a deal breaker for me. According to their plans page (https://www.parse.com/plans), I'd need a pro account to enable multi-app push. Pay Pad is three apps actually so the combination of UrbanAirship and Webscript.io end up being a very cheap solution if I wanted to ditch my current implementation on Heroku.

Although I suppose you could get around the multi-push-certificate restriction with multiple Parse accounts. If you had two iOS apps, then you'd be making two web requests out to Parse. Although I do this now with UrbanAirship so there would not really be a difference. Interesting.

Thanks for the feedback. The app has since been approved. Blog post updated with details: http://coovtech.com/posts/the-apple-reaper/

I confirmed with Apple this morning that this is not the case. Update the blog post: http://coovtech.com/posts/the-apple-reaper/

Update: Apple reached out to me about this incident. They've approved the app! http://itunes.apple.com/us/app/pay-pad-for-stripe-for-iphone...

I'll update the blog post in the morning with details.

Here's what I wrote in my appeal. I tried to speak in the most simple terms as possible. I hope it works:

" The rejection states that "if the purchasable content, functionality, or services are intended to be used within the app, they must be purchased through IAP, within the app" - This is absolutely not the case. Pay Pad for Stripe allows USERS to accept payments from their customers with their iPhone & iPad. Nothing that the user is accepting payments for would be used within the app.

Pay Pad for Stripe is companion app to the Stripe API (http://www.stripe.com).

I am not selling anything inside of the app. There are no subscriptions inside of the app. There is no exchange of a fee or subscription money between myself and a Pay Pad for Stripe user. They cannot buy any content, products, or services from my while inside the app.

The most straight-forward way I can describe how someone might use Pay Pad for Stripe is this: My wife has a Stripe account which allows her to accept credit card payments. She downloads Pay Pad for Stripe so that she can manage her Stripe account and accept mobile payments. She takes our daughters to the local grocery store to sell girl-scout cookies. A customer of hers want's to buy a box of thin-mints. She uses Pay Pad for Stripe to take a credit card payment from the customer for those thin-min cookies.

That's it. The feature is identical to what you will find in the popular Square and Pay Pal apps. This is not in-app purchasing. This in enabling B2C business transactions. There is no money exchanged between myself and the Pay Pad for Stripe users. "

That's what he's telling me.

Lots fo suggestions for this one :)

"before even attempting to resolve it using the normal methods" - I know I left it wide-open for assumptions like this. I'll update the post with what has transpired since my conversation with him.

The iPhone version is a brand new app. The iPad versions were updates that they approved. He said they will be taking them down.

It sounds like bs, but then when you look at Square and PayPal, it makes sense according to this "rule", I guess.

Why would I create a new application?

re-submitting without the best feature (in my opinion). That's the plan...

Although a lot of good ideas have been coming in about how to get around it.

I built and iOS library for this last night (i'll open-source it soon). I love this idea and for iOS apps that don't have a web backend, this is a great and easy way to implement CRM with your app user info.

We use TestFlight a lot in our iOS apps. TestFlight is great for tracking what your users are doing inside your app, and logging errors. LessNeglect goes a step further and lets you tie users and actions together with an open communication channel.

I'm going to use this specifically to allow users of my iOS apps to send me support requests, and to also track in-app purchases.

In addition to Pay Pad, we also have Alerts for Stripe: http://www.pay-pad.com/alerts

Also, Zapier open-sourced a nice dashboard that uses Stripe Apps: https://board.zapier.com/

Thanks for the feedback!

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.

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... :)

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.

I think the biometrics angle is interesting and will become more prominent in our lives as the tech gets cheaper, smaller, and easier to implement.

But biometrics doesn't pass the grandma test (you know, grandma who doesn't use cell phones, won't do online bill pay, snail mails everything, like mine).

I'm fascinated by all the ways people are trying to reduce the inconvenience of authentication.

Xcode 4 does a nice job of pointing out objects you may have forgotten to wire-up in IB. Prior to that, I struggled with IB. I realize now there is a cadence to it. Declare, synthesize, wire-up, implement delegate methods. Forget a step and your on StackOverflow face-palming.

I tried to get into iOS about 3.5 years ago. I failed miserably. IB was a big part of that...

Trying to get two objects to line-up horizontally with the designer in Eclipse... Well, it makes me want to punch something.

To be fair... The classes were a joke. We wrote the same mortgage payment calc in Java, VB, and SQL. In other words, college programming is a waste of time.

iOS taking twice as long had little to do with Objective-C, although I do find the language frustrating at times. But that's just like any other language I guess. If I had a dollar for every time I cursed at Javascript...