What it keeps

Processor confirmation. Authored event evt-9001 confirms pay-1001; evt-9002 confirms refund-1001. Event identity supports deduplication, but arrival order alone never establishes truth. Sources: src-processor-confirmation and src-refund-confirmation. Attributes: event_id, payment_id, refund_id, outcome. kept by Payment service

Order reference. Authored order ord-1042 requests EUR 10000 for Mira’s lamp. This is the minimal payment-facing reference, not a complete merchant order system. Source: src-purchase-requirement. Attributes: id, amount_minor, currency. kept by Payment service

Payment. Authored logical payment pay-1001 references ord-1042 for EUR 10000, using pay-op-1001. Its initial timeout leaves the outcome unknown. src-processor-confirmation later records evt-9001 and processor-pay-7001. Attributes: id, order_id, amount_minor, currency, operation_key, state, processor_reference. kept by Payment service

Refund. Authored refund-1001 references pay-1001 for EUR 10000 with separate key refund-op-1001. The requested state precedes prepared confirmation evt-9002; bank posting remains unknown to this sample. Attributes: id, payment_id, amount_minor, currency, operation_key, state. kept by Payment service

Payment state · illustrative PostgreSQL design: a PostgreSQL design of Payment records. Proposed physical design for the authored logical entities. Payment and refund records link to their order and original operation; processed confirmation identity is explicit. No database or payment backend is provisioned.

orders. Columns: id, amount_minor, currency. Payment state · illustrative PostgreSQL design

payments. Columns: id, order_id, amount_minor, currency, operation_key, state, processor_reference. Payment state · illustrative PostgreSQL design

confirmations. Columns: event_id, payment_id, refund_id, outcome. Payment state · illustrative PostgreSQL design

refunds. Columns: id, payment_id, amount_minor, currency, operation_key, state. Payment state · illustrative PostgreSQL design