This page is the complete list of what DimeTrades tells you about money for a customer whose balance you hold (external wallet integration). For each flow it states which events are sent, in what order, which id ties them together, and — just as important — where no wallet event is sent.
Wallet events are the authoritative instruction to move money on your side. DimeTrades holds no balance for these customers, so if a flow is listed here as “no wallet event”, nothing will tell you about it. Dedupe on the envelope id.

​
Reason values

reason appears on every wallet.debit and wallet.credit. These are the only values sent today. Parse reason as an open set: new values are added as new money flows gain events.
Despite its name, reason: settlement is not a market settlement. It means money from a trade fill. A market paying out uses market_settlement. The name is kept so existing integrations don’t break.
Amounts are always positive integers in US cents; the event type (debit or credit) gives the direction.

​
What each flow sends

Order within a flow is the order DimeTrades writes the events, all in the same database transaction as the money movement. Delivery order is not guaranteed (each event is delivered and retried independently), so match events using the correlation id in the last column, not arrival order.

​
Notes on each flow

Settlement win. A winning position is paid with wallet.credit, reason: market_settlement, outcome: yes or no, and amountCents = winningContracts × 100. Settlement loss. No event. The loss is the cost you already debited at fill time (wallet.debit), so there is nothing further to apply. Void / refund settlement. When a market is refunded through settlement, every contract pays: YES contracts pay settlementPriceCents and NO contracts pay 100 − settlementPriceCents. winningContracts equals yesContracts + noContracts. A refunded market that never traded sends no wallet event because no money moves. Market terminated by an admin. market.terminated tells you the market was voided and carries a platform-wide totalRefunded; it does not instruct a per-customer refund. Per-customer refund instructions for this flow are not sent yet — treat refunds for admin-terminated markets as outstanding until they are announced. Expired market. No refund or payout flow exists for expired markets yet, so no wallet event is sent. Trade bust. When a trade is busted while both parties still hold their contracts, it is reversed: a BUY leg is refunded with wallet.credit (cost plus fee) and a SELL leg’s payout is taken back with wallet.debit, both with reason: trade_bust_reversal and the busted trade’s orderId/tradeId. They are the mirror image of the events the original fill sent. Contracts that were already merged away when a BUY filled are not reversed. Bust corrected to fair value. When a party already sold on, the trade is not reversed; it is corrected to fair value as of when it executed. Make-whole payments, the proceeds of closing a position that was still held, and any amount recovered from the party at fault are netted into one wallet.credit or wallet.debit per customer, with reason: trade_bust_correction and a breakdown of the parts. Nothing is sent if the net is zero. Price correction. An admin re-prices the trade. Each of your customers in it gets trade.corrected with adjustmentCents (signed, positive is in their favour) and one wallet.credit or wallet.debit for exactly that amount with reason: price_correction. Fees are not recalculated. A trade can be corrected more than once; each correction has its own correctionId. Amounts are exact and never capped to a balance. DimeTrades holds no balance for your customers, so a debit is always the full amount owed. If a customer cannot cover it, how you handle that is your decision. trade.busted and trade.corrected. Each is sent once per player of yours in the trade and carries only that player’s own order and trade data: no counterparty, no party at fault, no admin details. trade.busted has resolution: reversed | corrected_to_fair_value. Both are sent before the wallet events of the same action, but delivery order is not guaranteed. Subscribe your endpoint to trade.busted, trade.corrected, wallet.credit and wallet.debit; existing endpoints are not subscribed to the new events automatically. Admin adjustment. An adjustment made by a DimeTrades admin never produces a wallet event. Your customers’ balances are yours; keep any adjustment on your side.
Rows marked “none yet” are known gaps, not intentional omissions. When a flow starts sending wallet events its reason value will be added to the table above and announced before it is switched on.

​
What to do on your side

  • Subscribe your endpoint to trade.busted, trade.corrected, wallet.credit and wallet.debit.
  • Apply every wallet.credit and wallet.debit exactly once, deduplicating on the envelope id.
  • On trade.busted, exclude the trade from your volume and P&L. If resolution is reversed, expect the refund as wallet events with reason: trade_bust_reversal.
  • Match events to the trade with tradeId, and to a correction with correctionId. Do not rely on arrival order.
  • Treat reason as an open set so a new value never breaks your parser.
  • You can stop polling trade history for busts and corrections.

​
Quick reference: debit versus credit