Cursor

# Intégration LigdiCash

## Contexte

LigdiCash est un agrégateur de paiement mobile money en Afrique de l'Ouest.
API base URL : https://app.ligdicash.com

## Headers obligatoires sur chaque requête

```
Apikey: {API_KEY}
Authorization: Bearer {AUTH_TOKEN}
Accept: application/json
Content-Type: application/json
```

## Format des données

- Numéros de téléphone : format E.164 sans `+` ni espaces — ex. `22670000000`
- Montants : entiers (XOF n'a pas de décimales) — ex. `5000`
- Devise : `XOF` exclusivement
- Clés API dans les exemples : toujours `{API_KEY}` et `{AUTH_TOKEN}`, jamais de vraies valeurs

## Règle d'or — identification des transactions

Le `token` retourné à la création est différent du `token` reçu dans le callback.
Ne jamais utiliser ce token pour identifier une transaction.

Toujours passer un identifiant marchand dans `custom_data` à la création :
```json
"custom_data": { "transaction_id": "ORD-2025-00042" }
```

Dans le callback, `custom_data` revient sous forme de tableau d'objets. LigdiCash y ajoute ses propres champs (`hash`, `logfile`). Extraire avec :
```javascript
const entry = custom_data.find(e => e.keyof_customdata === "transaction_id");
const transactionId = entry?.valueof_customdata;
```

## Payin avec redirection — pièges

- `customer` doit rester `""` — sinon LigdiCash filtre les opérateurs visibles
- Ne jamais ouvrir l'URL de paiement dans un `<iframe>` — utiliser le même onglet, un nouvel onglet, un popup ou une WebView native

## Callback

- LigdiCash envoie deux POST : un `application/x-www-form-urlencoded` + un `application/json`. Dédupliquer.
- Re-vérifier chaque callback en appelant l'endpoint `confirm` avec le token stocké à la création. Ne jamais faire confiance au payload reçu.