开发者

在开放商户 API 之前准备开发者基础

Oceafin 的 MVP 以 Web 为主，但内部边界会为未来商户 API 做准备。交易创建、幂等、Webhook、事件和审计记录都按稳定契约设计。

Adapter 优先

通道凭据和调用保留在后端服务内。

重复请求、重试和 Webhook 更新保持稳定业务引用。

商户 API key、签名、限流和 Webhook 可以建立在既有边界上。

开发者

Developers 页面展示的是 Oceafin 的技术准备度：当前版本优先服务 Web 工作台和内部运营，但后端契约从一开始就按可开放 API 的方式组织。账户、支付、受益人、退款、换汇、费用和账务都有清晰边界。

这种路线能避免过早暴露不稳定接口，也能让未来商户 API、Webhook 订阅、API key、签名、限流、沙盒事件和文档门户建立在现有模型上。产品先把流程跑稳，再把稳定能力开放给开发者。

对接团队最关心的是确定性：请求能否幂等、失败能否解释、Webhook 能否重放、字段含义是否一致、状态变化是否能订阅。Oceafin 会把这些能力作为开发者体验的底层规则。

POST /payments/*

支付创建接口围绕业务引用、金额、币种、对象、幂等键和能力状态设计，避免重复提交造成歧义。

GET /accounts/*

账户和余额接口区分可用、处理中、冻结、外部状态和本地账务解释，让资金展示更稳定。

POST /beneficiaries/*

受益人接口保留银行账户、钱包、筛查、审批和可用状态，支持未来商户自助管理。

WEBHOOK /events

事件入口需要验签、去重、落库、重放、失败重试和运营可见的处理结果。

Model

先定义账户、支付、受益人、费用、账务和事件的核心字段与状态机。

Operate

在 Merchant Web 和 Admin Web 中验证真实运营路径、异常处理和权限边界。

Expose

当契约稳定后，再开放 API key、签名、Webhook 订阅、测试事件和开发者文档。