Stripe to Snowflake: How to Move Your Data
Move Stripe into Snowflake with Airbyte. Why the lookback window defaults to zero, which streams it affects, and how deleted records reach your tables.
Moving Stripe into Snowflake is how payment data stops being a separate conversation. Stripe knows what was charged, refunded and disputed, and nothing about what those customers cost to acquire, how much support they needed, or whether they used the product they paid for.
This guide covers the managed path with Airbyte. One setting defaults to zero and is the usual reason a reconciliation does not balance, and it only applies to some of your streams, which is the part people miss.
Stripe to Snowflake at a glance:
Why move data from Stripe to Snowflake?
Two situations account for most of these pipelines.
The first is revenue analysis your finance team will stand behind. Cohort retention, lifetime value and refund patterns are definitions people argue about, and settling them once in a warehouse beats three teams each computing them from a different Stripe export.
The second is joining payments to everything else. Whether customers acquired through a particular channel are worth more, and whether heavy support users churn, are questions spanning systems Stripe has never seen. If you only need standard payment reports, Stripe's dashboard produces them already.
What do you need before you start?
Short list, and the lookback decision is the one that decides whether your numbers reconcile:
A restricted API key with read access. Created in your Stripe dashboard. Use a restricted key rather than a secret key, granting read permissions only on the resources you intend to sync. The Stripe source documentation covers the setup.
A lookback window that is not zero. It defaults to zero, which means cursor-based streams never revisit a period once read. Setting it to a few days costs almost nothing against a deduplicating destination and covers the cases below.
A deliberate start date. Finance questions reach further back than product ones, and a long history is a large first sync, so adjust the data request window if the initial backfill struggles.
Snowflake objects and a governance decision. A warehouse, database, schema and a role able to create tables. Use a schema dedicated to financial sources, because payment records deserve deliberate grants rather than landing beside general analytics.
If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the Snowflake side before you begin.
How do you build a Stripe to Snowflake pipeline in Airbyte?
Step 1: Agree what finance needs to reconcile
Ask which Stripe figures somebody will compare your warehouse against, because that tells you which streams matter and how far back to go. Charges, invoices, payouts and balance transactions cover most reconciliation work, and the rest can wait until somebody asks.
Step 2: Configure the Stripe source
Click Sources in the left navigation, then New Source, and select Stripe, following adding a source. Enter the account identifier, your restricted key and a start date, then set the lookback window rather than leaving it at zero.
Step 3: Configure the Snowflake destination
Click Destinations, then New Destination, and select Snowflake, following adding a destination. Supply the account identifier, warehouse, database, schema and role. Point it at the financial schema from your prerequisites rather than wherever your other sources land.
Step 4: Use a deduplicating sync mode
Click Connections, then New connection, select your streams and choose incremental append and deduped as the sync mode. That is what makes a lookback window free, since re-reading an overlapping period leaves no duplicate rows behind.
Then reconcile a closed month against Stripe's own reporting before anyone builds on it, because a discrepancy found now is a configuration question while one found later is a credibility problem.
Why does the lookback window only help some streams?
Because the connector reads your data two different ways. Event-based streams discover changes from Stripe's own event feed, so they learn about an update whenever it happens. Cursor-based streams filter on a timestamp and move forward, which means they can only find what the timestamp exposes.
The lookback window applies to the second group only, and that is the group where a record can change without its cursor advancing. A dispute resolved weeks after the charge, or a backdated adjustment, is exactly the kind of thing a zero lookback never revisits.
So set it to a few days at minimum and longer if your business has slow-settling records. Against a deduplicating destination the cost is a slightly longer sync and nothing else, and the benefit is that finance stops finding gaps you cannot explain.
What happens when something is deleted in Stripe?
It arrives carrying a deletion flag rather than disappearing from your tables. That is the right behaviour for financial data, because a record that vanished without trace would be impossible to audit and awkward to explain to anybody asking what changed.
It does mean your queries have to account for it. A revenue total that does not filter on that flag includes records Stripe no longer considers current, and the difference will not be large enough to look obviously wrong, which is the worst size for an error to be.
Handle it once in a view rather than in every query. The same view is the natural place to hide Airbyte's metadata columns and define your revenue measures, which gives analysts a stable interface and keeps the deletion logic in one place somebody can check.
Frequently asked questions
Why do my Stripe totals not match the dashboard?
Check the lookback window, which defaults to zero, and whether your query filters out deleted records. Those two account for most reconciliation gaps.
Does the lookback window apply to every stream?
No. It applies to cursor-based streams only. Event-based streams learn about changes from Stripe's event feed and do not need it.
Are deleted records removed from my tables?
No. They arrive with a deletion flag, which suits financial auditing. Filter on that flag in a view so every consumer gets the same answer.
My initial backfill is struggling. What should I change?
Adjust the data request window, which controls how much history each request covers. A smaller window means more requests that each complete comfortably.
Can I do this without writing code?
Yes. The setup above is entirely UI-driven. You will want Snowflake views filtering deleted records and defining your revenue measures.
Get your Stripe data into Snowflake
Set the lookback window rather than leaving it at zero, because cursor-based streams otherwise never revisit a settled period. Use a deduplicating sync mode so that costs nothing, filter deleted records in a view, keep payment data in its own schema, and reconcile a closed month before anyone reports on it.
Airbyte's connector catalog includes 700+ pre-built connectors, so payment data can sit beside the product and marketing sources that explain it. For the same source in another warehouse, see Stripe to BigQuery, and for subscription billing alongside it, Chargebee to Snowflake.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.