Stripe to Snowflake integration for analytics-ready payments data

The Stripe to Snowflake integration from Adapters loads charges, refunds, payouts, fees, and subscription events from Stripe into Snowflake 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 Snowflake by hand costs you

The Stripe API returns 100 objects per page and rate-limits, so backfilling years of charges by hand is slow and brittle.
Balance transactions hold the real fee and payout detail, and stitching them to charges in a script is easy to get wrong.
Analysts end up exporting Stripe CSVs to build MRR and churn models, which go stale the day after they run.

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 / SNOWFLAKE

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 Snowflake NUMBER dollars, Unix timestamps become TIMESTAMP_NTZ in UTC, and balance-transaction fees join to their charge so revenue, fee, and net-payout models read one deduplicated table.

Stripe to Snowflake: minor units, the three-hour refresh, and the reconciliation that only works on gross

Stripe data in Snowflake goes wrong in a specific and expensive way: revenue that is off by a factor of one hundred, or a payout that never matches the deposit. Both come from the same two facts about how Stripe represents money and how its data lands. Below: the unit problem, the refresh cadence of Stripe own pipeline, the reconciliation model that actually balances, and the Snowflake types worth setting by hand. Stripe and Snowflake documentation read 19 August 2026.

Stripe amounts are integers in the smallest currency unit

A $42.50 charge is 4250 in the Stripe API, not 42.50. Load that straight into a warehouse column and every revenue figure is one hundred times too large, which is obvious on a dashboard and much less obvious in a model that someone divides by another Stripe amount. Convert on the way in, and be careful with the exceptions: zero-decimal currencies such as JPY and KRW are not multiplied by 100, so a hardcoded divide-by-100 breaks the moment the business takes its first yen payment. Store the currency code alongside every amount and do the conversion per currency rather than globally.

Snowflake NUMBER defaults to scale zero, which quietly drops the cents

Snowflake NUMBER defaults to precision 38, scale 0, and maximum precision is 38. If a loader creates the column on the default and you have already divided Stripe minor units into dollars, the cents are truncated with no error raised. Define NUMBER(18,2) for money explicitly. The safer pattern is to keep the raw integer minor-unit column exactly as Stripe sent it, add the currency, and compute the decimal amount in a view. That way the source of truth in the warehouse is byte-identical to the source of truth in Stripe, and any conversion bug is fixable without a reload.

Reconciliation balances on gross plus fee, never on net

The most common finance complaint about Stripe data is that the Snowflake number does not match the bank deposit. It will not, if you model net. A payout is the sum of gross charges, minus refunds, minus per-transaction fees, minus disputes and their fees, plus or minus adjustments, over a specific balance-transaction window. Model the balance transactions rather than the charges: every one of those components appears there with the payout it settled into. Charges alone cannot reconcile to a bank statement, and no amount of pipeline quality fixes that, because it is a data-model choice rather than a transfer problem.

If you use Stripe Data Pipeline, know its cadence before you promise freshness

Stripe first-party Data Pipeline delivers into Snowflake and Redshift through secure data sharing rather than a copy you operate. The share becomes accessible within 12 hours of setup, and then loads run as a full refresh every 3 hours. That is a genuinely good arrangement for finance reporting and a poor one if somebody expects a dashboard to reflect a charge from four minutes ago. Decide which of those the business actually needs before choosing between the native share and an API-based sync, because they answer different questions and cost differently.

Late-arriving events are normal, so build for restatement

Refunds, disputes and chargebacks attach to charges that may be weeks old. A pipeline that only appends new rows since the last watermark will carry a permanently optimistic revenue figure, because the events that reduce revenue arrive after the row was written. Two workable patterns: re-extract a trailing window on every run, typically 30 to 90 days depending on your dispute profile, or model from balance transactions where the reducing event is its own row with its own timestamp. Either works. Appending charges only does not, and the error compounds monthly.

How Adapters handles this lane, and where it does not fit

Adapters syncs Stripe objects into Snowflake on a schedule with explicit minor-unit conversion per currency, a trailing re-extract window so refunds and disputes restate correctly, defined numeric types rather than warehouse defaults, and per-record error logs, at a flat $49 to $399 a month. That fits finance and analytics teams who want Stripe modeled correctly next to product data. It is not the pick if Stripe first-party Data Pipeline already covers you at an acceptable three-hour cadence, if you need event-level streaming latency, or if the wider project needs a large connector catalog.

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 Snowflake 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 Snowflake covers the field-by-field detail, the failure cases, and what changes at volume.

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

Stripe to Snowflake sync: common questions

How do I get Stripe data into Snowflake?

There are two routes. Stripe Data Pipeline uses Snowflake Secure Data Sharing to deliver your Stripe data with no copy, available within 12 hours of setup and then refreshed on a regular full load. A connector instead loads charges, refunds, payouts and customers into tables you define and control, which is the route to take when you want your own schema and field mapping.

What is Stripe Data Pipeline?

It is Stripe's first-party warehouse feed, supporting Snowflake and Amazon Redshift. You enter your Snowflake account identifier in the Stripe Dashboard, accept the share, and Stripe delivers core data and reports as a data share rather than a pipeline you operate. It is the least effort option, and the trade-off is that you take Stripe's schema and refresh cadence.

Which Stripe objects should you load into Snowflake?

Charges, refunds, disputes, payouts and balance transactions cover almost every finance question. Balance transactions are the ones people skip and then regret, because they are what tie gross charges to the net amount that actually reached the bank. Add customers and subscriptions when you need revenue cohorts.

How do you handle Stripe amounts in Snowflake?

Stripe reports amounts in the minor unit of the currency, so 12900 means $129.00. Divide by 100 at load time for two-decimal currencies and store the result as NUMBER with an explicit scale, never a float. Keep the currency code on the same row, because zero-decimal currencies such as JPY do not take the divide.

How does the Stripe to Snowflake sync work?

Is there a prebuilt Stripe connector for Snowflake?

Yes. This Stripe to Snowflake 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 Snowflake 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 Snowflake?

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 Snowflake?

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 Snowflake NUMBER dollars, Unix timestamps become TIMESTAMP_NTZ in UTC, 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 Snowflake, 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.