JSON adapters protect the canonical model

What the public implementation shows

The SIPS.Adapter package models endpoints, fields, mapping types, and JSON adapter options, with participant mapping files mounted independently from core orchestration.

Configurable translation ends at internal DTOs consumed by the same payment, verification, status, and return handlers. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleVariation belongs at the edge; financial meaning belongs in one canonical model.

The decision behind the mechanism

The adapter absorbs naming and shape differences while keeping financial workflow code participant-neutral.

Participant-specific branches inside core handlers multiply testing paths and make a mapping change capable of altering unrelated transaction behavior. 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.

• Define explicit source and destination fields.
• Reject missing required financial fields after mapping.
• Test optional-field omission and aliases.
• Keep adapter configuration outside secrets and core code.

How the control should be operated

Adapter changes should be versioned, validated against representative payloads, and deployed with a restart or controlled reload procedure.

Onboarding becomes a governed mapping exercise rather than a fork of the payment platform. 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.