Skip to content

Payments — Payment events history

binding spec data-contracts/payments-events.odcs.yaml @ 1.2.0 — the spec of record. It states what must be; implementations converge on it, never the reverse.

Enforced by
  • check:version — any change must bump the artifact and service versions; a silent edit fails CI
  • datacontract-cli validation
  • Spectral house rules for attribute and value naming
Version history
VersionFirst releasedService version
1.2.02026-08-242.1.0
1.1.02026-08-232.0.0
1.0.02026-08-231.1.0
Consume it

Status: active · Domain: Commerce ·Data product: payments

Purpose

Append-only historical record of payment settlement events. One row per event, mirroring the AsyncAPI payload on payments.settled.v2 field for field - the stream is ephemeral, this table is the record.

Usage

Settlement analytics, audit, and replay/backfill for downstream consumers that joined after the fact. The daily reconciliation product (payments-daily) is derived from this record.

Limitations

Delivery upstream is at-least-once; rows are deduplicated on the CloudEvents envelope id, so exactly one row per settlement (settlement is terminal). Not a source for real-time balances - use the payments service API for that.

Schema

erDiagram
    payment_settled_events {
        string event_id PK
        string event_type
        string event_source
        date event_time
        string payment_id UK
        string order_id
        date settled_at
        integer amount_pence
    }

payment_settled_events — One row per PaymentSettled event on payments.settled.v2.

FieldTypeRequiredKeyConstraints
event_idstring (uuid)yesprimary key, unique
event_typestring (text)yes
event_sourcestring (text)yes
event_timedate (timestamp)yes
payment_idstring (uuid)yesunique
order_idstring (uuid)yes
settled_atdate (timestamp)yespartition
amount_penceinteger (bigint)yes≥ 0

SLA

  • latency: 15m

Ownership & support

  • team-payments (owner)
  • slack: #payments-support