# Payment providers in Côte d’Ivoire: connect checkout, invoices and XOF refunds

A customer has paid, an order exists, and an invoice has been issued. Do all three refer to the same transaction? For a business accepting payments in Côte d’Ivoire, that question matters as much as the percentage on a commercial proposal. It becomes particularly expensive when a cancellation creates a credit note but the customer is still waiting for their money.

PayStar’s gateway-data snapshot of **14 September 2026** contains **8 unique offer records linked only to Côte d’Ivoire: 4 collections and 4 payouts**. All eight have an XOF currency association. These are historical records supplied by gateways, not eight providers or eight verified live payment routes. PayStar has not independently verified their commercial statements.

This guide uses that small sample as a starting point for asking better questions. The country-specific focus is the connection between mobile checkout, order reconciliation, electronic invoicing and refunds. The cost calculations below are explicitly hypothetical, not anonymised versions of private quotes.

## 1. What eight records tell you—and what they leave open

The recorded direction split is balanced. Your operating requirements may not be. A merchant collecting many small orders and refunding occasional cancellations needs different controls from a business making scheduled XOF payouts.

<!-- CHART:offers -->

Four records in each direction are too few for a useful public tariff comparison without exposing narrow commercial groups. We therefore publish no fee averages, minimums, maximums or settlement-time distribution from this sample. A count is a starting point for discovery, not a price list.

The source links countries, currencies and payment types separately. Those links do not establish every possible combination of country, method, currency and direction. In particular, an XOF association does not prove that an offer can collect through a named wallet, refund through the original method, or settle to your bank account.

Ask for a written answer for your legal entity, product and transaction flow. The answer should identify the collection method, merchant onboarding requirements, settlement currency and destination, refund process and payout service. Confirm which parts are covered by one contract and which need a separate provider or agreement.

## 2. Compare payment costs at your actual order value

A lower percentage can lose on small purchases if the fixed component is higher. Consider two **fictional** collection tariffs: A charges **2% + XOF 50** per completed payment; B charges **1% + XOF 150**. These figures were chosen for this explanation and do not represent the recorded offers.

<!-- CHART:cost -->

The tariffs have equal cost at an order value of **XOF 10,000**: both charge XOF 250. Below that value, A is cheaper in this model; above it, B is cheaper. Your distribution of order values matters more than a headline percentage. A business selling mostly XOF 5,000 baskets should not evaluate costs using only a much larger average order.

For a real comparison, add any minimum fees, taxes, conversion charges, refund fees and retained collection fees. Clarify what triggers a charge: a successful payment, a request, a failed attempt or a payout. These are separate questions; the historical dataset cannot answer them for your business today.

Also separate processing cost from cash availability. A payment may be confirmed while the proceeds remain outside the merchant’s usable balance. Ask how reconciliation reports describe the gross amount, deductions and the amount that is actually available for settlement.

## 3. Test a merchant checkout, not just a wallet transfer

Orange Côte d’Ivoire describes a Web Payment flow in which the customer generates a one-time code through USSD and enters it during online payment. Merchant enrolment and integration testing are part of the service description. This is a concrete local checkout to investigate, not evidence that any of the eight catalogue offers supports it. [Orange Money Web Payment](https://business.orange.ci/fr/orange-money-web-payment.html)

Build the acceptance test around an order reference. Try a completed payment, an expired code, a customer who leaves the checkout, a delayed final status and a repeated notification. These are proposed tests, not claims about documented Orange API behaviour. Ask the chosen provider which states and lookup mechanisms its integration supports.

Your fulfilment decision should use the provider’s verified final payment status, mapped to the correct order. A browser return, a customer screenshot or an invoice number alone should not be your proof of successful collection. If the final answer is missing, keep an exception queue with the payment reference, amount, timestamp and next reconciliation action.

Measure checkout completion with an agreed denominator: for example, successful unique orders divided by unique orders that started the payment flow, over a defined period. Retried requests are not additional customers. We have no measured Côte d’Ivoire conversion rate in this dataset, so no average or improvement promise appears here.

## 4. Keep the invoice correction and the money refund in sync

Côte d’Ivoire’s tax authority describes FNE electronic invoices and full or partial credit notes in its official FAQ. It also provides documentation for businesses connecting their own invoicing systems. Applicability, exceptions and the required DGI process need checking for the merchant concerned. [DGI FNE FAQ](https://www.fne.dgi.gouv.ci/faq.php) · [DGI API procedure](https://fne.dgi.gouv.ci/documents/FNE-procedureapi.pdf)

Our operational recommendation is to track three separate references: the order, the fiscal document or credit note where applicable, and the provider’s payment or refund transaction. Creating a credit note and returning money are different actions. Link them, but do not use one action’s success flag as proof that the other has completed. This is a reconciliation design recommendation, not a claim that PayStar supplies a DGI-certified invoicing connector.

Here is a **fictional refund example**. Twenty completed orders of XOF 5,000 generate XOF 100,000 in receipts. Two are refunded in full. Assume the collection charge remains 2% of the original gross receipts and each refund has an additional XOF 50 fee. These are teaching assumptions, not gateway terms.

<!-- CHART:refunds -->

After XOF 10,000 in refunds, XOF 2,000 in retained collection fees and XOF 100 in refund fees, the remaining cash is **XOF 87,900**. This is neither accounting revenue nor taxable profit. The example excludes starting balances, taxes, FX, reserves and release delays. It shows why refund policy belongs in the commercial comparison before integration begins.

For partial refunds, ask how the original payment, refunded amount and remaining refundable amount are linked. For a refund still pending, record both the customer-service commitment and the provider’s actual status. A daily exception report should expose mismatches rather than silently close the order.

## 5. Request evidence for the complete operating flow

Ask a candidate provider for a demonstration using your order, invoice and refund references. The useful output is not merely a green checkout screen. It is a reconciliation record your operations team can follow without guessing which transaction a customer is discussing.

- **Collections:** final status definition, references, duplicate handling, transaction lookup and reconciliation export.
- **Refunds:** full and partial refund support, original-method restrictions, fees, timing and the evidence of completion.
- **XOF settlement and payouts:** who receives funds, which account is eligible, when funds become usable and how deductions appear.
- **Support:** an exception owner, escalation channel and the information required to investigate a missing or disputed payment.

Do not treat a payout API as an automatic substitute for a refund. The permitted recipient, original-payment linkage, contractual treatment and operational risks may differ. Have the provider document the intended process for your use case.

Test a small representative set before increasing volume. Include one cancellation and one unresolved payment in the test plan, not only successful orders. Any acceptance criteria and response times should be agreed with the provider; this article does not establish a service-level commitment.

## 6. Confirm the entity, permissions and local obligations

Payment services in the monetary union are covered by BCEAO’s Instruction No. 001-01-2024. BCEAO also publishes a dated list of authorised payment institutions. Check the actual contracting entity, applicable provider category and permitted services, rather than relying on a brand name or catalogue entry. A payment-institution list should not be read as a complete list of every bank or electronic-money issuer. [BCEAO payment-services instruction](https://www.bceao.int/fr/reglementations/instruction-ndeg001-01-2024-du-23-janvier-2024-relative-aux-services-de-paiement) · [BCEAO register dated 28 February 2026](https://www.bceao.int/fr/communique-presse/liste-des-etablissements-de-paiement-agrees-dans-lumoa-au-28-fevrier-2026)

Confirm merchant establishment, product eligibility, required documentation and the lawfulness of the proposed activity before onboarding. Separately confirm invoicing obligations and any DGI authorisation needed for the merchant’s own invoicing integration. A successful payment test does not establish compliance with these requirements.

The official sources were reviewed on **2 October 2026**. The DGI FAQ and API document were available through official-domain search results, but direct retrieval timed out; this access limitation is recorded in the source notes. No tax rate, implementation deadline or universal FNE obligation is asserted here. Recheck the relevant rules and provider permissions before launch.

## 7. PayStar’s role

PayStar provides informational and technical services. It is not a bank or payment service provider, does not arrange payment acceptance or settlement in its own name, and does not receive, hold or settle customer or business funds.

The business selects its payment service provider and contracts with that provider directly. The provider remains responsible for the payment services it supplies. PayStar can help structure a comparison and, within a separately agreed technical scope, support integration, routing, monitoring and reconciliation. A catalogue entry is not approval, guaranteed availability, conversion or settlement performance.

PayStar works with lawful products and appropriately authorised providers. Product eligibility, provider approval, fees and contractual conditions must be confirmed separately for the proposed arrangement.

## 8. Bring Anastasia the flow you need to operate

For a useful first discussion, share your legal entity and product, customer geography, expected order values and monthly volumes. Add your collection method preferences, XOF settlement destination, refund needs and whether your invoicing system already has an FNE workflow.

Anastasia can help request and organise information about payment options, fees, limits, settlement and documentation. Information discovery is free; payment processing, integration and other services have their own agreed terms. Contact [Anastasia on Telegram](https://t.me/anastasiapaystar) or [by email](https://mail.google.com/mail/?view=cm&fs=1&to=Anastasia%40PayStar.uk&su=Payment%20Discovery%20request).

## 9. Data, examples and reusable graphics

The commercial source is the gateway-supplied snapshot of **14 September 2026**. Counts use unique offer records, not JOIN rows, providers, payment methods or approved routes. The eight records in this article are linked only to Côte d’Ivoire; XOF is a separate currency association. Commercial statements have not been independently verified by PayStar, can change weekly, and do not establish present availability.

All monetary calculations are hypothetical examples authored on 2 October 2026. No individual quote, private counterparty or narrow-group tariff statistic is disclosed. Official method descriptions explain local context and do not prove catalogue support. The material is general information, not an offer, legal or tax advice.

The [media library](media/index.html) contains original RU/EN covers, standalone graphics with context and compact article graphics. Localised preview images are candidates for review; the standard PayStar network preview remains unchanged. See the [source notes](sources.md) and [public calculation data](commercial-snapshot.json).