

IOS Developers Reporting In-App Purchasing Outage - dsil
http://www.wired.com/gadgetlab/2011/09/ios-in-app-purchasing-outage/

======
Mizza
This is headline news for iOS.

For Android, this is _literally_ a daily occurrence.

~~~
TobbenTM
Heard about it, never experienced it.

~~~
nupark2
As someone involved with products that sell a _lot_ of in-app purchases, I can
state that it happens with Android _all the time_.

------
smokey_the_bear
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.

------
dangrover
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!

------
DenisM
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.

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

~~~
xsmasher
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.

~~~
jen_h
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?)?

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

~~~
tvon
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.

~~~
SomeCallMeTim
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.

~~~
drivebyacct2
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...

~~~
jen_h
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.

~~~
drivebyacct2
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...

~~~
SomeCallMeTim
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.

