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.
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 ([email protected]) 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.
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.
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.
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.
"
"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.
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.