OpenTest 项目：API 接口补齐与全业务逻辑规范

APIインターフェースの完成とビジネスロジックの仕様

文書作成日：2026.01.16｜WordPress 特別な目的のための課金とバックエンドのインターフェイス

1. ⚠️ リファインすべきバックエンドAPIのリスト

現在のAPIドキュメントには以下の内容が欠けており、補完的に開発する必要がある：

インターフェース 1 署名検証の追加増加 サイン フィールド。WordPressはアセットリリースの通知を開始するため、MD5署名によってセキュリティを検証する必要があります。
インターフェイス 1 オリジナル・オーダー・アソシエーションを追加するに対して アップグレード 型に渡す必要があります。 オリジナル注文番号.バックエンドは古い資産を探し出し、それに応じてSKUの更新を行う必要がある。
インターフェース 4 デバイス名の追加戻る戻る必要がある マシン名.そうしないと、ユーザーはパーソナルセンターでアンバンドリング操作のために異なるコンピューターを識別できない。
インターフェース4 オフライン残差の数を増やす戻る必要がある remainingOfflineUnbindCount.オフライン・ライセンスは年間3アンバンドルに制限されていた。

2.コア・コンプライアンス・ルールのアップグレード

個人版アセットハンドリング： 認証コードの一貫性を確保するため、Personal Editionのアップグレードは以下のように行われます。 "上書き更新" ロジックだ。
1.支払いに成功すると、WPは以下を含むリクエストを送信する。 注文タイプ: UPGRADE まで オリジナル注文番号.
2. バックエンドは、元の注文に関連する認証コードを見つけ、そのコードのみを更新する。 skuCode の分野だ。新しいコードは生成されない.
3.アップグレードは権限の変更にすぎず、有効期間は原則として変更されない。

3.アップグレード請求の変換式（WP導入）

アップグレードは片道のみサポートされています。WordPressプラグインは、以下の式に従ってスプレッド注文金額を計算します：

トップアップ金額 = 新しいパッケージ料金 - ( 元のパッケージ料金 / 元のパッケージ合計日数 * 残利用可能日数 )

4.認証コード生成の論理的内訳のまとめ

ビジネス・ディメンション	購入シナリオ	バックエンドのフルフィルメント活動の説明
パーソナル・エディション・パッケージ	新規購入 (NEW)	新しい認証コードを生成し、自動的にバインドする。
	リニューアル（RENEW）	新しいコードは生成されず、元のコードの有効期限（EndTime）が更新されます。
	アップグレード	新しいコードは生成されず、元のコードのSKUコードが更新される。
チーム・エディション・パッケージ	すべてのシーン	新しい認証コードは、座席ごとに独立して生成されます。
オプションキット	新規購入／チーム購入	対応する数の新しいオプションパック認証コードを生成する。

5.認証コードのバインド/アンバインド規則（インターフェース3）

無国籍直接執行 バインド オペレーション
既存のパッケージの状態システムはブートストラップとまずUNBINDを呼び出し、古いライセンスコードのバインドを解除する。新しいコードBINDを持っていない場合は、新しいコードBINDを実行してください。
オプション・パッケージのステータス直接実行可 バインドオプションのエンタイトルメント・オーバーレイを実現する。

国境を越えた旅を始めようお問い合わせ

ウェブサイト制作 カスタマーサービス

カスタマーサービス

デザイナー（Figmaのプロトタイプを作る）