> Cải tiến quy trình liên tục > Xử lý thanh toán > Fiserv > Mẫu dữ liệu

Mẫu dữ liệu xử lý thanh toán

Name: Mẫu dữ liệu process mining cho quy trình Xử lý thanh toán
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

← Quay lại hướng dẫn cải tiến

Thuộc tính xử lý thanh toán(19) Hoạt động xử lý thanh toán(13) Hướng dẫn trích xuất dữ liệu(1)

Mẫu dữ liệu xử lý thanh toán

Mẫu này cung cấp cấu trúc giúp bạn chuyển dữ liệu Fiserv sang định dạng phù hợp cho process mining và phân tích. Mẫu nêu các thuộc tính và hoạt động cần thiết để bạn theo dõi rõ chu kỳ quyết toán và đối soát. Làm theo hướng dẫn để tạo nhật ký sự kiện, qua đó nhận diện điểm kém hiệu quả và rủi ro tuân thủ trong hoạt động tài chính.

Các thuộc tính nên dùng để phân tích thanh toán
Các mốc quan trọng cần theo dõi trong quy trình
Hướng dẫn kỹ thuật trích xuất dữ liệu Fiserv

Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Tải mẫu xuống

Thuộc tính xử lý thanh toán

Các trường dữ liệu được đề xuất cung cấp ngữ cảnh cần thiết cho nhật ký sự kiện, giúp bạn phân tích toàn bộ vòng đời thanh toán.

5 Bắt buộc 9 Nên có 5 Không bắt buộc

	Tên	Mô tả
	Dấu thời gian sự kiện EventTimestamp	Ngày và giờ chính xác khi hoạt động diễn ra.
Mô tả Thuộc tính này ghi lại chính xác thời điểm một sự kiện diễn ra. Đây là cơ sở cho mọi phân tích thời gian, bao gồm thời gian chu kỳ, thời gian xử lý và xác định điểm nghẽn. Trong bảng điều khiển, dữ liệu này dùng để tính thời lượng giữa các bước, chẳng hạn như khoảng thời gian từ “Đã tạo yêu cầu thanh toán” đến “Đã xác thực thanh toán”. Dấu thời gian có độ chính xác cao giúp sắp xếp đúng thứ tự các sự kiện diễn ra liên tiếp trong thời gian ngắn. Vì sao điều này quan trọng Cần thiết để sắp xếp sự kiện và tính thời lượng hiệu suất của quy trình. Lấy dữ liệu ở đâu Nhật ký kiểm tra hoặc cột dấu thời gian cập nhật giao dịch. Ví dụ 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Mã giao dịch thanh toán PaymentTransactionId	Mã định danh duy nhất của chỉ thị thanh toán hoặc trường hợp giao dịch cụ thể.
Mô tả Thuộc tính này là khóa trung tâm để liên kết mọi hoạt động trong một vòng đời thanh toán. Nhờ đó, chuyên viên phân tích có thể theo dõi từ yêu cầu ban đầu qua các bước xác thực, phê duyệt đến khi tất toán hoặc hủy. Trong môi trường Fiserv, đây thường là khóa chính trong các bảng lịch sử giao dịch. Thuộc tính này rất cần thiết để dựng lại luồng quy trình và đảm bảo các sự kiện rời rạc, chẳng hạn như tất toán diễn ra vài ngày sau khi xác thực, được liên kết đúng với cùng một đối tượng nghiệp vụ. Vì sao điều này quan trọng Đây là Case ID cơ bản cần có để nhóm các sự kiện thành từng phiên bản quy trình. Lấy dữ liệu ở đâu Tham khảo tài liệu Fiserv về các bảng Transaction hoặc Payment Header. Ví dụ TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Tên hoạt động ActivityName	Sự kiện hoặc thay đổi trạng thái cụ thể đã xảy ra trong quy trình thanh toán.
Mô tả Thuộc tính này mô tả bước đã thực hiện, chẳng hạn như “Đã tạo yêu cầu thanh toán” hoặc “Đã tất toán thanh toán”. Thuộc tính xác định các nút trên sơ đồ quy trình và rất quan trọng để hiểu trình tự vận hành. Phân tích từng hoạt động giúp tổ chức hình dung quy trình làm việc, phát hiện bước bị bỏ qua và tìm ra các luồng không tuân thủ, trong đó bước xác thực hoặc phê duyệt bắt buộc đã bị bỏ qua. Vì sao điều này quan trọng Xác định các sự kiện tạo nên dòng thời gian của quy trình. Lấy dữ liệu ở đâu Nhật ký lịch sử giao dịch hoặc bảng kiểm tra thay đổi trạng thái. Ví dụ Đã tạo yêu cầu thanh toánĐã cấp phép thanh toánĐã phát hiện lỗi thanh toánĐã tất toán thanh toánĐã hủy thanh toán
	Hệ thống nguồn SourceSystem	Tên hệ thống nơi dữ liệu bắt nguồn.
Mô tả Xác định mô-đun Fiserv hoặc hệ thống bên ngoài cụ thể đã tạo sự kiện. Thuộc tính này đặc biệt hữu ích trong môi trường phức tạp, nơi khoản thanh toán có thể bắt đầu từ kênh giao dịch trực tiếp và được tất toán trong hệ thống ngân hàng lõi ở phía sau. Chuyên viên phân tích có thể lọc chế độ xem quy trình theo hệ thống nguồn, từ đó tập trung phân tích vào từng môi trường kỹ thuật hoặc điểm tích hợp cụ thể. Vì sao điều này quan trọng Cung cấp bối cảnh kỹ thuật và nguồn gốc dữ liệu. Lấy dữ liệu ở đâu Được gán cố định trong quá trình trích xuất hoặc lấy từ siêu dữ liệu hệ thống. Ví dụ Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Lần cập nhật dữ liệu gần nhất LastDataUpdate	Dấu thời gian cho biết lần gần nhất bản ghi được trích xuất hoặc làm mới.
Mô tả Cho biết dữ liệu dùng để phân tích có mới hay không. Điều này rất quan trọng để xác định bảng điều khiển phản ánh vận hành theo thời gian thực hay dữ liệu lịch sử. Thông tin này giúp người dùng tin tưởng vào các chỉ số hiển thị và tránh đưa ra quyết định dựa trên dữ liệu cũ, nhất là khi theo dõi việc tuân thủ giờ chốt hoặc các điểm nghẽn đang diễn ra. Vì sao điều này quan trọng Đảm bảo dữ liệu được cập nhật và đáng tin cậy. Lấy dữ liệu ở đâu Thời gian hệ thống tại thời điểm chạy ETL. Ví dụ 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Mã lỗi ErrorCode	Mã cụ thể được tạo khi khoản thanh toán không vượt qua bước xác thực.
Mô tả Ghi lại mã lỗi kỹ thuật hoặc nghiệp vụ gắn với hoạt động “Đã phát hiện lỗi thanh toán”. Thuộc tính này là nền tảng của công cụ theo dõi lỗi xác thực và xử lý lại. Tổng hợp tần suất của từng mã lỗi giúp tổ chức xác định các vấn đề chất lượng dữ liệu mang tính hệ thống, chẳng hạn như “Số định tuyến không hợp lệ”, rồi đưa ra biện pháp phù hợp để sửa logic xác thực hoặc đào tạo người dùng. Vì sao điều này quan trọng Giúp xác định nguyên nhân gốc rễ của việc xử lý lại. Lấy dữ liệu ở đâu Nhật ký lỗi hoặc chi tiết trạng thái giao dịch. Ví dụ E-101INV_ACCNSF_ERRAUTH_FAIL
	Mã tiền tệ CurrencyCode	Mã tiền tệ ISO của khoản thanh toán.
Mô tả Cho biết khoản thanh toán được tính bằng loại tiền nào, chẳng hạn như USD hoặc EUR. Thuộc tính này rất quan trọng đối với bảng điều khiển Xu hướng khối lượng theo tiền tệ và phương thức, giúp tổ chức theo dõi mức độ tiếp xúc với các loại ngoại tệ. Thuộc tính này cũng được dùng để quy đổi số tiền về cùng một chuẩn khi lập báo cáo toàn cầu và tránh đánh dấu nhầm các giao dịch có cùng giá trị số nhưng khác loại tiền là trùng lặp. Vì sao điều này quan trọng Cần thiết để phân tích quy trình xử lý nhiều loại tiền tệ. Lấy dữ liệu ở đâu Bảng tiêu đề giao dịch, cột Currency. Ví dụ USDEURGBPCADJPY
	Ngày đến hạn thanh toán PaymentDueDate	Ngày cuối cùng khoản thanh toán phải được xử lý.
Mô tả Ngày mục tiêu để hoàn tất thanh toán. Thuộc tính này được dùng trong Công cụ giám sát tuân thủ giờ chốt xử lý để đánh dấu các giao dịch có nguy cơ trễ hạn. So sánh dấu thời gian “Đã tất toán thanh toán” với thuộc tính này giúp tính các chỉ số giao đúng hạn và duy trì niềm tin của người nhận. Vì sao điều này quan trọng Mốc tham chiếu để đo mức độ đáp ứng SLA. Lấy dữ liệu ở đâu Chi tiết chỉ thị thanh toán. Ví dụ 2023-11-012023-11-15
	Người xử lý ProcessingUser	ID người dùng hoặc tác nhân hệ thống chịu trách nhiệm cho hoạt động.
Mô tả Cho biết ai thực hiện hành động cụ thể, có thể là người phê duyệt hoặc bot tự động của hệ thống. Dữ liệu này hỗ trợ các bảng điều khiển Hiệu quả xử lý lỗi và Thông lượng phê duyệt theo thẩm quyền. Theo dõi người dùng giúp chuyên viên phân tích xác định nhu cầu đào tạo cho những người thường mắc lỗi, hoặc phát hiện điểm nghẽn khi một số người phê duyệt phải xử lý quá nhiều yêu cầu. Vì sao điều này quan trọng Hỗ trợ phân tích tài nguyên và xác định điểm nghẽn. Lấy dữ liệu ở đâu Nhật ký kiểm tra, cột User ID. Ví dụ jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Phương thức thanh toán PaymentMethod	Cách thức thực hiện thanh toán, chẳng hạn như Wire hoặc ACH.
Mô tả Phân loại giao dịch theo kênh xử lý. Thuộc tính này rất quan trọng đối với phân tích thời gian chu kỳ xác thực, vì mỗi phương thức có quy trình vận hành tiêu chuẩn và cam kết mức dịch vụ rất khác nhau. Phân tích các biến thể quy trình theo phương thức thanh toán giúp xác định liệu chậm trễ chỉ xảy ra ở một kênh cụ thể, chẳng hạn như chuyển tiền quốc tế, hay phổ biến trong toàn tổ chức. Vì sao điều này quan trọng Phân nhóm luồng quy trình theo hạ tầng được sử dụng. Lấy dữ liệu ở đâu Loại giao dịch hoặc cột mã phương thức. Ví dụ Chuyển khoản WireACHSécRTPChuyển khoản nội bộ
	Số tài khoản người nhận PayeeAccountNumber	Số tài khoản được ghi có.
Mô tả Xác định tài khoản nhận tiền. Tương tự tài khoản người trả, thuộc tính này rất quan trọng đối với chế độ xem Phát hiện thanh toán trùng lặp. Nhờ đó, phân tích tập trung đúng vào từng mối quan hệ với người thụ hưởng. Khi giám sát việc tuân thủ giờ chốt, thông tin người nhận giúp ưu tiên các nhà cung cấp chiến lược hoặc khoản tất toán quan trọng không được phép thất bại. Vì sao điều này quan trọng Cần thiết để phát hiện thanh toán trùng lặp và phân tích người nhận. Lấy dữ liệu ở đâu Chi tiết giao dịch, cột Credit Account hoặc Beneficiary. Ví dụ 555000111222333444BEN-882-11
	Số tài khoản người trả PayerAccountNumber	Số tài khoản bị trừ tiền.
Mô tả Xác định tài khoản nguồn của khoản thanh toán. Đây là thành phần quan trọng trong chế độ xem Phát hiện thanh toán trùng lặp. Khi kết hợp với người nhận, số tiền và thời gian, thuộc tính này tạo thành dấu hiệu nhận diện duy nhất để phát hiện các khoản thanh toán vô tình bị gửi hai lần. Thuộc tính này cũng cho phép phân tích khối lượng thanh toán theo tài khoản nguồn để xác định các danh mục nội bộ có hoạt động nhiều nhất. Vì sao điều này quan trọng Cần thiết để phát hiện thanh toán trùng lặp và phân tích gian lận. Lấy dữ liệu ở đâu Chi tiết giao dịch, cột Debit Account. Ví dụ 123456789987654321ACC-001-992
	Số tiền thanh toán PaymentAmount	Giá trị tiền tệ của giao dịch thanh toán.
Mô tả Thuộc tính này thể hiện giá trị tài chính của khoản thanh toán. Đây là chiều phân tích chính, giúp người dùng phân biệt các khoản thanh toán chiến lược giá trị cao với giao dịch thường lệ giá trị thấp. Thuộc tính này rất cần thiết cho chế độ xem Phát hiện thanh toán trùng lặp. Các khoản tiền giống nhau cùng thông tin người trả/người nhận có thể là dấu hiệu của lỗi. Thuộc tính này cũng hỗ trợ phân tích thẩm quyền phê duyệt, vì khoản tiền lớn hơn thường đi theo luồng quy trình khác. Vì sao điều này quan trọng Quan trọng để phân tích rủi ro tài chính và phát hiện giao dịch trùng lặp. Lấy dữ liệu ở đâu Bảng tiêu đề giao dịch, cột Amount. Ví dụ 150.0025000.5010.991000000.00
	Xử lý tự động xuyên suốt IsStraightThroughProcessing	Cờ cho biết khoản thanh toán có cần can thiệp thủ công hay không.
Mô tả Thuộc tính boolean được tính toán, có giá trị đúng nếu trường hợp không có bước “Đã phát hiện lỗi thanh toán”, “Đã xử lý lỗi thanh toán” hoặc “Đã phê duyệt thanh toán” thủ công, tùy theo định nghĩa. Thuộc tính này hỗ trợ trực tiếp KPI Tỷ lệ xử lý tự động xuyên suốt. Thuộc tính này cho phép phân nhóm quy trình thành hai loại: luồng hoàn toàn tự động và luồng cần người xử lý, giúp thấy rõ tiềm năng tự động hóa. Vì sao điều này quan trọng Chỉ số cốt lõi để đánh giá hiệu quả quy trình và mức độ thành công của tự động hóa. Lấy dữ liệu ở đâu Được tính trong quá trình chuyển đổi dữ liệu. Ví dụ truefalse
	Cấp phê duyệt ApprovalLevel	Cấp bậc cần có hoặc được sử dụng để xác thực khoản thanh toán.
Mô tả Cho biết thâm niên hoặc cấp thẩm quyền gắn với hoạt động “Đã phê duyệt thanh toán”. Thuộc tính này được dùng trong bảng điều khiển Thông lượng phê duyệt theo thẩm quyền để phân tích xem người phê duyệt cấp cao có trở thành điểm nghẽn hay không. Hiểu cách phân bổ khoản thanh toán theo cấp, chẳng hạn Cấp 1 so với Cấp 3, giúp tối ưu chính sách phân quyền. Vì sao điều này quan trọng Phân tích điểm nghẽn phê duyệt theo cấp bậc. Lấy dữ liệu ở đâu Vai trò người dùng hoặc bảng quy trình phê duyệt. Ví dụ Cấp 1Quản lýGiám đốcCFO
	Công việc xử lý lại IsRework	Cờ cho biết hoạt động cụ thể này có thuộc vòng lặp xử lý lại hay không.
Mô tả Cờ boolean đánh dấu các hoạt động diễn ra sau khi phát hiện lỗi nhưng trước khi xử lý xong, hoặc các hoạt động bị lặp lại. Thuộc tính này hỗ trợ KPI Tỷ lệ xử lý lại trong xác thực thanh toán. Chuyên viên phân tích có thể lọc sơ đồ quy trình để chỉ hiển thị “luồng chuẩn”, hoặc chỉ tập trung vào “luồng xử lý lại” nhằm hiểu các dạng lỗi. Vì sao điều này quan trọng Tách biệt công việc tạo giá trị với công việc sửa lỗi. Lấy dữ liệu ở đâu Được tính dựa trên các vòng lặp trong quy trình. Ví dụ truefalse
	Đơn vị kinh doanh BusinessUnit	Phòng ban hoặc bộ phận khởi tạo khoản thanh toán.
Mô tả Phân loại khoản thanh toán theo đơn vị tổ chức chịu trách nhiệm cho khoản chi. Thông tin này giúp phân bổ chi phí và xác định bộ phận nào tạo ra nhiều công việc xử lý lại thủ công hoặc lỗi nhất. Thuộc tính này hỗ trợ hoạt động kiểm tra tuân thủ luồng thanh toán, đảm bảo từng đơn vị đáp ứng các yêu cầu kiểm soát nội bộ hoặc quy định riêng. Vì sao điều này quan trọng Cung cấp bối cảnh tổ chức để đánh giá hiệu suất. Lấy dữ liệu ở đâu Ánh xạ trung tâm chi phí hoặc mã phòng ban. Ví dụ Ngân hàng bán lẻCho vay thương mạiQuản lý tài sảnVận hành
	Lỡ giờ chốt IsCutoffMissed	Cờ cho biết khoản thanh toán được gửi sau giờ chốt hằng ngày của ngân hàng hay không.
Mô tả Giá trị boolean được tính bằng cách so sánh thời điểm “Đã gửi chỉ thị thanh toán” với giờ chốt hằng ngày của loại tiền tệ/phương thức cụ thể. Thuộc tính này hỗ trợ KPI Tỷ lệ đáp ứng giờ chốt. Xác định các trường hợp lỡ giờ chốt giúp tìm nguyên nhân gốc rễ của chậm trễ, dù do khởi tạo muộn hay xử lý nội bộ chậm. Vì sao điều này quan trọng Quan trọng để đảm bảo tuân thủ trong vận hành và quản lý thanh khoản. Lấy dữ liệu ở đâu Được tính bằng cách so sánh EventTimestamp với bảng Cutoff Reference. Ví dụ truefalse
	Ngân hàng thụ hưởng BeneficiaryBank	Tên hoặc mã định danh của ngân hàng nhận tiền.
Mô tả Xác định tổ chức tài chính nhận khoản thanh toán. Thông tin này hữu ích khi phân tích chậm trễ trong tất toán, vì tốc độ xử lý hoặc vấn đề tích hợp có thể khác nhau giữa các ngân hàng nhận. Thuộc tính này bổ sung một chiều phân tích cho bảng điều khiển Khoảng cách từ tất toán đến đối soát, giúp xác định chậm trễ đến từ bên ngoài, cụ thể là ngân hàng nào, hay từ nội bộ. Vì sao điều này quan trọng Phân tích các yếu tố phụ thuộc bên ngoài. Lấy dữ liệu ở đâu Chi tiết giao dịch, cột Bank ID hoặc Name. Ví dụ ChaseBank of AmericaWells FargoCitibank

Bắt buộc Nên có Không bắt buộc

Hoạt động xử lý thanh toán

Ghi lại các bước và mốc quan trọng này vào nhật ký sự kiện để khám phá và tối ưu hóa quy trình thanh toán chính xác hơn.

5 Nên có 8 Không bắt buộc

	Hoạt động	Mô tả
	Đã đối soát thanh toán	Đối chiếu nội bộ giao dịch với sao kê ngân hàng hoặc tệp tất toán. Bước này khép lại quy trình kế toán.
Vì sao điều này quan trọng Cần thiết để theo dõi “Khoảng cách từ tất toán đến đối soát”. Giúp chốt sổ tài chính chính xác. Lấy dữ liệu ở đâu Nhật ký của mô-đun đối soát, ghi nhận khi trạng thái chuyển thành “Đã khớp” hoặc “Đã đối soát”. Thu thập Ghi nhận khi giao dịch được khớp trong quá trình đối soát Loại sự kiện explicit
	Đã gửi chỉ thị thanh toán	Chuyển tệp thanh toán, chẳng hạn như lô ACH hoặc thông điệp Wire, đến mạng lưới bên ngoài hoặc đơn vị thanh toán bù trừ. Đây là điểm bàn giao quan trọng.
Vì sao điều này quan trọng Quan trọng đối với “Công cụ giám sát tuân thủ giờ chốt xử lý”. Giúp tổ chức đáp ứng giờ chốt giao dịch ngân hàng hằng ngày. Lấy dữ liệu ở đâu Nhật ký xử lý theo lô hoặc dấu thời gian tạo tệp. Thường được ghi nhận là “Đã tạo lô” hoặc “Đã truyền tệp”. Thu thập Ghi nhận khi tạo tệp lô Loại sự kiện explicit
	Đã phê duyệt thanh toán	Quyết định thủ công hoặc tự động cho phép thanh toán tiếp tục dựa trên hạn mức thẩm quyền. Sự kiện này được ghi nhận khi người dùng có thẩm quyền hoặc quy tắc hệ thống cập nhật cờ phê duyệt.
Vì sao điều này quan trọng Chỉ số quan trọng cho 'Authorization Cycle Time Analysis'. Chậm trễ ở bước này cho thấy điểm nghẽn trong chuỗi phê duyệt của nhân viên. Lấy dữ liệu ở đâu Nhật ký kiểm toán ghi lại thao tác của người dùng làm trạng thái đổi từ 'Pending Approval' sang 'Approved'. Thu thập Được ghi nhận khi thao tác phê duyệt được thực hiện Loại sự kiện explicit
	Đã tạo yêu cầu thanh toán	Thời điểm chỉ thị thanh toán được nhập lần đầu vào hệ thống Fiserv. Sự kiện này được ghi nhận rõ khi người dùng hoặc hệ thống bên ngoài khởi tạo giao dịch qua API hoặc giao diện.
Vì sao điều này quan trọng Đánh dấu thời điểm bắt đầu quy trình. Đây là mốc cần thiết để tính tổng thời gian xử lý và xác định điểm nghẽn ở khâu tiếp nhận. Lấy dữ liệu ở đâu Dấu thời gian tạo bản ghi trong bảng lịch sử giao dịch. Tìm bản ghi sớm nhất có Payment Transaction ID tương ứng. Thu thập Được ghi nhận khi bản ghi giao dịch được tạo Loại sự kiện explicit
	Đã tất toán thanh toán	Việc chuyển tiền đã hoàn tất và được ghi vào sổ cái tổng hợp. Theo góc nhìn của ngân hàng, đây là lúc giao dịch hoàn tất về mặt tài chính.
Vì sao điều này quan trọng Điểm kết thúc chính để tính “Tỷ lệ xử lý tự động xuyên suốt”. Cho biết tiền đã thực sự được chuyển. Lấy dữ liệu ở đâu Trạng thái giao dịch “Đã ghi sổ” hoặc có dấu thời gian “Ngày ghi sổ” trong sổ cái. Thu thập Ghi nhận khi phát sinh bút toán vào sổ cái tổng hợp Loại sự kiện explicit
	Đã cấp phép thanh toán	Xác nhận nội bộ cuối cùng rằng có đủ tiền và giao dịch đã được phép thực hiện. Bước này có thể diễn ra cùng lúc với phê duyệt hoặc như một lần kiểm tra riêng của hệ thống.
Vì sao điều này quan trọng Phân biệt giữa phê duyệt của cấp quản lý và xác thực ở cấp hệ thống. Quan trọng đối với bảng điều khiển “Thông lượng phê duyệt theo thẩm quyền”. Lấy dữ liệu ở đâu Trạng thái thay đổi thành “Đã xác thực” hoặc “Sẵn sàng ghi sổ”. Thu thập So sánh trường trạng thái trước và sau Loại sự kiện inferred
	Đã gửi thông báo thanh toán	Hệ thống gửi thông báo qua email/SMS cho người trả hoặc người nhận tiền để xác nhận giao dịch. Nhờ đó, khách hàng nắm rõ tình trạng giao dịch hơn.
Vì sao điều này quan trọng Hỗ trợ theo dõi “Tốc độ và mức độ phản hồi thông báo”. Khoảng chờ lâu sau khi tất toán có thể làm giảm niềm tin của khách hàng. Lấy dữ liệu ở đâu Nhật ký liên lạc hoặc bảng lịch sử tương tác với khách hàng được liên kết với Transaction ID. Thu thập Ghi nhận khi gửi email/SMS Loại sự kiện explicit
	Đã hủy thanh toán	Dừng luồng thanh toán trước khi tất toán theo yêu cầu của người dùng hoặc quy tắc hệ thống. Mọi bước xử lý tiếp theo đều bị dừng.
Vì sao điều này quan trọng Giúp phát hiện công việc lãng phí và bị bỏ dở. Tỷ lệ hủy cao sau khi phê duyệt có thể cho thấy quy trình chưa hiệu quả. Lấy dữ liệu ở đâu Trạng thái chuyển thành “Đã hủy”, “Vô hiệu” hoặc “Đã dừng”. Thu thập Ghi nhận khi trạng thái chuyển thành Đã hủy Loại sự kiện explicit
	Đã lên lịch thanh toán	Xảy ra khi khoản thanh toán đã được phê duyệt nhưng được giữ lại đến ngày hiệu lực trong tương lai. Hệ thống xếp giao dịch vào hàng đợi cho đến khi bắt đầu khung giờ xử lý.
Vì sao điều này quan trọng Giải thích thời gian chờ trong quy trình. Phân biệt giữa chậm trễ do điểm nghẽn và thời gian chờ có chủ đích đến ngày đến hạn. Lấy dữ liệu ở đâu So sánh “Ngày nhập” với “Ngày hiệu lực”. Trạng thái này có hiệu lực nếu Ngày hiệu lực nằm trong tương lai. Thu thập Suy ra bằng cách so sánh trường X với Y Loại sự kiện calculated
	Đã phát hiện lỗi thanh toán	Ghi nhận thời điểm giao dịch bị đánh dấu lỗi hoặc có mã ngoại lệ. Tình huống này xảy ra khi giao dịch không đạt quy tắc xác thực hoặc kiểm tra bên ngoài trả về kết quả không đạt.
Vì sao điều này quan trọng Cần thiết cho dashboard 'Validation Error and Rework Tracker'. Số lượng cao ở bước này cho thấy dữ liệu đầu vào có vấn đề về chất lượng. Lấy dữ liệu ở đâu Trường trạng thái giao dịch chuyển sang mã ngoại lệ, chẳng hạn 'Invalid', 'Hold' hoặc 'Error'. Thu thập Được ghi nhận khi trạng thái chuyển thành Error Loại sự kiện explicit
	Đã xác nhận thanh toán	Nhận xác nhận tích cực (ACK) từ mạng lưới hoặc cổng kết nối bên ngoài. Điều này xác nhận đơn vị tiếp theo đã nhận chỉ thị hợp lệ.
Vì sao điều này quan trọng Xác nhận “Đã gửi chỉ thị” thành công. Nếu có khoảng trống ở bước này, nguyên nhân có thể là sự cố kết nối mạng hoặc định dạng bên ngoài không phù hợp. Lấy dữ liệu ở đâu Nhật ký xử lý tệp đến hoặc mã phản hồi API xác nhận đã nhận. Thu thập Ghi nhận khi nhận ACK Loại sự kiện explicit
	Đã xác thực thông tin thanh toán	Hệ thống kiểm tra số tài khoản, mã định tuyến và định dạng theo yêu cầu. Thường có thể suy ra bước này đã hoàn tất khi giao dịch chuyển thành công từ trạng thái đã nhận sang đang chờ hoặc đã phê duyệt mà không phát sinh lỗi.
Vì sao điều này quan trọng Cho biết giao dịch đã qua bước kiểm tra tự động đầu tiên. Nếu không qua được bước này, nguyên nhân thường là chất lượng dữ liệu chứ không phải thanh khoản hay phê duyệt. Lấy dữ liệu ở đâu Có thể suy ra từ việc trạng thái đổi từ 'Received' sang 'Pending' hoặc 'Ready' trong thời gian ngắn. Thu thập So sánh trường trạng thái trước và sau Loại sự kiện inferred
	Đã xử lý lỗi thanh toán	Cho biết giao dịch từng gặp lỗi đã được sửa. Có thể suy ra bước này đã hoàn tất khi trạng thái giao dịch chuyển từ lỗi về trạng thái đang xử lý hoặc hợp lệ.
Vì sao điều này quan trọng Cần thiết để tính 'Mean Time to Resolve Payment Errors'. Chỉ số này giúp đo hiệu quả của đội ngũ vận hành. Lấy dữ liệu ở đâu Có thể suy ra khi trạng thái giao dịch chuyển từ mã lỗi sang mã xử lý thông thường. Thu thập So sánh trường trạng thái trước và sau Loại sự kiện inferred

Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Fiserv

Các bước

1. Cấu hình điều kiện cần

Đảm bảo bạn có quyền truy cập cổng dành cho nhà phát triển Fiserv Commerce Hub. Tạo API Key và API Secret (đôi khi được gọi là Client ID và Client Secret) có quyền truy cập Transaction Inquiry hoặc Search API. Nếu môi trường Fiserv bật giới hạn IP, hãy xác nhận địa chỉ IP của bạn nằm trong danh sách cho phép.

2. Thiết lập môi trường

Cài Python 3.8 trở lên trên máy chủ trích xuất hoặc máy tính của bạn. Bạn cần các thư viện requests và pandas. Cài đặt bằng pip: pip install requests pandas. Tạo thư mục làm việc cho tập lệnh và các tệp đầu ra.

3. Cấu hình tập lệnh

Tải tập lệnh Python được cung cấp vào thư mục làm việc. Mở tập lệnh và cập nhật phần cấu hình ở đầu tệp. Nhập API_KEY, API_SECRET và BASE_URL của bạn (dùng URL sandbox để kiểm thử và URL production khi chạy chính thức). Điều chỉnh START_DATE và END_DATE theo khoảng thời gian process mining cần phân tích.

4. Triển khai logic xác thực

Tập lệnh có lớp hỗ trợ xử lý yêu cầu xác thực riêng của Fiserv. Thông thường, lớp này tạo chữ ký HMAC từ API Secret, dấu thời gian và nội dung yêu cầu. Không sửa logic tạo chữ ký, trừ khi hệ thống Fiserv của bạn dùng chuẩn khác, chẳng hạn OAuth2 bearer token.

5. Tìm hiểu logic phân tích dữ liệu

Tập lệnh truy vấn API để lấy giao dịch. API thường trả về ảnh chụp đối tượng giao dịch với nhiều dấu thời gian, chẳng hạn thời điểm gửi, thời điểm cấp phép và thời điểm thanh toán. Tập lệnh phân tích một đối tượng JSON rồi chuyển dữ liệu thành nhiều hàng sự kiện trong nhật ký sự kiện. Ví dụ, một bản ghi JSON có dấu thời gian gửi và thanh toán sẽ tạo ít nhất hai hàng riêng trong tệp CSV.

6. Xử lý phân trang

Tập lệnh có vòng lặp để xử lý phân trang. Fiserv API giới hạn số bản ghi trong mỗi phản hồi, thường là 50 hoặc 100. Tập lệnh tự động yêu cầu trang tiếp theo cho đến khi lấy đủ giao dịch trong khoảng ngày đã chọn. Đảm bảo kết nối internet ổn định, vì quá trình này có thể mất thời gian với tập dữ liệu lớn.

7. Chạy tập lệnh

Chạy tập lệnh từ dòng lệnh: python fiserv_extraction.py. Bảng điều khiển sẽ hiển thị tiến độ, gồm số trang đã xử lý và số giao dịch đã lấy. Theo dõi các lỗi HTTP 401 (Unauthorized) hoặc 429 (Rate Limit).

8. Kiểm tra đầu ra

Sau khi tập lệnh chạy xong, tìm tệp fiserv_event_log.csv trong thư mục. Mở tệp và kiểm tra cột ActivityName có đủ 13 hoạt động bắt buộc, đồng thời trường EventTimestamp được định dạng chính xác.

9. Xử lý sau khi trích xuất (không bắt buộc)

Nếu cần điều chỉnh múi giờ cụ thể, chẳng hạn chuyển UTC sang giờ địa phương, bạn có thể sửa phần chuyển đổi dữ liệu pandas trong tập lệnh hoặc xử lý việc này trong ProcessMind sau khi tải lên.

10. Tải lên ProcessMind

Nhập tệp CSV vào ProcessMind. Ánh xạ PaymentTransactionId thành Case ID, ActivityName thành Hoạt động và EventTimestamp thành dấu thời gian. Đảm bảo các cột dạng số như PaymentAmount được ánh xạ thành thuộc tính.

Cấu hình

Thông tin xác thực API: Cần API Key và Secret/Shared Secret. Đảm bảo các thông tin này có quyền đọc dữ liệu từ các endpoint Transaction Reporting.
URL cơ sở: Dùng https://api.commerce.fiserv.com cho môi trường production hoặc URL cert/sandbox cụ thể được cung cấp trong quá trình thiết lập.
Khoảng ngày: Do giới hạn kích thước dữ liệu API, nên trích xuất trong 30 đến 90 ngày. Với dữ liệu lịch sử, hãy chạy script theo từng tháng.
Kích thước trang: Được đặt ở mức 100 bản ghi mỗi lần gọi để cân bằng mức dùng bộ nhớ và tải mạng.
Múi giờ: API trả về dấu thời gian theo UTC. Script giữ nguyên định dạng này để dữ liệu nhất quán giữa các khu vực.
Cơ chế thử lại: Có cơ chế thử lại cơ bản khi mạng tạm thời hết thời gian chờ (HTTP 500/502/503).

Truy vấn mẫu 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()

Sẵn sàng bắt đầu?

Bắt đầu tối ưu hóa quy trình làm việc tài chính bằng cách áp dụng mẫu này cho môi trường Fiserv của bạn. Hướng dẫn giúp bạn chuẩn bị đúng dữ liệu để cải thiện dòng tiền và mức độ tuân thủ trong vận hành.

Quay lại hướng dẫn cải tiến

Tải mẫu xuống

Tối ưu hóa xử lý thanh toán, đạt 98% STP ngay hôm nay

Giảm chậm trễ đối soát và kiểm soát tốt hơn các quy trình làm việc trên Fiserv.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng. Thiết lập chỉ mất vài phút.

Mẫu dữ liệu xử lý thanh toán

Mẫu dữ liệu xử lý thanh toán

Thuộc tính xử lý thanh toán

Hoạt động xử lý thanh toán

Hướng dẫn trích xuất dữ liệu

Script Python dùng API Fiserv Commerce Hub

Các bước

1. Cấu hình điều kiện cần

2. Thiết lập môi trường

3. Cấu hình tập lệnh

4. Triển khai logic xác thực

5. Tìm hiểu logic phân tích dữ liệu

6. Xử lý phân trang

7. Chạy tập lệnh

8. Kiểm tra đầu ra

9. Xử lý sau khi trích xuất (không bắt buộc)

10. Tải lên ProcessMind

Cấu hình

Truy vấn mẫu python

Sẵn sàng bắt đầu?

Tối ưu hóa xử lý thanh toán, đạt 98% STP ngay hôm nay