注文にはどの金額フィールドが含まれますか？
すべての金額は数値ではなく文字列です。公開されている理由は浮動小数点の精度です：
0.1 + 0.2 は 0.3 になりません。これは金額としては許容できません。小数（decimal）としてパースしてください。
注文が自分の作成したものであることをどのように検証すればよいですか？
貴社自身のpaymentRequestId または merchantOrderId をキーにして、orderAmount + orderCurrency を送信した値と比較してください。この 2 つのフィールドは貴社自身の入力がエコーバックされたものなので、要求したものと等しいことが保証されている唯一のペアです。
finalDealAmount を期待金額と比較して検証してはいけません。これは設計上異なる量であり、まったく正常な 2 つの状況によって異なる値になります。それが次の質問です。
finalDealAmount が orderAmount と異なるのはなぜですか？
API 契約は 2 つの理由を挙げており、どちらも正常です：
- 注文通貨がユーザーの支払通貨ではない。 クロスカレンシー注文は、貴社が一方の通貨で価格設定し、ユーザーが別の通貨で支払うため、2 つの数値は異なる単位であり一致しません。
- ユーザーが追加のサービス手数料を支払った。 決済手段が支払者に手数料を課す場合、その手数料は
finalDealAmountに含まれるため、貴社の金額より大きくなります。
finalDealAmount は*「これはユーザーにいくらかかったか」に答え、orderAmount は「自分はいくら請求したか」*に答えます。商品の出荷と業務上の検証は orderAmount に基づいて行い、finalDealAmount はユーザーに支払額を表示したい場合にのみ使用してください。
orderCurrency と userCurrency は本当に異なることがありますか？
はい。それこそがクロスカレンシー注文です：貴社は自身の通貨で価格設定し、ユーザーは自身の通貨で支払います。これはエラー状態ではなく、特定の決済手段カテゴリーに限定されるものでもありません。公開されている定義とそれに伴うパラメーターは
金額と通貨にあります。注文作成の実務上のルールとして、payMethodType または payMethodName を固定していない場合、クロスカレンシー注文には payMethodCountry が必要ですが、userCurrency 自体は任意のままです。
貴社の照合処理が注文ごとに 1 通貨を前提としている場合は、最初から 3 つのフィールドを想定して構築してください：orderCurrency（貴社のもの）、userCurrency / userPaymentCurrency（ユーザーのもの）、そして貴社の精算通貨（精算計算の解説を参照）。
これらは 3 つの別々のものであり、注文時点で貴社が制御できるのは最初のものだけです。
ユーザーは自身の通貨で正確にいくら支払いましたか？
paymentInfo.payMethodResponse.userPaymentAmount と
paymentInfo.payMethodResponse.userPaymentCurrency です。このブロックは決済手段自身の取引に対する見方であり、以下も含まれます：
これは JSON 文字列であり、どのキーが存在するかは決済手段によって異なります。固定の形を想定するのではなく、防御的に読み取ってください。
ユーザーの純支払額を finalDealAmount からユーザー手数料を引いて計算できますか？
いいえ。照会レスポンスからはできません。userFeeAmount と userFeeCurrency は注文作成レスポンスの orderAction.actionData で返され、注文照会や決済通知のトップレベルフィールドとしては返されません。したがって、照合を行っている時点では通常、差し引くための手数料を独立した数値として持っておらず、そもそも 2 つの通貨をまたいだ減算は誤りです。
代わりに以下を使用してください：
- 正しい金額が請求されたか？ →
orderAmount+orderCurrency。 - ユーザーは合計でいくら支払ったか？ →
finalDealAmount、または決済手段側の数値としてはuserPaymentAmount。 - 手数料はいくらだったか？ → 後で必要な場合は、作成時に
actionData.userFeeAmountを取得して保存してください。
ユーザー手数料は店頭（over-the-counter）決済でのみ課されますか？
API はそのような範囲設定をしていません。userFeeAmount / userFeeCurrency は orderAction.actionData にあり、これは独自のチェックアウトを構築する加盟店向けのブロックであり、契約上これらを 1 つの payMethodType に限定するものは何もありません。手段のカテゴリーで判断するのではなく、支払者手数料はどの手段でも発生し得るものとして扱い、フィールドを読み取ってください。finalDealAmount と同じ助言です：読み取ること、推測しないこと。
Waffo のチェックアウトページを使用している場合、ユーザーはチェックアウト上で手数料を確認します。貴社が描画する必要はありません。
originalAmount とは何ですか？割引はどの金額に対して検証すればよいですか？
originalAmount は割引適用前の注文金額です。プロモーションコードまたはクーポンが使用された場合、orderAmount は割引後の支払うべき金額であり、originalAmount は貴社が価格設定した割引前の数値です。
したがって、業務上のチェック（権利付与、履行、「この SKU に対して十分に支払ったか」）には orderAmount を使用してください。それが実際に請求された金額だからです。originalAmount は表示用または割引の影響を測定するためだけに使用してください。返金時の割引の扱いを含むクーポンとプロモーションコードの仕組みは、
クーポンとプロモーションコードにあります。
財務はどの金額に対して照合すればよいですか？
orderAmount も finalDealAmount も単独では不適切です。これらは注文レベルのフィールドであり、手数料前、精算換算前のものです。資金の照合には、金額、手数料、精算通貨をまとめて含む精算レポートを使用してください：
精算レポートと
精算計算の解説。
注文レベルのフィールドは注文の照合のためのものです。つまり、作成した注文が支払われた注文であることを証明するためのものです。この 2 つの作業は分けてください。それが「あなたの数字と私の数字が一致しない」の最もよくある原因です。
注文は現地通貨で作成しなければなりませんか？
いいえ。orderCurrency は貴社の価格設定通貨であり、クロスカレンシー注文（貴社が一方の通貨で価格設定し、ユーザーが別の通貨で支払う）はサポートされている第一級のフローです。特定の決済手段が特定の注文通貨に対応できるかどうかは、貴社のアカウントの契約に依存します。これは推測ではなく、参照によって確認します：
そのレスポンスは契約をキーにしているため、1 つの決済手段が通貨ごとに複数回表示されることがあります。
payMethodName は一意なキーではありません。詳細は
決済手段の設定と限度額にあります。
ある決済手段が 1 つの通貨で掲載されています。それでも別の通貨で価格設定できますか？
2 つの通貨を分けて読み取ってください：- 支払通貨 — ユーザーに請求される通貨。ローカル決済手段の場合、これは事実上その手段自体によって固定されます。
- 注文通貨 — 貴社が価格設定し、貴社への請求と精算の基準となる通貨。
A0018 として返されます。
限度額、通貨、設定エラーをご覧ください。
クロスカレンシー注文の為替レートはどこで確認できますか？
2 つの異なるレート、2 つの異なるフィールドがあります：
これらは異なる質問に答えるものであり、異なる値になることがあります。レートがいつ確定するか、どれだけの期間有効か、返金にどのレートが使われるかはすべて
決済と精算における為替レートにあります。
小数は何桁まで送信できますか？通貨によって異なりますか？
はい、通貨によって異なり、同一通貨注文とクロスカレンシー注文でルールが異なります。公開されているルール：ほとんどの通貨は ISO 4217 に従って小数 2 桁を取り、一部の通貨は同一通貨注文では小数をまったく含めてはならず、クロスカレンシー注文ではすべての通貨が例外なく ISO 4217 の精度に従わなければなりません。完全なリストと拒否時の動作は 金額と通貨と 注文金額、限度額、拒否にあります。 決済手段ごとの金額範囲は精度とは別のチェックです。これらは契約上のorderAmountMin / orderAmountMax から来るため、エラーコードから限度額を知るのではなく、注文を作成する前にそれらに対して検証してください。
返金にはどの金額フィールドが含まれますか？
remainingRefundAmount は、貴社の記録から再計算するのではなく、「まだ返金できるか」という貴社自身のロジックを駆動するためのフィールドです。貴社自身が開始していないものも含め、その注文のすべての返金がすでに考慮されています。返金ルール自体は
返金 FAQと
決済手段別の返金制限にあります。
どのフィールドを比較すべきかまだ分からない場合は、
paymentRequestId と一致しない 2 つの数値を添えてサポートにお問い合わせください。