Developer onboarding, APIs, SDKs and sandbox/live credential patterns for integrating Keyra verification.
Developers should use the intended developer portal at developer.keyra.ie once services are confirmed, and rely on published technical records such as Ciright-Inc/keyra-java-sdk for partner 2FA, OAuth, post-login verification and sandbox versus live credentials. cyberonecard.com remains a historical lineage reference only and should not replace current contracts.
Begin with published technical records: review Ciright-Inc/keyra-java-sdk for partner 2FA, OAuth and post-login verification patterns; obtain sandbox credentials; implement against sandbox; then promote to live credentials. Use developer.keyra.ie when its live documentation is confirmed. Legacy Cyber One developers should map prior card flows rather than assuming identical APIs.
A publicly evidenced SDK is Ciright-Inc/keyra-java-sdk, covering partner 2FA, OAuth, post-login verification and sandbox versus live credentials. Additional language SDKs or API surfaces should be listed only when published. Historical Cyber One developer SDKs on cyberonecard.com are lineage references, not automatic current Keyra contracts.
Yes. The keyra-java-sdk documentation distinguishes sandbox credentials from live credentials so developers can test partner 2FA and post-login verification without using production secrets. Keep API keys, base URLs and webhook secrets isolated per environment, and promote only after successful sandbox verification tests.
Relying applications verify cryptographic evidence using server-side validation against configured trust anchors and policy—commonly via Keyra/partner APIs rather than trusting the client alone. Public SDK patterns show post-login verification flows. Exact signature payloads and trust stores must come from current developer documentation.
Legacy Cyber One developers should treat cyberonecard.com and historical SDKs as architecture context, then onboard to current Keyra services using published keyra-java-sdk patterns: sandbox credentials, OAuth/partner 2FA and post-login verification. Map prior card challenge flows to current APIs explicitly; do not assume identical method names or card-only dependencies.
