v0.16.0 dbt_stripe

Breaking Change - Potential Change in Values May Impact Downstream Queries

• The aggregated net, gross, sale, charge, refund, and fee amount-based fields in stripe__daily_overview and stripe__customer_overview now reflect the raw smallest units (e.g., cents), following Stripe's raw data, instead of converted dollar amounts. This change standardizes values across all models.
  • Customers using these models should note that the values will appear inflated compared to the previous dollar-based representation.
  • The cent-to-dollar conversion has been moved upstream and is now controlled by a new variable: stripe__convert_values which is disabled by default.
  • See the below Feature Update notes for more context behind these changes and for detailed setup instructions, see the README.

Feature Update: Optional Conversion to Major Units

Stripe passes amount-based fields, such as amount, net, and fee, in the smallest denomination as raw form. This means, if your currency has minor and major units such as USD, 100 represents 100 cents, the minor unit, or 1 USD, the major unit. Alternatively, if your currency doesn't use minor units such as JPY, 100 represents 100 JPY.

• This PR introduces a variable stripe__convert_values (disabled by default) upstream in the staging models which allows users the option to divide all amount-based fields by 100.
  • For information on how to enable the division, refer to the README on configuring the stripe__convert_values variable.
  • Otherwise, amount-based fields will be brought through in their raw form.
  • Examples of currencies using minor units (in which enabling stripe__convert_values is relevant) include United States Dollar (USD), Euro (EUR), and the Canadian Dollar (CAD).
  • Examples of currencies NOT using minor units (in which it makes more sense to keep the amount-based fields in raw form) include Japanese Yen (JPY), Indonesian Rupiah (IDR), and Korean Won (KRW).

Notes

• This update is not providing multiple currency support; however, we're interested in exploring this functionality if there's a need. As such, we have created a feature request to support multiple currencies where you are welcome to provide feedback or contribute to the discussion.

Under the Hood

• Updated the run_models.sh script to test for when stripe__convert_values is set to True.
• Added a consistency test for stripe__customer_overview.

Documentation

• Updated the descriptions for all amount-based fields to specify the grain of the values and add information about the stripe__convert_values variable.
• Added Quickstart model counts to README. (#103)
• Corrected references to connectors and connections in the README. (#103)

Full Changelog: v0.15.1...v0.16.0

v0.15.1 dbt_stripe

Bug Fixes

• Updated the logic in stripe__line_item_enhanced to properly bring in refund data by adjusting the joins on balance transactions, refunds and charges.
  • Since charges and refunds are both types of balance transactions, included an additional join between refunds and balance transactions to bring in refunds at the same level as charges.
    • Updated balance transactions join on connected_account_id and source_relation to look at both charge and refund balance transactions.
  • Fixed fee_amount logic to sum together charge and refund amounts.
    • Coalesced fee_amount with zero for invoice-only (non-header) rows and updated downstream summing logic accordingly.
  • Updated transaction_type logic to not only bring in charge, but also return charge + refund if the balance transaction has a charge and a refund associated with it, or payment intent + refund if the refund balance transaction is not yet tied to a charge.

Under the Hood

• Modified the consistency tests to better compare differences between production and development rows.

Full Changelog: v0.15.0...v0.15.1

v0.15.0 dbt_stripe

Breaking Changes

• Updated stripe__balance_transactions to correctly handle multiple disputes on the same transaction:
  • Adjusted customer_facing_amount to reflect the dispute_amount of the latest dispute (if the transaction is not a charge or refund and is associated with any disputes) (PR #92).
  • Added the following the dispute-related columns (PR #92):
    • latest_dispute_amount_won: Latest disputed amount that was won in favor of the merchant.
    • latest_dispute_amount_lost: Latest disputed amount that was lost and returned to the customer.
    • latest_dispute_amount_under_review: Latest disputed amount that is currently under review by the bank.
    • latest_dispute_amount_needs_response: Latest disputed amount that currently needs a response (the dispute has been filed but the merchant has not yet responded with evidence).
    • latest_dispute_amount_warning_closed: Latest disputed amount that is currently of status warning_under_closed (early fraud warning being closed due to no formal dispute).
    • latest_dispute_amount_warning_under_review: Latest disputed amount that is currently of status warning_under_review (card issuer suspects possible fraud but hasn't yet escalated the situation to a full dispute).
    • latest_dispute_amount_warning_needs_response: Latest disputed amount that is currently of status warning_needs_response (early fraud warning has been escalated into formal dispute and/or card issuer has requested more information).
    • dispute_count: Count of disputes raised against this transaction. If > 1, join in dispute data for additional information on each dispute.
  • Adjusted the dispute_id and dispute_reason fields to aggregate together data from multiple disputes if present. They have been renamed to dispute_ids and dispute_reasons in the following models (PR #88):
    • stripe__balance_transactions
    • stripe__activity_itemized_2
    • stripe__balance_change_from_activity_itemized_3
    • stripe__ending_balance_reconciliation_itemized_4

Under the Hood

• Updated dispute seed data to test the above changes (PR #92).
• Added additional validation tests on the affected models from above (PR #92).

Contributors

• @bramrodenburg (PR #88)
• @jsnorthrup

Full Changelog: v0.14.1...v0.15.0

v0.14.1 dbt_stripe

PR #89 includes the following updates:

Bug Fixes

• Addressed a potential Divide by 0 error in calculating unit_amount in the stripe__line_item_enhanced model. Now, if the denominator invoice_line_item.quantity is 0, unit_amount will also be 0.

Under the Hood

• Expanded the consistency_line_item_enhanced_count test to also validate potential changes to unit_amount sums.
• Adjusted the invoice_line_item seed data to include cases where quantity = 0 in order to test the above bug fix.

Full Changelog: v0.14.0...v0.14.1

v0.14.0 dbt_stripe

PR #82 includes the following updates:

Feature Updates

• Addition of the stripe__line_item_enhanced model. This model constructs a comprehensive, denormalized analytical table that enables reporting on key revenue, subscription, customer, and product metrics from your billing platform. It’s designed to align with the schema of the *__line_item_enhanced model found in Stripe, Recharge, Recurly, Shopify, and Zuora, offering standardized reporting across various billing platforms. To see the kinds of insights this model can generate, explore example visualizations in the Fivetran Billing Model Streamlit App. Visit the app for more details.
  • This model is currently disabled by default. You may enable it by setting the stripe__standardized_billing_model_enabled as true in your dbt_project.yml.

Relevant Upstream Updates (dbt_stripe_source v0.12.0)

• Addition of the following new staging models and accompanying upstream references:
  • stg_stripe__discount (required for downstream dbt_stripe model transformations)
  • stg_stripe__product (enabled by default, but can be disabled by setting the stripe__using_subscriptions variable to false)

Under the Hood

• Added consistency test within integration_tests for the stripe__line_item_enhanced model.
• Updated the quickstart.yml to include the product source table as a requirement for the stripe__using_subscriptions variable.

Full Changelog: v0.13.0...v0.14.0

v0.13.0 dbt_stripe

PR #78 includes the following updates:

🚨 Breaking Changes 🚨

• Renamed folder stripe_reports to stripe_financial_reports to be more descriptive of the contents.
  • ⚠️ If you are using folder names to scope out configs, runs, etc., you will need to update the folder name.

Bug fixes

• Updated model int_stripe__date_spine to accommodate cases when model stripe__balance_transactions has no records.
  • Previously, the date spine relied on stripe__balance_transactions to set date bounds, which caused errors if empty. Now, the model defaults to a one-month range in such cases.

Under the hood

• Updated structure of model int_stripe__date_spine for improved performance and maintainability.

Full Changelog: v0.12.0...v0.13.0

v0.12.0 dbt_stripe

PR #75 includes the following updates:

🚨 Breaking Changes 🚨

• No longer filters out deleted customers in stripe__customer_overview.
  • Persists is_deleted field to differentiate between deleted and active customers.
  • Note that this is a 🚨 breaking change 🚨, as previously filtered-out records will appear in stripe__customer_overview.

Feature Updates

• Adds the phone column to stripe__customer_overview.

Under the Hood

• Included auto-releaser GitHub Actions workflow to automate future releases.
• Updated the maintainer PR template to resemble the most up to date format.

Full Changelog: v0.11.0...v0.12.0

v0.11.0 dbt_stripe

PR #69 contains the following updates:

🚨 Breaking Changes 🚨

• Prefixed the following fields based on their corresponding upstream source to maintain clarity:

Previous Name	New Name
created_at	balance_transaction_created_at
available_on	balance_transaction_available_on
currency	balance_transaction_currency
amount	balance_transaction_amount
fee	balance_transaction_fee
net	balance_transaction_net
type	balance_transaction_type
source	balance_transaction_source_id
reporting_category	balance_transaction_reporting_category
description	balance_transaction_description

Updates

• Introduced the following new models, named after the Stripe reports that they follow. These models help reproduce reports available in the Stripe Reporting API. The reports introduced in this update include:

  • stripe__activity_itemized_2
  • stripe__balance_change_from_activity_itemized_3
  • stripe__ending_balance_reconciliation_itemized_4
  • stripe__payout_itemized_3

• Updated the stripe__balance_transactions with the following changes:

  • reporting_category has been updated to pull directly from the titular column. If no reporting_category exists, it then falls to sort based on balance transaction type in accordance to the Stripe documentation.
  • Added the following fields:
    • dispute fields
    • transfer fields
    • additional payout fields
    • additional customer fields
    • additional card fields
    • additional charge fields
    • additional invoice fields
  • Updated customer_facing_amount to include for refunds and disputes as well
  • Updated charge_id to charge, refund, then dispute objects consecutively

Under the Hood

• Incorporated the new fivetran_utils.drop_schemas_automation macro into the end of each Buildkite integration test job.
• Updated the pull request templates.

Full Changelog: v0.10.1...v0.11.0

v0.10.1 dbt_stripe

PR #61 contains the following changes:

Documentation Updates

• Updated the Metadata pivot documentation to be more clear that these variables only affect the dbt_stripe_source staging models.
• Added reference to the new stripe__card_metadata and stripe__invoice_line_item_metadata metadata variables that are available in the latest source package update.

Under the Hood

• Updated the card and invoice_line_item seed files to be consistent with the source package versions. Specifically to include the metadata fields.
• Added a new BuildKite run statement to test a few of the metadata variables.

Full Changelog: v0.10.0...v0.10.1

v0.10.0 dbt_stripe

PR #60 includes the following changes:

🚨 Breaking Changes 🚨:

• Unwrapped total_* fields from the for loop in stripe__daily_overview to reduce compute required for previous for-loops
• Add account_id in int_stripe__account_rolling_totals for use as part of the join in the case where more than 1 account_id exists.

Under the Hood

• Intermediate model materializations have changed from ephemeral to table to reduce the compute required for the complexity of calculations.