Portal で 1 つの精算通貨に 2 つの口座番号が表示されるのはなぜですか？
精算アカウントは 2 つのサブアカウントに分割できるためで、貴社のアカウントが分割されている場合、Portal には両方が表示されます。各アカウントにはaccountSubType が付いています。
3 つのうちどれが貴社に適用されるかはアカウントの設定方法によって決まり、貴社が変更する設定ではありません。理解しておくべき 2 つの結果があります。
REGULATED_CORPORATEの場合、通貨ごとに1 つの口座番号が表示され、すべてが単一の資金プールとして動作します。REGULATEDとCORPORATEが別々のアカウントである場合、同じ通貨について2 行が表示され、それぞれに固有の口座番号と固有の利用可能残高があります。その通貨における貴社の合計ポジションは両者の合計であり、単一の行にそれが表示されることはありません。
subAccounts リストとして返されるため、subAccounts リストが空でない行は親であり、その残高の詳細は子にあります。
overdraftLimit と availableOverdraftLimit とは何ですか？
各アカウントにはオーバードラフト（当座貸越）枠が設定されている場合があり、2 つのフィールドで報告されます。
これらは、何も問題が起きていないのに残高がマイナスになり得る理由を説明するものです。チャージバックとチャージバック手数料は、貴社の残高に対して一定の順序で充当が試みられ、その順序の最後にオーバードラフトを利用することがあり、その後に入金される資金によって解消されます。その順序については 残高とアカウント履歴 をご覧ください。
注視すべき数値は
overdraftLimit ではなく availableOverdraftLimit です。枠は消費されるものであるため、設定された限度額が大きくても現在の余裕については何も分かりません。オーバードラフト枠はアカウント設定の一部であり、セルフサービスで変更できる項目ではありません。ご相談はサポートまでお問い合わせください。
1 件の出金申請から 2 件の支払いが発生したのはなぜですか？
資金が両方のサブアカウントから拠出されたためです。これは、貴社の精算アカウントが統合（REGULATED_CORPORATE）タイプであり、かつ一方のサブアカウントだけでは金額をカバーできない場合にのみ発生します。
常に規制対象側が先に引き落とされます。各レグはそれぞれ固有の金額を持つ独立した対外支払いとなるため、貴社の銀行取引明細には 1 件の出金申請に対して 2 件の入金が表示されることがあり、同時に着金しない場合もあります。
**出金手数料は 2 回ではなく 1 回課金されます。**出金が分割される場合、手数料全額は 2 つのレグのうち大きい方に乗り、もう一方のレグには手数料がまったく付きません。したがって、分割された出金を照合する際に、各レグが独立して差額なく一致することを期待しないでください。一方のレグは手数料全額分だけ少なく見え、もう一方は正確に見えます。申請額と比較する前に、両レグを合算してください。
残高 API にもサブアカウントは表示されますか？
いいえ。そしてこれが混乱を招く違いです。/api/v1/account/balance/inquiry は accounts[] に通貨ごとに 1 エントリを返します。
availableBalance は保存された値ではなく、導出された値です。
reserveBalance は Reserve の不足分であり、その絶対値は Reserve が再び充足するまで出金可能額から留め置かれます。ゼロまたはプラスの reserveBalance が availableBalance を減らすことはありません。
リクエストで currency を省略すると、1 回の呼び出しですべての精算通貨を取得できます。
つまり、API のビューは通貨単位であり、Portal のビューはサブアカウント単位になり得ます。Portal に 2 つの口座番号が表示されるところで API が 1 つしか表示しなくても、どちらも間違いではありません。口座番号ではなく、通貨ごとの合計で照合してください。
Account History の正しい業務タイプは何ですか？
6 つあり、Portal が提供するフィルターリストは次のとおりです。
スペルにご注意ください。
WITHDRAW ではなく WITHDRAWAL です。
最後の 3 つが重要なのは、Reserve の変動が台帳に表示される形だからです。精算タイプや調整タイプの下に Reserve の活動が見つかることを期待して Account History をフィルターしていた場合は、代わりに RESERVE_* の値でフィルターしてください。古い行には、現在は生成されなくなったタイプ（両替が出金より前に移動する以前の FX Conversion 行）が残っている場合があるため、すべての変動を突き合わせようとする際はまずフィルターなしで照会し、その後絞り込んでください。
Account History はReserve口座も対象ですか、精算アカウントだけですか？
どの画面・インターフェースを見ているかによります。
アカウントタイプの値は次のとおりです。
同じ 2 つの値が
/api/v1/account/history/inquiry のリクエストと返される各行の両方で受け付けられるため、混在した結果セットの中で Reserve の変動と精算の変動を区別する手段が accountType です。行には accountNo、businessId（変動の原因となった取引）、amount、currency、accountDirection（DEBIT / CREDIT）、newBalance（変動直後の残高）、transactionTime も含まれます。
精算アカウントが分割されている場合、Portal のビューではさらに REGULATED または CORPORATE でフィルターしてサブアカウント単位に絞り込むことができます。統合タイプはフィルターの選択肢にはありません。統合アカウントは 1 つのアカウントであり、絞り込むものがないためです。
照会できる日付範囲と、エクスポートできる内容は何ですか？
エクスポートの方が制約が厳しいため、広い範囲を照会してからエクスポートしようとするのではなく、月ごとに区切って照合を計画してください。エクスポートは
account_history_{merchant id}_{from}_{to}.csv という名前の CSV です。
返金の処理手数料はいつ返還されますか？
返金時に元の決済の処理手数料の一部が返還されるかどうかは契約設定であり、2 つの状態があります。REFUND_BY_RATIO の場合、返還される手数料は元の注文金額に対する返金額の比率で按分され、貴社の精算通貨の小数精度で切り捨てられます。各部分返金は元の注文に対して独立して計算され、常に切り捨てられるため、複数回の部分返金の合計は、1 回の全額返金の場合よりわずかに少なくなることがあります。その差は丸めによるものであり、記録の欠落ではありません。
精算レポートでは、返還された手数料はその期間の手数料合計を減少させます。その数値がどこに反映されるかは 精算レポート をご覧ください。
返金手数料がまったく返還されませんでした。何が妨げているのですか？
1 つの厳格なルールが適用されます。**決済の手数料通貨と返金の手数料通貨は一致していなければなりません。**一致しない場合、返金に黙ってゼロの手数料返還が付くのではなく、そのバッチの精算処理が失敗して調査対象となるため、解決されるまでその変動は貴社の明細にまったく表示されません。同じチェックにより、元の決済の精算通貨が、それが清算されるバッチの精算通貨と一致することも求められます。 手数料返還を期待していた返金が、ゼロの手数料返還付きで表示されるのではなく精算から完全に欠落している場合、サポートに問い合わせるべきなのはこのチェックです。返金 ID と元の注文 ID をお伝えください。 それ以外では、方針がNO の場合は単に手数料返還が適用されません。
チャージバック手数料は常に USD ですか？
いいえ。チャージバック手数料の通貨は貴社の加盟店設定に基づき、各案件でfeeAmount の隣に feeCurrency として返されます。USD に固定されているわけではなく、貴社の精算通貨と一致する必要もありません。
手数料通貨が精算通貨と異なる場合、手数料は精算時に、その精算固有のレートで精算通貨に換算されます。案件が開かれた時点で取得されたレートではありません。両者が一致する場合、換算は行われません。チャージバックの元本とチャージバック手数料は別々のレート基準で換算されるため、通貨をまたぐ案件では、金額と手数料が単一のレートを使ったようには見えません。
その結果、明細に予期しない通貨のチャージバック手数料が、換算後の数値と並んで表示されることは正当にあり得ます。結果として生じる精算行のラベル付けについては、
チャージバック項目リファレンス
をご覧ください。