多通貨対応の旅行予約サイト、利益はどこで漏れるか

リヤドのサブエージェントから、検索画面ではSAR建てだったのに請求書がAEDになっている、と問い合わせが来る。調べてみると、どちらの数字も間違っていない。運賃は仕入先がある通貨で建て、旅行者には別の通貨で表示され、カードが通った時点で三つ目の通貨で決済された。誰もミスをしていないのに、手元に残る金額だけが足りない。多通貨対応の旅行予約サイトが静かに利益を落とすのはこの隙間で、犯人が為替レートそのものであることはまずない。効いているのはその下にある丸めの規則と、見積もりから決済までのあいだのリスクを誰が持っているのか、という答えの出ていない問いのほうだ。

通貨は二系統、お金が動くのは片方だけ

国境をまたいで売る店は、必ず二つの通貨系統を同時に走らせている。これを一つだと思い込むことが、混乱のほとんどの根にある。

表示通貨は旅行者が読む数字である。これは表示層にすぎない。当プラットフォームではホワイトレーベルのサイトごとに既定通貨と提示する通貨リストを選び、価格はテナント単位のレート表を使ってクライアント側で換算される。この一点は聞こえよりも重い。画面上の数字は導出された値であって、ページが描画された瞬間の仕入価格に自社のレートを掛けただけのもの、つまり誰も保持を約束していない価格だ。

決済通貨は実際にお金が動く通貨である。仕入先が請求してくる通貨、ゲートウェイが捕捉する通貨、銀行明細に載る通貨、そして払い戻しが出ていく通貨。ふつうは仕入先ごとに一つ、ゲートウェイごとに一つあり、その二つが同じとはかぎらない。

代理店が「AEDとSARとUSDで売っている」と言うとき、実態はほぼ常に「三通貨で表示し、一通貨で決済している」である。商売としてはまったく健全で、多くの店がそう回している。壊れるのは、下流のどこかが表示価格を約束として扱った瞬間だ。払い戻し、サブエージェントへの精算書、チャージバックの応酬。表示価格は約束ではなかった。描画結果だった。

多通貨の予約サイトで為替リスクを負うのは誰か

旅行者が価格を見てから入金が確定するまでのあいだ、必ず誰かが動きうるレートに晒されている。問うべきは、その晒しが存在するかどうかではない。誰のものか、そして本人が自覚しているかどうかである。

正直な答えは三つしかない。自社通貨建てでネット料金を契約し、換算を相手に飲ませているなら、リスクは仕入先が持つ。仕入先の通貨で請求してカード発行会社に換算させるなら、持つのは旅行者だ。自社にとって最も清潔で、そして旅行者が最も文句を言う形でもある。明細の金額が確認書の金額と違うからだ。あるいは自社が持つ。レート表を置くとはそういうことで、自社レートと決済日の実勢との差は、どちらに振れても自社のものになる。

三つとも立派に成立する。避けるべきは、誰も決めていない四番目の状態だ。レート表は思い出した人が更新し、ポジションは一四半期あとの照合で発見される。所有者と更新頻度を一文で言えないなら、いまその四番目にいる。

丸めは書式の問題ではなく価格の決定である

多くのエンジンは丸め幅の既定値を0.01にしている。十進通貨の見た目がそうだからだ。旅行には四つの理由で向かない。

第一に、すべての通貨が補助単位を持つわけではない。日本円と韓国ウォンは持たない。その市場で小数二桁の価格が出ていれば、それはソフトウェアの都合が漏れた跡にしか見えないし、存在しない単位に対して0.01刻みで丸めるのは算術として空回りしている。

第二に、換算された価格は換算されたように見える。1,236.47という数字は掛け算の出力だと自分から名乗っている。読んだ旅行者はその裏にもう一つ数字があることを理解し、次にやることはそれを他所で探すことだ。きりのよい刻みに落ちた価格だけが、自社の価格として読まれる。

第三に方向がある。最近接への丸めは対称で、誤差は数量の中で打ち消し合い、利益率は動かない。常に切り上げれば毎回わずかに乗せ、常に切り捨てれば毎回わずかに渡す。どれも方針であり、選んだのなら問題はない。事故なのは、選んでいないのに片方に寄っていて、ある市場の粗利だけがなぜか少し低いと後で首をかしげることだ。

第四が演算の順序で、実際に噛みついてくるのはこれである。換算し、マークアップを乗せ、最後に一度だけ丸める。換算時にネット運賃を丸め、マークアップ後にもう一度丸めるエンジンは二度丸めており、二度目は端数をすでに失った数字に対して適用されている。運賃・税・付帯サービスを別部品として建てるとこれが積み上がり、合計が部品の和と一致しなくなる。これは価格の問題である前に照合の問題だ。

部品ごとに丸めるか、合計を丸めるか。どちらかにして、両方はやらない。そして請求書に出る数字は、サブエージェントが表計算に打ち込んだときに必ず足し合うようにしておく。彼らは必ず打ち込む。

運用の型は三つ

下の三つは機能のグレードではない。「旅行者に何を約束するのか」への三つの異なる答えであり、背負う作業量が違う。

ほぼ全員が左の列から始め、手をかける価値が出た市場だけを一つ真ん中へ動かせばよい。右の列は技術の衣を着た業務上の決断である。いま社内で二つの元帳を突き合わせている人がいないなら、通貨を増やしたところでその習慣は始まらない。

間違えたときに払う代償

典型は払い戻しだ。あるレートで売られた予約が六週間後に取り消され、エンジンが手元に持っていた今日のレートで返金される。レートが旅行者に有利に動いていれば差額は自社負担、逆に動いていれば旅行者は値切られたと思い、そしてその感覚は完全には間違っていない。販売時点のレートを予約に保存し、それに対して返金すること。

静かなほうは与信である。サブエージェントの与信枠と精算請求は、当プラットフォームでは表計算ではなく一級の機能として存在する。ただしそれが効くのは、枠がそのエージェントの実際に売っている通貨で建っている場合だけだ。SARで売る相手にUSDで枠を置けば、レートが動くたびに枠も漂い、そのズレが見つかるのはたいてい最悪の瞬間、つまり空港で発券が止まった瞬間になる。

そして遅いほうの損失。古いレート表はエラーを出さない。売れてしまう。数週間は一つの市場で妙に調子がよいように見え、月が締まったところで、その数量が気づかずに配っていた値引きだったと判明する。レート表に日付と担当者を貼っておけという話の根拠はここにある。誰も読まないcronではなく。

市場を一つ開く前に

ここまでのどれもプロジェクトを必要としない。必要なのは、通貨がセレクタに現れる前に、この順で書き留められた決定である。

• その市場の決済通貨と、それが適用される仕入先とゲートウェイを名指しする。一文で。
• レート表を誰がどの頻度で更新するかを決め、最終更新日を人間の目に入る場所に出す。
• 丸め幅は通貨ごとに選ぶ。全体で一つにしない。補助単位のない通貨は別に確認する。
• 順序が「換算、マークアップ、最後に一度だけ丸め」であることと、部品価格の和が請求書の合計と一致することを確かめる。
• 払い戻しが今日のレートではなく保存された販売日レートを使うことを確かめる。
• サブエージェントの与信枠と精算請求が、そのエージェントの読む明細と同じ通貨であることを確かめる。

そのうえで開き、二週間売り、その二週間を一度だけ手で照合する。最初の市場は、上の六つのうちどれを取り違えていたかを教えてくれる装置である。

通貨の挙動は、店の中でもっともデモしやすく、もっとも監査しにくい部分だ。だから設計を固める前に実際の設定画面を見ておく価値がある。標準で何が載っているのか、通貨リスト、レート表、マークアップが住んでいる管理画面を確かめたいなら、ウィザードから一つ立ち上げてみるとよい。プラットフォームのサブドメイン上に用意され、カード番号は訊かれない。そもそも他社のエンジンに乗るかどうかを迷っている段階なら、ホワイトレーベルと自社開発の比較がこの記事の下にある議論であり、残りの面はホワイトレーベルで実際に何が手に入るかで扱っている。

為替レートは公開情報である。丸めの規則と、返金に使うレートと、更新の頻度は公開されていない。国境をまたぐ予約の利益が本当に決まっているのは、その三つのほうだ。