> ## Documentation Index
> Fetch the complete documentation index at: https://developers.ligdicash.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tokens et identifiants

> Différence entre token, request_id, transaction_id et external_id dans l'API LigdiCash — quel identifiant utiliser pour quoi.

L'API LigdiCash fait circuler plusieurs identifiants dans les requêtes, les réponses et les callbacks. Ils ont des rôles distincts et ne sont pas interchangeables. Confondre `token` et `transaction_id`, par exemple, est l'une des erreurs les plus fréquentes lors d'une première intégration.

## Tableau de synthèse

| Identifiant      | Généré par  | Format        | Où il apparaît                                     | Rôle                                                |
| ---------------- | ----------- | ------------- | -------------------------------------------------- | --------------------------------------------------- |
| `token`          | LigdiCash   | Chaîne longue | Réponse création + callback                        | Appeler `confirm`                                   |
| `request_id`     | LigdiCash   | `PXXXXXXXX`   | Page de paiement + callback                        | Référence courte affichable                         |
| `transaction_id` | Le marchand | Libre         | `custom_data` de la requête + callback + dashboard | Réconciliation marchand                             |
| `external_id`    | Le marchand | Libre         | Champ `invoice` de la requête                      | Équivalent de `transaction_id`, syntaxe alternative |

## Le token

Le `token` est généré par LigdiCash à la création de chaque transaction. Il est retourné dans la réponse de création :

```json theme={null}
{
  "response_code": "00",
  "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..."
}
```

Son **unique utilité** est d'être passé à l'endpoint `confirm` pour vérifier le statut d'une transaction. Stockez-le en base dès la création.

<Warning>
  La valeur du `token` dans le callback est différente de celle obtenue à la création. N'utilisez jamais le token comme identifiant de transaction — il n'est pas stable. Utilisez votre `transaction_id` pour la réconciliation.
</Warning>

## Le request\_id

Le `request_id` est un identifiant court généré par LigdiCash pour chaque transaction. Son format est `PXXXXXXXX` — par exemple `P2756808232026`.

Il est affiché sur la page de paiement LigdiCash et est présent dans le callback. Sa concision le rend facile à communiquer : un marchand peut l'afficher à son client comme référence de paiement, par exemple sur un reçu ou dans une interface de suivi.

<Tip>
  Le `request_id` est un bon identifiant à montrer à vos clients pour le suivi ou le support — il est court, unique et reconnu par LigdiCash.
</Tip>

## Le transaction\_id

Le `transaction_id` est un identifiant que **vous générez côté marchand** et que vous injectez dans le champ `custom_data` de votre requête. LigdiCash vous le retourne dans le callback et l'affiche dans votre dashboard parmi vos transactions payin et payout.

C'est le pivot de votre réconciliation : il fait le lien entre une transaction LigdiCash et votre propre système de commandes.

Le format est entièrement libre — référence commande, UUID, code court lisible par un client, etc.

Consultez [Le pattern transaction\_id](/concepts/transaction-id-pattern) pour les bonnes pratiques de format et d'utilisation.

## L'external\_id

L'`external_id` est l'équivalent direct du `transaction_id` — ils servent le même objectif. La différence est leur emplacement dans la requête : `external_id` est un champ du bloc `invoice`, tandis que `transaction_id` est injecté dans `custom_data`.

```json theme={null}
"invoice": {
  "total_amount": 5000,
  "devise": "XOF",
  "external_id": "ORD-2026-00042",
  "otp": "",
  ...
}
```

Utilisez l'un ou l'autre selon ce qui convient mieux à votre architecture — pas les deux simultanément. Dans les réponses de l'API, ces deux champs auront la même valeur.

<Note>
  Les deux sont retournés dans le callback. Utilisez celui qui correspond le mieux à votre architecture — ils auront la même valeur dans les réponses de l'API.
</Note>

## Pages associées

* [Le pattern transaction\_id](/concepts/transaction-id-pattern) — format, cycle de vie, extraction dans le callback
* [Sécuriser le callback](/api-paiement/callback/securisation) — pourquoi re-vérifier avec le token stocké
* [Codes de réponse et statuts](/concepts/codes-reponse-statuts)