店頭での暗号資産決済の受け入れ
店頭での暗号資産決済とは、カウンターに立つ顧客がUSDCのようなステーブルコインやBTCのようなコインで支払い、加盟店であるあなたにはユーロで入金される仕組みです。顧客が送る資産と、あなたが受け取るお金は別のもので、タップの瞬間に確定するレートがその二つをつなぎます。レジも帳簿も銀行口座も、暗号資産が関わったことを知る必要はありません。端末にはユーロの価格が表示され、顧客がコードを読み取り、数秒後には売上がユーロで確定します。カード決済と同じ行に計上されます。店頭の暗号資産決済は、会計の変更ではなく決済手段のひとつです。そのままの形で提供することが、エンジニアリング上の課題のすべてです。
最初にこの考え方を押さえておくのは、暗号資産決済をめぐる混乱の多くが、本来分けておくべき二つの問いを混同することから生じるからです。その二つとは、顧客がどう支払うか、そして加盟店がどの通貨で受け取るか、です。二つを切り分ければ、以降の話は自然につながります。
本当に解決すべき課題
加盟店が求めているのは売上であって、価格変動ではありません。一日の終わりに価値の定まらない資産を抱えたくはありませんし、経理担当者に突然二つの通貨を扱わせたくもありません。タップからレシートまでの間は価格が固定され、入金はユーロで、照合はいつものカードの一日と変わらないことを望んでいます。暗号資産を素朴に受け入れる店舗では、そのどれも得られません。顧客が迷っている間にも価格が動く資産を受け取り、ウォレットに置いたまま、帳簿には第二の通貨が加わります。その評価や換算を、誰かが手作業で行うことになります。そこで設計目標は、狭く厳格なものになります。暗号資産が見えるのは決済の瞬間の一か所だけにして、それ以外のあらゆる場所では見えないようにすることです。
ワンタップ：QR、固定レート、ユーロの一行
カウンターでの流れを見てみましょう。レジ担当者が €24.00 の買い物を会計します。端末にはユーロの合計額が表示され、リクエストをエンコードしたQRコードが生成されます。コードには、金額、宛先アドレスまたはインボイス、有効期間の短いレートIDが含まれます。顧客は自分のウォレットでそれを読み取り、送金内容をそのまま確認して承認します。端末はネットワーク上でその送金を監視し、確認が取れた時点でユーロ建てのレシートを発行します。レジ担当者から見ると、リズムはカードと変わりません。合計、提示、承認、レシートです。カウンターの内側で、アドレスを入力する人も、ユーロ以外の残高を読む人もいません。
リクエストをQRコードの中に収めることで、見知らぬ人のスマートフォンに安全に渡せるようになります。金額と宛先はチェックサム付きでコードに含まれるため、顧客が入力ミスで誤ったアドレスや金額に送金することはありません。回収側の「構造的に特定される」仕組みと同じ考え方を、カウンターに応用したものです。読み取れるコードは正しいコードであり、間違える余地のある自由入力欄はありません。
ユーロで精算し、帳簿に暗号資産を持ち込まない
顧客が送る資産と加盟店が受け取るユーロの間には換算が入ります。そして、その換算をどこで行うかが要点です。顧客はUSDCやBTCを送り、プラットフォームが換算して加盟店の口座にEURで入金します。資産は加盟店が管理するウォレットに残されず、プラットフォーム側で換算されるため、加盟店の元帳に載るのはユーロの入金とユーロの手数料行だけです。カード精算と同じ形になります。一日の終わりには、帳簿は最初から最後までユーロです。評価替えが必要なコインの束も、会計上の第二の通貨も、月曜の朝に出金しなければならない資産もありません。
顧客の役割は、手持ちの資産で支払うことです。加盟店の役割は、帳簿を一つの通貨で保つことです。暗号資産をユーロで精算するPOSは、この二つの事実を決して交わらせないための仕組みです。
レートは追いかけず、固定する
懸念されるのは価格変動ですが、その答えがカウントダウン付きの固定レートです。端末がユーロの価格を表示するとき、同時に、数秒間という明示された有効期間を持つレートを確定させます。顧客はその期間内に、そのレートで支払います。加盟店に入金されるユーロは画面に表示された金額であり、ウォレットの読み込み中に相場がどう動いたかには左右されません。顧客が承認する前に有効期間が切れた場合、端末は再度レートを提示します。新しいコード、新しいカウントダウン、そして明示された新しい価格です。知らないうちに価格がずれることはありません。タップから承認までの値動きのリスクを加盟店が負うことはなく、そのリスクはレートを確定させた側が負います。コーヒーを一杯売りたいだけの店主が負うものではありません。
顧客の操作が遅いとき、端末がオフラインのとき
ネットワークは滞ることがあり、店舗の接続が切れることもあります。そのため、オフライン時の挙動は意図的に地味なものにしなければなりません。ケースは二つあります。顧客の操作が遅い場合は、レートが失効して再提示されるだけです。決済は有効期間内に確定するか、成立しないかのどちらかで、中途半端な売上を取り消す必要はありません。端末自体がオフラインになった場合、金額が決まっているリクエストは表示できますが、新しいレートの確定も精算の確認もできません。そのため売上は保留として保持し、成功を装わずに、再接続した時点で照合します。基本原則は、レシートは期待ではなく確認が取れた時点で発行することです。ユーロのレシートは、そのユーロが帳簿上で確かに把握されていることを意味します。端末が確認できなかった売上は、消えてなくなるのではなく、未完了のままオペレーターコンソールに表示され続けます。
端末とゲートウェイの接点
カウンターは、オンラインで稼働しているものと同じ決済受け入れスタックの、対面での入口です。カード提示型の暗号資産タップとリンク決済のチェックアウトは、内部では同じ出来事です。リクエスト、支払い、ユーロでの精算、レシートという流れを、異なる画面で見せているだけです。そのため加盟店は、店頭の暗号資産決済とオンライン注文を、同じ手数料行と同じエクスポートで、ユーロのまま一か所で照合できます。月末に二つの帳簿をつなぎ合わせる必要はありません。端末は /products/pos、同じ基盤のオンライン側は /products/gateway にあり、レート、精算、アクワイアラー、照合といった用語は /glossary で定義しています。
率直な境界線
カウンターで暗号資産を使いたい人がいないなら、暗号資産対応の端末は、存在しない問題への解決策です。カードを受け付ければ十分です。暗号資産端末が役立つのは、顧客の一定数がすでにデジタル資産を保有していて、先にオフランプするより、そのまま使いたいと考える場面です。特定の旅行ルートや、オンラインネイティブの客層、ステーブルコインが日常的な使えるお金の持ち方になっている地域などがそうです。そうした場では、タップを断ることは、売上を断ることになります。ここまで述べたQR、固定レート、ユーロでの精算、確認してからレシートを発行するルールがあれば、価格変動も、第二の通貨も、経理の大がかりな作業も抱えずに、その売上を受けられます。暗号資産は顧客の側の事情であり、ユーロはあなたのものです。