Skip to main content
PayID は、顧客が銀行アプリから支払う宛先です。Hello Clever は複数の種類の PayID を発行しており、どれを選ぶかによって、その宛先の有効期間、金額を持つかどうか、受け付けられる支払いの回数が決まります。このページでは各種類を比較し、それぞれに適した流れを示し、プレフィックスを再利用した場合の挙動を解説します。
PayID は AUD 専用の機能で、v1 API から発行します。エンドポイントとペイロードは AUD PayID による入金を参照してください。

​
種類の選び方

これらの名称は、各種類の挙動を説明するものです。v1 API は独自の用語を使うため、エンドポイントのリファレンスやレスポンスの項目を読む際は次のように対応づけてください。使い切りの PayID は支払いリクエストの request_payid、再利用できる金額指定の PayID は非推奨の prefix_static_payid、継続利用する金額自由の PayID は API が Static Open PayID と呼ぶもの（static_payid）です。

​
使い切りの PayID

1件の取引のために生成される PayID で、想定する金額をそのまま持ちます。支払いが完了するか expired_at を過ぎると登録が解除されるため、再利用も二重の支払いもできません。 支払いが1回限りの出来事で、金額を事前に確定したい場合に使います。
  • チェックアウト：顧客が1件の注文を支払うと、その宛先はなくなります。
  • 請求書：請求書ごとに1つの宛先を用意し、external_id で突き合わせます。
  • 期間限定のオファー：expired_at を設定すれば、未払いのリクエストは自動的に失効します。
有効期間の短さがそのまま不正対策になります。1回の支払い、1つの金額のためだけに存在する宛先は、攻撃者にとって再利用の余地がありません。
顧客がチェックアウトを離脱すると、pending のリクエストが残ります。失効を待たずに cancel-a-payid を呼び出して登録を解除すれば、離脱がすぐにレポートへ反映されます。

​
再利用できる金額指定の PayID

同じ PayID の文字列を複数の支払いリクエストで使い回し、金額と説明だけを都度変える方式です。宛先が変わらないため、支払う側の銀行アプリの登録先一覧に残り、入力し直すことなく再び支払えます。一方で、各支払いはそれぞれ独自の金額を持つ個別のリクエストです。 同じ支払者に、金額を変えて繰り返し請求する場合に適しています。
  • 毎月同じ口座から支払う法人顧客への継続的な請求。
  • 金額を都度確定したいアカウントへのトップアップ。
  • 1つの顧客関係に対する分割払い。
v1 API では、このパターンは create-payment-request の prefix_static_payid フィールドが担いますが、このフィールドは非推奨です。既存の連携では引き続き動作しますが、新規の実装では使わず、継続利用する金額自由の PayID か、支払いごとの使い切りの PayID を利用してください。継続的な支払いの仕組みを新たに構築する場合は、想定される代替手段を Hello Clever に確認してください。

​
継続利用する金額自由の PayID

顧客に紐づく継続的な宛先です。任意の金額を何度でも受け付け、無効化するまで登録されたままになります。取引に固有の要素は一切ありません。 取引ではなく顧客との関係そのものを宛先が表す場合に使います。
  • 顧客ウォレット：顧客が任意のタイミングで入金できる恒久的な宛先。
  • 金額を定めない入金やトップアップ。
  • 入金の時期が読めないマーケットプレイス出品者の資金。
入金のたびに customer_notification の Webhook が、金額、paid_at、送金者の情報とともに呼び出されるため、宛先が開かれていても支払いごとの記録は残ります。

​
無効化後のプレフィックスの再利用

Static PayID は、指定したプレフィックス（3〜35文字、英小文字・数字・ドット）から作られ、prefix@example.com の形式の宛先になります。プレフィックスは永久に消費されるものではなく、無効化された PayID が使っていたプレフィックスは再び利用できます。 以前に使われ、その後無効化されたプレフィックスで Static PayID を作り直す場合、メールアドレスの一意性の検証は再度行われません。そのプレフィックスの以前の PayID で使われていたメールアドレスを、そのまま指定できます。
1

Static PayID を作成する

顧客の name、email、選んだ prefix_static_payid を指定します。この時点ではメールアドレスは一意である必要があり、初回の作成は通常どおり検証されます。
2

顧客が支払う

prefix@example.com に支払いが届き、通常どおり Webhook が呼び出されます。
3

Static PayID を無効化する

その宛先は支払いを受け付けなくなり、プレフィックスが解放されます。
4

同じプレフィックスで作り直す

同じプレフィックスで Static PayID を再度作成します。メールアドレスの一意性の確認は行われないため、同じメールアドレスを指定しても重複として拒否されることはありません。
これが当てはまるのは、そのプレフィックスに実際に PayID が存在し、その後無効化された場合のみです。アカウントで初めて使うプレフィックスや、PayID がまだ有効なプレフィックスでの作成は、通常の検証の流れに従います。
作り直した PayID は、復元されたものではなく新しい記録です。無効化された PayID の履歴を引き継ぐことはなく、無効化より前の支払いは以前の記録に紐づいたままです。両方にまたがって顧客を追跡する必要がある場合は、external_id による対応付けを自社で保持してください。

​
関連ページ

AUD PayID による入金

各パターンのエンドポイント、ペイロード、Webhook の扱い。

C2B の PayID

消費者から企業への PayID がもたらすもの。