Short answer. The reference price is in dinars, on the catalogue. The customer sees the price in their currency, computed with a reference rate and a written rounding rule, frozen at order time and kept on the record: the charged amount is the shown one. Two collections: a local provider for CIB and Edahabia in dinars, and a foreign provider, attached to an entity outside Algeria, for international cards in euros, because the large foreign providers do not open accounts for an Algerian company today. European banks require strong authentication of the cardholder for most online payments, and the payment page handles it. Both providers send a webhook to one handler, and there is only one order and one state machine; the channel is a field. Reconciliation is done per channel, in its currency, against the provider's payout; the dinar equivalent at the frozen rate serves revenue. A refund goes back through the original channel, to the cent. Six weeks, the first without code and with the accountant.
This guide is for the founder settled in France whose customers are on both sides, online lessons, care, bookings, gifts delivered in Algiers, the manager in Algeria part of whose customers pay from abroad, and the person who reconciles every month a euro payout and a dinar payout without knowing which one is short. It does not repeat how local payment is integrated, the page, the webhook and the order states, described in the online payment guide; it describes what is added when part of the customers pay in another currency, and it extends our software engineering page.
What the customer sees, in six steps
What the customer experiences, whether in Paris or Algiers, and the moment the application stops trusting the screen.
See the price in their currency: the currency comes from the card they will use or from their explicit choice, never from an approximate detection; the rate is frozen at that instant. Choose the method: international card, or CIB and Edahabia; the channel follows, and the customer sees only one page. Pay on the provider's page: amount and currency are set server side before the redirect, and the European bank may ask for strong authentication; this is the accented step.
Return to the application: the browser return is not proof, we wait for the webhook, following the rule set in the online payment guide. Receive the confirmation in their currency, with the receipt, through the channel described in the notifications guide. Be refunded if needed through the same channel, in the same currency, for the same amount, without the day's rate intervening.
Collecting in two currencies, in five layers
The single order is the layer that avoids double bookkeeping; the second layer carries the condition this guide cannot lift for you.
Prices and currencies. A catalogue price in dinars; a price shown in the customer's currency, computed with a reference rate chosen with the accountant, rounded by a written rule, frozen at order time and kept on the record. Prices come from the same engine as the quote and invoice guide. Two collections. A local provider for Algerian cards in dinars; a foreign provider for international cards in euros, attached to an entity outside Algeria: foreign providers publish the list of countries where an account can be opened, and Algeria is not on it today, France is. Single order. One record, one state machine, one webhook handler for both providers: signature checked, idempotent payment identifier, amount and currency compared with the order's, a single transition to “paid”; the channel is a field, not another order.
Reconciliation. Per channel and per currency, against the provider's payout: expected fees, expected net, payout date; the dinar equivalent at the frozen rate serves revenue, never reconciliation; two totals, never added up. Refunds and disputes. Refund through the original channel in the original currency; payment disputes handled with the order's evidence, confirmation, delivery, exchanges, following the after-sales guide; credit note linked to the order.
Two customers, two paths, one order
The figure follows two customers buying the same thing: one in Paris, the other in Algiers. Two paths, one record.
The customer in Paris sees 160 euros, computed from 24,000 dinars at the reference rate frozen at 10:02; they pay on the foreign provider's page, their bank requires strong authentication, and the provider sends a signed webhook with the payment identifier and the fees. The customer in Algiers sees 24,000 dinars, without conversion, and pays on the local provider's page, whose browser return is ignored and whose webhook is awaited. Both webhooks land on the same handler: signature, idempotent identifier, amount and currency compared with the order, and the record moves to “paid”, once, whatever the channel.
The record holds the catalogue price, the shown price, the frozen rate with its time, the channel, the provider's fees and the state; the refund will go back through the same channel. What the figure does not settle, and this guide does not settle either: which entity collects the euros, how funds move between the two countries and what the foreign exchange regime says; those are questions to settle with the accountant and counsel before the first week. Amounts, fees and rate are a constructed example.
«The customer does not choose a currency: they see the price in theirs, computed from the catalogue price in dinars with a rate frozen at order time and kept on the record.»
The 10 November reconciliation, in two currencies
The figure shows what the server expects from each provider, and what arrived. Two channels, two totals, and one row that does not match.
Every order carries its channel, the amount paid by the customer in their currency, the frozen rate, the dinar equivalent, the expected fees and net per the provider's schedule, and the expected payout date. Euro orders wait for the payout of the 17th; dinar orders received the one of the 12th, and one row shows a gap, flagged to be explained, not added. The 60 euro refund goes back through the original channel, in the original currency, and the rate does not move: the customer gets back exactly what they paid.
The manager reads one total per channel, in its currency, and never adds them; the dinar equivalent at the frozen rate serves revenue on the dashboard, following the real-time dashboard guide, and the export to the accountant, following the integration guide. Payout import and reconciliation run as a night task, following the background tasks guide. Amounts in the figure are a constructed example; fee schedules and payout delays are each provider's.
«Each channel reconciles in its own currency, against its provider's payout; the dinar equivalent serves revenue and never reconciliation.»
Six real situations, and what the application does
The six situations found in almost every company selling on both sides of the sea, and the construction that settles them.
The first three rows are settled by the euro payment page, the rate frozen at order time and the strong-authentication flow: the customer pays in a minute, the charged amount is the shown one, and a declined card has a message and a follow-up. The next three are settled by the single order, reconciliation per channel and refund through the same path: a payment never creates two orders, a payout that does not match is read row by row, and a refund does not depend on a manual transfer. None is settled by a cousin who is quicker on WhatsApp.
Seen elsewhere: where foreign providers open accounts, strong authentication, and what carries over
Three facts carry over as they are. Where an account can be opened: foreign payment providers publish the list of countries where a business can create an account; with the best known of them, France is on it and Algeria is not, at the time of writing; what carries over is that euro collection goes through an entity in a listed country, and that it is a business decision, not a code one. Strong authentication: in Europe, since September 2019, banks require for most online card payments an authentication of the cardholder, most often through 3-D Secure; a flow that does not handle it sees its payments declined; what carries over is a payment page that triggers it when the bank asks, and a test with the provider's test cards. The webhook as sole proof, already set for local payment; what carries over is one handler for both providers.
What those facts do not decide for you: the entity, the reference rate and its source, who pays the fees, and the refund rules; the project's first week answers that, with the accountant, and the manager signs.
The rules of two-currency collection that holds
Six rules, written in the first week. The reference price is in dinars, and the shown price is computed, never typed. The rate is frozen at order time and kept on the record. Amount and currency are set server side before the redirect. One order, the channel is a field, one webhook handler. Reconciliation is per channel and per currency, never added up. The refund goes back through the original channel, in the original currency, to the cent.
And one rule of method: the question of the collecting entity and the foreign exchange regime is settled with the accountant and counsel before writing a line; the application is built for the set-up chosen, not the other way round. Where servers run and where data lives is a separate decision, described in the hosting guide.
Six companies, and the collection path that was missing
Six situations composed from projects we meet; the names are generic and the figures are examples.
- An online lessons platform, pupils in Algiers, parents in Paris. Parents paid by transfer and the lesson started before the payment was identified. The construction: euro price frozen at enrolment, foreign provider's page on the French entity, webhook, lesson unlocked within the second; the model is described in the tutoring guide.
- A dental practice in Algiers, diaspora patients in summer. The treatment plan deposit arrived by Western Union with a photo of the receipt. The construction: euro deposit paid from France, frozen rate, deposit attached to the treatment plan; the case is described in the dental practice guide.
- A gift shop delivering in Algiers, orders from France. The euro price was recomputed every morning and customers disputed the differences. The construction: rate frozen at order time, charged amount equal to shown amount, refund through the same channel.
- A hotel in Oran, bookings from France and payments on site. Two spreadsheets, one in euros, one in dinars, never reconciled. The construction: one order per booking, channel on the record, reconciliation per channel; the model is described in the hotel booking guide.
- A founder in Marseille, online shop in Algiers. They had created the French entity to collect euros and had no common view. The construction: one application, two providers, a dashboard with two totals in their currency; remote management follows the shop from France guide.
- A startup launched from France, customers in Algeria. It billed everything in euros and lost local customers without an international card. The construction: catalogue price in dinars, CIB and Edahabia locally, euros for the diaspora; the launch calendar follows the startup launched from France guide.
The 2027 calendar
Six weeks for an application that already collects in dinars; the first week passes without code, with the accountant.
Week 1, decisions: the entity collecting the euros, the providers, the reference rate and its source, the rounding rule, who pays the fees, the refund rules; signed with the accountant and counsel. Week 2, prices and currencies: catalogue price in dinars, price shown in the customer's currency, rate frozen at order time and kept, display and receipts in both languages, following the bilingual application guide. Week 3, euro collection: foreign provider's page, strong authentication, signed webhook, idempotency, tests with the provider's test cards.
Week 4, single order: one webhook handler for both providers, channel on the record, state machine, customer confirmation in their currency. Week 5, reconciliation: expected fees and net per channel, payout import, gaps per row, refunds through the original channel. Week 6, measurement: share of orders per channel, success rate of euro payments, reconciliation gaps, Monday review. Every week ends with a demo, following the delivery without breakage guide.
What makes two-currency collection fail
Five causes, seen in applications we take over. The euro price recomputed at display: the customer sees one amount and pays another. The amount set browser side: it gets modified. Two orders for one payment: one per currency, and double bookkeeping begins. Totals added up: euros and dinars in the same column, and reconciliation impossible. The refund at the day's rate: the customer gets back more or less than they paid.
And one cause of method: building euro collection before settling the collecting entity. The application follows the set-up; it does not replace it.
Frequently asked questions
The questions founders and managers ask when they describe customers on both sides of the sea.
- How do you collect from a customer in France for a service in Algeria?
- Through a foreign payment provider, attached to an entity in a country where it opens accounts, France for example; the large foreign providers do not open accounts for an Algerian company today. The customer pays in euros on the provider's page, with the strong authentication their bank requires, and the webhook confirms the order. Which entity and how funds move are questions for your accountant and counsel.
- Why a rate frozen at order time?
- Because the customer must be charged the amount they saw. The reference price is in dinars; the euro price is computed with a reference rate at order time, rounded by a written rule, and kept on the record. The refund goes back for the same amount, in the same currency, without the day's rate intervening.
- Do you need two orders, one per currency?
- No, never. One order, one state machine, and the collection channel is a field of the record. Both providers send their webhook to the same handler, which checks the signature, the identifier and the amount, and moves the order to “paid” once.
- How do you reconcile euros and dinars?
- Separately: each channel reconciles in its currency against its provider's payout, with expected fees and net row by row. The two totals are never added up. The dinar equivalent at each order's frozen rate serves revenue and the export to the accountant, not reconciliation.
- Why does the French bank decline the card?
- Most often because the flow does not handle the strong authentication European banks have required since 2019 for most online payments, or because the amount was modified browser side. The provider's page triggers authentication when the bank asks, and the application shows a clear message and follows up with the customer.
- How do you refund a customer who paid in euros?
- Through the same channel, in the same currency, for the same amount, via the foreign provider; a credit note is linked to the order. Never by manual transfer nor at the day's rate. The refund appears in the euro channel's reconciliation with its negative sign.
- How long does it take to set this up?
- Six weeks in the typical calendar, the first without code with the accountant for the entity, the rate and the fees; then prices and currencies, euro collection, single order, reconciliation, measurement. The duration depends mostly on the time to open the foreign provider's account on the chosen entity.