販売者(Usakeyの利用者)向け

販売サービスと連携する

Shopify・Square・KOMOJU・Paddle・Lemon Squeezyや自社のシステムでの購入に合わせて、ライセンスを自動で発行・更新・停止・取り消します。

対象プラン
個人 チーム 大規模
操作する人
オーナー 管理者

仕組み

ソフトウェアの代金は、あなたが契約している販売サービス(Shopify・Square・KOMOJU・Paddle・Lemon Squeezy)で受け取ります。Usakeyが代金を預かることはありません。Usakeyは販売サービスからの通知を受け取り、購入・更新・解約・返金に合わせてライセンスを発行・更新・一時停止・再開・取消します。自社のシステムや自動化サービスからは、署名つきの「汎用の受け口」へ送れます。

Usakeyは販売サービスのAPIを呼ばないので、販売サービスの購読を解約しません。ライセンスを取り消す・一時停止する、顧客をアーカイブする、連携を止めるときも、購読と購入者への請求は続きます。請求を止めるには、販売サービスで購読を解約してください。ライセンスの詳細の「購入元」で、どこで買われたかを確かめられます。

  • Usakeyは、販売サービスの公式の方式で通知の署名を確かめ、合った通知だけを使います。販売サービスのAPIは呼ばず、預かるのは通知の署名の鍵だけです。
  • 同じ通知が何度届いても、ライセンスは1回だけ発行します。届く順番が入れ替わっても、購入ごとに新しい通知の状態に合わせます。返金の通知が購入の通知より先に届いたときは、発行しません。
  • テスト用の連携にはテスト環境の製品、本番用の連携には本番環境の製品だけを対応づけられます。まずテスト用で試してください。
  • 検証プランから使えます。オーナーと管理者が設定できます。
  • 検証プランではテスト環境のみ利用できます。検証プランで新規発行するライセンスの期限は、発行から最長1時間です。更新後の期限も、最初の発行から1時間以内です。数量や利用ルールの制限も適用されます。有料プランで発行済みのライセンスは、検証プランに変更しても期限を短縮しません。現在の期限を超える延長はできません。
販売サービスでの購入が、ライセンスになるまで購入者が販売サービスで支払うと、代金はあなたのアカウントに入り、販売サービスは連携ごとの通知を受け取るURLへ署名つきの通知を送ります。Usakeyは、サービスの公式の方式と登録した鍵で署名を確かめ、合わない通知は記録しません。同じ通知は1回だけ反映し、購入ごとに新しい状態に合わせるので、古い通知ではライセンスを変えません。次に、商品の識別子から商品とライセンスの対応を探し、対応の無い商品は記録だけを残します。支払い済みや購読が有効なら、ライセンスを発行するか期限を合わせ、連携が止めたライセンスは再開します。支払い待ち・一時停止・チャージバックなら一時停止、返金・キャンセル・購読の終わりなら取り消しです。製品の署名鍵の準備中やプランの上限など、時間をおけば成功するときは「保留」にして、販売サービスの再送で処理し直します。Usakey(連携ごとの、通知を受け取るURL)あなたの販売サービスShopify・Square・KOMOJU・Paddle・Lemon Squeezy購入者が支払うと、署名つきの通知を送る。代金はあなたのアカウントへ署名を確かめる販売サービスが定める方式と、登録した鍵で確かめる。合わない通知は記録しない1回だけ反映する同じ通知は1回だけ。購入ごとに新しい状態に合わせ、古い通知では変えない商品の対応を探す商品の識別子から、発行する利用ルールを決める。対応が無ければ記録だけ残す支払い済み・購読が有効発行する・期限を合わせる連携が止めたものは再開する支払い待ち・一時停止・チャージバック一時停止する返金・キャンセル・購読の終わり取り消す製品の署名鍵の準備中やプランの上限など、時間をおけば成功するときは「保留」にして、販売サービスの再送で処理し直します販売サービスでの購入が、ライセンスになるまで購入者が販売サービスで支払うと、代金はあなたのアカウントに入り、販売サービスは連携ごとの通知を受け取るURLへ署名つきの通知を送ります。Usakeyは、サービスの公式の方式と登録した鍵で署名を確かめ、合わない通知は記録しません。同じ通知は1回だけ反映し、購入ごとに新しい状態に合わせるので、古い通知ではライセンスを変えません。次に、商品の識別子から商品とライセンスの対応を探し、対応の無い商品は記録だけを残します。支払い済みや購読が有効なら、ライセンスを発行するか期限を合わせ、連携が止めたライセンスは再開します。支払い待ち・一時停止・チャージバックなら一時停止、返金・キャンセル・購読の終わりなら取り消しです。製品の署名鍵の準備中やプランの上限など、時間をおけば成功するときは「保留」にして、販売サービスの再送で処理し直します。Usakey(連携ごとの、通知を受け取るURL)あなたの販売サービスShopify・Square・KOMOJU・Paddle・Lemon Squeezy購入者が支払うと、署名つきの通知を送る。代金はあなたのアカウントへ署名を確かめる販売サービスが定める方式と、登録した鍵で確かめる。合わない通知は記録しない1回だけ反映する同じ通知は1回だけ。購入ごとに新しい状態に合わせ、古い通知では変えない商品の対応を探す商品の識別子から、発行する利用ルールを決める。対応が無ければ記録だけ残す支払い済み・購読が有効発行する・期限を合わせる連携が止めたものは再開する支払い待ち・一時停止・チャージバック一時停止する返金・キャンセル・購読の終わり取り消す製品の署名鍵の準備中やプランの上限など、時間をおけば成功するときは「保留」にして、販売サービスの再送で処理し直します
Usakeyは署名を確かめた通知だけを使い、購入ごとの新しい状態にライセンスを合わせます。結果は、連携の画面の通知の履歴で確かめられます。

使える販売サービス

サービス反映する通知商品の識別子
Shopify注文の支払い・更新・キャンセル(一回払い。返金は注文の状態で判断)、異議申し立て(Shopifyペイメントのチャージバック)の作成・更新バリエーションID・商品ID・SKU
Squareサブスクリプションの作成・更新(有効・一時停止・解約)、購読の請求の自動支払いの失敗・支払い購読プランのバリエーションID
KOMOJU決済の完了・全額の返金(一回払い)決済のmetadataのusakey_item
Paddle取引の完了、購読の作成・更新・支払い待ち・一時停止・再開・解約、返金(全額・承認済み)・チャージバック価格ID(pri_)・商品ID(pro_)
Lemon Squeezy注文の作成・返金、購読の作成・更新・解約・再開・終了・一時停止バリエーションID・商品ID
汎用(署名つき)発行・プランの変更・更新・停止・再開・取消(送る内容で指定)送るJSONのitem

表に無い販売サービスや自社のシステムからは、汎用の受け口かManagement APIへ送って連携できます。送り方は「汎用の受け口に送る」と「自動化サービスとCRMから使う」にあります。

送り元ごとの、Usakeyへの送り先受け口のある販売サービス(Shopify・Square・KOMOJU・Paddle・Lemon Squeezy)は、連携の通知を受け取るURLへ、サービスの方式で署名した通知を送ります。自社のシステムや、署名を作れる自動化サービスの送り先は、汎用の受け口です。署名はUsakeyが作った鍵で「時刻.イベントID.本文」から計算し、同じ購入を1回だけ反映するなどの扱いはUsakeyが受け持ちます。署名を作れないサービスは、APIキーでManagement APIを呼び、ライセンスの発行や停止を直接行います。この道では、重複の防止を呼び出す側で行ってください。Usakey受け口のある販売サービスShopify・Square・KOMOJU・Paddle・Lemon Squeezy通知を受け取るURL販売サービスの方式の署名を確かめる。発行するライセンスは商品の対応で決まる署名を作れる送り元自社のシステム・n8n・Make・Zapier・SalesforceのApex汎用の受け口Usakeyが作った鍵で、「時刻.イベントID.本文」に署名する。重複と順序はUsakeyが受け持つ署名を作れない送り元Power Automate・Yoom・kintone・HubSpot・SalesforceのフローManagement APIAPIキーで、ライセンスの発行・停止などを直接呼ぶ。重複の防止は呼び出す側で行う送り元ごとの、Usakeyへの送り先受け口のある販売サービス(Shopify・Square・KOMOJU・Paddle・Lemon Squeezy)は、連携の通知を受け取るURLへ、サービスの方式で署名した通知を送ります。自社のシステムや、署名を作れる自動化サービスの送り先は、汎用の受け口です。署名はUsakeyが作った鍵で「時刻.イベントID.本文」から計算し、同じ購入を1回だけ反映するなどの扱いはUsakeyが受け持ちます。署名を作れないサービスは、APIキーでManagement APIを呼び、ライセンスの発行や停止を直接行います。この道では、重複の防止を呼び出す側で行ってください。受け口のある販売サービスShopify・Square・KOMOJU・Paddle・Lemon SqueezyUsakey通知を受け取るURL販売サービスの方式の署名を確かめる。発行するライセンスは商品の対応で決まる署名を作れる送り元自社のシステム・n8n・Make・Zapier・SalesforceのApexUsakey汎用の受け口Usakeyが作った鍵で、「時刻.イベントID.本文」に署名する。重複と順序はUsakeyが受け持つ署名を作れない送り元Power Automate・Yoom・kintone・HubSpot・SalesforceのフローUsakeyManagement APIAPIキーで、ライセンスの発行・停止などを直接呼ぶ。重複の防止は呼び出す側で行う
受け口のある販売サービスは連携のURLへ、署名を作れる送り元は汎用の受け口へ、作れない送り元はAPIキーでManagement APIへ送ります。

連携を登録する

  1. 手順1使う販売サービスを選ぶ

    左のメニューの「決済・販売サービスの連携」を開き、「連携を追加する」から使うサービスを選びます。テスト用と本番用は、別の連携として登録します。

  2. 手順2販売サービスに通知先のURLを登録する

    登録画面の「通知を受け取るURL」を、販売サービスの通知(Webhook)の送り先に登録し、画面に並ぶ出来事を選びます。SquareはこのURLを署名に含めるので、1文字も変えずに登録してください。

    • Shopify: 管理画面の「設定 > 通知 > Webhook」で、「注文の支払い」「注文の更新」「注文のキャンセル」のWebhookをJSON形式で作ります。Shopifyペイメントのチャージバックを反映するときは、disputes/createとdisputes/updateのWebhookも同じURLで作ってください。管理画面で選べないときは、注文の分も含めてカスタムアプリ(read_shopify_payments_disputesの権限)のWebhookで作り、アプリのクライアントシークレットを署名の鍵にします。
    • Square: Developer ConsoleのWebhooksで購読を追加し、subscription.created・subscription.updated・invoice.scheduled_charge_failed・invoice.payment_madeを選びます。請求(invoice)の通知には、請求書の読み取り(INVOICES_READ)の権限が要ります。
    • KOMOJU: 管理画面でWebhookを追加し、payment.capturedとpayment.refundedを選び、シークレットトークンを決めます。
    • Paddle: 「Developer tools > Notifications」で通知先を作り、取引・購読・返金(adjustment)・顧客の出来事を選びます。サンドボックスと本番は別の通知先です。
    • Lemon Squeezy: 「Settings > Webhooks」でWebhookを追加し、署名シークレットを決めて、注文と購読の出来事を選びます。
  3. 手順3署名の鍵を入れて登録する

    販売サービスの画面の署名の鍵(ShopifyのWebhookの署名の鍵、SquareのSignature key、KOMOJUのシークレットトークン、Paddleの通知先の秘密鍵、Lemon Squeezyの署名シークレット)を入れて、「連携を登録」を押します。鍵は保存後に表示しません。汎用の受け口の鍵はUsakeyが作り、登録の直後に一度だけ表示します。

Management API(/mgmt/v1/sales-integrations)と、AIアシスタントの接続(MCP)からも登録・変更できます。読み取りにはproducts:read、変更にはproducts:writeとlicenses:writeの権限が要ります。AIアシスタントは販売サービスの署名の鍵を扱いません。AIアシスタントで登録した連携は「署名の鍵の登録待ち」になるので、連携の画面の「設定の画面で鍵を入れる」から鍵を入れてください。鍵が入るまで、通知は受け取りません。

商品とライセンスを対応づける

連携の画面の「対応を追加」から、販売サービスの商品の識別子と、発行するライセンスの利用ルールを対応づけます。対応の無い商品が買われたときは、通知の履歴に記録だけ残り、ライセンスは発行しません。ただし、購入者のアプリの確認値(usakey_claim_challenge)が付いた購入で、どの商品にも対応が無いときは保留にします。対応を追加すると、販売サービスの再送のときに発行します。

  • 買い切りの利用ルールは期限なしで発行します。
  • 期間制の利用ルールは、Square・Paddle・Lemon Squeezyでは販売サービスの契約期間の終わりを期限にします(有効日数を入れると、購入日からの日数にします)。ShopifyとKOMOJUは購読を反映しないので、有効日数が必要です。
  • お試しの利用ルールと、管理なしの完全オフラインの買い切りは選べません。
  • 数量は使いません。1つの購入(Shopifyでは注文の1明細)につき、1つのライセンスを発行します。台数や人数は利用ルールのとおりです。
  • 購読(Paddle・Lemon Squeezy・Square)の商品は、期間制の利用ルールに対応づけます。購読の通知の商品を買い切りの利用ルールに対応づけると、設定の誤りとして発行に失敗します。
  • 対応の商品の識別子を書き換えると、前の識別子で続いている購読の次の通知は、プランの変更として扱います。新しい識別子に合う対応が無ければ、ライセンスを停止します。

ライセンスキーを購入者へ渡す

発行したライセンスキーの渡し方は、次のどれかです。

  • 購入者のアプリが受け取る(安全な受け取り): アプリが購入の前に43文字の確認値(claim_verifier)を作り、そのSHA-256をusk_claim_v1_に続けた値を、購入のcustom dataのusakey_claim_challengeに入れます(Shopifyはカートの属性、KOMOJUはmetadata、PaddleはcustomData、Lemon Squeezyはcheckout[custom])。購入のあと、連携の画面の「受け取り口のURL」へ確認値を送ると、キーを受け取れます。Stripeでの販売連携と同じ仕組みで、受け取れるのは72時間です。Squareはcustom dataを渡せないため使えません。
  • 汎用の受け口の応答で受け取る: 発行を送ると、応答にライセンスキーが入ります。同じイベントIDで送り直しても、72時間は同じキーが返ります。
  • 販売者が渡す: ライセンスの詳細の画面でキーを確かめて、購入者へ知らせます。
購入者のアプリが、ライセンスキーを安全に受け取るまで購入者のアプリは、購入の前に確認値を作って手元に保存し、そのSHA-256を購入のcustom dataに入れて購入画面を開きます。購入者が支払うと、販売サービスはcustom dataを含む署名つきの通知をUsakeyへ送ります。キーをあずかるのは、Usakeyがライセンスを発行してから最長72時間です。アプリが確認値を「受け取り口のURL」へ送るとキーが返り、保存したことを知らせると、Usakeyはあずかったキーを消します。確認値を知っているのは購入者のアプリだけなので、ほかの人はキーを受け取れません。汎用の受け口では、発行の応答にキーが入ります。Squareはcustom dataを渡せないので、ライセンスの画面でキーを確かめて購入者へ知らせてください。購入者のアプリ販売サービスUsakey購入の前確認値を作り、手元に保存する1購入画面を開く。custom dataに、確認値のSHA-256を入れる2購入購入者が支払う3署名つきの通知(custom dataつき)4ライセンスを発行し、キーを最長72時間あずかる5購入のあと確認値を「受け取り口のURL」へ送る6ライセンスキー7保存したことを知らせる8あずかったキーを消す9汎用の受け口では、発行の応答にキーが入ります。Squareはcustom dataを渡せないので、ライセンスの画面でキーを確かめて購入者へ知らせてください購入者のアプリが、ライセンスキーを安全に受け取るまで購入者のアプリは、購入の前に確認値を作って手元に保存し、そのSHA-256を購入のcustom dataに入れて購入画面を開きます。購入者が支払うと、販売サービスはcustom dataを含む署名つきの通知をUsakeyへ送ります。キーをあずかるのは、Usakeyがライセンスを発行してから最長72時間です。アプリが確認値を「受け取り口のURL」へ送るとキーが返り、保存したことを知らせると、Usakeyはあずかったキーを消します。確認値を知っているのは購入者のアプリだけなので、ほかの人はキーを受け取れません。汎用の受け口では、発行の応答にキーが入ります。Squareはcustom dataを渡せないので、ライセンスの画面でキーを確かめて購入者へ知らせてください。購入の前1購入者のアプリ確認値を作り、手元に保存する2購入者のアプリ販売サービス購入画面を開く。custom dataに、確認値のSHA-256を入れる購入3販売サービス購入者が支払う4販売サービスUsakey署名つきの通知(custom dataつき)5Usakeyライセンスを発行し、キーを最長72時間あずかる購入のあと6購入者のアプリUsakey確認値を「受け取り口のURL」へ送る7Usakey購入者のアプリライセンスキー8購入者のアプリUsakey保存したことを知らせる9Usakeyあずかったキーを消す汎用の受け口では、発行の応答にキーが入ります。Squareはcustom dataを渡せないので、ライセンスの画面でキーを確かめて購入者へ知らせてください
キーを受け取れるのは、購入の前に確認値を作ったアプリだけです。受け取れるのは72時間で、保存の確認が届くとUsakeyはキーを消します。

購入のあとに起きること

販売サービスの購読・支払い・返金の状態に合わせて、ライセンスを次のように変えます。連携が止めたライセンスだけを再開します。あなたが管理画面やManagement APIで止めたライセンスは、そのまま期限を過ぎたあとも、販売サービスの通知では再開しません(期限と利用ルールだけを合わせます)。

購入より先に届いた停止・再開・取消の通知も記録し、発行時に照合します。初回購入が全額返金された購入では、その後に購読が有効の通知が届いても、ライセンスを発行・再開しません。Squareは請求書ごとに未払いを管理し、別の請求への支払いでは停止を解きません。Shopifyは同じ異議申し立ての終了後に届いた古い開始通知で止め直しません。Paddleでは、購読から削除された明細のライセンスを停止し、再追加時は同じライセンスを再開します。返金対象が初回取引か分からない間は停止し、初回取引の通知で確認できたら、初回の全額返金なら取り消し、更新分の返金ならその停止を解きます。他の停止理由が残る場合は再開しません。

出来事ライセンスの変化サービスごとの違い
更新の支払い期限を販売サービスの契約期間の終わりに合わせ、連携が止めたものは再開します。Paddle・Lemon Squeezyは契約期間の終わりです。Squareは請求した期間の最後の日(charged_through_date)で、支払いの日ではありません。ShopifyとKOMOJUは購読を反映しないので、対応の有効日数で期限を決めます。
支払いの失敗(カードの期限切れ・拒否)すぐ停止し、猶予はありません。支払われたら再開します。カードの更新は、購入者が販売サービスの画面で行います。Paddle・Lemon Squeezyでは、支払い待ち(past_due・unpaid)の通知で停止し、購読が有効の通知で再開します。Squareは未払いでも購読を有効のまま送るため、invoice.scheduled_charge_failedで停止し、再開は全額の支払い(invoice.payment_made)のときだけです。期限が過ぎてから支払われたときは自動で再開しないことがあるので、管理画面で再開してください。
プランの変更同じライセンスキーのまま、新しい商品の対応の利用ルールへ切り替えます。権利は新しい利用ルールの内容になり、あなたがライセンスに足した権利は引き継がれます。期限は販売サービスに合わせます。対応が無い商品・別の製品の商品・期間制ではない利用ルールへの変更では、前のプランの権利を残さないよう停止します。対応を直せば、次の通知で切り替えて再開します。切り替える時点は、販売サービスでプランが変わった時点です(予約した変更は、切り替わった時点)。明細が複数あるPaddleの購読は、明細ごとの扱いです。汎用の受け口ではchangeを送ってください。
解約期間の終わりでの解約では、その時点まで使えて、終了の通知で取り消します。すぐ解約したときは、その通知ですぐ取り消します。期間内に解約を取り消せば、有効のままです。Paddleは解約の予約(scheduled_change)の時点を期限にし、canceledの通知で取り消します。Lemon Squeezyのcancelledはends_atまで使えて、expiredの通知で取り消しになります。SquareはCANCELED・COMPLETEDの通知で取り消します。
返金全額の返金で取り消します。一部の返金では変えません。Shopifyは注文が返金・キャンセル・無効になれば全部の明細を、明細の数量ぶん返金されればその明細だけを取り消します。KOMOJUは全額の返金(payment.refunded)だけです。Paddleは最初の取引の全額・承認済みの返金だけで、更新分の返金ではライセンスを変えません。Lemon Squeezyは注文の返金で、その注文から始まった購読のライセンスも取り消します。更新分の返金の通知は扱いません。
異議申し立て(チャージバック)起きたら停止し、負けたら取り消します。勝つか取り下げられたら、連携が止めたものだけ再開します。注文や購読の更新の通知では再開しません。支払い待ちなどで止めているときに起きた場合は、両方の理由が解けるまで再開しません。1つの注文に異議申し立てが2件あるときは、両方が終わるまで再開しません。Shopifyはdisputes/create・disputes/updateで、問い合わせの段階(inquiry)では止めません。Paddleはchargebackで停止し、chargeback_reverseで再開します。Lemon Squeezyは不正(fraudulent)の注文を取り消します。KOMOJUは異議申し立ての通知が無いので反映しません(必要なら管理画面でライセンスを止めてください)。Squareの異議申し立ては扱いません。
Usakeyのプランの上限発行済みのライセンスの更新と再開は、数量の上限を超えていても、その理由だけでは断りません。期限の制限は適用されます。新しい発行と、プランの変更で使う枠が増えるときだけ上限を確かめ、足りなければ保留にします(保留の間、ライセンスは前のプランのままです)。すべてのサービスで同じです。
  • 購入者は、販売サービスの顧客ID(Shopify・Square・Paddle・Lemon Squeezy)と、汎用の受け口のcustomer.referenceで、同じ顧客として扱います。メールアドレスでは照合しません。KOMOJUの通知には顧客IDが無いので、購入のたびに新しい顧客を作ります。アーカイブ済みの顧客に当たったときは、その顧客へ発行し、通知の履歴に残します。
  • 別々の購入(2つのタブで買う、同じ人が購読を2つ始めるなど)には、それぞれライセンスを発行します。二重の支払いはUsakeyでは止められないので、販売サービスの側で既存の購読を確かめてから購入画面を開いてください。1つの確認値で受け取れるのは1回です。同じ確認値の2回目の購入にもライセンスを発行しますが、キーはあなたが渡します。
  • 購読の解約と返金は、販売サービスで行います。Usakeyでライセンスを取り消したり、顧客をアーカイブしたりしても、販売サービスの購読と請求は止まりません。
  • KOMOJUの通知には、テストと本番を見分ける項目がありません。テスト用と本番用で別のWebhookとシークレットトークンを使ってください(テストの決済の通知が本番用のWebhookに届くかは確かめていません)。

汎用の受け口に送る

自社のシステムから、連携の画面の「通知を受け取るURL」へJSONをPOSTします。署名は、UsakeyのWebhook通知と同じ形です。

  • X-Usakey-Event-Id: 送り元が決める一意のID(英数字と記号(.・_・:・-)、128文字まで)。送り直すときは同じ値にします。
  • X-Usakey-Timestamp: 送った時刻(Unix秒)。前後300秒まで受け付けます。
  • X-Usakey-Signature: v1=に続けて、署名の鍵で「時刻.イベントID.本文」をHMAC-SHA256にした16進数。
{
  "action": "issue",
  "purchase_id": "order-1001",
  "item": "pro-yearly",
  "customer": {"email": "buyer@example.com", "name": "山田 太郎", "reference": "crm-42"},
  "expires_at": "2027-10-18T00:00:00Z"
}

actionはissue(発行)・change(プランの変更)・renew(期限の更新)・suspend(一時停止)・resume(再開)・revoke(取消)です。2回目からはpurchase_idだけで同じライセンスを指せます。changeはitemに新しい商品の商品コードを入れ、同じライセンスキーのまま、その対応の利用ルールへ切り替えます。同じ製品の期間制の利用ルールに対応づけた商品でないときは失敗になり、ライセンスは変わりません。suspend・resume・revokeにはreason(理由)を付けられ、操作履歴に残ります。応答の結果(反映・変更なし・失敗・保留)と、項目の詳しい意味はAPIリファレンスにあります。保留(503)の通知は、時間をおいて同じイベントIDで送り直してください。

自動化サービスとCRMから使う

署名を計算できるサービスは汎用の受け口へ、できないサービスはManagement API(APIキー)へ送ります。APIキーは、必要な操作の権限だけを持つものを作ってください。

  • n8n: ワークフローの定義ファイルを取り込みます(Import from File)。Cryptoノードで署名を作り、HTTP Requestノードで汎用の受け口へ送ります。署名の鍵はCryptoの資格情報に入れます。
  • Make: 変数に本文(JSONの文字列)・時刻(formatDate(now; "X"))・イベントIDを作り、sha256(時刻 + "." + イベントID + "." + 本文; "hex"; 署名の鍵)の前にv1=を付けて署名にします。HTTPの「Make a request」で、Raw・application/jsonの本文と3つのヘッダーを付けて汎用の受け口へ送ります。
  • Zapier: Code by Zapier(JavaScript。Node.jsのcryptoとfetchが使えます)で署名を作り、そのままfetchで汎用の受け口へ送ります。
  • Power Automate: 式にHMACの関数が無いので、HTTPアクション(プレミアム)でManagement APIへ送ります(Authorization: BearerにAPIキー)。
  • Yoom: ストアに注文が入ったときなどのトリガーから、Management APIへ送ります。任意のAPIを呼ぶ方法はYoomのヘルプで確かめてください。
  • kintone: Webhookは認証のヘッダーを付けられないので、Zapier・Power Automateで受けて送るか、プラグインのkintone.plugin.app.setProxyConfigにAPIキーを保存してkintone.plugin.app.proxyでManagement APIを呼びます(保存した値は利用者から見えません)。
  • HubSpot: ワークフローの「Webhookを送信」(Data Hub Professional以上)で、認証に「APIキー」(リクエストヘッダーのAuthorization)を選び、Management APIへ送ります。
  • Salesforce: 外部認証情報と指定ログイン情報でAuthorizationのヘッダーを付け、フローのHTTPコールアウトでManagement APIへ送ります。ApexならCrypto.generateMacで署名を作り、汎用の受け口へ送れます。

困ったときは

  • 通知の履歴に何も出ないときは、署名の鍵と通知先のURLを確かめてください。署名の合わない通知は記録しません。「署名の鍵の登録待ち」の連携は、鍵を入れるまで通知を受け取りません。
  • 利用ルールを編集すると、有効な対応は新しい版へ切り替わります。利用ルールを廃止すると、その対応での発行は保留になります。対応で運用中の利用ルールを選ぶと、販売サービスの再送のときに発行します。
  • 「保留」は、製品の署名鍵の準備中やプランの上限など、時間をおけば成功しうるときです。販売サービスが再送すると、もう一度処理します。
  • 確認値の無い購入で対応の無い商品は、あとで対応を作っても同じ通知では発行しません。ライセンスを手で発行するか、汎用の受け口でissueを送ってください。
  • 販売サービスが送り直すのは決まった期間だけです(Lemon Squeezyは数分、Shopifyは4時間、Squareは24時間、Paddleは3日、KOMOJUは25日)。連携を止めている間や保留のまま期間を過ぎた通知は、販売サービスで送り直すか、ライセンスを手で直してください。ShopifyのアプリのWebhookは、失敗が続くと登録が消えることがあるので、再開したら確かめてください。
  • 販売者が管理画面やManagement APIで一時停止したライセンスは、販売サービスの通知では再開しません。
  • テストの通知が本番用の連携に届いたとき(Shopifyのtest、Lemon Squeezyのtest_mode)は反映しません。

AIに実装・設定を頼む

MCPへ接続したAIアシスタントに、目的に合う指示文をコピーしてください。MCPのプロンプト一覧から同じ作業を選ぶこともできます。接続手順は「製品に組み込む」のページにあります。 製品アプリに認証を組み込む

Stripe以外の販売サービスとの連携
UsakeyのMCPと配布スキルを使って、次の作業を進めてください。まず対象のスキルのVERSIONとSKILL.md、以下の参照資料を読んでください。手元のMCPで資料を読めない場合は、接続先が案内する配布ZIPから同じ資料を読んでください。対象製品・環境・言語・既存設定を確認し、不明な値を創作しないでください。製品アプリには公式SDKを使い、管理APIキーを入れないでください。管理操作は現在の接続で許可された権限とプランの範囲で行い、秘密情報は会話・画面・ログへ出さないでください。実装前に期待する動作をテストへ書き、完了時には実際に動かした範囲と未確認の範囲を示してください。

利用する販売サービスを確認し、販売連携と購入後のライセンス受け取りを実装してください。対象サービスのイベント形式と本人確認の方法はスキルの手順に従ってください。重複通知、取消・返金、反映待ち、キーの再取得とACKをテストし、秘密情報を入力するConsoleの操作は利用者へ案内してください。

読む資料
skill://usakey-stripe-integration/references/other-sales-services.md
skill://usakey-stripe-integration/references/license-key-claim.md
skill://usakey-stripe-integration/references/test-matrix.md

設定・確認に使う管理ツール
list_sales_integrations
create_sales_integration
update_sales_integration
list_sales_integration_events

画面はテスト環境で架空のデータを使って撮影しています。製品IDなどの識別子、ライセンスキー、認証トークンは伏せています。画面の細部は、改善に合わせて変わることがあります。