決済にはどの識別子があり、どれを伝えればよいですか？
4 つあり、互いに置き換えることはできません：
チケットを起票する際は、
Order Id を先頭に記載してください。お客様自身の注文 ID はクロスチェックには有用ですが、
プラットフォーム全体で一意ではないため、それだけでは追跡に時間がかかります。
返金には独自の識別子セットがあります — 下記を参照してください。
決済にはどのタイムスタンプがあり、なぜ 3 つあるのですか？
これらは意図的に分けられています。深夜 0 時の直前に作成され、直後に支払われた注文は、作成タイムスタンプが
ある日、決済日付が翌日になります。入金との照合には
Payment Date を、注文件数や上限による拒否の調査には
Created Datetime を使用してください — Payin 契約と取引上限
で説明しているとおり、日次取引上限は作成時点から数えます。
未設定のタイムスタンプは - と表示されるため、未払いの注文は作成時刻が表示され、他の 2 つはダッシュになります。
返金に加盟店注文 ID が 2 つ表示されます。どちらがどちらですか？
これらは異なるオブジェクトであり、混同することが最もよくある照合エラーです：
したがって、返金から販売まで遡るには
Merchant Original Order ID を使用します。お客様自身の返金指示を
追跡するには Merchant Order Id を使用します。
Merchant Original Order ID は、返金一覧、返金詳細の加盟店情報ブロック、返金エクスポートに表示されます。
値がない場合、Portal は - を表示します。
Waffo 側の識別子はそれらと並んで表示されます：返金自体のアクワイアリング注文 ID、返金リクエスト ID、
そして — 返金が一括処理から生じた場合 — Refund Batch ID（単独の返金では -）です。
元の決済の注文 ID で返金を検索できますか？
はい。merchantOriginalOrderId は返金一覧の複合検索セレクターのフィールドの 1 つで、前方一致や部分一致ではなく
完全一致で照合されます。元の注文 ID を丸ごと貼り付けてください。
何も返されない場合は、返金自体の ID ではなく元の決済の ID を検索しているか、値の末尾に空白がないかを
確認してください。
返金ボタンが表示されない、またはグレーアウトしているのはなぜですか？
3 つの状態があり、それぞれ意味が異なります：
ボタンがグレーアウトしている場合、次の 5 つの条件のいずれかを満たしていません：
処理中の返金は最後の 2 つに数えられることに注意してください。数秒前に提出した返金は、すでに枝数と金額の
両方を消費しているため、何も確定していない段階でボタンがグレーアウトすることがあります。
返金パネルと注文詳細のどちらにも
Remaining Refundable Amount が表示されるため、3 番目の数値を直接確認できます。
どの決済手段が返金に対応しているかは、Payin 契約ページ
にあります。
返金権限のないユーザーには、上記にかかわらずボタンは表示されません — Merchant Portal の操作
を参照してください。
Initiation Type 列とは何ですか？
Initiation Type は、カード取引を誰がトリガーしたかを分類します：
これは取引ごとの属性であるため、決済一覧に存在し、集計ビューには存在しません。
Initiation Type が常にダッシュで表示されるのはなぜですか？
値はそれでフィルターしたときにのみ設定されるためです。これは仕様であり、データの欠落ではありません：
つまりこの列はフィルターの確認であり、閲覧可能な属性ではありません。内訳を見るには、フィルターなしの一覧を
眺めるのではなく、値ごとに 1 回ずつ計 2 回クエリを実行してください。
またこの列は、サブスクリプションを契約しているアカウントにのみ存在します。この区別が意味を持つのはそこだからです。
一覧にまったく表示されない場合、それが理由です。
決済レコードにはどのカード情報が表示されますか？
決済手段がカードの場合、決済詳細の決済情報ブロックに：
これらの行はいずれも値がない場合は省略されます — ブロックは空のラベルを表示しません。
したがって
Issuing bank の行がないということは、その取引ではそのデータが利用できなかったことを意味し、
フィールドが削除されたわけではありません。カード以外の決済手段ではカード関連の行は一切表示されません。
値はその取引に対して記録されたものです。後から更新されることはないため、同じカードで別の時点に行われた
2 つの取引で値が異なることは正当にあり得ます。
Cardholder name はユーザーの個人データです。エクスポートや保存の際はそれに応じた取り扱いをしてください。
カード番号はどのようにマスクされますか？
先頭 6 桁、次にアスタリスク、最後に末尾 4 桁 — たとえば 16 桁の番号は、6 桁、6 個のアスタリスク、4 桁で 表示されます。短い値も安全に処理されます：6〜9 文字の値は先頭 6 文字を表示し残りをアスタリスクにします。 それより短いものはそのまま表示されます。 完全な番号は Portal でもエクスポートでも決して取得できず、それを表示する設定もありません。取引をまたいで カードを照合する必要がある場合は、完全な番号を期待するのではなく、マスク済みの値と有効期限、カードブランドを 組み合わせて使用してください。金額がダッシュで表示されるのはなぜですか？
Portal は、金額の数値と通貨の両方がある場合にのみ金額を表示します。いずれかが欠けている場合、セルには-
が表示されます。
これを知っておく価値があるのは、したがって - はゼロを意味しないからです。本当のゼロは通貨コード付きの
書式化された 0.00 として表示されます。ダッシュはペアが利用できなかったことを意味します。
金額と通貨はどのように書式化されますか？
エクスポートした数値を解析する場合は、記号ではなくコードに対して解析し、区切り文字の慣習が Portal の
言語設定に従うとは想定しないでください。
決済一覧に精算ステータス列がないのはなぜですか？
main にはありません。決済一覧には注文自体のステータス、作成と決済のタイムスタンプ、および — 該当する場合 — サブスクリプション ID がありますが、精算状態はありません。 精算ステータスは異議申し立て一覧では利用可能で、列とフィルターの両方として存在します。 決済単位の精算情報については、取引一覧ではなく精算レポートから確認してください： 精算レポート と 精算サイクル を参照してください。Order Failure Code と Order Failure Description とは何ですか？
失敗した注文にのみ表示され、同じ答えの 2 つの半分です：自社システムで分岐に使える安定したコードと、 それを人が読める形にした説明です。ロジックにはコードを、サポートとの会話には説明を使用してください。 よくある失敗原因とその対処は エラーとトラブルシューティング に、 上限による拒否については特に Payin 契約と取引上限 にまとめられています。決済レコードにサブスクリプション ID が表示されるのはなぜですか？
その決済がサブスクリプションの下で行われたためです。決済一覧には関連するサブスクリプション ID が含まれており、 1 件の課金からそれを生み出した契約まで遡ることができます。単発の決済では- になります。
逆方向 — サブスクリプションからその課金へ — については、
サブスクリプションのライフサイクル管理 を参照してください。
決済レコードにはどの手数料の数値が表示されますか？
決済詳細にはFees ブロックがあり、その取引に課された手数料が金額と手数料通貨で表示されます。手数料の算定基準
— 料率、固定額、下限・上限 — は取引上にはなく、
Payin 契約ページ にあります。
部分返金を含め、決済が返金された場合の手数料の動作については、返金 FAQ を参照してください。
ドキュメントに記載されているフィールドが Portal ではダッシュになっています。データが欠けていますか？
通常は欠けていません。Portal は 3 つの異なる状況で、N/A や空セル、ゼロではなく意図的に - を表示します。
これらを見分けることでサポートチケットを 1 件節約できます：
3 つのいずれも、レコードを再度開いても回復しません。2 番目に該当する場合は、該当するフィルターを付けて
クエリを再実行してください。