Merchant boundary
Tenant, merchant, member, and participant mapping stay explicit.
Platform
Oceafin turns payment operations into a business platform: merchant activation, global accounts, payment flows, risk status, fees, ledger records, and bilingual operations live in one product surface.
Tenant, merchant, member, and participant mapping stay explicit.
Fiat account capabilities, balances, deposits, and payout readiness are visible before funds move.
Admin Web, Merchant Web, and the operator app share the same source of truth.
Platform
Oceafin is designed as the operating layer between payment service providers, downstream merchants, and the regulated rails they rely on. It keeps provider integration details behind the platform while exposing the business objects a PSP actually needs: merchants, capabilities, accounts, balances, beneficiaries, payments, fees, approvals, and ledger records.
The product is intentionally status-driven. A merchant can be registered but not activated, an account can be requested but not ready for payout, a payment can be collected but not reconciled, and a webhook can be received but still require operational review. Presenting those states clearly is what turns raw financial connectivity into a usable Techfin platform.
For platform teams, this means one place to reason about access, ownership, and evidence. Merchant Web gives operators a clean workspace, Admin Web gives internal teams control and auditability, and the mobile operator experience can reuse the same capability and status model instead of inventing another operational truth.
Tenants, merchants, members, participants, and provider accounts are kept as explicit platform concepts, so PSP teams can scale beyond a single-merchant integration without losing operational boundaries.
The platform separates login registration from payment capability activation, making KYB/KYC, agreements, account readiness, and flow permissions visible before users can move funds.
Fiat accounts, deposit instructions, balances, pending movement, beneficiary readiness, and payout state are presented as business operations rather than raw provider payloads.
Roles, approvals, audit events, status evidence, and reconciliation data stay connected to each merchant action, giving support and finance teams a shared context.
01
Create the merchant account, bind it to a tenant and merchant boundary, and keep the account safe until activation requirements are complete.
02
Collect agreements, KYB/KYC data, files, contacts, and business information before enabling account, collection, payout, refund, and conversion workflows.
03
Run accounts, collections, payouts, refunds, conversion, fees, webhooks, and ledger checks from the same workspace.
04
Add routing, reporting, white-label readiness, and merchant segmentation without exposing provider credentials or raw channel complexity.