Toutes les listes utilisent une pagination par curseur (pas de ?page=N). Plus stable que l’offset : pas de saut si la collection mute pendant la pagination.

​
Format

Requête : 
GET /v1/payment-intents?limit=50&cursor=cur_abc123
Réponse : 
{
  "data": [ /* 50 intents */ ],
  "nextCursor": "cur_xyz789"
}
  • nextCursor: null → fin de la collection
  • limit : défaut 20, plafonné silencieusement à 100 (jusqu’à 500 pour les payouts, settlements et transactions wallet) ; une valeur supérieure n’est pas rejetée mais ramenée au plafond

​
Avec le SDK

​
Lecture page par page

let cursor: string | undefined;
do {
  const page = await izipay.paymentIntents.list({ status: 'completed', cursor, limit: 100 });
  for (const intent of page.data) {
    processOne(intent);
  }
  cursor = page.nextCursor ?? undefined;
} while (cursor);

​
Async iterator (recommandé)

for await (const intent of izipay.paymentIntents.iterate({ status: 'completed' })) {
  await processOne(intent);
}
L’iterator gère le curseur tout seul, s’arrête à nextCursor: null. Disponible sur toutes les ressources : paymentIntents, payouts, invoices, products.

​
Filtres

Liste-spécifiques (voir la référence API par endpoint) :
  • Payment Intents : status, assetCode, source, from, to
  • Payouts : status, assetCode, payoutType
  • Invoices : status, from, to
  • Products : isActive

​
Ordre

Par défaut : createdAt DESC (plus récent d’abord).

​
Limites de profondeur

Pas de limite hard sur la profondeur de pagination : vous pouvez itérer sur des millions de payment intents. Mais préférez les filtres de date : 
// 1 mois à la fois
for await (const intent of izipay.paymentIntents.iterate({
  from: '2026-11-01', to: '2026-11-30'
})) {
  // ...
}
Le cursor est opaque : ne le parsez pas. Sa structure peut changer sans préavis. Conservez-le tel quel et renvoyez-le.