概要

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の準拠スコープを最小化できる

knowledgecenter.zuora.comknowledgecenter.zuora.com/Zuora_Payments/Payment_Methods/B1_Define_Payment_Met...

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ステータスになる

knowledgecenter.zuora.comknowledgecenter.zuora.com/Zuora_Payments/Process_payments/Process_payments_wit...

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が結果を受け取れなかった
金額が一致しない	通貨換算・手数料の計上漏れ

knowledgecenter.zuora.comknowledgecenter.zuora.com/Zuora_Payments/Report_and_reconcile_transactions/Bat...

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フィールドに記入させる」は、いずれも"一覧から選択させる"という要件を満たさないため誤りです。

101/201補足2 — 支払い方法の分類とPayment Gatewayの基礎

Payment MethodはElectronic・External・Alternateの3種類に大別されます。Payment Gatewayは自動化・セキュリティ・複数決済手段対応などの理由で導入されます。

Payment Methodの3分類

分類	別名	特徴	例
Electronic	Pull Payment Method	事業者側から自動で引き落とす	クレジットカード、デビットカード、口座振替（ACH等）
External	Push Payment Method	顧客側が能動的に送金する	現金、小切手、Wire Transfer
Alternate	—	顧客の決済情報を預かり、第三者サイトへの支払いにも使えるオンライン決済サービス	Amazon Pay、Google Wallet、Apple Pay

Bank Transferの地域別呼称

Bank Transferは国・地域によって呼び方が異なります。

地域	呼称
アメリカ	ACH（Automated Clearing House）
カナダ	PAD（Pre-Authorized Debit）
ヨーロッパ・イギリス	SEPA（Single Euro Payments Area）
イギリス	Direct Debit
オーストラリア・ニュージーランド	Direct Debit Schemes

支払い方法を選ぶ際にビジネスが考慮する要因

事業者がどの支払い方法を受け付けるかは、売上・収益に直結するため慎重に決定されます。主な考慮要因は次のとおりです。

• Geography（地域）
• Customer preference（顧客の好み）
• Business type（事業形態）
• Processing cost（処理コスト）
• Settlement speed（入金までの速さ）
• Payment frequency（支払い頻度）
• Likelihood of success（成功しやすさ）
• Risk of fraud（不正リスク）

PCI準拠でZuoraに保存できない情報

PCI（Payment Card Industry）準拠のルールにより、Zuoraに保存できないカード情報が定められています。

情報	扱い
CVV／CSC（セキュリティコード）	最初の取引でGatewayに渡すのみで、Zuoraには保存されない
クレジットカード番号（全桁）	保存不可。ただし先頭6桁と末尾4桁のみ保存可能
磁気ストライプの全データ	保存不可

また、PCI Self-Assessment Questionnaire（SAQ）は、カード情報を保存・処理・転送する加盟店向けの検証ツールで、事業の形態に応じて複数のバージョンがあります。

Hosted Payment Pages（HPM）とTokenization

HPMはZuoraが管理する決済ページを自社サイトの外に置く仕組み、Tokenizationはカード情報をトークンに置き換える仕組みです。どちらもPCI準拠のコストを下げる目的で使われます。

仕組み	内容
HPM（Hosted Payment Page）	決済ページをZuoraが自社サイト外でホストし、チェックアウト時にクレジットカードやACHなどの決済情報を受け取る。PCI準拠のコストを抑えられる
Tokenization	顧客の機密な支払い情報を、ランダムに生成されたトークン（識別子）に置き換えて送信・保存する仕組み。クレジットカードやPayPalなどで利用できる

External Payment Methodの詳細

種類	内容
Wire Transfer	銀行口座間で資金を直接・リアルタイムに近い形で送金する方法。アメリカではFedwire、国際間ではSwiftというネットワークが使われ、クロスボーダー送金にも対応する
Cash	紙幣・硬貨など現物の通貨。国によっては伝統的な決済手段として好まれるが、継続課金（Recurring Payment）には向かない
Check	金融機関に対して特定の口座からの支払いを指示する証書。LockBox連携を使って処理を効率化することもある

Payment Gatewayを導入する主なメリット

Payment Gatewayを利用することで、事業者は次のようなメリットを得られます。

• Automation：支払いに関わる業務を自動化し、運用コストを削減できる
• Security：PCI DSSに準拠したホスティングにより、不正利用の検知・防止につながる
• Speed and Ease：電子決済を素早く、簡単かつシームレスに処理できる
• Validation：カード情報の有効性を検証できる
• Payment Capture：決済金額を実際に引き落とす処理を行える
• Credit Card Authorization：顧客のカードに十分な残高があるかを確認し、購入を承認する
• Supporting Multiple Payment Methods：複数の決済手段に対応できる
• Settlement Report：入金結果をまとめたレポートを取得できる
• Access to Acquiring Banks：加盟店契約を持つ銀行（Acquiring Bank）への接続を提供する

101/201補足3 — 決済フローとZuoraの決済操作・セキュリティ機能

電子決済はCard Holder→Merchant→Merchant Account/Gateway→Acquiring Bank→Card Network→Issuing Bankという流れで承認されます。ZuoraはVoid・Cancel・Delete・Applyなどの決済操作と、Gateway Reconciliationなどのセキュリティ機能を提供します。

電子決済の処理フロー

クレジットカードなどの電子決済は、次の関係者を経由して処理されます。

登場人物	役割
Card Holder	カードを使って支払う顧客
Merchant	商品・サービスを提供する事業者
Merchant Account/Gateway	決済情報を受け取り、Acquiring Bankへ転送する役割
Acquiring Bank/Processor	加盟店側の銀行。決済情報をCard Networkへ送る
Card Network	Visa・Mastercard等のカードブランドのネットワーク
Issuing Bank	カード保有者の口座がある発行銀行。承認・拒否を判断する

Payment Gatewayを導入する主なメリット（詳細）

メリット	内容
Validation	購入時にクレジットカード・デビットカードの情報を検証する
Payment Capture	決済が承認された後に実際に資金を確保する処理。Test gatewayで失敗シナリオへの対応も確認できる
Supporting Multiple Payment Methods	顧客が好みの支払い方法を使えるよう、複数の決済手段に対応する
Settlement Report	多くのGatewayは日次で入金結果のレポートを生成する。決済の成功状況に加え、Payment reversal（返金）などの例外情報も含まれる
Access to Acquiring Banks	Acquiring Bankと直接接続できるのは一部の大企業のみだが、Payment Gatewayを使えばどの規模の事業者でも決済システムに簡単にアクセスできる

Zuoraにおける決済操作（Successful Payment Actions）

決済が正常に処理された後、Zuoraでは次の操作を行えます。

操作	対象	内容
Void Payment	Electronic	成功した電子決済を取り消す操作。Gatewayの仕様に依存し、決済がSettle/処理される前にのみ実行可能。対象PaymentのAccounting Periodがopenである必要がある
Cancel Payment	External	成功した外部決済（現金・小切手など）を取り消す操作。取り消す前にInvoiceやDebit MemoからPaymentをUnapplyしておく必要がある。対象PaymentのAccounting Periodがopenである必要がある
Delete Payment	Canceled/Voided/Error	Canceled・Voided・ErrorになったPaymentの記録自体を削除する操作
Apply Payment	全般	PaymentをInvoiceやDebit Memoに充当する操作。Scheduled Payment Runは電子決済の作成とApplyを自動で行う。小切手や振込などExternalで受け取った入金は手動でApplyすることもある

Zuoraが統合する決済セキュリティ機能

Zuoraは、Payment Gateway側が提供する以下のセキュリティ機能と連携できます。

機能	内容
Authorization of Electronic Payment Methods	新しいPayment Method登録時、$1などの少額（Gatewayによっては$0）で試験的に決済を行い有効性を検証する仕組み。Payment Methodの追加・更新時にZuoraからGatewayへ認証リクエストを送信する
Gateway Reconciliation	Zuoraに記録された電子決済・返金・チャージバックの取引と、Gatewayが報告する取引が一致しているかを検証するプロセス。Gatewayの決済処理・Settlement・Post-settlementイベントの取得をZuoraがサポートする
Fraud Prevention	Gatewayが対応していれば設定可能な不正防止機能。対応例としてCybersource Decision Manager、Verifi、Chase Safetech Fraud Serviceがある。IPアドレス・地域・メールアドレス・デバイスフィンガープリントなどの追加情報をHosted Payment Method（HPM）ページ経由でGatewayに渡すことで実現する
Tokenization	Hosted Payment Pageに入力されたカード情報がGateway側で検証され、トークンが発行されてTokenization Vaultに保管される仕組み。検証に成功すると、対応するトークンがHosted PageからZuoraへ返され、以降の決済に利用される
Support for Different Levels of Data	クレジットカード処理に必要な情報量に応じたLevel 1〜3の分類

Support for Different Levels of Dataの内訳は次のとおりです。

レベル	必要な情報
Level 1	最も少ない情報。購入金額とPrimary Account情報のみ
Level 2	Level 1に加え、Invoice情報・購買注文番号（PO番号）・税額など
Level 3	Level 2に加え、商品説明・単価・拡張価格・単位（Unit of Measure）など

Zuora Paymentsでできること

Zuora Paymentsを使うことで、事業者は次のことが可能になります。

• 決済のライフサイクル全体を1つのアプリケーションで管理する
• 顧客をグループ化し、グループごとに自動決済のスケジュールやルールを設定する
• External（現金・小切手）とElectronic（クレジットカード・ACH・デビットカード・PayPal）の両方に対応する
• PCI準拠かつセキュアな方法で継続課金を処理する
• 決済処理を自動化し、手作業を減らす

101/201補足4 — 決済操作の続き、支払い中断・返金の詳細

UnapplyはInvoiceへの充当を解除する操作、RefundはUnapplied Payment/Credit Memoから返金する操作、TransferはPaymentの帰属先Accountを修正する操作です。ACH決済の失敗やChargebackなどの中断は、Zuora内でExternal Refundとして記録するのが基本方針です。

Zuoraにおける決済操作（続き：Unapply／Refund／Transfer）

操作	内容
Unapply Payment	InvoiceやDebit Memoに充当済みのPaymentを解除する操作。Unapplyすると、そのInvoice/Debit Memoの未払額が再びopenになる。例：小切手払いが誤って別のInvoiceに充当された場合、いったんUnapplyしてから正しいInvoiceにApplyし直す
Refund Payment	Unapplied PaymentやUnapplied Credit Memoに対して返金を発行・追跡する操作。部分返金も可能だが、返金額は元のPayment金額を超えられない。Zuora UIまたはAPIから実行できる。例：顧客が過払いした場合、その超過分をUnapplyしてから顧客に返金する
Transfer Payment	誤って別のAccountに記録されたPaymentを正しいAccountへ付け替える操作。正しいAccountが不明な場合はUnassigned（どのAccountにも紐づかない状態）にできる。現時点でTransfer/Unassignできるのは、Invoice/Debit Memoに未充当（Unapplied）のExternal Paymentのみ

支払いの中断（Interrupted Payments）

決済が正常に完了せず、途中で止まってしまうケースには次の3種類があります。

種類	内容
Chargebacks（チャージバック）	顧客がカード会社に異議を申し立て、支払いが取り消されるケース
ACH Settlement Failures（ACH決済の失敗）	ACH取引は通常1営業日以内に決済されるが、口座残高不足・口座番号不正・顧客による承認取り消し・ルーティング番号不正・金額欄の誤りなどにより失敗することがある
Bounced Checks（不渡り小切手）	小切手の資金が確保できず決済が成立しないケース。ZuoraではACHと同じ方法で管理する

ACH決済失敗・Reversal発生時にZuoraが推奨する対応は次のとおりです。

• 別の支払い方法で再度決済を試みる
• InvoiceまたはInvoice Item Adjustmentを作成し、残高をWrite-offする
• 顧客に連絡する
• サービスへのアクセスを制限・停止する（De-provision）

Chargebackの処理フロー

一部のGatewayはChargebackを自動的にExternal Paymentとして記録できますが、対応していないGatewayでは次の手順で手動処理します。

1. Payment Gatewayから事業者にChargebackの通知が届く
2. 事業者はGatewayが定める手続きに従い、Chargebackに異議を申し立てることができる
3. 異議を申し立てない場合、または異議申し立てに敗れた場合、事業者はZuoraにExternal Refundを記録する
4. Subscriptionを解約し、未払いInvoiceに対応する売掛金（AR）を調整する

Referenced Refund と Non-referenced Refund

種類	内容
Referenced Refund	元のPaymentに紐づけて返金する方式。返金は元の決済で使われたPayment Gateway経由で、同じ電子決済手段に返される。ただし元のGatewayをすでに使っていない場合は返金できず、External Refundなど別の方法で対応する必要がある
Non-referenced Refund	特定のPaymentに紐づかず、Credit Memoに対して作成する返金方式。電子決済でのNon-referenced Refundは一部のGatewayのみ対応しており、実際に回収していない金額を返金してしまうリスクがあるため慎重な取り扱いが必要

Electronic RefundとExternal Refund

種類	内容
Electronic Refund	Zuoraが対応するPayment Gatewayを通じて処理され、顧客の電子的な支払い手段に自動で返金される。返金日はGatewayが処理した時点でZuoraが自動的に記録する
External Refund	元の支払いがExternal Paymentだった場合に作成できる。Payment Gatewayを経由しないため、返金日は作成時に手動で入力する

返金のキャンセルと削除

操作	内容
Cancel（返金の取り消し）	何らかの理由でRefundを無効にしたい場合に使う。元のRefundの会計期間（Accounting Period）がopenである必要がある。Electronic Refundのキャンセルは、Electronic Paymentのvoidと同様、Payment Gatewayが定める期間内にのみ実行できる
Delete（返金の削除）	RefundのステータスがCanceledまたはErrorになっている場合、Zuoraから削除できる。ただし、履歴レポートのため、本番環境での削除は推奨されない

Payment作成・処理の2つの方法（Zuora UI／API）

Zuoraでは、支払いの作成と処理を次の2通りの方法で行えます。

方法	内容
Zuora UI	電子決済はUI上でPaymentの作成とPayment Runの実行によりGatewayを通じて処理される。非電子（External）決済はZuora外部で処理された後、UIでZuoraに記録する
API	電子決済はPOSTなどのAPI呼び出しでGatewayを通じて処理・記録される。非電子決済もZuora外部で処理された後、APIで記録する

Payment Runの2種類（詳細）

種類	実行タイミング	繰り返し
Scheduled Payment Run	あらかじめ設定した将来の日時に自動実行される	日次・週次・月次など繰り返し設定が可能。1回限りの実行も可能
Ad Hoc Payment Run	設定後すぐに実行される	単発実行のみで繰り返しは不可

Zuoraにおける決済ステータス

決済が処理された後、Paymentは次のいずれかのステータスになります。

ステータス	内容
Draft	Paymentが処理済みの取引として扱われていない状態。External Paymentを作成した場合にのみ発生する
Processing	電子決済が不明な状態にあることを示す。Gateway側で処理状況を確認し、その結果に応じてサポートへステータス変更を依頼する必要がある
Processed	取引が処理され、正式な金融取引として認識された状態
Error	電子決済が失敗した状態
Voided	Payment Gatewayごとに定められたルール（voidできる支払い方法、void可能な時間の制限など）に従って取り消された状態。時間制限を過ぎた場合はVoidではなくRefundでの対応が必要になる
Canceled	Draftの支払い（External Payment）を作成した場合にのみ発生しうるステータス

電子決済が失敗する一般的な原因には、次のようなものがあります。

• 顧客のデビットカード・クレジットカードの有効期限切れ
• 顧客の銀行口座の残高不足
• 顧客の銀行による決済拒否

Dunning通知の設定例

Dunning（督促）通知は、Invoice OverdueやPayment Declinedといったイベントをトリガーに設定できます。

イベント	通知タイミングの例
Invoice Overdue（請求書の期日超過）	Invoice Due Dateから指定日数（例：10日）後に、顧客へメールやコールアウトで通知する
Payment Declined（決済拒否）	決済の失敗回数（Sequence of failed attempt）を指定し、例えば2回目の失敗時にメールで通知する

実装上のベストプラクティス

Zuoraで決済を実装する際の主な注意点は次のとおりです。

• フルのクレジットカード番号をZuoraに保存しない：トークンで管理することで、将来Gatewayを変更する際の柔軟性を確保できる。フルのカード番号を保存すると、他のGatewayへの切り替えが難しくなる
• 利用したいGatewayの機能がZuora連携でサポートされているか事前に確認する：例えばAdyenは250以上の決済手段に対応しているが、Zuora連携でサポートされるのはその一部のみ
• 決済の取り消し（Reversal）はExternal Refundとして記録する：ACHの決済失敗、クレジットカードのChargeback、不渡り小切手などによる取り消しはExternal Refundとして記録するのが基本方針。Gateway Reconciliation機能は一部のGatewayでのみ電子決済の取り消しを自動処理できる
• 決済の成功率を分析し、リトライルールを最適化する：Zuoraのレポート機能を使って支払い試行ごとの成功率を分析し、処理コストを抑えつつ回収率を最大化するリトライ設定に活かす。この情報はPayment Method Snapshotオブジェクトに保存される

101/201補足5 — 他システムとのAPI連携ユースケース

ZuoraのAPIは、決済の作成・確定・不正防止・カード情報の管理など、外部システムとの連携が必要な場面で使われます。

Creating Payments via API

Payment Runを使わずAPI経由でPaymentを作成するケースとして、次のような例があります。

• Wire TransferやLockbox Payment：加盟店の銀行口座に直接送金される支払いは、Payment Run経由では作成できないため、ZuoraのPOST PaymentAPIを使ったカスタム連携でZuoraに記録する
• 1回限りの電子決済：CRMなどの顧客管理システムからカスタマーサービス担当者が起票するケースや、セルフサービスのWebポータルから顧客自身が1回限りの決済をリクエストするケースがある

Settling, Rejecting, or Reversing Payments via API

Gateway Reconciliation機能が利用できないPayment Gatewayの場合、ZuoraはPaymentをSettle（確定）・Reject（拒否）・Reverse（取り消し）するためのAPIを提供しています。Reconciliation機能に対応していないGatewayを使う場合は、これらのAPIで決済結果を反映する必要があります。

Manage Credit Card Payment Methods（APIによるカード情報管理）

ZuoraのAPIを使うと、次のようなクレジットカード情報の閲覧・管理が可能です。

操作	内容
カード情報の取得	セルフサービスのWebポータルなどから、Billing Accountに登録されている全クレジットカードのPayment Methodを取得する
カード情報の更新	住所や有効期限などのカード情報を、セルフサービスのWebポータルから更新する
カード情報のScrub（削除・置換）	EUのGDPR（General Data Protection Regulation）対応のため、Payment Method内の機密情報を置き換える

Securely Capture Electronic Payment Methods

クレジットカードは機密性の高い情報のため、PCI DSSの要件対象になります。見積もり（Quote）フローの中でクレジットカードや口座振替などのElectronic Payment Methodの情報を安全に取得する必要があり、事業者のWebサイトへのリンクやメールで顧客に入力を促す形や、セルフサービス注文でフォームを提示する形が一般的です。

ZuoraはPCI DSS準拠のフォームを実装する方法として、次の2つを提供しています。

方法	内容
HPM（Hosted Payment Method）	Zuoraがホストする決済フォームを事業者のWebページに埋め込み、決済情報を安全に取得する
Direct POST	HPMと同様にPCI DSS準拠のフォームを実装するもう一つの方法