Provider connections

Route handles the provider integrations. Your backend uses one Route API key; select which providers its policy may consider, then inspect each quote's execution and preparation capabilities. A provider connection check does not establish liquidity or execution for every pair.

Connection choices#

See compatibility for asset representations, wallet requirements and destination fees. Current candidate and action flags decide whether a specific path can proceed.

Connection options#

NEAR and SwapKit support two explicit project settings. Garden retains these settings but is currently paused:

In Providers, select Use Route’s connection, or enter your own credential. The active source is displayed. Shared credentials remain server-side and are never returned to customers. Both modes follow the existing Route credit rates, project limits and routing policies. Provider fees and network fees are separate from Route credits. Provider quotas or outages can temporarily prevent quotes.

For API setup, use a key with providers:write:

PUT /v1/providers/swapkit
Authorization: Bearer ROUTE_API_KEY
Content-Type: application/json

{"version":0,"enabled":true,"credentialSource":"route"}

Use the actual current connection version from GET /v1/providers. That response includes routeConnections availability, the selected credential_source, credential_present for the active connection and customer_credential_present for your saved credential.

To use your own account, save its credential with PUT /v1/providers/near/credential or PUT /v1/providers/swapkit/credential, passing the current version and credential. Then enable the provider with credentialSource: "customer". Obtain a SwapKit key from the SwapKit dashboard. A failed customer credential never falls back to Route’s account.

Switching changes the provider version: request fresh quotes for new activity. Existing NEAR preparations retain their original credential source for refresh and scheduled tracking. Switching does not delete your saved credential. Replacing or removing a customer credential can prevent tracking of orders made with that account; retain access until those payments complete.

Removing a provider key with payments in flight#

DELETE /v1/providers/{adapter}/credential with the current {"version":N} removes your saved key and is never blocked. The response is {"ok":true,"version":N+1,"credentialPresent":false,"warnings":[...]}. When payments tracked with this key have funds in flight and no terminal outcome, warnings contains {"code":"UNSETTLED_PROVIDER_PAYMENTS","count":N,"message":"…"}. Such payments have a source hash or an unconfirmed wallet handoff of a funding transaction. Payments that use Route’s connection, cancelled payments, payments that were never funded and payments with only a pending spending approval are not counted. The warning lists what automatic tracking may no longer reach; nothing is cancelled or released.

For SwapKit payments whose key was removed:

• Delivery: reconnect the original SwapKit connection, then use POST /payments/{id}/refresh, optionally with {"destinationHash":"HASH"}. SwapKit must identify that exact transaction as the final delivery leg of the saved source transfer. Route also verifies the finalized canonical receipt, recipient, destination asset, reported amount, saved minimum and source time before reserving the exclusive payout claim. A supplied hash cannot replace provider attribution: missing credentials, unavailable tracking or a mismatched report leave the payment unsettled and keep its reservations.
• Refund: {"refundHash":"HASH"} is accepted only when SwapKit’s tracking reports that exact transaction as the swap’s refund leg. Route then verifies a finalized credit of the reported source-asset amount to the saved refund address. Any wallet can send funds to the refund address, so chain credit alone never settles a refund. Without the key the request returns 409 PROVIDER_CREDENTIAL_REQUIRED. A hash that SwapKit does not report as the refund returns 409 REFUND_RECEIPT_MISMATCH. Reconnect a SwapKit key to confirm a refund, or have a workspace member confirm it in the dashboard; the payment and its reservations stay unchanged meanwhile.

Confirm a SwapKit refund in the dashboard#

When SwapKit cannot confirm a refund, a workspace member can confirm it from the payment's details with Confirm refund. This is a dashboard action only: API keys cannot use it and /v1 has no equivalent. The member needs a role that can prepare payments (owner, admin, developer or operations) and must have signed in within the last 15 minutes; otherwise the request returns 403 FRESH_SIGN_IN_REQUIRED.

The action is available for a standalone SwapKit payment whose deposit is verified and finalized, with no verified delivery or refund. Multi-step payments are excluded. A payment for which Route already holds delivery evidence (a destination transaction verified while its payout claim is pending, or a recorded settlement discrepancy) is refused with 409 PAYMENT_DELIVERY_EVIDENCE. Route first asks SwapKit when a connection is available. If SwapKit reports this swap as completed, even when the reported payout does not match the saved recipient or minimum (409 PROVIDER_REPORTS_DELIVERY), or reports its own refund with a different transaction (409 PROVIDER_REPORTS_REFUND), refresh the payment instead. Manual confirmation applies only when the SwapKit key was removed, its tracking cannot be read or does not describe this swap's deposit, it reports no outcome, or it reports as its refund the same transaction the member supplies but Route cannot verify that report (providerCheck reported-unverified).

Route then verifies the supplied hash on chain:

• the transaction is successful and final: EVM finalized block, or six Bitcoin confirmations (409 REFUND_NOT_FINALIZED otherwise);
• it credits the payment's source asset to the saved refund address, as a canonical net credit;
• it was included after the deposit: in a later block on Bitcoin (block heights, since Bitcoin block times are not ordered), or at a later block time on EVM networks;
• its senders are identifiable and none is the payment's sender, refund or recipient address: the EVM transaction sender and the token senders to the refund address, or the Bitcoin spent-output addresses. A self-transfer or a withdrawal submitted by the payer's saved wallet is refused. Route cannot recognize other wallets the payer controls;
• the credited amount is at most the deposit and at least the payment's minimum refund.

The minimum refund is the deposit less three allowances: the provider fees in the saved SwapKit quote, the accepted slippage, and 10% of the deposit. The fees count those in the source asset and those in the destination asset, converted at the quote's own rate (deposit ÷ expected output), with Route's 10% fee headroom. The 10% of the deposit covers the refund's source-network fee, which the quote does not price. The minimum is never below half the deposit. If the quote deducts a fee in any other asset, the minimum is half the deposit. A genuine refund below the minimum can still be settled from SwapKit's own report: reconnect SwapKit and refresh the payment. Whether the credit came from the payment's SwapKit deposit address is recorded but not required, because vault-based providers refund from other addresses. A failed check returns 409 REFUND_RECEIPT_MISMATCH with details.reason, and nothing changes. Each payment allows ten checks per five minutes (429 TRY_LATER).

On success Route reserves the transaction as this payment's exclusive payout (409 REFUND_ALREADY_CLAIMED if another payment already holds it). The payment becomes REFUNDED and emits payment.refunded. The usual refund rules apply to credit holds. tracking.refundConfirmation records the member's user ID, the time, the hash, why SwapKit could not confirm (providerCheck), the accepted range, the senders and whether one of them is the payment's deposit address. GET /payments/{id}/next-action then returns refunded with a message that a workspace member, not SwapKit, confirmed it. The workspace audit log records payment.refund_confirmed_manually for the member. Chain checks cannot prove that SwapKit sent the transaction; the member's confirmation is that attestation.

Garden#

Temporarily unavailable. Route has paused new Garden quotes and execution while provider availability and execution support are verified. Garden is excluded from route comparisons, Auto-route plans and SwapKit candidates that depend on Garden. Other providers remain available under your policy.

GET /adapters reports platformAvailability.status: "paused" and capabilities.quote: false. GET /providers reports effective enabled: false; configuredEnabled preserves the owner's saved preference. Enabling Garden returns 409 PROVIDER_PAUSED, for either a customer App ID or Route's connection. Adding or replacing a credential cannot bypass the pause.

Paused providers are hidden from dashboard setup, new policy and API-key provider choices, and health checks. Saved credentials, policy preferences and existing order records are retained. Existing strict provider rules remain visible so they can be reviewed; Route never silently changes the required provider. The pause does not delete or cancel an existing order. Asset identities remain in the catalog, but Garden is omitted from their active quoteProviders. A Garden-only policy needs another available provider before it can return an eligible route. Route does not silently expand the policy.

Rift#

Rift (rift) is an optional REST API provider. Enable it in Providers and include it in the routing policy and API-key provider restrictions. It needs no provider API key; requests to Route still need a Route API key. This implementation uses Rift's current REST contract, not an earlier Rift SDK.

Read the connection's current version from GET /v1/providers, then use a key with providers:write:

PUT /v1/providers/rift
Authorization: Bearer ROUTE_API_KEY
Content-Type: application/json

{"version":0,"enabled":true}

The version above is illustrative. Use the actual current value. There is no Rift credential endpoint.

Assets and networks: read GET /v1/assets and filter quoteProviders for rift. The reviewed catalog covers Ethereum, Base, Arbitrum, Ink, Robinhood, Bitcoin and Hyperliquid HyperCore, including crypto, tokenized stocks, ETFs and vault shares whose identity and precision have been verified. Each issuer, contract and network remains a separate asset. Unknown decimals are not guessed. HyperCore balances are distinct from HyperEVM tokens; wrapped Bitcoin is distinct from native BTC. The upstream token list is non-exhaustive, but Route only offers reviewed identities.

Use the usual POST /v1/quotes with exact catalog asset IDs and a decimal source amount. Different assets on the same network are accepted for Rift. Its received is an estimate after venue and delivery costs. minimumReceived is null: the final amount may vary and there is no slippage protection or guaranteed minimum. Source gas is checked during wallet preparation; a full arrival estimate remains unavailable. Missing token prices leave USD-policy checks unresolved. Quote freshness ends at the earlier of Rift's expiry and 60 seconds after observation.

Payment flow: choose a direct Rift candidate explicitly and create the payment through POST /v1/payments. Rift is not an automatic fixed-minimum recommendation and cannot be a leg in a composed payment. Read its execution flags. Direct preparation supports reviewed assets on Ethereum, Base, Arbitrum, Ink and Robinhood, plus native Bitcoin. EVM senders must be externally owned wallets; Bitcoin senders must use single-key native SegWit or Taproot. HyperCore remains quote-only.

Prepare through the existing endpoint, with a persisted UUID Idempotency-Key:

POST /v1/payments/PAYMENT_ID/prepare
Authorization: Bearer ROUTE_API_KEY
Idempotency-Key: PERSISTED_UUID
Content-Type: application/json

{"version":1,"sender":"SENDER_ADDRESS","recipient":"RECIPIENT_ADDRESS","acceptVariableOutput":true}

acceptVariableOutput must follow the customer's explicit acceptance; do not silently set it in a UI. It is required for Rift, and does not invent a minimum from the estimate. Route binds the quote, source amount, recipient and sender refund address before allocating an order. Refunds return to the sender; an arbitrary refund override is not accepted. The order's deposit deadline is seven days after creation, while the wallet action has its own shorter review expiry. Always follow current action flags. A timeout does not justify a fresh quote or replacement order: resume the same saved preparation and terms. An ambiguous or malformed allocation is retained for review.

Review and sign the exact locally built deposit transaction, then use the existing signature and execution endpoints. Creating or preparing an order does not move funds. Continue with GET /v1/payments/{id}/next-action and the existing refresh flow. A submitted source deposit proves funding, not recipient delivery.

Tracking: Rift statuses are awaiting_deposit, funded, underfunded, executing, delivered, refunded, expired and frozen. Its reported amount_out is destination units for delivered orders and source units for refunds. Route keeps the provider status separate from independently verified settlement. The current REST contract has no payout or refund transaction hash. A delivered or refunded report remains verification-pending until a canonical, finalized payout is independently linked to this order. An address, amount and time match alone is insufficient; ambiguous evidence does not complete the payment. Do not fund again because verification is pending. Frozen and underfunded orders need review rather than automatic replacement funding.

Live verification: on October 1, 2026, an isolated Cloudflare staging Worker successfully read Rift’s health endpoint and received valid live quotes for Ethereum USDC → Base USDC and Ethereum USDC → Ethereum AAPLon (a tokenized stock). The earlier development HTTP 403 / Cloudflare 1010 response did not prevent these Cloudflare requests. The checks created no orders and moved no funds. Live order allocation, funding, delivery and refund settlement remain unverified. A successful quote does not guarantee continued availability, a minimum output, or another pair or amount; the implementation also has contract and simulated-provider tests.

References: Rift quickstart, token identities, quote API, order status, API contract.

SwapKit#

SwapKit (swapkit) adds cross-chain quote comparisons through its underlying providers. A candidate such as SwapKit · NEAR or SwapKit · CHAINFLIP identifies the service behind that path. Direct NEAR candidates remain separate: account access, fees and route terms may differ. Garden-backed candidates are excluded while Garden is paused.

Quote failures distinguish provider limits from authentication. details.errorCode: "SWAPKIT_SIZE_LIMIT_EXCEEDED" means the requested amount exceeds the selected SwapKit key's trade-size limit; check that Route's amount is a decimal quantity of the source token (for example, "0.000132" BTC, not "13200" satoshis), then reduce the amount or review the provider key's limit. SWAPKIT_ACCESS_DENIED means SwapKit rejected authentication or access. SWAPKIT_PAIR_UNAVAILABLE means no current route was returned for the exact assets and amount; it does not by itself identify a minimum trade size. These provider checks are separate from your Route policy and usage-credit balance.

Execution coverage: simple native-token or ERC-20 deposits from Ethereum, Base or Arbitrum, and native Bitcoin deposits from single-key native SegWit/Taproot wallets, to reviewed EVM ERC-20 assets, Stellar classic/native assets or native Bitcoin. Each candidate reports its own execution.supported value. Preparation additionally requires a provider deposit channel with a supported deadline and locally verified transaction fields. Contract-call routes, memo-bearing deposits and other source networks remain quote-only when a quote is available. Garden-backed paths, including Bitcoin escrow routes, are paused for both quotes and execution. Bitcoin channels with a block deadline must also include a wall-clock deadline and have more than six blocks remaining. EVM block-deadline channels need separate support.

Discover and compare#

Use GET /assets and filter quoteProviders for swapkit. The reviewed catalog includes popular assets on 33 SwapKit networks. An entry means an exact token identity is recognized; a live quote still decides pair availability and liquidity. Stellar entries include native XLM and Circle-issued USDC, not USDT0.

The same POST /quotes request applies:

{
  "sourceAssetId": "SOURCE_ID_FROM_ROUTE_CATALOG",
  "destinationAssetId": "DESTINATION_ID_FROM_ROUTE_CATALOG",
  "amount": "10",
  "slippageBps": 10
}

No wallet addresses are needed for price discovery. Route sends human-readable amounts and converts basis points to SwapKit’s percentage unit: 10 bps becomes 0.1 percent. Chain, contract or issuer, decimals and exact asset identity remain bound to the requested pair. EVM address casing is normalized; other chain identifiers remain case-sensitive.

The current integration compares assets across different networks, consistent with Route’s quote API. It does not expose SwapKit’s same-chain swaps, limit orders or other standalone APIs.

Candidate fields#

• route names SwapKit and its underlying providers.
• In view=full, details.quoteId and details.routeId identify the upstream comparison and offer; details.underlyingProviders retains the provider sequence. The optional compact view keeps the provider names in route. Mainnet defaults to a single recommendation summary with view=best; use compact/full for these candidate details.
• received and minimumReceived preserve the expected output and the published slippage floor. A response with a weaker minimum than the requested tolerance is rejected.
• fees discloses provider charges without deducting included fees from the output a second time. Inbound and priority estimates are additional. Exact wallet gas, approvals and unresolved fee assets remain explicit, so total cost is not yet marked complete.
• compact and full retain eta and its timing scope. In view=full, details.inboundSeconds, details.swapSeconds and details.outboundSeconds expose available provider stages. Signing, approval and Route receipt-finality timing are not included in a claimed end-to-end guarantee.
• expiresAt is bounded by Route’s observation freshness, five minutes from the provider’s quote creation, and any earlier provider expiry.
• Provider warnings are returned as bounded codes, never raw credential-bearing errors or instructions to execute.

Route applies the owner’s policy. SwapKit’s CHEAPEST, FASTEST or RECOMMENDED tags do not override it. Allowing swapkit permits that aggregator’s underlying providers; disabling a direct project connection does not exclude that provider’s liquidity inside SwapKit. Platform-wide pauses do: Garden-backed candidates are unavailable while Garden is paused. The underlying providers are disclosed on each candidate.

Failure and execution boundaries#

Connection checks authenticate a dry quote request. A successful check verifies access, not every pair. Quote failures remain isolated from other providers: examples include SWAPKIT_ACCESS_DENIED, SWAPKIT_PAIR_UNAVAILABLE, SWAPKIT_RATE_LIMIT, SWAPKIT_UNAVAILABLE and INVALID_SWAPKIT_RESPONSE.

Price comparisons call only SwapKit’s /v3/quote. Route does not follow returned nextActions URLs, build transactions, allocate deposits, sign, broadcast or move funds during comparison. During payment preparation, Route calls /v3/swap once after saving an allocation claim. The same database transaction saves the preparation and reserves its Route credits and API-key USD budget, valued at a fresh source price. INSUFFICIENT_CREDITS, KEY_RESTRICTION, KEY_VALUATION_REQUIRED or KEY_BUDGET_EXCEEDED returns before any SwapKit call; nothing is allocated and the draft can still be cancelled. It binds the returned channel, recipient, assets, amount and minimum output, then reconstructs a supported deposit with current wallet nonce and gas. Use the ordinary /prepare → /transaction → signature → /execute flow described in protocol execution.

If the build response is lost or fails validation, SWAPKIT_ALLOCATION_NEEDS_REVIEW preserves the existing attempt. Retrieve the payment’s providerAllocation; retry only the same preparation. Route can reconcile a captured response without calling /v3/swap again. An unknown provider identity requires operator review and cannot be automatically replaced. providerAllocation.responseCaptured distinguishes a saved response from an unknown outcome. Initial build errors can include error.details.providerHttpStatus and an allowlisted providerCode; these diagnostics do not prove that no channel was created. Allocated payments cannot be archived or cancelled as unused drafts.

Until its deposit instructions are attached, the preparation has deposit: null and a preparation-pending blocker, and it keeps its credit and API-key holds. A SwapKit quote that expires before the claim is made is refused with QUOTE_EXPIRED, SWAPKIT_QUOTE_REQUIRED or SWAPKIT_QUOTE_EXPIRED before anything is reserved. A draft whose quote expired is refused with QUOTE_EXPIRED first. One outcome proves that no channel exists: SwapKit's definite refusal, a 400 naming insufficientBalance, insufficientGas, outputBelowPublishedFloor or outputAmountDeviationTooHigh with no swap. POST /prepare then returns 409 SWAPKIT_BUILD_REFUSED, and the same transaction releases the payment's credit and API-key holds. providerAllocation.state becomes refused with its refusal, the payment stays PREPARING without lastError, and next-action returns prepare-payment until the quote deadline in providerAllocation.expiresAt. Fix the cause, for example by funding the source wallet, then call /prepare again with the same wallets under any Idempotency-Key. Route reserves again before it calls SwapKit, and a refused reservation calls nothing. After the deadline, cancel the payment and start from a fresh quote; a refused build does not block cancellation. A composed leg's refusal keeps its holds and is handled as uncertain.

After the claim, every other outcome keeps the holds: a failed build, an unknown outcome, or a channel that expires before deposit instructions are attached. A failed or missing response does not prove that no channel exists, and there is no release endpoint. A failed attempt after the claim sets the preparation to needs-review with lastError, so the payment reports REQUIRES_ATTENTION and webhooks receive payment.requires_attention. A request that finds another request's build still in progress leaves the preparation unchanged. If a build is interrupted, the preparation stays preparing until a later retry records it.

A /prepare with the same wallets resumes only a validated or accepted build. It reuses the same channel under any Idempotency-Key, and the draft’s own quote expiry no longer applies. The resume works only until the earlier of the channel’s saved quote and deposit deadlines, reported as providerAllocation.expiresAt; after that, next-action returns review-required for operator reconciliation. A changed build goes to quote review instead. A validated channel saved without a preparation, possible for payments prepared before holds moved ahead of the build, resumes the same way; its credits and budget are checked when its deposit instructions are attached.

Tracking treats SwapKit completion and refund hashes as hints. Route verifies the source deposit and the final recipient’s chain credit, then reserves an exclusive payout claim before marking delivery or refund complete. A destination hash you supply to /refresh must match the delivery leg SwapKit reports for the saved source transfer, and undergoes the same chain verification. The original credential source is required. A supplied refund hash must also be the refund leg that SwapKit reports; see removing a provider key. Provider status alone does not complete the payment. Bitcoin payouts require the reviewed confirmation threshold. For SwapKit’s NEAR Ethereum ERC-20 → BTC path, a returned fee reserve can make the actual payout exceed the reported amount. Route accepts that difference only after verifying the signed underlying quote and the exact NEAR bridge allocation. Otherwise the payment remains in verification. EVM native destination assets remain quote-only because internal contract payouts need an additional verifier. Native-source refunds can be verified when returned as a direct transfer. To have Route verify a known refund transaction, send it as refundHash to POST /payments/{id}/refresh (SDK: refresh(id, {refundHash})); the hash is only a hint.

References: API overview, quote and swap flow, SDK documentation.

Reviewing changed SwapKit terms#

If POST /payments/{id}/prepare returns SWAPKIT_ALLOCATION_NEEDS_REVIEW, retain the payment and its original preparation request key. The provider may already have created a deposit channel.

1. Check providerAllocation.responseCaptured. If false, the build outcome is unknown: preserve the original payment and ask an operator to establish its allocation outcome. Do not request another build. When true, read GET /payments/{id}/quote-review. When the captured response is valid, Route returns the original and updated minimum receipt, expected receipt, provider fees, expiry and a reviewHash.
2. Show those values to the payer. After explicit acceptance, call POST /payments/{id}/quote-review with an Idempotency-Key and { "reviewHash": "<returned hash>", "minimumReceived": "<returned minimum>" }.
3. Retry /prepare on the same payment, using its original wallets and preparation request key. Route uses the accepted terms, rebuilds the wallet action and rechecks the current policy, balances and gas. Sign and submit through the normal transaction flow.

Acceptance neither signs nor submits a transaction. Route retains the original quote, captured provider response and accepted revision; it never requests a second channel for this review. The dashboard provides Review saved quote and Accept updated terms actions.

This recovery applies before deposit instructions or a wallet action have been saved. Acceptance changes only the reserved preparation’s minimum receipt and provider quote; its credit and budget holds are unchanged. It does not extend provider deadlines or waive identity, slippage, warning, policy or fee checks. An unknown build outcome, expired channel, changed recipient or provider warning still requires reconciliation. Do not automatically create a replacement payment or deposit.

Auto-route and execution checks#

SwapKit quotes can participate in Auto-route plans. Supported SwapKit simple deposits can execute as legs; Garden is excluded while paused. Every leg must have a released builder and receipt verifier before the complete plan can execute.

Allbridge and Axelar on Stellar#

Stellar requests now perform live Allbridge registry checks and Axelar ITS contract reads. They are no longer excluded merely because one network is Stellar. details distinguishes registry exclusions, token-registration results, actual fee requests and remaining Route capabilities.

Axelar checks verified registrations for Ethereum USDC ↔ Stellar USDC.ITS, and native Stellar XLM ↔ Ethereum XLM.ITS. The catalog exposes these exact representations as separate choices. Stellar USDC.ITS is a six-decimal Soroban token (kind: "soroban"); it is not Circle's native seven-decimal Stellar USDC. Do not substitute assets by ticker. Each quote rechecks canonical token linkage, precision, hub trust, pauses, flow limits and applicable destination inventory before requesting relay fees. A registered path can be blocked by current inventory: a recorded 1 XLM.ITS → Stellar XLM check was blocked for that reason. Other networks without an integrated chain reader remain explicit capability limitations. Other token pairs need their own verified registration.

Axelar relay fees use the source network's native currency (ETH or XLM). EVM source gas is attempted using exact token and destination call history; missing samples and Stellar Soroban fees remain explicit gaps. Full arrival ETA may remain unresolved; owner delivery policy determines whether that blocks execution. Fresh Soroban simulation replaces modeled source fees during preparation. ITS representations do not automatically inherit their underlying asset's USD price, so valuation may also remain unknown.

The last verified Allbridge registry lists Stellar USDC but publishes no active Stellar CCTP v2 deployment. Its implemented EVM execution uses the legacy CCTP V1 path; migration remains an open compatibility task. The last verified Ethereum ↔ Stellar fee requests received a provider rejection. Its contract documentation says pool transfers were discontinued. Route reports that upstream limitation and does not revive deprecated pool routes. A future successful fee response still requires matching active deployments and exact assets before a quote is returned.

Bitcoin wallet actions#

For a supported SwapKit Bitcoin source, the existing protocol payment flow returns a base64 PSBT in transaction.psbt and its exact input list in transaction.inputs. The nested transaction.transaction retains the same Bitcoin payload. Sign the saved transaction with a single-key native SegWit or Taproot wallet and return a finalized base64 PSBT or raw transaction hex at /transaction/signature. Route verifies every input, output and signature before its single submission attempt. No NEAR intent-message signature is required for a SwapKit payment.

Route checks confirmed, unspent inputs, reserves them across providers, returns change to the sender, and estimates the network fee from the actual transaction. A spent input, expired channel or higher required fee blocks the unchanged saved action. Do not replace an uncertain payment automatically. Source finality and independently verified delivery are separate tracking steps. A provider's completed status alone cannot mark a payment complete.