商品ページに表示された通貨を、そのまま実際の請求通貨と判断しないでください。BigCommerceの表示通貨と取引通貨を区別し、チェックアウトと注文記録まで一致を確認できる場合に限って検収を完了します。三者に矛盾があれば、流入を広げる前に設定と決済手段を調べてください。

この記事は、複数市場向けの通貨表示を調整する越境販売担当者、買い手から価格や請求通貨について問い合わせを受けた運営担当者、公開前の検収を行う責任者向けです。

最初に分ける指標：表示通貨と取引通貨

BigCommerceでは、active currency が買い手に価格を表示するために使われても、その通貨が決済に使われるとは限りません。チェックアウトで使われる通貨に関わるのは transactional currency です。用語と前提条件は、BigCommerce公式の通貨概要および商品カタログとカートにおける通貨の扱いで確認してください。

商品ページが米ドル表示なら、チェックアウトでも米ドルで請求されますか。
表示価格だけでは判断できません。チェックアウトに表示される通貨と、確定後の注文記録にある通貨情報を照合してください。通貨記号だけでなく、画面上の通貨名や決済前の説明も記録します。

確認対象 買い手側で見るもの 判断に使う証拠
表示通貨 商品ページやカートの通貨名、金額 表示価格の用途。決済通貨とは限りません
取引通貨 チェックアウトの通貨表示、決済直前の金額 選択した決済手段が対応する通貨か
注文通貨 注文記録の通貨関連項目 チェックアウトの表示と矛盾しないか

第一段階：同じ買い手セッションでページをたどる

検収中に地域や通貨の選択を変えると、比較している条件が揃わなくなります。市場入口から商品ページ、カート、チェックアウトへ同じブラウザーセッションで進み、各画面の通貨名、金額、説明文を残してください。

表示価格が現地通貨でも、現地通貨で受け取らない設定かどうかはどう見分けますか。
商品ページの価格だけで決めず、チェックアウトの通貨表示と注文記録を確認します。カタログの標準価格を基準にした表示なのか、為替換算後の表示なのかも、店の設定と画面上の説明を照らして切り分けます。差額がある場合は、標準通貨をすぐ変更せず、価格の基準と換算方法を先に確認してください。

第二段階：割引・税・送料を別々に記録する

商品価格が揃っていても、割引、税、送料を加えた最終金額まで整合するとは限りません。カートとチェックアウトで項目ごとの通貨と金額を記録し、割引適用前後の差、税の表示有無、送料の計算条件を別々に照合します。

金額項目 比較する画面 ずれがあった場合の確認先
商品価格 商品ページ、カート 標準価格か換算表示か、選択中の市場
割引 カート、チェックアウト 適用条件、対象商品、通貨表示
税・送料 カート、チェックアウト 店舗の設定、配送先、適用条件

プロモーション、価格検索、チェックアウトの機能範囲は、設定や対応機能によって異なる場合があります。一般論だけで可否を決めず、現在の公式通貨ドキュメントと店舗管理画面で確認してください。

注意：通貨表示が一致していても、割引や税・送料の適用条件が一致するとは限りません。金額の合計だけでなく、各項目の計算根拠を記録してください。

第三段階：決済手段と通貨の関係を確認する

多通貨で公開する前に、管理画面の設定と決済手段で何を確認しますか。
対象市場で有効な通貨設定に加え、使う決済手段がその取引通貨に対応するかを確認します。BigCommerceの取引通貨、決済事業者が処理する通貨、事業者口座への入金通貨は同じとは限りません。決済の構成要件はBigCommerceのTransactions API資料を参照し、実際の対応状況は店舗と決済事業者の設定で確かめてください。

カード発行会社や決済事業者が独自に換算する場合の手数料や換算額は、BigCommerceが決める金額として扱えません。買い手の最終的な請求額を断定するのではなく、店舗側で確認できる取引通貨と、外部の換算条件を分けて説明します。

第四段階：注文記録で買い手側の表示を裏付ける

チェックアウト画面を確認しただけでは、注文後の記録まで整合しているとは限りません。注文データにある通貨関連項目を確認し、チェックアウト時の通貨と照合してください。注文APIの通貨項目の説明を基準に、取引通貨と店舗の標準通貨を混同しないよう記録します。

通貨を積極的に選択したセッションと、初期表示のまま進んだセッションは、別々に確認します。注文の通貨情報が買い手側の表示と食い違う場合は、設定、決済手段、注文データのどの段階で差が生じたかを確認し、原因が特定できるまで公開拡大を保留します。

第五段階：Safariの買い手側検収を再現する

Safariでの買い手側検収では、市場入口から商品ページ、カート、決済直前の説明まで同じ条件で進み、通貨、金額、表示メッセージを記録します。画面幅を変えた確認だけで、実機の挙動まで検証したことにはなりません。

AppleのSafari Web Inspectorの機能はページの調査に使えますが、Responsive Design Modeは表示サイズなどを確認するための機能です。iOS端末上のページを調べる必要がある場合は、実機を接続して検査する方法も確認し、プレビューと実機で確かめた範囲を記録上で分けてください。

注文記録の通貨と買い手が見た価格が異なる場合はどうしますか。
まず、買い手側の表示通貨、チェックアウトの取引通貨、注文記録の通貨項目を並べ、どの段階で食い違うかを特定します。原因が設定や決済手段にあると確認できれば修正後に再検収し、説明できない差が残る場合は公開や流入拡大を保留して追加調査に回します。

公開前に使う比較表と判定基準

次の表は、設定画面だけで合否を決めず、買い手側の表示と注文記録を合わせて判断するためのものです。

判定 表示通貨・チェックアウト・注文記録 次の対応
合格 各画面の通貨と金額の関係を説明でき、注文記録とも整合する 対象市場と決済手段を記録して公開判断へ進む
修正 設定や決済手段に原因があり、修正箇所を特定できる 修正後、同じ条件で一連の画面を再確認する
保留 買い手側の表示と注文記録に矛盾がある、または原因を特定できない 流入拡大を止め、設定・決済・注文データを追加調査する

検収記録には、市場入口、商品ページ、カート、チェックアウト、注文記録の各画面を揃えます。併せて、選択した通貨、決済手段、割引・税・送料の条件、Safariか実機かを記録してください。条件が異なる記録を一つの結果としてまとめないことが重要です。

Safari確認環境を選ぶときの判断

方法 向いている確認 注意点
手元のMacとSafari 担当者の環境で買い手側表示を確認する 端末や地域条件が変わると同じ結果を再現しにくい場合があります
レスポンシブ表示の確認 画面幅やレイアウトの確認 実機での操作確認とは区別します
リモートMac環境 チームでSafariを使う検収環境を用意する 通貨設定や決済資格、取引成功を保証するものではありません

通常の画面幅確認で足りるなら、追加の環境を借りる必要はありません。一方、手元にSafari環境がなく、同じ買い手側の確認手順をチームで再現したい場合は、RUVCLOUDの米国向けMac環境の適用範囲を確認できます。Windows上の表示確認だけではSafari固有の差を検証できず、実機を個別に用意する方法では端末の保管やチーム間の受け渡しが負担になります。いずれも決済ルールを変えるものではないため、必要な検収条件を先に定めてください。

短期間の再検収やチーム用のSafari環境が必要な場合は、購入前にRUVCLOUDの料金と利用条件を確認し、用途に合うか判断できます。継続的な重い作業や物理端末への接続が必要なら、自社でMacを保有する方法が適することもあります。BigCommerceの通貨検収では、環境を変える前に、表示通貨・取引通貨・注文記録の食い違いを特定することが先決です。