Stripe to BigQuery integration for analytics-ready payments data

The Stripe to BigQuery integration from Adapters loads charges, refunds, payouts, fees, and subscription events from Stripe into partitioned BigQuery tables on an incremental schedule, so revenue and finance models read a complete transaction history instead of paginating the Stripe API by hand. Field mapping is no-code.

Try it in the live demo

No credit card required.

Input

Output

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Last updated September 2026

What running Stripe to BigQuery by hand costs you

The Stripe API returns 100 objects per page and rate-limits, so backfilling years of charges into BigQuery by hand is slow and brittle.
Balance transactions hold the real fee and net-payout detail, and stitching them to charges in a scheduled query is easy to get wrong.
Analysts export Stripe CSVs to build MRR and churn models, which go stale the day after they run and never join cleanly to product data.

The field mapping, out of the box

These cables are pre-wired when you pick the pair. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.

Input / STRIPE

Output / BIGQUERY

charge.id

fct_charge.charge_id

charge.amount

fct_charge.amount

charge.created

fct_charge.created_at

balance_txn.fee

fct_charge.fee

payout.id

dim_payout.payout_id

charge.updated

fct_charge.loaded_at

Transforms included

Incremental loads pull only objects changed since the last run using Stripe event timestamps; minor-unit amounts (cents) cast to BigQuery NUMERIC dollars, Unix timestamps become TIMESTAMP in UTC, tables partition by created date, and balance-transaction fees join to their charge so revenue, fee, and net-payout models read one deduplicated table.

Stripe to BigQuery in depth

Stripe data breaks in BigQuery for two reasons that have nothing to do with the pipeline: amounts are integers in the smallest currency unit, and only balance transactions reconcile to the money that actually moved. Read from Stripe and Google Cloud documentation on 20 August 2026.

Amounts are integers in the smallest currency unit

A $42.50 charge arrives as 4250. The obvious fix, dividing everything by 100 on the way in, is wrong: zero-decimal currencies such as JPY and KRW already express the full amount, so a ¥4250 charge becomes ¥42.50 and your Japanese revenue drops by two orders of magnitude with no error anywhere. Store the raw integer alongside the currency code, keep a currency exponent lookup, and apply the conversion in a view. Never hardcode a divide by 100 in the loader.

Only balance transactions reconcile

Charges tell you what a customer was billed. They do not tell you what landed in the bank, because fees, refunds, disputes, adjustments and payout timing all sit between the two. The balance_transactions object carries gross, fee and net for every movement, and it is the only Stripe object that sums to the payout. Any revenue model built on charges alone will disagree with the bank statement forever, and the gap will look like a pipeline bug when it is a modeling one.

Stripe Data Pipeline goes to Snowflake and Redshift, not BigQuery

Worth checking before you evaluate it as an option: Stripe Data Pipeline delivers to Snowflake and Redshift via secure data sharing. The share becomes accessible within 12 hours and then refreshes with a full load every 3 hours. BigQuery is not one of its destinations, so a BigQuery pipeline reads the Stripe API or its event stream instead. That also means you own the incremental logic rather than inheriting it.

Load job quotas shape the schedule

BigQuery allows 1,500 load jobs per table per day and 100,000 per project per day. Writing a load job per webhook event exhausts that quickly on a busy account, and the failure is a quota error rather than a queue. Buffer events and micro-batch on a fixed interval, or use the Storage Write API where latency genuinely matters. A single load job carries up to 15 TB and may run up to 6 hours, and batch loads are free on a shared slot pool, so larger and less frequent is both cheaper and safer.

Events arrive out of order and more than once

Stripe webhooks are at-least-once and are not ordered, so the same event can arrive twice and a charge.refunded can land before the charge.succeeded it refers to. Land the raw events append-only with the Stripe event ID and the ingestion timestamp, then build current state as a view that takes the latest event per object. Deduplicating on the event ID makes replays harmless, which matters because replaying a window is the normal way to recover from an outage.

Model the object graph before you model revenue

Customer, subscription, invoice, invoice line, charge, balance transaction and payout are separate objects, and revenue questions cross all of them. Subscription changes mid-cycle produce proration line items that are not a new subscription and should not be counted as one. Land each object in its own partitioned table, join in the modeling layer, and keep the raw shape intact so a definition can change without a re-ingest.

Partition, and mind the row and file ceilings

Partition charges and invoices by created date and cluster by customer ID. On the ingestion side, CSV and newline-delimited JSON have a maximum row size of 100 MB and compressed files are capped at 4 GB. Stripe metadata is user-supplied and occasionally enormous, so a single record with a metadata blob can fail a load that has run cleanly for months. Cap or split metadata at write time rather than discovering the limit during a month-end backfill.

Timestamps are epoch seconds in UTC

Stripe returns Unix timestamps in seconds, not milliseconds, which is the opposite of several other APIs feeding the same warehouse. Cast to BigQuery TIMESTAMP, which is timezone-aware, rather than DATETIME, which is not. Apply the local date conversion only where a business day is actually defined, because a payout that appears to land on the wrong side of a month boundary is a finance conversation rather than a data one.

How it goes live

Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.

STEP 01

Pick the pair

Connect Stripe and BigQuery with scoped credentials. About a minute each.

STEP 02

Confirm the mapping

The cables above are pre-wired. Adjust any field, preview the transform on sample records, done.

STEP 03

Schedule the sync

Hourly down to every minute, with retries, alerting, and a full log on every run.

Prefer to understand the moving parts first? Our long-form guide to replicating Stripe data to BigQuery covers the field-by-field detail, the failure cases, and what changes at volume.

Try it in the live demo Preloads STRIPE → BIGQUERY with sample records

Stripe to BigQuery sync: common questions

How do I load Stripe data into BigQuery?

Authenticate Stripe with a restricted read-only API key, select the objects you need (charges, refunds, payouts, balance transactions), map fields to BigQuery columns, and schedule an incremental load keyed on the created or updated timestamp. A MERGE on the Stripe object ID keeps replays from duplicating rows.

What are Stripe's API rate limits?

Stripe applies per-second request limits per account and returns HTTP 429 when you exceed them, with tighter limits on write endpoints than reads. Any loader worth using backs off exponentially on a 429 and resumes rather than failing the run. Paginating with a cursor and loading incrementally keeps normal syncs far below the ceiling.

How do you avoid a large BigQuery bill on Stripe data?

Partition the tables on the transaction date and cluster on customer or product. BigQuery charges by bytes scanned, so an unpartitioned charges table means every dashboard refresh reads the entire payment history. Partitioning usually cuts the scan on a typical month-to-date query by well over ninety percent.

How do you keep refunds and disputes correct in BigQuery?

Load them as their own rows rather than mutating the original charge. A refund issued in April against a March charge belongs in April's activity and March's gross, and you can only report both if the events are separate rows joined by the charge ID. Netting them at load time destroys information you cannot rebuild.

How does the Stripe to BigQuery sync work?

Is there a prebuilt Stripe connector for BigQuery?

Yes. This Stripe to BigQuery connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and you can try it against sample records in the live demo. No code or engineering sprint required.

How much does the Stripe BigQuery integration cost?

Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.

How often can Adapters sync Stripe to BigQuery?

Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.

Do I need to write code to connect Stripe and BigQuery?

No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads pull only objects changed since the last run using Stripe event timestamps; minor-unit amounts (cents) cast to BigQuery NUMERIC dollars, Unix timestamps become TIMESTAMP in UTC, tables partition by created date, and balance-transaction fees join to their charge so revenue, fee, and net-payout models read one deduplicated table.

More pairs from the API connector library

Browse the full api connector library, or request a pair you do not see.

Stripe and BigQuery, finally in agreement

Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.

Try the live demo

No credit card required.