Device patterns
Same-device, different-device, and wildcard flows for identification and signing.
| Pattern | Endpoint suffix | When to use | Typical platform |
|---|---|---|---|
| Same-device | /same-device | User completes on the same device as your app | Native mobile |
| Different-device | /different-device | User starts on your app (e.g. browser), completes on phone | Web |
| Wildcard | /wildcard | Target NIN unknown; secure-start via seeds (1–10) | Flexible onboarding, QR |
Applies separately to identification and signing route groups.
Same-device (autostart)
pasby is distributed mobile-first: most users have the pasby app on phone or tablet. Same-device flows run when your service is opened on that same device. After POST …/same-device, open the returned link (often on open.pasby.africa) or use a pasby button.
Different-device (direct start)
The user starts on your app (e.g. desktop browser) and completes on their phone. Pass the target user (NIN) on identification or signing. Requires scope identification:another / signing:another.
Wildcard (secure start)
When you do not know the NIN upfront, use wildcard: pass seeds (integer 1–10) and render a QR or deep link from the returned seed payload. Any eligible pasby user may complete (subject to your app’s scopes and policy).
Wildcard notes
- Omit
user/ninon wildcard identification; includeseedsinstead. - Wildcard signing with
action: signstill requires a webhook. - Strict per-signer NIN constraints are incompatible with wildcard (by design).
- Some restricted scopes (e.g. certain
identification:anotheruse cases) may require pasby approval — contact support if your sector needs elevated access.