How to Reconcile Marketplace Payouts Across Africa
Build a seller payout ledger that matches marketplace payables to provider records, blockchain transfers, local delivery and returned funds.
On this page
Chainalysis tracked 152 active intra-regional crypto payment corridors in Sub-Saharan Africa, up from 80, in its 2026 analysis. Measured business-like transfer value rose from US$34.3 million to US$116.5 million. These figures measure observed activity. They provide context for why finance teams need records that work across currencies, providers and destinations.
For marketplace finance teams, the question is whether a seller’s approved balance became a confirmed payment, an open liability or a reconciled return.
Reconcile the payable, payout attempt and delivery
One seller payable can produce more than one payout attempt. Give the payable a stable identifier. Assign each authorised attempt its own record and connect both to the provider’s references.
| Record | Minimum fields | Evidence |
|---|---|---|
| Seller payable | Payable ID, seller ID, gross and net amounts, currency, approval time | Order or earnings ledger |
| Payout attempt | Attempt ID, payable ID, destination, quote, fees, request time | Provider request and reference |
| Settlement | Asset, network, amount and transaction or batch reference where applicable | Provider settlement record or blockchain evidence |
| Seller delivery or return | Actual amount, currency, status, time and reference | Provider delivery or return record, corroborated where available |
A single funding or settlement transaction may cover multiple sellers. Record the allocation by payout. Finlazo’s marketplace payouts product page describes direct stablecoin and local-currency delivery. The evidence required to close the payable differs for each.
Map provider events to finance states
Separate provider acceptance, settlement and beneficiary delivery. For a local currency route, record a confirmed blockchain transfer as settlement evidence. Close the seller payable when the provider confirms delivery under the agreed evidence rules.
| Event | Finance action |
|---|---|
| Request timed out | Look up the original reference. Use the provider’s idempotency procedure before retrying. |
| Settlement confirmed, local payout pending | Keep the payable open and reserved. Check the expected delivery window. |
| Beneficiary delivery confirmed | Post the delivered amount and fees, then close the payable. |
| Payout rejected or returned | Locate the funds, record the actual return and any fee, then release or reissue the payable under policy. |
Verify webhook signatures, deduplicate deliveries and reconcile events against provider records. Stripe’s webhook documentation is one example of why implementations should plan for duplicate and out-of-order events. Confirm the guarantees of the provider actually handling the payout.
What a failed local payout looks like in practice
Take an illustrative US$250 seller payable for delivery to M-PESA in Kenya. The platform approves the payout and records its reference. In Finlazo’s marketplace payout flow, a supported stablecoin settles the cross-border leg. The local payout partner converts the value into Kenyan shillings for delivery to the seller’s wallet, where the route is enabled.
Suppose settlement confirms, but the local partner rejects the wallet credit. Record the settlement reference and the failed local attempt. The seller’s US$250 payable stays open and reserved while operations locates the funds.
| What operations learns | What to record | When to act |
|---|---|---|
| The local payout is still pending | Keep the payable reserved and record the provider’s reference. | Check the original instruction before sending another. |
| The provider confirms a return to the funding balance | Record the amount and currency actually returned, plus any fee or FX difference. | Release the reserve or approve a new attempt against the same payable. |
| The seller’s wallet was credited after a delayed status update | Record the local credit and delivery reference. | Close the payable and cancel any queued replacement. |
Apply the same rule to an approved local bank payout. A stablecoin transaction hash establishes the settlement leg. The bank or mobile money provider’s delivery confirmation establishes that the seller received the money. The guide to bank, mobile money and stablecoin delivery explains the evidence to collect for each route.
Close the day with a balance check
Suppose a platform approves US$25,000 in seller payables. It confirms delivery of US$22,000, has US$2,000 still in flight and records US$1,000 in returned payouts whose seller balances are available again. Amounts use the original payable currency. The example excludes fees and FX.
| End-of-day state | Amount |
|---|---|
| Delivered and closed | US$22,000 |
| Open and reserved | US$2,000 |
| Open and available for reissue | US$1,000 |
| Total approved payables accounted for | US$25,000 |
| Category | Value (US$) |
|---|---|
| Delivered and closed | 22000 |
| Open and reserved | 2000 |
| Available for reissue | 1000 |
Illustrative ledger. Amounts are shown before fees and FX.
Reconcile the provider balance separately from the seller ledger. Match top-ups, transfers, fees and returns in their original currencies before translating them for reporting. Assign every unmatched item an owner, a reason and an expected resolution date.
Handle a failed local payout without paying twice
If the blockchain leg confirms and the local leg fails, check whether the provider still holds the funds, has credited a provider balance or has returned them to the funding source. Keep the payable reserved until the location and amount are established.
A new payout attempt should reference the same payable. Record who approved reissue and any FX or fee difference. Escalate unresolved balances by age, value and corridor so exceptions stay visible during the daily close.
