Adapter first
Provider credentials and calls stay behind backend services.
Developers
Developer-ready foundations before public merchant APIs
Oceafin's MVP is web-first, but its internal boundaries are prepared for future merchant APIs. Payment creation, idempotency, webhooks, events, and audit records are designed as durable contracts.
Idempotent by design
Repeated requests, retries, and webhook updates keep stable business references.
API roadmap
Merchant API keys, signatures, rate limits, and webhooks can build on existing boundaries.
Developers
Prepared for integration without rushing exposure
Oceafin's first product surface is web-first, but the implementation should still behave like a platform. Payment creation, idempotency, webhook ingestion, audit trails, fee snapshots, and ledger events need stable internal contracts before public merchant APIs are exposed.
That discipline keeps the roadmap open. When merchant API keys, webhook subscriptions, sandbox tools, or developer documentation become part of the product, they can reuse the same boundaries already serving Admin Web, Merchant Web, and the operator app.
The developer page therefore focuses on foundations rather than premature API marketing: adapter boundaries, event models, retry-safe requests, webhook evidence, and implementation surfaces that can become public only when the product is ready.
Contract surfaces
POST /payments/*
Payment creation should carry merchant context, idempotency keys, capability checks, fee basis, and a durable local request record before any provider call.
POST /beneficiaries/*
Beneficiary and wallet records need ownership, screening, evidence, and status fields that can be reused by payout and withdrawal flows.
POST /webhooks/provider
Webhook ingestion must verify, deduplicate, store raw evidence, map channel status, and trigger safe state transitions.
GET /ledger/events
Ledger-facing reads should explain balance movement through business events, fees, holds, reversals, and reconciliation references.
Boundary
Keep adapters internal
Provider credentials, route selection, request signing, and raw provider payloads remain behind backend services.
Idempotency
Make retries safe
Every create or submit operation keeps stable references so duplicate clicks, network retries, and webhook races do not create duplicate business effects.
Events
Persist evidence
Requests, responses, webhook payloads, audit actions, and ledger events are stored as evidence that future APIs can expose selectively.