メインコンテンツに移動

トランザクションと支払いによる確認のガイド

トランザクションと支払いによる確認が、開発者ハブで完全にドキュメント化されました。

新機能

  • トランザクション。 プロダクトは子どもの購入をk-IDに報告し、k-IDはそれをリンクされた保護者に、Family Connectの子どもごとの購入ビューとして、また定期的なアクティビティのダイジェストとして提示します。請求の前に保護者を介在させたい場合には、購入の承認リクエストが先にその承認を求め、結果はTransaction.PurchaseApprovalResultウェブフックとして届きます。どちらの部分も、Compliance Studioでプロダクトごとに設定します。
  • 支払いによる確認。 完了したカード決済は、保護者の同意ステップの代わりになり、クレジットカード確認方法を1対1で反映します。その方法がセッションに対して有効な場面でまったく同じように尊重され、クレジットカードの資金のみが対象で、それ以外のあらゆる場面では保護者が標準の検証済み保護者同意フローをこれまでどおり完了します。

ドキュメント

検証済み保護者リンク、スクリーンタイム、アクティビティ取り込みのガイド

3つのペアレンタルコントロール機能が、開発者ハブで完全にドキュメント化されました。検証済み保護者リンク、スクリーンタイム、アクティビティの取り込みです。

新機能

  • 検証済み保護者リンク(VPL)。 プレイヤーは自分の保護者をプロダクトに招待できます。保護者が本人確認を完了すると、そのプレイヤーのコントロール(例えばスクリーンタイム)を確認し設定できるようになります。VPLはゲートではなくリンクです。何もブロックされず、保護者が承諾したかどうかにかかわらずプロダクトは動作し続けます。Session.Unlinkウェブフックが、どちらかの側がリンクを解除したことを知らせます。VPLはデベロッパー組織単位で有効化されます。
  • スクリーンタイム。 保護者はFamily Connectで、子どもの1日の制限、静かな時間、休憩リマインダーを設定します。プロダクトは利用状況を報告し、k-IDが返す判定に従います。k-IDはルールを保持し、子どもごと・1日ごとに利用時間を数え、スケジュールを評価します。各制限の前には警告イベントが届くため、プレイヤーは保存できる区切りに到達できます。また、子どもはスクリーンタイムの延長をリクエストして、より多くの時間を求めることができます。
  • アクティビティの取り込み。 プロダクトは、Compliance Studioでプロダクトごとに宣言したアクティビティタイプに対してレコードをプッシュすることで、子どもの行動を報告します。k-IDはそれらのレコードを保存・集計し、Family Connectで信頼できる大人が読む画面(定期的なダイジェストメールを含む)に反映します。アクティビティは受信専用です。

ドキュメント

Version history and rollback in Compliance Studio

Every configuration a product has published is now kept and listed, and an administrator can point Live back at a configuration it served before without waiting on k-ID.

What's new

  • The History tab. A product now has a History tab holding two sections. Activity lists everything that has happened to the product, and any entry that changed the configuration carries a View changes link showing exactly what that one entry changed. Versions lists every configuration published to Live and to Test, newest first, with the one being served marked Current.
  • Rollback. The version Live is serving offers Rollback, which repoints Live at the configuration published before it. It doesn't create a new version, so numbering is unaffected and the version you rolled off stays in the list and can be made current again. A rollback takes effect within minutes, with no review step, so the confirmation shows the full diff of what Live would serve.
  • Reset to published. A working copy with unpublished edits can be reset back to whatever Live or Test is serving, previewed the same way. This is separate from a rollback: a rollback changes what players are served and leaves your working copy alone, a reset does the opposite.
  • Naming a version. Versions can be given a name, so Live v7 can also read as "pre-launch tuning" when someone comes looking a month later.

Documentation

/session/delete の新しいモードで必須プロダクトの依存関係を保護

/session/delete が、削除対象のセッションに依存する他のプロダクトを保護(またはまとめて削除)できるようになりました。

新機能

  • POST /session/deleteessentialDependencies あるプロダクトが他のプロダクトにとって*必須(essential)*として構成されている場合、そのセッションを削除すると、これまでは依存するプロダクトのセッションが、依拠していた同意の基盤を失ったまま静かに残されていました。新しいフィールドを使うと、デフォルトの取り消しと hardDelete の両方のパスで、代わりの動作を選択できます。
  • block は依存プロダクトを孤立させる代わりに削除を拒否します。 プレイヤーが削除対象のプロダクトに依存するアクティブなプロダクトをまだ保持している間、呼び出しは ESSENTIAL_DEPENDENTS_EXIST を返し、依存プロダクトのIDを明示します。有効化は不要です。
  • cascade は依存するセッションも削除し、その後に指定されたセッションを削除します。各セッションには独自のWebhookが送信され、ハード削除の場合は削除記録も個別に作成されます。指定していないセッションを削除するため、開発者ごとのオプトインです(有効化せずに送信すると FEATURE_DISABLED が返されます)。また、クライアントアクセストークンではなくサーバーサイドのAPIキーが必要です。
  • 既存のすべての呼び出しは影響を受けません。 フィールドを省略するか ignore を送信すると、/session/delete は従来どおりの動作を維持し、今後も変わりません。これはデフォルト変更の前段階ではなく、安定したオプトイン機能です。

ドキュメント

Google Play Age Signals v0.0.4 の `ageRangeSource` に対応

k-IDは、Google Play Age Signals v0.0.4 の ageRangeSource の値を、google-play プラットフォーム年齢シグナルの declarationType として受け入れるようになりました。

新機能

  • google-play シグナルの ageRangeSource Google Play Age Signals v0.0.4 では、userStatusageRangeSource に置き換えられました。年齢ゲートおよびセッションのエンドポイントを呼び出す際は、Google Play age signals responsesageRangeSource の値を PlatformAgeSignaldeclarationType として指定してください。
  • 非推奨の userStatus の値も引き続き機能します。 k-IDは、従来のスキーマを使用するストアのために従来の userStatus の値を引き続き受け入れるため、まだ移行していないアプリからのシグナルにも影響はありません。

ドキュメント

メール年齢推定専用の年齢確認エンドポイント

メール年齢推定のみを方式として年齢確認を実行するための専用エンドポイント /age-verification/perform-email-age-estimation が追加されました。これは、既存の単一方式エンドポイント(ID、AgeKey、ConnectID)と並ぶものです。

新機能

  • POST /age-verification/perform-email-age-estimation 自動的な方式選択をバイパスし、メール年齢推定のみでユーザーを確認します。他の単一方式エンドポイントと同じリクエスト形式(jurisdictionsubjectcriteria、および任意の options.redirectUrl / options.locale)を受け取り、idurlshortUrl を返します。subject.email フィールドは任意です。省略した場合、ユーザーはホストされた確認ページでメールアドレスを入力します。
  • 18歳以上のシグナル。 メール年齢推定は、正確な年齢推定ではなく18歳以上のシグナルです。対象者が18歳以上であることのみを確認でき、それより若い年齢帯を区別することはできないため、リクエストの基準をこの能力に合わせることはお客様の責任です。
  • ステータスと結果は変更なし。 これまでどおり /age-verification/get-status をポーリングするか、Verification.Result webhook を処理してください。

ドキュメント

Apple iOSの「confirmed」年齢シグナルに対応

k-IDは、iOS 26.5以降のプレイヤーについて、Appleの confirmed 宣言タイプを確認済みのプラットフォーム年齢シグナルとして受け入れるようになりました。

新機能

  • confirmed は確認済みのApple宣言タイプです。 iOS 26.5以降、AppleのAge Range Serviceは selfDeclaredguardianDeclaredconfirmed のみを返します。confirmed は、クレジットカードや政府発行IDなど、精査された方法で年齢範囲が設定されたことを示します。k-IDは confirmed を確認済みとして扱うため、年齢ゲートの抑制、確認閾値の充足、および ageVerification の記録が可能です。
  • 非推奨のタイプも引き続き機能します。 Appleは paymentCheckedgovernmentIDCheckedguardianPaymentCheckedguardianGovernmentIDChecked を非推奨としました。k-IDは後方互換性のためこれらを引き続き受け入れるため、以前のiOSバージョンからのシグナルにも影響はありません。
  • selfDeclaredguardianDeclared は未確認のままです。 これらは年齢確認の要件をバイパスしません。

ドキュメント

ウィジェットと年齢確認に関するモバイル統合ガイダンス

モバイルでk-IDをどのように統合するのが最適かを明確にするため、ドキュメントを更新しました。年齢ゲートと同意ステップについては、ネイティブに構築したUXがプレイヤーに最もシームレスなエクスペリエンスを提供し、年齢確認URLや年齢保証URLなどのWeb埋め込みはシステムブラウザサーフェスを通じて表示されます。

新機能

年齢ゲートとエンドツーエンドウィジェットに関するモバイルガイダンス

年齢ゲートウィジェットとエンドツーエンドウィジェットは、モバイルで完全にサポートされています。年齢ゲートと同意ステップについては、最もブランドに統合されたエクスペリエンスを実現するために、カスタムワークフローを使用し、CDK UXガイドラインに従ってUXをネイティブに構築することを推奨します。

k-ID APIから返される年齢確認URLと年齢保証URLも同じ方法で表示されます。具体的なエンドポイントとチャレンジタイプについては、モバイルアプリガイドを参照してください。

モバイルアプリガイドの刷新

モバイルアプリガイドは、モバイルで最も一般的なWeb埋め込みである年齢確認を中心に再構成されました:

デフォルトブラウザ方法

モバイル実装方法として、デフォルトの外部ブラウザ方法が新たに文書化されました。これはAndroid(Intent.ACTION_VIEW)とiOS(UIApplication.open)の両方で機能し、AgeKeysを完全にサポートし、redirectUrlコールバックを通じてアプリにフォーカスを戻します。

デバイスの向きに関するガイダンス

年齢確認はポートレート(縦向き)で最も効果的に機能します。アプリ内ブラウザサーフェスはアプリの向きのロックを継承するため、横向きにロックされたアプリでは、確認URLをデフォルトの外部ブラウザで開いてください。ブラウザは独自の向きを管理するため、ユーザーはポートレートに回転でき、フロー完了時にはredirectUrlコールバックがアプリに戻します。

更新されたドキュメント

  • モバイルアプリ: 年齢確認を中心に再構成し、デフォルトブラウザとデバイスの向きのセクションを新設
  • CDK 埋め込みフロー: エンドツーエンドウィジェットと年齢ゲートウィジェットのモバイルでの表示ガイダンスを追加
  • CDK 概要: 統合アプローチの比較にモバイルガイダンスを追加
  • CDK カスタムワークフロー: カスタムワークフローがモバイルアプリに推奨されるアプローチである旨を記載
  • 検証可能な保護者の同意(VPC): このウィジェットベースのガイドのモバイルでの利用に関する注記を追加

次のステップ

  • モバイルで統合する場合は、最もシームレスなエクスペリエンスを実現するために、カスタムワークフローCDK UXガイドラインを使用して、年齢ゲートと同意のUXをネイティブに構築することを検討してください
  • 確認URLを表示する際、横向きロックされたアプリにはデフォルトブラウザ方法を使用してください

Permanently erase a session with a new flag on /session/delete

/session/delete can now permanently erase a session instead of only revoking it.

What's new

  • hardDelete on POST /session/delete. Set to true to permanently delete a player session and its embedded consent, scoped to the calling product. Unlike the default revoke (which is internally retained), this physically removes the record and can't be undone.
  • Opt-in per developer. Available only to developers explicitly enabled for hard delete. Setting hardDelete: true without enablement returns FEATURE_DISABLED.
  • Every existing call is unaffected. Omitting hardDelete, or setting it to false, behaves exactly as /session/delete always has: a reversible revoke.
  • In-flight challenges are failed too. Any pending challenge tied to that exact session is set to FAIL, scoped to that session only (other sessions for the same player are untouched).

Documentation

クレジットカード専用の年齢確認エンドポイント

クレジットカードのみを方式として年齢確認を実行するための専用エンドポイント /age-verification/perform-credit-card-verification が追加されました。これは、既存の単一方式エンドポイント(ID、AgeKey、ConnectID)と並ぶものです。

新機能

  • POST /age-verification/perform-credit-card-verification 自動的な方式選択をバイパスし、クレジットカードのみでユーザーを確認します。他の単一方式エンドポイントと同じリクエスト形式(jurisdictionsubjectcriteria、および任意の options.redirectUrl / options.locale)を受け取り、idurlshortUrl を返します。
  • 成人(18歳以上)の保証。 クレジットカード確認は、正確な年齢推定ではなく成人であることの保証シグナルです。カードの所有が成人に限定されている法域に最も適しています。
  • ステータスと結果は変更なし。 これまでどおり /age-verification/get-status をポーリングするか、Verification.Result webhook を処理してください。結果は確認 method として credit-card を報告します。

ドキュメント