忘れていると、とても痛い目にあう仕様。
AndroidのIn-app BillingのorderIdは、
(アプリのアルファ/ベータ公開)テスト時にはセットされない。
ドキュメントの片隅に、ひっそりと書いてあります。
[Testing In-app Billing]
https://developer.android.com/google/play/billing/billing_testing.html#testing-purchases
Testing In-app Purchasesセクション。
Test purchases can be used in alpha/beta releases only.
Test Purchases (In-app Billing Sandbox)
Test purchases don't have an orderId field
または、In-app Billing Referenceの、
Table 4. Descriptions of the JSON fields for INAPP_PURCHASE_DATA.
を参照。
ですが、この仕様を忘れていた場合、テスト時にorderIdがセットされていないことが発覚するのは、アプリのアルファ/ベータ公開テスト時。
なので、orderIdをチェックするコードが入っている場合は、何らかの対策しておかないといけません。(テスト時はスルーするなど)
・・といっても、「テスト時」かどうか判定できない(テストかどうか判定するフラグは、データに入っていない)ので、実際は、本番用とテスト用のバージョンを分けるしかありません。
言い換えると、orderIdを扱う箇所があるなら、本番にならないとテストできないパスが存在するということ。
テスト段階で、(購入処理の一部ができないなどで)対策が抜けている事に気づいた場合は・・
・対策用のコードを入れたら、他の場所に不具合が出た
(例：orderId以外のチェックなどが原因で、セーブデータが読込めない)
・テスト時のセーブデータを、本番用にそのまま使えない
(例：orderIdが設定されていないデータが混在するので、セーブデータの消去が必要)
・すでに公開していたアプリに、購入機能を追加した場合は・・テスト参加者は、どこまでロールバックするのだろう？
というシナリオもあり得るので、要注意。
そして、(テスト時は)orderIdに紐付くデータを持たせられない。
こちらの方が深刻な問題です。(テスターだけロールバック・・を除けば。)
取引照合用のデータベースなどで、うっかり、注文ID(orderId)をキーにしてしまったなんて事は・・、いや、(仕様上の制限を説明していなければ)普通、するでしょう。当然、Web周りも影響を受けるわけで。
テストをしないで公開する？設計変更して大幅に直す？それとも・・公開を一旦中止する？
そんな選択に迫られないためにも、In-app Billingを使う場合は、(この大迷惑な仕様の事を)忘れないように注意しましょう。