A0001、A0002、A0003、A0018、および Exxxxx 系）を扱っています。このページでは、それ以外の注文作成時の却下（限度額、通貨、言語、為替、設定）を扱い、続けて、エラーコードは一切出ないのに同じ「なぜ〜できないのか」というお問い合わせを生む設定関連の質問を扱います。
どのエラーコードがどの限度額に対応しますか？3 種類あって区別がつきません
これらは異なるレベルでチェックされる 3 つの異なる上限です。同じものだと読んでしまうことが、加盟店が誤った設定を「修正」してしまう典型的な原因です。
ここから 3 つのことが導かれます。
A0020とA0021は注文通貨ごとです。ある通貨の限度額を引き上げても、別の通貨には何の影響もありません。A0021は当日すでに受け付けた取引量に依存するため、同じリクエストが朝には成功し、夕方には失敗することがあります。すぐにリトライしても解決しません。翌日にリトライすれば解決します。A0008は決済手段の範囲であり、アカウントの限度額ではありません。範囲の確認方法は よくあるエラーのトラブルシューティングで扱っています。
契約していない通貨を送信しました。A0007 が返りますか？
いいえ。返るのは A0018 “Payment method in merchant order does not match with current merchant contract” です。通常の注文作成経路には、通貨固有の却下は存在しません。契約の検索は貴社のマーチャント ID と注文通貨の組み合わせで照合されるため、いずれの契約にも含まれない通貨では照合できる契約が単に存在せず、その失敗は決済手段の不一致として報告されます。メッセージは誤解を招きますが、原因は通貨です。
A0007 “Transaction currency is not supported” はエラー表に存在しますが、精算通貨を 1 つしか受け付けない特殊なステーブルコインプロトコルの決済経路のために予約されています。通常の注文を作成していて通貨の問題に遭遇した場合、デバッグすべきコードは A0018 です。
/api/v1/paymethodconfig/inquiry は契約ごとに 1 件のエントリを返し、それぞれに固有の currency があります。リクエストを組み立てる前に、課金しようとしている通貨で照合してください。通貨に起因して A0018 になるパターンは、
通貨を有効化する必要がありますか？で順に説明しています。
A0026 と A0047 — cashierLanguage の何が間違っているのですか？
これらは「存在しない言語を要求した」と「有効な言語タグではない」を区別しています。
値は
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.” です。
通貨間の注文では、提示されたレートは注文作成時に検証されます。提示レートがもはや有効でない場合（期限切れ、または現在のレートが提示レートに対して不利な方向に動いた場合）、注文はそのまま却下されます。Waffo は新しいレートで注文を黙って再計算することはしません。貴社が価格を確定した後にユーザーの支払額が変わってしまうためです。
対処法：
A0024はリトライ可能として扱ってください。注文を再作成すれば、現在の提示レートが適用されます。- 長いチェックアウトのファネルにわたって提示レートを持ち越さないでください。価格の提示から注文作成までの間隔が長いほど、これが発生する頻度は高くなります。
- UI が注文作成前に現地通貨の金額を表示していた場合は、更新後の金額をユーザーに表示してください。
A0023 と A0024 の違い — コードコメントにそのまま貼れる要約はありますか？
通貨間の一部返金が A0014 で却下されました。金額は問題なさそうでした
換算後の金額を確認してください。通貨間の注文では、送信した返金額は検証前に換算され、換算後の金額がゼロ以下になると、返金は A0014（“Order cannot be refunded due to refund rules”）で却下されます。
これは次の 2 つの状況で起こります。
- レートの差が大きい通貨ペアでの非常に小さな一部返金。換算後の金額が切り捨てでゼロになります。
- 想定より補助単位の桁数が少ない通貨。換算後の金額が丸めで完全に消えてしまいます。
A0014 がカバーしないものに注意してください。それは、残額を超える返金の要求です。すでに返金済みまたは処理中のすべての金額と合算して元の支払額を超える返金は、返金ルール違反ではなく、単なるパラメータ不正（A0003 Parameter validation failed）として却下されます。したがって通貨間の注文では、A0014 は「換算後の金額が返金ルールを満たさなかった」、A0003 は「要求額が多すぎた」と読み、どちらの場合も送信した数字ではなく換算後の数字を確認してください。換算ルールは
為替レートに、決済手段ごとの返金ルールは
決済手段別の返金制限にあります。
A0022 “multiple products are found” — 何を指定すればよいのですか？
商品（product）です。A0022 は、要求した決済手段が貴社アカウント上の複数の契約済み商品に解決されることを意味します。たとえば、同じ決済手段をワンタイム決済とサブスクリプションの両方で契約している場合です。Waffo はどちらを意図したかを推測しないため、誤った商品で注文が作成される代わりに、注文は却下されます。
対処法は、paymentInfo に productName を送信し、契約がちょうど 1 件だけ一致するようにすることです。payMethodType、payMethodName、payMethodCountry で一致を絞り込む方法を含むパラメータの組み合わせについては、
チェックアウトのカスタマイズをご覧ください。
為替レートが動くと、契約した金額限度額も変わりますか？
いいえ。契約上の注文金額の最小値と最大値は固定値です。これらは決済手段が貴社アカウントに契約された時点で一度だけ計算され、その後は為替レートに連動して動くことはありません。通貨間の注文でも同様です。 知っておくとよい 2 つの詳細：- 貴社の価格設定通貨が決済手段自体の通貨と異なる場合、上下限は契約時に換算され、その後は固定されます。最小値はその通貨の補助単位に切り下げられ（ゼロにはなりません。下限は 1 補助単位です）、最大値は切り上げられます。
- 貴社がアカウントに対して要求する限度額は、システムが計算した範囲の内側に収まっている必要があります。貴社の範囲はその部分集合であり、より広くなることはありません。より広い範囲を要求した場合、設定は丸められるのではなく却下されます。
A0021）または設定変更を確認してください。値の確認方法は
よくあるエラーのトラブルシューティングにあります。
決済が限度額のために失敗しましたが、私の限度額ではありません。これは何ですか？
一部のウォレット決済手段は、ユーザー自身のウォレットに限度額を設けています。最も一般的なのは、ユーザーがそのウォレットで支出できる年間上限です。ユーザーがこれに達すると決済は失敗し、これを許可するために貴社や Waffo が設定できるものは何もありません。 対処法：- ユーザーには中立的なメッセージを表示し、同じ決済手段をリトライするのではなく、別の決済手段を提案してください。
- これらを貴社自身の限度額や連携の健全性の指標に含めないでください。これはユーザー側の問題です。
- 上限を回避するために注文を小さな決済に分割しようとしないでください。年間上限は分割では回避できず、ユーザー体験を損ねるだけです。
Portal に Settlements、Fees、Settlement Cycle が表示されないのはなぜですか？
貴社が何を契約しているかによるものです。加盟店 Portal の一部は、ロールではなく契約済みの商品によって制御されており、Admin であっても付与することはできません。メニューレベルの一覧表は 加盟店 Portal の操作をご覧ください。 メニューに加えて、ゲートウェイのみの契約形態（契約済み商品が Direct Payment のみで他に何もない）の加盟店では、精算関連の列も表示されなくなります。
これは不具合ではなく想定どおりの動作です。精算商品がなければ、精算サイクルも、表示すべき手数料体系も、報告すべき精算ステータスもありません。貴社側で切り替えられるものは何もありません。注文と返金のデータ、エクスポート、Webhook には影響しません。
精算データが表示されるはずなのに表示されない場合、サポートに尋ねるべき質問は「私のアカウントはどの商品を契約していますか」であり、「メニューを付与してください」ではありません。
ある決済手段がサンドボックスでは動くのに、本番環境では失敗します
これは設計上あり得ることで、サンドボックスの違いの中で最も人を驚かせる点です。サンドボックスには、本番環境で稼働していない決済手段や設定が意図的に含まれています。これは、決済手段が実トラフィック向けに有効化される前に、連携やエンドツーエンドのテストを開始できるようにするためです。 したがって：- サンドボックスで利用できることは、本番環境で利用できることの証拠にはなりません。
- 本番環境のカバー範囲は、サンドボックスの動作ではなく、貴社の契約（Portal の PayIn ページ、または本番環境に対する
/api/v1/paymethodconfig/inquiry）で確認してください。 - サンドボックスでは動くのに本番環境で
A0018を返す決済手段は、通常これが原因であり、連携のバグではありません。
ユーザーは WeChat Pay の継続課金をどのように承認しますか？
ユーザーの利用環境に応じて、次の 2 つのフローのいずれかで行われます。
承認が成立すると、Waffo はユーザーのさらなる操作なしにその承認に対して継続的な金額を課金します。ユーザーまたは貴社は承認を終了でき、課金された注文は全額または一部を返金できます。サブスクリプションの仕組み自体（プラン変更、引き落とし失敗、リトライ、通知）は
サブスクリプション FAQにあります。
存在するのは上記の 2 つのフローのみです。アプリ内、ミニプログラム、クライアント内の承認も挙げている設計に基づいて構築している場合、それらは利用できません。
初回決済の返金で、継続課金のシリーズ全体が停止することがありますか？
はい。カードの継続課金シリーズではそうなります。そしてこれは、数か月後に最も驚かされる可能性の高い失敗モードです。
つまり、カスタマーサービスが初回課金を全額返金すると、貴社の記録上はまだ有効と表示されていても、決済レベルでは顧客のサブスクリプションが静かに終了してしまいます。2 つの安全策：
- 補償金額が許す場合は、一部返金を優先してください。
- 初回課金を全額返金する場合は、シリーズは終了したものとして扱い、顧客が継続する場合は承認を再確立してください。
ユーザーがどのデバイスを使っているかをチェックアウトに伝える必要がありますか？
いいえ。Waffo のチェックアウトはユーザーのデバイスを検出し、表示方法を自ら選択します。
このためにデバイス、端末、認証モードのパラメータを渡す必要はありません。間違えるものも、決済手段の動作が変わったときに同期を保つべきものもありません。一部のアプリ型ウォレット決済手段では、モバイルでさらに一歩進み、チェックアウトがユーザーの選んだ特定のアプリに直接ディープリンクするか、OS のアプリ選択画面に引き渡します。
貴社が制御できるのは、そもそもどの決済手段を表示するかです。
チェックアウトのカスタマイズとチェックアウト表示ルールをご覧ください。
トークン化せずにカードで課金しました。後で同じカードに再度課金できますか？
いいえ。tokenId なしで行われたカード決済は、顧客起点のワンタイム取引です。そのカードに再度課金できるようなものは何も保持されないため、この決済には加盟店起点の後続処理を行う能力はありません。
後でカードに再度課金するには、まずトークン化する必要があります。トークン化フローを完了し、有効な tokenId を保持し、その後の課金でそのトークンを参照してください。完了済みの通常のカード決済を事後的にトークンに変換する方法はありません。ユーザーがカード紐付けを行う必要があります。
トークンのライフサイクル全体、CIT/MIT の区別、AUTHORIZATION_REQUIRED のケースについては
トークン化とカード決済をご覧ください。