クイックリファレンスから得られない唯一のものは、あるコードがどの API ファミリーに属するかです。
そしていくつかのコードは、ファミリーによって異なる意味を持ちます。それが以下の最初の質問です。
同じエラーコードは、Waffo のどの API でも同じ意味ですか？
いいえ。 コードの数字部分のスコープはグローバルではなく、API ファミリーです。 特に 3 つのコードが罠になります。
したがって
/api/v1/payout/create での A0013 は、その payoutRequestId による先のリクエストが
まだ処理中であることを意味します。待ってから照会し、その後に再送してください。一方
/api/v1/order/cancel での A0013 は終端であり、再試行してはいけません。
コードは必ず、呼び出したエンドポイントのファミリーに照らして解決してください。
プレフィックスの意味はどこでも一定です。A は加盟店関連、B はユーザー関連、
C はシステム関連、D はリスクによる拒否、E は不明（最終ステータスが出るまで照会を
続けてください）です。
送金でどの受取人フィールドを送る必要があり、どれが payoutMethodProperty の中に入りますか？
要件は 受取国 × 送金手段 のマトリクスであって、API の性質ではありません。
payeeFirstName、payeeMiddleName、payeeLastName、payeeIDType が仕様上
conditional と宣言されているのは、まさにこの理由によります。
本人確認に関する 2 つのルールは、このマトリクスの外側、フィールド定義そのものに記載されています。
それ以外のすべての回廊では、受取人フィールドは国のルールではなく下流で検証されるため、
保有しているものはすべて送信してください。回廊がオンボードされるにつれてこのマトリクスには
行が追加されます。上限ではなく下限として扱い、実際に何が欠けているかは拒否によって
知ってください。
トップレベルではなく payoutMethodProperty に入るのはどのフィールドですか？
payoutMethodProperty はオブジェクトではなく JSON 文字列（最大 512 文字）で、
銀行のルーティング情報を受け付ける唯一の場所です。
受取人の口座識別子そのものは
payoutMethodProperty に入りません。それは
payoutInfo.payoutMethodUserAccountNo であり、その形式は payoutMethodType に依存します。
BANK_ACCOUNT では銀行口座番号、EWALLET ではそのウォレット自身の口座番号または公開の
ユーザー識別子です。payoutMethodName は EWALLET ではウォレット名、BANK_ACCOUNT では
空です。
作成 / 照会 / 通知のループそのものについては
送金 FAQ を参照してください。
送金の purpose にはどの値を指定できますか？
/api/v1/payout/create の purpose は、中国本土向けの送金では必須であり、その場合は
以下の値のいずれかである必要があります。それ以外の回廊では任意で、指定されたまま受取側に
渡されます。受け付けられる値は次のとおりです。
その支払いを本当に説明するものを選んでください。一部の回廊 — 特に中国本土 — では
これに対して検証が行われます。
隣接する 2 つの自由記述フィールドがよく混同されます。
description（最大 128 文字）は
受取人の銀行またはウォレットの明細に印字されるため、短く保ってください。銀行やウォレットは
これを切り詰めるため、実務上の上限はおよそ英単語 16 語または漢字 10 文字です。
extendInfo（最大 128 文字、JSON）はそのまま貴社に返され、受取人には決して届きません。
/api/v1/order/create の「任意」フィールドのうち、特定の決済手段で必須になるのはどれですか？
アクワイアリングの仕様では goodsInfo、addressInfo、そして userInfo の大半が任意とされています。
必須かどうかが、実際に使われる決済手段に依存するためです。payMethodType ごとに集約すると
次のとおりです。
これは契約としてではなく、規模感を掴むための情報として読んでください。同じ
payMethodType
でも市場によって異なることがあり、いくつかのセルが市場によると書かれているのはそのためです。
提供されるすべての場所で明細化されたカート全体を必要とするのは BNPL だけです。
Waffo のホスト型チェックアウトを使っている場合、この表はたいてい無視できます。 選ばれた
決済手段が、貴社が指定していないユーザー情報を必要とする場合、購入者はチェックアウトページに
リダイレクトされ、チェックアウトページがそれを収集します。この表が重要になるのは、フローに
チェックアウトページがない場合です。
信頼できるパターン — 送信し、返された欠落フィールドの一覧を読み、再送する — と、
要求されうるフィールドパスの完全な集合については
決済手段ごとの条件付き必須フィールド
を参照してください。
orderAction.actionData には何が含まれますか？
orderAction は、orderStatus = AUTHORIZATION_REQUIRED のとき、すなわち購入者にまだ
やることが残っているときに、/api/v1/order/create と /api/v1/order/inquiry から
返されます。actionType は WEB（購入者を webUrl にリダイレクトする）または
DEEPLINK（deeplinkUrl を開く）です。
actionData はリダイレクトの代替です。生の支払手段の情報を運ぶので、自前のチェックアウトページを
描画できます。どのレスポンスにも、選ばれた決済手段に関係する部分集合だけが現れます。
したがってすべてのフィールドを任意として扱い、存在するものを描画してください。
支払バウチャー関連のフィールド
金額と為替に関するフィールド
銀行振込に関するフィールド
バーチャル口座（注文ごとに生成される
bankAccount）は口座番号だけで消込できます。
共用の集金口座は referenceNumber で消込します。両方が返された場合は両方を表示し、
referenceNumber を購入者の必須入力として扱ってください。
エラーコード完全表 — 送金
/api/v1/payout/create、/api/v1/payout/inquiry、および送金の通知。
送金にないものにも注意してください。
A0015〜A0047 は存在しません。送金の
エンドポイントでそれらのいずれかを見たなら、見ている表が違います。
エラーコード完全表 — アクワイアリング
/api/v1/order/create、/inquiry、/cancel、/refund、/capture、
/api/v1/refund/inquiry、および決済と返金の通知。
アクワイアリングファミリーが最も広く、
クイックリファレンス
にはこの仕様のリビジョンを超える追加のアクワイアリングコードが掲載されています。両者が食い違う場合は、
クイックリファレンスのほうが新しい一覧です。
エラーコード完全表 — サブスクリプション
/api/v1/subscription/create、/inquiry、/cancel、/manage、/change、
/change/inquiry、/update、およびサブスクリプションの通知。
このファミリー固有で、明示的に処理する価値のあるコードが 2 つあります。
A0025
（サブスクリプションは 1 期間より長く継続する必要がある）と A0028
（初回の決済が確定する前に管理 URL を要求した）です。
エラーコード完全表 — 出金、残高、取引限度額ルール
/api/v1/account/balance/inquiry、/api/v1/account/history/inquiry、
/api/v1/withdraw/consult、/create、/inquiry、出金の通知、および
/api/v1/risk/transactionlimit/create、/update、/inquiry。
A0100〜A0102 はここにのみ存在し、取引限度額ルールのエンドポイントにのみ現れます。
一般的なクイックリファレンスには載っていないため、A0100 は A0010 の書き間違いでは
ありません。
これらのどの表にもないコードを受け取りました。これは何ですか？
署名付きの公開 API で Waffo が返すすべてのコードは、次のいずれかの形をしています。0、
または A〜E の 1 文字に続く 4 桁の数字です。それ以外の形の値 — より長い文字列、
異なるプレフィックス、英数字が混在した識別子 — は公開のエラー契約の一部ではなく、
貴社の連携で分岐の対象にすべきではありません。paymentRequestId / payoutRequestId と
ともにログに記録し、サポートに連絡 してください。
照会呼び出しから確定的なステータスが得られるまでは、その取引を E0001 と同じように
扱ってください。
公開の形をしているものの、呼び出したファミリーの表に載っていないコードについても同様です。
コードから結果を推測するのではなく、注文を照会してその本当のステータスを確認してください。