アプリ内購入は問題なく機能しており、サーバー検証ルートを使用します。サーバーは私がサンドボックスにいるかどうかを知る必要があるので、今のところは「&sandbox = 1」パラメーターを送信しているだけです。もちろん、アプリのフルバージョンがリリースされている場合は、このパラメーターを送信しません。
これをアプリにハードコーディングしたくないのは、将来的にテストが困難になるためです。ビルドをAppleに送信する前に、変更することを忘れないでください。
サンドボックスにいるかどうかをStoreKitに問い合わせて、このパラメーターをサーバーに送信する必要があるかどうかを判断する方法はありますか?または、サーバー検証を処理するための他のベストプラクティスはありますか?
これについてもっと考えてみると、サーバーに常に最初にライブシステムをチェックさせ、次にサンドボックスをチェックさせる必要がありますか? Apple IDがライブシステムとサンドボックスシステムの間で分離されている場合、害はありませんか?
ありがとう。
少し掘り下げた後、私はこれをAppleの テクニカルノートTN2259 から見つけました:
領収書を確認するにはどうすればよいですか(iOS)?
必ず最初に本番URLで領収書を確認してください。 21007ステータスコードを受け取った場合は、サンドボックスURLで確認します。このアプローチに従うことで、アプリケーションがサンドボックスでテストまたはレビューされている間、またはAppStoreに住んでいます。
したがって、&sandbox
パラメータを完全にaxして、それを実行する必要があるようです。私は本当にこの答えを掘る必要があったので、誰かがそれに遭遇することを期待してここに投稿します!
同じ問題が発生しました。送信したアプリの「本番」バージョンが、実際の受信を検証するサーバー上のPHPスクリプト)に接続するようにハードコードされていたため、アプリが拒否されました。 AppStoreサーバー(私の開発ビルドは別のPHPサンドボックスサーバーで受信を検証するスクリプトを指します)。ただし、Appleエンジニアと数回交換した後、私はサンドボックス化されたユーザーアカウントを使用して、送信されたアプリケーションをテストしていることがわかりました。これが、エラーが発生した理由を説明しています。
上記で説明したように、いずれかのスクリプトを指すようにアプリを条件付きでビルドする代わりに、最初に本番サーバーを試行し、21007ステータスコードを受信するとサンドボックスサーバーにフォールバックする単一のスクリプトを使用します。
どうもありがとう!
必ず最初に本番URLで領収書を確認してください。 21007ステータスコードを受け取った場合は、サンドボックスURLで確認してください。
残念ながら、テクニカルノートには、これが自動更新サブスクリプションにのみ有効であることが記載されていません。
アプリ内購入プログラミングガイド は、以下の表7-1に記載されています。
重要ここでのゼロ以外のステータスコードは、自動更新可能なサブスクリプションに関する情報を回復する場合にのみ適用されます。他の種類の製品の応答をテストするときは、これらのステータスコードを使用しないでください。
非更新サブスクリプションの場合、本番サーバーはステータスコードを返しませんが、適切なレシートを返します。
非更新を使用して独自のサブスクリプション有効期限ロジックを実装する必要がある場合、考えられる解決策は、アプリのバージョンをサーバーに送信し、現在開発中のバージョンを追跡することです。これにより、リダイレクトできます。必要に応じて、sandbox.iTunesサーバーにアクセスして受信を確認し、サーバーでの開発のためにサブスクリプションのx分の有効期限を模倣します(sandbox.iTunesが自動更新する場合と同様)。