バーチャル口座とは何ですか？リダイレクト型の決済とフローはどう違いますか？
VA 決済では、Waffo はユーザーを決済ページへ送る代わりに、その注文のために生成された銀行口座番号を返します。ユーザーはその番号宛てに、自身の銀行アプリ、ATM、または店頭から振り込みます。これは貴社のセッションからも Waffo のセッションからも完全に外で行われます。 貴社側で対応を作り込む必要がある影響は次のとおりです。
チェックアウト上の関連する決済手段タイプには、
VA（バーチャル口座）と、ユーザーが窓口で現金で支払う店頭払いタイプがあります。VA の決済手段のみを表示するためのカスタマイズパラメータは、Checkout のカスタマイズに記載されています。
VA 番号の有効期間はどのくらいですか？自分で制御できますか？
VA は、有効期限を決済手段側で固定するのではなく、注文で実際に設定できる数少ない決済手段ファミリーの 1 つです。VA の決済手段がそれに対応している場合：- 有効期限の枠は数日程度に上限が設けられています。各行が受け付ける正確な範囲は、Service → Payin の
Order Expiry Customization列に表示されます（Payin 契約と取引限度額を参照）。 - 指定しない場合は、その決済手段のデフォルトが適用されます。
orderExpiredAt のガイダンスがそれを扱っています。Merchant Portal の PayIn ページには、決済手段ごとの有効期限の挙動が表示されます。
VA 番号は自分の注文に固有のものですか？他人の支払いがその番号に着金する可能性はありますか？
注文の有効期間内では、口座番号は一意です。その注文にのみ属し、他のものには属しません。 注文の有効期限が切れると、その保証は終わります。数か月後に同じ口座番号が、別の注文のために発行されて再び現れることがあります。したがって：- VA 番号を、顧客・注文・Invoiceの永続的な識別子として扱わないでください。
- VA 番号を保存し、注文の有効期限が切れた後にそれに対して照合しないでください。
- 期限切れの VA 番号をユーザーに再表示しないでください。また、以前の注文のために渡した番号に対してユーザーが支払えるようにしないでください。新しい注文を作成して再発行してください。
ユーザーが誤った金額を入力した、または期限切れ後に番号を使いました。注文はもう無効ですか？
いいえ。どちらの場合も、貴社の注文に何かが届く前に、銀行側で拒否されます。
銀行は振込を受け付ける前に口座番号と金額を検証するため、誤った試行は通常、送信すらできません。注文ステータスは影響を受けず、注文が有効な間はユーザーは正しい金額で再試行できます。
サポート対応での実務的な回答は次のとおりです。「お客様の振込は受け付けられていません。注文はまだ有効です。期限までに表示された金額どおりに振り込んでください。」
ユーザーが注文金額より多く支払いました。何が起こりますか？
実際に受け取った金額を報告する銀行振込の決済手段では、過払いは受取金額が貴社の請求金額より大きい成功注文になります。結果通知には両方の数値が含まれるため、差額は貴社側で確認できます。 これが意味すること：- 注文は支払済みで履行可能です。配送を止める例外として扱わないでください。
- 余剰分は、決済手段が自動的に戻すものではありません。
- 余剰分をユーザーへ返すのは加盟店側のアクションです。決済手段によっては API 経由ではまったく返金できない場合があり、その場合は決済の外で精算されます。
ユーザーが注文金額より少なく支払いました。それでも履行できますか？
期限内に不足分が補われた場合のみです。不足払いは別個の結果として報告されます。通知には受取金額が不足していた旨と不足額が含まれ、次の 2 つのいずれかで解決します。
つまり、不足払いの注文はすぐに失敗になるわけではなく、すぐに支払済みになるわけでもありません。不足している間は履行を保留してください。最終的に失敗になった場合、すでに振り込まれた金額はユーザーへ返す必要があります。これも加盟店側のアクションであり、失敗した銀行振込を API で返金できない決済手段では、元の決済の外で行います。
最もトラブルを減らす 2 つのルール：
- 不足払いの通知で履行しないでください。最終状態を待ってください。
- 不足額の通知で話が終わったと思わないでください。ユーザーはまだ完了させる可能性があります。
これはステーブルコインの過払い・不足払いと同じですか？
形は同じですが、扱いは異なります。どちらも「着金した金額が請求金額と異なる」ケースであり、どちらも支払者が金額を制御しているために存在します。しかし解決の経路は十分に異なるため、両方に同じコードパスを流用すべきではありません。
ステーブルコインのルールはステーブルコインの例外と返金にあります。このページから推測するのではなくそのページを読んでください。逆も同様です。
銀行振込の注文を API 経由で返金できますか？
常にできるわけではありません。最初の返金依頼が来てからではなく、決済手段を受け入れる前に確認しておく価値があります。複数の銀行振込系決済手段は返金 API では一切返金できません。資金が可逆的な経路で入ってきていないため、取り消すものがないのです。API で返金できる場合でも、一部の決済手段では追加のユーザー情報（銀行口座情報）が必要です。資金は元の決済の取り消しではなく振込で返されるためです。
自社コード内で決済手段の名称からどのケースに当たるかを判断しないでください。必須フィールドは設定であり、決済手段から推測できる属性ではありません。返金を送信し、レスポンスで分岐してください。完全なルールは決済手段別の返金制限と返金 FAQにあります。
店頭払いも同じように動作しますか？
おおむねそうです。ユーザーはセッションの外で支払い、結果は 2 段階で届き、長い保留期間は正常です。違いはユーザーに渡すものです。店頭払いの決済手段は、口座番号の代わりに、ユーザーが窓口で提示する支払いコードと、どこでどのように支払うかを説明する一連の指示を返します。 実務上の 2 つのポイント：- 指示はテキストとコードであり、描画を当てにできる画像やリンクではありません。永続的な場所に置いてください。ユーザーは数時間から数日後に支払うため、通常はメールが答えになります。
- 注文は、このページのすべての事項について VA の注文と同様に動作します。早期にキャンセルせず、経過時間を失敗と見なさず、最終通知を待ってください。
数時間保留中のままの銀行振込の注文はキャンセルすべきですか？
いいえ。VA、銀行振込、店頭払いの決済では、ユーザーが自分のスケジュールで支払うため、長い保留期間が通常のケースです。早期のキャンセルは、あり得る中で最悪の失敗モードを生みます。貴社側で注文が閉じられている一方で、資金はまだ向かっている途中という状態です。 最終通知を待つか、/api/v1/order/inquiry をポーリングしてください。長時間保留のケースについては決済結果の確認を、タイムアウトが何を示し何を示さないかについてはタイムアウトと結果が確定するタイミングを参照してください。
VA または店頭払いの注文を作成した後、ユーザーに何を表示すべきですか？
振込を完了するために必要なすべてを表示し、静かに期限切れになるものは表示しないでください。- 返されたとおりの口座番号または支払いコードを、ユーザーがコピーできる形式で。
- 通貨と小数を含む正確な金額。金額の不一致は銀行に拒否されるため、精度は見栄えの問題ではありません。
- 期限を、生のタイムスタンプではなくユーザー自身の言葉で（「…までにお支払いください」）。
- 支払いは即時ではなく、振込の受領後に確認される旨の注記。