Skip to main content

​
Overview

Daya Coins follows a merchant-managed account model. Daya maintains your business’s aggregate Coins balance and transaction records; your business maintains the breakdown of those assets across its own customers.

​
Responsibility model

​
Separate product balances

Coins, Stocks, and the Business API keep independent balances. You can display them together, but they are not one spendable pool.
Do not fund a Coins order from a Stocks or Business API balance. Check the Coins balance before creating the order. Moving value between products is a separate operation — never assume a cross-product movement and a trade settle atomically.

​
Customer allocation workflow

1

Record the instruction

Create an internal operation ID and record the customer, asset, side, and intended amount.
2

Quote and order

Request a quote, then place the order with its quote_id. Save one Idempotency-Key for this logical order and reuse it for every retry.
3

Store the Daya order ID

Link the returned order to the customer operation in your system.
4

Wait for a final outcome

Process the terminal order webhook, or poll GET /orders/{id} until the order is filled or failed.
5

Update the subledger

Apply the filled quantity, cash movement, and fees to the customer exactly once.
6

Reconcile

Compare the sum of customer allocations against the aggregate Daya Coins balance and portfolio.

​
Reconciliation

Persist the last state you processed for every order and transaction, make customer-ledger updates idempotent, and periodically compare the sum of customer allocations with the aggregate Daya balance and portfolio.
Configure signed order and money-movement webhooks in the Daya Dashboard. Keep API polling and periodic reconciliation as fallbacks for delayed, duplicated, or missed deliveries.