goodsInfo、addressInfo、および userInfo のいくつかのフィールドが
任意と記載されており、実際に裏側のオブジェクトにも長さ制限しかなく、必須制約はありません。
それでも、スキーマ検証を通過したリクエストが、これらのフィールドのいずれかを名指しして
A0003 Parameter validation failed で返されることがあります。以下で使用する payMethodType の値は
データリファレンス に一覧があります。
Optional と記載されているフィールドが、なぜ「不足」として拒否されるのですか？
「必須」かどうかは API の属性ではなく、実際に使用される決済手段と、お客様が置かれているシナリオの 属性だからです。ある連携ではカード決済を送信しgoodsInfo から何も必要としませんが、別の連携では
分割払い決済を送信し、明細付きの完全なカート情報が必要になります。単一のスキーマで両方を表すことはできません。
このことから 2 つの結果が生じます。
- 要件は決済手段だけで安定的に決まるものではありません。 同じ決済手段でも決済の処理方法によって 異なるフィールドが要求されることがあり、お客様側の変更なしにその集合が変わることもあります。そのため、 連携側にハードコードした決済手段ごとの一覧は、気づかないうちに古くなっていきます。
- 事前確認用の探索エンドポイントはありません。
/api/v1/paymethodconfig/inquiryは 利用可否、メンテナンス時間帯、金額範囲、通貨、返金ポリシーを返しますが、 フィールド要件は返しません。
では、正しいパターンは何ですか？
送信し、一覧を読み取り、再送信します。予測はしないでください。- 手元にあるすべての情報を含めてリクエストを送信します。
- 必須フィールドが不足している場合、呼び出しは
A0003で失敗します。A0003に限っては、 レスポンスのmsgに括弧付きでフィールドレベルの詳細が付加されます。/api/v1/order/refundでは、 不足しているパスがmissingFieldsの一覧としても返されます。 - ちょうどそのパスを埋めて再送信します。
userInfo.userFirstName、addressInfo.postcode、
goodsInfo.goodsUniquePrice — そのため、リクエストボディにそのまま対応付けられます。
ホスト型チェックアウトを使用している場合、通常これを目にすることはありません。 選択された決済手段が
お客様の送信していないフィールドを必要とする場合、Waffo は注文をチェックアウトへルーティングし、
チェックアウトが購入者に対してそれらの入力欄を表示します。上記のループが最も重要になるのは、フォールバック先の
チェックアウトが存在しない場合です。つまり、加盟店起点の取引（merchantInitiatedMode）と、
直接処理されるエージェント決済です。
不足フィールド一覧には、どのフィールドパスが現れうるのですか？
大まかに、どの決済手段タイプが何を要求しますか？
方向性を示すものにすぎません — データ収集の規模を見積もるには有用ですが、契約ではありません。 返された一覧に判断を委ねてください。同じ決済手段タイプでも市場によって要件は異なり、 これが静的な一覧が成り立たないもうひとつの理由です。これらのうち、実際に無条件で必須なのはどれですか？
単に必須であるフィールドに労力をかけないでください。/api/v1/order/create では、
userInfo.userId、userInfo.userTerminal、orderDescription がすべてのリクエストで必須です。
userInfo.userEmail は実質的に必須です。実際のアドレスを収集していない場合は、userId@examples.com の形式で
一意のフォールバック値を送信してください。共有値やプレースホルダー値はリスク管理に引っかかる可能性があるため、
決して使用しないでください。goodsInfo 内では、コンプライアンスとリスク審査のために、契約上 goodsUrl または
appName のいずれか（両方ではない）が期待されます。作成呼び出し自体はこれらの欠落を拒否しません。
拒否するのは決済手段の条件付きルールのみで、上記の不足フィールド一覧を通じて行われます。
決済手段ではなくシナリオによって決まる要件
どのように連携するかによって発生し、決済手段固有のルールが実行される前に検証されます。返金も同じ一覧を使用しますか？
いいえ。返金は独自の検証を行い、決済では決して必要としない本人確認情報や送金先情報を要求することがあります。 これは、資金が元の決済の取消ではなく送金によって戻されることが多いためです。そのため、返金リクエストはuserInfo（userBankInfo を含む）、addressInfo、extendInfo を受け付けます。送信して読み取るループは同じです。
フィールドは存在しているのに拒否されます。なぜですか？
書式ルールは、要求されたかどうかにかかわらず、送信するすべてのフィールドに適用されます。
長さ制限はこれとは別で、アクワイアリング仕様にフィールドごとに記載されており、
同様にフィールド名を含む
A0003 を発生させます。
レスポンスが要求したとおりに再送信しても、まだブロックされますか？
paymentRequestId と完全な A0003 メッセージを添えて
サポートにお問い合わせください。