ਡਿਜੀਟਲ ਪਾਸ ਅਤੇ ਐਕਸੇਸ ਕਾਰਡ ਲਈ ਮੋਬਾਈਲ ਐਪ ਕਿਵੇਂ ਬਣਾਈਏ

ਵਰਕ ਕੇਸ ਅਤੇ ਸਫਲਤਾ ਮੈਟਰਿਕਸ ਸਪਸ਼ਟ ਕਰੋ

QR vs NFC—ਜਾਂ Apple Wallet vs in-app pass ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਨਿਰਣਯ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਪਰੋਜੈਕਟ ਵਿੱਚ “ਡਿਜੀਟਲ ਪਾਸ” ਦਾ ਮਤਲਬ ਕੀ ਹੈ। ਇੱਕੋ ਐਪ employee access badges, member IDs, event tickets, ਜਾਂ time-limited visitor passes ਜਾਰੀ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਹਰ ਇੱਕ ਦੀਆਂ ਪਛਾਣ-ਜਾਂਚ, ਰੱਦਗੀ ਅਤੇ ਕ੍ਰੈਡੈਂਸ਼ਲ ਬਦਲਣ ਦੀ ਆਵਰਤੀ ਲਈ ਵੱਖ-ਵੱਖ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ.

ਪਾਸ ਕਿਸਮ (ਅਤੇ ਵਾਸਤਵਿਕ ਵਰਕਫਲੋ) ਨਿਰਧਾਰਤ ਕਰੋ

ਅੰਤ-ਤੱਕ ਕੀ ਹੁੰਦਾ ਹੈ, ਕੌਣ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦਰਵਾਜ਼ੇ 'ਤੇ “ਸਫਲਤਾ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਇਹ ਲਿਖੋ।

ਉਦਾਹਰਨ ਲਈ:

• Access badge: ਇੱਕ ਵਿਅਕਤੀ ਨਾਲ ਜੁੜਿਆ; ਤੇਜ਼ ਅਨਲਾਕ ਦੀ ਲੋੜ; offboard ਹੋਣ 'ਤੇ ਤੁਰੰਤ ਰੱਦ ਕਰਨਾ।
• Membership pass: ਸਖਤ ਐਕਸੈਸ ਕੰਟਰੋਲ ਨਾਲੋਂ ਆਸਾਨ ਦਰਜਾ ਅਤੇ ਨਵੀਨੀਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦੇ ਸਕਦਾ ਹੈ।
• Tickets: ਉੱਚ-ਥਰੂਪੁੱਟ ਸਕੈਨਿੰਗ, ਨਕਲ ਰੋਕਥਾਮ, ਛੋਟੀ ਵੈਧਤਾ ਖਿੜਕੀ।
• Visitor pass: ਇੱਕ ਕਰਮਚਾਰੀ ਵੱਲੋਂ ਪ੍ਰਾਇਮ ਕੀਤਾ ਗਿਆ; ਆਟੋਮੈਟਿਕ ਅਵਧੀਅੰਤ; ਕੁਝ ਖੇਤਰਾਂ ਲਈ ਸੀਮਿਤ ਹੋ ਸਕਦਾ ਹੈ。

ਮੁੱਖ ਯੂਜ਼ਰਾਂ ਦੀ ਪਛਾਣ ਕਰੋ (ਸਿਰਫ “ਐਂਡ ਯੂਜ਼ਰ” ਨਹੀਂ)

ਉਹ ਲੋਕ ਜੋ ਸਿਸਟਮ ਨੂੰ ਛੁਹਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਲੱਖਾਂ ਲਿਖੋ:

• Employees/customers/visitors: ਸਧਾਰਣ ਸੈੱਟਅਪ, ਭਰੋਸੇਯੋਗ ਦਾਖਲਾ, ਘੱਟ ਰੁਕਾਵਟ।
• Admins/security staff: ਜਾਰੀ ਕਰੋ, ਰੱਦ ਕਰੋ, ਆਡਿਟ ਕਰੋ, exemptions ਸੰਭਾਲੋ (ਲੌਸਟ ਫ਼ੋਨ,Denied entry)।
• Front desk/event staff: ਤੇਜ਼ ਤਸਦੀਕ ਅਤੇ ਭਰੀ ਦੌਰਾਨ troubleshooting।

ਮੈਟਰਿਕ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਮੈਜ਼ਰ ਕਰ ਸਕੋ

ਉਹ ਮੈਟਰਿਕ ਚੁਣੋ ਜੋ user experience ਅਤੇ operations ਦੋਹਾਂ ਨਾਲ ਜੁੜਦੇ ਹਨ:

• Activation rate: ਭੇਜੇ ਗਏ ਯੂਜ਼ਰਾਂ ਦਾ % ਜੋ ਸਫਲਤਾਪੂਰਵਕ ਪਾਸ ਜੋੜਦੇ/ਸਕ੍ਰੋਲੇਟ ਕਰਦੇ ਹਨ।
• Door-open success rate: ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ 'ਚ ਸਫਲ unlocks/scans।
• Time-to-issue: ਬੇਨਤੀ/ਮਨਜ਼ੂਰੀ ਤੋਂ ਲੈ ਕੇ ਕ੍ਰੈਡੈਂਸ਼ਲ ਵਰਤਣਯੋਗ ਹੋਣ ਤੱਕ।
• Support tickets: ਆਵਾਜਾਈ, ਮੁੱਖ ਕਾਰਨ, ਅਤੇ time-to-resolution।

ਆਫਲਾਈਨ ਪਹੁੰਚ (ਅਤੇ ਇਸ ਦੀਆਂ ਸੀਮਾਵਾਂ) ਦਾ ਜਲਦੀ ਫੈਸਲਾ ਕਰੋ

ਜੇ ਦਰਵਾਜ਼ੇ ਜਾਂ ਸਕੈਨਰ ਨੈੱਟਵਰਕ ਬਿਨਾਂ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਆਫਲਾਈਨ ਪਹੁੰਚ ਕਿੰਨੀ ਦੇਰ ਲਈ ਵੈਧ ਰਹੇਗੀ (ਮਿਨਟ, ਘੰਟੇ, ਦਿਨ) ਅਤੇ ਜਦੋਂ ਪਾਸ ਰੱਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ। ਇਹ ਚੋਣ ਕ੍ਰੈਡੈਂਸ਼ਲ ਡਿਜ਼ਾਇਨ, ਰੀਡਰ ਕਨਫਿਗਰੈਸ਼ਨ ਅਤੇ ਭਵਿੱਖ ਦੇ ਤੁਹਾਡੇ ਸੇਂਕਿਊਰਿਟੀ ਮਾਡਲ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ।

ਪਾਸ ਕਿਵੇਂ ਪੇਸ਼ ਕੀਤਾ ਜਾਵੇ: QR, NFC, ਅਤੇFallbacks

ਤੁਹਾਡਾ “ਡਿਜੀਟਲ ਪਾਸ” ਸਿਰਫ ਉਸ ਸਮੇਂ ਤੱਕ ਵਧੀਆ ਹੈ ਜਦੋਂ ਉਹ ਸਕੈਨ ਜਾਂ ਟੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਕ੍ਰੀਨਾਂ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਰੀਡਰ ਕੀ ਲੈਗਾ ਅਤੇ ਯੂਜ਼ਰ ਅਸਲ ਹਾਲਾਤਾਂ (ਭੀੜ, ਖਰਾਬ ਕਨੈਕਟੀਵਿਟੀ, ਠੰਡੀ, ਦਸਤਾਨੇ) ਵਿੱਚ ਕੀ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪੇਸ਼ ਕਰ ਸਕਦੇ ਹਨ।

ਆਮ ਪੇਸ਼ਕਾਰੀ ਵਿਕਲਪ (ਅਤੇ ਉਹ ਕਿਸ ਲਈ ਚੰਗੇ ਹਨ)

QR codes ਯੂਨੀਵਰਸਲ ਅਤੇ ਸਸਤੇ ਹਨ: ਕਿਸੇ ਵੀ ਕੈਮਰਾ-ਆਧਾਰਤ ਸਕੈਨਰ—ਅਥਵਾ ਵਿਜ਼ੂਅਲ ਪੜਤਾਲ ਲਈ ਫੋਨ ਕੈਮਰਾ—ਦੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਪ੍ਰਤੀ ਵਿਅਕਤੀ NFC ਜਿਹੇ ਟੈਪ ਦੀ ਤਰ੍ਹਾਂ ਤੇਜ਼ ਨਹੀਂ ਹੁੰਦੇ ਅਤੇ ਜੇ ਤੁਸੀਂ ਸਟੈਟਿਕ ਕੋਡ ਤੇ ਨਿਰਭਰ ਹੋ ਤਾਂ ਕੌਪੀ ਹੋਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।

NFC (ਟੈਪ) ਭੌਤਿਕ ਬੈਜ ਦੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇਹ ਤੇਜ਼ ਅਤੇ ਜਾਣ-ਪਛਾਣ ਵਾਲਾ ਹੈ, ਪਰ ਇਹ ਅਨੁਕੂਲ ਦਰਵਾਜ਼ਾ ਰੀਡਰ ਅਤੇ ਡਿਵਾਈਸ ਸਪੋਰਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਦੇ ਪਲੇਟਫਾਰਮ ਪਾਬੰਦੀਆਂ ਵੀ ਹੁੰਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਕਾਰਡ ਇਮੀਲੇਟਰ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ Wallet-based credentials ਵਰਤਣੇ ਪੈਣਗੇ)।

Bluetooth (hands-free) ਐਕਸੇਸਿਬਿਲਟੀ ਅਤੇ ਰਫ਼ਤਾਰ ਵਿੱਚ ਸੁਧਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਟਿਊਨ ਕਰਨਾ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੈ (ਰੈਂਜ, ਹਸਤਕਸ਼ੇਪ) ਅਤੇ ਇਹ “ਕਿਉਂ ਨਹੀਂ ਖੁੱਲਿਆ?” ਵਰਗੇ ਪਲ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।

One-time links / in-app codes (ਰੋਟੇਟਿੰਗ ਕੋਡ, ਸਾਈਨ ਕੀਤੇ ਟੋਕਨ) ਮਜ਼ਬੂਤ fallback ਹੁੰਦੇ ਹਨ ਅਤੇ cloning ਰਿਸਕ ਘਟਾ ਸਕਦੇ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਐਪ ਲੌਜਿਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਡਿਜ਼ਾਇਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕਦੇ-ਕਦੇ ਨੈੱਟਵਰਕ ਆਮਦਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਤਕਨੀਕ ਨੂੰ ਆਪਣੀਆਂ ਪਾਬੰਦੀਆਂ ਨਾਲ ਮਿਲਾਓ

ਹਰ ਇਕ ਤਰੀਕੇ ਨੂੰ ਮਿਲਾਓ: ਮੌਜੂਦਾ ਰੀਡਰ ਹਾਰਡਵੇਅਰ, ਥਰੂਪੁੱਟ (ਲੋਕ/ਮਿੰਟ), ਆਫਲਾਈਨ ਲੋੜਾਂ, ਬਜਟ, ਅਤੇ ਸਹਾਇਤਾ ਭਾਰ। ਉਦਾਹਰਨ: ਉੱਚ-ਟ੍ਰੈਫਿਕ ਟਰਨਸਟਾਇਲ ਆਮ ਤੌਰ 'ਤੇ NFC ਦੀ ਰਫ਼ਤਾਰ ਮੰਗਦੇ ਹਨ; ਅਸਥਾਈ ਇਵੈਂਟ ਦਰਵਾਜ਼ੇ QR ਨੂੰ ਸਹਿਣਸ਼ੀਲ ਮੰਨ ਸਕਦੇ ਹਨ।

ਪਰਾਇਮਰੀ ਢੰਗ ਅਤੇ ਇੱਕ ਸੋਚ-ਸਮਝ ਕੇ fallback ਚੁਣੋ

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਪੈਟਰਨ ਹੈ NFC primary + QR fallback। NFC ਤੇਜ਼ੀ ਲਈ ਹੈ; QR ਬੁਨਿਆਦੀ ਫੋਨਾਂ, ਖਰਾਬ NFC, ਜਾਂ ਜਿਨ੍ਹਾਂ ਜਗਾਂ 'ਤੇ NFC ਰੀਡਰ ਨਹੀਂ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਕਵਰੇਜ ਦਿੰਦਾ ਹੈ।

“ਖਰਾਬ ਦਿਨ” ਦੇ ਸਨਾਰੀਓ ਪਲਾਨ ਕਰੋ

ਠੀਕ ਢੰਗ ਨਾਲ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ ਕੀਤਾ ਹੋਵੇ ਜਦੋਂ:

• Phone locked: ਕੀ ਪਾਸ ਲੌਕ ਸਕ्रीन (Wallet) ਤੋਂ ਪੇਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਯੂਜ਼ਰ ਨੂੰ ਐਪ unlock ਕਰਨੀ ਪਵੇਗੀ?
• No network: ਕੀ ਕ੍ਰੈਡੈਂਸ਼ਲ ਆਫਲਾਈਨ ਤਸਦੀਕਯੋਗ ਹੈ (signed token, cached entitlement), ਅਤੇ ਕਿੰਨੀ ਦੇਰ ਲਈ?
• Low battery / dead phone: ਕੀ ਤੁਸੀਂ ਅਸਥਾਈ ਪ੍ਰਿੰਟ ਕੀਤਾ QR, ਸਾਈਟ-ਉੱਤੇ override, ਜਾਂ ਬੈਕਅੱਪ ਫਿਜ਼ਿਕਲ ਕਾਰਡ ਦਿੰਦੇ ਹੋ?

ਇਹ ਫੈਸਲੇ ਰੀਡਰ ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਸੁਰੱਖਿਆ ਰਵੈਏ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਯੂਜ਼ਰ ਸਹਾਇਤਾ ਪਲੇਬੁੱਕ ਨੂੰ ਆਕਾਰ ਦਿੰਦੇ ਹਨ।

ਫ਼ੈਸਲਾ ਕਰੋ: In-App Passes vs. Apple Wallet ਅਤੇ Google Wallet

ਇਹ ਨਿਰਣਯ ਸ਼ੁਰੂ ਵਿੱਚ ਕਰੋ ਕਿਉਂਕਿ ਇਹ ਰੀਡਰ ਇੰਟੇਗ੍ਰੇਸ਼ਨ, ਯੂਜ਼ਰ ਅਨੁਭਵ, ਅਤੇ ਸੁਰੱਖਿਆ ਪਾਬੰਦੀਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਵਿਕਲਪ A: In-app passes (ਤੁਹਾਡੇ ਐਪ ਦੇ ਅੰਦਰ)

In-app pass ਤੁਹਾਡੇ ਐਪ ਵੱਲੋਂ ਰੇਂਡਰ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਹੁੰਦਾ ਹੈ। ਇਹ UI, authentication, analytics, ਅਤੇ ਕਸਟਮ ਵਰਕਫਲੋਜ਼ 'ਤੇ ਜ਼ਿਆਦਾ ਕੰਟਰੋਲ ਦਿੰਦਾ ਹੈ।

ਫਾਇਦੇ: ਪੂਰਾ branding ਅਤੇ ਕਸਟਮ ਸਕ੍ਰੀਨਾਂ, ਲਚਕੀਲਾ auth (biometrics, step-up prompts), ਅੱਧਿਕ ਸੰਦਰਭ (ਸਾਈਟ ਮੈਪ, ਨਿਰਦੇਸ਼), ਅਤੇ ਕਈ ਕ੍ਰੈਡੈਂਸ਼ਲ ਕਿਸਮਾਂ ਲਈ ਆਸਾਨ ਸਹਾਇਤਾ।

ਨੁਕਸਾਨ: ਯੂਜ਼ਰਾਂ ਨੂੰ ਤੁਹਾਡੀ ਐਪ ਖੋਲ੍ਹਣੀ ਪੈਂਦੀ ਹੈ (ਜਾਂ ਤੁਸੀਂ ਬਣਾਇਆ widget/quick action ਵਰਤੋਂ), OS-ਸਤਰ ਦੀ ਲੌਕ-ਸਕ੍ਰੀਨ ਪਹੁੰਚ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਆਫਲਾਈਨ ਬਿਹੇਵਿਅਰ ਤੁਹਾਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ।

ਵਿਕਲਪ B: Apple Wallet / Google Wallet passes

Wallet passes (ਉਦਾਹਰਨ ਲਈ, PKPass on iOS) ਤੇਜ਼ ਪੇਸ਼ਕਾਰੀ ਲਈ ਜਾਣੇ ਜਾਂਦੇ ਹਨ।

ਫਾਇਦੇ: ਉੱਚ ਭਰੋਸਾ ਅਤੇ ਖੋਜਯੋਗਤਾ, ਲੌਕ-ਸਕ੍ਰੀਨ/ਕੁਇਕ ਐਕਸੈਸ, ਪ੍ਰਸਤੁਤੀ ਲਈ ਮਜ਼ਬੂਤ OS ਹੈਂਡਲਿੰਗ, ਅਤੇ ਤੇਜ਼ “ਕੋਡ ਦਿਖਾਓ” ਬਿਹੇਵਿਅਰ।

ਨੁਕਸਾਨ: ਪਲੇਟਫਾਰਮ ਪਾਬੰਦੀਆਂ (ਸਹਾਇਤ ਬਾਰਕੋਡ/NFC ਫਾਰਮੇਟ, ਸੀਮਿਤ ਕਸਟਮ UI), ਅੱਪਡੇਟ Wallet ਨਿਯਮਾਂ ਦਾ ਪਾਲਣ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਹਾਨੂੰ Apple/Google-ਵਿਸ਼ੇਸ਼ ਸੈਟਅਪ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ (ਸਰਟੀਫਿਕੇਟ, issuer configuration, ਅਤੇ ਕਈ ਵਾਰ review/approval)। ਡੀਪ telemetry ਵੀ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ।

ਇੱਕ ਵਰਤਣਯੋਗ ਫੈਸਲਾ ਨਿਯਮ

ਜਦੋਂ ਰਫ਼ਤਾਰ, ਜਾਣ-ਪਛਾਣ, ਅਤੇ “ਹਮੇਸ਼ਾ ਉਪਲਬਧ” ਪ੍ਰਸਤੁਤੀ ਮਹੱਤਵਪੂਰਨ ਹੋ (visitors, events, ਸਧਾਰਣ door/barcode ਵਰਕਫਲੋਜ਼), ਤਾਂ Wallet ਵਰਤੋਂ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਮਜ਼ਬੂਤ ਪਛਾਣ ਜਾਂ ਜਟਿਲ credential logic ਚਾਹੀਦਾ ਹੋ (multi-site staff access, approvals, role-based access), ਤਾਂ in-app ਵਰਤੋਂ।

ਕਈ ਪਾਸ ਕਿਸਮਾਂ, ਟੈਂਪਲੇਟ, ਅਤੇ branding

ਜੇ ਤੁਸੀਂ ਕਈ organizations ਨੂੰ serve ਕਰਦੇ ਹੋ, ਤਾਂ ਟੈਂਪਲੇਟ ਪ੍ਰਤੀ org ਦੀ ਯੋਜਨਾ ਬਣਾਓ: ਲੋਗੋ, ਰੰਗ, ਨਿਰਦੇਸ਼, ਅਤੇ ਵੱਖ-ਵੱਖ ਡੇਟਾ ਫੀਲਡ। ਕੁਝ ਟੀਮ ਦੋਹਾਂ ਭੇਜਦੇ ਹਨ: ਇੱਕ Wallet pass ਤੇਜ਼ ਦਾਖਲਾ ਲਈ ਅਤੇ ਇੱਕ in-app credential ਪ੍ਰਬੰਧਨ ਅਤੇ ਸਹਾਇਤਾ ਲਈ।

ਪਾਸ lifecycle ਜੋ ਤੁਸੀਂ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

ਕੰਟੇਨਰ ਕਿਸੇ ਵੀ ਹੋਵੇ, lifecycle ਕਾਰਵਾਈਆਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਟਰਿਗਰ ਕਰ ਸਕਦੇ ਹੋ:

• Issue (ਪਹਿਲੀ ਵਾਰੀ ਦਾ enrollment)
• Update (ਨਾਂ, ਐਕਸੇਸ ਲੈਵਲ, expiry, ਵਿਜ਼ੂਅਲ ਬਦਲਾਅ)
• Suspend (ਅਸਥਾਈ ਰੋਕ)
• Revoke (ਸਥਾਈ ਹਟਾਉ)
• Re-issue (ਨਵਾਂ ਡਿਵਾਈਸ, ਲੁੱਟਿਆ ਫ਼ੋਨ, ਸ਼ੱਕ ਦੀ ਸਥਿਤੀ)

ਇਹ ਕਾਰਵਾਈਆਂ in-app ਅਤੇ Wallet ਦੋਹਾਂ 'ਚ ਸਥਿਰ ਰੱਖੋ ਜਿੰਨ੍ਹਾਂ ਨਾਲ operations ਟੀਮ ਬਿਨਾਂ ਮੈਨੁਅਲ ਹੱਲਾਂ ਦੇ access ਨੂੰ ਮੈਨੇਜ ਕਰ ਸਕੇ।

ਡੇਟਾ ਮਾਡਲ ਅਤੇ ਪਾਸ lifecycle ਡਿਜ਼ਾਇਨ ਕਰੋ

ਸਾਫ਼ ਡੇਟਾ ਮਾਡਲ ਸਿਸਟਮ ਨੂੰ ਅਨੁਮਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ: ਪਾਸ ਜਾਰੀ ਕਰਨਾ, ਰੀਡਰ 'ਤੇ ਇਸਦੀ ਤਸਦੀਕ, ਰੱਦਗੀ ਅਤੇ ਘਟਨਾਵਾਂ ਦੀ ਜਾਂਚ ਸਪਸ਼ਟ ਕਵੈਰੀਆਂ ਹੋਣ ਚਾਹੀਦੀਆਂ ਹਨ—ਅਨੁਮਾਨ ਨਹੀਂ।

ਕੋਰ ਐਨਟਿਟੀਜ਼ ਜੋ ਮਾਡਲ ਕਰਨੀ ਚਾਹੀਦੀਆਂ ਹਨ

ਛੋਟੀ ਸੈਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜ਼ਰੂਰਤ ਹੋਣ 'ਤੇ ਹੀ ਵਧਾਓ:

• User: ਜਿਸ ਵਿਅਕਤੀ ਨੂੰ ਐਕਸੈਸ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ।
• Organization / Site: ਜਿਸਦਾ ਸਿਸਟਮ ਮਲਿਕ ਹੈ (ਅਤੇ ਜਿੱਥੇ ਐਕਸੈਸ ਲਾਗੂ ਹੁੰਦਾ ਹੈ)।
• Pass: ਯੂਜ਼ਰ-ਮੁਖੀ “ਕਾਰਡ” (ਜੋ ਐਪ ਜਾਂ Wallet ਦਿਖਾਉਂਦਾ ਹੈ)।
• Credential: ਰੀਡਰ ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਜਾਣ ਵਾਲਾ ਟੋਕਨ (NFC credential, QR payload ਆਦਿ)। ਇੱਕ ਪਾਸ ਦੇ ਕੋਲ ਸਮੇਂ ਦੇ ਨਾਲ ਕਈ credentials ਹੋ ਸਕਦੇ ਹਨ।
• Device: ਫ਼ੋਨ ਇੰਸਟੈਂਸ ਜੋ ਕ੍ਰੈਡੈਂਸ਼ਲ ਰੱਖਦਾ/ਦਿਖਾਉਂਦਾ ਹੈ।
• Reader / Door: ਭੌਤਿਕ endpoint (reader ID, door ID, location)।
• Access policy: ਨਿਯਮ ਜੋ ਯੂਜ਼ਰ/ਗਰੁੱਪਸ ਨੂੰ ਦਰਵਾਜ਼ਿਆਂ ਅਤੇ ਟਾਈਮਸ਼ੀਡਿਊਲ ਨਾਲ ਜੋੜਦੇ ਹਨ।

ਇਹ ਵੱਖ-ਵੱਖਤਾ ਮਦਦ ਕਰਦੀ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਫੋਨ ਬਦਲਦਾ ਹੈ: pass ਸੰਕਲਪਾਤਮਕ ਤੌਰ 'ਤੇ ਇੱਕੋ ਰਹਿ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ credentials ਰੋਟੇਟ ਹੋਂਦੀਆਂ ਅਤੇ devices ਬਦਲਦੇ ਹਨ।

ਪਾਸ ਸਟੇਟਸ ਅਤੇ lifecycle

ਪ੍ਰਤੱਖ ਸਟੇਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਨਿਰਧਾਰਤ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿਓ:

• pending (invite/enrolling)
• active (usable)
• suspended (ਅਸਥਾਈ ਰੁਕਾਵਟ)
• expired (ਸਮਾਂ ਸਮਾਪਤ)
• revoked (ਸਥਾਈ ਅਵੈਧ)

ਉਦਾਹਰਨ ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ: pending → active verification ਤੋਂ ਬਾਅਦ; active → suspended ਨੀਤੀ ਉਲੰਘਣਾਂ ਲਈ; active → revoked ਨੌਕਰੀ ਖ਼ਤਮ ਹੋਣ 'ਤੇ; suspended → active admin ਦੁਆਰਾ ਰੀਸਟੋਰ ਦੇ ਬਾਅਦ।

ਪਹਚਾਣਕ ਅੰਕ (Identifiers) ਅਤੇ ਰੀਡਰ ਨਾਲ ਮੈਪਿੰਗ

ਦੋ ਪੱਧਰਾਂ 'ਤੇ ਯੂਨੀਕ IDs ਦੀ ਯੋਜਨਾ ਬਣਾਓ:

• ਇੱਕ ਸਥਿਰ pass_id (ਅੰਦਰੂਨੀ) lifecycle ਅਤੇ ਸਹਾਇਤਾ ਲਈ।
• ਇੱਕ ਜਾਂ ਵੱਧ credential_id / token_id ਜੋ ਰੀਡਰ ਤਸਦੀਕ ਕਰ ਸਕਦੇ ਹਨ।

ਫੈਸਲਾ ਕਰੋ ਕਿ ਰੀਡਰ ਟੋਕਨਾਂ ਨੂੰ ਐਕਸੈਸ ਨੀਤੀਆਂ ਨਾਲ ਕਿਵੇਂ ਜੋੜਦਾ ਹੈ: direct lookup (token → user → policy) ਜਾਂ token → policy group (ਏਜ 'ਤੇ ਤੇਜ਼)। Identifiers ਨੂੰ non-guessable ਰੱਖੋ (random, sequential ਨਹੀਂ)।

ਆਡਿਟ ਲੌਗ: ਕੀ ਰਿਕਾਰਡ ਕਰਨ ਅਤੇ ਕਿੱਥੇ

ਆਡਿਟ ਲੌਗਜ਼ ਨੂੰ append-only ਮੰਨੋ ਅਤੇ “current state” ਟੇਬਲਾਂ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਘੱਟੋ-ਘੱਟ 기록:

• issue (ਕੌਣ ਜਾਰੀ ਕੀਤਾ, ਕਿਸ ਨੂੰ, ਡਿਵਾਈਸ, ਸਮਾਂ)
• scan (ਰੀਡਰ, ਨਤੀਜਾ, ਰੀਜ਼ਨ ਕੋਡ)
• deny (policy mismatch, expired, revoked, offline failure)
• revoke/suspend/reactivate (actor, justification, time)

ਇਹ ਘਟਨਾਵਾਂ troubleshooting, compliance, ਅਤੇ abuse detection ਲਈ ਤੁਹਾਡੀ ਸੋурс ਆਫ਼ ਟਰੂਥ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।

ਯੂਜ਼ਰ ਐਨਰੋਲਮੈਂਟ ਅਤੇ ਪਾਸ ਜਾਰੀ ਕਰਨ ਦਾ ਫਲੋ ਬਣਾਓ

ਡਿਜੀਟਲ ਪਾਸ ਪਰੋਜੈਕਟ “ਪਹਿਲੇ 5 ਮਿੰਟ” ਅਨੁਭਵ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਅਸਲ ਵਿਅਕਤੀ ਕਿਵੇਂ Enrollment ਕਰਦਾ ਹੈ, ਕ੍ਰੈਡੈਂਸ਼ਲ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਅਗਲੇ ਕਦਮ ਨੂੰ ਸਮਝਦਾ ਹੈ।

Enrollment paths (1–2 ਪ੍ਰਾਇਮਰੀ ਚੁਣੋ)

ਅਧਿਕांश ਟੀਮ ਹੇਠਾਂ ਦਿੱਤੇ ਰਸਤਿਆਂ ਦਾ ਮਿਕਸ ਸਹਾਇਤਾ ਕਰਦੀਆਂ ਹਨ, ਸੁਰੱਖਿਆ ਅਤੇ deployment ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ:

• Invite link: ਇੱਕ admin (ਜਾਂ HR ਸਿਸਟਮ) ਸਮੇਂ-ਸੀਮਿਤ ਲਿੰਕ ਜਨਰੇਟ ਕਰਦਾ ਹੈ। ਯੂਜ਼ਰ ਇਸਨੂੰ ਆਪਣੇ ਫੋਨ 'ਤੇ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਸਿੱਧਾ ਠੀਕ ਫਲੋ 'ਚ ਆ ਜਾਂਦਾ ਹੈ।
• Email/SMS verification: ਇਕ-ਵਾਰ ਦਾ ਕੋਡ ਭੇਜੋ ਤਾਂ ਕਿ ਫ਼ੋਨ ਨੰਬਰ ਜਾਂ ਈਮੇਲ ਦੀ ਪੁਸ਼ਟੀ ਹੋ ਸਕੇ।
• SSO: ਕਰਮਚਾਰੀਆਂ ਲਈ SAML/OIDC ਵਰਤੋ ਤਾਂ ਕਿ pass ਸਿਰਫ਼ corporate sign-in ਤੋਂ ਬਾਅਦ ਜਾਰੀ ਹੋਵੇ।
• Admin approval: ਉੱਚ-ਸੁਰੱਖਿਆ ਸਾਈਟਾਂ ਲਈ, ਬੇਨਤੀ ਨੂੰ review queue ਵਿੱਚ ਰੱਖੋ (reason codes, timestamps, audit trail)।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਪੈਟਰਨ: invite link → verify email/SMS → (optional) SSO → issue pass.

ਪਾਸ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ (ਅਤੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਿਵੇਂ ਗਾਇਡ ਕੀਤਾ ਜਾਵੇ)

ਜਾਰੀ ਕਰਨ ਨੂੰ ਐਸਾ ਬਣਾਓ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ “ਖੋਜਣਾ” ਨਾ ਪਵੇ:

• In-app pass: ਕ੍ਰੈਡੈਂਸ਼ਲ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਹੈ; ਤੁਸੀਂ ਅੱਪਡੇਟ ਅਤੇ UI ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਸਟਮ authentication, ਆਫਲਾਈਨ ਨਿਯਮ, ਜਾਂ ਵਿਸ਼ੇਸ਼ ਰੀਡਰ ਬਿਹੇਵਿਅਰ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇਹ ਚੰਗਾ ਹੈ।
• Wallet add: verification ਤੋਂ ਬਾਅਦ “Add to Apple Wallet” / “Add to Google Wallet” ਬਟਨ ਦਿਓ। Invite ਤੋਂ wallet-add ਸਕਰੀਨ ਖੋਲ੍ਹਣ ਲਈ deep links ਵੀ ਸਹਾਇਤਾ ਕਰੋ।
• QR invitation fallback: ਸਾਈਟ 'ਤੇ, receptionist kiosk QR ਦਿਖਾਵੇ ਜੋ enrollment link ਖੋਲ੍ਹਦਾ ਹੈ (ਜਦੋਂ ਯੂਜ਼ਰ ਨੂੰ ਈਮੇਲ ਨਾ ਮਿਲੇ ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ)।

ਕਾਪੀ ਬਹੁਤ ਸਾਫ਼ ਰੱਖੋ: ਇਹ ਪਾਸ ਕਿਸ ਲਈ ਹੈ, ਇਹ ਕਿੱਥੇ ਦਿਖਾਈ ਦੇਵੇਗਾ (app vs wallet), ਅਤੇ ਦਰਵਾਜ਼ੇ 'ਤੇ ਕੀ ਕਰਨਾ ਹੈ।

ਡਿਵਾਈਸ ਬਦਲਾਅ ਅਤੇ re-issuance ਨਿਯਮ

ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਯੋਜਨਾ ਬਣਾਓ ਤਾਂ ਕਿ support tickets ਨਾ ਬਣਨ:

• New phone: ਇੱਕ self-serve re-enrollment ਫਲੋ ਦਿਓ ਜੋ ਪਛਾਣ ਨੂੰ ਦੁਬਾਰਾ ਸਤ੍ਹਾਪਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਪਾਸ ਨੂੰ ਮੁੜ ਜਾਰੀ ਕਰਦਾ ਹੈ।
• Multiple devices: ਇਹ ਆਗਿਆ ਦਿਓ ਜਾਂ ਨਾ, ਫੈਸਲਾ ਕਰੋ। ਜੇ ਆਗਿਆ ਦਿੰਦੇ ਹੋ ਤਾਂ ਗਿਣਤੀ ਸੀਮਤ ਕਰੋ ਅਤੇ settings ਵਿੱਚ active devices ਦਿਖਾਓ।
• Lost device: ਤੁਰੰਤ remote revoke ਯੋਗ ਬਣਾਓ, ਫਿਰ re-issue ਦੁਬਾਰਾ-ਪਛਾਣ ਤੋਂ ਬਾਅਦ।

ਅਸਲ-ਦੁਨੀਆ ਦੀਆਂ ਫੇਲਿਅਰ ਲਈ ਯੂਜ਼ਰ ਸੁਨੇਹੇ

ਦੋਸਤਾਨਾ, ਵਿਸ਼ੇਸ਼ ਸੁਨੇਹੇ ਲਿਖੋ:

• Denied access (ਅਗਲਾ ਕਦਮ: “Contact security” ਬਣਾਮ “Try again after refresh”)
• Expired pass (expiry date ਅਤੇ renewal action ਸ਼ਾਮِل ਕਰੋ)
• Connectivity issues (ਸਪਸ਼ਟ ਕਰੋ ਕਿ ਆਫਲਾਈਨ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਆਨਲਾਈਨ ਹੋਣ 'ਤੇ ਕਿਵੇਂ ਰਿਕਵਰ ਕਰਨਾ ਹੈ)

ਚੰਗੀ issuance ਸਿਰਫ਼ “ਪਾਸ ਬਣਾਉਣ” ਨਹੀਂ—ਇਹ ਇੱਕ ਸੰਪੂਰਨ, ਸਮਝਣਯੋਗ ਯਾਤਰਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪੇਸ਼ਗੋਈਯੋਗ ਰਿਕਵਰੀ ਰਾਸ਼ਤੇ ਹੋਣ।

ਯੂਜ਼ਰ ਅਤੇ ਐਡਮਿਨ ਲਈ Authentication ਅਤੇ Authorization

ਡਿਜੀਟਲ ਪਾਸ ਉਸ ਪਛਾਣ ਅਤੇ ਅਧਿਕਾਰ ਤੋਂ ਹੀ ਭਰੋਸੇਯੋਗ ਹਨ ਜੋ ਉਨ੍ਹਾਂ ਦੇ ਪਿਛੇ ਹੈ। Authentication (ਤੁਸੀਂ ਕੌਣ ਹੋ) ਅਤੇ Authorization (ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ) ਨੂੰ ਪਹਿਲੀ ਕਲਾਸ ਪ੍ਰੋਡਕਟ ਫੀਚਰ ਵਜੋਂTreat ਕਰੋ, ਸਿਰਫ਼ ਪਲੰਬਿੰਗ ਵਜੋਂ ਨਹੀਂ।

Authentication ਪদ্ধਤੀ ਚੁਣਨਾ

ਉਹ ਲੌਗਿਨ ਤਰੀਕਾ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਦਰਸ਼ਕ ਅਤੇ ਜੋਖਮ ਪੱਧਰ ਨੂੰ ਮਿਲੇ:

• Email + one-time passcode (OTP): consumers ਲਈ ਆਸਾਨ, ਘੱਟ password resets।
• Passwordless “magic link”: low-friction enrollment ਲਈ ਵਧੀਆ, ਪਰ ਭਰੋਸੇਯੋਗ email delivery ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• SSO / enterprise identity (SAML/OIDC): ਕਰਮਚਾਰੀਆਂ, ਠੇਕੇਦਾਰਾਂ, ਅਤੇ ਕੈਂਪਸਾਂ ਲਈ ਸਰਵੋਤਮ; HR/IT ਨੀਤੀਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਕਈ tenants (ਵੱਖ-ਵੱਖ organizations) ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਤੋਂ ਵੱਧ tenant ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ context ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ।

Authorization: roles, scopes, ਅਤੇ auditability

Roles ਸਾਦੇ ਭਾਸ਼ਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ: Pass Holder, Front Desk, Security Admin, Auditor), ਫਿਰ ਉਹਨਾਂ ਨੂੰ permissions ਨਾਲ ਮੈਪ ਕਰੋ:

• ਕੌਣ issue, reissue, revoke, ਜਾਂ suspend ਕਰ ਸਕਦਾ ਹੈ
• ਕੌਣ view access logs ਅਤੇ reports export ਕਰ ਸਕਦਾ ਹੈ
• ਕੌਣ facility rules (door groups, schedules) ਬਦਲ ਸਕਦਾ ਹੈ

Authorization checks 서버 'ਤੇ ਰੱਖੋ (ਸਿਰਫ UI 'ਤੇ ਨਹੀਂ), ਅਤੇ ਹਰ ਸੰਵੇਦਨਸ਼ੀਲ ਕਾਰਵਾਈ ਨੂੰ who, what, when, where (IP/device) ਨਾਲ ਲੌਗ ਕਰੋ, ਨਾਲ ਹੀ admin actions ਲਈ reason ਫੀਲਡ ਰੱਖੋ।

Sessions, device trust, ਅਤੇ ਯੂਜ਼ਰ ਸਹੂਲਤ

ਛੋਟੇ-ਅਬਾਦ ਵਾਲੇ access tokens ਨੂੰ refresh tokens ਨਾਲ ਵਰਤੋ, ਅਤੇ pass ਦਿਖਾਉਣ ਲਈ biometrics (Face ID/Touch ID) 'ਤੇ ਸੁਰੱਖਿਅਤ ਦੁਬਾਰਾ ਦਾਖਲਾ ਸਹਾਇਤਾ ਕਰੋ।

ਉੱਚ-ਸੁਰੱਖਿਆ deployments ਲਈ, device binding ਜੋੜੋ ਤਾਂ ਜੋ ਇੱਕ credential ਸਿਰਫ਼ enrolled device(s) 'ਤੇਵੇਧ ਹੋਵੇ। ਇਹ ਨਕਲ ਕੀਤੇ ਟੋਕਨ ਨੂੰ ਥਾਂ ਤੋਂ ਦੂਜੇ ਥਾਂ ਉਪਯੋਗ ਕਰਨ ਨੂੰ ਮੁਸ਼ਕਲ ਕਰਦਾ ਹੈ।

Admin ਸੁਰੱਖਿਆ ਜੋ ਗਲਤੀਆਂ ਅਤੇ ਦੁਰਪਯੋਗ ਘਟਾਏ

Admin ਟੂਲਜ਼ ਨੂੰ ਵਾਧੂ guardrails ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

• Approval workflows bulk issuance ਜਾਂ privileged passes ਲਈ
• Rate limits issuance/reissue endpoints 'ਤੇ
• Alerts ਅਸਧਾਰਨ ਪੈਟਰਨ ਲਈ (ਜਿਵੇਂ ਇੱਕੋ ਈਮੇਲ ਡੋਮੇਨ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਪਾਸ ਜਾਰੀ ਹੋਣ, ਕਾਰੋਬਾਰ ਘੰਟਿਆਂ ਤੋਂ ਬਾਹਰ spikes)

ਇਹ ਨੀਤੀਆਂ ਇੱਕ internal runbook ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ admin UI ਤੋਂ ਲਿੰਕ ਕਰੋ (ਉਦਾਹਰਨ /docs/admin-security) ਤਾਂ ਜੋ operations consistent ਰਹੇ।

ਸੁਰੱਖਿਆ ਮਾਡਲ: क्लੋਨਿੰਗ, ਸਕਰੀਨਸ਼ਾਟ ਅਤੇ ਰੀਪਲੇ ਰੋਕੋ

ਡਿਜੀਟਲ ਪਾਸ ਦੀ ਸੁਰੱਖਿਆ “QR ਕੋਡ ਛੁਪਾਉਣ” ਤੋਂ ਘੱਟ ਅਤੇ ਇਸ ਬਾਰੇ ਜ਼ਿਆਦਾ ਹੈ ਕਿ ਰੀਡਰ ਕੀ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹੈ। ਠੀਕ ਮਾਡਲ ਨੈੱਟਵਰਕ, ਰੀਡਰ ਸਮਰੱਥਾ, ਅਤੇ ਰੱਦਗੀ ਦੀ ਤੀਬਰਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਰੀਡਰ ਕੀ ਤਸਦੀਕ ਕਰਦਾ ਹੈ?

ਆਮ ਤੌਰ 'ਤੇ ਤਿੰਨ ਪੈਟਰਨ ਹੁੰਦੀਆਂ ਹਨ:

• Signed payload (offline validation): QR/NFC ਵਿੱਚ ਐਸਾ payload ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੁਆਰਾ ਸਾਈਨ ਕੀਤਾ ਗਿਆ ਹੋਵੇ। ਰੀਡਰ ਸਾਈਨਚਰ ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਵੀਰੀਫਾਈ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਦਰਵਾਜ਼ੇ ਆਫਲਾਈਨ ਕੰਮ ਕਰਦੇ ਹਨ। ਇਹ ਤੇਜ਼ ਹੈ, ਪਰ ਰੱਦਗੀ ਸਿਰਫ਼ ਰੀਡਰ ਅੱਪਡੇਟਸ ਦੀ ਤੇਜ਼ੀ ਦੇ ਬਰਾਬਰ ਹੋ ਸਕਦੀ ਹੈ।
• Server check (online validation): ਰੀਡਰ ਸਕੈਨ ਕੀਤਾ ਟੋਕਨ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਨੂੰ ਰੀਅਲ-ਟਾਈਮ ਭੇਜਦਾ ਹੈ ਤਾਂ ਕਿ ਮਨਜ਼ੂਰੀ/ਅਨਮਦਨ ਹੋ ਸਕੇ। ਰੱਦਗੀ ਤੁਰੰਤ ਹੁੰਦੀ ਹੈ, ਪਰ ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਅਪਟਾਈਮ ਅਤੇ ਲੈਟੈਂਸੀ 'ਤੇ ਨਿਰਭਰ ਹੋ।
• Hybrid: ਰੀਡਰ ਪਹਿਲਾਂ ਸਾਈਨਚਰ ਵੇਰਿਫਾਈ ਕਰਦਾ ਹੈ (ਆਮ ਨਕਲਾਂ ਨੂੰ ਰੋਕਣ ਲਈ), ਫਿਰ ਉੱਚ ਜੋਖਮ ਖੇਤਰਾਂ ਲਈ ਜਾਂ ਜਦੋਂ ਕਨੈਕਟੀਵਿਟੀ ਉਪਲਬੱਧ ਹੋਵੇ ਤਾਂ ਸਰਵਰ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ।

QR ਕੋਡ: ਸਕਰੀਨਸ਼ਾਟ ਅਤੇ ਰੀਪਲੇ ਰਿਸਕ ਘਟਾਓ

ਸਟੇਟਿਕ QR ਕੋਡ ਸਾਂਝਾ ਅਤੇ ਸਕਰੀਨਸ਼ਾਟ ਲਈ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। Prefer ਕਰੋ ਰੋਟੇਟਿੰਗ ਜਾਂ ਸਮੇਂ-ਸੀਮਿਤ ਕੋਡ:

• ਛੋਟੇ ਸਮੇਂ ਲਈ ਵੈਧ token ਵਰਤੋਂ (ਉਦਾਹਰਨ, 15–60 ਸਕਿੰਟ)।
• ਜਿੱਥੇ ਸੰਭਵ ਹੋ, ਡਿਵਾਈਸ/session ਨਾਲ אליו bind ਕਰੋ (ਤਾਂ ਜੋ ਫਾਰੇਵਰ ਕੀਤਾ ਸਕ੍ਰੀਨਸ਼ਾਟ ਹੋਰਥਾਂ 'ਤੇ ਵੈਧ ਨਾ ਹੋਵੇ)।
• anti-replay ਡੇਟਾ (timestamp + nonce) ਸ਼ਾਮਿਲ ਕਰੋ ਅਤੇ backend ਨਾਲ ਉਹਨਾਂ ਟੋਕਨਾਂ ਨੂੰ ਰੱਦ ਕਰੋ ਜੋ ਪਹਿਲਾਂ ਵਰਤੇ ਜਾ ਚੁੱਕੇ ਹਨ ਜਿੱਥੇ “one-time entry” ਲੋੜੀਂਦੀ ਹੈ।

ਜੇ ਤੁਹਾਨੂੰ ਆਫਲਾਈਨ QR validation ਸਪੋਰਟ ਕਰਨੀ ਪਏ, ਤਾਂ QR ਨੂੰ time-boxed ਅਤੇ signed ਰੱਖੋ, ਅਤੇ ਮੰਨੋ ਕਿ ਅਸਲ-ਟਾਈਮ ਰੱਦਗੀ ਰੀਡਰ ਸਿੰਗ ਕਰਵਾਉਣ ਦੇ ਬਿਨਾਂ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗੀ।

NFC credentials: ਡਿਵਾਈਸ 'ਤੇ keys ਦੀ ਸੁਰੱਖਿਆ ਕਰੋ

NFC ਲਈ, ਸੋਚੋ ਕਿ ਰਾਜ਼ ਸਥਿਤ ਕਿੱਥੇ ਹਨ ਅਤੇ ਉਹ ਕਿਵੇਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ:

• credential keys ਨੂੰ hardware-backed secure storage (Secure Enclave/Keystore ਜਿੱਥੇ ਉਪਲਬਧ) ਵਿੱਚ ਰੱਖੋ।
• NFC 'ਤੇ ਲੰਬੇ-ਅਵਧੀ ਵਾਲੇ identifiers ਉਗਲੇ ਨਾ ਕਰੋ; ਜੇ ਰੀਡਰ challenge-response ਜਾਂ derived session keys ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ ਤਾਂ ਉਹ ਵਰਤੋ।
• assume ਕਰੋ ਕਿ rooted/jailbroken devices ਮੌਜੂਦ ਹਨ; hardware-backed keys ਅਤੇ server-side risk ਨੀਤੀਆਂ 'ਤੇ ਨਿਰਭਰ ਰਹੋ, app obfuscation 'ਤੇ ਨਹੀਂ।

ਰੱਦਗੀ ਦੀ ਤੇਜ਼ੀ: ਆਪਰੇਸ਼ਨਲ ਲੋੜ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਰੱਦ ਕੀਤਾ ਹੋਇਆ ਪਾਸ ਕਿੰਨੀ ਜਲਦੀ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇ (seconds, minutes, hours)। ਇਹ ਲੋੜ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ:

• Seconds: online checks (ਜਾਂ ਰੀਡਰਾਂ ਨੂੰ constant connectivity) ਆਮ ਤੌਰ 'ਤੇ ਲਾਜ਼ਮੀ ਹੁੰਦੇ ਹਨ।
• Minutes: frequent reader sync + short-lived tokens ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ।
• Hours: ਘੱਟ ਜੋਖਮ ਖੇਤਰਾਂ ਲਈ periodical updates ਸਹੀ ਹੋ ਸਕਦੇ ਹਨ।

ਇਸਨੂੰ security ਅਤੇ operations SLO ਵਜੋਂ ਲਿਖੋ ਕਿਉਂਕਿ ਇਹ ਰੀਡਰ configuration, backend availability, ਅਤੇ incident response ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਡੋਰ ਰੀਡਰਾਂ ਅਤੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਸਿਸਟਮਾਂ ਨਾਲ ਇੰਟੇਗ੍ਰੇਟ ਕਰੋ

ਇਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡੇ ਡਿਜੀਟਲ ਪਾਸ ਅਸਲ ਦੁਨੀਆ ਨਾਲ ਮਿਲਦੇ ਹਨ: turnstiles, door controllers, elevator readers ਅਤੇ front-desk scanners। ਇੱਥੇ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਚੋਣਾਂ ਭਰੋਸੇਯੋਗਤਾ, ਰਫ਼ਤਾਰ, ਅਤੇ ਨੈੱਟਵਰਕ ਨਾਹ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ, ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ।

ਰੀਡਰ ਵੈਲਿਡੇਸ਼ਨ ਰਸਤਾ ਚੁਣੋ

ਆਮ ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਰਸਤੇ:

• Reader → your API (cloud validation): ਰੀਡਰ (ਜਾਂ ਇਸਦਾ controller) ਹਰ ਟੈਪ/ਸਕੈਨ ਲਈ ਤੁਹਾਡੇ validation endpoint ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਲਚੀਲਾ, ਪਰ ਨੈੱਟਵਰਕ ਗੁਣਵੱਤਾ 'ਤੇ ਨਿਰਭਰ ਅਤੇ rate limiting ਦੀ ਲੋੜ।
• Reader → existing access control system (ACS): ਤੁਹਾਡੀ ਐਪ ਇਕ ਐਸਾ credential ਜਾਰੀ ਕਰਦੀ ਹੈ ਜੋ ACS ਸਮਝਦਾ ਹੈ, ਅਤੇ ACS allow/deny ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਦਰਵਾਜ਼ਿਆਂ 'ਤੇ ਘੱਟ ਕਸਟਮ ਲੌਜਿਕ, ਪਰ ਇਹ encoded ਡੇਟਾ 'ਤੇ ਸੀਮਿਤ ਹੋ ਸਕਦਾ ਹੈ।
• Reader → local gateway (edge validation): ਰੀਡਰ on-site service ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ ਜੋ ਲੋਕਲ ਤੌਰ 'ਤੇ credentials ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਬੈਕਐਂਡ ਨਾਲ sync ਕਰਦਾ ਹੈ। ਇਹ ਰੀਜ਼ਿਲੀਅਂਸ ਸੰਵਾਰਦਾ ਹੈ ਅਤੇ ਲੈਟੈਂਸੀ ਅਨੁਮਾਨਕਤੀ ਰਹਿੰਦੀ ਹੈ।

response-time ਅਤੇ ਆਫਲਾਈਨ ਬਿਹੇਵਿਅਰ ਟਾਰਗਿਟ ਸੈੱਟ ਕਰੋ

ਪਹਿਲਾਂ ਟਾਰਗਿਟ ਤਯਾਰ ਕਰੋ (ਉਦਾਹਰਨ: “unlock decision 300–500 ms ਵਿੱਚ”)। ਪਰ ਹਰ ਸਾਈਟ ਲਈ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਕਿ “ਆਫਲਾਈਨ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ:

• ਜੇ ਨੈੱਟਵਰਕ ਡ੍ਰੌਪ ਹੋਵੇ, ਕੀ ਤੁਸੀਂ fail closed (ਸਾਰੇ deny) ਕਰੋਗੇ ਜਾਂ fail open ਕੁਝ ਦਰਵਾਜ਼ਿਆਂ ਲਈ?
• ਕੀ ਤੁਸੀਂ cached allowlists gateway/controller 'ਤੇ ਛੋਟੀ ਮਿਆਦ ਨਾਲ ਰੱਖਦੇ ਹੋ?
• ਤੁਸੀਂ events ਨੂੰ ਬਾਅਦ ਵਿੱਚ duplicate ਨਾ ਹੋਣ ਦੇ ਨਾਲ ਕਿਵੇਂ sync ਅਤੇ ਲਾਗ ਕਰੋਗੇ?

ਇੰਟੇਗ੍ਰੇਸ਼ਨ ਪੁਆਇੰਟਸ ਦਸਤਾਵੇਜ਼ ਕਰੋ (ਗਲਤੀਆਂ ਨੂੰ ਛੱਡੋ ਨਾ)

ਉਹ ਸਿਸਟਮ ਅਤੇ ਡੇਟਾ ਜੋ ਤੁਹਾਨੂੰ ਰੇਖਾਬੱਧ ਕਰਨੇ ਹਨ:

• Badge provisioning: ਕਿਸ ਨੇ ਵਿਅਕਤੀ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਕਦੋਂ (HR system, visitor system, admin portal)?
• Access groups and schedules: roles ਨੂੰ doors, floors, time windows, ਅਤੇ holiday rules ਨਾਲ ਮੈਪ ਕਰਨਾ।
• Door and reader inventory: canonical door IDs, locations, reader types (NFC, QR), ਅਤੇ controller firmware constraints。

ਇੱਕ ਸਧਾਰਣ “source of truth” ਡਾਇਗ੍ਰਾਮ ਅੰਦਰੂਨੀ docs ਵਿੱਚ ਬਾਅਦ ਵਿੱਚ ਹਫ਼ਤੇ ਬਚਾ ਸਕਦਾ ਹੈ।

ਮਾਨੀਟਰਿੰਗ ਅਤੇ ਡਾਇਗਨੋਸਟਿਕਸ ਦੀ ਯੋਜਨਾ ਬਣਾਓ

ਰੀਡਰਾਂ ਨੂੰ production infrastructure ਵਜੋਂ treat ਕਰੋ। ਟਰੈਕ ਕਰੋ:

• Reader health: last seen timestamp, firmware version, battery/power status (ਜੇ ਉਪਲਬਧ)।
• Failure rates and latency: p95 validation time, timeouts, ਅਤੇ retries।
• Denied-access reasons: expired pass, revoked credential, outside schedule, unknown door, suspected replay।

ਇਹਨਾਂ ਨੂੰ ops ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਵੇਖਣਯੋਗ ਬਣਾਓ ਅਤੇ critical issues ਨੂੰ on-call 'ਤੇ ਰੂਟ ਕਰੋ। “ਮੈਂ ਕਿਉਂ deny ਹੋਇਆ?” ਦਾ ਤੇਜ਼ workflow rollout ਦੌਰਾਨ support load ਘਟਾਉਂਦਾ ਹੈ।

ਬੈਕਐਂਡ ਆਰਕੀਟੈਕਚਰ: APIs, Signing, ਅਤੇ Scalability

ਡਿਜੀਟਲ ਪਾਸ ਸਿਸਟਮ ਆਪਣੀ ਬੈਕਐਂਡ ਤੇ ਜ਼ਿੰਦਾ ਰਹਿੰਦਾ ਹੈ: ਇਹ credentials ਜਾਰੀ ਕਰਦਾ, validity ਨਿਯੰਤਰਤ ਕਰਦਾ, ਅਤੇ ਜਦ ਲੋਕ ਦਰਵਾਜ਼ੇ 'ਤੇ ਖੜੇ ਹੁੰਦੇ ਹਨ ਉਹ ਜੋ ਕੁਝ ਹੋਇਆ ਉਸਦਾ ਰਿਕਾਰਡ ਰੱਖਦਾ—ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰੂਪ ਵਿੱਚ।

ਕੋਰ APIs (ਸਾਦੇ ਅਤੇ versioned ਰੱਖੋ)

ਛੋਟੀ API ਸੈਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਵਿਕਸਤ ਕਰ ਸਕਦੇ ਹੋ:

• POST /v1/passes/issue — create a pass for a user, return an activation link or pass payload
• POST /v1/passes/refresh — rotate identifiers / update entitlements, return latest pass data
• POST /v1/passes/validate — verify a QR/NFC token presented at a reader (online readers)
• POST /v1/passes/revoke — immediately invalidate a pass (lost phone, terminated access)
• POST /v1/events — log entry attempts and outcomes (accepted/denied/error)

ਭਾਵੇਂ ਕੁਝ validations ਡਿਵਾਈਸ ਜਾਂ ਰੀਡਰ 'ਤੇ ਹੁੰਦੀਆਂ ਹੋਣ, ਸਰਵਰ-ਸਾਈਡ validation API audit, remote revocation, ਅਤੇ “break glass” operations ਲਈ ਬਣਾਈ ਰੱਖੋ।

Signing ਅਤੇ key management (ਸੁਰੱਖਿਅਤ ਰੋਟੇਸ਼ਨ ਨਾਲ)

ਜੇ ਤੁਸੀਂ Apple Wallet (PKPass) ਜਾਂ ਹੋਰ signed payloads ਸਹਾਇਤ ਕਰਦੇ ਹੋ, ਤਾਂ signing keys ਨੂੰ production secrets ਵਜੋਂ ਰਵਾਇਤੀ ਕਰੋ:

• private keys ਨੂੰ managed KMS/HSM ਵਿੱਚ ਰੱਖੋ; ਕਦੇ ਵੀ app servers ਜਾਂ CI logs ਵਿੱਚ ਨਾ ਰੱਖੋ।
• keys ਨੂੰ schedule 'ਤੇ rotate ਕਰੋ ਅਤੇ incidents ਤੋਂ ਬਾਅਦ; multiple active public keys ਸਹਾਇਤ ਕਰੋ ਤਾਂ ਕਿ ਪੁਰਾਣੇ passes transition ਦੌਰਾਨ ਕੰਮ ਕਰਦੇ ਰਹਿਣ।
• ਹਰ signing operation ਨੂੰ audit ਕਰੋ (who/what issued, for whom, when, with which key version)।

ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਪੈਟਰਨ ਹੈ ਇੱਕ dedicated “signing service” ਜਿਸਦਾ narrow interface ਹੋਵੇ (ਉਦਾਹਰਨ: “sign pass payload”) ਜੋ ਬਾਕੀ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਆਈਸੋਲੇਟਡ ਹੋਵੇ।

ਪੀਕ ਐਨਟਰੀ ਸਮਾਂ 'ਤੇ ਸਕੇਲ ਲਈ ਡਿਜ਼ਾਇਨ

Entry spikes predictable ਹੁੰਦੇ ਹਨ (9:00 AM, event start)। ਬਰਸਤੀ reads ਲਈ ਯੋਜਨਾ:

ਕੈਚਿੰਗ ਵਰਤੋ revocation lists ਅਤੇ entitlement lookups ਲਈ, issuance ਲਈ retries ਅਤੇ idempotency keys ਜੋੜੋ, ਅਤੇ non-critical ਕੰਮ (analytics, notifications) ਨੂੰ queue ਕਰੋ ਤਾਂ ਕਿ validation ਤੇਜ਼ ਰਹੇ। ਜੇ ਰੀਡਰ online ਹੋ ਕੇ ਜਾਂਦੇ ਹਨ, validation latency ਘੱਟ ਰੱਖਣ ਲਈ chatty dependencies ਤੋਂ ਬਚੋ।

ਪ੍ਰਾਈਵੇਸੀ ਕੰਟਰੋਲ ਅਤੇ ਲੌਗ ਰਿਟੇਂਸ਼ਨ

ਸਟੋਰ ਕੀਤੀ ਗਈ personal data ਘੱਟ ਰੱਖੋ: pass records ਅਤੇ events ਵਿੱਚ ਨਾਂ/ਈਮੇਲ ਦੀ ਬਜਾਏ internal user IDs ਵਰਤੋ। retention ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (ਉਦਾਹਰਨ, entry logs 30–90 ਦਿਨ ਰੱਖੋ ਜਦ ਤੱਕ ਲੰਮਾ ਰੱਖਣ ਲੋੜ ਨਾ ਹੋਵੇ), ਅਤੇ operational logs ਅਤੇ security/audit logs ਨੂੰ ਵੱਖ ਕਰੋ ਅਤੇ ਆਨ੍ਹੇ ਤੋਂ ਸਖ਼ਤ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਰੱਖੋ।

ਤੇਜ਼ ਬਿਲਡ ਕਰਨਾ (ਆਰਕੀਟੈਕਚਰ 'ਚ ਲਾਕ-ਇਨ ਤੋਂ ਬਿਨਾਂ)

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ iterate ਕਰ ਰਹੇ ਹੋ—admin portal, issuance APIs, ਅਤੇ ਪਹਿਲਾ ਮੋਬਾਈਲ ਅਨੁਭਵ—ਤਾਂ tools ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ pilot ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ (React for web, Go + PostgreSQL for backend, Flutter for mobile)। ਇਹ ਖਾਸ ਕਰਕੇ pilot ਬਣਾਉਣ ਲਈ ਉਪਯੋਗੀ ਹੈ ਅਤੇ ਫਿਰ ਜਦ ਤੁਸੀਂ ACS ਜਾਂ on-prem gateway ਨਾਲ ਡੀਪ ਇੰਟੇਗ੍ਰੇਟ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ, ਤਾਂ source code export ਕਰਨ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ।

ਮੋਬਾਈਲ ਐਪ UX: Setup, Display, ਅਤੇ Accessibility

ਡਿਜੀਟਲ ਪਾਸ ਉਸ ਸਕ੍ਰੀਨ 'ਤੇ ਫੇਲ ਜਾਂ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਦਰਵਾਜ਼ੇ 'ਤੇ ਵੇਖਦੇ ਹਨ। ਤਿੰਨ ਪਲਾਂ ਲਈ optimize ਕਰੋ: ਪਹਿਲੀ ਵਾਰੀ ਸੈਟਅਪ, “ਹੁਣ ਮੇਰਾ ਪਾਸ ਦਿਖਾਓ,” ਅਤੇ “ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ—ਮੈਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਹਾਇਤਾ ਦਿਓ।”

ਐਪ ਦਾ ਢੰਗ ਚੁਣੋ

• Native (iOS/Android): NFC experiences, Wallet integration, ਅਤੇ polished system behaviors ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ।
• Cross-platform (Flutter/React Native): ਸਾਂਝੀ UI ਅਤੇ ਤੇਜ਼ iteration ਲਈ ਵਧੀਆ, ਪਰ NFC, background behaviors, ਅਤੇ Wallet handoffs ਨੂੰ ਜਲਦੀ validate ਕਰੋ।
• Web-based companion: QR-only ਪ੍ਰੋਗਰਾਮ ਅਤੇ ਤੇਜ਼ pilots ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ camera permissions ਅਤੇ ਕਨੈਕਟੀਵਿਟੀ 'ਤੇ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਰਹੋਗੇ।

ਜੇ ਤੁਸੀਂ Apple Wallet / Google Wallet ਸਹਾਇਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ provisioning ਤੋਂ ਬਾਅਦ ਐਪ ਦੀ ਲੋੜ ਕਿੱਥੇ ਹੈ। ਬਹੁਤ ਯੂਜ਼ਰ “add to wallet and forget” ਨੂੰ ਪਸੰਦ ਕਰਦੇ ਹਨ।

ਪਾਸ ਡਿਸਪਲੇ ਜੋ ਦਬਾਅ ਹੇਠ ਕੰਮ ਕਰੇ

“present pass” ਸਕਰੀਨ ਨੂੰ boarding pass ਵਾਂਗ ਬਣਾਓ: ਤੁਰੰਤ, ਚਮਕੀਲਾ, ਅਤੇ ਪੜ੍ਹਨ ਵਿੱਚ ਆਸਾਨ।

• QR rendering: high-contrast ਕੋਡ ਨਾਲ wide quiet zones, orientation ਲਾਕ ਕਰੋ ਜੇ ਲੋੜ, ਅਤੇ “maximize brightness” ਪ੍ਰਮਪਟ ਸ਼ਾਮਿਲ ਕਰੋ।
• NFC tap UI: ਸਧਾਰਣ “Hold near reader” ਸਟੇਟ ਦਿਖਾਓ, ਪੋਜ਼ੀਸ਼ਨਿੰਗ ਲਈ ਐਨੀਮੇਟਿਡ hint, ਅਤੇ ਸਫਲਤਾ ਦੀ ਸਪਸ਼ਟ ਪੁਸ਼ਟੀ।
• Wallet deep links: ਇੱਕ-ਟੈਪ “Open in Wallet” / “Open in Google Wallet” action ਦਿਓ (ਉਪਭੋਗੀਆਂ ਨੂੰ ਸਿੱਧਾ ਰੀਡਾਇਰੈਕਟ ਕਰੋ)।

ਪਾਸ ਨੂੰ ਮੈਨੂਜ਼ ਦੇ ਪਿੱਛੇ ਨਹੀਂ ਛੁਪਾਓ। ਇੱਕ persistent home-screen card ਜਾਂ ਇੱਕ primary button ਦਰवਾਜ਼ੇ ਉੱਤੇ ਦੇਰੀ ਘਟਾਂਦਾ ਹੈ।

Accessibility ਅਤੇ ਸਪਸ਼ਟਤਾ

Large Text, Dynamic Type, screen reader labels (“Access pass QR code”), ਅਤੇ high-contrast ਥੀਮਾਂ ਨੂੰ ਸਹਾਇਤਾ ਕਰੋ। error ਸਟੇਟਾਂ ਨੂੰ UX ਦਾ ਹਿੱਸਾ ਮੰਨੋ: camera blocked, NFC off, pass expired, ਜਾਂ reader not responding। ਹਰ ਇੱਕ ਨੂੰ ਸਧਾਰਨ-ਭਾਸ਼ਾ fix ਦਿਓ (“Enable Camera in Settings”) ਅਤੇ fallback action ਸ਼ਾਮਿਲ ਕਰੋ।

Edge cases ਲਈ ਡਿਜ਼ਾਇਨ

Time zones ਅਤੇ device clock drift time-based passes ਨੂੰ “ਗਲਤ” ਦਿਖਾ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ venue ਦੇ time zone ਸਹਿਤ times ਦਿਖਾਓ ਅਤੇ ਇੱਕ “Last synced” ਸੋਝੀ ਇੰਗਿਤ ਸ਼ਾਮਿਲ ਕਰੋ।

ਇਹਨਾਂ ਦੀ ਯੋਜਨਾ ਵੀ ਬਣਾਓ: airplane mode, ਲਾਬੀਜ਼ ਵਿੱਚ ਖਰਾਬ reception, revoked permissions (camera/NFC), ਅਤੇ low-battery accessibility modes। ਇੱਕ ਛੋਟਾ “Troubleshoot” ਲਿੰਕ /help/mobile-pass support queues ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।

ਟੈਸਟਿੰਗ ਰਣਨੀਤੀ: ਡਿਵਾਈਸ, ਰੀਡਰ, ਆਫਲਾਈਨ, ਅਤੇ ਦੁਰਪਯੋਗ ਕੇਸ

ਮੋਬਾਈਲ ਐਕਸੇਸ ਕਾਰਡ ਐਪ ਨੂੰ ਟੈਸਟ ਕਰਨਾ “ਕੀ ਇਹ ਖੁੱਲਦਾ ਹੈ?” ਤੋਂ ਘੱਟ ਅਤੇ “ਕੀ ਇਹ ਹਰ ਵਾਰੀ, ਦਬਾਅ ਹੇਠ, ਖੁੱਲਦਾ ਹੈ?” ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਟੈਸਟਿੰਗ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਲੋੜ ਸਮਝੋ, ਨਾ ਕਿ ਇਕ ਆਖਰੀ ਚੈਕਲਿਸਟ।

ਪਰੈਟਿਕਲ ਟੈਸਟ ਮੈਟਰਿਕਸ ਬਣਾਓ

ਉਹ ਮੈਟਰਿਕਸ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰਾਂ ਦੇ ਸਹੀ ਡਿਵਾਈਸ ਅਤੇ ਤੁਹਾਡੇ ਦਰਵਾਜ਼ਿਆਂ ਦੀ ਨਿਸ਼ਾਨੀ ਹੋਵੇ:

• Devices: ਪੁਰਾਣੇ ਅਤੇ ਨਵੇਂ iPhones/Android, ਵੱਖ-ਵੱਖ ਸਕ੍ਰੀਨ ਸਾਈਜ਼, ਅਤੇ QR ਸਕੈਨਿੰਗ ਲਈ ਘੱਟ-ਕੋਸਟ ਕੈਮਰਿਆਂ ਦਾ ਮਿਕਸ।
• OS versions: ਘੱਟੋ-ਘੱਟ ਮੌਜੂਦਾ ਅਤੇ ਪਹਿਲੀ ਵੱਡੀ iOS/Android ਵਰਜ਼ਨ ਸ਼ਾਮਿਲ ਕਰੋ।
• Capabilities: NFC availability (ਅਤੇ placement), camera autofocus speed, brightness, ਅਤੇ battery saver modes।
• Reader models: ਹਰ door reader firmware/version ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ, ਨਾਲ-turnstiles ਅਤੇ handheld scanners।

In-app credentials ਅਤੇ wallet flows (Apple Wallet pass / Google Wallet pass) ਦੋਹਾਂ ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ PKPass ਬਿਹੇਵਿਅਰ ਅਤੇ system UI timing ਤੁਹਾਡੇ ਐਪ ਤੋਂ ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ।

ਅਸਲ-ਦੁਨੀਆ ਦਾਖਲਾ ਹਾਲਾਤਾਂ ਦੀ ਰਿਹਰਸਲ ਕਰੋ

Lab-perfect scans ਹਕੀਕਤ ਵਾਲੀਆਂ entry lines ਨਾਲ ਮੇਲ ਨਹੀਂ ਰੱਖਦੇ। “rush tests” ਚਲਾਓ ਜਿੱਥੇ 20–50 ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ پਾਸ ਪੇਸ਼ ਕਰਦੇ ਹਨ, back-to-back, ਨਾਲ:

• ਖਰਾਬ ਲਾਈਟਿੰਗ ਅਤੇ glare (ਬਾਹਰ ਦਾ ਸੂਰਜ, dim lobby)
• Spotty connectivity (Wi‑Fi drops, weak LTE)
• Offline mode (airplane mode + device reboot) cached credentials ਅਤੇ UX guidance ਦੀ ਜਾਂਚ ਲਈ

median time-to-entry, failure rate, ਅਤੇ recovery time ਮ ਦੇਖੋ (ਯੂਜ਼ਰ ਅਗਲਾ ਕੀ ਕਰਦਾ ਹੈ)।

ਦੁਰਪਯੋਗ ਅਤੇ ਫੇਲਿਅਰ ਸਪੈਸੀਨ ਤਸਦੀਕ ਕਰੋ

ਸક્રਿਆਟਾ ਨਾਲ ਟੈਸਟ ਕਰੋ:

• Replay attempts (ਇੱਕੋ QR ਨੂੰ ਇਸਦੀ validity window ਵਿੱਚ reuse ਕਰਨਾ)
• Screenshot use ਅਤੇ screen-recording edge cases
• Revoked pass attempts (server-side revocation ਤੋਂ ਬਾਅਦ ਤੁਰੰਤ denial)
• Rate limits ਅਤੇ repeated failures ਲਈ lockouts

ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਂਗ staging ਰੱਖੋ

staging environment ਨੂੰ test readers ਅਤੇ synthetic traffic ਨਾਲ ਰੱਖੋ ਜੋ ਪੀਕ events ਦੀ ਨਕਲ ਕਰੇ। issuance, updates, ਅਤੇ revocations ਨੂੰ load 'ਤੇ verify ਕਰੋ, ਅਤੇ logging ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਓ ਕਿ ਤੁਸੀਂ "tap/scan → decision → door result" end-to-end trace ਕਰ ਸਕੋ।

ਲਾਂਚ, ਰੋਲਆਉਟ, ਅਤੇ ਚਲਦੀ-ਰਹਿਣ ਵਾਲੀ operations

ਸਫਲ ਲਾਂਚ ਇੱਕ ਵੱਡੀ ਰਿਲੀਸ ਤੋਂ ਘੱਟ ਅਤੇ ਹਰ ਦਿਨ ਹਰ ਦਰਵਾਜ਼ੇ 'ਤੇ predictable ਦਾਖਲਾ ਹੋਣ ਵੱਧ ਹੈ। ਇੱਕ ਨਿਆਜ਼ ਰੋਲਆਉਟ, ਸਪਸ਼ਟ support paths, ਅਤੇ ਉਹ metrics ਜੋ friction ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਦੀ ਯੋਜਨਾ ਬਣਾਓ।

ਫਿਜ਼ੀਕਲ ਕਾਰਡ ਤੋਂ ਮਾਈਗ੍ਰੇਟ ਕਰੋ ਬਿਨਾ ਐਕਸੇਸ ਤੋੜੇ

ਜਿਆਦातर organizations phased rollout ਨਾਲ ਚੰਗਾ ਕਰਦੇ ਹਨ:

• Pilot group first (security team, facilities, ਇੱਕਦਫਤਰ/ਫਲੋਰ) readers, onboarding, ਅਤੇ edge cases ਨੂੰ validate ਕਰਨ ਲਈ।
• Dual-credential period ਜਿੱਥੇ ਕਰਮਚਾਰੀ physical card ਜਾਂ digital pass ਦੋਹਾਂ ਵਰਤ ਸਕਦੇ ਹਨ। ਇੱਕ ਟਾਰਗਟ end date ਰੱਖੋ, ਪਰ contractors ਜਾਂ special devices ਲਈ exceptions ਰੱਖੋ।
• Training and comms: ਛੋਟੇ “how to enter” ਨਿਰਦੇਸ਼, ਕਿੱਥੇ ਟੈਪ/ਸਕੈਨ ਕਰਨਾ ਹੈ, ਫੋਨ ਡਾਈ ਹੋ ਜਾਣ 'ਤੇ ਕੀ ਕਰਨਾ ਹੈ, ਅਤੇ ਸਹਾਇਤਾ ਕਿਵੇਂ ਮੰਗਨੀ ਹੈ।

Support playbooks ਜੋ ਤੁਸੀਂ ਵਾਕਈ ਵਰਤੋਂਗੇ

ਆਪਣੇ help desk ਅਤੇ admins ਲਈ ਸਾਦੇ, ਦੁਹਰਾਫੇ workflows ਬਣਾਓ:

• Lost phone: ਤੁਰੰਤ credential revoke ਕਰੋ; ਨਵੀਂ ਡਿਵਾਈਸ ਤੇ re-issue identity verification ਤੋਂ ਬਾਅਦ।
• Denied access: reader logs, pass status (active/expired), user permissions, ਅਤੇ time schedules ਚੈੱਕ ਕਰੋ; ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਅਸਥਾਈ fallback ਦਿਓ।
• Device switch/upgrade: ਜਿੱਥੇ ਸੰਭਵ self-serve re-enrollment, rate limits ਅਤੇ admin override ਨਾਲ।
• Re-issue: identifiers ਨੂੰ ਕਦੋਂ rotate ਕਰਨਾ ਹੈ vs same pass ਨੂੰ re-activate ਕਰਨਾ ਹੈ, ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (fraud prevention ਅਤੇ audit trails ਲਈ ਮਹੱਤਵਪੂਰਨ)।

ਇਹ playbooks ਇੱਕ ਥਾਂ 'ਤੇ ਰੱਖੋ ਅਤੇ admin console ਅਤੇ internal docs ਤੋਂ ਲਿੰਕ ਕਰੋ।

Instrumentation ਅਤੇ operational metrics

ਇਹ analytics ਜੋ ਅਸਲ entry performance ਦਰਸਾਉਂਦੀਆਂ ਹਨ, ਜੋ ਕਿ installs ਤੋਂ ਵੱਖ ਹਨ, ਸ਼ਾਮਿਲ ਕਰੋ:

• Activation funnel: invite → install → enroll → first successful entry
• Scan/tap success rate (site, door, reader model ਵਾਰ)
• Time-to-entry (median ਅਤੇ p95)
• Reader ਅਤੇ backend errors (timeouts, offline, signature failures)

ਇਨ੍ਹਾਂ metrics ਨੂੰ ਰੀਡਰ ਟਿਊਨਿੰਗ ਅਤੇ ਯੂਜ਼ਰ ਸਿੱਖਿਆ ਨੂੰ ਪ੍ਰਾਥਮਿਕਤਾ ਦੇਣ ਲਈ ਵਰਤੋਂ।

Rollout checklist (ਪੁਬਲਿਸ਼ ਅਤੇ ਦੁਹਰਾਓ)

• Readers verified (NFC/QR) ਅਤੇ fallback tested
• Admin roles ਅਤੇ escalation contacts ਪਰਿਭਾਸ਼ਿਤ
• Support scripts ਤਿਆਰ (lost phone, denied access, re-issue)
• Analytics dashboard ਲਾਈਵ ਅਤੇ ਸਪਤਾਹਿਕ ਜਾਂਚ cadence
• ਸਪਸ਼ਟ user comms ਅਤੇ ਸਹਾਇਤਾ ਮੰਗਣ ਦਾ ਤਰੀਕਾ ( /contact)
• Commercial ਅਤੇ scaling plan ਪੁਸ਼ਟੀ ( /pricing)