Connect Stripe to Snowflake

Stripe holds the payments. Snowflake is where revenue, retention, and cohort analysis happen. Exporting CSVs from the Stripe dashboard gives you a snapshot with no history of state changes, amounts in cents, and no link between a payout and the transactions that made it up.

• Objects load from the event stream, so you keep every state change (a subscription that went past due then recovered), not just the current row
• A historical backfill walks the API once at setup so the warehouse has data from before the integration existed
• Amounts are normalized to major units and currency-tagged, so an analyst never divides by 100 or trips over a zero-decimal currency
• Each payout is joined to its balance transactions, so "what was in the deposit" is a query, not a support ticket

The revenue-warehouse flow, backfill then stream.

Stripe objects loaded into Snowflake from events, with a backfill and a reconcile

One-time backfill, then continuous event load, plus a daily reconciliation pass.

1. 1Backfill: at setup, page the Stripe API for charges, invoices, subscriptions, customers, and payouts over the chosen history window and load each to its Snowflake table.
2. 2Trigger: Stripe Event received for the configured types (charge.*, invoice.*, customer.subscription.*, payout.*), carrying the full object.
3. 3Normalize: divide amount fields by the currency's minor-unit factor, keep the raw value too, and add the ISO currency code as its own column.
4. 4Upsert: merge each object into its table keyed on the Stripe ID, keeping a row per version with _valid_from so state history is preserved.
5. 5Payout join: on payout.paid, list the balance transactions and load them to stripe_balance_transactions with the payout ID, so deposits reconcile in SQL.
6. 6Reconcile: a daily flow compares Snowflake row counts and sums against the Stripe reporting API for the prior day and alerts on any drift.

The starting map for a Stripe charge to the Snowflake table.

• Transactions. Charges, refunds, disputes, and balance transactions, loaded from events with amounts normalized. (Stripe to Snowflake)
• Billing. Invoices, subscriptions, subscription items, and price changes, with a row per state so churn and expansion are queryable. (Stripe to Snowflake)
• Payouts. Each payout and the balance transactions inside it, so deposits reconcile to the bank in SQL. (Stripe to Snowflake)
• Backfill and reconcile. A one-time history load and a daily count-and-sum check against the Stripe reporting API. (Stripe to Snowflake)

The same controls apply to this sync as to every other Neblex workload.

• Ordered run log. Every batch records the event IDs, the objects touched, and the Snowflake load result. The daily reconcile is logged with the compared figures.
• Reconciliation check. A drift between the warehouse and the Stripe reporting API alerts rather than sitting undiscovered until a board meeting.
• Scoped access. Stripe uses a restricted API key with read on the object types in scope, no write. Snowflake uses a role with write on the finance database only.
• Environments. Backfill from Stripe test mode into a scratch schema, verify the reconcile, then switch to the live key and the production schema.