creating-integrationlisted

# External and legacy integrations Put concrete external adapters in `App\Infrastructure\Integrations`, grouped by provider when useful. Legacy workflow bridges may live in `App\Infrastructure\Legacy`. Keep HTTP clients, SDK objects, transport failures, and provider-specific payloads at this boundary; translate them into consumer concepts. ## Connect the consumer A consumer in Domain or Application cannot depend on a concrete Infrastructure class. This boundary is a concrete reason for a contract: - Application need: `App\Application\<Capability>\Contracts`. - Domain need: `App\Domain\<Capability>\Contracts`. - Implementation: Infrastructure. - Binding: a standard Laravel service provider. ```php // App\Application\Orders\Contracts\PaymentGateway interface PaymentGateway { public function refund(string $paymentReference, string $idempotencyKey): void; } // In a service provider's register() method: $this->app->bind( \App\Application\Orders\Contracts\PaymentGateway::class, \App\Infrastructure\Integrations\Payments\ProviderPaymentGateway::class, ); ``` After `OrderCancelled` commits, a queued listener can invoke a refund Action that receives `PaymentGateway`. The adapter implements that interface and translates the provider response. Derive a stable idempotency key for a refund operation and use the provider's supported mechanism or an application deduplication strategy. Do not inject SDK types into the contract or resolve concrete adapters from Actions thro