stg_postgres__payments

staging view 1 PII columns

Payment lifecycle rows, with a derived day column.

Definition

Per-order payment events — multiple rows per order are the norm (auth followed by capture; capture followed by refund). Revenue eligibility is `transaction_type='capture' AND status='succeeded'`; marts that sum `amount` blindly will double-count auth+capture. `processed_day` is the partition-friendly date for daily rollups.

12 of 12

Column

Description

Tests · PII

payment_id

Primary key — UInt64.

2 tests

order_id

FK to `stg_postgres__orders.order_id`. NOT NULL.

customer +2 PII2 tests

payment_method_id

FK to `stg_postgres__payment_methods.payment_method_id`. Nullable — vendor failures may arrive without a method.

transaction_type

`auth`, `capture`, `refund`, or `void`.

1 test

status

`succeeded`, `failed`, or `pending`.

1 test

amount

Transaction amount in `currency`. Decimal(12,2). NOT a customer-level sum — see definition.

2 tests

currency

ISO-4217 currency code.

failure_reason

Vendor diagnostic on failed transactions. Nullable. May embed behavioural detail — flagged PII.

PII

processed_at

When the vendor processed the transaction. DateTime64(6).

processed_day

Calendar date — `toDate(processed_at)`. Partition key for daily marts.

source_created_at

Row insert timestamp from the source DB. DateTime64(6).

airbyte_extracted_at

When Airbyte extracted this row from postgres-source.