Skip to main content

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.

The LigdiCash API circulates several identifiers across requests, responses, and callbacks. They have distinct roles and are not interchangeable. Mixing up token and transaction_id, for example, is one of the most common mistakes during a first integration.

​
Summary table

IdentifierGenerated byFormatWhere it appearsRole
tokenLigdiCashLong stringCreate response + callbackCall confirm
request_idLigdiCashPXXXXXXXXPayment page + callbackShort displayable reference
transaction_idThe merchantFree-formcustom_data of the request + callback + dashboardMerchant reconciliation
external_idThe merchantFree-forminvoice field of the requestEquivalent of transaction_id, alternative syntax

​
The token

The token is generated by LigdiCash when each transaction is created. It is returned in the create response: 
{
  "response_code": "00",
  "token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9..."
}
Its only purpose is to be passed to the confirm endpoint to check a transaction’s status. Store it in your database as soon as the transaction is created.
The value of token in the callback is different from the one obtained at creation. Never use the token as a transaction identifier — it is not stable. Use your transaction_id for reconciliation.

​
The request_id

The request_id is a short identifier generated by LigdiCash for each transaction. Its format is PXXXXXXXX — for example P2756808232026. It is displayed on the LigdiCash payment page and is present in the callback. Its short form makes it easy to communicate: a merchant can show it to their customer as a payment reference, for example on a receipt or in a tracking interface.
The request_id is a good identifier to show your customers for tracking or support — it is short, unique, and recognized by LigdiCash.

​
The transaction_id

The transaction_id is an identifier that you generate on the merchant side and inject into the custom_data field of your request. LigdiCash returns it to you in the callback and displays it in your dashboard among your payin and payout transactions. It is the pivot of your reconciliation: it links a LigdiCash transaction with your own order management system. The format is entirely free — order reference, UUID, short customer-readable code, etc. See The transaction_id pattern for best practices on format and usage.

​
The external_id

The external_id is the direct equivalent of transaction_id — they serve the same purpose. The difference is their location in the request: external_id is a field of the invoice block, while transaction_id is injected into custom_data. 
"invoice": {
  "total_amount": 5000,
  "devise": "XOF",
  "external_id": "ORD-2026-00042",
  "otp": "",
  ...
}
Use one or the other depending on what fits your architecture better — not both at the same time. In API responses, these two fields will have the same value.
Both are returned in the callback. Use whichever fits your architecture best — they will have the same value in API responses.