Party addresses must survive every payment hop

What the public implementation shows

SIPS Connect includes end-to-end address mapping tests for outgoing messages, incoming transaction recording, and later status responses. The PostgreSQL model also has a migration dedicated to debtor and creditor address fields.

Address data crosses participant JSON, canonical DTOs, ISO party models, transaction persistence, and status reconstruction rather than living in one serializer. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA field is supported only when it survives the complete transaction and recovery path.

The decision behind the mechanism

The tests assert the same debtor and creditor values at multiple boundaries, making data loss visible when any mapper or persistence projection changes.

A field can appear correctly in the initial request yet disappear from the durable record, leaving status responses, investigations, or compliance exports incomplete. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Name debtor and creditor fields explicitly at every mapping boundary.
• Add persistence migrations with the application mapping change.
• Test both incoming and outgoing transaction directions.
• Reconstruct status responses from durable values, not assumptions.

How the control should be operated

For every newly supported party attribute, define its canonical meaning and test create, receive, persist, reload, and response paths as one contract.

Operational and downstream consumers see consistent party evidence even after the original message is no longer in memory. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.