Questions fréquentes

Tiki est une plateforme d'avantages salariés et de fidélité : elle permet à une entreprise d'émettre des cartes cadeaux digitales, de gérer des titres restaurant, de piloter des programmes de cashback et de verser des montants en masse sur les wallets de ses bénéficiaires.

Non. Les quatre briques partagent le même socle mais s'activent indépendamment. Vous pouvez commencer par les titres restaurant et ajouter les cartes cadeaux plus tard, sans recréer vos bénéficiaires.

Les équipes RH, paie ou administratives qui préparent et valident les distributions, et la direction financière pour le suivi et les exports. Les droits se règlent par rôle, chacun ne voyant que ce qui le concerne.

L'ouverture d'un espace entreprise et le paramétrage d'un programme standard se font rapidement ; le délai réel dépend de la déclaration de vos bénéficiaires et, le cas échéant, de l'intégration à vos systèmes.

Chez les commerçants affiliés au réseau, dans les catégories autorisées par votre programme. Un titre restaurant est restreint aux commerces alimentaires ; une carte cadeau peut couvrir un périmètre plus large, que vous définissez.

Oui, par lot ou par carte. Le solde reste visible jusqu'au dernier jour ; après expiration, le résiduel est identifié ligne par ligne sur le lot concerné.

Vous décrivez le déclencheur — commerçant, catégorie, montant minimum — et la récompense, en pourcentage ou en montant fixe, puis vous posez les plafonds par bénéficiaire et le budget global avant d'activer la règle.

Oui. Un même bénéficiaire peut porter un wallet repas, un wallet cadeau et un wallet cashback, chacun avec ses propres règles d'usage et son solde distinct.

Les opérations du portail — créer un bénéficiaire, émettre une carte, créditer un wallet, déposer un ordonnancement, lire un solde — sont exposées par l'API REST, avec la même logique de droits.

Oui : un environnement isolé, avec ses propres clés et des données jetables, pour dérouler l'intégration complète avant de basculer en production. Les appels sont identiques d'un environnement à l'autre.

Par webhooks signés : vous déclarez une URL et les événements qui vous intéressent, et vous vérifiez la signature à la réception. Les livraisons en échec sont réessayées et leur historique est consultable.

Seuls les utilisateurs que vous avez invités, et selon le rôle que vous leur avez donné. Le cloisonnement entre organisations est appliqué à la requête, pas au filtrage de l'affichage.

Chaque émission, rechargement, dépense, annulation et modification de paramétrage est horodatée et attribuée à son auteur, et reste consultable et exportable.

Générez une clé par intégration pour pouvoir en révoquer une sans casser les autres, ne les placez jamais dans du code client ni dans un dépôt, et pratiquez une rotation en créant la nouvelle clé avant de révoquer l'ancienne.