カードもステーブルコインも。チェックアウトはひとつ。

01すべての決済手段を1ページに

ホスト型チェックアウトでは、カード、Apple Pay、Google Pay、USDCが並んで表示されます。左側には注文9F21-0716（明細3件、手数料€0.50、お支払い額€49.00）、右側には支払方法の選択があります。顧客が選ぶとページが対応し、加盟店の連携は一度きりです。

• カード、USDC、ウォレットのボタンを同じ画面に配置
• 明細、手数料、合計といった注文の全体を決済フォームの横に表示
• 支払方法を問わず、Pay €49.00の1アクションで完了

02同じURLでモバイルにも対応

同じチェックアウトURLが、スマートフォン向けのレイアウトに切り替わります。注文は概要バーに折りたたまれ、支払方法のボタンはそのまま表示され、カードフォームのラベルも維持されます。デスクトップで提供するものは、そのままモバイルでも提供されます。ブラウザではなく自社アプリ内で決済を完結させたい場合は、iOSとAndroidのSDKが、同じ注文に対して同じチェックアウトをネイティブで表示します。

03それだけで内容が分かるレシート

USDCでの支払いは、加盟店の経理担当者がそのまま読めるレシートで完了します。支払方法：Base上の52.95 USDC →︎ EUR決済、レシートに記載されたレート1 EUR = 1.0807 USDC。リファレンスは9F21-0716で、顧客にメール送信され、その場でダウンロードもできます。顧客は暗号資産で支払い、帳簿には€49.00と記録されます。

04リンクだけでなく、リンクのバックオフィスも

ペイメントリンクにも、本格的な管理画面があります。Arc Studio SRLの8件のリンクが支払済み・有効・期限切れに分かれて並び、各行に金額、支払件数、ステータスが表示されます。上部のカードには集計が表示されます。有効なリンクは4件、今月はリンク経由の18件の支払いで€2,304.50を回収、本日の入金は€49.00です。作成、検索、エクスポートまで、この画面で完結します。

• すべてのリンクを、URL、金額、ステータスとともに表示
• 今月の回収額と本日の入金額を最上部に表示
• リンクの作成は、管理しているのと同じ画面で

05注文に対する返金

返金は支払方法ではなく、注文を対象に行います。9F21-0716でドロワーを開くと、金額には全額の€49.00があらかじめ入力されており、理由は必須、任意のメモはエクスポートと顧客のレシートに反映されます。資金は元の決済レールを通じて自動的に戻ります。カード決済はカードへ、USDCの注文はEUR決済分として、通常1〜3営業日で処理されます。

• 全額でも一部でも、元の請求額までの任意の金額で返金可能
• 理由は必須、メモはレシートに反映
• どちらのレールでも、元の経路で自動的に取り消し

06お客様のチェックアウトを、お客様らしく

ブランディングは、開発支援の依頼ではなく設定ページで行えます。ロゴをアップロードし、アクセント、インク、サーフェスの各カラーを設定し、書体と角の形状を選ぶだけです。保存前に、実際のチェックアウト（デスクトップまたはモバイル）がライブプレビューで表示されます。アクセントカラーは、支払いボタンのフォーカス、ステータスのチェック、アクティブなタブに反映されます。サンドボックスに発行されるチェックアウトホストでも、お客様自身のドメインでも運用できます。

07作らずに、切り替えるだけの支払方法

支払方法は、背後にプロバイダーを持つトグルです。3-Dセキュア対応のカード、ウォレットボタンとしてのApple PayとGoogle Pay、Ethereum・Base・Solanaに対応したUSDC、vIBANリファレンスによるSEPA銀行振込を用意しています。その横の決済パネルには、条件が分かりやすく示されています。顧客は確定前に換算内容を確認でき、加盟店は常にEURで決済を受け取ります。

• 支払方法ごとのトグルと、各行に表示されるプロバイダー名
• USDC決済：自動換算、毎日23:00に払い出し
• 3-Dセキュアのポリシーを確認できるカードルーティング

08ドロップイン連携

注文を作成し、ホスト型ページにリダイレクトして、結果を受け取るだけです。決済UI、支払方法のロジック、レシートはGatewayが担います。支払方法の変更に合わせて、チェックアウトのフロントエンドを開発、修正、保守する必要はありません。

09単位は、注文

すべては支払方法ではなく、注文に紐づきます。注文9F21-0716には、明細（ブランドアイデンティティ・スプリント€38.50、書体ライセンス€6.00、特急納品€4.00）、手数料€0.50、そして1つの合計が含まれます。どの方法で支払われても、照会、照合、返金の基準になるのはこのリファレンスです。

10セッションを乱さない設定

支払方法やブランディングの変更は、新しいチェックアウトセッションから適用されます。この点は、保存する画面にも明記されています。支払い途中の顧客の画面が、操作中に変わることはありません。

11カード決済を、きちんと

カード決済は地味ですが重要な部分であり、しっかり対応しています。入力時のインライン検証、分かりやすいルーティングポリシーのもとでフローに組み込まれた強力な顧客認証付きの3-Dセキュア、そして連携テスト用のサンドボックスごとのテストカード。暗号資産に対応しても、カード決済の体験が損なわれることはありません。

12Apple PayとGoogle Pay

ウォレットは、プロジェクトではなくボタンです。Apple PayとGoogle Payは同じページにワンタップのシートとして表示され、デバイストークンで支払います。実際のカード番号がページに渡ることはなく、注文もレシートも同じです。有効化は、支払方法画面のトグルひとつです。

13USDCをEURで決済

暗号資産は、チェックアウトで提示されるレートで価格が決まり、ユーロで決済されます。加盟店が意図せずトークンのポジションを抱えることはなく、帳簿も単一の通貨で維持されます。

143つのネットワークでUSDC

USDCの支払方法は、Ethereum、Base、Solanaにまたがり、トグルひとつで切り替えられます。顧客はウォレットのあるネットワークで支払い、加盟店側の運用は変わりません。

15vIBANによる銀行振込

振込払いにはvIBANリファレンスが付くため、着金したSEPA送金は構造上、どの注文のものかが特定されます。銀行から支払える請求書を求める顧客向けに有効にしておけば、照合は自動のままです。

16必要な場所に、ローカルな支払方法を

カードやウォレットに加えて、欧州の購入者が期待する口座間決済やローカルな支払方法にも対応しています。一覧を長く並べるのではなく、顧客の国に合わせて表示します。

17後払い（BNPL）

BNPLも他の支払方法と同じ行に並びます。顧客は支払いを分割し、加盟店への入金は一度で、注文リファレンスも変わりません。トグルひとつで、レシートも照合も同じです。

18顧客に合わせて並ぶ支払方法

ページは、国、言語、デバイス、過去にお支払いいただいたことがあるかどうかなどから、顧客が使いそうな順に支払方法を並べます。関連性の高い選択肢が、4番目ではなく先頭に表示されます。

19顧客の通貨で表示し、御社の通貨で決済

金額は顧客の通貨で表示し、確定前に換算内容を明示したうえで、決済は常にEURで行います。顧客には見慣れた金額が表示され、御社の元帳は1つの通貨で保たれます。

20顧客の言語で表示するチェックアウト

ホスト型ページは、ラベル、エラーメッセージ、レシートを各言語にローカライズします。ボタンの言語が違うという理由で、支払いを離脱する人はいません。

21保存済みカードとワンクリック決済

再訪した顧客は、保存済みのカードでワンタップで支払えます。カードは当社側で保管され、トークンで参照されるため、御社のシステムが保持するのは参照情報のみで、PANを持つことはありません。2回目の購入は、1回目より短い手順で完了します。

22サブスクリプションと定期課金

定期課金は、金額、間隔、開始日、終了日を定義したスケジュールに沿って、トークン化されたカードに対して実行されます。サイクルごとに専用の注文とレシートが生成されるため、サブスクリプションも他の取引と同様に、1件ずつ照合できます。

23売上を取り戻すリトライ

定期課金のソフトデクラインは、損失として処理せず、スケジュールに沿って再試行します。顧客への通知は、本当に必要なときだけです。更新の失敗が、気づかれない解約につながることはなくなります。

24ネットワークトークンとカード情報の更新

保存されたカードはネットワークトークンとして保持され、再発行や有効期限の更新後もカード会員に追従します。カードの交換で止まっていたサブスクリプションも、課金を継続します。

25APIと開発者向けセクション

注文はAPIで、冪等キーとともに作成します。再試行したリクエストは、二重請求されることなく元の結果を返します。キーとドキュメントは開発者向けセクションに用意されています。チェックアウトはホスト型で、連携に必要なのはいくつかのエンドポイントだけです。ドキュメントは、設定画面と同じ場所にあります。

26注文ライフサイクルのWebhook

バックエンドは、決済が発生した瞬間にその内容を受け取れます。支払済み、失敗、返金済みといった注文ライフサイクルの署名付きWebhookイベントを送信し、署名の検証は御社側で、リプレイ対策は当社側で行います。

27iOS・Android向けモバイルSDK

ネイティブアプリでは、ユーザーをブラウザへ誘導せず、アプリ内で同じチェックアウトを表示します。SDKが支払方法のロジック、ウォレットのシート、3-Dセキュアを担い、注文とレシートは、御社のバックエンドがすでに把握しているものと同一です。

28現在お使いのプラットフォーム向けプラグイン

ショッピングカートのプラグインを使えば、開発者なしで既存のストアをGatewayに接続できます。インストールし、キーを貼り付け、テスト決済を行うだけです。API経由の注文と同じ注文が、同じバックオフィスに表示されます。

29自社ページに埋め込める入力フィールド

決済を自社のレイアウト内で行う必要がある場合は、決済フィールドを直接埋め込めます。入力欄は当社側でホストされPCIの対象範囲に収まり、周囲のページは完全に御社のものです。カードデータが御社のサーバーを通ることはありません。

30単発・複数回・有効期限

リンクは1回の支払いで終了することも、受け付けを続けることもできます。デモのワークショップ枠はこれまでに3件、相談1時間枠は6件の支払いを受けています。リンクの有効期限は既定で30日。期限切れのリンクは、何も言わずに失敗するのではなく、期限切れであることをきちんと表示します。

31テストモード

連携のテストは、サンドボックスキーとあわせて発行されるカードを使い、テストセッション上で実行します。実際の資金が動く前に確認できます。フローは本番と同一なので、テストで通ったものがそのまま本番に出ます。

32読み解けるルーティング

カード取引は、ブラックボックスではなく、カードブランド、発行国、通貨、金額といった分かりやすい条件で書かれたルーティングポリシーに従います。どの経路で処理されたかは、支払いを表示する同じ画面で確認できます。

33売上を失う前の、もう一度のチャンス

ソフトデクラインは、顧客に失敗が表示される前に、同じチェックアウトセッション内で別ルートへ再試行されます。回復した支払いの多くは、危うかったことを顧客が知らないままのものです。

34分かりやすい言葉で示すデクライン理由

発行会社の生のコードは、期限切れカード、残高不足、発行会社のリスク判断など、運用担当者が対応できる理由に変換されます。さらにグループ化されるので、複数の支払いにまたがる傾向もパターンとして見えてきます。

35摩擦ではなくポリシーとしての3-D Secure

ほとんどの支払いは、デバイスと行動のシグナルだけで通過します。追加認証は、ポリシー上必要な場合にのみ表示されます。ポリシーは常時、リスクベース、規則上可能な場合は免除から選べ、フローはホスト型ページが担います。

36照合は1行で完結

チェックアウト、レシート、決済は同じ注文リファレンスを共有します。9F21-0716を照合すれば、見つかるのは€49.00の1件のみ。片方のシステムにカード記録、もう片方に暗号資産記録、という状態にはなりません。

37決済と支払い出金

決済条件は、設定する画面にそのまま表示されます。EURへの自動換算、RO49 •••• 0421への決済、毎日23:00の出金。明日、経理担当者が目にする数字は、今日、加盟店が読める画面で決まります。

38さかのぼれる出金

すべての出金は、その原資となった注文まで開いて確認でき、手数料も内訳表示されます。銀行の明細行はエクスポート可能な一覧と一致するため、月次締めは調査ではなく照会で済みます。

39一部返金

返金額は元の請求額まで編集できます。ドロワーには上限額が表示され、それ未満であれば一部返金として扱われます。1件の注文に対して10回の一部返金を行っても、照合は1つのリファレンスで完結します。

40記録に残る返金理由

すべての返金に必須の理由と任意のメモが付き、メモはエクスポートや顧客のレシートにも引き継がれます。半年後に、注文9F21-0716がなぜ補償されたのかを誰かが思い出す必要はありません。

41レシートの送付

レシートは顧客にメールで送信され、その場でダウンロードもできます。返金レシートも同じ経路で届きます。加盟店がレシートのテンプレートを作る必要はありません。

42決済前の取消

その日のバッチ処理前にキャンセルすると、オーソリ保留が解除され、資金は一切動きません。返金も手数料も発生せず、顧客の明細に説明を要する記載も残りません。

43リスク管理は標準で有効

カード決済は、内容を確認できるルーティングポリシーのもとで3-D Secureを実行します。ウォレット決済にはデバイス自身の認証が伴い、Webhookイベントは署名検証を経てから信頼されます。

44自社の言葉で書けるルール

スクリーニングルールは、「国Yからの初回カードで金額がXを超える場合」のように文章として読め、許可、チャレンジ、ブロックのいずれかを実行します。信頼済み・ブロック済みのカード、メールアドレス、住所のリストも同じ画面から管理できます。

45ベロシティとデバイスのシグナル

同一カード、同一デバイス、同一住所からの繰り返しの試行は、後から人が気づくのではなく、レートルールで検知されます。シグナルはスコアに埋もれず、支払いの画面にそのまま表示されます。

46証拠を添えたディスピュート

チャージバックは、背後にある注文とともに開きます。オーソリ結果、3-D Secureの結果、レシート、配送、返金履歴まで確認できます。その画面から回答すれば、証拠資料は記憶ではなく記録から作成されます。

47カードデータは御社に届きません

カード情報を入力するページは、PCIスコープ対象の当社ホスト型ページです。顧客が当社ドメイン、御社ドメイン、アプリ内のいずれで支払う場合でも、御社のサーバーが受け取るのはトークンと注文リファレンスだけで、カード番号は一切届きません。

48保存時に暗号化、EU域内で処理

決済データは保存時に暗号化され、EU域内で処理されます。欧州の加盟店にとって、データの所在は脚注ではなく、きちんとした回答です。

49すべての操作を記録に残す

返金、決済手段の変更、ブランド設定の変更、キーのローテーション。いずれも、操作者、タイムスタンプ、理由とともに監査ログに記録されます。特権操作は、実行前に理由の入力が必須です。

50必要な人に、必要なロールを

経理は出金、サポートは注文と返金、開発者はキーとログを確認できます。1つのログインを共有するのではなく、ロールごとにアクセス権を付与します。

51顧客ディレクトリ

支払者は顧客ビューに蓄積されます。誰が、何回、どの決済手段で支払ったかが分かるので、リピーターはエクスポート上でたまたま一致したメールアドレスではなく、1件のレコードになります。

52検索とCSVエクスポート

リンクやリファレンスから、検索ボックスで支払いを探せます。帳簿が必要とするときは、現在のビューをCSVにエクスポートできます。バックオフィスは、経理担当者から問い合わせが来る前提で作られています。

53日別・決済手段別の数字

取扱高、承認率、返金、決済手段の構成比を、任意の期間で確認できます。お金がどこに動いたのか、どの決済手段を推すべきかは、何もエクスポートせずに分かります。

54その裏側にあるオペレーター向けビュー

Gatewayは Protocore Center と連携します。Center のペイメントリンク用バックオフィスには、すべてのリンクが決済の送金とともに表示され、完全なトレースを確認できる Tracer へのリンクも用意されています。運用チームは、チェックアウトから台帳の底まで見通せます。

55ホワイトラベルまたはPowered-by表示

デモのチェックアウトは Arc Studio SRL のものです。社名もマークも注文も、すべて同社のもの。「Powered by Protocore」のフッターを付けても、完全なホワイトラベルで運用しても、ページは御社のものとして見えます。