> ## 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.

# 限度額・通貨・設定に関するエラー

> 他のページで扱っていない注文作成時の却下理由：A0008 / A0020 / A0021 の金額限度額の違い、契約外通貨が A0007 ではなく A0018 を返す理由、A0026 / A0047 のチェックアウト言語、A0024 の為替レート期限切れ（A0023 ではありません）、A0014 の換算後にゼロになる通貨間返金、A0022 の決済手段の曖昧さ。さらに、限度額が為替レートに連動しない理由、Portal に精算メニューが表示されない場合がある理由、サンドボックスと本番環境の利用可否の違い、継続課金のルールも扱います。

[よくあるエラーのトラブルシューティング](/docs/ja/support/errors-troubleshooting-guide)では、最も多くのお問い合わせを生むコード（`A0001`、`A0002`、`A0003`、`A0018`、および `E`xxxxx 系）を扱っています。このページでは、それ以外の注文作成時の却下（限度額、通貨、言語、為替、設定）を扱い、続けて、エラーコードは一切出ないのに同じ「なぜ〜できないのか」というお問い合わせを生む設定関連の質問を扱います。

## どのエラーコードがどの限度額に対応しますか？3 種類あって区別がつきません

これらは異なるレベルでチェックされる 3 つの異なる上限です。同じものだと読んでしまうことが、加盟店が誤った設定を「修正」してしまう典型的な原因です。

| コード | メッセージ | 意味 | 限度額の所在 |
| - | - | - | - |
| `A0008` | Payment amount should be within the range | 注文金額が、その通貨における**決済手段**の最小/最大範囲の外にあります | 決済手段の設定 |
| `A0020` | Payment amount exceeds transaction limit | **単一の注文**が、その注文通貨における貴社アカウントの 1 取引あたりの限度額を超えています | アカウントレベルの限度額（注文通貨ごと） |
| `A0021` | Accumulative payment amount exceeds daily transaction limit | この注文と、**その注文通貨で当日すでに受け付けたすべての金額**の合計が、日次上限を超えています | アカウントレベルの限度額（注文通貨ごと） |

ここから 3 つのことが導かれます。

* `A0020` と `A0021` は**注文通貨ごと**です。ある通貨の限度額を引き上げても、別の通貨には何の影響もありません。
* `A0021` は当日すでに受け付けた取引量に依存するため、同じリクエストが朝には成功し、夕方には失敗することがあります。すぐにリトライしても解決しません。翌日にリトライすれば解決します。
* `A0008` は決済手段の範囲であり、アカウントの限度額ではありません。範囲の確認方法は
  [よくあるエラーのトラブルシューティング](/docs/ja/support/errors-troubleshooting-guide)で扱っています。

いずれかのアカウントレベルの限度額が貴社のビジネスに対して低すぎる場合、それは設定変更にあたります。Waffo の連携担当者にお問い合わせください。

## 契約していない通貨を送信しました。`A0007` が返りますか？

いいえ。返るのは **`A0018`** *"Payment method in merchant order does not match with current merchant contract"* です。通常の注文作成経路には、通貨固有の却下は存在しません。契約の検索は貴社のマーチャント ID **と**注文通貨の組み合わせで照合されるため、いずれの契約にも含まれない通貨では照合できる契約が単に存在せず、その失敗は決済手段の不一致として報告されます。メッセージは誤解を招きますが、原因は通貨です。

`A0007` *"Transaction currency is not supported"* はエラー表に存在しますが、精算通貨を 1 つしか受け付けない特殊なステーブルコインプロトコルの決済経路のために予約されています。通常の注文を作成していて通貨の問題に遭遇した場合、デバッグすべきコードは `A0018` です。

| 症状 | コード |
| - | - |
| 注文通貨が契約されていない | `A0018` |
| 決済手段、または `orderCurrency` → `userCurrency` のペアが契約されていない | `A0018` |
| 金額が契約された範囲の外にある | `A0008` |

`/api/v1/paymethodconfig/inquiry` は契約ごとに 1 件のエントリを返し、それぞれに固有の `currency` があります。リクエストを組み立てる前に、課金しようとしている通貨で照合してください。通貨に起因して `A0018` になるパターンは、
[通貨を有効化する必要がありますか？](/docs/ja/support/currency-and-method-enablement-faq)で順に説明しています。

## `A0026` と `A0047` — `cashierLanguage` の何が間違っているのですか？

これらは「存在しない言語を要求した」と「有効な言語タグではない」を区別しています。

| コード | 意味 | 典型的な原因 |
| - | - | - |
| `A0026` | 指定されたチェックアウト言語はサポートされていません | Waffo が提供していない言語の、有効なタグ |
| `A0047` | チェックアウト言語の形式が無効です | 構文の誤り、または余分なサブタグ |

値は `language[-script][-region]` 形式の IETF BCP 47 タグである必要があります。

* **language** — 2 文字の ISO 639-1 コードで、Waffo がサポートしているものでなければなりません。他の値を渡してもサポート対象は拡張されません。
* **script** — 任意。4 文字（ISO 15924）。指定する場合は Waffo が使用しているスクリプトでなければなりません。運用中のものは `Hant` と `Hans` です。
* **region** — 任意。2 文字の ISO 3166-1 alpha-2 コード。ここでは有効な国コードであれば何でも受け付けられ、地域はサポート一覧に制限されません。

それ以外はすべて `A0047` です。ハイフンの代わりのアンダースコア（`en_US`）、バリアントサブタグ（`de-DE-1996`）、私用拡張（`en-US-x-foo`）は、いずれも「未サポート」ではなく「形式不正」として却下されます。大文字小文字はエラーになりません。`en-us` は `en-US` に正規化されます。

## 通貨間の注文が為替レートのために却下されました。どのコードですか？

**`A0024`** — "Order can not be processed due to the fx rate is expired." です。

> [!WARNING]
>
> コードは `A0024` であり、`A0023` ではありません。`A0023` は **"Order cannot be created due to expired token"** で、カードトークンに関する全く別の失敗であり、対処法も全く異なります。期限切れまたは悪化した為替レートを `A0023` に対応付けている連携メモをお持ちなら、それは誤りです。修正してください。

通貨間の注文では、提示されたレートは注文作成時に検証されます。提示レートがもはや有効でない場合（期限切れ、または現在のレートが提示レートに対して不利な方向に動いた場合）、注文は**そのまま却下**されます。Waffo は新しいレートで注文を黙って再計算することはしません。貴社が価格を確定した後にユーザーの支払額が変わってしまうためです。

対処法：

1. `A0024` はリトライ可能として扱ってください。注文を再作成すれば、現在の提示レートが適用されます。
2. 長いチェックアウトのファネルにわたって提示レートを持ち越さないでください。価格の提示から注文作成までの間隔が長いほど、これが発生する頻度は高くなります。
3. UI が注文作成前に現地通貨の金額を表示していた場合は、更新後の金額をユーザーに表示してください。

レートの提示方法と有効期間については、
[決済・精算における為替レート](/docs/ja/support/exchange-rates-faq)をご覧ください。

## `A0023` と `A0024` の違い — コードコメントにそのまま貼れる要約はありますか？

| コード | メッセージ | 対象 | 対処法 |
| - | - | - | - |
| `A0023` | Order cannot be created due to expired token | カードの `tokenId` が使用できなくなった | カードを再トークン化します。[トークン化とカード決済](/docs/ja/support/tokenization-faq)をご覧ください |
| `A0024` | Order can not be processed due to the fx rate is expired | 通貨間の注文における為替の提示レート | 注文を再作成して現在のレートを取得します |

## 通貨間の一部返金が `A0014` で却下されました。金額は問題なさそうでした

**換算後**の金額を確認してください。通貨間の注文では、送信した返金額は検証前に換算され、換算後の金額が**ゼロ以下**になると、返金は `A0014`（"Order cannot be refunded due to refund rules"）で却下されます。

これは次の 2 つの状況で起こります。

* レートの差が大きい通貨ペアでの非常に小さな一部返金。換算後の金額が切り捨てでゼロになります。
* 想定より補助単位の桁数が少ない通貨。換算後の金額が丸めで完全に消えてしまいます。

`A0014` が**カバーしない**ものに注意してください。それは、残額を超える返金の要求です。すでに返金済みまたは処理中のすべての金額と合算して元の支払額を超える返金は、返金ルール違反ではなく、単なるパラメータ不正（`A0003 Parameter validation failed`）として却下されます。したがって通貨間の注文では、`A0014` は「換算後の金額が返金ルールを満たさなかった」、`A0003` は「要求額が多すぎた」と読み、どちらの場合も送信した数字ではなく換算後の数字を確認してください。換算ルールは
[為替レート](/docs/ja/support/exchange-rates-faq)に、決済手段ごとの返金ルールは
[決済手段別の返金制限](/docs/ja/support/payment-method-refund-limits-faq)にあります。

## `A0022` "multiple products are found" — 何を指定すればよいのですか？

商品（product）です。`A0022` は、要求した決済手段が貴社アカウント上の**複数の契約済み商品**に解決されることを意味します。たとえば、同じ決済手段をワンタイム決済とサブスクリプションの両方で契約している場合です。Waffo はどちらを意図したかを推測しないため、誤った商品で注文が作成される代わりに、注文は却下されます。

対処法は、`paymentInfo` に `productName` を送信し、契約がちょうど 1 件だけ一致するようにすることです。`payMethodType`、`payMethodName`、`payMethodCountry` で一致を絞り込む方法を含むパラメータの組み合わせについては、
[チェックアウトのカスタマイズ](/docs/ja/developer-docs/integration/checkout/customization)をご覧ください。

## 為替レートが動くと、契約した金額限度額も変わりますか？

いいえ。契約上の注文金額の最小値と最大値は**固定値**です。これらは決済手段が貴社アカウントに契約された時点で一度だけ計算され、その後は為替レートに連動して動くことはありません。通貨間の注文でも同様です。

知っておくとよい 2 つの詳細：

* 貴社の価格設定通貨が決済手段自体の通貨と異なる場合、上下限は契約時に換算され、その後は固定されます。最小値はその通貨の補助単位に**切り下げ**られ（ゼロにはなりません。下限は 1 補助単位です）、最大値は**切り上げ**られます。
* 貴社がアカウントに対して要求する限度額は、システムが計算した範囲の**内側**に収まっている必要があります。貴社の範囲はその部分集合であり、より広くなることはありません。より広い範囲を要求した場合、設定は丸められるのではなく却下されます。

したがって、レートの変動が金額の却下の理由になることはありません。以前は通っていた金額が今は失敗する場合は、為替ではなく、アカウントレベルの日次限度額（`A0021`）または設定変更を確認してください。値の確認方法は
[よくあるエラーのトラブルシューティング](/docs/ja/support/errors-troubleshooting-guide)にあります。

## 決済が限度額のために失敗しましたが、私の限度額ではありません。これは何ですか？

一部のウォレット決済手段は、**ユーザー自身のウォレット**に限度額を設けています。最も一般的なのは、ユーザーがそのウォレットで支出できる年間上限です。ユーザーがこれに達すると決済は失敗し、これを許可するために貴社や Waffo が設定できるものは何もありません。

対処法：

* ユーザーには中立的なメッセージを表示し、同じ決済手段をリトライするのではなく、別の決済手段を提案してください。
* これらを貴社自身の限度額や連携の健全性の指標に含めないでください。これはユーザー側の問題です。
* 上限を回避するために注文を小さな決済に分割しようとしないでください。年間上限は分割では回避できず、ユーザー体験を損ねるだけです。

## Portal に Settlements、Fees、Settlement Cycle が表示されないのはなぜですか？

貴社が何を契約しているかによるものです。加盟店 Portal の一部は、ロールではなく契約済みの商品によって制御されており、Admin であっても付与することはできません。メニューレベルの一覧表は
[加盟店 Portal の操作](/docs/ja/support/portal-operations-faq)をご覧ください。

メニューに加えて、**ゲートウェイのみ**の契約形態（契約済み商品が Direct Payment のみで他に何もない）の加盟店では、精算関連の**列**も表示されなくなります。

| 場所 | 非表示になるもの |
| - | - |
| PayIn（決済手段の設定） | `Fees` 列と `Settlement Cycle` 列 |
| Refunds 一覧 | `Settlement Status` 列 |
| ナビゲーション | Settlements、Balance、Withdrawal および関連するサブメニュー |

これは不具合ではなく想定どおりの動作です。精算商品がなければ、精算サイクルも、表示すべき手数料体系も、報告すべき精算ステータスもありません。貴社側で切り替えられるものは何もありません。注文と返金のデータ、エクスポート、Webhook には影響しません。

精算データが表示されるはずなのに表示されない場合、サポートに尋ねるべき質問は「私のアカウントはどの商品を契約していますか」であり、「メニューを付与してください」ではありません。

## ある決済手段がサンドボックスでは動くのに、本番環境では失敗します

これは設計上あり得ることで、サンドボックスの違いの中で最も人を驚かせる点です。**サンドボックスには、本番環境で稼働していない決済手段や設定が意図的に含まれています**。これは、決済手段が実トラフィック向けに有効化される前に、連携やエンドツーエンドのテストを開始できるようにするためです。

したがって：

* **サンドボックスで利用できることは、本番環境で利用できることの証拠にはなりません。**
* 本番環境のカバー範囲は、サンドボックスの動作ではなく、貴社の契約（Portal の PayIn ページ、または本番環境に対する `/api/v1/paymethodconfig/inquiry`）で確認してください。
* サンドボックスでは動くのに本番環境で `A0018` を返す決済手段は、通常これが原因であり、連携のバグではありません。

その他のサンドボックスと本番環境の違いは
[サンドボックステスト](/docs/ja/support/sandbox-testing-faq)にあります。

## ユーザーは WeChat Pay の継続課金をどのように承認しますか？

ユーザーの利用環境に応じて、次の 2 つのフローのいずれかで行われます。

| ユーザーの環境 | 署名フロー |
| - | - |
| デスクトップ Web | ユーザーがコードをスキャンして承認します |
| モバイルブラウザ | ユーザーが H5 ページで承認します |

承認が成立すると、Waffo はユーザーのさらなる操作なしにその承認に対して継続的な金額を課金します。ユーザーまたは貴社は承認を終了でき、課金された注文は全額または一部を返金できます。サブスクリプションの仕組み自体（プラン変更、引き落とし失敗、リトライ、通知）は
[サブスクリプション FAQ](/docs/ja/support/subscription-faq)にあります。

存在するのは上記の 2 つのフローのみです。アプリ内、ミニプログラム、クライアント内の承認も挙げている設計に基づいて構築している場合、それらは利用できません。

## 初回決済の返金で、継続課金のシリーズ全体が停止することがありますか？

はい。カードの継続課金シリーズではそうなります。そしてこれは、数か月後に最も驚かされる可能性の高い失敗モードです。

| シリーズの初回決済に起こること | シリーズへの影響 |
| - | - |
| **全額返金** | シリーズは**終了**します。以降、このシリーズに対して継続課金を行うことはできません |
| 不正取引または異議申し立ての取引から参照された | シリーズは**終了**します |
| **一部返金** | 影響なし。シリーズは継続します |

つまり、カスタマーサービスが初回課金を全額返金すると、貴社の記録上はまだ有効と表示されていても、決済レベルでは顧客のサブスクリプションが静かに終了してしまいます。2 つの安全策：

1. 補償金額が許す場合は、一部返金を優先してください。
2. 初回課金を全額返金する場合は、シリーズは終了したものとして扱い、顧客が継続する場合は承認を再確立してください。

## ユーザーがどのデバイスを使っているかをチェックアウトに伝える必要がありますか？

いいえ。Waffo のチェックアウトはユーザーのデバイスを検出し、表示方法を自ら選択します。

| ユーザーのデバイス | チェックアウトの動作 |
| - | - |
| モバイルブラウザ | 決済アプリまたは決済ページにリダイレクトします |
| デスクトップブラウザ | ユーザーがスキャンするための QR コードを表示します |

このためにデバイス、端末、認証モードのパラメータを渡す必要はありません。間違えるものも、決済手段の動作が変わったときに同期を保つべきものもありません。一部のアプリ型ウォレット決済手段では、モバイルでさらに一歩進み、チェックアウトがユーザーの選んだ特定のアプリに直接ディープリンクするか、OS のアプリ選択画面に引き渡します。

貴社が制御*できる*のは、そもそもどの決済手段を表示するかです。
[チェックアウトのカスタマイズ](/docs/ja/developer-docs/integration/checkout/customization)と[チェックアウト表示ルール](/docs/ja/support/cashier-display-rules-faq)をご覧ください。

## トークン化せずにカードで課金しました。後で同じカードに再度課金できますか？

いいえ。`tokenId` なしで行われたカード決済は、**顧客起点のワンタイム取引**です。そのカードに再度課金できるようなものは何も保持されないため、この決済には加盟店起点の後続処理を行う能力はありません。

後でカードに再度課金するには、まずトークン化する必要があります。トークン化フローを完了し、有効な `tokenId` を保持し、その後の課金でそのトークンを参照してください。完了済みの通常のカード決済を事後的にトークンに変換する方法はありません。ユーザーがカード紐付けを行う必要があります。

トークンのライフサイクル全体、CIT/MIT の区別、`AUTHORIZATION_REQUIRED` のケースについては
[トークン化とカード決済](/docs/ja/support/tokenization-faq)をご覧ください。

## 次はどこを見ればよいですか？

| 質問 | ページ |
| - | - |
| `A0001`、`A0002`、`A0003`、`A0018`、`E`xxxxx、Webhook のリトライ | [よくあるエラーのトラブルシューティング](/docs/ja/support/errors-troubleshooting-guide) |
| 通貨間の注文がどのレートをどれだけの期間使うか | [決済・精算における為替レート](/docs/ja/support/exchange-rates-faq) |
| `A0017` と `A0014` の背後にある決済手段ごとの返金ルール | [決済手段別の返金制限](/docs/ja/support/payment-method-refund-limits-faq) |
| Portal のメニュー、ロール、加盟店ごとに異なる理由 | [加盟店 Portal の操作](/docs/ja/support/portal-operations-faq) |
| サンドボックスの認証情報、シミュレーター、テストカード | [サンドボックステスト](/docs/ja/support/sandbox-testing-faq) |
| トークン、CIT、MIT | [トークン化とカード決済](/docs/ja/support/tokenization-faq) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.