海外決済連携の手引き · PayPal・Stripe

国内PGでも、契約した商品と決済手段によって海外発行カードや海外のウォレットを受け付けられます。最初に対応国とカードブランド、認証方式、決済通貨と精算通貨を確認します。国内PGを使うことだけを理由に、ウォン決済しかできないとは判断しません。承認率が低い場合は、発行会社の拒否、認証失敗、加盟店設定、決済手段の不足を分けて調べます。失敗コードと認証結果を集め、記録だけで確認できない理由は決済会社に問い合わせます。海外決済会社を追加するかは、海外からの決済試行数と承認率、国別の決済画面離脱を基に判断します。国内カードとの差だけで原因を一つに決めません。現地の手段への対応と顧客の問い合わせを照らし、既存契約や連携設定で改善できる範囲を確認します。追加候補の期待効果と開発・運用・精算費用を同じ表で比較します。

海外決済を導入するとき最初に決めるのは、何をどの通貨で見せ、どの通貨で請求するかです。表示通貨は商品ページの価格で、決済通貨は実際に承認が下りる通貨です。二つを同じにすると顧客が見た値がそのまま請求されますが、為替が動くたびに価格を付け直すことになります。二つを別にすると価格は固定できますが、顧客は自分のカード明細で違う数字を見て問い合わせを入れます。決済時点で顧客の通貨に換算して見せる方式もありますが、そのときの為替とその上に乗せる利ざやを誰が決めるかはサービスごとに違うため、画面にどの値を書くかも併せて決めます。サブスクリプション商品はこの判断がより重くなります。毎月同じ金額を請求するには通貨を固定する必要があり、通貨を固定すれば為替が動いた分だけ国ごとの体感価格が開きます。国別に価格表を分ける方法は売上を守りますが、料金プランと請求規則がその分だけ増えます。返金でも同じ問題が戻ってきます。決済した日と返金する日の為替が違えば顧客が受け取る金額は支払った金額とずれ、その差を誰が負うかを方針として先に決めていなければ件ごとに判断が分かれます。表示通貨と決済通貨、返金の基準通貨の三つを一つの文書に書いておけば、サポートが同じ答えを返せます。

承認が下りたからといって、お金が口座に入るわけではありません。海外の決済会社は残高を自社アカウントに積み、定められた周期で加盟店の口座へ送ります。ここで確認することが四つあります。受け取る通貨を何にするか、ウォンで受け取るなら換算を決済会社が行うのか銀行が行うのか、外貨口座で受け取るならどの銀行のどの口座が必要か、そして初回の精算がいつ出るかです。新規アカウントには代金を一定期間留め置く条件が付くことがあり、取消と係争が増えればその比率がさらに上がります。換算がどこで起きるかが手取り額を分けます。決済会社がウォンに替えて送れば楽ですが換算条件は決済会社の方針に従い、外貨で受け取って自分で替えれば銀行の条件を選べる代わりに外貨口座と受領手続きが生まれます。財務の側では、売上の計上時点と実際の入金時点が離れるという問題がもう一つ付くため、決済会社の残高と銀行入金を別々の二本の線として管理する突合ルールが必要です。精算明細の項目構造も国内とは違います。取引別の手数料と通貨換算分、チャージバックで回収された金額とその処理費用、返金で戻った金額が一つのファイルに混ざって届くため、どの項目を売上から差し引き、どの項目を費用として計上するかを最初に決めておきます。この規則がなければ月次の締めのたびに同じ判断を繰り返します。

海外販売の税務要件は、顧客の国だけでは決まりません。販売主体と商品の種類、販売国、企業間取引か消費者取引かによって確認項目が変わります。対象国と取引構造を決めてから、登録・申告・税の扱い・証憑の要件を税務担当や専門家と確認します。連携設計では、その判断に必要な入力値と保存先を定めます。顧客の国と請求先住所、事業者区分と登録番号は、対象取引で必要な範囲を確認して収集します。税込み表示か決済時の加算か、請求書と領収書に残す項目も、確認した要件に合わせます。プラン変更や返金時に税額と文書をどう修正するかを決め、確認日と担当者を記録します。決済会社が税計算機能を提供する場合も、対象範囲と設定の責任者を確認します。公開前には注文額、決済額、税の記録、領収書が同じ取引を指すことを点検します。

海外の決済会社を導入する仕事は、API連携よりアカウント審査で時間が掛かります。PayPalとStripeはアカウントを開設する法人の所在国によって利用条件と使える機能が分かれ、開設段階で法人書類と代表者の本人確認、事業内容の説明、想定取引規模を求めます。ウェブサイトも審査の対象です。何を販売しているのか、価格と配送条件が書かれているか、返金方針と連絡先が掲示されているか、利用規約がサービス内容と合っているかを見ます。国内審査では求められなかった項目がここで出るため、ページを直す作業が連携日程に入ります。取り扱えない業種の一覧も決済会社が公開しているので、契約前に照合します。機能の面では国内と違うものがいくつかあります。承認と売上確定を分けて掛ける方式、地域ごとに異なる決済手段、定期課金や税額計算を決済会社の機能として受け取る方式がそうです。国内PGと海外決済会社を併用するサービスは、この差を製品コードに散らさず一つの取引仕様の下でアダプターに吸収させます。どの取引をどちらへ送るかは規則として書きます。カードの発行国や顧客が選んだ通貨、商品の種類を条件に経路を分け、片方が遅延したときの迂回まで同じ場所に置きます。注文番号と取引識別子を両社で同じ規則で作っておかなければ、突合とサポートの照会が一つの画面で終わりません。

海外決済で新たに生まれる最大の運用負荷がチャージバックです。顧客が加盟店ではなくカード発行会社に異議を申し立てると代金が先に回収され、加盟店は定められた期限内に証憑を提出して争うことになります。国内の返金が加盟店の判断で終わるのとは手順が違います。対応は証憑の準備で決まります。注文時刻とアクセス記録、配送の追跡番号と受領確認、デジタル財ならアカウントの利用ログ、規約に同意した時点と返金方針を見せた画面が必要です。この資料を事後に集めると期限を逃すため、取引ごとに自動で貯まるようにしておくことが実際の対応です。チャージバックが増えると決済会社が留保比率を上げたりアカウント条件を見直したりするため、比率そのものを指標として管理します。係争を減らす側も併せて見ます。明細に載る加盟店名を顧客が分かる形で書き、サブスクリプションは請求前に案内を送り、返金の受付窓口を発行会社より見つけやすい場所に置けば、異議申し立てに移る前に終わる件が増えます。カード情報を盗んで使われた取引は性格が違い、証憑をいくら添えても加盟店が代金を守るのは難しいため、承認の前に危険度判定を置いて最初から通さないほうが費用が少なくて済みます。判定をどこに置くか、どの取引に追加認証を掛けるかは決済手段と商品の性格によって分かれるので、連携設計の段階で併せて決めます。