dbt
DatabricksThe problem
Different payment providers describe transactions differently. Repeating those definitions for each project creates integration work; the goal was a shared foundation that new projects could reuse.
Architecture & flow
Logical flow starting from existing silver-layer data, not an ingestion or deployment diagram.
Provider inputs
Stripe, Adyen and Worldpay data in the silver layer.
Shared gold model
Standardize transactions and centralize subscription, refund and revenue logic with SQL, dbt and Databricks.
Quality expectations
Contracts and validation rules alongside the models.
Reuse & reporting
A common foundation for new projects and downstream reporting.
Decisions & trade-offs
- Shared definitions over project-by-project logic
- Centralizing business rules makes reuse the starting point. Provider differences belong in the modeling work, rather than being reinterpreted in every downstream project.
- Make reliability explicit
- Contracts and validation rules express quality expectations close to the models. The architecture story includes those expectations, not just a list of tools.
The result
The shared payments model contributed to approximately 50% less time to launch new projects, with a common foundation instead of repeated integration work.
Simplified view of documented work. No client data, internal table names or production topology are shown.