> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # 注文金額、限度額、決済拒否 > 有効に見える金額が拒否される理由、同一通貨と異通貨の注文で検証がどう異なるか、processingAmountLimits の min/max/multiple の意味、どの限度額がどのエラーコードを生んだか、決済手段のタイプが顧客の支払い可否をどう決めるか、カードの決済拒否の読み方、未払いの注文がどれだけ開いたままになるかを説明します。 顧客が決済ページを見る前に注文が拒否された理由のすべてと、顧客が決済ページを見た後の決済拒否の読み方をまとめています。注文フィールドの意味については[注文作成フィールドガイド](/docs/ja/support/order-create-field-guide)を、結果の確認については[決済結果の確認](/docs/ja/support/payment-results-faq)を、通貨ごとの固定小数桁の表については[通貨](/docs/ja/developer-docs/core-concepts/currency)を参照してください。 ## 小数桁が多すぎるとして金額が拒否されたのはなぜですか？ 精度のルールは 1 つではなく **2 つ**あり、それぞれ異なる金額に適用されるためです。 | 層 | 適用対象 | 効果 | | - | - | - | | **注文通貨、ISO の小数桁** | 貴社の `orderAmount`、常に | 金額が注文通貨の ISO 4217 定義より多い小数桁を持つ場合、またはその通貨の倍数ルールに違反する場合、作成時に `A0003` で拒否されます。 | | **処理精度と倍数** | 実際に課金される金額 | 課金金額が処理精度で表現できない場合、または決済手段の倍数ルールに違反する場合、その決済手段が除外されます。どれも残らなければ `A0018` が返ります。 | 2 つ目の層が同一通貨と異通貨で分岐するところであり、しっかり理解しておく価値のある部分です。 ## 同一通貨と異通貨では検証が異なるとのことですが、どのように違いますか？ 2 つ目の層は**顧客に課金される方の金額**に適用されます。 * **同一通貨の注文** — 課金金額は貴社の `orderAmount` *そのもの*なので、厳格な処理精度と倍数は送信した金額に直接適用されます。一部の通貨は処理精度が **ISO の小数桁より狭く**なっています。そうした通貨は ISO ルールでは 2 桁の小数を受け付けますが、整数単位で処理されます。そのような通貨で小数部を持つ金額は、1 つ目の層を通過した後、2 つ目の層で拒否されます。 * **異通貨の注文** — 課金金額は**換算後**の金額なので、厳格な検証はそこに適用され、貴社の `orderAmount` には適用されません。Waffo は換算した後、結果を処理通貨の精度と決済手段の倍数に調整するため、処理側が受け付けられない小数を持つ `orderAmount` はもう貴社の問題ではなくなります。 **自分がどちらのシナリオにいるかを把握しておく必要があります。** 同じ通貨の同じ `orderAmount` が一方では受け付けられ、他方では拒否されることがあり、その違いはひとえに顧客がどの通貨で支払うかにあります。ある通貨で価格を付けて別の通貨で課金する場合、国内フロー向けに構築した同一通貨の検証をそのまま持ち込まないでください。 ## Waffo は換算後の金額をどちらの方向に丸めますか？ **切り上げ**です。換算後、金額は処理通貨の精度に合うように上方に調整され、次に決済手段に倍数がある場合は次の有効な倍数へ上方に調整されます。丸めが現れるのは**異通貨**の注文のみです。同一通貨の注文は再度丸められることはなく、検証されてそのまま通過します。 差分は貴社に報告されます。異通貨の注文の照会レスポンスは換算後の金額、適用されたレート、行われた調整を返すため、再計算せずに課金金額と価格付けした金額を照合できます。レートが確定するタイミングについては[為替レート](/docs/ja/support/exchange-rates-faq)を参照してください。 ## 10 は受け付けられたのに 10.50 が拒否されたのはなぜですか？ 金額の制限は範囲だけではなく、**整数倍**もあるためです。決済手段は金額が特定の単位の整数倍であることを要求できます。その場合、その倍数でない値は、min/max の中にどれだけ余裕を持って収まっていても拒否されます。 倍数は**決済手段と実際に処理される通貨**の組み合わせで決まるため： * 同じ決済手段が、ある通貨では倍数を持ち、別の通貨では持たないことがあります。 * 同じ通貨の 2 つの決済手段が、異なる倍数を持つことがあります。 * 倍数を持つ決済手段は、ほぼ常に**小数部をまったく持ちません**。決済手段が整数単位の倍数を要求するなら、`10.50` は決してそれを満たせません。 この形の金額は、「限度額の範囲内なのに拒否される」の最も多い単一の原因です。 ## 注文を作成する前に限度額を確認するには？ 決済手段の照会レスポンスから読み取ってください。利用可能な各決済手段は、処理される通貨をキーとした `processingAmountLimits` を、3 つのフィールドとともに返します。 | フィールド | 意味 | | - | - | | `min` | その通貨で受け付けられる最小金額。 | | `max` | 受け付けられる最大金額。 | | `multiple` | 金額はこの値の整数倍でなければなりません。ゼロまたは未設定は倍数制約なしを意味します。 | そのマップには現地通貨と換算後の通貨の両方が現れるため、異通貨の決済手段は顧客が実際に課金される通貨で限度額を報告します。貴社側の事前チェックでは、`min`/`max` だけでなく `multiple` も検証してください。それが最も多くの連携で省略されているフィールドです。 ## どのエラーがどの限度額に当たったことを意味しますか？ | コード | ここでの意味 | 対処 | | - | - | - | | `A0003` | 注文金額の小数桁または倍数が**注文通貨**に合いません。 | 送信する金額を修正してください。 | | `A0008` | 注文金額が、すべての候補契約について**契約**の金額範囲の外にあります。 | 問題は金額の形ではなく金額そのものです。 | | `A0018` | フィルタリングを通過した決済手段がありません。**課金**金額が処理精度または決済手段の倍数を満たさない場合も含みます。 | `processingAmountLimits` を再確認して調整してください。渡した決済手段と端末も確認してください。 | | `A0029` | 参照したカード資格情報が使用できません。不明、ステータス不正、またはこのユーザーのものではありません。 | 下記のトークンのセクションを参照してください。 | `A0018` は「何も利用できなかった」の包括的なコードであるため、端末の不一致や長すぎるサブスクリプションでも返されます。「決済手段名が間違っている」ではなく「フィルタリングで何も残らなかった」と読んでください。その他の `A0018` の原因については[注文作成フィールドガイド](/docs/ja/support/order-create-field-guide)を参照してください。 ## 顧客が決済手段を利用できないのはなぜですか？ 決済手段の**タイプ**が顧客の完了方法を決め、一部のタイプは 1 つの方法でしか完了できないためです。決済手段は特定の顧客端末に限定されることがあり、Waffo はそれを注文作成時に強制します。 * Waffo は決済手段ごとに許可端末リストを保持しています。送信した `userTerminal` がその決済手段のリストにない場合、**その決済手段は候補から除外されます**。何も残らなければ作成は失敗します。 * アプリ起動専用の決済手段が典型例です。一部の電子ウォレット、BNPL、デジタルバンキングの決済手段はモバイルアプリへの引き渡しで完了するため、デスクトップブラウザでは選択肢として単に存在しません。 その帰結：**`userTerminal` は分析用のヒントではなく、ルーティングの入力です。** モバイルセッションにデスクトップの値を送ったり、全トラフィックで 1 つの値にデフォルト設定したりすると、完全に利用可能な決済手段が消え、ログでは別の原因に帰されてしまう作成失敗を生みます。セッションごとに検出してください。受け付けられる値については[注文作成フィールドガイド](/docs/ja/support/order-create-field-guide)を参照してください。 ## 銀行振込と店頭払い：注文を作成した後、何も起こらないのはなぜですか？ これらのタイプでは、**注文の作成と支払いは別々のイベント**だからです。顧客は口座番号、参照番号、または伝票を持って離脱し、後で銀行や窓口で支払います。顧客が支払うまで Waffo では他に何も起こりません。 * 作成から結果までに長い間隔があることと、2 つの通知が来ることを想定してください。1 つは注文が支払い可能になったとき、もう 1 つは資金が到着したときです。 * 顧客がまだ支払える期間は、単一のプラットフォーム値ではなく**決済手段ごとに**設定されるため、同じ国の 2 つの銀行振込の決済手段が異なる時刻に閉じることがあります。 * 数時間静かだからといって注文をキャンセルしたり再作成したりしないでください。何が最終状態と見なされるかは[決済結果の確認](/docs/ja/support/payment-results-faq)を参照してください。 ## 注文作成時に顧客のデフォルトカードを設定できますか？ いいえ。注文作成はデフォルトカードを設定する場所ではありません。専用の保存済み決済手段エンドポイントを使用してください。[トークン化とカード決済](/docs/ja/support/tokenization-faq)を参照してください。 注文作成が保存済み資格情報に対して*行う*のは、厳格な検証です。`paymentInfo.userPaymentAccessToken` を渡すと： | 状況 | 結果 | | - | - | | トークンが存在しない | 作成は失敗します（`A0029`）。 | | トークンが使用可能な状態でない | 作成は失敗します。 | | トークンが別の `userId` に属している | 作成は失敗します。トークンは作成した顧客にスコープされます。 | | 生のカードデータも一緒に渡した | 作成は失敗します。両者は相互排他です。 | つまり、保存済みカードでの課金は、その正確な資格情報で進むか、まったく進まないかのどちらかです。別の保存済みカードへの暗黙のフォールバックはなく、これは意図的です。貴社が指定していないカードで顧客に課金してはならないからです。 ## `tokenizationNotifyUrl` は `notifyUrl` の代わりになりますか？ いいえ。両者は別々のチャネルで、両方が必要です。 * `notifyUrl` は従来どおり**決済**結果を受け取ります。 * トークン化通知 URL は**カード紐付け**の結果のみを受け取ります。 一方を設定しても他方には影響せず、決済中に紐付けられたカードはそれぞれに通知を生成します。トークン化 URL の設定場所については[トークン化とカード決済](/docs/ja/support/tokenization-faq)を参照してください。 ## カードが拒否されました。再試行すべきですか？ 4 種類の決済拒否のどれを受け取ったかを把握した後でのみです。Waffo はカードスキームのレスポンスを Waffo の失敗コードと再試行クラスにマッピングします。 | クラス | 意味 | 対処 | | - | - | - | | **再試行しない** | スキームがこの試行は決して成功しないと告げています。アカウントが閉鎖・無効、紛失・盗難として報告済み、またはこのカード保有者に取引が許可されていません。 | **顧客に別のカードを依頼してください。** スケジュールによるものを含め、再試行しないでください。これらへの繰り返しの試行はスキームの手数料を招くことがあります。 | | **情報を更新した後に再試行** | 資格情報自体が古い、または認証に失敗しました。期限切れのカード、または検証できなかった認証データです。 | 顧客にカードを再入力または再紐付けしてもらい、その後で再度課金してください。同じ保存済み資格情報を変更せずに再試行しても同じように失敗します。 | | **後で再試行** | イシュアー側の一時的な状態です。現時点で資金がない、頻度または金額の制限に達した、イシュアーに到達できない、など。 | 遅延を置いて再試行してください。サブスクリプションでは、再試行戦略がすでにこれを代行しています。 | | **その他** | この取引に適さないカード商品を含む、それ以外のすべて。 | 再試行可能と仮定しないでください。別の支払い手段を取得すべきという案内の場合は、1 つ目のクラスとして扱ってください。 | 分類より重要な 2 つのルール： * **恒久的な決済拒否はカード変更の促しであり、再試行候補ではありません。** ここでの最も高くつく連携ミスは、決して解消しない決済拒否をループすることです。 * Waffo はコードごとの再試行上限を公開しておらず、貴社の運用手順書もそれを仮定すべきではありません。継続課金の再試行上限はカードスキームのルールに従います。[サブスクリプションの再試行と決済手段](/docs/ja/support/subscription-retry-and-payment-methods-faq)を参照してください。 ## 顧客が銀行に継続課金の停止を申し出ました。何をしなければなりませんか？ **その顧客に対するすべての継続的な引き落としを直ちに停止してください。** スキームには、カード保有者が承認を取り消した場合（単一の加盟店に対して、またはすべての加盟店に対して）、およびカード保有者が継続課金や分割払いの停止を求めた場合の特定のレスポンスコードがあります。これらは定義上再試行不可であり、試行を続けることは単なる決済失敗ではなくコンプライアンス上の問題です。 具体的には： * 再試行スケジュールが尽きるのを待つのではなく、サブスクリプションをキャンセルしてください。 * 同じ資格情報で新しいサブスクリプションを作成しないでください。 * 顧客が後で再開を希望する場合は、新たな同意のもとで最初から再度承認してもらう必要があります。 ## 未払いの注文はどれだけの間開いたままになりますか？ Waffo 側のデフォルトは、決済手段がカードかどうかで 2 つに分かれており、いずれも貴社が前提にすべき契約条件ではありません。 | 注文 | デフォルトの期間 | | - | - | | カード系の決済手段 | 時間単位で計られる**長い**プラットフォームデフォルト。カードには意図的に長い期間が与えられています。結果は同期的に届き、短い期間ではその後成功する注文を閉じてしまうリスクがあります。 | | その他すべての決済手段 | **短い**プラットフォームデフォルト。ただし実際には決済手段自身に設定されたタイムアウトが優先され、それが銀行振込、バーチャル口座、店頭払いのフローを支配する値です。 | プラットフォームデフォルトは環境設定であり変更されることがあります。期間が貴社のビジネスにとって重要な場合は、加盟店指定の有効期限を受け付ける決済手段では `orderExpiredAt` を自ら送信してください（**Service → Payin** の `Order Expiry Customization` 列がどれかを示します）。受け付けない決済手段では無視されます。`orderExpiredAt` が何を制御し何を制御しないか、および Waffo が注文を閉じた後でも決済が着金し得る理由については[決済結果の確認](/docs/ja/support/payment-results-faq)を参照してください。 ## ステーブルコイン：1 つの決済に 2 つの例外タイプが付くことはありますか？ いいえ。例外は**ちょうど 1 つ**のタイプを持ちます。フィールドは単一値なので、遅延かつ不足である決済は 2 つではなく 1 つの分類で記録されます。タイプは次のとおりです。 | タイプ | 意味 | | - | - | | `OVERPAID` | 注文金額より多く受け取った。 | | `UNDERPAID` | 注文金額より少なく受け取った。 | | `LATE_PAID` | 注文がすでに最終状態になった後に資金が到着した。 | | `WRONG_TOKEN` | 受け取ったトークンが注文の期待するトークンではない、またはまったく認識されないトークンである。 | | `WRONG_CHAIN` | 注文が期待していないチェーンに資金が到着した。 | | `NO_MATCH_ORDER` | 送金に一致する注文が見つからなかった。 | | `UNSUPPORTED_WALLET_ADDRESS` | 関係するアドレスを自動的に処理できない。 | | `BLOCKED` | リスク上の理由で資金が拒否された。 | 依拠できる 2 つの順序ルール： * **トークンの同一性は金額より先に解決されます。** 認識されない、または一致しないトークンはトークンの問題として分類され、金額は比較されません。したがって、誤ったトークンでの送金に `UNDERPAID` を期待しないでください。 * **返還先アドレスは最後にチェックされ、それが優先されます。** 例外が本来なら自動的に解決されるはずでも、返還先のアドレスが単純なウォレットアドレスでない場合、例外は**アドレスの問題として再分類され、手動処理へ回されます**。過払いがアドレス例外として現れ得るのはこのためです。 各ケースで資金がどうなるかについては、[ステーブルコインの例外と返金](/docs/ja/support/stablecoin-exceptions-faq)を参照してください。 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.