小数桁が多すぎるとして金額が拒否されたのはなぜですか？
精度のルールは 1 つではなく 2 つあり、それぞれ異なる金額に適用されるためです。
2 つ目の層が同一通貨と異通貨で分岐するところであり、しっかり理解しておく価値のある部分です。
同一通貨と異通貨では検証が異なるとのことですが、どのように違いますか？
2 つ目の層は顧客に課金される方の金額に適用されます。- 同一通貨の注文 — 課金金額は貴社の
orderAmountそのものなので、厳格な処理精度と倍数は送信した金額に直接適用されます。一部の通貨は処理精度が ISO の小数桁より狭くなっています。そうした通貨は ISO ルールでは 2 桁の小数を受け付けますが、整数単位で処理されます。そのような通貨で小数部を持つ金額は、1 つ目の層を通過した後、2 つ目の層で拒否されます。 - 異通貨の注文 — 課金金額は換算後の金額なので、厳格な検証はそこに適用され、貴社の
orderAmountには適用されません。Waffo は換算した後、結果を処理通貨の精度と決済手段の倍数に調整するため、処理側が受け付けられない小数を持つorderAmountはもう貴社の問題ではなくなります。
orderAmount が一方では受け付けられ、他方では拒否されることがあり、その違いはひとえに顧客がどの通貨で支払うかにあります。ある通貨で価格を付けて別の通貨で課金する場合、国内フロー向けに構築した同一通貨の検証をそのまま持ち込まないでください。
Waffo は換算後の金額をどちらの方向に丸めますか？
切り上げです。換算後、金額は処理通貨の精度に合うように上方に調整され、次に決済手段に倍数がある場合は次の有効な倍数へ上方に調整されます。丸めが現れるのは異通貨の注文のみです。同一通貨の注文は再度丸められることはなく、検証されてそのまま通過します。 差分は貴社に報告されます。異通貨の注文の照会レスポンスは換算後の金額、適用されたレート、行われた調整を返すため、再計算せずに課金金額と価格付けした金額を照合できます。レートが確定するタイミングについては為替レートを参照してください。10 は受け付けられたのに 10.50 が拒否されたのはなぜですか？
金額の制限は範囲だけではなく、整数倍もあるためです。決済手段は金額が特定の単位の整数倍であることを要求できます。その場合、その倍数でない値は、min/max の中にどれだけ余裕を持って収まっていても拒否されます。 倍数は決済手段と実際に処理される通貨の組み合わせで決まるため：- 同じ決済手段が、ある通貨では倍数を持ち、別の通貨では持たないことがあります。
- 同じ通貨の 2 つの決済手段が、異なる倍数を持つことがあります。
- 倍数を持つ決済手段は、ほぼ常に小数部をまったく持ちません。決済手段が整数単位の倍数を要求するなら、
10.50は決してそれを満たせません。
注文を作成する前に限度額を確認するには？
決済手段の照会レスポンスから読み取ってください。利用可能な各決済手段は、処理される通貨をキーとしたprocessingAmountLimits を、3 つのフィールドとともに返します。
そのマップには現地通貨と換算後の通貨の両方が現れるため、異通貨の決済手段は顧客が実際に課金される通貨で限度額を報告します。貴社側の事前チェックでは、
min/max だけでなく multiple も検証してください。それが最も多くの連携で省略されているフィールドです。
どのエラーがどの限度額に当たったことを意味しますか？
A0018 は「何も利用できなかった」の包括的なコードであるため、端末の不一致や長すぎるサブスクリプションでも返されます。「決済手段名が間違っている」ではなく「フィルタリングで何も残らなかった」と読んでください。その他の A0018 の原因については注文作成フィールドガイドを参照してください。
顧客が決済手段を利用できないのはなぜですか？
決済手段のタイプが顧客の完了方法を決め、一部のタイプは 1 つの方法でしか完了できないためです。決済手段は特定の顧客端末に限定されることがあり、Waffo はそれを注文作成時に強制します。- Waffo は決済手段ごとに許可端末リストを保持しています。送信した
userTerminalがその決済手段のリストにない場合、その決済手段は候補から除外されます。何も残らなければ作成は失敗します。 - アプリ起動専用の決済手段が典型例です。一部の電子ウォレット、BNPL、デジタルバンキングの決済手段はモバイルアプリへの引き渡しで完了するため、デスクトップブラウザでは選択肢として単に存在しません。
userTerminal は分析用のヒントではなく、ルーティングの入力です。 モバイルセッションにデスクトップの値を送ったり、全トラフィックで 1 つの値にデフォルト設定したりすると、完全に利用可能な決済手段が消え、ログでは別の原因に帰されてしまう作成失敗を生みます。セッションごとに検出してください。受け付けられる値については注文作成フィールドガイドを参照してください。
銀行振込と店頭払い：注文を作成した後、何も起こらないのはなぜですか？
これらのタイプでは、注文の作成と支払いは別々のイベントだからです。顧客は口座番号、参照番号、または伝票を持って離脱し、後で銀行や窓口で支払います。顧客が支払うまで Waffo では他に何も起こりません。- 作成から結果までに長い間隔があることと、2 つの通知が来ることを想定してください。1 つは注文が支払い可能になったとき、もう 1 つは資金が到着したときです。
- 顧客がまだ支払える期間は、単一のプラットフォーム値ではなく決済手段ごとに設定されるため、同じ国の 2 つの銀行振込の決済手段が異なる時刻に閉じることがあります。
- 数時間静かだからといって注文をキャンセルしたり再作成したりしないでください。何が最終状態と見なされるかは決済結果の確認を参照してください。
注文作成時に顧客のデフォルトカードを設定できますか？
いいえ。注文作成はデフォルトカードを設定する場所ではありません。専用の保存済み決済手段エンドポイントを使用してください。トークン化とカード決済を参照してください。 注文作成が保存済み資格情報に対して行うのは、厳格な検証です。paymentInfo.userPaymentAccessToken を渡すと：
つまり、保存済みカードでの課金は、その正確な資格情報で進むか、まったく進まないかのどちらかです。別の保存済みカードへの暗黙のフォールバックはなく、これは意図的です。貴社が指定していないカードで顧客に課金してはならないからです。
tokenizationNotifyUrl は notifyUrl の代わりになりますか？
いいえ。両者は別々のチャネルで、両方が必要です。
notifyUrlは従来どおり決済結果を受け取ります。- トークン化通知 URL はカード紐付けの結果のみを受け取ります。
カードが拒否されました。再試行すべきですか？
4 種類の決済拒否のどれを受け取ったかを把握した後でのみです。Waffo はカードスキームのレスポンスを Waffo の失敗コードと再試行クラスにマッピングします。
分類より重要な 2 つのルール：
- 恒久的な決済拒否はカード変更の促しであり、再試行候補ではありません。 ここでの最も高くつく連携ミスは、決して解消しない決済拒否をループすることです。
- Waffo はコードごとの再試行上限を公開しておらず、貴社の運用手順書もそれを仮定すべきではありません。継続課金の再試行上限はカードスキームのルールに従います。サブスクリプションの再試行と決済手段を参照してください。
顧客が銀行に継続課金の停止を申し出ました。何をしなければなりませんか？
その顧客に対するすべての継続的な引き落としを直ちに停止してください。 スキームには、カード保有者が承認を取り消した場合（単一の加盟店に対して、またはすべての加盟店に対して）、およびカード保有者が継続課金や分割払いの停止を求めた場合の特定のレスポンスコードがあります。これらは定義上再試行不可であり、試行を続けることは単なる決済失敗ではなくコンプライアンス上の問題です。 具体的には：- 再試行スケジュールが尽きるのを待つのではなく、サブスクリプションをキャンセルしてください。
- 同じ資格情報で新しいサブスクリプションを作成しないでください。
- 顧客が後で再開を希望する場合は、新たな同意のもとで最初から再度承認してもらう必要があります。
未払いの注文はどれだけの間開いたままになりますか？
Waffo 側のデフォルトは、決済手段がカードかどうかで 2 つに分かれており、いずれも貴社が前提にすべき契約条件ではありません。
プラットフォームデフォルトは環境設定であり変更されることがあります。期間が貴社のビジネスにとって重要な場合は、加盟店指定の有効期限を受け付ける決済手段では
orderExpiredAt を自ら送信してください（Service → Payin の Order Expiry Customization 列がどれかを示します）。受け付けない決済手段では無視されます。orderExpiredAt が何を制御し何を制御しないか、および Waffo が注文を閉じた後でも決済が着金し得る理由については決済結果の確認を参照してください。
ステーブルコイン：1 つの決済に 2 つの例外タイプが付くことはありますか？
いいえ。例外はちょうど 1 つのタイプを持ちます。フィールドは単一値なので、遅延かつ不足である決済は 2 つではなく 1 つの分類で記録されます。タイプは次のとおりです。
依拠できる 2 つの順序ルール：
- トークンの同一性は金額より先に解決されます。 認識されない、または一致しないトークンはトークンの問題として分類され、金額は比較されません。したがって、誤ったトークンでの送金に
UNDERPAIDを期待しないでください。 - 返還先アドレスは最後にチェックされ、それが優先されます。 例外が本来なら自動的に解決されるはずでも、返還先のアドレスが単純なウォレットアドレスでない場合、例外はアドレスの問題として再分類され、手動処理へ回されます。過払いがアドレス例外として現れ得るのはこのためです。