概要
InvoiceはBill Runで生まれ、Payment Runで回収されます。Zuora自身は決済処理を持たず、Payment GatewayとPayment Methodを組み合わせて回収サイクルを設計します。
支払いサイクルの全体像：
Payment Method — 支払い手段の設定
顧客のAccountにElectronic（カード・口座）またはExternal（現金・振込）のPayment Methodを登録します。Electronicのみが自動回収の対象です。
ElectronicとExternalの2種類
| 種類 | 処理方法 | 主な例 |
|---|---|---|
| Electronic | Payment GatewayがZuoraの指示で自動処理 | クレジットカード、デビットカード、口座振替（ACH）、SEPA、PayPal |
| External | 担当者が手動で入金を記録する | 現金、小切手、銀行振込、Wire Transfer |
AccountへのPayment Method設定
| 設定 | 内容 |
|---|---|
| Default Payment Method | Payment Runで自動回収するときに使われる支払い方法 |
| Backup Payment Method | Defaultが失敗したときの代替手段 |
トークン化（Tokenization）とPCI DSS
クレジットカードなどのElectronic Payment Methodを登録する際、実際のカード番号はZuoraには保存されません。代わりにGatewayが発行するトークン（無意味な識別子）だけがZuoraに保存されます。
| 項目 | 内容 |
|---|---|
| トークン | Gatewayが生成するカード番号の代替識別子。Zuora上ではこの値だけが保管される |
| PCI DSS | クレジットカード情報を扱う事業者に適用されるセキュリティ基準 |
| Zuoraの立場 | カード番号を保持しないため、PCI DSSの準拠スコープを最小化できる |
Payment Gateway — 決済処理の設定
ZuoraはGatewayにAPIクレデンシャルで接続し、決済処理を委譲します。Test modeで疎通確認後、Activeに切り替えて本番運用します。
Payment Gatewayとは
Payment Gatewayとは、クレジットカード・デビットカード・ACH/SEPA/PADなど電子決済の情報転送と処理を加盟店に代わって行うサービスです。ZuoraはGatewayの「指示役」として機能します。
Gatewayの設定項目
| 設定項目 | 内容 |
|---|---|
| Gateway種別 | Stripe・Braintree・Adyen・GMO等から選択 |
| APIクレデンシャル | API Key・Merchant ID等（GatewayとZuoraを繋ぐ認証情報） |
| Active / Test mode | 本番処理か疎通確認かの切り替え |
| 対応Payment Method | このGatewayで処理できる支払い手段 |
| Gateway Reconciliation | GatewayとZuoraの取引記録の自動照合を有効化 |
Active / Test modeの違い
| モード | 動作 | 使いどころ |
|---|---|---|
| Test | ダミーの決済番号でも成功扱い。実際の課金は発生しない | 導入時の疎通確認・開発テスト |
| Active | 実際の決済処理が走る。顧客のカードに課金される | 本番運用 |
Gatewayエラーの種類と対処
| エラー種別 | 意味 | 対処 |
|---|---|---|
| Decline（拒否） | 銀行・カード会社が承認を拒否した | 顧客に連絡して支払い方法の更新を依頼。再試行しても同じ結果になる |
| Timeout（タイムアウト） | GatewayとZuora間の通信が時間切れになった | Gateway側では処理が完了している場合があるため、Reconciliationで確認してから再試行を判断する |
| Invalid（不正情報） | カード番号の桁数誤り・有効期限切れなど | カード情報の更新が必要 |
Payment Run・手動支払い
Payment Runは未収InvoiceをDefault Payment Methodで自動回収するバッチです。Externalの支払いは対象外で、担当者が手動でPaymentを記録します。
Payment RunとBill Runの関係
Bill RunがInvoiceを生成するバッチであるのに対し、Payment RunはそのInvoiceの代金を回収するバッチです。2つは別々に実行されます。
| Invoiceの状態 | 意味 |
|---|---|
| Open | Posted済みだが未回収。次のPayment Runまたは手動回収の対象 |
| Paid | 全額回収済み |
| Partial | 一部のみ回収済み（残額がOpen） |
Payment Runの設定項目
| 設定項目 | 内容 |
|---|---|
| Target Date | この日付時点でOpenのInvoiceを対象にする |
| Bill Cycle Day | 指定したBCDのAccountだけを対象にする |
| Currency | 指定通貨のAccountだけを対象にする |
| Payment Gateway | 使用するGatewayを指定（未指定ならデフォルト） |
| Apply Credit Balance | 未充当のCredit MemoをInvoiceに先に充当するか |
Ad Hoc vs Scheduled
| 方式 | 説明 | 使いどころ |
|---|---|---|
| Scheduled（定期） | 毎日・毎月など定期的に自動実行 | 通常の自動回収運用 |
| Ad Hoc | 設定後すぐに実行される | 特定Accountの即時回収、再試行 |
Zuoraの複数通貨対応
Zuoraは複数通貨での支払い回収を自動化できます。Payment Runは通貨フィルターで特定通貨のAccountだけを対象にできるため、JPY・USD・EURなど異なる通貨の回収バッチを別々にスケジュールすることが可能です。
PaymentのステータスとVoid
| ステータス | 意味 |
|---|---|
| Processing | GatewayにリクエストをしてZuoraが結果待ちの状態 |
| Processed | Gateway処理が成功し、InvoiceへのApplyが完了した状態 |
| Error | Gatewayが失敗を返した。InvoiceはOpenのまま残る |
| Voided | 処理済みのPaymentを取り消した状態。帳簿上の逆仕訳が行われる |
Payment Apply — 充当の順序と原則
| 充当ルール | 内容 |
|---|---|
| Invoice Date順（古いものから） | 最も古いInvoiceから順に充当するのがデフォルト |
| Invoice番号順 | 番号が小さいInvoiceから優先する設定も可能 |
| 手動Apply | 担当者が特定のInvoiceに手動でPaymentを紐づけることも可能 |
支払い失敗時の対処
Dunning — 支払い失敗後の督促設計
Dunningとは、支払いが失敗した顧客に対して自動で再試行・督促メールを行う仕組みです。
| Dunningの構成要素 | 内容 |
|---|---|
| Retry Schedule | 何日後に何回まで再試行するか |
| Email Notification | 失敗通知・督促メールの文面とタイミング |
| Account Action | 一定回数失敗したときにSubscriptionを停止・解約するアクション |
Retry設定と間隔ロジック
Write-off — 不良債権の会計処理
| 操作 | 内容 |
|---|---|
| Write-off | 回収不能と判断したInvoice残額を貸倒損失として計上し、InvoiceをClosed扱いにする |
| 会計上の処理 | 売掛金（資産）を減少させ、貸倒損失（費用）を計上する逆仕訳が走る |
Standalone Payment
通常のPaymentはInvoiceに充当されますが、Standalone PaymentはInvoiceに紐づかない単独の入金記録です。
| 用途 | 例 |
|---|---|
| 前払い金の受領 | 契約前に保証金・デポジットを受け取った場合 |
| 過払い金の管理 | 顧客が請求額より多く振り込んできた場合 |
External支払いの手動記録
現金・銀行振込などのExternal Payment MethodはPayment Runの対象外です。入金を確認した担当者が手動でPaymentを作成し、該当するInvoiceに充当します。自動決済（Automatic Payment）が設定されていないアカウントでも、管理画面から手動で決済を起こすことができます。
| 手順 | 内容 |
|---|---|
| 1. Payment作成 | 金額・Payment Method・日付を入力 |
| 2. Invoiceへ充当 | Apply PaymentでInvoiceに紐づける |
| 3. Invoice状態更新 | InvoiceがPaidステータスになる |
Refund・Payment Reconciliation
返金はCredit Memoで帳簿調整し、Refundオブジェクトで現金を送金します。ReconciliationではGatewayの取引記録とZuoraのPayment記録を照合して差異を確認します。
返金の2ステップ
| オブジェクト | 役割 | お金の動き |
|---|---|---|
| Credit Memo | 請求額のマイナス調整 | 帳簿上の調整のみ |
| Refund | 実際に顧客へ現金を返す | Electronic：Gateway経由、External：手動記録 |
Refundの種類
| 種類 | 処理方法 | 使いどころ |
|---|---|---|
| Electronic Refund | Payment GatewayにRefundリクエストを送り自動処理 | カード払いの返金など |
| External Refund | 銀行振込などで手動対応し、Zuoraに記録 | 現金・振込で受け取った代金を返金する場合 |
Payment Reconciliation（照合）
ReconciliationはZuoraのPayment記録とGatewayが持つ取引記録を突き合わせ、差異を検出する作業です。
| 差異の例 | 原因 |
|---|---|
| Zuoraに記録があるがGatewayにない | 処理が途中でタイムアウトした |
| GatewayにあるがZuoraにない | 通信エラーでZuoraが結果を受け取れなかった |
| 金額が一致しない | 通貨換算・手数料の計上漏れ |
101/201補足 — 標準イベントとRetry Rulesの詳細
Zuoraの標準イベント
Invoice is posted（請求書転記）、Invoice is past due date（期日超過）、Payment declined（支払拒否）は、いずれもZuoraが標準で発火するイベントで、通知やWorkflowのトリガーに使えます。一方、Payment method deleted（支払方法削除）やCheck payment returned（小切手返却）は標準イベントには含まれません。標準イベントは「請求書・支払のライフサイクル上の節目」に限られる点を押さえてください。
Payment Retry Rules（201）
Payment Retry Rulesを設定する目的は、決済失敗時に事前に定めた回数だけ自動で再試行することです（Maximum Attemptsで上限、Retry Intervalで間隔を指定）。「電子決済の処理にはretry rulesの設定が必須」という記述は誤りです。retryなしでも決済自体は処理できます。
たとえば毎月1日と15日にスケジュール支払ランを設定し、Maximum Attemptsを2、Retry Intervalを既定の12時間としたケースでは、1日のランが失敗した場合、次の再試行は「15日のスケジュールラン」ではなく「12時間後」に行われます。15日のランが失敗した場合は当月最後のスケジュールランのため、リトライ上限を使い切ると残りの失敗分は翌月1日のランまで再試行されません。
Payment Method Updater（PMU）
PMUはZuoraが管理するサービスで、実行スケジュールを管理者が任意に設定することはできません。自分で制御できる設定（Retry Rules等）と、Zuora側が管理・実行するサービス（PMU）を区別してください。
Invoice Item AdjustmentのReason Code
Invoice Item Adjustmentを行う理由の選択肢は、Reason Codeという専用機能で管理します。Customer service repsが理由を一覧から選べるようにするには、Payments Settings > Configure Reason Codesページで該当コードを有効化し、必要であれば新しいReason Codeを追加します。「カスタムpicklistフィールドを新規作成する」「自由記述のCommentsフィールドに記入させる」は、いずれも"一覧から選択させる"という要件を満たさないため誤りです。