Les ressources publiques ciblent des modèles reproductibles. SDK, firmware et documents fabricant restreints restent dans leurs canaux approuvés.
Des preuves comparables avec méthode, version et limites.
- Un propriétaire de sécurité approuvé et un appareil de test ou un jeu de cartes défini.
- Une limite claire pour les clés, les codes PIN, les données APDU, les certificats et l'intégration de l'hôte de paiement.
- Un environnement de test privé avec des journaux expurgés et aucun identifiant client.
Norme de publication
Intégrer Android en entreprise avec des preuves versionnées.
Les ressources publiques ciblent des modèles reproductibles. SDK, firmware et documents fabricant restreints restent dans leurs canaux approuvés.
- 01
Nommer la carte et la limite de sécurité
ICC, PSAM, PICC, bande magnétique, pavé PIN et élément sécurisé sont des flux de travail différents. Enregistrez le type de carte, l'emplacement, le protocole, le propriétaire et l'appareil cible au lieu de tout appeler « support de carte ».
- 02
Gardez les secrets en dehors de la démo
Utilisez des poignées de test opaques et des résultats rédigés dans le modèle public. Les clés, les blocs PIN, les données de suivi, les valeurs KSN, les certificats et les accessoires client restent dans l'intégration privée approuvée.
- 03
Rendre l'activation et la libération symétriques
Activez une session, validez la longueur et le statut de la réponse, puis désactivez-la dans un chemin final. Une transaction échouée ne doit pas laisser une carte ou un module sécurisé ouvert.
- 04
Exiger un examen de sécurité avant les réclamations concernant le matériel
Les échantillons locaux SDK sont utiles pour la découverte de modules, mais ils n'établissent pas la conformité, l'approbation du paiement ou la compatibilité de production. Ces affirmations nécessitent un dossier de preuve distinct.
Applications exemples / Kotlin
Modèles SDK et API
Cela utilise délibérément une poignée de test opaque. Il ne s'agit pas d'une implémentation de paiement et ne contient ni clés ni informations d'identification.
data class SecureRequest(
val operation: String,
val testHandle: String,
)
sealed interface SecureResult {
data object Accepted : SecureResult
data class Declined(val reason: String) : SecureResult
data class Failed(val reason: String) : SecureResult
}
interface SecurePort {
suspend fun execute(request: SecureRequest): SecureResult
}
suspend fun executeApprovedOperation(port: SecurePort): SecureResult =
runCatching {
port.execute(SecureRequest("approved-test", "fixture-01"))
}.getOrElse {
SecureResult.Failed("secure-operation-failed")
}Distribution des SDK
Contrôle de publication
Aucun binaire fournisseur, référence d'API, firmware ou exemple de code source n'est publié sans autorisation de redistribution et périmètre pris en charge enregistrés.
Supprimez la réponse du flux de travail public, enregistrez un échec expurgé et libérez la session.
Arrêtez le test, faites pivoter les informations d'identification concernées et supprimez l'artefact de l'environnement de test.
Divisez l'enregistrement de compatibilité et demandez un examen de sécurité spécifique à l'appareil.
États de preuve
Des preuves comparables avec méthode, version et limites.
- 01
Utilisez les informations d'identification et les appareils de test approuvés uniquement dans un environnement privé.
- 02
Vérifiez les chemins d’activation, de réussite, d’expiration, d’échec et de version.
- 03
Exécutez une analyse du journal expurgé avant de partager un rapport ou un échantillon.
- 04
Enregistrez le propriétaire de la sécurité, l'appareil, le micrologiciel, SDK et la portée de l'approbation.
Ressources
Modèles SDK et API
Aucun binaire fournisseur, référence d'API, firmware ou exemple de code source n'est publié sans autorisation de redistribution et périmètre pris en charge enregistrés.