Provider gateways: one contract, twelve providers.
Swap card issuer or open-banking provider without touching the ledger.
The provider coupling problem
Every fintech that integrates a payment provider directly eventually faces the same problem: the provider relationship changes, and the product has to change with it. The provider raises fees, the product team wants to switch. The provider has an outage, the engineering team has no fallback. The regulator asks for a business continuity plan, and the answer is 'we have only one provider for this rail'.
The Coreal provider gateway (PG-03) solves this by abstracting all provider integrations behind a single contract. The ledger does not know whether a SEPA payment was routed through Provider A or Provider B. The BPM engine does not know which card issuer processed an authorisation. The product code expresses intent: 'route this SEPA credit transfer'. The gateway selects the provider based on availability, cost, and routing rules.
The gateway contract
The gateway contract is a typed interface that every provider adapter must implement. For payments: initiate, confirm, cancel, status, settle. For cards: auth, capture, reverse, void, inquiry. For accounts: open, close, balance, statement. The adapter translates between the Coreal interface and the provider's native API, handling differences in data model, error codes, retry semantics, and idempotency requirements.
The idempotency requirement is critical: every payment initiation carries a unique idempotency key. If the same key is submitted twice (due to a network retry, a client bug, or a test), the gateway detects it and returns the original result without processing the payment a second time. This guarantee is required for double-entry correctness: you cannot have a ledger posting without a corresponding payment, and you cannot have a payment without a corresponding posting.
Failover and the 200ms SLA
Provider failover is a routing rule, not an incident response procedure. When a provider returns an error class that indicates an outage (as opposed to a transaction-level decline), the gateway's routing logic automatically routes subsequent transactions to the secondary provider. The switchover is transparent to the product: the ledger sees a successful payment, and the audit trail records which provider processed it.
The p95 failover time — the time between a provider failure and the first successful transaction on the fallback — is under 200ms in our production environment. This is achievable because the failover decision is local to the gateway process, without requiring a human decision or an operations procedure.