One-off Offramp (Single USD Payout)
Use a one-off offramp when you need a single USD payout — a vendor invoice, a customer refund, a scheduled disbursement — and want to embed a human-readable reference on the bank wire. One-offs generate a single-use crypto deposit address that’s discarded after the transaction completes. What one-off offramps give you over a reusable offramp account:-
payment_reference— text carried into the bank wire. Per-rail constraints:- ACH — 1 to 18 chars. Letters, digits, and spaces only (no hyphens or punctuation). Delivered as the ACH addenda.
- Wire (Fedwire) — 1 to 140 chars. Delivered as the wire message.
- SWIFT — 5 to 140 chars across at most 4 lines of 35 characters. Letters, digits, spaces, and
/ - ? : ( ) . , ' +only (the SWIFT character set, so hyphens are allowed). Carried as the wire’s remittance information; whether the payee sees it depends on the receiving bank and any intermediaries, so do not rely on it for payee-side reconciliation.
-
destination_payment_rail— override the rail per transaction (e.g. forcefedwireinstead of the destination’s defaultach). -
developer_fee_bpsordeveloper_fee_fixed— developer fee for this transaction, as a percentage in basis points or as a fixed amount in the deposited asset. Send one or neither; omitted means no developer fee. The rate is returned when you read the one-off transaction (developer_fee_bpsis0when none was set, anddeveloper_fee_fixedis present only when you set it), and the fee actually charged appears asdeveloper_feein each transaction’sreceipt(client_feeis its deprecated alias, with the same value). See Developer Fees.
Create the One-off Transaction
Prerequisite: a bank Destination (destination_type: "fiat_us") already attached to a Recipient for this Customer — see Add a Bank Destination.
crypto_address. You choose the amount — Dakota does not return a deposit quote to send against — and Dakota converts what arrives and wires the proceeds to the bank Destination with INV 2024 042 included as the payment reference. Subscribe to transaction.one_off.created and transaction.one_off.updated to track status.
amount on the request is the destination amount you expect. It is optional and used for validation — it does not determine how much you send. When omitted, Dakota still converts and delivers whatever you deposit.
Reconcile against receipt.output. It reports what Dakota sent to the destination. Do not reconcile against the destination_amount field on transaction.one_off.* events: that echoes the amount you requested (or 0 if you omitted it) and is never updated to the delivered figure. On the swift rail, the beneficiary’s bank and intermediary banks can deduct their fees from the wire, so the beneficiary can receive less than receipt.output. See SWIFT Payouts.
The request above sets no developer_fee_bps, so nothing is deducted and a 1,250.00 USDC deposit converts in full. When you do set one, it is taken from your deposit before conversion and so reduces what reaches the destination: at 25 bps, a 1,250.00 USDC deposit gives up 3.125 USDC, leaving 1,246.875 USDC to convert and wire. Dakota’s own fee is billed separately on your invoice and is not taken out of the deposit. To have a destination receive an exact amount, size the deposit to cover the developer fee yourself. With a fixed fee that is simply amount plus the fee; see Fixed fees on one-off transactions. In each transaction’s receipt, developer_fee is the developer fee that was deducted (the deprecated client_fee carries the same value) and dakota_fee is the separately-billed amount, recorded for reference.
SWIFT Payouts (International Wire)
See Foreign exchange (FX) for currencies, availability checks and quote examples. SWIFT is Dakota’s international wire rail. Use it to pay recipients whose bank accounts are outside the US domestic rails (ACH, Fedwire, FedNow). SWIFT payouts support USD and foreign currencies. Foreign-currency (FX) payouts require FX access to be enabled for the account and are priced by quote: callGET /customers/{customer_id}/fx-currencies to see which currencies are available and POST /fx/quotes to price one. Fixed (rate-locked) quotes are available on request and are not generally available yet. In sandbox, FX access is enabled for every client (see FX Access). SWIFT payouts settle in 1–3 business days, and is gated on the customer’s international_wire capability. If your customer does not have that capability, contact Dakota support.
Bank fees are taken out of the wire. Bank charges on an international wire are deducted from the amount sent, so in effect the sender pays them. The beneficiary’s bank, and any intermediary bank on the route, take their fees out of the wire, and the beneficiary receives less than
receipt.output. Dakota does not control these deductions and is not told about them: they do not appear in receipt.external_fee, and the transaction completes as sent. If the beneficiary must receive an exact amount, allow for the charges when you size the payout.Currency availability
Check the Customer’s available currencies before requesting a quote. See Check available currencies for the request, response and quote-mode fields.Availability by jurisdiction
SWIFT, and FX on SWIFT, is not available everywhere. Whether a customer can use it depends on where the customer is based and where your organization (the client the customer belongs to) is based. Dakota does not publish the list of affected jurisdictions, and a refusal does not say which jurisdiction caused it. Check before you build the flow: callGET /customers/{customer_id}/fx-currencies?direction=outgoing for the customer (direction=incoming for SWIFT deposits).
200: the customer passed the jurisdiction check for this request. The list reports current foreign-currency availability for the requested direction and omits currencies not offered where they are based. An emptycurrenciesarray means no foreign currency is currently reported; it does not guarantee that USD SWIFT is configured or available. A200does not mean the customer’s SWIFT setup is complete: check theirinternational_wirecapability withGET /customers/{customer_id}/capabilities. Quote and payment checks still apply.403with typecapability-unavailable: SWIFT is not available to the customer. Creating a SWIFT account or one-off payout, or requesting an FX quote, returns the same error.
503 with type eligibility-unavailable usually means Dakota could not check availability at that moment; retry with exponential backoff. On the FX quote endpoints the same type is also used when quotes cannot be served for the account, for example "detail": "The account is not provisioned for FX quotes.". Retrying does not fix that; contact Dakota support if it persists.
This check covers where the customer and your organization are based, not where the money is going. Each payout is still screened when it is sent, and screening can refuse a payout to a particular beneficiary.
Set up a SWIFT offramp
- Create a Recipient with a physical address. An address is required before adding any fiat destination — see Destinations & Recipients.
- Add a
fiat_ibanDestination to the Recipient withcapabilities: ["swift"]. Includeiban,account_holder_name,account_holder_address,bank_name, andbic.bank_addressis required wheneverbicis provided. See the IBAN destination fields. - Create the offramp Account pointing at that destination:
source_crypto_address triggers a USD SWIFT wire to the IBAN destination. For a single payout instead of a reusable account, create a one-off offramp with destination_payment_rail: "swift".
SWIFT for onramps
SWIFT also works as an inbound rail. Includeswift in capabilities when creating an onramp account; this narrows the account to SWIFT deposits. The returned bank_account deposit instructions then carry the BIC and the beneficiary’s postal address (account_holder_address) — give the sender both, along with the account details. The sender’s bank asks for the beneficiary address on international wires, and the sender must copy it exactly as shown.
Dakota does not charge for receiving a SWIFT deposit. Banks on the route can still deduct their fees before the wire reaches Dakota. The deposit is booked for the amount that arrives, so the transaction can be smaller than the amount the sender wired.
SWIFT caveats
- Bank fees reduce the amount received. See the note at the top of this section. The deductions are not reported to Dakota and are not in the receipt.
payment_referencedelivery is not guaranteed. The reference is carried as the wire’s remittance information; whether the payee sees it depends on the receiving bank and any intermediaries. Constraints: 5–140 characters across at most 4 lines of 35 characters; letters, digits, spaces, and/ - ? : ( ) . , ' +only (the SWIFT character set, so hyphens are allowed).rail,capabilities, and destination routing are immutable after account creation.PATCH /accounts/{account_id}only updates the developer fee (developer_fee_bpsordeveloper_fee_fixed); a request that changes a routing field returns501. To add SWIFT for an existing customer, create a new account withrail: "swift".- Returns carry no NACHA code. An international wire return may come back as a reduced amount after intermediary fees, without an
R-code.
One-off Swap (Single Cross-Chain Swap)
Use a one-off swap when the target network varies per swap (a reusable swap account pinsdestination_network_id) or you want to apply a different developer fee (developer_fee_bps or developer_fee_fixed) on this specific swap. payment_reference and destination_payment_rail are offramp-only and do not apply to swaps.
Create the One-off Swap
Prerequisite: a crypto Destination on the target network/asset already attached to a Recipient — see Add a Crypto Destination.crypto_address. You choose the amount — Dakota does not return a deposit quote to send against — and Dakota converts what arrives and delivers the destination asset on the target network. Same transaction.one_off.* webhooks as one-off offramp.
amount on the request is the destination amount you expect, and is optional. When omitted, Dakota still converts and delivers whatever you deposit. As with offramps, reconcile against receipt.output rather than the destination_amount on the event, which only echoes what you requested.
The developer_fee_bps above is deducted from your deposit before conversion — at 25 bps a 500.00 USDC deposit gives up 1.25 USDC, leaving 498.75 USDC to swap — so size the deposit accordingly if the destination must receive an exact amount. With developer_fee_fixed instead, send amount plus the fee. Dakota’s own fee is billed separately rather than taken from the deposit.
One-off transaction lifecycle
Both one-off offramps and one-off swaps share the sameOneOffTransactionStatus values and the same lifecycle rules. Inspect status on the transaction object or on each transaction.one_off.updated event to drive your own state machine.
pending_return, returned, pending_reversal, and reversed only apply to one-off offramps (the bank leg). They do not appear on one-off swaps, which are crypto-to-crypto. This mirrors the general Transaction lifecycle — one-offs surface pending as their initial status rather than not_started.
Cancel a one-off transaction
CallPOST /transactions/{transaction_id}/cancellations to cancel a one-off transaction that has not yet delivered. A successful cancellation returns 204 No Content and the transaction moves to cancelled. Cancellation is only meaningful before Dakota starts settling the outbound leg — in practice, while the transaction is still in pending and no deposit has arrived at crypto_address.
The endpoint returns 400 Invalid request or transaction cannot be cancelled when the target transaction is not in a cancellable state — for example, when it has already reached a terminal status (completed, failed, cancelled, returned, reversed) or is far enough along that the outbound leg can no longer be halted. The detail field on the problem response carries the specific reason. See Errors for the response shape.
One-off requests do not accept a return_address (unlike reusable offramp accounts, which do). If a deposit lands on a crypto_address for a one-off that has already been cancelled, contact Dakota support with the transaction id to reconcile — the cancellation endpoint does not itself handle recovered funds.
Failed, returned, and reversed one-offs
For terminal non-success statuses, the fields on theOneOffTransaction object are your source of truth:
failed— readfailure_reasonfor the cause.returned— switch onfailure_code: the code mapped from the bank’s return code when there is one, otherwisepayment_returned.return_code(e.g.R01) is the bank’s own code when it sent one,return_reasonis Dakota’s message, andreturn_deadlineis the ACH return window.reversed— either an ACH originator reversal (reversal_reason, e.g.duplicate,receiver_incorrect, andreversal_initiated_at) or a returned payout that was refunded to the source wallet. A refunded return hasfailure_codeset and noreversal_reason(except payouts returned before this behaviour shipped in October 2026, which may carry nofailure_code).
Returned SWIFT payouts
An international (SWIFT) payout that the receiving bank returns moves toreturned, and then to reversed once the returned funds are refunded to the source wallet. SWIFT returns are not refunded automatically, so the payout can stay at returned until Dakota makes the refund. There is no separate refunded status.
On both statuses the payout carries failure_code (the code mapped from the bank’s return code, or payment_returned when there is none or it does not map) and return_reason. reversal_reason stays empty. Payouts returned before this behaviour shipped (October 2026) may carry no failure_code.
The bank or an intermediary can deduct a fee from the returned funds, and the customer bears that deduction. net_recovered_amount is set when the refund is made, and only when the return came back short: it is the face amount less the deduction, in the same units as send_amount. On returned it is absent whatever came back, so its absence there says nothing about the amount. On a reversed payout that was a bank return, its absence means nothing was withheld.
In sandbox, a returned SWIFT payout can end in one of two ways, depending on which bank leg carried it. Some are refunded automatically, without operator action: the payout moves to returned and then to reversed, with failure_code: payment_returned. Others stay at returned and are not refunded automatically, the same as in production, where Dakota operations resolve them. A SWIFT payout in a currency other than USD always stays at returned. For a USD SWIFT payout, the outcome is not something you can choose or predict from the request, so do not assume either one: act on the status and the transaction.one_off.updated or transaction.auto.updated webhook you receive, and do not wait for reversed on a payout that has settled at returned.
failure_code is not a status. Use status for the outcome; a payout that completes after a return (for example a resent wire) has no failure_code and no return fields.
Unlike a reusable offramp account, a one-off transaction has no return_address on the create request. If a one-off ends in returned or reversed and you need to reconcile the recovered value, contact Dakota support with the transaction id.
Developer Fees
A developer fee is your cut of each deposit to an account or one-off transaction. Dakota takes it from the deposit before conversion. Dakota’s own fee is billed separately on your invoice and is not taken out of the deposit. A fee is either a percentage or a fixed amount:- Send one or the other. A request that sends both is a
400, even when one of them is0. - Setting one on update replaces the other.
PATCH /accounts/{account_id}withdeveloper_fee_fixedswitches a percentage account to a fixed fee, anddeveloper_fee_bpsswitches it back. APATCHthat sends neither leaves the fee as it is. - Changes apply to future deposits only. Transactions already created keep the fee they were created with.
- Omit both to charge no fee. To remove a fixed fee from an account, set
developer_fee_bpsto0.
POST /accounts) or a one-off transaction (POST /transactions), and change it on an account with PATCH /accounts/{account_id}. A one-off’s fee can’t be changed after creation.
Fixed fees are charged in the deposited asset
developer_fee_fixed has no currency of its own. It is charged in units of the asset deposited to the account, and it is never converted between currencies:
- It must be greater than
0and have at most 2 decimal places."10","10.5"and"10.00"are all valid. - There is no upper limit.
- The same value means a different amount on accounts that receive different assets.
"10.00"is 10 USDC on a USDC deposit, 10 USD on a USD bank deposit and 10 EUR on a EUR bank deposit.
For example, this offramp account charges 10.00 USDC on every USDC deposit:
GET /accounts/{account_id} returns the same fields. developer_fee_bps is 0 on a fixed-fee account. developer_fee_fixed and minimum_deposit are absent on an account that charges a percentage or no fee.
Minimum deposit
A fixed-fee account only converts a deposit that leaves something after the fee.minimum_deposit is developer_fee_fixed + 0.01, in units of the deposited asset. On the account above it is "10.01", so a 10.01 USDC deposit converts 0.01 USDC.
Crypto deposits must be USD-pegged stablecoins
On a fixed-fee account, a crypto deposit must be a USD-pegged stablecoin, such as USDC or USDT. If a fixed-fee account receives any other crypto asset, Dakota doesn’t charge the fee: it holds the deposit for review, and nothing is converted until the review is done. Percentage fees have no such restriction.Fixed fees on one-off transactions
On a one-off transaction,amount is the destination amount you expect, not the amount to deposit. The fixed fee is taken from whatever is deposited, so the depositor sends the destination amount plus the fee. Dakota doesn’t check amount against the fee when you create the one-off, for any pair of assets. A small payout with a larger fee is accepted.
For example, a USDC → USD one-off offramp with amount 5.00 and developer_fee_fixed 10.00:
crypto_address. Dakota takes 10.00 USDC as your fee and delivers 5.00 USD. The one-off returns developer_fee_fixed when you read it, but not minimum_deposit. A deposit that doesn’t cover the fee plus 0.01 is not converted; contact Dakota support to recover it.
Where fixed fees are available
A fixed fee isn’t available on every account. When an account or one-off can’t charge one,developer_fee_fixed is refused with a 400:
developer_fee_bps on that account instead. The same error is returned when you PATCH an account that can’t charge a fixed fee.
Agentic payments also take developer_fee_bps or developer_fee_fixed, in developer_fee_defaults or on a create_auto_account action, and the same restriction applies to them. By default a payment’s amount is what the payee receives, so either kind of fee is added on top. See the conversion fee.
The fee charged
The fee actually taken from each deposit appears asdeveloper_fee in the transaction’s receipt, in the deposited asset. client_fee is its deprecated alias, with the same value. On the EUR onramp above, GET /transactions/{transaction_id} returns:
transaction.* webhooks, each fee is a flat decimal string instead of an object; see Fee fields in the receipt.
Fee payouts
Developer fees charged in EUR are held and not paid out automatically. To arrange a payout of EUR fees, contact Dakota support.Set the fee in the dashboard
You can also set the developer fee when you create an onramp, offramp, swap or one-off transaction in the Dakota dashboard. The create form has a Developer fee selector with three options:
The form sends only the option you picked, never both fields. The fixed amount is charged in units of the deposited asset, as described above. If the account can’t charge a fixed fee, creation fails with the
developer_fee_fixed is not supported for this account error; choose Percentage instead.
The detail drawer of an onramp, offramp or swap account shows a Developer Fee row: the percentage with its basis points (for example 0.5% (50 bps)), the fixed amount with its asset (for example 10.00 USDC), or None. Fixed-fee accounts also show a Minimum Deposit row, such as 10.01 USDC. A one-off offramp’s drawer shows the Developer Fee row only when a fee was set.
To change the fee on an existing account, use PATCH /accounts/{account_id}.
Developer fee errors
Each error is a400 invalid-request problem. The detail is one of these messages, where the quoted value is the one you sent:
developer_fee_fixed is checked in the order listed. Exponent notation ("1e1"), a leading +, a trailing or leading ., and surrounding spaces all get the decimal-string error. developer_fee_bps keeps its existing validation (an integer from 0 to 10000).