実際に貼り付けるもの
チェックアウトボタンはダッシュボードで一度だけ設定します。金額、資産、チェーン、そして支払い後に顧客をどこへ送るかです。ページに貼り付けるのはこれだけです:
<a href="https://pay.unheld.io/pay/btn_8f2c41"
style="display:inline-block;padding:12px 20px;border-radius:8px;background:#3B37F0;color:#fff;font-weight:600;text-decoration:none;font-family:system-ui,sans-serif">
Pay with crypto
</a>これが実装のすべてです。アンカータグ1つです。
なぜスクリプトではなくリンクなのか
公開ページ上のスニペットは秘密鍵を持てません。誰でも読めてしまうからです。そこでボタンが持つのは推測できない公開IDだけで、請求書はクリックされた時点でサーバー側で作成されます。あなたのアカウントに関する情報がストアフロントに露出することはなく、ページを遅くしたり壊したりするスクリプトも、更新し続けるライブラリもありません。
顧客がクリックすると何が起きるか
4つのステップ。どれもあなたのサーバー上では動きません。
- 01
ホスト型のチェックアウトに移動する
リンクは保存された設定から請求書を作成し、当社がホストする決済ページへ顧客を送ります。あなたが決済フォームを描画したり、金額を隠しフィールドに保持したり、ブラウザから返る値を信用したりする必要はありません。
- 02
どのウォレットからでも支払える
資金はあなた自身のウォレットから導出されたアドレスへ届きます。当社を経由しないため、引き出すべき残高も、待つべき入金もありません。
- 03
あなたの参照情報が一緒に返る
ボタンには独自のフィールドを付けられます。注文番号、カートID、ショップで使っている値なら何でも構いません。それは支払いを通じて運ばれ、ウェブフックで返ってくるので、金額を突き合わせなくてもどの注文が支払われたかわかります。
- 04
顧客があなたのサイトへ戻る
ボタンごとに成功時とキャンセル時のURLを設定できるので、顧客は当社のページに取り残されるのではなく、あなたの注文確認ページへ戻ります。
注文が支払われたことを知る
イベントは通常の請求書イベントです。チェックアウトボタン経由の支払いは普通の請求書であり、中途半端に対応された別系統の仕組みではありません。
- invoice.created
- invoice.receiving
- invoice.confirming
- invoice.paid
- invoice.underpaid
- invoice.overpaid
- invoice.expired
すべてのウェブフックには署名が付き、失敗すれば再送され、ボタンに付けた参照フィールドを運びます。発送は、支払いが最初に検出された時点ではなく、確定のイベントを待ってから行ってください。その2つの違いこそが、承認数の存在理由です。
連携のしくみ
連携はリンク1本です。それが何をどこまで担うのかを正確に書きます。着手前に作業量を見積もれるように。
- Shopify専用アプリもWooCommerceプラグインも、まだありません。連携は上のリンクで、プラットフォームがHTMLを置ける場所ならどこにでも貼れます。どのプラットフォームでも置けます。専用プラグインは開発予定です。
- カートとの連携はありません。ボタンは設定した金額を運ぶので、合計が変動するカートには保存済みのボタンではなくAPIが必要です。
- 出荷済みの記録が自動で付くことはありません。ウェブフックは特定の注文が支払われたことをあなたのシステムに伝えます。それをどう扱うかはショップ側の仕事です。
- 当社経由の返金はありません。資金を保有していないからです。返金は、あなた自身のウォレットから、あなたの条件で行う支払いになります。
- 顧客には暗号資産のウォレットと、その中の資金が必要です。これはすでにウォレットを持っている買い手に届く手段であって、持っていない人を変えるものではありません。
質問
今の決済事業者から乗り換える必要がありますか。
いいえ、そうすべきでもありません。これはすでに提供している支払い方法の隣に選択肢を1つ加えるものです。カード決済はそのままで、これまでどおりの顧客に対応し続けます。多くのショップにとって暗号資産は注文全体のごく一部です。移行ではなく追加として扱うことが、正直な捉え方であると同時に、売上を危険にさらさない捉え方でもあります。
Shopify、WooCommerce、あるいは私のプラットフォームで使えますか。
HTMLを貼れる場所ならどこでも使えます。多くのプラットフォームがそうです。商品ページ、ランディングページ、メールの署名欄などです。存在しないのは、それらのためのネイティブアプリやプラグインです。ですからカート合計の自動反映も、管理画面への注文状態の書き戻しも、ワンクリックのインストールもありません。それらが必要であれば、まだお使いいただける段階ではありません。
毎回合計が変わる注文はどうすればよいですか。
保存済みのボタンは固定の金額を運ぶため、変動するカートにはチェックアウト時にAPIで請求書を作成する必要があります。リクエスト1回で、顧客を送る決済URLが返ります。ボタンは固定価格の商品向けで、それ以外はAPIの領域です。
注文を発送してよいのはいつですか。
支払いが最初に検出された時点ではなく、確定のイベントが届いたときです。検出は取引が現れたことを、確定はチェーン上で最終と見なせる深さに達したことを意味します。この2つが別々のウェブフックとして届くのは、顧客にはすぐ「支払いを受け付けました」と示しつつ、現物の出荷は決済が固まるまで保留できるようにするためです。