Stripe Payment Linksの使い方｜単発決済リンクの設定・共有・支払い確認

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

Stripe Payment Linksは、決済ページへのリンクを作り、メールやウェブページなどで案内できる仕組みです。固定価格の商品を少数から販売するとき、決済用の画面を自分で開発しなくても支払いを受け付ける方法として検討できます。ただし、リンクが作れたことと、販売に必要な案内や購入後の対応が整ったことは別です。

この記事では、日本で営業する小規模事業者が、同じ固定価格・一回限りの商品を複数の購入者へ案内する場面に絞ります。商品と数量、必要な入力欄、サンドボックスでの確認、共有先と停止、支払いと提供の照合を順に整理します。継続課金、寄付、購入者が自由に金額を決める販売、決済システムの開発は扱いません。

各表の品名、価格、回数、管理番号は説明用の架空例です。実在する取引や運用実績ではなく、テスト票も実施結果を示すものではありません。公式情報は2026年10月6日（日本時間）時点で確認しています。実際の利用前には、現在の公式資料、アカウントの審査状況、設定画面と料金を確かめてください。

決済リンクで受け付ける単発購入の範囲を決める

同じリンクを複数の人へ案内する用途かを確かめる

Payment Linksの公式比較では、リンクを受け取った人が利用でき、複数の顧客による再利用が可能とされています。対してInvoicingは、特定の個人や企業へ請求する用途です。まず「誰に対する何の支払いか」を考え、共通の商品購入と、特定の取引先への個別請求を混ぜないようにします。Payment LinksとInvoicingの比較

例えば、自作の印刷冊子を同じ条件で販売し、紹介メールと案内ページの両方から同じ決済ページへ進んでもらう場合は、共通のリンクが管理しやすい場面です。一方、取引先ごとに金額や期限が違い、請求先を特定して案内したい場合は、請求書の仕組みも比較した方がよいでしょう。この記事では、前者の固定価格の単発購入を扱います。

共通リンクを一人にだけ送っても、それだけで本人専用の支払い口になるわけではありません。転送されたリンクを別の人が開く可能性があります。限定の相手だけに購入を許可したい、本人ごとに一回に制限したい、といった条件が重要なら、リンクの共有範囲だけで実現できると判断しないでください。本人の確認方法や販売条件を別に検討する必要があります。

表は横にスクロールできます。

オンラインストア不要でも、事業の確認は必要になる

決済ページをStripeが提供するため、オンラインストアを一から作らずに決済を受け付けることはできます。しかし、本番の支払いを受け付けるには、事業や本人に関する情報の確認など、アカウントの有効化に必要な手続きを行います。日本向け公式開始ガイドには、事業内容の説明、本人確認、入金用口座などの案内があります。日本でStripeを利用開始するためのガイド

「何を売るのか」「誰へ提供するのか」「どのように渡すのか」を、申し込み前に自分の言葉で説明できるようにします。業種を短く書くだけでは、実際の取引の姿が伝わらないことがあります。審査に必要な情報と、購入者に見せる商品説明を同じものだと思わず、それぞれの目的に合わせて準備します。追加確認があれば現在の公式案内に従って対応します。

審査の日数の目安を、その日から必ず販売できる約束へ変えないことも大切です。商品を発送できる準備が整っていても、本番で決済を受け付けられるかはアカウントの状態を見て判断します。開始前の告知をする場合も、未確認の段階で購入可能と案内しないよう、公開日と案内文の管理を分けます。

Stripeの商取引開示ガイドには、加盟店が表示する情報や、そのページへ決済画面からアクセスできるようにする案内があります。独自のストアが不要という説明を、事業情報や商品説明も不要という意味に読み替えてはいけません。必要な記載や個別の法律の適用が分からない場合は、公式案内や公的な相談先、必要に応じた専門家へ確認します。商取引に関する開示ページの案内

決済を受け付けた後の担当を先に決める

リンクの作成前に、支払いを誰が確認し、商品を誰が提供し、問い合わせをどこで受けるかを決めます。一人で運営する場合も、頭の中だけで済ませず、確認する時間帯と記録する場所を書いておくと見落としを減らせます。購入者が夜に支払う可能性があるなら、購入後の案内で、いつ次の連絡が届くかを実態に合わせて伝えます。

通常のPayment Linksを使うだけで、販売者としての対応をすべてStripeが引き受けるわけではありません。税務や販売上の責任を肩代わりする別のサービスと混同せず、商品説明、提供、返品・返金への対応を自分の運用として確認します。決済を処理できることと、商品や取引そのものが適切であることは、それぞれ別に確認する事項です。

ここまでを一枚の用途判定票へまとめます。販売するもの、固定価格、対象者、提供方法、購入後の連絡先、停止する判断を記入し、空欄が残るものを洗い出します。リンクの設定だけを急ぐより、支払いが入った後に困る点を先に見つけられます。とくに数量の上限や提供時期が曖昧なら、次の設定へ進む前に商品条件をそろえておきましょう。

商品・金額・数量と、購入回数の上限を設定する

一回限りの固定価格を、選択した商品と照合する

公式の作成手順では、ダッシュボードのPayment Linksから新しいリンクを作り、既存の商品を選ぶか新しい商品を追加し、リンクを作成する流れです。この記事の対象は、決まった価格で一回だけ支払う商品です。設定する際は、商品名だけでなく、選んだ価格が一回限りになっていること、金額と通貨が意図どおりであることを確認します。決済フォームへのリンクを作成する

架空の商品を「練習用ワークブック・印刷版」とし、表示価格を三千円とします。同じような名称の旧版や別形式の商品があるなら、購入者が見分けられる表記にします。管理用の名前だけに版を付けても、決済画面の表示が同じままでは誤購入につながります。リンク、商品、価格をそれぞれ識別できるよう台帳へ残すと、後で修正する対象を取り違えにくくなります。

価格を見るときは、単価だけでなく、購入者が最後に支払う総額も確認します。税の扱い、送料、別の追加項目が設定されていれば総額は変わります。説明用の三千円という数字を、そのままどの購入者にも同じ最終金額になると扱わないでください。販売地域や通貨に関する設定が影響する場合も、実際の表示を確認した範囲を記録します。

商品の数量と、完了した決済セッションの回数を分ける

一回に買う個数の上下限と、リンクを無効にする完了セッション回数の上限は、別の設定です。数量と回数を別の列へ記録します。数量の調整と支払い回数の制限

例えば一回の購入で三個を選び、その購入手続きが一つのセッションとして完了した場合、商品数量は三個、完了セッションは一回です。三個買ったからリンクの回数を三回消費する、と数えるのは誤りです。反対に、上限を五回にしたことを、販売できる商品の総数が五個に固定されたことと読み替えてはいけません。

表は横にスクロールできます。

この表の十五個は、五回の購入すべてが三個だった場合の算術例です。実際の販売数、在庫数、同時に開かれた決済画面の状態を保証する数字ではありません。リンクの上限を使う場合でも、提供できる商品数や残量の管理を別に用意し、設定の意味をテスト環境で確認します。

複数リンクに分けたときの管理単位もそろえる

メール用と紹介ページ用に、同じ商品のリンクを別々に作りたくなることがあります。その場合は、どの上限をどのリンクへ設定したかを区別します。一つのリンクの制限が、別のリンクや他の販売経路の在庫までまとめて制御する、と考えないようにしてください。残数が少ない商品ほど、決済と在庫を結ぶ方法を慎重に検討します。

予約席や日時別の定員にも同じ注意が必要です。リンクの完了回数を設定しただけで、複数の申込者による最後の一枠の取り合いを、予約システムと同じように管理できるとは言えません。日程の選択、仮押さえ、キャンセル後の枠の戻し方まで必要なら、それに適した仕組みを選びます。決済用の回数制限へ、扱っていない役割を背負わせないことが大切です。

上限を一回にしたリンクも、「特定の一人が一回だけ使う」という本人制限とは異なります。先に別の人が利用すれば、想定した相手が使えなくなる可能性があります。購入者の識別が必要な取引では、誰が支払ったかを確認する運用を持ち、名前をリンクの説明へ書いただけで保護できると思わないようにします。

設定を終える前に、台帳とプレビューを横に並べて照合します。商品名、版、単価、通貨、一回限りの設定、数量の初期値、数量変更の可否、回数制限を順に見ます。設定の意味が分からない項目は、とりあえず有効にして後から考えるより、必要性を確かめてから選びます。簡単に作れるリンクだからこそ、商品条件を一度文章にしておくことが役立ちます。

必要な入力欄と、購入前に読める案内を整える

入力してもらう項目には、それぞれ目的を付ける

決済ページの入力欄は、多ければ安心というものではありません。提供や連絡に使わない情報まで集めると、購入者の負担と管理する情報が増えます。最初に、発送、領収書、連絡、商品選択など、項目を必要とする目的を書きます。同じ目的の情報を別の欄でも重ねて求めていないかを確認しましょう。

請求先と配送先は別の住所欄です。配送先を集める場合は国も選び、電話番号は取引に必要な場合だけ求めます。住所と電話番号の収集設定

以下の表は、入力欄を選ぶ前の検討用です。実際には事業内容、利用する決済手段、税計算などによって必要な項目が変わります。個別の要件を確認したうえで、標準の入力欄で受け取るものと、商品固有の選択肢を整理してください。

表は横にスクロールできます。

カスタム欄を、秘密情報の受け取り口にしない

公式資料はカスタム欄で個人情報、保護対象・機密・法的に制限される情報を集めないよう求めています。カード情報や本人確認書類などの受け取り口にしないでください。カスタムフィールドの注意事項

自由記入欄を置くと、こちらが想定しない情報を書かれることもあります。「何でもご記入ください」より、入力の目的を絞り、機密情報は書かない旨を分かりやすく伝えます。そもそも選択肢で済む場合は、非個人情報の選択式にできないか検討します。例えば包装の有無を選ぶだけなら、詳しい事情を聞く必要はありません。

商品に関する質問が多い場合も、決済欄を長い相談フォームにする前に、購入前の案内を見直します。発送時期、含まれるもの、対象外の使い方などを読めれば、入力しなくてよい質問が減ることがあります。購入前に相談が必要な商品なら、問い合わせ先を明らかにし、条件が決まらないまま支払いを急がせないようにします。

規約や開示は、設定したことより読めることを確かめる

利用規約のURLを設定すると同意チェックを求められ、設定済みのプライバシーポリシーもリンク表示されます。購入者として読めるかを確認します。利用規約への同意とプライバシーポリシーの表示

リンク先が編集者だけに見える下書きだったり、別の商品の古い条件だったりすると、正しい案内になりません。普段の管理者ログインに頼らず閲覧できるか、スマートフォンで文字が読めるか、販売者と商品を識別できるかを確認します。ページを移動した際には、決済ページ側に古いリンクが残っていないかも点検します。

商取引に関する開示ページも、設定したURLから到達できることを確認します。公式ガイドは、決済ページで開示ページへのリンクを表示する方法を案内しています。ここで扱うのは、その表示と到達の点検です。定型文を貼り付ければすべての法律上の要件を満たすという説明ではなく、自分の事業に必要な記載内容は別に確認してください。商取引開示ページの表示方法

購入前の説明と、決済後のメッセージも一致させます。購入前には「確認後に発送」と書き、完了画面には「発送済み」と表示すると、実際の状態が分からなくなります。手動で支払いを確認するなら、その後の案内や連絡の目安を、守れる範囲で伝えます。購入者が次に何を待てばよいか分かる文章にすることが大切です。

作成した入力項目の表には、目的、必須か任意か、受け取った情報を確認する場所、関連する案内ページを残します。使わなくなった欄をそのままにせず、商品条件を変えたときに見直す対象とします。設定を増やす前に、必要な目的があるかを一つずつ確かめると、決済画面も運営後の照合も分かりやすくなります。

サンドボックスで表示・失敗・完了後の動きを確かめる

実資金が動かない環境で、確認項目を試す

Stripeのサンドボックスは、実際の資金を動かさずに動作を確かめるための環境です。成功する支払いだけでなく、拒否される支払いや認証が必要な場面など、公式のテスト情報で状況を再現できます。実際の決済情報を使って本番環境で試し買いすることは、Stripeのテスト資料で禁止と案内されています。Stripeのテスト方法

最初に、開いているのがサンドボックスか本番かを画面で確認します。ブラウザーのタブ名や自分の記憶だけに頼らず、環境と対象アカウントを確かめてから作業します。テスト用のリンクと本番のリンクを同じメモへ無印で置くと、配布時に取り違えやすくなります。台帳の列や名称で明確に分けてください。

ここからの表は、販売者自身が確認するときに使う仮のテスト票です。この記事のためにアカウントやリンクを作成して試した結果ではありません。確認日、対象の環境、使った設定、実際の結果を埋め、未確認の項目を確認済みへ変えない形で利用してください。

表は横にスクロールできます。

成功画面だけを見るテストで終わらせない

支払いが成功する経路だけを確かめると、途中で失敗した購入者への案内が抜けます。失敗後に商品が提供済みになる、認証途中なのに完了と連絡する、数量を変えたのに説明の金額が古い、といった食い違いを探します。具体的なテスト情報は公式ページの該当するシナリオから選び、現実のカード情報は使いません。

数量のテストでは、初期値だけでなく、設定した最小と最大で表示がどう変わるかを見ます。三千円の商品を三個にする架空例なら、商品代金の合計は九千円です。送料や税などを別に加える設定がある場合は、その分を区別して確認します。金額が一致しなければ、どの設定で増減しているかを先に調べ、説明文だけを合わせてごまかさないようにします。

回数上限の確認も、閲覧した回数ではなく完了セッションを基準にします。リンクを開いただけ、途中で戻った、支払いを完了した、という状態を区別して記録すると、想定する数え方との違いを探しやすくなります。上限後のメッセージが分かりにくい場合は、販売が終了したことと、問い合わせの方法が伝わる案内を検討します。

完了後の移動先を、納品機能と取り違えない

Payment Linksでは、支払い後の確認メッセージを編集したり、指定したページへ移動させたりできます。ただし、完了画面に移動しただけで、配送やファイルの受け渡しが自動で完了するわけではありません。提供の自動化には別の連携などが必要で、この記事では手動確認と提供記録を分けて扱います。支払い後の確認動作と提供の自動化

例えば購入後のページに、商品を受け取るまでの流れを載せることはできます。しかし、秘密にしたいファイルを誰でも開けるURLへ置いて、そのリンクへ移動させるだけでは、購入者以外への共有や閲覧を防げません。限定配布が必要なら、認証やアクセス制御を含めた提供方法を別に設計し、その部分まで確認してから販売します。

確認メッセージの文面では、事実として確認できることを伝えます。「お支払いを確認後、案内した方法で提供します」とする場合も、管理者側でどの状態を確認するかが決まっていなければ運用できません。手動で対応する時間や休日を踏まえ、購入者へ約束する連絡時期と日々の確認作業を合わせます。

テストを通過した範囲と、本番で再確認する範囲を残す

サンドボックスで確認できたことを、本番の審査やすべての決済手段の利用可否が確認できたことへ広げないようにします。本番へ案内する前には、対象アカウントの状態と、本番リンクの商品、価格、必要な入力、案内ページ、終了時の扱いを改めて照合します。テスト用のデータが入った案内を公開しないことも確認項目です。

画面や機能は変わることがあるため、テスト票には結果だけでなく確認日を残します。商品を変えた、数量の制限を変えた、案内ページを移した、といった変更があれば、関連する箇所を再点検します。全部を何となく見直すより、変更した設定と影響を受ける表示を結び付ける方が、抜けを探しやすくなります。

共有先を記録し、販売終了時にリンクを無効化する

リンクを配る前に、どこへ載せるかを一覧にする

同じ決済リンクは、メール、案内ページ、QRコードなど複数の場所で案内できます。公式には、リンクのコピー、QRコードの作成、ウェブサイトの購入ボタンに関する案内があります。まず少数の配布先から始め、どこに何を載せたかを自分で把握できるようにします。決済フォームへのリンクを共有する

配布先を増やすと、商品条件を変えたときに直す場所も増えます。リンクそのものが同じでも、メールには旧価格、紹介ページには新価格、紙の案内には古い提供時期が残ることがあります。決済画面が正しいからといって、その前に見た説明との食い違いが消えるわけではありません。共有先の説明文も管理する対象に含めます。

表は横にスクロールできます。

個人情報を付けたURLを共通リンクとして配らない

共有用のリンクは、送信前に余分な情報が付いていないかを確認します。自分の作業用メモや、購入者の氏名、メールアドレスなどをURLへ埋め込み、そのまま広く共有しないようにします。URLは転送や履歴に残ることがあり、相手だけに見える秘密の連絡欄として扱えません。

配布先を見分けるための記録が必要なら、まず台帳へ掲載場所とリンクを残す方法から始められます。解析のための設定を追加するときも、何を識別したいのか、情報をどこへ渡すのかを理解してから選びます。仕組みを知らないまま、購入者の情報を識別子にすることは避けてください。

メールの文面では、何の商品へのリンクか、購入が一回限りであること、価格と提供の案内を簡潔に示します。架空例なら「印刷版ワークブックの単発購入ページです。商品内容と発送の案内をご確認のうえ、お手続きください」と書けます。販売条件が未確定なのに、リンクだけを先に送り、支払い後に説明を追加する進め方は避けましょう。

QRコードを紙面へ載せる場合は、読み取った先の商品と紙面の表示を照合します。周囲の文字や余白が読み取りを妨げないかも確認しますが、読み取れたことだけで十分とは限りません。別のリンクを印刷していないか、テスト環境へ進んでいないか、停止後にどの案内が出るかまで確認しておきます。

販売終了は、元のリンクを止めて確かめる

公式資料では、QRコード自体に有効期限はないと説明されています。基になる決済リンクを無効にすれば、そのQRコードから購入することもできなくなります。紙を回収しきれない場合や、メールを取り消せない場合も想定し、配布済みのリンクを停止する方法を準備します。QRコードとリンクの無効化

決済リンクは作成後に削除するものではなく、無効化して購入を止める仕組みです。ダッシュボードで対象のリンクを特定し、無効化した後、実際の配布先から開いて購入できない状態になっているかを確かめます。似た名前のリンクが複数ある場合は、名称だけで選ばず、商品と識別情報を照合して誤停止を防ぎます。リンクを無効にする方法

リンクを無効にすることは、過去の支払いを返金したり、取引履歴を消したりする操作ではありません。既に購入した人への提供が残っていれば、その対応は続きます。販売をやめることを決めた際には、新しい購入を止める作業と、支払い済みの注文を整理する作業を別の一覧にします。

終了時の案内は、理由を詳しく書き過ぎなくても、現在購入できないことと、既に購入した人の問い合わせ先が分かれば役立ちます。別商品へ案内する場合は、同じ内容を同じ条件で受け取れるかのように見せないよう注意します。停止前の説明が残る配布先には、可能な範囲で販売終了の表示を追加し、古い案内を見た人が迷わないようにします。

販売を再開する場合も、以前のリンクがそのまま現在の条件に合うとは限りません。価格、商品の版、数量、提供方法、開示ページを再確認し、配布先の説明との一致を確かめます。停止の記録に再開の確認日を加え、過去の条件と現在の条件が混ざらないようにすると、問い合わせ時にも説明しやすくなります。

支払い・提供・返金・入金を分けて照合する

購入者の完了画面だけで、提供を確定しない

支払い後の確認は、購入者が見せた画面だけで済ませず、Stripeのダッシュボードにある対象の支払いを確認します。リンクや商品、金額、通貨、状態を照合し、その支払いに対して何を提供するかを記録します。購入の手続きが完了したことと、代金が確定していることを同じ言葉で扱わないようにします。支払いを追跡する方法

特に、決済の確定まで時間のかかる手段を利用する場合は、セッション完了と支払い確定の違いに注意が必要です。この記事では国内のカードによる単発購入の例を中心にしていますが、別の支払い方法を追加する際は、その方法の公式案内を確かめて、提供を始める条件を見直します。支払い手段を増やしただけで、確認の運用まで同じでよいとは考えません。

同じ人から似た金額の支払いが複数見つかったときも、名前だけで一件にまとめないようにします。再購入なのか、操作の重複なのかは、支払いの識別情報と本人の問い合わせを照らして確認します。判断できないものを、売上を増やすためにそのまま提供済みへ進めるのではなく、確認待ちとして残します。

表は横にスクロールできます。

手数料は、今回の条件で一件ずつ点検する

日本の標準料金では、カード決済の成功一回あたり三・六パーセントが案内されています。Payment Links自体は標準のPayments利用時に追加手数料なしで含まれますが、決済処理まで無料になる意味ではありません。通貨換算や、別の商品・オプションを使う場合には条件が変わります。すべての決済手段へ同じ率を当てはめないでください。Stripeの日本向け料金体系

説明用に、国内の標準カード単発決済で、支払額が三千円、通貨換算・追加商品・返金・その他の調整がないと仮定します。三千円に三・六パーセントを掛けると、決済処理手数料は百八円です。三千円から百八円を差し引いた額は二千八百九十二円になります。これは、この仮定の控除計算であり、商品の原価を引いた利益や銀行着金の保証ではありません。

同じ条件の支払いが十件なら、支払総額は三万円、手数料合計は千八十円、控除後の合計は二万八千九百二十円です。数量三個を一回で購入し、商品代金九千円を支払う同条件の例なら、手数料は三百二十四円、控除後は八千六百七十六円です。いずれも端数の出ない架空例で、実際には各取引の明細を正として照合します。

表は横にスクロールできます。

Stripe Tax、独自ドメイン、決済後の請求書など、別の商品やオプションの利用を検討する場合は、それぞれの料金を確認します。この記事の控除計算には、それらの費用を入れていません。利用する項目が増えたら、手数料の欄を一つにまとめて記憶するより、明細で何に課金されたかを確認できる記録にします。

返金した取引と、残る手数料を分ける

返金が必要になった場合は、対象の支払いを特定し、理由と金額を確認します。リンクの停止だけでは返金されません。標準料金の公式FAQでは、元の取引の決済処理などの手数料は返金されないと案内されています。顧客への返金額と、販売者側に残る費用を同じものとして扱わないようにします。料金体系の返金に関するFAQ

例えば前の架空例で、三千円の支払いに対して全額返金を行い、元の決済処理手数料百八円が戻らず、ほかの費用や調整がないとすると、その取引の差引はマイナス百八円です。実際の残高や銀行入金にはほかの取引も影響するため、この一件の計算だけで、アカウント全体の残高を判断しないでください。

返金の操作が受け付けられたことと、購入者の明細へ反映されたことも別です。公式資料は通常五〜十営業日程度の反映と、残高不足などで保留になる場合を案内しています。相手へ「今すぐ明細に戻ります」と確約せず、確認できた処理状態と案内できる目安を分けます。返金のタイミング

解析の集計値を、リアルタイムの注文台帳にしない

リンクの解析では閲覧数や売上件数などを確認できますが、データは最大十八時間遅延する場合があり、サンドボックスでは利用できません。数字がすぐ増えないことだけで支払いがないと判断したり、集計値から現在の在庫を断定したりしないようにします。日々の提供判断は、対象の支払いと提供記録を照合して行います。決済リンクの指標

銀行への入金は、支払いの一覧とは別に、残高や入金スケジュール、実際の入金履歴を確認します。アカウントの条件や保留、返金などが関係するため、「購入から必ず七日後に着金する」と予定を固定しません。複数の支払いがまとめて入金される場合も、どの明細と結び付くかを確認してから帳簿へ反映します。日本向け開始ガイドの入金確認

日々の点検では、未確認の支払い、支払い確認後に提供していない注文、返金の保留、銀行入金の不一致をそれぞれ拾い出します。金額が合わないときは、期間と通貨、返金の有無、手数料、集計の遅れを分けて確認し、単に合計だけを手入力で合わせないようにします。調べた結果と確認日を残せば、同じ疑問を繰り返し追いかけずに済みます。

Stripe Payment Linksを使う際は、リンクを作るだけで終わらず、どの条件で販売し、どこへ共有し、何を見て提供し、いつ止めるかまでを一組で用意しましょう。用途判定票、設定台帳、入力と案内の対応表、テスト票、配布台帳、取引の照合表がそろうと、小さな単発販売でも確認する場所が明確になります。未確認の条件を残したまま配るより、説明と画面、記録がそろったリンクから案内することが大切です。