IOS Developers Reporting In-App Purchasing Outage | Hacker News Reader

IOS Developers Reporting In-App Purchasing Outage

wired.com

34 pointsdsil21 comments

This is headline news for iOS.

For Android, this is literally a daily occurrence.

Heard about it, never experienced it.

As someone involved with products that sell a lot of in-app purchases, I can state that it happens with Android all the time.

I think this mostly affects subscription and re-occurring subscription type in app purchases. Developers often don't bother verifying other types, but it's critical for renewable subscriptions, as that server is how you check if it has been renewed.

Dealing with this for Etude right now. Just giving a free pass and logging extensively so the transactions can be audited later.

What's weird is that this happened immediately after Apple put Etude on the front page of the store yesterday!

I've designed my IAP such that form the moment transaction is paid till the moment it is confirmed it is "tentatively accepted", and the app works as if it was truly accepted. Should the verification later fail, the "tentatively accepted" will turn into "failed" and the related functionality will cease to work later on.

Payment systems outages like this are inevitable, and design a billing system without handling outages gracefully is just inviting trouble.

On a related note, I am open to licensing the tech (both iOS code and the backend server) to anyone who is interested.

Perhaps this is related to http://news.ycombinator.com/item?id=3019783 as an outage to fix the problem system-wide? Cross fingers.

It's probably related to a new hack that intercepts/fakes the in-app purchase calls on jailbroken phones; it allows the user to get "free" in-app purchases, but with invalid receipts.

I'm sure a lot of devs weren't checking receipts and got stung by the hack. So they started verifying receipts, traffic goes through the roof, Apple's servers fail under the load.

Been watching what may be the server side of this hack for the last week or so...it's not very subtle and retries obnoxiously enough to stand out/get itself blacklisted.

It may also be possible that some developers' apps aren't catching duplicates or thresholding these calls and are checking receipts with each hit--that'd put a lot more load on Apple's servers, too (though I'd think the app developers would notice this change in traffic as well on their side?)?

Just use an alternative in-app payment processor for now. Oh wait.

I suspect this will be resolved in far shorter time than it would take to switch your app to a new API and distribute updates to your userbase.

His comment was actually misplaced sarcasm, hence the downvotes.

He is implying you can't use alternative payment methods for an iOS app, which just isn't true. He is probably not an iOS developer, and he just misunderstood the media coverage.

Does Section 11.2 not prohibit the publishing of apps that use in app payment processes other than Apple's IAP? If I'm mistaken, I'd be interested to be told how. You are right, I'm not an iOS developer and I will accept downvotes for the snarky sarcasm, but I believe my core assumption to be true. If not, please forgive my ignorance and point me in the right direction.

There are a number of ways that you can sell app add-ons and subscriptions without using Apple's system. Hundreds, if not thousands of apps, such as Kindle and NetFlix, use alternate methods.

I think you need to check your facts. Amazon's Kindle app and BN's Nook apps were updated to remove in app purchases and completely remove all links to the Kindle web store even from the application [1]. Same with Spotify and Rhapsody [2] and WSJ [3] and Hulu [4] (Okay, that's enough links).

[1] http://9to5mac.com/2011/07/25/amazon-brings-kindle-newspaper...

[2] http://www.the-digital-reader.com/2011/07/25/spotify-rhapsod...

[3] http://www.slashgear.com/kindle-wsj-spotify-ios-apps-more-lo...

[4] http://www.macrumors.com/2011/06/20/hulu-complies-with-apple...

It's a valid point: Neither Google nor Apple allow alternate payment processors. In that case they should be extra careful to make their service have lots of redundancy.

In fact their services (especially Google's) are not nearly so reliable as one would hope. Such is the danger of a monopoly.

Wait, Google forces you to use them for in-app payments as well? The Market obviously uses Google's Google Checkout, but alternatives markets and distribution channels exist for Android. I thought you could still use your own in-app payment system if you chose...

The developer agreement indicates that only authorized payment processors can be used. AFAIK, Google Checkout is the only Authorized Payment Processor.

Good thing for the GOOG, too, because reliability and support is often so bad as to be comical (you'd have to cry if you didn't laugh--there is a reason that this comment is top-voted right now: http://news.ycombinator.com/item?id=3031478). I think a good many developers would jump ship to something else in an instant were it available.

Oh, I know from following `koush` (RomManager, DeskSMS) on Twitter that Google's payment processing is a bit miserable. He's posted more than one screenshot of mass verification failures.

I'm looking at the Dev Agreement and I don't see the parallel verbiage to Apple's "Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected". I can think of a fairly significant list of applications that have unlocks via PayPal or other methods other than Google's in app payment that ties into the Market.

edit: It appears to be in Section 3.3 of the Android Market Developer Distribution Agreement: "All fees received by Developers for Products distributed via the Market must be processed by the Market's Payment Processor." I wonder if they're simply not enforcing it... Lame Google...

Actually, the clause you quote (and the restriction I mention) only applies to free apps.

They certainly DON'T enforce the policy very often. Of course they'd need an army to enforce ALL of their policies. I doubt there are many apps on the market that adhere religiously to all the policies, and most have lots of obvious violations.

Reply on news.ycombinator.com