B2B Cross-Border Payments: Building a Platform for West Africa–China Trade

A West African importer needs to pay a manufacturer in China. The invoice is denominated in Chinese yuan, but the importer holds local currency. They want to see the total cost, pay through a familiar local method, and know when their supplier has received the money.

For a FinTech building a B2B cross-border payments platform, delivering that experience means coordinating local collection, foreign exchange, transaction accounting, and an overseas payout.

This was the challenge behind a recent enquiry we received at SDK.finance. We provide the software foundation for payment products, and the team wanted to understand how our platform could support their proposed service. We’ve anonymised the enquiry and simplified some implementation details to focus on the architectural decisions.

The team wanted to build a mobile-first B2B cross-border payments platform that would allow merchants to:

• Fund high-volume B2B supplier payments in local currencies through familiar bank-transfer and mobile-money methods.
• See the amount needed to pay a supplier’s CNY-denominated invoice, including FX margins and fees.
• Accept an exchange quote valid for a defined period.
• Pay suppliers through a connected payout provider, using a prefunded balance to support faster delivery.
• Track the payment through one interface.

Consider how this would work for an importer in Ghana paying a manufacturer in China. The supplier issues an invoice in Chinese yuan, while the importer holds Ghanaian cedis:

1. The importer enters the CNY amount due and the supplier’s details in the app, reviews a time-limited quote showing the total cost in GHS, and funds the payment through a supported local method.
2. Once funding is verified and the required checks pass, the platform requests a CNY payout from an available prefunded balance with its payout partner.
3. The importer follows the payment’s progress in the app, while the backend records the collection, conversion, fees, and payout.

Treasury teams replenish the payout balance through a separate process.

For the merchant, this should feel like one payment journey. Behind it, the platform must coordinate providers, currencies, financial records, and transaction states.

The team’s goal was to build this service on an existing transaction and accounting foundation, while connecting external collection, FX, and payout providers. Below, we walk through the architecture such a product needs, where SDK.finance fits, and which workflows require provider integration or custom development.

The architecture of a cross-border payments platform

The proposed service would support importers in Ghana, Nigeria, and selected West African markets using XOF. Merchants would fund payments in local currency, while Chinese suppliers would receive CNY through an approved payout route.

SDK.finance sits between the external collection and payout services as the transaction backend. In this architecture, the SDK.finance Transaction Platform:

• Manages internal wallets, payment states, fees, and limits.
• Connects to the selected collection, FX, and payout providers through project-specific integrations.

The architecture has four connected layers:

For cross-border payments in Africa, each collection and payout route needs individual validation. Currency coverage, business eligibility, beneficiary requirements, funding arrangements, and settlement rules determine whether the complete payment journey is viable.

Within this cross-border payment infrastructure, the configured workflow links three steps:

1. A verified collection event is mapped to the relevant transaction and balance updates in SDK.finance.
2. The payment workflow requests a payout from the external partner when the required conditions are met.
3. Subsequent payout status updates are recorded in SDK.finance.

The external providers collect and deliver the funds and supply FX liquidity. SDK.finance maintains the internal transaction records.

Formal double-entry accounting can be added through SDK.finance General Ledger, with its scope and posting model agreed during solution design.

Designing B2B cross-border payments around supplier invoices

For an importer arranging payments to China, the starting point is often the amount the supplier must receive.

An invoice-led payment journey should establish the CNY amount due, the beneficiary, the merchant’s funding currency, and the total cost before collection begins. It should also retain a connection between the invoice and every subsequent financial operation.

For example, a payment request could contain:

• The supplier’s invoice amount and currency.
• The sending business and receiving business details.
• The selected collection and payout routes.
• The exchange quote, fees, and expiry time.
• The supporting documents required by the payout provider.

Document collection belongs in the payment design. Requirements differ by provider and route. For example, Thunes’ published China B2B requirements include supporting documents, a business receiving bank account, and a payout currency matching the invoice currency. Those conditions apply to its documented service and should be checked for the selected implementation.

A consumer wallet destination should therefore be evaluated separately from a business bank-account payout. Availability for one payment category does not establish suitability for supplier invoices.

Connecting providers through cross-border payments APIs

A cross-border payments API can initiate a collection or payout, but the final result may arrive later through a webhook or status enquiry.

The integration needs to turn those external messages into controlled internal operations. A collection-success notification should be checked against the expected merchant, amount, currency, and payment reference before it changes available funds or authorises a payout.

Flutterwave’s documentation illustrates this requirement: before giving value based on a webhook, an integration should re-query the API and verify critical transaction data. It also recommends idempotent processing, so repeated notifications do not produce repeated financial effects.

A practical integration flow is:

1. Authenticate the incoming notification.
2. Store it durably for processing.
3. Verify the payment details with the provider where required.
4. Check whether the financial operation has already been processed.
5. Apply the permitted transaction-state change and associated postings.
6. Trigger the next eligible step.

For cross-border payment software, the same principle must cover outbound requests. If a payout request times out, the system should resolve its status using the provider’s supported mechanisms before submitting another payment.

When assessing payment and financial service integrations, examine the complete provider workflow, including authentication, status enquiries, notifications, and settlement records. This integration work defines how the product behaves when external systems are delayed, unavailable, or inconsistent.

FX quotes and rate locking in B2B cross-border payments

A merchant-facing GHS/CNY or NGN/CNY price requires more than a stored exchange rate.

The platform needs a source for an executable quote, a method for calculating its margin and fees, and rules governing when that price can be accepted and executed.

A direct customer-facing pair can use an underlying route through an intermediate currency. The backend should preserve the relationship between the merchant’s quoted price and the provider operations used to fulfil it.

For invoice payments, calculating backwards from the required CNY amount can make the customer journey clearer: the supplier receives the agreed amount, and the merchant sees the local-currency funding requirement.

Rate locking needs backend rules

A time-limited quote creates an obligation that must be defined precisely. The implementation should establish:

• Whether acceptance or confirmed funding must occur before expiry.
• Whether the external provider guarantees the quoted rate.
• How available liquidity is checked or reserved.
• What happens when funding arrives after expiry.
• How failed conversions and refunds are handled.

An exchange-rate source alone cannot guarantee an executable conversion at that price. The customer-facing commitment must match the provider arrangement and the operator’s risk policy.

SDK.finance documentation describes currency-pair and rate management, including manual rates and external rate sources. A fixed-time customer quote requires an additional workflow aligned with the selected provider’s execution conditions.

Prefunding cross-border business payments

In a prefunded model, the operator maintains an available balance with its payout provider. Once the merchant’s funding and other required checks pass, the platform can request a supplier payout against that existing balance.

Local collection proceeds replenish the wider funding arrangement through a separate treasury process.

This design can reduce the need to wait for each individual collection to fund its corresponding overseas payout. It also creates working-capital and liquidity-management requirements.

Before accepting a payment, the platform should know whether enough payout liquidity is available after existing reservations. Treasury teams need visibility into:

• Available and reserved provider balances.
• Pending supplier payouts.
• Local collections awaiting settlement.
• Expected replenishment amounts and timing.
• Exposure to delays, reversals, and currency movements.

A fixed daily replenishment schedule may suit an initial operating model, but the schedule should follow actual volumes, provider conditions, and liquidity buffers. A successful collection does not establish that sufficient payout funds remain available.

Tracking cross-border payments from collection to settlement

The merchant needs a simple experience. Operations teams need a precise record of each financial step.

An illustrative workflow might move through:

Quote accepted → funding verified → payout submitted → beneficiary credited → reconciliation completed

Some payments will also require review, additional documents, or status investigation.

The interface should translate these states into clear messages. “Payment received” can describe confirmed local funding. “Supplier paid” should depend on the evidence the payout provider supplies for beneficiary credit.

This distinction also determines how failures are handled.

If a payout is definitively rejected, the workflow can follow its agreed release or refund procedure. If the payout outcome is unknown, the system needs an investigation path that prevents both a duplicate payout and an incorrect refund.

Fast B2B cross-border payments depend on handling these exceptions predictably.

Accounting and reconciliation for B2B cross-border payments

Wallet balances show one view of the business. The operator also needs to understand its obligations to merchants, positions with providers, conversion results, and earned fees.

Design the accounting model alongside the payment lifecycle. Each operation should retain the references needed to connect merchant funding, FX execution, supplier payout, and any reversal. A multi-currency ledger keeps the currency context of those balances and movements explicit.

Reconciliation should then compare those internal records with provider statements and bank records. It must be able to explain differences caused by timing, fees, failed payments, or missing transactions.

For an initial release, the operational goal is straightforward: a team member should be able to trace an invoice payment from collection to payout and identify any unresolved amount without reconstructing the journey from separate logs.

Using SDK.finance as cross-border payment software

The SDK.finance Transaction Platform can provide the transactional foundation for this model, with multi-currency wallets, configurable fees and limits, backoffice tools, and 650+ APIs. Its money transfer software provides a starting point for branded transfer products connected to external banking, payment, and FX providers.

The implementation defines how provider events affect transaction states, balances, fees, and reconciliation records. Provider-specific mappings, duplicate protection, routing, and exception handling need to be assessed and configured or developed for the project.

The transaction-processing and accounting scopes should also be explicit. If the business requires formal double-entry accounting across customer liabilities, settlement positions, FX, and adjustments, assess the role of SDK.finance General Ledger and establish the posting model during solution design.

This gives the team a clear boundary between the software foundation, the integration work, and the external financial services.

SaaS or Source Code for a cross-border payments platform

SDK.finance offers SaaS and commercial source-code licensing. SaaS provides a hosted application, while the source-code model allows customisation and deployment within the licensed scope.

For the architecture discussed here, evaluating the Source Code model early is sensible if provider routing, quote management, settlement logic, or infrastructure requirements demand deep changes.

SaaS can still suit a proof of concept or production implementation whose needs fit the available APIs and workflows. Custom provider integrations can also be delivered in SaaS, so needing an integration alone is not a reason to choose Source Code. The deciding question is whether the requirements can be met through configuration, APIs, and middleware, or require changes to the core transaction logic.

Compare the models against integration flexibility, maintenance responsibility, hosting requirements, release control, and total operating cost at expected volumes. If a later transition is contemplated, establish how custom integrations, balances, transaction history, and in-flight payments would move.

Validating cross-border payments in Africa: start with one corridor

A useful proof of concept demonstrates a complete invoice-payment journey through one collection route and one approved payout route.

It should test the financial consequences of failures as well as the successful path:

For a high-volume cross-border payments platform, testing should also cover peak transaction rates, bursts of provider notifications, processing backlogs, and recovery after an interruption. The platform needs to preserve correct balances and prevent duplicate financial operations under those conditions.

These tests give founders, engineering teams, and implementation partners evidence that the architecture can support operations before adding more countries and providers.

TheOneGate: a B2B payments platform built on SDK.finance

TheOneGate, a Swiss financial platform, selected the SDK.finance SaaS Transaction Platform as the foundation for its corporate payment and money-transfer services.

The published case describes multi-currency accounts, multiple payment flows, and connections to external financial providers. TheOneGate’s account of the implementation highlights the value of starting with an existing payment core and focusing development on its own services, integrations, and customer experience.

For a team building cross-border payments infrastructure, that is the relevant principle: use an established transactional foundation, then develop the provider connections and business workflows the product requires.

Planning a B2B cross-border payments platform? Discuss your architecture with SDK.finance, including collection routes, FX quoting, payout providers, accounting requirements, and deployment needs.