webUrl と deeplinkUrl は排他的ですが、どちらが返るかは何で決まりますか？
次の順序で 2 つの条件が成り立つ必要があります。
第 1 に、決済ステップがそもそもリダイレクトである必要があります。 リダイレクトのフィールドが生成されるのは、
注文がルーティングされた決済手段が次のアクション形式のいずれかを返す場合のみです。
アプリプッシュのフローでは URL はまったく生成されません —
webUrl も deeplinkUrl もです。何も問題は起きておらず、
単に開くものがないだけです。
第 2 に、リダイレクトのフィールドが生成される場合、URL 自体の種類がペアを決めます。
これが、常にどちらか一方しか存在しない理由です。
actionType と URL フィールドは、同じ分岐から一緒に設定されます。
では、Web URL ではなくディープリンクを要求できますか？
いいえ。actionType はパラメーターでも加盟店の設定でもありません。この特定の取引が実際にルーティングされた決済手段が
返すリダイレクト成果物の形によって決まります。
実務的には、お客様の 2 つの注文で actionType が異なることがあり、その理由は作成時点では見えません — チェックアウトで
顧客が選んだ決済手段が違った、あるいは同じ決済手段が別の顧客のデバイスで異なる振る舞いをした、などです。連携はこれを
許容する必要があります。
では、リダイレクトを読む正しい方法は何ですか？
orderAction.actionType で分岐してください。決して予測しないでください。
- 「
actionTypeも URL もない」を、エラーではなく妥当な結果として扱ってください。 - 注文が使ったと思われる決済手段、顧客のデバイス、先週その決済手段が返した内容から、URL フィールドを推測しないでください。
- 自社ページへのリダイレクトは、決済成功の証明ではありません。正本は常に、決済通知（Webhook）または注文照会です。
actionType は userInfo.userTerminal と関係がありますか？
両者は独立した 2 つの次元です。 actionType はリダイレクト成果物の形を表し、userTerminal は顧客のデバイスタイプを
表します。どちらも他方を決定しません。
ただし、実際に間接的な関連はあり、混乱の大半の原因になっているので理解しておく価値があります。
- 一部の決済手段は
userTerminalを使ってそもそもどのフローを開くかを決めます。顧客が PC にいるときは QR コードを表示し、 スマートフォンにいるときはウォレットアプリを起動する、という決済手段もあります。 - この 2 つのフローは異なる成果物を生みます。アプリの起動はスキーム URL を返すため、
actionType = DEEPLINKになります。 QR コードの表示はそもそもリダイレクトではないため、actionTypeも URL も返りません — コードは代わりに Waffo の チェックアウトページに描画されます。
userTerminal は、決済手段自身の振る舞いを通じて、最終的に受け取るものに影響しうるということです。
それがしないのは、予測を可能にすることです。
- 同じ
userTerminalでも、決済手段が異なればactionTypeの値は異なります。 - すべての決済手段が
userTerminalを見るわけではありません。
userTerminal は顧客の状況を正直に記述する入力です。actionType は実行時に読み取る出力です。前者で後者を
推測しないでください。
では userTerminal は実際に何をしているのですか？
その主要かつ文書化された役割は対象の判定です。すべての決済手段がすべての端末タイプをサポートしているわけではないため、
この値はその決済手段をこの顧客に提示できるかどうかの判定に使われます。送信した端末をサポートしていない決済手段は、
チェックアウトに表示されません。
そのセッションにとって真である値を送信してください。実際にはウォレットアプリ内にいる顧客に対して
WEB を送っても
何かが解放されるわけではなく、プラットフォームに誤った絞り込み情報を与えるだけです。
顧客はチェックアウトで自分で国を切り替えられますか？
はい。2 つの条件があります。
セレクターが存在するのは決済手段の選択ステップのみです。顧客が決済手段を選んで次へ進むと、国の切り替えはできません。
国を切り替えると、その国の決済手段一覧が再読み込みされます。入力済みのプロモーションコードなど、以前の選択に紐づくものは
切り替えによってクリアされるため、必要であれば顧客が再入力します。
デフォルトではどの国が選択されますか？
次の順序で解決されます。- このセッションで顧客がすでにタブを切り替えていれば、そのタブ。
- そうでなければ、顧客の IP から推定された国 — ただしその国が注文の解決済みタブのひとつである場合。
- そうでなければ、注文に Global タブがあればそれ。
- そうでなければ、一覧の最初のタブ。タブはアルファベット順で、Global があれば先頭に置かれるため、これは アルファベット順で最初の国になります。
ワンタイム決済では、パラメーターで国と決済手段を固定できますか？
部分的にできます。注文作成時：payMethodCountry はフィルターであり、国のロックではありません。1 つの国を渡してもページがその国の決済手段だけになる
わけではなく、グローバルな決済手段は設計上フィルターを通過します。国タブがどうなるか、フィルターを通過するものが
何もなかった場合にどうなるかを含む完全な挙動は
チェックアウトの決済手段表示ルール に記載しています。
サブスクリプションでは、パラメーターで国と決済手段を固定できますか？
はい。同じ 3 つのフィルターが/api/v1/subscription/create の paymentInfo の下に存在し、ワンタイム注文と同じように
動作します。
サブスクリプション固有の点が 2 つあります。
- 渡した国はサブスクリプションに保存され、Waffo が対象となる決済手段を再解決するたびに再適用されます — たとえば 顧客が後から決済手段を追加・変更したときです。したがって、ある国向けに作成されたサブスクリプションは、その一生を通じて その国のローカル決済手段（およびグローバルなもの）を提示し続けます。
payMethodCountryはワンタイム注文とまったく同様に、ロックではなくフィルターです。1 つの国を渡してもページがその国の 決済手段だけになるわけではなく、グローバルな決済手段は設計上フィルターを通過します。
payMethodCountry で、決済手段は payMethodType / payMethodName で絞り込み、言語は cashierLanguage で設定します。
グローバルな決済手段を含まない厳密な単一国の体験が必要な場合は、決済手段の制限として表現してください — 提示したい決済手段を
名指ししてください。国フィルターだけではグローバルな決済手段を除去できないためです。
Cashier Ranking の設定は、サブスクリプションのチェックアウトにも適用されますか？
いいえ。並び順と表示の設定は2 つの次元、国とプロダクトタイプに紐づいて保存されます。ONE_TIME_PAYMENT と
SUBSCRIPTION は別々のプロダクトタイプであるため、各国はワンタイム決済用の設定と、サブスクリプション用の別の設定を持ちます。
両者はどちらの方向にも継承しません。
チェックアウト時に参照される設定は、注文の国かつ注文のプロダクトタイプに一致するものです。そのペアに設定がなければ、
そのペアにはプラットフォームのデフォルトの並び順が適用されます。カスタマイズしたワンタイムの並び順がサブスクリプションの
チェックアウトに波及することはなく、その逆もありません。
計画しておくべき結果がひとつあります。ワンタイムのチェックアウトを設定することは、サブスクリプションのチェックアウトを
設定することではありません。 両方を提供している場合は、Merchant Portal の Cashier Customization → Cashier Ranking で、
プロダクトタイプごとに 2 回、並び順を設定してください。
設定の参照時にプロダクトタイプがまったく指定されていない場合、デフォルトは ONE_TIME_PAYMENT になります。これも、
明示的に設定するまでサブスクリプションのチェックアウトが手つかずに見えるもうひとつの理由です。
ある通貨で注文を作成したのに、顧客が別の通貨で課金されました。なぜですか？
1 つの決済手段が、お客様の契約の下で複数の決済通貨に設定されていることがあり、チェックアウトは通貨ごとではなく 決済手段ごとに 1 エントリーを表示するためです。そのエントリーが設定済みのどの通貨を使うかを何かが選ぶ必要があり、 注文通貨として渡した通貨が自動的に勝つわけではありません。 渡した注文通貨は、依然としてお客様の注文と精算ビューの通貨です。変わるのは顧客が実際に支払う通貨であり、 換算はチェックアウトページで顧客に表示されます。決済手段が複数の通貨に設定されている場合、どの通貨が選ばれますか？
その決済手段の候補は、レベルごとに絞り込まれます。各レベルで、ちょうど 1 件一致すれば処理は終了し、複数一致すれば候補を 絞って続行し、一致がなければ候補はそのままで続行します。
実例です。これがこの種のチケットを最も多く生み出しています。
注文通貨が結果を決めるのはレベル 3 のみ、つまり決済手段自身の現地通貨に一致する候補がなく、顧客の IP の通貨にも一致する 候補がなかった場合だけです。これは意図的な設計です。ローカルな決済手段では、顧客自身の口座の建値通貨のほうが、 たまたま請求に使った通貨よりも良い結果だからです。 この収束はプラットフォームの動作であり、加盟店が設定することはできません。currency = HKDで注文を作成します。顧客の IP は中国に解決されます。顧客が使いたい eウォレット系の決済手段は中国に属し、 お客様の契約の下で USD と CNY の両方に設定されています。
- レベル 1 — その決済手段の本拠国は中国で、現地通貨は CNY です。2 つの候補のうち、ちょうど 1 つが一致します。解決。
- HKD を送信したにもかかわらず、顧客は CNY で支払います。
この驚きを完全に避けるにはどうすればよいですか？
次の 2 つで、不可解ではなく予測可能なものになります。- 決済通貨は注文から読み取り、想定しないでください。 チェックアウトには顧客の決済金額と換算の内訳が表示され、 同じ値が注文にもあります。 チェックアウトページのライフサイクルと領収書 を参照してください。
- 特定の決済通貨が業務要件である場合は、
payMethodType/payMethodNameで提示する決済手段を絞り込んでください。 決済手段を限定すれば、収束が実行される候補集合も限定されます。