Abstraction layer
One API surface over many payment rails, assets, and settlement environments
Why abstraction matters
Integrating directly with every bank switch, payout aggregator, card network, and settlement environment does not scale. An abstraction layer normalises operations—deposit, transfer, payout, balance query—behind one API contract and one event schema, regardless of whether the user holds USDC, EURC, or a regional stablecoin.
What gets abstracted
| Concern | Without abstraction | With GoldRail Gateway / PayLink |
|---|---|---|
| Auth | Per-provider credentials | Single tenant identity |
| Status codes | Provider-specific | Normalised job states + Echo events |
| Retries | Ad hoc | Safe idempotent operations |
| Asset & rail details | Developer manages complexity | Platform handles settlement paths |
Gateway orchestrates multi-step flows (collect → convert → disburse). PayLink exposes product-specific capabilities while sharing consistent middleware for validation, logging, and security.
Trade-offs
Abstraction adds latency and a dependency on the platform operator. In return you gain faster integration, consistent error handling, and network effects—reach other fintechs and corridors without new bilateral contracts.
Design tip for integrators
Model your domain in business objects (Customer, Wallet, Payout) mapped to GoldRail identifiers. Avoid leaking provider-specific fields into your core ledger; store them in metadata for support investigations.