Use case summary
Data Pipelines deliver payment data automatically into your own database, structured across four schemes covering requests, attempts, provider transactions, and refunds. For one-off questions, any table exports as a CSV with your filters and chosen columns. Result: payment data reaches the same stack as the rest of your business data.
- Developers & CTO
- Finance & CFO
Why payment data ends up stranded
Every other part of the business reports from one place. Revenue, marketing spend, product usage, and support volumes all land in the warehouse, and questions that cross them get answered in an afternoon.
Payment data usually sits outside it. It lives in a platform's dashboard, or in several providers' portals, and reaches the warehouse as a monthly CSV that someone exports by hand. By the time it arrives, it has been filtered by whoever exported it.
So the questions that need payments joined to everything else stay unanswered. Cost of payments per customer segment, approval rates by acquisition channel, refund behavior by product line: each one is straightforward in a warehouse and impossible in a payment dashboard.
How payment data reaches your stack
Which one fits depends on whether you need a continuous feed or an answer today.
- 1
Stream it into your own database
A Data Pipeline delivers payment data automatically into your database, so it lands in your infrastructure without anyone exporting anything. This is the option built for teams with their own BI or analytics function.
- 2
Work with four documented schemes
The pipeline delivers along defined structures: Payment Request covers the payment itself with amounts, currency, status and identifiers; Payment Commit records each processing attempt with the provider's response code, timing and errors; Payment Transaction holds the detail of interactions with the provider across authorization, charge, and refund; and Refund covers returns with their amount, reason, and status.
- 3
Expect denormalized data, deliberately
The Payment Request scheme is denormalized so key payment parameters can be read without additional queries to other tables. For a BI team, this matters: the fast path is already flattened, and the joins you do write are the ones your own model needs.
- 4
Export any table when you need an answer now
Exports generate a CSV from whichever table you are looking at. The export inherits the filters and date range already applied to the grid, so what you download matches what you were looking at.
- 5
Choose the columns that go in the file
Take the columns currently on screen, every column the system holds for that entity, or a custom selection. 10 entities are supported, including payment requests, commits and transactions, their payout equivalents, merchant accounts, customers, routes and provider accounts.
- 6
Keep the export history
Past exports are listed under account settings, where you can download, preview, or delete each one, so a file shared with finance last month can be retrieved rather than regenerated.
What you get
Payment data sits in the same place as the rest of your business data, in a structure your team controls.
Questions that cross payments and everything else
With payment data in the warehouse, the cost of payments by customer segment or approval rates by acquisition channel becomes an ordinary query instead of a project that needs two teams and a spreadsheet.
Reports built to your own model
Your BI team builds against documented schemes and shapes the output to how your business measures itself, rather than adapting to the reports a platform decided to ship.
Answers today without a pipeline project
When the question is one-off, a filtered CSV with the columns you pick takes a minute, which keeps small questions from waiting on the data team's backlog.
Even with AI embedded in the workflow, most analyst time still goes on organizing data
dbt Labs' 2026 State of Analytics Engineering report found AI-assisted coding embedded in daily workflows, with 72% prioritizing it, and yet a majority of respondents still spend most of their time maintaining or organizing datasets. Poor data quality remains the most frequently reported obstacle. Payment data adds to both when it arrives as a manual export rather than a modeled table, because the shaping is redone by hand for every analysis.