It is a Tuesday morning. Your operations lead opens the payout dashboard and finds a payment to a supplier in Lagos sitting at failure. The beneficiary account number had a digit wrong. Nothing dramatic. The fix is obvious: correct the account, send it again, move on.
From 7 September 2026, that instinct became an expensive move.
Not because of the account number. Because of when Fincra converts your money, and what that means for where the money is when something goes wrong. This piece walks through what is changing, why it matters, and the one habit your integration needs to unlearn before the switch flips.
A payout you think of as one thing is actually two
Every cross-currency payout does two jobs. It converts your money into the destination currency, and it sends a bank transfer in that currency to your beneficiary.
When both jobs succeed, nobody needs to care about the distinction. You send NGN, your supplier receives KES, and the internals stay internal.
The distinction becomes very visible the moment the second job fails while the first one has already worked. At that point your money exists, it is yours, and it is not where your integration expects it to be. Everything below is about that gap.
How it works today
Right now, Fincra converts your money and then sends the transfer. If the payout fails at any point, the money comes back to your source wallet. You fix whatever caused the failure and send the cross-currency payout again.
One retry path covers every failure. Your webhook consumer sees a failed payout, your reconciliation expects the source balance to be restored, and it is. Nothing to branch on.
The trade-off, and it is a real one, is that every failure sends you back to the start of the FX process. The rate you were quoted is gone with it.
What changes on 7th September
Fincra moves the conversion to the last step before the transfer. Once the conversion succeeds, it is final.
The gain is rate certainty. You keep the rate you were quoted, whatever the transfer does afterwards. The trade-off is that a transfer can now fail after your money has already been converted. When that happens the money does not come back as source currency. It sits in your destination-currency wallet, at your quoted rate, waiting for you to do something with it.
Here is the same thing side by side:
| Scene | Today | From 7 September |
|---|---|---|
| Transfer fails after a successful conversion | Money returns to your source wallet | Money stays in your destination wallet at the quoted rate |
| Conversion itself fails | Money returns to your source wallet | Money returns to your source wallet. No change. |
| Conversion signal in the webhook | None | conversionStatus and isConversionSuccessful |
| Your move after a failure | Send the cross-currency payout again | Depends on whether the conversion succeeded |
| Approved payouts | Debit and conversion at request creation | Debit and conversion at approval |
So the failed payout on Tuesday morning is now two different situations that look identical on the dashboard, and they call for opposite moves.
The webhook tells you which one you are in
Two new fields arrive on the payout webhook. conversionStatus reads successful or failed. isConversionSuccessful reads true or false. Read them next to the payout status, not in isolation.
Payout failed, isConversionSuccessful true. The conversion worked, the transfer did not. Your money is in the destination wallet. Complete the payment with a new same-currency payout out of that wallet.
Payout failed, isConversionSuccessful false. The conversion did not happen. Fincra has already returned the money to your source wallet. Send the cross-currency payout again, exactly as you do today.
Same-currency payouts. conversionStatus is absent and isConversionSuccessful is null. Nothing about these changes.
This is the part that catches teams the first time. The payout says failed and the source wallet balance has not moved, so the natural read is that nothing happened. Something did happen. The money is one wallet to the right.
Completing the payment
- Confirm the payout actually failed. A timeout is not a failure, query the payout again by customerReference before you act. Acting on a timeout is how you pay a beneficiary twice.
- Read isConversionSuccessful. True means the money is in your destination wallet.
- Send a new payout from that wallet, in the currency you now hold, with a new customerReference.
{
"business": "{{businessId}}",
"sourceCurrency": "NGN",
"destinationCurrency": "NGN",
"amount": 100000,
"paymentDestination": "bank_account",
"customerReference": "new-unique-ref",
"beneficiary": { }
}Both currency fields carry the currency you now hold, because this is no longer a cross-currency payment. Correct the beneficiary if the account details were the problem. Leave the quote out entirely, quotes belong to cross-currency payouts only.
Why the retry is the expensive move
Back to Tuesday. The account number was wrong, the transfer failed, and the obvious move is to fix the digit and send the same request again.
Under today’s behaviour that is right. From 7 September it is not, because the first conversion already succeeded. Sending the original cross-currency request again converts a second amount out of your source wallet. The first amount stays in your destination wallet with nothing to complete it. Your supplier still has not been paid, and now you are holding two balances in two currencies instead of one clean payment.
The rule is short enough to put in a code comment:
A failure before the conversion is a retry. A failure after the conversion is a new same-currency payout.
Two smaller changes worth knowing
Your fees come back with the money. On a failed payout after a successful conversion, Fincra refunds your destination wallet the exact amount it debited, stamp duty on NGN payouts included. You are not paying for a transfer that never landed.
Approval flows debit later. If your payouts pass through an approver, Fincra now debits and converts at approval rather than at request creation. A request raised Monday and approved Wednesday takes the Wednesday debit. Your source wallet needs to be funded when your approver acts, not when your team raises the request. If your treasury runs on a next-day funding cycle, look at this one closely.
What to do before 7th September
Branch on both conversion outcomes in your webhook consumer. A consumer that treats every failed payout as a full reversal will report a source balance that is not there and hide a destination balance that is.
Check your automatic retries. If your system retries failed payouts without reading isConversionSuccessful, that is the one path that strands money. It is also the easiest thing on this list to fix.
Brief the people who reconcile. The team closing payouts every morning needs to know that failure can now mean funded, in a different wallet.
Testing opens on 7 September, the same day the change goes live.
Where the rest of the details live
This piece covers the behaviour and the decision. The full field reference, complete payloads, error cases, and wallet endpoints are in the Fincra API documentation.
If you want to walk through it against your own integration before go-live, your account manager can arrange that. Or write to [email protected] .
