> 継続的なプロセス改善 > 決済処理 > Fiserv > データテンプレート

支払処理用データテンプレート

Name: 決済処理 Process Mining Data Template
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

← 改善ガイドに戻る

決済処理の属性 (19) 決済処理のアクティビティ (13) 抽出ガイド (1)

支払処理用データテンプレート

このテンプレートは、Fiservのデータをプロセスマイニングと分析に適した形式へ整理するための枠組みを提供します。決済と照合のサイクルを明確に把握するために必要な属性とアクティビティを示しています。このガイドに沿って作成したイベントログから、財務業務における非効率やコンプライアンス上のリスクを確認できます。

支払分析に推奨される属性
監視すべき主要なプロセス上の節目
Fiservデータ抽出に関する技術ガイダンス

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

決済処理の属性

決済ライフサイクル全体を詳細に分析するために必要なコンテキストを、イベントログに提供する推奨データ項目です。

5 必須 9 推奨 5 任意

	名前	説明
	アクティビティ名 ActivityName	支払いプロセスで発生した特定のイベントまたはステータス変更です。
説明この属性は、「Payment Request Created」や「Payment Settled」など、実行されたステップを表します。プロセスマップのノードを定義し、処理順序を理解するために欠かせません。個別のアクティビティを分析すると、組織はワークフローを可視化し、スキップされたステップを特定できます。また、必須の検証や承認が省略されたコンプライアンス違反の経路も検出できます。重要な理由プロセスのタイムラインを構成するイベントを定義します。入手先取引履歴ログまたはステータス変更監査テーブルです。例支払い依頼作成支払い承認済み支払いエラー特定支払い決済済み支払いキャンセル済み
	イベントタイムスタンプ EventTimestamp	アクティビティが発生した正確な日時です。
説明この属性は、イベントが発生した正確な時点を記録します。サイクルタイム、リードタイム、ボトルネックの特定など、時間に関するすべての分析の基礎です。ダッシュボードでは、このデータを使ってステップ間の所要時間を計算します。たとえば、「Payment Request Created」から「Payment Authorized」までの時間を算出できます。短時間に連続して発生するイベントを正確な順序で並べるには、高精度のタイムスタンプが必要です。重要な理由イベントの順序付けとプロセスの所要時間の計算に必要です。入手先監査ログまたは取引更新時刻の列です。例 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	支払い取引ID PaymentTransactionId	特定の支払い指示または取引ケースを一意に識別するIDです。
説明この属性は、1件の支払いライフサイクル内のすべてのアクティビティを関連付ける中心キーです。初回リクエストから検証、承認、最終決済またはキャンセルまでの流れを追跡できます。 Fiserv環境では通常、取引履歴テーブルの主キーです。プロセスフローを再構築し、承認の数日後に決済されるような分離したイベントを同じ業務オブジェクトに正しく関連付けるために欠かせません。重要な理由イベントをプロセスインスタンスにまとめるために必要な基本のCase IDです。入手先 TransactionまたはPayment Headerテーブルについては、Fiservのドキュメントを参照してください。例 TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	ソースシステム SourceSystem	データの発生元となるシステム名です。
説明イベントを生成した特定のFiservモジュールまたは外部システムを識別します。支払いがフロントエンドのチャネルで開始され、バックエンドのコアバンキングシステムで決済されるような複雑なシステム環境で特に役立ちます。発生元のシステムでプロセスビューを絞り込めるため、特定の技術環境や連携ポイントに対象を絞って分析できます。重要な理由技術的な背景とデータの系譜を示します。入手先抽出時にハードコードされる値、またはシステムメタデータです。例 Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	最終データ更新 LastDataUpdate	レコードが最後に抽出または更新された時刻です。
説明分析に使うデータの鮮度を示します。ダッシュボードがリアルタイムの業務状況を反映しているのか、過去時点のスナップショットなのかを判断するうえで重要です。特に締切時刻のコンプライアンスや現在のボトルネックを監視する際、古いデータに基づいて判断していないことを確認し、表示される指標への信頼につなげます。重要な理由データの最新性と信頼性を確保します。入手先 ETL実行時点のシステム時刻です。例 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	STPかどうか IsStraightThroughProcessing	支払いに手作業の介入が不要だったかを示すフラグです。
説明ケースに「Payment Error Identified」、「Payment Error Resolved」、または手動の「Payment Approved」ステップが含まれない場合（定義による）にtrueとなる、計算済みのブール属性です。Straight Through Processing Rate KPIを直接支えます。プロセスを、完全自動のフローと人の作業が必要なフローに二分して分類できます。自動化の可能性を明確に把握できます。重要な理由プロセス効率と自動化の成果を測る中核指標です。入手先データ変換時に計算されます。例 truefalse
	エラーコード ErrorCode	支払いの検証に失敗したときに生成される特定のコードです。
説明「Payment Error Identified」アクティビティに関連する技術エラーまたは業務エラーのコードを記録します。Validation Error and Rework Trackerの基礎となる属性です。特定のエラーコードの発生頻度を集計すると、組織は体系的なデータ品質の問題（「Invalid Routing Number」など）を特定し、検証ロジックやユーザートレーニングに対する対策を実施できます。重要な理由手戻りの根本原因を特定します。入手先エラーログまたは取引ステータスの詳細です。例 E-101INV_ACCNSF_ERRAUTH_FAIL
	処理ユーザー ProcessingUser	アクティビティを担当したユーザーIDまたはシステムエージェントです。
説明人による承認者かシステムの自動化ボットかを問わず、特定の操作を実行した主体を識別します。このデータは、Error Resolution Cycle EfficiencyおよびApproval Authority Throughputダッシュボードに使われます。ユーザーを追跡すると、エラー率の高い担当者のトレーニングニーズを特定できます。また、特定の承認者にリクエストが集中しているボトルネックも把握できます。重要な理由リソース分析とボトルネックの特定を可能にします。入手先監査ログのUser ID列です。例 jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	受取人の口座番号 PayeeAccountNumber	資金が入金される口座の番号です。
説明支払い先の口座を識別します。支払人の口座と同様に、Duplicate Payment Detection Viewに欠かせません。特定の受取人との関係を正確に分析できます。締切時刻のコンプライアンス監視では、受取人を把握することで、失敗が許されない戦略的な取引先や重要な決済を優先できます。重要な理由重複検出と受取人分析に欠かせません。入手先取引詳細のCredit AccountまたはBeneficiary列です。例 555000111222333444BEN-882-11
	支払い方法 PaymentMethod	支払いの実行に使われる方式です（Wire、ACHなど）。
説明処理経路によって取引を分類します。方式ごとに標準手順やサービスレベル合意が大きく異なるため、Authorization Cycle Time Analysisの基礎となる属性です。支払い方法別にプロセスのバリエーションを分析すると、遅延が特定のチャネル（国際Wireなど）に固有のものか、組織全体に共通するものかを切り分けられます。重要な理由使用するインフラストラクチャによってプロセスフローを分類します。入手先取引タイプまたは決済手段コードの列です。例電信送金ACH小切手RTP内部振替
	支払い金額 PaymentAmount	支払い取引の金銭的価値です。
説明この属性は、支払いに関連する金額を表します。分析を分類する主要な軸であり、高額な戦略的支払いと少額の定常取引を区別できます。同一金額と支払人・受取人の情報を組み合わせて潜在的なエラーを検出する、Duplicate Payment Detection Viewに欠かせません。承認権限の分析にも役立ちます。高額な支払いでは、異なるワークフロー経路が選択されることが多いためです。重要な理由財務リスク分析と重複検出に必要です。入手先取引ヘッダーテーブルのAmount列です。例 150.0025000.5010.991000000.00
	支払人の口座番号 PayerAccountNumber	資金が引き落とされる口座の番号です。
説明支払い元の口座を識別します。Duplicate Payment Detection Viewの主要な構成要素です。受取人、金額、時刻と組み合わせることで、誤った二重支払いを検出するための一意の特徴を形成します。また、支払い元口座別の取引量を分析し、最も取引が多い社内ポートフォリオを特定できます。重要な理由重複検出と不正分析に欠かせません。入手先取引詳細のDebit Account列です。例 123456789987654321ACC-001-992
	支払期日 PaymentDueDate	支払いを処理しなければならない日付です。
説明支払いを完了させる目標日です。Processing Cutoff Compliance Monitorで、遅延するリスクのある取引を検出するために使われます。「Payment Settled」のタイムスタンプとこの属性を比較すると、期限内処理の指標を算出できます。受取人との信頼関係を維持するうえでも役立ちます。重要な理由 SLA遵守状況を測定する基準点です。入手先支払い指示の詳細です。例 2023-11-012023-11-15
	通貨コード CurrencyCode	支払い金額のISO通貨コードです。
説明支払いに使用される通貨を示します（USD、EURなど）。Currency and Method Volume Trendsダッシュボードで、組織が異なる外国為替へのエクスポージャーを監視するために必要です。グローバルレポート向けの金額の正規化にも使われます。また、数値が同じでも通貨が異なる取引を重複として誤検出しないためにも役立ちます。重要な理由複数通貨の処理分析に必要です。入手先取引ヘッダーテーブルのCurrency列です。例 USDEURGBPCADJPY
	事業部門 BusinessUnit	支払いを開始した部門または事業部です。
説明費用を担当する組織単位によって支払いを分類します。コスト配分や、組織内のどの部門で手作業の手戻りやエラーが多いかの把握に役立ちます。 Payment Path Compliance Auditを支え、各部門が固有の規制要件や内部統制要件を守っていることを確認できます。重要な理由パフォーマンスを分析するための組織的な背景を示します。入手先コストセンターのマッピングまたは部門コードです。例リテールバンキング法人融資ウェルスマネジメントオペレーション
	受取銀行 BeneficiaryBank	受取銀行の名称または識別子です。
説明支払いを受け取る金融機関を識別します。特定の受取銀行によって処理速度や連携上の問題が異なる可能性があるため、決済遅延の分析に役立ちます。 Settlement to Reconciliation Gapダッシュボードに別の分析軸を加え、遅延が外部要因（銀行固有）によるものか、内部要因によるものかを明らかにします。重要な理由外部依存関係の分析です。入手先取引詳細のBank IDまたはName列です。例 ChaseBank of AmericaWells FargoCitibank
	手戻りかどうか IsRework	この特定のアクティビティが手戻りループの一部かを示すフラグです。
説明エラーが特定されてから解消されるまでに発生したアクティビティ、または繰り返されたアクティビティを示すブールフラグです。Payment Validation Rework Rate KPIを支えます。プロセスマップを絞り込み、正常経路だけを表示したり、反対に手戻り経路だけに注目して失敗のパターンを理解したりできます。重要な理由付加価値のある作業と修正作業を切り分けます。入手先プロセスループに基づいて計算されます。例 truefalse
	承認レベル ApprovalLevel	支払いの認証に必要な、または使用された階層レベルです。
説明「Payment Approved」アクティビティに関連する役職または権限のレベルを示します。Approval Authority Throughputダッシュボードで、上位レベルの承認者がボトルネックになっていないか分析するために使われます。レベル1とレベル3など、レベル別の支払い分布を把握すると、権限委譲ポリシーを最適化できます。重要な理由階層別に承認のボトルネックを分類します。入手先ユーザーロールまたは承認ワークフローのテーブルです。例レベル1マネージャーディレクターCFO
	締切時刻超過かどうか IsCutoffMissed	支払いが日次の銀行締切時刻後に送信されたかを示すフラグです。
説明「Payment Instruction Sent」の時刻を、通貨と方式ごとの日次締切時刻と比較する計算済みのブール値です。Cutoff Adherence Rate KPIを支えます。締切時刻の超過を特定すると、遅延の根本原因を調査できます。原因が開始の遅れなのか、社内処理の遅さなのかを切り分けられます。重要な理由業務上のコンプライアンスと流動性管理に欠かせません。入手先 EventTimestampとCutoff Referenceテーブルを比較して計算されます。例 truefalse

必須推奨任意

決済処理のアクティビティ

決済ワークフローを正確にディスカバリーして最適化できるよう、これらの主要なプロセス手順と節目をイベントログに記録します。

5 推奨 8 任意

	アクティビティ	説明
	支払い依頼作成	Fiservシステムに決済指示が最初に登録された時点です。ユーザーまたは外部システムがAPIやインターフェースを介して取引を開始した際に、明示的に記録されます。
重要な理由プロセスのタイムラインの開始点を示します。合計サイクルタイムの算出と、受付時点のボトルネックの特定に欠かせません。入手先取引履歴テーブルが作成された時刻です。対象のPayment Transaction IDを持つ最も早いレコードを確認します。取得取引レコードが挿入された時点で記録イベントタイプ explicit
	支払い承認	権限上限に基づき、決済を進めることを許可する手動または自動の判断です。承認権限を持つユーザーまたはシステムルールが承認フラグを更新した時点で記録されます。
重要な理由「Authorization Cycle Time Analysis」に必要な項目です。ここでの遅延は、人による承認チェーンにボトルネックがあることを示します。入手先ユーザー操作によってステータスが「Pending Approval」から「Approved」へ変わったことを示す監査ログです。取得承認操作が行われた時点で記録イベントタイプ explicit
	支払い指示送信済み	支払いファイル（ACHバッチ、Wireメッセージなど）を外部ネットワークまたはクリアリングハウスへ送信します。重要な引き継ぎポイントです。
重要な理由「Processing Cutoff Compliance Monitor」に必要です。組織が日次の銀行締切時刻を守れるようにします。入手先バッチ処理ログまたはファイル生成時刻です。「Batch Created」または「File Transmitted」として記録されることがよくあります。取得バッチファイル生成時に記録イベントタイプ explicit
	支払い決済済み	資金移動が完了し、総勘定元帳に計上されます。銀行側から見た取引の財務処理が完了したことを示します。
重要な理由「Straight Through Processing Rate」の主な終点です。資金が実際に移動したことを示します。入手先取引ステータスが「Posted」であること、または元帳に「Post Date」のタイムスタンプが存在することです。取得 GL計上時に記録イベントタイプ explicit
	支払い照合済み	取引を銀行取引明細または決済ファイルと内部照合します。会計処理を完了させます。
重要な理由「Settlement to Reconciliation Gap」に必要です。財務帳簿を正確に締められるようにします。入手先ステータスが「Matched」または「Reconciled」に更新された照合モジュールのログです。取得照合一致時に記録イベントタイプ explicit
	支払いエラー特定	取引に失敗ステータスまたは例外コードが付与された時点を記録します。検証ルールに違反した場合や、外部チェックで否定的な応答が返された場合に発生します。
重要な理由「Validation Error and Rework Tracker」ダッシュボードに欠かせない項目です。ここで件数が多い場合、上流のデータ品質に問題があることを示します。入手先取引ステータス項目が例外コード（例：「Invalid」、「Hold」、「Error」）に変わります。取得ステータスがErrorに変わった時点で記録イベントタイプ explicit
	支払いエラー解消	以前エラーになった取引が修正されたことを示します。取引がエラーステータスから処理中または有効なステータスへ戻った場合に推定されます。
重要な理由「Mean Time to Resolve Payment Errors」の算出に欠かせません。業務チームの対応効率を測定できます。入手先取引ステータスがエラーコードから通常の処理コードへ更新された場合に推定されます。取得変更前後のステータス項目を比較イベントタイプ inferred
	支払いキャンセル済み	ユーザーまたはシステムルールによって開始される、決済前の支払いフローの終了です。以降の処理をすべて停止します。
重要な理由無駄や中断された作業を特定します。承認後のキャンセル率が高い場合、プロセスの非効率を示唆します。入手先「Cancelled」、「Void」、または「Stopped」へのステータス変更です。取得ステータスがCancelledに変更されたときに記録イベントタイプ explicit
	支払い予定	支払いが承認されたものの、将来の適用日に処理されるよう保留されたときに発生します。処理時間帯が始まるまで、システムが取引をキューに入れます。
重要な理由プロセス内の待機時間を説明します。ボトルネックによる遅延と、支払期日を待つ意図的な待機を区別します。入手先「Entry Date」と「Effective Date」を比較します。「Effective Date」が将来の日付の場合、この状態が有効です。取得フィールドXとYの比較から導出イベントタイプ calculated
	支払い承認済み	資金が利用可能であり、取引を実行できる状態であることを社内で最終確認した時点です。承認と同時に発生する場合もあれば、独立したシステムチェックとして実行される場合もあります。
重要な理由管理者による承認とシステムレベルの認証を区別します。「Approval Authority Throughput」ダッシュボードに必要です。入手先「Authorized」または「Ready to Post」を示すステータス変更です。取得変更前後のステータス項目を比較イベントタイプ inferred
	支払い確認済み	外部ネットワークまたはゲートウェイから肯定応答（ACK）を受信します。次の処理主体が指示を正常に受け取ったことを確認します。
重要な理由「Instruction Sent」が成功したことを検証します。ここでの空白は、ネットワーク接続または外部フォーマットの問題を示します。入手先受信ファイル処理ログ、または受信を確認するAPI応答コードです。取得 ACK受信時に記録イベントタイプ explicit
	支払い詳細検証	システムが口座番号、銀行コード、形式上のコンプライアンスを確認します。通常は、エラーを発生させずに取引が受信済みステータスから保留中または承認済みステータスへ正常に移行した場合に推定されます。
重要な理由最初の自動ゲートを通過したことを示します。ここでの失敗は、流動性や承認の問題ではなく、データ品質の問題を意味します。入手先短時間のうちにステータスが「Received」から「Pending」または「Ready」へ変化したことから推定されます。取得変更前後のステータス項目を比較イベントタイプ inferred
	支払い通知送信済み	システムが支払人または受取人にメールやSMSで連絡し、取引を確認します。顧客への透明性を高めます。
重要な理由「Notification Speed and Responsiveness」を支えます。決済後の長い空白は、顧客の信頼を低下させます。入手先取引IDに関連付けられた通信ログまたは顧客対応履歴テーブルです。取得メールまたはSMSの送信時に記録イベントタイプ explicit

推奨任意

抽出ガイド

Fiservからデータを取得する方法

ステップ

1．前提条件の設定

Fiserv Commerce Hub開発者ポータルにアクセスできることを確認します。Transaction InquiryまたはSearch APIにアクセスする権限を持つAPI KeyとAPI Secret（Client IDとClient Secretと呼ばれる場合もあります）を発行する必要があります。IP制限が有効なFiserv環境では、IPアドレスが許可リストに登録されていることを確認します。

2．環境を準備します

抽出サーバーまたはローカルマシンにPython 3.8以降をインストールします。requestsとpandasライブラリが必要です。pip install requests pandasでインストールできます。スクリプトと出力ファイル用の作業ディレクトリを作成します。

3．スクリプトを設定します

提供されたPythonスクリプトを作業ディレクトリにダウンロードします。スクリプトを開き、先頭の設定セクションを更新します。固有のAPI_KEY、API_SECRET、BASE_URLを指定します。テスト時はサンドボックスURLを、最終実行時は本番URLを使用します。START_DATEとEND_DATEを、プロセスマイニングの対象期間に合わせて調整します。

4．認証ロジックを実装します

スクリプトには、Fiserv固有の認証要件に対応するヘルパークラスが含まれています。通常は、API Secret、タイムスタンプ、リクエストペイロードを使ってHMAC署名を生成します。Fiservの導入環境で異なる方式（例：OAuth2ベアラートークン）を使用していない限り、署名生成ロジックは変更しないでください。

5．解析ロジックを確認します

スクリプトはAPIに取引を問い合わせます。APIは通常、送信時刻、承認時刻、決済時刻など、複数のタイムスタンプを含む取引オブジェクトのスナップショットを返します。スクリプトはこの1つのJSONオブジェクトを解析し、イベントログ用の複数行に変換します。たとえば、送信タイムスタンプと決済タイムスタンプを含む1件のJSONレコードから、CSVには少なくとも2つの異なる行が生成されます。

6．ページネーションを処理します

スクリプトにはページネーションを処理するループが実装されています。Fiserv APIは1回のレスポンスに含めるレコード数を制限します（多くの場合50件または100件）。スクリプトは、指定期間のすべての取引を取得するまで次のページを自動的に要求します。大量のデータを取得する場合は時間がかかるため、インターネット接続が安定していることを確認してください。

7．実行します

コマンドラインからpython fiserv_extraction.pyを実行します。コンソールには、処理したページ数と取得した取引数が表示されます。HTTP 401（Unauthorized）または429（Rate Limit）エラーが発生していないか確認します。

8．出力を確認します

スクリプトの処理が完了したら、ディレクトリにfiserv_event_log.csvというファイルがあることを確認します。ファイルを開き、ActivityName列に必須の13アクティビティが混在していること、EventTimestamp列が正しい形式になっていることを確認します。

9．後処理（任意）

タイムゾーンの調整（例：UTCから現地時刻への変換）が必要な場合は、スクリプトのpandas変換部分を変更するか、アップロード後にProcessMindで処理できます。

10．ProcessMindにアップロードします

CSVファイルをProcessMindにインポートします。PaymentTransactionIdをCase ID、ActivityNameをActivity、EventTimestampをTimestampに対応付けます。PaymentAmountなどの数値列は属性として対応付けてください。

設定

API認証情報：API KeyとSecret／Shared Secretが必要です。これらにTransaction Reportingエンドポイントへの読み取りアクセス権があることを確認します。
ベースURL：本番環境ではhttps://api.commerce.fiserv.comを設定します。オンボーディング時に提供された証明書用またはサンドボックス用のURLがある場合は、それを使用します。
日付範囲：APIのペイロードサイズを考慮し、推奨する抽出期間は30～90日です。過去データを読み込む場合は、月単位でスクリプトを実行します。
ページサイズ：メモリ使用量とネットワーク負荷のバランスを取るため、1回の呼び出しにつき100レコードに設定します。
タイムゾーン：APIはタイムスタンプをUTCで返します。スクリプトは地域間の一貫性を保つため、この形式を維持します。
再試行ロジック：一時的なネットワークタイムアウト（HTTP 500／502／503）に対応する基本的な再試行機能が含まれています。

a サンプルクエリ python

import requests
import json
import time
import hmac
import hashlib
import base64
import uuid
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
API_KEY = class="hl-string">"YOUR_API_KEY"
API_SECRET = class="hl-string">"YOUR_API_SECRET"
BASE_URL = class="hl-string">"https://cert.api.fiservapps.com"  class=class="hl-string">"hl-comment"># Update to Production URL as needed
ENDPOINT = class="hl-string">"/ch/payments/v1/transaction-inquiry"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
PAGE_SIZE = 50
OUTPUT_FILE = class="hl-string">"fiserv_event_log.csv"

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># AUTHENTICATION HELPER
class=class="hl-string">"hl-comment"># ==========================================
def generate_headers(payload):
    class=class="hl-string">"hl-comment"># Fiserv Commerce Hub typically requires HMAC auth
    class=class="hl-string">"hl-comment"># This is a standard implementation pattern
    client_request_id = str(uuid.uuid4())
    timestamp = str(int(time.time() * 1000))
    
    class=class="hl-string">"hl-comment"># specific signature construction depends on Fiserv documentation version
    class=class="hl-string">"hl-comment"># standard pattern: apiKey + reqId + timestamp + payload
    raw_signature = API_KEY + client_request_id + timestamp + payload
    
    hmac_obj = hmac.new(
        API_SECRET.encode(class="hl-string">'utf-8'),
        raw_signature.encode(class="hl-string">'utf-8'),
        hashlib.sha256
    )
    message_signature = base64.b64encode(hmac_obj.digest()).decode(class="hl-string">'utf-8')
    
    return {
        class="hl-string">"Content-Type": class="hl-string">"application/json",
        class="hl-string">"Client-Request-Id": client_request_id,
        class="hl-string">"Api-Key": API_KEY,
        class="hl-string">"Timestamp": timestamp,
        class="hl-string">"Message-Signature": message_signature
    }

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># PARSING LOGIC (UNPIVOTING EVENTS)
class=class="hl-string">"hl-comment"># ==========================================
def extract_events_from_transaction(tx):
    events = []
    
    class=class="hl-string">"hl-comment"># Base Attributes
    case_id = tx.get(class="hl-string">"transactionId", class="hl-string">"")
    amount = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"total", 0.0)
    currency = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"currency", class="hl-string">"USD")
    method = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"type", class="hl-string">"Unknown")
    payer_acc = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"maskedAccountNumber", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Identifying common attributes
    base_data = {
        class="hl-string">"PaymentTransactionId": case_id,
        class="hl-string">"SourceSystem": class="hl-string">"Fiserv Commerce Hub",
        class="hl-string">"LastDataUpdate": datetime.utcnow().isoformat(),
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentMethod": method,
        class="hl-string">"PayerAccountNumber": payer_acc,
        class="hl-string">"PayeeAccountNumber": class="hl-string">"MerchantAccount", class=class="hl-string">"hl-comment"># Placeholder
        class="hl-string">"ErrorCode": tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseCode", class="hl-string">""),
        class="hl-string">"IsStraightThroughProcessing": class="hl-string">"True" class=class="hl-string">"hl-comment"># Default assumption unless error found
    }

    class=class="hl-string">"hl-comment"># Helper to append event
    def add_event(activity, timestamp_str, specific_attrs={}):
        if timestamp_str:
            row = base_data.copy()
            row.update({
                class="hl-string">"ActivityName": activity,
                class="hl-string">"EventTimestamp": timestamp_str
            })
            row.update(specific_attrs)
            events.append(row)

    class=class="hl-string">"hl-comment"># 1. Payment Request Created (Submission Time)
    submission_time = tx.get(class="hl-string">"submissionTime")
    add_event(class="hl-string">"Payment Request Created", submission_time)

    class=class="hl-string">"hl-comment"># 2. Payment Details Validated (Inferred: slightly after submission if no immediate 400 error)
    class=class="hl-string">"hl-comment"># We infer this exists if the transaction exists and has a submission time
    if submission_time:
        class=class="hl-string">"hl-comment"># Infer validation happened 1 second after submission
        val_time = (datetime.fromisoformat(submission_time.replace(class="hl-string">'Z', class="hl-string">'+00:00')) + timedelta(seconds=1)).isoformat()
        add_event(class="hl-string">"Payment Details Validated", val_time)

    class=class="hl-string">"hl-comment"># 3. Payment Error Identified / 4. Resolved
    status = tx.get(class="hl-string">"transactionStatus", class="hl-string">"")
    if status == class="hl-string">"FAILED":
        fail_time = tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseTimestamp", submission_time)
        add_event(class="hl-string">"Payment Error Identified", fail_time, {class="hl-string">"IsStraightThroughProcessing": class="hl-string">"False"})
    elif status == class="hl-string">"APPROVED" and tx.get(class="hl-string">"retryCount", 0) > 0:
        class=class="hl-string">"hl-comment"># Logic: If approved but had retries, an error was resolved
        add_event(class="hl-string">"Payment Error Resolved", submission_time) class=class="hl-string">"hl-comment"># Simplified assumption

    class=class="hl-string">"hl-comment"># 5. Payment Approved
    approval_time = tx.get(class="hl-string">"approvalTime")
    if approval_time:
        add_event(class="hl-string">"Payment Approved", approval_time)

    class=class="hl-string">"hl-comment"># 6. Payment Authorized
    auth_time = tx.get(class="hl-string">"authorizationTime")
    class=class="hl-string">"hl-comment"># If separate auth time not provided, use approval time
    if not auth_time and approval_time:
        auth_time = approval_time
    add_event(class="hl-string">"Payment Authorized", auth_time)

    class=class="hl-string">"hl-comment"># 7. Payment Scheduled (if future dated)
    req_exec_date = tx.get(class="hl-string">"requestedExecutionDate")
    if req_exec_date and req_exec_date > submission_time:
         add_event(class="hl-string">"Payment Scheduled", submission_time)

    class=class="hl-string">"hl-comment"># 8. Payment Instruction Sent
    gateway_time = tx.get(class="hl-string">"gatewayTransmitTime")
    add_event(class="hl-string">"Payment Instruction Sent", gateway_time)

    class=class="hl-string">"hl-comment"># 9. Payment Confirmed (Gateway ACK)
    gateway_ack = tx.get(class="hl-string">"gatewayAckTime")
    add_event(class="hl-string">"Payment Confirmed", gateway_ack)

    class=class="hl-string">"hl-comment"># 10. Payment Settled
    settle_time = tx.get(class="hl-string">"settlementTime") or tx.get(class="hl-string">"fundingDate")
    add_event(class="hl-string">"Payment Settled", settle_time)

    class=class="hl-string">"hl-comment"># 11. Payment Notification Sent (Inferred or specific field)
    notify_time = tx.get(class="hl-string">"customerNotificationEmailTime")
    add_event(class="hl-string">"Payment Notification Sent", notify_time)

    class=class="hl-string">"hl-comment"># 12. Payment Reconciled
    recon_time = tx.get(class="hl-string">"reconciliationDate")
    add_event(class="hl-string">"Payment Reconciled", recon_time)

    class=class="hl-string">"hl-comment"># 13. Payment Cancelled
    if status == class="hl-string">"VOIDED" or status == class="hl-string">"CANCELLED":
        void_time = tx.get(class="hl-string">"voidTime") or tx.get(class="hl-string">"lastUpdateTime")
        add_event(class="hl-string">"Payment Cancelled", void_time)

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXTRACTION LOOP
class=class="hl-string">"hl-comment"># ==========================================
def main():
    all_events = []
    page_number = 1
    has_more = True
    
    print(fclass="hl-string">"Starting extraction from {START_DATE} to {END_DATE}...")

    while has_more:
        class=class="hl-string">"hl-comment"># Construct Search Payload
        payload_dict = {
            class="hl-string">"startDate": START_DATE,
            class="hl-string">"endDate": END_DATE,
            class="hl-string">"page": page_number,
            class="hl-string">"limit": PAGE_SIZE
        }
        payload_json = json.dumps(payload_dict)
        
        headers = generate_headers(payload_json)
        full_url = BASE_URL + ENDPOINT
        
        try:
            response = requests.post(full_url, headers=headers, data=payload_json)
            
            if response.status_code == 200:
                data = response.json()
                transactions = data.get(class="hl-string">"reports", []) class=class="hl-string">"hl-comment"># Key depends on specific endpoint schema
                
                if not transactions:
                    print(fclass="hl-string">"No transactions found on page {page_number}. Finishing.")
                    has_more = False
                    break
                
                print(fclass="hl-string">"Processing page {page_number}, found {len(transactions)} transactions.")
                
                for tx in transactions:
                    events = extract_events_from_transaction(tx)
                    all_events.extend(events)
                
                class=class="hl-string">"hl-comment"># Pagination Check
                total_pages = data.get(class="hl-string">"totalPages", page_number)
                if page_number >= total_pages:
                    has_more = False
                else:
                    page_number += 1
            else:
                print(fclass="hl-string">"Error fetching data: {response.status_code} - {response.text}")
                has_more = False
                
        except Exception as e:
            print(fclass="hl-string">"Exception occurred: {str(e)}")
            has_more = False

    class=class="hl-string">"hl-comment"># ==========================================
    class=class="hl-string">"hl-comment"># EXPORT TO CSV
    class=class="hl-string">"hl-comment"># ==========================================
    if all_events:
        df = pd.DataFrame(all_events)
        class=class="hl-string">"hl-comment"># Column ordering
        cols = [
            class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 
            class="hl-string">"SourceSystem", class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentMethod",
            class="hl-string">"PayerAccountNumber", class="hl-string">"ErrorCode", class="hl-string">"IsStraightThroughProcessing"
        ]
        class=class="hl-string">"hl-comment"># Ensure columns exist even if empty
        for c in cols:
            if c not in df.columns:
                df[c] = None
                
        df = df[cols]
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">"Extraction complete. {len(df)} rows written to {OUTPUT_FILE}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    main()

準備はできましたか？

このテンプレートをFiserv環境に適用して、財務ワークフローの改善を始めます。ガイドに沿って進めることで、キャッシュフローと業務上のコンプライアンス対応を改善するために必要なデータを確実にそろえられます。

改善ガイドに戻るテンプレートをダウンロード

支払処理を最適化し、今すぐSTP98％を達成

照合の遅延をなくし、Fiservのワークフローを適切に管理します。

無料トライアルを開始

クレジットカードは不要です。数分で設定できます。

支払処理用データテンプレート

支払処理用データテンプレート

決済処理の属性

決済処理のアクティビティ

抽出ガイド

Fiserv Commerce Hub API用Pythonスクリプト

ステップ

1．前提条件の設定

2．環境を準備します

3．スクリプトを設定します

4．認証ロジックを実装します

5．解析ロジックを確認します

6．ページネーションを処理します

7．実行します

8．出力を確認します

9．後処理（任意）

10．ProcessMindにアップロードします

設定

a サンプルクエリ python

準備はできましたか？

支払処理を最適化し、今すぐSTP98％を達成

プライバシーを大切にしています