5 ms·

IOS Developers Reporting In-App Purchasing Outage

34 points by dsil 15y ago

dangrover 15y ago
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!
smokey_the_bear 15y ago
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.
- deleted 15y ago
  [deleted]
  - sehugg 15y ago
    Blocking a sale because the receipt server is down is also not doing it right. If you have a client-only IAP (i.e. no server component) any pirate worth their salt is going to disable it, so you may as well be lenient about validating receipts or cache them to retry later.
shaggyfrog 15y ago
Perhaps this is related to http://news.ycombinator.com/item?id=3019783 http://news.ycombinator.com/item?id=3019783 as an outage to fix the problem system-wide? Cross fingers.
- xsmasher 15y ago
  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 15y ago
    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 15y ago
Just use an alternative in-app payment processor for now. Oh wait.
- tvon 15y ago
  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.
  - andrewljohnson 15y ago
    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.
    - drivebyacct2 15y ago
      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.
      - andrewljohnson 15y ago
        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.
        drivebyacct2 15y ago
        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-newspapers-and-magazines-to-ios-devices/ http://9to5mac.com/2011/07/25/amazon-brings-kindle-newspaper... [2] http://www.the-digital-reader.com/2011/07/25/spotify-rhapsody-have-cut-ties-to-their-ios-apps/ http://www.the-digital-reader.com/2011/07/25/spotify-rhapsod... [3] http://www.slashgear.com/kindle-wsj-spotify-ios-apps-more-lose-store-links-25167338/ http://www.slashgear.com/kindle-wsj-spotify-ios-apps-more-lo... [4] http://www.macrumors.com/2011/06/20/hulu-complies-with-apples-new-ios-in-app-subscription-rules/ http://www.macrumors.com/2011/06/20/hulu-complies-with-apple...
Mizza 15y ago
This is headline news for iOS. For Android, this is literally a daily occurrence.
- TobbenTM 15y ago
  Heard about it, never experienced it.
  - nupark2 15y ago
    As someone involved with products that sell a lot of in-app purchases, I can state that it happens with Android all the time.
DenisM 15y ago
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.

34 points by dsil 15y ago

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!

smokey_the_bear 15y ago

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.

deleted 15y ago
[deleted]
- sehugg 15y ago
  Blocking a sale because the receipt server is down is also not doing it right. If you have a client-only IAP (i.e. no server component) any pirate worth their salt is going to disable it, so you may as well be lenient about validating receipts or cache them to retry later.

shaggyfrog 15y ago

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

xsmasher 15y ago
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 15y ago
  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 15y ago

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

tvon 15y ago
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.
- andrewljohnson 15y ago
  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.
  - drivebyacct2 15y ago
    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.
    - andrewljohnson 15y ago
      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.
      - drivebyacct2 15y ago
        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-newspapers-and-magazines-to-ios-devices/ http://9to5mac.com/2011/07/25/amazon-brings-kindle-newspaper... [2] http://www.the-digital-reader.com/2011/07/25/spotify-rhapsody-have-cut-ties-to-their-ios-apps/ http://www.the-digital-reader.com/2011/07/25/spotify-rhapsod... [3] http://www.slashgear.com/kindle-wsj-spotify-ios-apps-more-lose-store-links-25167338/ http://www.slashgear.com/kindle-wsj-spotify-ios-apps-more-lo... [4] http://www.macrumors.com/2011/06/20/hulu-complies-with-apples-new-ios-in-app-subscription-rules/ http://www.macrumors.com/2011/06/20/hulu-complies-with-apple...

Mizza 15y ago

This is headline news for iOS. For Android, this is literally a daily occurrence.

TobbenTM 15y ago
Heard about it, never experienced it.
- nupark2 15y ago
  As someone involved with products that sell a lot of in-app purchases, I can state that it happens with Android all the time.

DenisM 15y ago

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.