Sécurité de l’appareil
Découvrez comment le Tapaya Accept SDK sécurise les transactions grâce aux contrôles d’intégrité de l’appareil et à la protection des données, et comment l’intégrer et le déployer dans une configuration prête pour la production.
Le Tapaya Accept SDK transforme des appareils grand public standard (COTS, consumer off-the-shelf) en terminaux de paiement sécurisés. Comme ces appareils ne sont pas du matériel de paiement dédié, le SDK met en œuvre des mesures de sécurité rigoureuses pour atténuer les menaces et garantir la conformité aux normes PCI.
Attestation de l’appareil
Pour garantir la sécurité de l’environnement de paiement, le SDK effectue des contrôles continus de l’état de l’appareil hôte. Si une violation de sécurité est détectée, le SDK refuse de s’initialiser ou de traiter des transactions.
Détection du root et du jailbreak
Le SDK surveille l’environnement à la recherche d’indices d’élévation de privilèges. Il détecte notamment les binaires root et les frameworks de gestion des privilèges tels que Magisk ou SuperSU. Il détecte également tout accès non autorisé en lecture ou en écriture aux répertoires système protégés. Il identifie en outre les builds de système d’exploitation non standard, y compris les ROM personnalisées et les signatures de noyau modifiées.
Détection du débogage
Pour empêcher la rétro-ingénierie et les tests non autorisés, le SDK détecte si un débogueur est attaché à l’application et vérifie qu’elle s’exécute sur un appareil physique. L’exécution est restreinte dans les émulateurs et les environnements virtuels.
Google Play Integrity API
Sur Android, le SDK s’appuie sur la Play Integrity API pour vérifier que le binaire de l’appareil est reconnu par Google et n’a pas été altéré.
Sécurité de l’application
Obfuscation du code
Le Tapaya Accept SDK utilise des techniques d’obfuscation avancées pour réduire le risque de rétro-ingénierie. Les symboles du code sont renommés en identifiants non descriptifs, la logique du programme est volontairement obscurcie, et les chaînes sensibles ou les clés embarquées sont chiffrées.
Protection contre la falsification
Le SDK vérifie sa propre intégrité à l’exécution. Il contrôle la signature numérique de l’application et des bibliothèques du SDK. Si l’APK a été modifié ou reconditionné par un tiers, le SDK ne démarre pas.
Protection des données
Chiffrement de bout en bout (E2EE)
Les données de la carte sont chiffrées dès leur lecture par le contrôleur NFC. Un chiffrement robuste conforme aux standards du secteur est utilisé, et les clés de déchiffrement sont stockées uniquement dans des HSM sécurisés. L’appareil mobile n’a jamais accès aux données brutes de la carte.
Saisie sécurisée
Pour les transactions avec PIN, le SDK garantit une saisie sécurisée. L’écran de saisie du PIN est protégé contre les attaques par superposition, la disposition du clavier est aléatoire, et le SDK vérifie que chaque saisie tactile provient bien de l’appareil physique.
Surveillance de l’environnement
Prévention de l’enregistrement d’écran
Pour protéger les données sensibles, le SDK bloque les captures d’écran, les enregistrements d’écran et le partage d’écran en imposant des contrôles d’affichage sécurisé sur l’appareil.
Services d’accessibilité
Les applications malveillantes détournent souvent les services d’accessibilité pour lire le contenu de l’écran ou injecter des saisies. Le SDK détecte les services d’accessibilité actifs. S’il autorise les services standard destinés aux personnes malvoyantes (comme TalkBack), il peut bloquer les services inconnus ou suspects pendant le parcours de paiement.
Attestation et surveillance dans votre application
L’attestation et la surveillance ne sont pas un composant que vous installez. Elles sont intégrées au Tapaya Accept SDK et à
l’application plugin Tapaya Terminal, démarrent avec Accept.initialize() et fonctionnent tant que le SDK est actif.
Il n’existe aucun indicateur de configuration, aucune possibilité de désactivation et aucun mode qui les assouplisse.
Les deux volets doivent être validés indépendamment. Votre application héberge le SDK, et le SDK confie chaque paiement par carte à Tapaya Terminal, qui effectue sa propre attestation séparément. Un appareil qui satisfait l’un mais pas l’autre ne peut pas accepter de paiements.
Intégrer l’attestation dans votre application
| Obligation | Ce que cela donne dans le code |
|---|---|
| Initialiser une seule fois, au plus tôt | Accept.initialize(context, isProduction = true) dans votre classe Application. |
| Déclarer l’environnement réel | isProduction suit votre type de build, jamais une valeur codée en dur par commodité. |
| Garder Tapaya Terminal installé et activé | Vérifiez Accept.plugin.isInstalled(), puis appelez Accept.plugin.activateTerminal(), avant d’accepter un paiement. |
| Considérer un refus comme définitif | Signalez-le au commerçant et arrêtez le processus. Ne réessayez pas et ne basculez pas vers un autre chemin de code. |
Consultez Intégration du SDK mobile pour l’ensemble de l’API derrière chacun de ces points.
Déployer dans une configuration prête pour la production
Un build de production ne doit pas être débogable, ne doit pas produire de journaux et ne doit pas affaiblir la sécurité du transport. Le SDK impose lui-même l’essentiel de ces règles : un build débogable, ou un débogueur attaché, l’empêche purement et simplement de s’initialiser.
| Paramètre | Développement | Production |
|---|---|---|
android:debuggable | true | false |
Accept.initialize(isProduction = …) | false | true |
Accept.setDebugLoggingEnabled(…) | true | false |
| Clé de signature | keystore de débogage (debug keystore) | keystore de release (release keystore) |
| R8 / ProGuard | désactivé | activé, avec les règles consumer du SDK intactes |
| Configuration de sécurité réseau | peut faire confiance aux autorités de certification installées par l’utilisateur | aucune confiance dans les autorités de certification de l’utilisateur, aucun contournement du pinning |
| Débogage USB sur l’appareil | activé | désactivé |
Pilotez l’environnement depuis le build plutôt que de le modifier à la main avant une release :
Accept.initialize(context = this, isProduction = !BuildConfig.DEBUG)
Accept.setDebugLoggingEnabled(BuildConfig.DEBUG)Conformité
Un build livré avec le débogage activé, avec la journalisation de débogage laissée active ou avec le certificate pinning contourné sort de la configuration dans laquelle Tapaya Accept est certifié, qu’il traite encore des paiements ou non. Vérifiez chaque ligne du tableau ci-dessus avant chaque release de production.
Prérequis de la plateforme
Chacun des contrôles ci-dessus dépend d’une capacité de l’appareil hôte. Appareils pris en charge détaille chaque exigence, pourquoi l’attestation en a besoin et ce qui se passe lorsqu’elle n’est pas remplie. Deux d’entre elles déterminent le choix du matériel :
- Android 11 est un minimum absolu. Les appareils sous une version inférieure ne peuvent pas du tout exécuter le SDK. Plusieurs modèles SoftPOS dédiés sont encore livrés sous Android 7 à 9 sans possibilité de mise à jour : vérifiez donc la version du système de l’unité concernée plutôt que celle de la gamme.
- Les Google Mobile Services sont facultatifs. Lorsque les GMS sont présents, le SDK ajoute le verdict de la Play Integrity API à ses propres contrôles. Les terminaux dédiés livrés sans GMS, courants chez des fabricants comme Sunmi et iMin, sont entièrement pris en charge.
Lorsqu’un contrôle échoue
L’échec d’un contrôle est définitif pour cet appareil ; ce n’est pas une erreur passagère à réessayer. Le SDK refuse de s’initialiser, ou refuse de traiter une transaction lorsque la violation survient en cours de session. Rien dans votre intégration ne peut passer outre, et toute tentative de contournement place votre déploiement hors de sa configuration certifiée.
Traitez-le comme une panne irrécupérable de l’appareil : indiquez au commerçant que l’appareil ne peut pas accepter de paiements, et orientez-le vers le support. Ne réessayez pas en boucle et ne vous rabattez pas sur un autre parcours de paiement.
Responsabilités du développeur
Si le SDK se charge de l’essentiel, vous, en tant qu’intégrateur, devez veiller aux points suivants :
- Ne désactivez pas les avertissements de sécurité : N’essayez pas de contourner le SSL pinning ou la détection du root dans les builds de production.
- Maintenez le SDK à jour : Des correctifs de sécurité sont publiés régulièrement. Assurez-vous que votre application utilise la dernière version du Tapaya Accept SDK.
- Obfusquez votre application : Utilisez ProGuard ou R8 sur le code de votre propre application pour éviter d’exposer des clés API ou la logique qui interagit avec le SDK.
# The Tapaya Accept SDK includes its own consumer rules, but ensure you do not strip them
-keep class com.tapaya.** { *; }Signaler un incident de sécurité
Si vous découvrez une vulnérabilité de sécurité ou soupçonnez un incident de sécurité impliquant le Tapaya Accept SDK ou votre intégration, signalez-le de manière confidentielle comme indiqué dans Contacts. Indiquez la version du SDK concernée et les informations sur l’appareil, le cas échéant.
Il manque quelque chose sur cette page ?Demandez une fonctionnalité. Nous joignons cette page pour que l’équipe ait le contexte.