Skip to main content
Cards let your customers spend the balance you hold for them, at any merchant that takes Mastercard, in USD. They are the only part of the API where money leaves without you naming a destination — the merchant decides, and you set the boundaries in advance.

​
The gates

Two tier checks stand in front of issuance, and they apply to different parties.
The second gate cannot currently be satisfied. Every customer is created at tier 1, and no endpoint in the API raises a customer’s tier. A business client must name a customer as holder, so every issuance attempt fails.This is recorded as the first open decision for this service. Nothing in your integration will fix it; it needs either a customer verification path or a change to the holder rule.
The rest of this documentation describes the service as built, so that when the gate opens you are not starting from scratch. Read it as a specification.

​
What a card is, structurally

A card is a balance plus a set of rules.
  • The balance lives in a hidden USD account Sakawave opens for the card. You cannot reach it except through funding and withdrawal.
  • The rules are spending controls — a per-transaction cap, a daily cap, and a daily count — enforced at authorisation.
Funding moves money from your account to that balance. Spending moves it out to merchants. Withdrawal brings it back. Termination sweeps whatever is left.

​
Cards are not transfers

They look similar and behave differently in ways worth knowing before you start. The second row is the important one. A transfer that fails keeps its externalReference and resending returns the failure; a card issuance that fails is re-driven by resending the same reference. The two services have opposite retry semantics.

​
Who holds a card

Only a customer, through this API. The service also supports issuing to a dashboard user, and an individual client gets a holder created for it automatically, but neither is reachable from a business client’s API key — issuance takes a customerId and nothing else.

​
The shape of the API

Eleven operations, split into three groups. Lifecycle Money Control and visibility There is no endpoint to change a card’s label or its spending controls after issuance.