How to accept naira and settle in USDC or USDT

To accept naira and settle in a stablecoin you need four things: a naira account number for each customer, a locked exchange rate, a conversion, and a chain that lets you withdraw the asset you picked. Daya API charges 1% capped at ₦100 on the naira deposit, plus $0.10 to send the stablecoin out.

That last one is where this usually goes wrong, and it has nothing to do with price. A chain that accepts a USDC deposit doesn't necessarily let you send USDC back out. Daya API charges 1% capped at ₦100 on an incoming naira deposit, against 1% capped at ₦1,000 on a Fincra virtual account collection. Every figure here comes from each provider's own documentation, read on 23 October 2026.

What are the steps to accept naira and settle in a stablecoin?

The flow has four steps and they run in a fixed order, because each one needs something the step before it produced. You create a customer, you lock a rate, you create a funding account that gives you a naira account number, and then you wait for a webhook telling you the money landed and settled.

1. Create the customer. Every naira collection belongs to one of your end users, and a reusable naira account number needs that customer verified to Tier 1, which means basic identity details rather than uploaded documents.
2. Lock a rate. A rate is a quote with an expiry on it. On Daya API a new rate is generated roughly every 10 minutes and expires about 30 minutes after it's created, and you pass its id into the next step.
3. Create the funding account. This is the call that returns the bank details your customer pays into: bank name, bank code, account number and account name. You tell it the asset and the chain you want the money to arrive as.
4. Show the exact amount, then wait. Display the amount the response gives you rather than the amount you asked for, because a payment provider's collection charge can change it. Then listen for the webhook.

A webhook is a message the provider posts to your server when something happens. The ones that matter here are the event saying the funding account is active, which is your signal to show the naira details, and the three deposit events that track the money as it arrives, gets processed and completes.

One thing worth knowing before you build the handler: on Daya API the deposit webhook doesn't carry the exchange rate you got, the chain, or the transaction hash. Those sit on the deposit record itself. So a completed webhook is a signal to go and fetch the deposit, not a receipt you can file.

Which chains can you withdraw USDC and USDT on?

USDC comes out on three chains and USDT comes out on four, and they barely overlap. Daya API's own list has USDC withdrawals on Base, Solana and Aptos, and USDT withdrawals on Polygon, BNB Smart Chain, Solana and Aptos. The deposit side is far wider than that, which is exactly what catches people.

Read the two withdrawal columns next to each other and the trap is plain. USDC can leave on Base but not on Polygon or BNB Smart Chain. USDT can leave on Polygon and BNB Smart Chain but not on Base. So a build that collects naira and settles USDC on Polygon will pass every test you write against the deposit side, and then fail at the moment it tries to send the money.

What it means for you: pick the asset and the chain together, and check that pair before you ship anything. Daya states its supported-chains list, and the same data comes off a public endpoint that needs no API key, with a deposit flag and a withdrawal flag on every entry. The withdrawal flag is the one that governs this job. The documentation also says not to hard-code the table, which is good advice for any provider, because the list moves.

Two smaller things off the same list. USDC and USDT run to 18 decimal places on BNB Smart Chain and 6 on Polygon, so an amount formatted for one chain is wrong by a factor of a trillion on the other. And the sandbox runs on Ethereum only, with USDT withdrawals switched off there, so a USDC settlement can be rehearsed end to end and a USDT one can't.

Which providers document a naira-in, stablecoin-out path?

Two providers describe the whole path on their own pages, and Daya API is one of them. Yellow Card documents it as Direct Settlement, with a Nigerian sample in its docs. Daya API documents it as on-chain settlement on a naira funding account. HoneyCoin advertises it and publishes no figures.

Yellow Card is the one to look at properly if you're shortlisting. Its Direct Settlement documentation sets a flag on a collection so that one transaction takes local currency in and sends crypto out, and its sample uses NGN and Nigeria rather than a generic example. Its naira collection limits are published too, at ₦2,500 minimum and ₦30,000,000 maximum per transaction. What it doesn't publish is a price list or a per-chain, per-direction support table, so you find out what a settlement costs by calling its fee endpoint with a signature.

The rest of the set stops short of one leg. Kora's stablecoin documentation covers customers sending USDT or USDC in from their own wallets, which is the opposite direction to this job. Fincra documents naira collection thoroughly and no stablecoin settlement at all, and its real price list is a spreadsheet linked from the pricing question in its docs FAQ. Bridge's overview names US dollars to USDC and euros to USDT and doesn't mention naira. Busha's fee page is an exchange schedule rather than a collections product, though it's useful for pricing the send leg: USDC out on Base is 0.1 USDC and on Ethereum it's 3 USDC.

What does it cost to turn a naira payment into a stablecoin?

On Daya API, ₦100,000 collected and settled on chain costs ₦100 on the deposit and $0.10 to send, because the 1% deposit fee caps at ₦100 and the default crypto withdrawal fee is $0.10. The cap is the part that matters: above ₦10,000 the naira fee stops growing.

The published figures on the naira-in, stablecoin-out path are these:

• 1% on an incoming naira deposit, capped at ₦100.
• $0.10 to send a stablecoin out on most chains, $0.20 on Ethereum and $1.00 on Tron.
• ₦20 flat on a naira payout below ₦1,000, and otherwise 1% capped at ₦100.
• A minimum deposit of about $1 in naira, a $10,000 ceiling per deposit, and a rolling 24-hour limit of $1,000,000 per merchant.

Set against that, Fincra charges 1% capped at ₦1,000 on a naira virtual account collection, so the collection leg alone costs ten times as much once both caps bite. Kora publishes no schedule, and the single figure in its stablecoin documentation is a worked example in which a 25 USDT deposit carried a 1.5 USDT fee. Yellow Card hands its fees back from a signed API call instead of printing them, which means you can't price a Yellow Card build without credentials.

The fee is the small number here, though. A 1% deposit fee capped at ₦100 is ₦100 on a ₦1,000,000 collection, and one per cent of difference in the rate you settle at is ₦10,000 on the same money. So compare the dollars that land rather than the fee line, and ask every provider on your shortlist what rate it settles at and how long that rate holds.

Where does Daya API fit?

Daya API is the naira collection and stablecoin settlement part of a money product, and it states both the price and the chain list. 1% capped at ₦100 on an incoming naira deposit, $0.10 to send the stablecoin out, USDC and USDT, and a public endpoint saying which chains take deposits and which allow withdrawals.

• A naira account number for each customer, temporary for a one-off payment or permanent for a reusable one.
• On-chain settlement that converts the naira and sends the stablecoin to a wallet address you set on the funding account.
• A locked rate on a temporary account, which executes with no slippage once the customer pays inside the window.
• Deposit webhooks for each stage, and a deposit record carrying the rate, the settled amount, the chain and the transaction hash.
• A sandbox with its own key and a call that simulates a naira deposit, so you can drive each outcome on demand.

Where Daya API isn't the pick: there's no hosted checkout or drop-in widget, so the naira payment screen is yours to build, and Yellow Card and Fincra both ship one. If your product collects in several African currencies rather than naira alone, Fincra documents the longest currency list in this set and Yellow Card covers the most countries. If your users send stablecoins in from their own wallets instead of paying naira, Kora documents that direction specifically. Pick on the leg you actually need, and read the withdrawal side of the chain list before you commit to an asset. The comparison of naira on-ramp and off-ramp APIs runs the same providers side by side on the wider job.

What breaks this integration once real money is moving?

The failures are operational rather than technical, and four of them account for most of what goes wrong: a rate that expired before the customer paid, an amount that didn't match, a webhook treated as the whole record, and a retry that created a second resource. All four are documented, which means all four are avoidable.

1. The rate expired. On Daya API a rate lives about 30 minutes and can't be extended, reused or applied after the fact. A payment arriving after that doesn't settle on its own; the deposit is held for manual review instead. Keep the payment window you show the customer shorter than the rate.
2. The amount didn't match. A temporary naira account expects the exact amount the response gave you. Underpay and the money goes back to the sender with no deposit created and no webhook fired, so your system sees nothing at all. Overpay and the correct amount settles and the rest is refunded. With some banks a mismatch fails the whole transaction instead of refunding part of it.
3. You credited a user straight from a webhook. Daya's documentation is direct about this: the partner keeps its own end-user ledger, and you credit from the customer amount on the deposit rather than the gross figure. Events can arrive more than once and out of order, so your handler needs to deduplicate on the event id and reconcile against the latest state.
4. A retry created a second account. The create calls take an idempotency key, which is a string you generate so the provider can tell a retry apart from a new request. Keys are kept 24 hours by default, so a retry the next day can make another resource. And retrying an expired request returns the original details rather than renewing them.

What it means for you: build the reconciliation job at the same time as the happy path, not after launch. Daya's partner integration guide says to reconcile webhook state, API state and your own ledger against each other, and to poll and check before anyone intervenes by hand. That's the job that stops a stuck payment becoming a duplicate one.

How do you test the whole path before you go live?

In the sandbox, with a call that pretends a customer paid. Daya API has a separate sandbox address and its own key, and a sandbox deposits call fires a simulated naira payment against a funding account you created. You pass it a scenario and it drives the webhooks for you: completed, processing, requires review, or failed.

• Fetch a fresh rate first. The sandbox flags a deposit when the rate has expired, the same as production does.
• Create the funding account and trigger the deposit straight away, because a second deposit against the same temporary naira instruction gets flagged too.
• Use the test bank details the documentation lists, and resolve each account number through the banks call before you use it.
• Know the gap. The sandbox is Ethereum only and USDT withdrawals are off there, so a USDT settlement can't be rehearsed end to end.

Do you need a licence to collect naira and pay out a stablecoin?

That turns on whether you're holding and converting the money yourself or routing it through a provider that does. It's a real question with a real answer and it's covered properly in two places already: the guide to building a crypto on-ramp in Nigeria sets out what registration with the Securities and Exchange Commission involves and what the alternative route looks like, and the comparison of naira on-ramp and off-ramp APIs covers who needs what.

What it means for you: settle that question before you write the integration rather than after. The technical work in this piece takes a few days, and the regulatory answer can change what you're allowed to build with it.