A payments API for the Maldives

Checkout sessionsLive

Create, retrieve, cancel. Hosted checkout page per session.

MandatesLive

A standing authorization your customer approves once. Collect later with one server call, inside the caps they agreed to.

WebhooksLive

Signed HTTPS endpoints for checkout.session.* and mandate.* events, with retries, a delivery log and replay.

Personal access tokensLive

Read your own balance, transactions and insights over GraphQL. Read-only for now.

OAuth2 appsLive

Authorization-code flow with PKCE and rotating refresh tokens, for apps acting on a user's behalf.

BalancesLive

Read wallet balances, derived from ledger entries.

HoldsLive

Reserve funds, then settle or release. Distinct ledger states.

Keys and scopesLive

Live and test keys. Issue, rotate, revoke. Every change audited.

SandboxLive

Separate environment, own keys and accounts. Toggled from the dashboard.

JS SDK and OpenAPI specBuilding

Generated from one OpenAPI spec. The reference is live as Markdown today.

Payment linksPlanned

Hosted, no code required.

Payouts and refundsPlanned

Behind the scope catalogue that already exists.

Underneath it is a payment service provider licensed by the Maldives Monetary Authority under the National Payment System Act, with customer funds in a segregated account. The compliance obligations are ours.

Keys carry their environment

sk_test_ can't reach production, and pk_live_ won't be mistaken for a test key in a log. Secrets are shown once, stored hashed, and rotate without downtime. Issues, rotations and revocations are all audited.

Every write is safe to retry

Send an Idempotency-Key on any mutating call. A repeat of the same key replays the original response instead of charging twice. The same key with a different body returns 409. Keys are scoped to the credential that used them.

The sandbox is a real deployment

A separate environment running the same code, with its own accounts and keys, rather than a flag that takes a different branch in process. The path you test is the path that runs in production.

Scopes and per-key limits

A key that only creates checkout sessions can't read balances or move money. Rate limits are per key, so one noisy integration doesn't throttle the rest of your account.

Mandates add no credential of their own. Your customer's approval is the authorization, and you charge with the same secret key, so a mandate is a permission on their side rather than a token on yours. See Authentication for the scopes each one carries.

Toward programmable money

A payments API moves money when you tell it to. We're building toward money you can attach conditions to: funds that release when something becomes true, authority that expires on its own, limits the ledger enforces instead of your application code.

Holds are the part of this that already works. Money sits under conditional control and settles or releases later, as a real ledger state rather than a flag your code has to remember to check. We can offer that because the ledger is ours: conditions on money have to be enforced where the money is, not in a layer above someone else's core.

Mandates are the second piece, and they are live. Authority scoped to a purpose, capped per charge and per month, expiring on its own, revocable in one tap by the person who granted it. The caps are enforced where the money is rather than in the code doing the charging, and every charge records which mandate it happened under. An integration that misbehaves burns its own authority, not the account.

The piece still ahead is pointing that same primitive at software spending on a person's behalf: the agent proposes a payment, the person confirms the exact amount and payee on their phone, and the mandate bounds everything it can do in between. That part is the direction, not a date. If it's why you're here, say so below.