Stripe to BigQuery: How to Move Your Data

Moving Stripe into BigQuery is how revenue stops being three numbers that disagree. Stripe knows what was charged, refunded and disputed. Your product knows who used what, and your CRM knows what was promised, and the questions finance actually asks need all three in one place.

This guide covers the managed path with Airbyte. The thing to understand before configuring anything is that this connector has two classes of stream that find changes in completely different ways, and one important setting only applies to one of them.

Stripe to BigQuery at a glance:

Why move data from Stripe to BigQuery?

Two situations account for most of these pipelines.

The first is revenue analysis that Stripe's dashboard cannot do. Cohort retention, revenue by plan and segment, churn by acquisition channel: all of these need Stripe data joined to something Stripe has never seen, and a warehouse is the only place that happens.

The second is one agreed set of numbers. Finance, sales and the product team each have a way of counting revenue, and a shared Stripe dataset with definitions written once in SQL is how those stop diverging. If you only need the standard reports, Stripe already produces them.

What do you need before you start?

Short list, and one item is a decision your finance team should make rather than you:

A restricted Stripe API key and your account identifier. Stripe lets you create keys with read-only access to specific resources, which is exactly what a replication pipeline should have. The Stripe source documentation covers the configuration fields.

A deliberate start date. Data on and after this date is replicated. Finance questions reach further back than product ones, so ask before choosing, and remember that a long backfill on a busy account is a substantial first sync.

A lookback window agreed with finance. It defaults to zero, meaning nothing is re-exported after it has been synced. Since payments are adjusted after the fact, zero is rarely the right answer, and the right answer depends on how long your adjustments typically take.

A BigQuery service account and dataset. With the BigQuery User and BigQuery Data Editor roles. Set the dataset location to match your product and CRM datasets, since joining them is the point and BigQuery only joins within a location.

If your organisation restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list on the BigQuery side before you begin.

How do you build a Stripe to BigQuery pipeline in Airbyte?

Step 1: Ask how long adjustments take

Ask your finance team how long after a payment things typically still change: refunds issued, disputes raised, adjustments applied. That period is your lookback window, and it is a business fact rather than a technical setting. Getting it from them takes five minutes and getting it wrong produces figures that disagree with Stripe.

Step 2: Configure the Stripe source

Click Sources in the left navigation, then New Source, and select Stripe, following adding a source. Supply the account identifier, the API key, a start date and your lookback window. There is also a data request window controlling the slice size used when asking Stripe for data, which is the setting to reduce if a large backfill struggles.

Step 3: Configure the BigQuery destination

Click Destinations, then New Destination, and select BigQuery, following adding a destination. Supply the project, dataset and service account key. Batched standard inserts is the default and is adequate for most accounts, since payment records are modest by warehouse standards.

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. A lookback window deliberately re-reads recent records, so deduplication is what stops that overlap becoming duplicate rows. Daily suits financial data, which settles over days rather than seconds.

Then reconcile a closed month against Stripe's own reporting before anyone builds on it. This is finance data that somebody will be held to, and a discrepancy found now is a configuration question while one found later is a credibility problem.

Why does the lookback window not apply to every stream?

Because the connector has two ways of finding changes. Some streams use event-based incremental syncs, discovering what changed from Stripe's own record of events, which catches updates without needing to re-read anything. Others do not, and rely on a cursor instead.

The lookback window applies only to the second group. That is stated plainly in the documentation and is easy to miss, and it means setting the window to seven does not cause a seven day re-read across the board. On the event-based streams it does nothing, because those streams already learn about changes another way.

The practical consequence is diagnostic. If a figure on one stream corrects itself over the following days and the equivalent figure on another does not, that difference is by design rather than a fault, and the fix is knowing which class the stream belongs to before assuming something is broken.

What happens when something is deleted in Stripe?

For a limited number of streams, deletions are propagated, and the mechanism is worth knowing because it does not look like a deletion. Rather than the row disappearing, each record is marked with a deleted flag when the corresponding event happens upstream.

That is the right behaviour for financial data, where you generally want a record that something existed and was removed rather than silent disappearance. It does mean every query needs to account for the flag, because a naive count includes deleted records and will not match Stripe.

So build views that filter on it and point your analysts at those rather than the raw tables. Note also that this applies to a limited set of streams, so on the others a removal in Stripe simply will not reach your warehouse. Establish which of the streams you rely on fall into that group.

Frequently asked questions

What should I set the lookback window to?

However long your payments typically take to settle, including refunds and disputes. It defaults to zero, which re-exports nothing, and that is rarely right for financial data.

Why does the lookback window seem to have no effect on some streams?

It applies only to streams that do not support event-based incremental syncs. Streams that do already discover changes through Stripe's events, so the window does not affect them.

Are deleted records removed from BigQuery?

No. On the streams that support it, records are marked with a deleted flag when the event occurs upstream. Filter on that flag in your views, or your counts will not match Stripe.

My backfill is struggling. What should I change?

Reduce the data request window so each request covers a shorter period, and consider a later start date if you do not genuinely need years of history.

Can I do this without writing code?

Yes. The setup above is entirely UI-driven. You will want BigQuery views filtering deleted records and defining your revenue measures, which is where those definitions belong.

Get your Stripe data into BigQuery

Agree the lookback window with finance rather than leaving it at zero, use a deduplicating sync mode so the deliberate overlap collapses, filter the deleted flag in your views, and reconcile a closed month before anyone reports on it. Then remember which streams are event-based, because that explains most surprises.

Airbyte's connector catalog includes 600+ pre-built connectors, so payment data can sit beside the product and CRM sources that explain it. For the accounting side of the same picture, see Xero to BigQuery, and for treasury balances, Kyriba to Snowflake.

Start syncing now →