Signing in with SSO tells us the user authenticated with your identity provider. For a small set of high-risk operations that isn’t enough on its own — those need a factor bound to the user’s own device, held by that user and not by any system in between. That factor is a passkey.
Enrol every SSO user in a passkey. Treat it as part of onboarding, not an optional extra. A user without a passkey cannot complete the operations below, and passkey is the only method accepted on an SSO session — PIN and TOTP are not substitutes.

​
Which operations are affected

For secure card details, use the POST form shown above — it is the only one that can carry a passkey confirmation. On an SSO session the legacy GET form is refused.

​
The flow

​
Step 1 — enrol the user (once per device)

An SSO user registers a passkey with the ordinary add-a-passkey endpoints, authenticated with the id_token they already hold — with one extra step that only applies to SSO: the user must confirm a code emailed to them before the passkey challenge is issued.
1

Start — a code is emailed

POST /v1/auth/passkey/register/start with Authorization: Bearer <id_token> and an optional friendly_name (e.g. "My iPhone"). On an SSO program this does not return publicKey. It emails the user a verification code and responds with:
2

Start again — with the code

Collect the code from the user and call the same endpoint again, with the same body plus email_code:
Once the code is confirmed you get the normal response — a session_token and publicKey creation options — and continue as any other program would.
3

On the device

Pass publicKey to navigator.credentials.create() on web, or the platform credential API on native — see the platform table. The user confirms with fingerprint, face, or screen lock.
4

Finish

POST /v1/auth/passkey/register/complete with the session_token and the attestation the device produced.
The email check runs on every SSO passkey registration. There is no grace period and no “already verified” fast path — a user adding a second device gets a fresh code. Build the code-entry screen as a normal part of the enrolment flow rather than a one-off.It exists so a passkey can only be added by someone who can read the account’s email. That is what makes the passkey meaningful as a second factor on top of your identity provider.
The email address used is the one held on the user’s Orenda account. If your identity provider changes a user’s email, the code goes to the address we hold — not necessarily the new one.
Users can hold several passkeys — list them with GET /v1/auth/passkey/credentials and let users add one per device. Prompt for enrolment at a calm moment in your app, not in the middle of a payment.

​
Step 2 — get a challenge

Immediately before the sensitive call:
The challenge is short-lived — request it when the user acts, not at screen load.

​
Step 3 — unlock on the device

Convert the base64url fields to byte arrays, call navigator.credentials.get() (or the native equivalent), and encode the result back to base64url. The passkey sign-in page has the conversion helpers and native platform notes — the mechanics are identical here.

​
Step 4 — send the confirmation

Add a confirmation object to the operation’s request body:
This is the same confirmation shape used by every other step-up in the API — see Confirm with a passkey.

​
Errors

Both are 422, with the code in the response body:
The message on SCA_MISSING names the accepted method: "Authentication is required (passkey)" for an SSO session, versus "Authentication is required (passkey, TOTP, or PIN)" elsewhere. Branch on the code, not the message text.

​
Building for it

1

Ship enrolment with your first release

Add a passkey screen and prompt existing users. Without enrolled users, payees, international payments, batches, invites, and card details are all unreachable.
2

Handle 422 as a prompt, not a failure

Treat SCA_MISSING as “ask the user to confirm”, run the challenge, and retry the same call. Do not surface it as an error.
3

Check device support

Passkeys need WebAuthn. Detect support before you offer it — see the support check — and tell users which of their devices can enrol.
4

Ask us if you get stuck

Contact the team if enrolment or step-up doesn’t behave as described here.