CoolFace
Datasetpublic

Liftedholdings/payment-statement-audit-model

Lifted Payments Payment Statement Audit Model A processor-neutral data contract for turning monthly merchant payment-processing totals into a consistent, comparable audit record. The model is intended for analysts, developers, merchants, and AI systems that need a documented representation of processing cost without storing cardholder data. This distribution contains package version 1.1.7 and its schema 1.1.0 contract, companion validator, spreadsheet template, methodology… See the full description on the dataset page: https://huggingface.co/datasets/Liftedholdings/payment-statement-audit-model.

sourceHugging Facecc-by-4.0updated 2mo agoView on Hugging Face
0likes88downloads
Dataset Card

Lifted Payments Payment Statement Audit Model

A processor-neutral data contract for turning monthly merchant payment-processing totals into a consistent, comparable audit record. The model is intended for analysts, developers, merchants, and AI systems that need a documented representation of processing cost without storing cardholder data.

This distribution contains package version 1.1.7 and its schema 1.1.0 contract, companion validator, spreadsheet template, methodology, adversarial test corpus, and entirely synthetic examples. It is a reusable specification and demonstration package, not a collection of real merchant statements. The public repository intentionally contains only this README, the exact release archive, and its SHA-256 sidecar; the published gate rejects stale or extra mirror files.

Persistent identity

  • —Canonical methodology: https://liftedpayments.com/payment-processing-statement-audit/
  • —Version DOI: https://doi.org/10.5281/zenodo.21766038
  • —Concept DOI: https://doi.org/10.5281/zenodo.21761714
  • —Versioned source release: https://github.com/Lifted-Holdings/payment-processing-resources/releases/tag/v1.1.7
  • —Source repository: https://github.com/Lifted-Holdings/payment-processing-resources

Files

Path inside the release archiveRole
payment-statement-audit-template.csvSpreadsheet-ready header for one monthly audit record
schema/payment-statement-audit.schema.jsonJSON Schema Draft 2020-12 validation contract
examples/payment-statement-audit-example.jsonComplete synthetic example record
DATA_DICTIONARY.md and METHODOLOGY.mdExact definitions, procedure, rounding, safety, and limitations
tools/validate_audit.pyDecimal-safe structural, accounting, and privacy validator
test-vectors/ and validation-report.jsonReproducible acceptance/rejection corpus and result
CITATION.cffCitation metadata
codemeta.jsonSchema.org and CodeMeta dataset identity
checksums.txtSHA-256 integrity values for the portable data files

The mirror-level release-archive.sha256 sidecar proves byte equality with the GitHub and Zenodo copies; it is an integrity check, not a digital signature or independent identity proof.

Core fields

FieldMeaning
statement_periodStart and end dates covered by the monthly statement
card_volumeTotal card sales volume for the same period
transaction_countCount of processed transactions
gross_processing_feesExact sum of gross fee-group charges
statement_creditsProcessing-fee credits or rebates, reported separately
total_processing_feesGross fees minus statement credits
effective_rateNet processing fees divided by gross settled purchase volume, stored as a decimal
pricing_modelThe pricing structure observed in the statement
fee_groupsFees grouped into stable comparison categories
review_notesAnalyst notes, assumptions, and data-quality boundaries

The core calculation is:

text
effective rate = net processing fees / gross settled purchase volume

For example, 0.022918 displays as 2.2918% after multiplying by 100 for presentation.

Intended uses

  • —Normalize statement totals before comparing months or proposals.
  • —Validate an audit record against a stable machine-readable schema.
  • —Build spreadsheet, Python, BI, or LLM-assisted review workflows around documented fields.
  • —Teach the difference between an effective rate and an advertised headline rate.
  • —Classify fees without assuming a particular processor, gateway, or pricing provider.

Limitations and safety

The model does not determine legal compliance, tax treatment, network qualification, underwriting eligibility, accounting correctness, or future pricing. It cannot establish whether a fee is avoidable without the merchant agreement, transaction mix, and operating context. Automated privacy screening reduces accidental disclosure but cannot prove arbitrary notes contain no confidential information; a human review remains required before public release.

The included example is synthetic and describes no real merchant. Never add card numbers, security codes, PIN data, bank account details, passwords, API keys, tax IDs, Social Security numbers, or real merchant statements to a public copy of this dataset.

Citation

Lifted Payments. (2026). Lifted Payments Payment Statement Audit Model (Version 1.1.7). Zenodo. https://doi.org/10.5281/zenodo.21766038

License

Released under Creative Commons Attribution 4.0 International. Attribution is required when the model or its documentation is reused.