Platform API
Environnements, authentification et sections de la Platform API de Tapaya dont votre intégration a besoin.
La Platform API de Tapaya vous permet de gérer les commerçants, les paiements et les paramètres de l’organisation depuis votre serveur. Les endpoints dont vous avez besoin dépendent de la manière dont votre application encaisse les paiements ; tous les intégrateurs n’ont pas besoin de toutes les sections.
Swagger documentationTapaya Integrator APIEvery endpoint, request field, and enum value, with a console to try requests.Open the API reference
Les enums sont numériques
Les champs comme businessTypeId, countryId, currencyId, documentType et refundReasonId sont tous des enums
numériques. Les valeurs possibles de chacun sont listées dans la
documentation Swagger, et non dans ce guide.
Sections qui vous concernent
| Votre intégration | Authentification des commerçants | Onboarding des commerçants | Reporting et paiements |
|---|---|---|---|
| Accept SDK (intégré à votre application) | 🟢 Obligatoire | 🟡 Facultatif | 🟡 Facultatif |
| Application Tapaya Terminal uniquement (intent/deeplink, sans SDK) | ⚪ Non nécessaire | 🟡 Facultatif | 🟡 Facultatif |
| Reporting / back-office uniquement | ⚪ Non nécessaire | ⚪ Non nécessaire | 🟢 Obligatoire |
- Authentification des commerçants : le SDK s’authentifie en tant que commerçant à l’aide d’un jeton de connexion demandé par votre backend. Elle n’est pas nécessaire pour les intégrations Tapaya Terminal : le commerçant se connecte directement à l’application Tapaya Terminal, il n’y a donc aucune session SDK à authentifier par votre backend.
- Onboarding des commerçants : facultatif pour toute intégration de paiement, en magasin ou en ligne. Un commerçant effectue l’onboarding une seule fois et cet onboarding couvre les deux canaux. L’onboarding se fait via la Tapaya Platform UI, une invitation hébergée ou l’API, selon qui doit collecter les données du commerçant.
- Reporting et paiements : facultatif pour l’une ou l’autre intégration de paiement si vous créez vos propres tableaux de bord ; obligatoire (et suffisant à lui seul) si vous récupérez uniquement des données de reporting sans intégration de paiement propre.
Toutes les lignes nécessitent tout de même l’authentification avec un Server Secret Token.
Utiliser la Secret key pour le Checkout
Le Checkout en ligne accepte la même Secret key issue de la
page API Keys, appelée ici Server Secret Token.
Le Checkout exige Authorization: Bearer <secret-key> et associe l’organisation à un commerçant.
Consultez Authentification du Checkout pour les conditions d’association du commerçant.
Environnements
La Platform API de Tapaya prend en charge les environnements suivants :
- Production : Hébergé sur
https://api.tapaya.com. Cet environnement utilise des comptes réels et implique des fonds réels. N’utilisez pas l’environnement de production pour vos tests. - Sandbox : Hébergée sur
https://api.sandbox.tapaya.com. Cet environnement vous permet de tester votre intégration sans aucun mouvement de fonds réels. Pour en savoir plus sur les tests, consultez notre guide Tests / sandbox.
Authentification
Les requêtes à la Platform API utilisent votre Server Secret Token, appelé Secret key sur la page API Keys. Transmettez-le tel quel dans l’en-tête Authorization de vos requêtes HTTP.
Authorization: REPLACE_MEPour authentifier votre plateforme auprès de l’API, vous devez générer une Secret key, appelée ici Server Secret Token, sur la page API Keys et l’utiliser pour remplacer REPLACE_ME ci-dessus.
Avertissement de sécurité
Votre Server Secret Token dispose de privilèges élevés. Ne l’exposez jamais dans du code côté client (applications mobiles, navigateurs web). Il ne doit être utilisé que depuis vos serveurs backend sécurisés.
Si un jeton est compromis, révoquez-le depuis la page API Keys ; la révocation prend effet immédiatement et est irréversible. Générez un jeton de remplacement avant ou après la révocation, selon vos besoins ; il n’existe pas d’action de « rotation » directe, mettez donc à jour la configuration de votre backend avec le nouveau jeton une fois celui-ci créé.
Pas de restriction de portée des clés
Chaque Server Secret Token dispose des mêmes privilèges à l’échelle de l’organisation ; il n’est pas possible pour l’instant de limiter un jeton à des endpoints ou à des commerçants précis. Considérez tout jeton comme équivalent à un accès complet à l’API pour votre organisation.
Le serveur n’est accessible que via le protocole HTTPS, avec TLS 1.2 ou version ultérieure imposé au niveau de l’infrastructure. Une limitation du débit est en place (100 requêtes par minute et par adresse IP) ; les requêtes qui surchargent le serveur renvoient une erreur 429 Too Many Requests.