Payments & Stablecoins: how we build reliable money movement

The business problem

A payout provider accepts a transfer, but its response never reaches your application. The customer still sees “processing.” Retrying through another provider could pay twice. Marking the payment as failed could release funds that have already left the account. Leaving it unresolved gives the operations team an obligation it cannot explain.

Payment systems face this uncertainty wherever money crosses a boundary: between a ledger and a bank, a signing service and a blockchain, or an exchange and a payout partner. Each system has its own identifiers, balances and definition of completion. A successful API request may establish only that an instruction was received.

We design around the payment obligation and the evidence needed to settle it. The system must retain what the customer authorised, which funds were reserved, what was submitted and what actually moved. That record gives recovery a safe starting point when a callback disappears, a transaction stalls or a provider becomes unavailable.

What we build

We build payment infrastructure for collections, payouts, conversion and treasury operations. The scope follows the currencies, networks, custody model and providers the product needs to support. Each supported route includes accounting and recovery behaviour as well as the transfer integration.

For batch payments such as payroll, the batch groups individual obligations. It does not turn them into one indivisible result. Operators need to see which recipients were paid, which are pending and which require correction without resubmitting successful items.

How we design money movement

The core sequence is payment intent → authorization → transfer → confirmation → reconciliation → failure recovery. Recovery can become necessary at any step, and reconciliation continues after apparent completion to detect returns or discrepancies.

Payment intent: preserve what was agreed

We first specify the payer, recipient, source and destination assets, network, amount, fees and completion conditions. A conversion also records the accepted quote, expiry and minimum output or fixed destination amount. Asset identifiers include the network and token contract where applicable; a ticker alone is insufficient to describe the route.

The intent receives a stable identifier before an external money movement begins. Changes to the recipient or economic terms follow an explicit amendment or replacement process with renewed approval. This prevents a later profile edit or pricing release from silently changing an authorised payment.

Authorization: reserve funds and constrain execution

Approval checks both the right to make the payment and the funds available for it. We define customer limits, applicable screening, treasury approvals and inventory reservations with the client's operating team. Concurrent requests must not reserve the same last available balance.

For platform-controlled signing, the signing boundary verifies the actual transaction against the approved intent. The checks cover destination, asset, amount and permitted fees, together with approval validity. Protecting a private key does not by itself stop an authorised application from requesting the wrong transfer.

Transfer: record the attempt before trusting its response

The payment obligation and its execution attempts have separate records. A worker persists the provider request identifier or signed transaction evidence before relying on an external acknowledgement. A restart can then inspect the existing attempt instead of constructing an unrelated payout.

Provider adapters define what can safely be repeated. Some support an idempotency key and lookup by client reference; others require transaction history or statements to resolve uncertainty. We check those capabilities during integration design because they determine whether automated recovery is possible.

Confirmation: verify the financial effect

We assign explicit meanings to accepted, submitted, included and completed states for each route. Blockchain confirmation checks the intended transfer as well as transaction execution. Fiat payout completion uses the provider evidence appropriate to that rail, with later returns handled as separate events.

The interface uses those distinctions. A transfer accepted by a partner can remain pending delivery. A blockchain transaction can appear provisionally before it reaches the confirmation policy required for an external payout. The client can choose a faster release policy only with the resulting exposure made explicit.

Reconciliation: compare records at a consistent point

The financial ledger records amounts in integer base units or fixed-precision decimals and balances entries within each asset. A conversion has separate currency legs, with recorded fees and inventory effects. Reserved, pending and available balances remain distinct.

We compare the ledger with provider records, custody balances and chain observations using compatible cutoffs. In-transit payments and fees need explicit treatment so timing differences do not become unexplained losses. Every discrepancy enters a classified exception with an owner, supporting references and an allowed resolution; a manual balance overwrite would destroy that history.

Failure recovery: resolve the existing obligation

An uncertain transfer stays attached to its original intent while the system queries its outcome. Retry, replacement, cancellation and refund are different operations with different preconditions. A refund cannot proceed merely because the payout worker timed out; the original payout may still execute.

We implement and test one complete route before multiplying providers or currencies. That includes a missing callback, a worker restart after submission and a reconciliation discrepancy. The first route establishes which financial facts must survive a failure and which provider behaviours require manual intervention.

Decisions that matter

Where does idempotency stop duplicate payments?

An API idempotency key handles repeated submissions only within its defined scope and retention period. We bind it to the customer, operation and request contents, reject conflicting reuse and return the existing operation for a matching retry. Durable uniqueness constraints then protect ledger postings and payout obligations even after an API cache expires.

Inside the platform, committing a financial change and its outbound event together prevents a crash between those actions from losing the notification. Consumers deduplicate repeated delivery. At the external boundary, provider keys or persisted blockchain attempts carry the same obligation forward. Retrying a workflow alone cannot guarantee a single financial effect.

How do missing or out-of-order callbacks resolve?

Callbacks are authenticated, stored durably and processed with duplicate detection. A late “processing” event must not overwrite a verified completion. Conflicting events trigger a provider lookup or reconciliation instead of letting arrival order decide the financial state.

Polling and statement ingestion provide recovery paths when notifications fail. We establish the provider's lookup guarantees, history retention and idempotency window before enabling automatic retries. If those cannot resolve an ambiguous result, the payment remains held for investigation with its reservation intact.

What can happen to a stuck blockchain transaction?

For an account-based payout route, nonce allocation belongs to a controlled wallet queue. A fee replacement stays linked to the original obligation and preserves the authorised recipient and amount. Losing an RPC response does not justify allocating another nonce and sending a second payment.

A Bitcoin route instead needs input reservations and tracking of conflicting spends. Each chain adapter also defines confirmation and reorganisation handling. If an incoming deposit disappears after an outgoing payout has completed, recovery records the exposure; changing a database status cannot retrieve the money already sent.

Who can move treasury funds?

We separate payment preparation, approval and signing. Treasury replenishment, new withdrawal destinations and changes to limits need their own permissions. Every signed movement must connect to an approved purpose, including transfers between the platform's own wallets.

Operating balances and cumulative outflow limits constrain the amount exposed to online signing. Available liquidity excludes existing reservations and buffers. A large wallet balance can therefore coexist with insufficient funds for a new quote, and both the router and operations screen must show that distinction.

When is provider failover safe?

An unavailable provider can be removed from new route selection immediately. Payments already submitted to it require outcome checks before another provider can take over. Otherwise an availability measure becomes a source of duplicate payments.

The same distinction applies to an uncertain exchange fill. Retrying the hedge at another venue can double the position. Prefunded inventory can keep eligible customer payments moving within agreed limits while treasury resolves the original fill, but it requires committed capital and a defined point at which new orders stop.

What does the stablecoin route depend on?

We document the exact settlement asset, custody arrangement, liquidity sources and conversion policy. The design review covers issuer controls, redemption access, price deviation and any bridge dependency for the selected route. A token balance cannot be treated as interchangeable with cash already available at a payout partner.

Gas inventory is another operational dependency. A wallet holding payout tokens may still lack the native asset needed to send them. We define replenishment thresholds, fee ceilings and blocked-payment handling alongside token liquidity. A route suspension must preserve existing customer obligations and specify how operators resolve them.

The recovery specification makes these distinctions reviewable before launch:

Selected work

AspanDigital, CashBridge and ZeroGrid show different control boundaries: cross-border payment routing, exchange payout recovery and conditional release of escrowed funds. These examples describe the architecture and engineering scope documented in the project materials.

AspanDigital: tying a quote to liquidity and signing

AspanDigital's payment architecture addresses a promise that spans several systems: a customer accepts a price, the route needs sufficient liquidity, and the signed transaction must still match the approved transfer. Software releases and policy changes can occur while that payment is pending.

Our design stores the route and accepted pricing terms with ledger reservations. Participating signing nodes independently check a signed compliance attestation against the actual transaction and a matching ledger hold. A changed recipient or amount cannot rely on the approval issued for the original intent.

The scope includes a double-entry ledger, corridor router, compliance engine, distributed signing controls, chain indexers and reconciliation between ledger reserves and custody balances. Versioned payment handlers preserve unfinished flows across releases. The result is a defined connection between what was quoted, what was authorised and what may be signed. Read the AspanDigital case study.

CashBridge: recovering without sending the payout twice

CashBridge connects an incoming crypto deposit to an outgoing payment, including BTC-to-USDC exchanges. A worker can fail after broadcasting the payout while leaving no successful RPC response. Recovery must determine whether that transfer exists before taking another financial action.

We separated the customer obligation from its execution attempts. The design reserves output inventory and persists signed transaction bytes, transaction hashes and nonce or input reservations. A replacement worker reconciles that attempt; an authorised fee replacement retains its relationship to the same payout.

The architecture combines durable order workflows, an authoritative ledger, inventory reservations, a payout authorizer and an isolated signing broker. Dedicated deposit addresses remain monitored after order expiry so late funds enter an exception process. Its accounting rules prohibit settling the same order with both a full payout and a full refund. Read the CashBridge case study.

ZeroGrid: reserving exit claims before the next release

ZeroGrid addresses conditional funding: a project receives staged payments while investors retain defined exit rights over money still in escrow. Approving a milestone is insufficient if the next release can consume funds already owed to exiting investors.

Our design separates available campaign funds, reserved exit claims, founder collateral and amounts already released. Registering an exit reserves the investor's payout before the next founder allocation becomes executable. Claiming those funds happens separately, so one investor's delayed withdrawal does not hold up the remaining campaign.

The scope includes escrow contracts, milestone approval and release rules, claim accounting, event indexing and recovery access independent of the main application. A failed token transfer preserves the claim, and campaign termination allocates only funds still controlled by the protocol. This makes the limit of recovery explicit: previously released capital cannot be reclaimed by changing the campaign state. Read the ZeroGrid case study.

What the client receives

The delivery package covers the working payment route and the controls needed to operate it. We agree acceptance checks for duplicate-payment attempts, competing inventory reservations and recovery from failed or ambiguous submissions. Those checks follow the provider's idempotency and lookup capabilities and the evidence retained for each obligation.

• A payment and accounting specification with state transitions, authorisation rules, ledger entries, provider dependencies and confirmation policies for each supported route.
• Working APIs, transaction workers, provider adapters and signing or contract integrations, with durable identifiers connecting the payment to every execution attempt.
• Treasury controls for reservations, wallet permissions, liquidity thresholds, fee limits and independently approved replenishment where required.
• Monitoring for aged payments, callback gaps, stuck transactions, low gas or payout inventory, signing failures and reconciliation discrepancies, with owners and response procedures.
• An operations interface and recovery flows for investigating uncertainty, approving supported replacements, handling returns and resolving discrepancies without erasing financial history.
• Deployment configuration, access handover, API documentation, recovery runbooks and evidence from the agreed integration, accounting and failure tests.

Before launch, we rehearse provider outages and interrupted payouts with the operations team. Releases must also preserve pending payments and their original terms. The system is ready to operate when the team can establish what is owed, what has moved and which action can safely happen next, including when an external system stops answering.