Payment rails, balances and reconciliation

Two balance concepts must remain distinct#

A payment provider acknowledging a bank or card transaction is not the same event as on-chain collateral becoming usable. Similarly, an off-chain invoice balance is not automatically a transferable token balance. The intended design needs an explicit mapping between payment status, account credit and permitted market actions.

The brief allows a non-trading fiat workflow for invoices and refunds as well as conversion to USDC for trading. It does not name a contracted payment partner, specify supported countries or publish a conversion spread. Those facts must not be inferred from an asset label used anywhere in the interface or the API examples.

Reconcile every handoff#

A production ledger must explain how a provider payment event relates to an account credit, a conversion, collateral allocation and a later settlement or refund. Duplicate notifications, delayed transfers and reversed payments need defined states rather than ad hoc balance edits.

The investor brief calls out reconciliation breaks as an operating metric. Useful evidence includes the external payment reference, internal operation identifier, status history and the reason for any adjustment. These are suggested implementation details, not a schema supported by the current API.

1. 1
   Receive

   Payment partner reports the external event

2. 2
   Reconcile

   Map reference and status to the account ledger

3. 3
   Convert / credit

   Apply the permitted balance transition

4. 4
   Allocate

   Apply eligibility and collateral controls

5. 5
   Resolve

   Settle, refund or handle a reversal

Controls identified by the investor brief#

Before production, the brief requires identity checks, sanctions screening, transaction monitoring, chargeback handling, reconciliation, custody boundaries and jurisdiction-specific licensing analysis. These are project requirements, not a claim that any named provider or implementation satisfies them.

Payment finality and delivery finality can happen on different timelines. The loss policy must explain what happens if a card charge is reversed after compute has been consumed. A smart-contract payment rule alone does not resolve an off-chain chargeback.

What a user can do now#

A user cannot pay for anything. The portfolio endpoint reports account access as unavailable, and the order, swap and settlement endpoints return HTTP 503 whatever asset label a request carries. The marketplace demo checkout only writes a configuration record to the visitor browser; it charges nothing and contacts no provider.

Do not send funds to an address inferred from a screenshot or source placeholder. A future live payment integration needs documented account eligibility, supported rails, fees, custody relationships and a verified end-to-end operating flow.

• Understand the proposed NMESH discount ↗
• Inspect the prototype API ↗