Integrations

PH-08 owns the domain behavior of payment execution and its Connector framework specifically; STD01-09 and STD01-08 set the platform-wide contract and resilience rules every external integration follows — payment or not, the same way PH-12's Notification Engine reuses the domain/mechanics split rather than defining its own.

Connector/Adapter versus Connection (STD01-09)

Executable integration behavior is versioned code (a Connector/Adapter), deployed through normal software delivery — no arbitrary runtime code upload or scripting. Tenant/provider-specific endpoint, identifier, secret-reference, and operational configuration is a separate Connection; one Connector/Adapter implementation can support multiple Connections. Connections reference secrets — payment/domain records never contain secret values. Not yet built.

Transformation lineage and contract compatibility (STD01-09)

Every transformation between a canonical DragonPay request/status and an external contract retains the Connector/Adapter version, internal contract/schema version, mapping-set version, and external API/message/file schema version needed to reproduce and troubleshoot the interaction. Breaking changes require an explicit major version and a controlled migration path; a new Connector/Adapter version must pass contract/conformance tests before production activation. Not yet built.

External dependency resilience (STD01-08)

Applied at the Connection/adapter boundary so one degraded CU/provider can't exhaust platform resources: circuit breaker (CLOSED / OPEN / HALF_OPEN), bounded concurrency and queued work per Connection, provider/CU rate limits enforced before calls reach the external dependency, and normalized operational health (health_state, circuit_state, admission_state). Not yet built.

What's still open

Several integration-adjacent technology choices remain open — async messaging, SMS/email delivery — see the Decision Register and Build vs. Buy.