Centro di sviluppo / Carte/operazioni sicure

Moduli card e sicuri

Separato ICC, PICC, struzzo magnetico, PIN e lavoro di elezione sicura dal codice di applicazione ordinario e registri.

Standard di pubblicazioneSviluppatori

Collega e convalida la tua applicazione sull'hardware di destinazione.

Un limite di sicurezza e un piano di prova che rende esplicita la proprietà, i dati sensibili e le porte di approvazione.

I team di pagamento, identità e integrazione di carte sicure che lavorano con hardware e credenziali approvate.

Le risorse pubbliche si concentrano su modelli di integrazione riproducibili. SDK, firmware e documenti soggetti a restrizioni restano nei canali di distribuzione autorizzati.

Dati comparabili sui dispositivi, con metodo, versione e limiti dichiarati.

Risorse per gli sviluppatoriCarte/operazioni sicure
RuggedLayer Laboratorio di provaAvanzato
Guide tecniche, note sull'SDK, app di esempio e dati di compatibilità per dispositivi Android robusti con codici a barre e RFID.I team di pagamento, identità e integrazione di carte sicure che lavorano con hardware e credenziali approvate.
  • Un proprietario di sicurezza approvato e un dispositivo di prova definito o set di carte.
  • Un confine chiaro per le chiavi, PIN, APDU dati, certificati e integrazione host di pagamento.
  • Un ambiente di prova privato con log retti e senza credenziali del cliente.

Standard di pubblicazione

Crea e valida integrazioni Android aziendali con evidenze versionate.

Le risorse pubbliche si concentrano su modelli di integrazione riproducibili. SDK, firmware e documenti soggetti a restrizioni restano nei canali di distribuzione autorizzati.

  1. 01

    Nome della carta e del confine di sicurezza

    ICC, PSAM, PICC, striscia magnetica, PIN pad e elemento sicuro sono diversi flussi di lavoro. Tipo di scheda di registrazione, slot, protocollo, proprietario e dispositivo di destinazione invece di chiamare tutto "supporto di carte".

  2. 02

    Tenere segreti fuori dalla demo

    Utilizzare maniglie di prova opaca e risultati retti nel modello pubblico. PIN blocchi, traccia dati, KSN i valori, i certificati e gli apparecchi dei clienti rimangono nell'integrazione privata approvata.

  3. 03

    Attivazione e rilascio simmetrico

    Attivare una sessione, convalidare la lunghezza e lo stato di risposta, quindi disattivare in un percorso finalmente. Una transazione fallita non deve lasciare una carta o un modulo sicuro aperto.

  4. 04

    Richiedere la revisione di sicurezza prima dei reclami hardware

    Il locale SDK i campioni sono utili per la scoperta del modulo, ma non stabiliscono la conformità, l'approvazione del pagamento o la compatibilità di produzione.

App di esempio / Kotlin

Modelli SDK e API

Questo utilizza deliberatamente una maniglia di prova opaca. Non è un'implementazione di pagamento e non contiene chiavi o credenziali.

secure-port.kt

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")
  }
Nessun codice binario del fornitore, riferimento API, firmware o esempio di origine viene pubblicato finché non vengono registrati l'autorizzazione di ridistribuzione e l'ambito supportato.

Distribuzione dell'SDK

Criteri di pubblicazione

Nessun codice binario del fornitore, riferimento API, firmware o esempio di origine viene pubblicato finché non vengono registrati l'autorizzazione di ridistribuzione e l'ambito supportato.

Lunghezza o stato di risposta non prevista

Scartare la risposta dal flusso di lavoro pubblico, registrare un fallimento reciso e rilasciare la sessione.

Un segreto appare nei registri o negli apparecchi

Fermare il test, ruotare le credenziali interessate e rimuovere l'artefatto dall'ambiente di prova.

Il modulo del dispositivo differisce per modello

Dividi il record di compatibilità e richiedi una recensione di sicurezza specifica del dispositivo.

Stati delle evidenze

Dati comparabili sui dispositivi, con metodo, versione e limiti dichiarati.

  1. 01

    Utilizzare le credenziali di prova approvate e gli apparecchi solo in un ambiente privato.

  2. 02

    Verificare i percorsi di attivazione, successo, timeout, fallimento e rilascio.

  3. 03

    Eseguire una scansione di log redatta prima di condividere qualsiasi report o campione.

  4. 04

    Registrare il proprietario della sicurezza, dispositivo, firmware, SDK e l'approvazione.

Collega e convalida la tua applicazione sull'hardware di destinazione. Richiedere un dispositivo di portata e una revisione di sicurezza prima di pubblicare una carta o l'integrazione di pagamento.

Risorse

Modelli SDK e API

Nessun codice binario del fornitore, riferimento API, firmware o esempio di origine viene pubblicato finché non vengono registrati l'autorizzazione di ridistribuzione e l'ambito supportato.

Collega e convalida la tua applicazione sull'hardware di destinazione.

Condividi il flusso applicativo non riservato, il dispositivo attuale e il percorso di integrazione; definiremo il deliverable di validazione più adatto.

Collega e convalida la mia applicazione