ਭਾਰਤ ਦੇ D2C ਸਟੋਰਾਂ ਲਈ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ: ਘੱਟ drop-offs

UPI-ਪਹਿਲੇ ਚੈੱਕਆਉਟ ਨਾਲ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਹੁੰਦੀ ਹੈ

ਭਾਰਤ ਵਿੱਚ ਮੋਬਾਈਲ 'ਤੇ ਖਰੀਦਦਾਰ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਚੈੱਕਆਉਟ ਦੋਸਤ ਨੂੰ ਪੈਸਾ ਭੇਜਣ ਵਰਗਾ ਤੇਜ਼, ਜਾਣੂ ਅਤੇ ਘੱਟ ਟਾਈਪਿੰਗ ਵਾਲਾ ਹੋਵੇ। ਜੇ ਉਹਨਾਂ ਨੂੰ ਲੰਬਾ ਕਾਰਡ ਨੰਬਰ ਭਰਨਾ ਪਵੇ, IFSC ਲੱਭਣਾ ਪਵੇ ਜਾਂ ਬਿਨਾਂ ਸਾਫ਼ ਦਿਸ਼ਾ ਨਿਰਦੇਸ਼ ਦੇ ਐਪ ਬਦਲਨਾ ਪਵੇ ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਛੱਡ ਦੇਂਦੇ ਹਨ, ਭਾਵੇਂ ਉਹ ਸਾਮਾਨ ਲੈਣਾ ਚਾਹੁੰਦੇ ਹੋਣ।

ਭੁਗਤਾਨ ਉਹੀ ਸਥਾਨ ਹੈ ਜਿਥੇ ਜ਼ਿਆਦਾਤਰ D2C ਚੈੱਕਆਉਟ ਲੋਕ ਗਵਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਪਹਿਲੀ ਵਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਗਾਹਕ ਨੂੰ ਖਤਰਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਗਾਹਕ ਪੈਸਾ ਦੇਣ ਵਾਲੇ ਹਨ, ਅਕਸਰ ਕਮਜ਼ੋਰ ਨੈੱਟਵਰਕ 'ਤੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹ OTPs, ਐਪ-ਸਵਿੱਚਿੰਗ ਅਤੇ ਧਿਆਨ ਭਟਕਣ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨਾਲ ਜੁਝ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਇਕ ਛੋਟੀ ਜਿਹੀ ਦੇਰੀ ਜਾਂ ਗੁੰਝਲਦਾਰ ਸਕ੍ਰੀਨ ਨੂੰ ਨਾਕਾਮੀ ਵਾਂਗ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਦਾ ਮਤਲਬ ਸਿਰਫ ਇਹ ਹੈ ਕਿ UPI ਨੂੰ ਤੁਸੀਂ ਡਿਫੌਲਟ ਤੇਜ਼ ਰਾਸ਼ਤਾ ਵਜੋਂ ਪੇਸ਼ ਕਰਦੇ ਹੋ ਅਤੇ ਇਸ ਨੂੰ ਸਭ ਤੋਂ ਵਧੀਆ ਤੇ ਸਮਰਥਨ ਦਿੰਦੇ ਹੋ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ UPI ਹੀ ਇਕਲਾ ਵਿਕਲਪ ਹੋਵੇ। ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ ਅਹਮ ਹਨ, ਪਰ ਉਹ fallback ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ ਉਹ ਮੁਕਾਬਲੇਵਾਲੇ ਵਿਕਲਪ ਜੋ ਫੈਸਲਾ ਲੈਣ ਨੂੰ ਸੋਝੀ ਪੈਂਦੇ ਹਨ।

ਚੰਗਾ UPI-ਪਹਿਲਾ ਫਲੋ ਚਾਰ ਚੀਜ਼ਾਂ ਲਈ optimize ਕਰਦਾ ਹੈ:

• ਭੁਗਤਾਨ ਦਾ ਸਮਾਂ (ਘੱਟ ਟੈਪ, ਘੱਟ ਟਾਈਪਿੰਗ)
• ਸਪਸ਼ਟਤਾ (ਅਗਲਾ ਕਦਮ ਕੀ ਹੈ, ਐਪ ਸਵਿੱਚ ਤੋਂ ਬਾਅਦ ਕੀ ਕਰਨਾ ਹੈ)
• ਭਰੋਸਾ (ਸਪਸ਼ਟ ਰਕਮ, ਮਰਚੈਂਟ ਨਾਮ ਅਤੇ ਪੁਸ਼ਟੀ)
• ਰਿਕਵਰੀ (ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਆਸਾਨ retry ਅਤੇ ਸੁਰੱਖਿਅਤ fallback)

ਉਦਾਹਰਨ ਵਜੋਂ, Instagram ਤੇ ਇੱਕ ਖਰੀਦਦਾਰ "Buy" 'ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਕਦਮ 'ਤੇ ਆਉਂਦਾ ਹੈ ਅਤੇ ਉੱਥੇ UPI ਊਪਰ ਦਿੱਤਾ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਉਹਦੀ ਆਖਰੀ ਵਰਤੀ ਐਪ suggest ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਉਹ ਇਕ ਵਾਰੀ ਟੈਪ ਕਰਦਾ ਹੈ, UPI ਐਪ ਵਿੱਚ approve ਕਰਦਾ ਹੈ ਅਤੇ ਸਪਸ਼ਟ success ਸਕ੍ਰੀਨ ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਸੁਨੇਹਾ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਵੇਂ “ਭੁਗਤਾਨ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਹੋਈ” ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਅਤ ਅਗਲਾ ਕਦਮ, ਨਾ ਕਿ ਫਸ ਕੇ ਰਹਿਣਾ ਜਾਂ ਦੁਬਾਰਾ ਭੁਗਤਾਨ ਕਰਨਾ।

ਜਦੋਂ ਤੁਸੀਂ ਤੇਜ਼ੀ, ਸਪਸ਼ਟਤਾ ਅਤੇ ਰਿਕਵਰੀ ਲਈ ਸੋਲਵ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਇੱਕ ਮੈਥਡ 'ਤੇ ਜ਼ੋਰ ਦੇਏ drop-offs ਘਟਾਉਂਦੇ ਹੋ।

ਸਕ੍ਰੀਨ ਡਿਜ਼ਾਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਭੁਗਤਾਨ ਰਾਸ਼ਤੇ ਚੁਣੋ

ਜਦੋਂ ਪ੍ਰੋਡਕਟ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਨਿਰਣਾ ਕਰ ਲੈਂਦੀ ਹੈ ਕਿ ਹਰ ਆਮ ਸਥਿਤੀ ਵਿੱਚ ਖਰੀਦਦਾਰ ਨੂੰ ਅਗਲਾ ਕੀ ਕਰਨਾ ਹੈ, ਤਦ ਚੈੱਕਆਉਟ "ਸੁਲਝਿਆ ਹੋਇਆ" ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਛੱਡ ਕੇ ਸਿੱਧਾ UI 'ਤੇ ਜਾਉਗੇ ਤਾਂ ਅਕਸਰ ਇੱਕ ਭਾਰੇ ਭਰਕਮ ਪੇਜ ਬਣਦਾ ਹੈ ਅਤੇ drop-offs ਵੱਧ ਜਾਂਦੇ ਹਨ।

ਆਪਣਾ ਪ੍ਰਾਇਮਰੀ ਰਾਸ਼ਤਾ ਨਾਂ ਦਿਓ। ਭਾਰਤੀ D2C ਸਟੋਰ ਲਈ ਇਹ ਆਮ ਤੌਰ 'ਤੇ UPI-ਪਹਿਲਾ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਡਿਫੌਲਟ ਐਕਸ਼ਨ ਇੱਕ-ਟੈਪ UPI intent ਹੁੰਦੀ ਹੈ: ਯੂਜ਼ਰ ਐਪ ਚੁਣਦਾ ਹੈ ਅਤੇ ਘੱਟ ਤਾਈਪਿੰਗ ਨਾਲ ਆਪਣੀ UPI ਐਪ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰ ਲੈਂਦਾ ਹੈ।

ਫਿਰ ਆਪਣੇ ਸੈਕੰਡਰੀ ਰਾਸ਼ਤਿਆਂ ਨੂੰ fallback ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਨਾ ਕਿ ਬਰਾਬਰ ਵਿਕਲਪ ਵਜੋਂ। ਇਨ੍ਹਾਂ ਨੂੰ "escape hatches" ਸਮਝੋ ਜਦੋਂ intent ਸੰਭਵ ਨਾ ਹੋਵੇ (ਕੋਈ UPI ਐਪ ਨਹੀਂ, ਐਪ ਫੇਲ ਹੋ ਗਿਆ, ਯੂਜ਼ਰ ਹੋਰ ਮੈਥਡ ਪਸੰਦ ਕਰਦਾ)। ਸੈੱਟ ਨੂੰ ਛੋਟਾ ਅਤੇ predictable ਰੱਖੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਹਿਚਕਿਚਾਹਟ ਨਾ ਮਹਿਸੂਸ ਕਰਨ।

ਰਾਸ਼ਤਿਆਂ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ

ਸਧਾਰਣ ਨਿਯਮ ਵਰਤੋ: ਸਭ ਤੋਂ ਤੇਜ਼ ਵਿਕਲਪ ਨੂੰ ਡਿਫੌਲਟ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਲੋੜ ਹੋਣ 'ਤੇ ਵਿਸਥਾਰ ਕਰੋ।

• ਡਿਫੌਲਟ: UPI intent (ਛੋਟੀ ਐਪ ਚੁਣਨ ਵਾਲੀ ਜਾਂ ਆਖਰੀ ਵਰਤੀ ਐਪ)
• ਵਿਸਥਾਰ: UPI QR ਅਤੇ UPI ID (ਉਹਨਾਂ ਲਈ ਜੋ ਐਪ ਨਹੀਂ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦੇ ਜਾਂ ਡੈਸਕਟਾਪ 'ਤੇ ਹਨ)
• ਫਾਲਬੈੱਕ: ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ (ਅਤੇ ਵੈਲੇਟ ਜੇ ਇਹ ਤੁਹਾਡੇ ਦਰਸ਼ਕ ਲਈ ਮਾਇਨੇ ਰੱਖਦਾ ਹੋਵੇ)
• ਹਮੇਸ਼ਾ ਉਪਲਬਧ: ਇੱਕ ਸਪਸ਼ਟ “ਹੋਰ ਭੁਗਤਾਨ ਵਿਕਲਪ” ਕੰਟਰੋਲ, ਨਾ ਕਿ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਪੂਰਾ ਗ੍ਰਿਡ

ਹੁਣ ਫੈਸਲਾ ਕਰੋ ਕਿ ਹਰ ਵਿਕਲਪ ਕਦੋਂ ਦਿਸੇ। ਉਦਾਹਰਨ ਵਜੋਂ, ਮੋਬਾਈਲ ਯੂਜ਼ਰਾਂ ਲਈ ਆਮ ਆਰਡਰ ਵੈਲਯੂ ਲਈ ਪਹਿਲਾਂ UPI intent ਦਿਖਾਓ, ਪਰ ਜਦੋਂ ਉਚਿ-ਟਿਕਟ ਆਰਡਰ ਜਾਂ ਦੁਬਾਰਾ ਖਰੀਦਦਾਰ ਜਿਸ ਨੇ ਪਿਛਲੇ ਵਾਰ ਕਾਰਡ ਵਰਤਿਆ ਸੀ, ਤੇ ਕਾਰਡ ਨੂੰ ਉਪਰ ਲਿਆਓ।

ਸਫਲਤਾ ਦੇ ਮਾਪਦੰਡ UI ਕੰਮ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੇ ਜਾਣ। ਘੱਟ ਕਦਮ, ਘੱਟ ਗਲਤ ਭਰਾਈ ਦੇ ਮੌਕੇ, ਅਤੇ ਇੱਕ ਅਜਿਹਾ ਪੁਸ਼ਟੀ ਸਥਿਤੀ ਜੋ ਸਪਸ਼ਟ ਹੋ—ਇਹੀ ਉਦੇਸ਼ ਰੱਖੋ। ਇੱਕ ਚੰਗਾ ਟੈਸਟ ਇਹ ਹੈ ਕਿ ਫਲੋ ਇਕ ਵਾਕ ਵਿੱਚ ਬਿਆਨ ਕਰੋ: “UPI ਨਾਲ Pay ਕਰੋ, ਐਪ ਵਿੱਚ approve ਕਰੋ, ਵਾਪਸ ਆ ਕੇ ਪੁਸ਼ਟੀ ਵੇਖੋ।” ਜੇ ਤੁਸੀਂ ਇੰਨਾ ਸਧਾਰਨ ਨਹੀਂ ਕਹਿ ਸਕਦੇ ਤਾਂ ਸਕ੍ਰੀਨ ਡਿਜ਼ਾਈਨ ਵੀ ਸੰਘਰਸ਼ ਕਰੇਗੀ।

ਇੱਕ ਛੋਟਾ ਸਹੀ ਨਜ਼ੀਰ: ਇੱਕ slow 4G ਕਨੈਕਸ਼ਨ 'ਤੇ ਖਰੀਦਦਾਰ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਪਹਿਲਾਂ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਿਰਫ਼ “More options” 'ਤੇ ਟੈਪ ਕਰਨ 'ਤੇ ਦਿਖਾਉਣਾ। ਇਸ ਨਾਲ ਚੋਇਸ ਓਵਰਲੋਡ ਘਟਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ ਰਾਸ਼ਤਾ ਅੱਗੇ ਰਹਿੰਦਾ ਹੈ।

ਮੋਬਾਈਲ ਲਈ ਚੈੱਕਆਉਟ ਸਕ੍ਰੀਨ ਹਾਇਰਾਰਕੀ ਡਿਜ਼ਾਇਨ ਕਰੋ

ਮੋਬਾਈਲ 'ਤੇ, ਸਭ ਤੋਂ ਤੇਜ਼ ਚੈੱਕਆਉਟ ਉਹ ਹੈ ਜੋ ਅਗਲਾ ਕਦਮ ਸਾਫ਼ ਦਿਖਾਉਂਦਾ ਹੈ। UPI-ਪਹਿਲਾ ਲੇਆਉਟ ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰਾਂ ਨੂੰ ਇਕ ਟੈਪ ਨਾਲ ਐਪ-ਸਵਿੱਚ (intent) ਵੱਲ ਮਾਰਗ ਦਰਸਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਹੋਰ ਮੈਥਡ ਨਜ਼ਦੀਕ ਹੀ ਰਹਿਣ ਤਾਂ ਜੋ ਲੋਕ ਫਸੇ ਨਾ ਮਹਿਸੂਸ ਕਰਨ।

ਭੁਗਤਾਨ ਮੈਥਡਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਕ੍ਰਮ ਹੈ: ਪਹਿਲਾਂ UPI intent (Pay with UPI app), ਫਿਰ UPI QR ਜਾਂ UPI ID, ਫਿਰ ਕਾਰਡ, ਫਿਰ ਨੈਟਬੈਂਕਿੰਗ। ਪਹਿਲੇ ਵਿਕਲਪ ਨੂੰ ਇੱਕ ਪ੍ਰਮੁੱਖ ਕਾਰਡ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਬਾਕੀ ਨੂੰ ਇੱਕ ਸਧਾਰਨ “More payment options” ਰੋਅ ਪਿੱਛੇ collapse ਕਰੋ ਤਾਂ ਕਿ ਸਕ੍ਰੀਨ ਸਹਿਮਤ ਰਹੇ।

ਲੇਬਲ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਮੀਦ ਸੈੱਟ ਕਰਦੇ ਹਨ। “Proceed” ਜਾਂ “Continue” ਵਰਗੇ ਝੁਟਲੇ ਬਟਨਾਂ ਤੋਂ ਬਚੋ। ਉਹ ਐਕਸ਼ਨ ਲੇਬਲ ਵਰਤੋ ਜੋ ਦੱਸਦੇ ਹਨ ਕਿ ਅਗਲਾ ਕੀ ਹੋਵੇਗਾ, ਜਿਵੇਂ “UPI ਐਪ ਨਾਲ ਭੁਗਤਾਨ ਕਰੋ” (ਤੁਹਾਡੀ UPI ਐਪ ਖੁਲੇਗੀ) ਜਾਂ “ਕਾਰਡ ਨਾਲ ਭੁਗਤਾਨ” (ਕਾਰਡ ਵੇਰਵਿਆਂ ਨੂੰ ਭਰੋ)। ਜੇ ਤੁਸੀਂ ਕਈ UPI ਐਪਾਂ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦੇ ਹੋ, ਤਾਂ “Choose UPI app” ਪਹਿਲੀ ਟੈਪ ਤੋਂ ਬਾਅਦ ਹੀ ਦਿਖਾਓ, ਸਾਰੀਆਂ ਦੀ ਲਿਸਟ ਸ਼ੁਰੂ ਤੋਂ ਨਾ ਦਿਖਾਓ।

ਉਸ ਰਕਮ ਨੂੰ ਓਥੇ ਰੱਖੋ ਜਿੱਥੇ ਲੋਕ ਸਕ੍ਰੋਲ ਕੀਤੇ ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਕਰ ਸਕਣ: ਕੁੱਲ ਰਕਮ ਹੇਠਾਂ ਨੇੜੇ, ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਦੇ ਕੋਲ, ਅਤੇ ਇੱਕ ਛੋਟਾ “View bill details” expander ਹੋਵੇ ਜਿਸ ਵਿੱਚ ਸ਼ਿਪਿੰਗ, ਛੂਟ ਅਤੇ ਟੈਕਸ ਆਦਿ हों। ਪ੍ਰਾਇਮਰੀ ਬਟਨ ਕੋਲ 1-2 trust cues ਜੋੜੋ (ਉਦਾਹਰਨ ਵਜੋਂ, “ਸੁਰੱਖਿਅਤ ਭੁਗਤਾਨ” ਅਤੇ “ਆਸਾਨ ਰੀਫੰਡ”) ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਬਟਨ ਹੇਠਾਂ ਨਾ ਢੁੱਕ ਜਾਵੇ।

ਲੇਆਉਟ ਨੂੰ ਸਥਿਰ ਰੱਖੋ। error text ਅਤੇ loading states ਲਈ ਜਗ੍ਹਾ ਰੱਖੋ ਤਾਂ ਕਿ pay ਬਟਨ ਸਕ੍ਰੋਲ ਨਾ ਕਰੇ। ਜਦੋਂ ਤੁਸੀਂ payment request ਬਣਾ ਰਹੇ ਹੋ ਤਾਂ method switching ਨੂੰ disable ਕਰੋ, ਅਤੇ ਇੱਕ ਸਾਫ਼ spinner ਦਿਖਾਓ ਜਿਵੇਂ “UPI ਐਪ ਖੋਲ੍ਹ ਰਹੇ ਹਾਂ…” ਤਾਂ ਜੋ double taps ਰੋਕੇ ਜਾਣ।

ਕਦੇ-ਕਦੇ ਵਰਤੇ ਨਾ ਜਾਣ ਵਾਲੇ ਮੈਥਡਾਂ ਨੂੰ default ਰੂਪ ਵਿੱਚ collapse ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਮੰਗ ਕੀਤੇ ਜਾਣ 'ਤੇ ਹੀ ਵਿਸਥਾਰ ਕਰੋ। ਬਰਾਬਰ-ਦਿਖਣ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਚੋਣ ਨੂੰ ਢੀਲਾ ਕਰ ਦਿੰਦੇ ਹਨ ਅਤੇ ਫੈਸਲਾ ਦੇਣ ਨੂੰ ਧੀਰਾ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਛੋਟੇ ਸਕ੍ਰੀਨਾਂ 'ਤੇ।

ਕਦਮ-ਬਦਕਦਮ UPI intent ਫਲੋ (ਖੁਸ਼ ਰਾਹ)

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

ਇੱਕ ਸੰਕੁਚਿਤ ਆਰਡਰ ਸੰਖੇਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਇਕ ਸਕ੍ਰੀਨ 'ਤੇ ਫਿੱਟ ਹੋ ਜਾਵੇ। ਕੁੱਲ ਰਕਮ ਸਾਫ਼ ਦਿਖਾਓ, ਨਾਲ ਹੀ 1-2 ਮੁੱਖ ਲਾਈਨਾਂ (ਆਈਟਮ ਗਿਣਤੀ, ਡਿਲਿਵਰੀ ਪਤਾ ਸ਼ਹਿਰ, ਉਮੀਦ ਕੀਤੀ ਡਿਲਿਵਰੀ)। ਇੱਥੇ ਲੰਬੇ ਕਾਰਟ ਜਾਂ ਵਾਧੂ ਫ਼ੀਲਡਾਂ ਤੋਂ ਬਚੋ। ਜੇ ਕੁਝ ਸੰਪਾਦਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਛੋਟਾ “Change” ਐਕਸ਼ਨ ਬਣਾਓ ਜੋ ਖਰੀਦਾਰੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਉਪਭੋਗੀ ਨੂੰ ਬਾਹਰ ਨਾ ਕੱਢੇ।

ਫਿਰ “UPI ਨਾਲ ਭੁਗਤਾਨ” ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਬਣਾਓ। ਟੈਪ ਕਰਨ 'ਤੇ, UPI intent ਫਲੋ ਸ਼ੁਰੂ ਕਰੋ ਤਾਂ ਕਿ ਫੋਨ ਤੇ ਇੰਸਟਾਲ ਕੀਤੀਆਂ UPI ਐਪਾਂ ਦਿਖਾਈਆਂ ਜਾਣ (ਉਦਾਹਰਨ ਵਜੋਂ PhonePe, Google Pay, Paytm, BHIM). ਜੇ ਤੁਸੀਂ UPI ID ਵੀ ਸਹਿਯੋਗ ਕਰਦੇ ਹੋ, ਇਸਨੂੰ ਸੈਕੰਡਰੀ ਰੱਖੋ ਤਾਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਸਿਰਫ਼ ਐਪ ਚੁਣ ਸਕਣ।

ਜਦੋਂ ਯੂਜ਼ਰ UPI ਐਪ ਤੋਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਿੰਨ ਨਤੀਜੇ ਸੰਭਾਲੋ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਾਓ:

• ਸਫਲਤਾ: ਇੱਕ ਛੋਟੀ “Payment received” ਸਥਿਤੀ ਦਿਖਾਓ ਅਤੇ ਅੱਗੇ ਵਧੋ।
• ਨਾਕਾਮੀ: “Payment failed” ਦਿਖਾਓ ਨਾਲ ਇੱਕ ਸਪਸ਼ਟ retry ਬਟਨ।
• ਅਣਜਾਣ: “Payment status ਦੀ ਜਾਂਚ” ਦਿਖਾਓ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਉਹੀ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖੋ।

"ਜਾਂਚ" ਲਈ ਇੱਕ ਪ੍ਰੋਸੈਸਿੰਗ ਸਕ੍ਰੀਨ ਦਿਖਾਓ ਜਿਸ 'ਤੇ ਇੱਕ spinner ਹੋਵੇ ਅਤੇ ਸਾਫ਼ ਸੁਨੇਹਾ ਜਿਵੇਂ “ਤੁਹਾਡੇ ਭੁਗਤਾਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਰਹੇ ਹਾਂ। ਇਹ 30 ਸਕਿੰਟ ਤੱਕ ਲੈ ਸਕਦਾ ਹੈ।” ਆਪਣੇ ਸਰਵਰ ਤੋਂ ਅੰਤਿਮ ਸਥਿਤੀ ਲਈ ਪੋਲ ਕਰੋ। ਇਸ ਵਿੰਡੋ ਦੌਰਾਨ ਯੂਜ਼ਰ ਨੂੰ ਦੁਬਾਰਾ ਭੁਗਤਾਨ ਕਰਨ ਲਈ ਨਾ ਕਹੋ।

ਇੱਕ ਵਾਰ ਪੁਸ਼ਟੀ ਹੋ ਜਾਵੇ, ਇੱਕ ਸਧਾਰਣ ਰਸੀਦ ਸਕ੍ਰੀਨ 'ਤੇ ਲੈਂਡ ਕਰੋ: ਆਰਡਰ ਨੰਬਰ, ਭੁਗਤਾਨ ਕੀਤੀ ਰਕਮ, ਡਿਲਿਵਰੀ ਪਤਾ, ਅਤੇ ਅਗਲੇ ਕਦਮ ਜਿਵੇਂ “Order track ਕਰੋ” ਅਤੇ “Continue shopping.” ਇਸਨੂੰ ਸਾਫ਼ ਰੱਖੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਫੌਰਨ ਨਤੀਜੇ 'ਤੇ ਭਰੋਸਾ ਕਰ ਲਏ।

ਨਾਕਾਮੀਆਂ ਅਤੇ ਅਣਿਸ਼ਚਿਤ ਸਥਿਤੀਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰੋ

UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਨੂੰ ਨਾਕਾਮੀਆਂ ਨੂੰ ਆਮ ਮੰਨਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਯੂਜ਼ਰ ਦੀ ਗਲਤੀ। ਉਦੇਸ਼ ਸਧਾਰਨ ਹੈ: ਆਰਡਰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ, ਖਰੀਦਦਾਰ ਨੂੰ ਸ਼ਾਂਤ ਰੱਖੋ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਸਪਸ਼ਟ ਬਣਾਓ।

ਜੇ ਫੋਨ 'ਤੇ ਕੋਈ UPI ਐਪ ਨਹੀਂ ਹਨ (ਜਾਂ intent ਲਾਂਚ fail ਹੋ ਜਾਂਦਾ ਹੈ), ਤਾਂ ਖਰੀਦਦਾਰ ਨੂੰ spinner 'ਤੇ ਛੱਡ ਕੇ ਨਾ ਰੱਖੋ। ਸਪਸ਼ਟ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੱਸੋ ਅਤੇ ਤੁਰੰਤ ਇੱਕ ਕਾਰਗਰ ਵਿਕਲਪ ਦਿਓ ਜਿਵੇਂ UPI QR, ਨਾਲ ਹੀ ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ।

ਜਦੋਂ ਖਰੀਦਦਾਰ UPI ਐਪ ਦੇ ਅੰਦਰ ਕੈਂਸਲ ਕਰਦਾ ਹੈ, ਤਾਂ "Payment failed" ਨਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਕਸੂਰਵਾਰ ਨਾ ਬਣਾਓ। ਉਹ ਕਿਸੇ ਚੋਣ ਕਰ ਚੁਕੇ ਹਨ ਜਾਂ ਰੁਕ_INTERRUPT ਹੋਏ ਹੋ ਸਕਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਨਿਊਟ੍ਰਲ ਸੁਨੇਹਾ ਜਿਵੇਂ “ਭੁਗਤਾਨ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ” ਦੇ ਕੇ ਚੈੱਕਆਉਟ ਤੇ ਵਾਪਸ ਲਿਆਓ ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਕਾਰਟ, ਪਤਾ ਅਤੇ ਚੁਣਿਆ ਮੈਥਡ ਉਹੀ ਹੀ ਰੱਖੋ।

ਪੇਂਡਿੰਗ ਸਥਿਤੀਆਂ ਆਮ ਹਨ ਜਦੋਂ ਨੈੱਟਵਰਕ ਢੀਲਾ ਹੋਵੇ ਜਾਂ ਬੈਂਕ ਦੇ ਜਵਾਬ ਵਿੱਚ ਦੇਰੀ ਹੋਵੇ। “Pending” ਨੂੰ ਆਪਣੀ ਅਲੱਗ ਸਥਿਤੀ ਮਨੋ, ਨਾਕਾਮੀ ਨਾ।

ਅਣਿਸ਼ਚਿਤ ਨਤੀਜਿਆਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣ ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ

• ਇਕ ਵਾਰ ਆਰਡਰ ਬਣਾਓ, ਉਸਨੂੰ "payment pending" ਟੈਗ ਕਰੋ ਅਤੇ ਆਰਡਰ ਪੁਸ਼ਟੀ ਸਕ੍ਰੀਨ ਦਿਖਾਓ।
• ਪਿਛੋਕੜ ਵਿੱਚ payment status ਨੂੰ ਜਾਰੀ ਰੱਖ ਕੇ ਜਾਂਚੋ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ "Check status" ਬਟਨ ਦਿਓ।
• ਜੇ ਪੁਸ਼ਟੀ ਦੇਰੀ ਕਰ ਰਹੀ ਹੈ ਤਾਂ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਲੈ ਸਕਦਾ ਹੈ।
• ਜੇ ਇਹ pending ਰਹਿੰਦਾ ਹੈ ਤਾਂ "Try again" ਅਤੇ "Use another method" ਦਿਓ ਬਿਨਾਂ ਆਰਡਰ ਗੁਆਉਣ ਦੇ।

ਡੁਪਲਿਕੇਟ ਭੁਗਤਾਨ ਅਕਸਰ ਉਸ ਸਮੇਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਲੋਕ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ Pay 'ਤੇ ਦੁਬਾਰਾ ਟੈਪ ਕਰਦੇ ਹਨ। ਇਸਨੂੰ ਸਪਸ਼ਟ ਸਥਿਤੀ ਅਤੇ ਨਰਮ ਰੁਕਾਵਟ ਨਾਲ ਰੋਕੋ। ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ UPI ਨੂੰ ਹੇਅਫ਼ਫ ਕਰਦੇ ਹੋ, Pay ਬਟਨ disable ਕਰੋ ਅਤੇ "Waiting for confirmation" ਦੇਖਾਓ ਜਿਸ 'ਤੇ ਰਕਮ ਅਤੇ ਆਖਰੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਸਮਾਂ ਦਿੱਤਾ ਹੋਵੇ।

ਸੁਚੱਜੇ timeout ਅਤੇ retries

ਜੇ ਤੁਸੀਂ timeout ਕਰਦੇ ਹੋ, ਤਾਂ "Retry now" ਨੂੰ ਇੱਕੋ ਵਿਕਲਪ ਨਾ ਰੱਖੋ। ਇੱਕ ਛੋਟੀ cooldown ਤੋਂ ਬਾਅਦ ਇੱਕ ਸੁਰੱਖਿਅਤ retry ਦਿਓ ਅਤੇ ਸਮਝਾਓ ਕਿ ਜੇ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਬਾਅਦ ਵਿੱਚ ਸਫਲ ਹੋ ਗਈ ਤਾਂ ਦੁਬਾਰਾ ਚਾਰਜ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਉਦਾਹਰਨ: Riya UPI ਰਾਹੀਂ ਭੁਗਤਾਨ ਕਰਦੀ ਹੈ, ਵਾਪਸ ਤੁਹਾਡੇ ਐਪ 'ਤੇ ਆਉਂਦੀ ਹੈ ਅਤੇ ਦੇਖਦੀ ਹੈ “Confirming payment (up to 30 seconds)”. ਜੇ ਇਹ ਹਜੇ ਵੀ pending ਹੈ, ਉਹ ਸਕ੍ਰੀਨ ਬੰਦ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਆਪਣੇ order page ਤੋਂ "Check status" 'ਤੇ ਟੈਪ ਕਰ ਸਕਦੀ ਹੈ ਬਜਾਏ ਪੈਨਿਕ ਵਿੱਚ ਦੁਬਾਰਾ ਭੁਗਤਾਨ ਕਰਨ ਦੇ।

ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ ਵੱਲ ਨਰਮ fallback ਬਣਾਉ

ਇੱਕ ਚੰਗਾ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਸਾਰਿਆਂ ਭੁਗਤਾਨ ਵਿਕਲਪਾਂ ਨੂੰ ਸਾਹਮਣੇ ਨਹੀਂ ਰੱਖਦਾ। ਇਹ ਪਹਿਲਾਂ UPI ਦੀ ਕੋਸ਼ਿਸ਼ ਕਮਾਈ ਕਰਦਾ ਹੈ, ਫਿਰ ਜਦੋਂ ਯੂਜ਼ਰ ਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸ਼ਾਂਤ ਤੇਜ਼ fallback ਦਿੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ ਨੂੰ ਜਲਦੀ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹੋ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਖਰੀਦਦਾਰ ਹਿਚਕਿਚਾਹਟ ਕਰਕੇ ਮੁਕਾਬਲਾ ਕਰਨਗੇ ਅਤੇ ਛੱਡ ਦੇਣਗੇ।

fallback ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਪਸ਼ਟ UPI ਸਮੱਸਿਆ ਤੋਂ ਬਾਅਦ trigger ਕਰੋ: ਯੂਜ਼ਰ ਨੇ UPI ਐਪ ਵਿੱਚ ਕੈਂਸਲ ਕੀਤਾ, intent timeout ਹੋ ਗਿਆ, ਜਾਂ gateway ਤੋਂ ਨਾਕਾਮੀ ਮਿਲੀ। ਅਣਿਸ਼ਚਿਤ ਸਥਿਤੀਆਂ (ਜਿਵੇਂ "pending") ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਹੋਰਨਾਂ ਮੈਥਡਾਂ ਵਿੱਚ ਫੌਰਨ ਨਹੀਂ dhakelਣਾ ਜਿਹੜਾ ਕਿ double payment ਕਰਵਾ ਸਕਦਾ ਹੈ। ਇਸਦੀ ਥਾਂ, ਇੱਕ ਛੋਟੀ ਸਥਿਤੀ ਸਕ੍ਰੀਨ ਦਿਖਾਓ ਜਿਸ 'ਤੇ ਇੱਕ ਹੀ ਕਾਰਵਾਈ ਹੋਵੇ ਜਿਵੇਂ "Try UPI again" ਅਤੇ ਦੂਜੀ ਜਿਵੇਂ "Use another method"।

ਜਦੋਂ ਖਰੀਦਦਾਰ ਮੈਥਡ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਉਹਦੀ ਪ੍ਰਗਤੀ ਬਣੀ ਰਹੇ। ਕਾਰਟ, ਸਿਪਿੰਗ ਪਤਾ, coupon, ਅਤੇ ਚੁਣਿਆ ਡਿਲਿਵਰੀ ਵਿਕਲਪ ਬਿਲਕੁਲ ਉਹੀ ਰਹਿਣ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਰਸੀਦ ਲਈ email/phone ਲਿਆ ਹੈ, ਤਾਂ ਫਿਰ ਨਹੀਂ ਪੁੱਛੋ।

fallback ਕਦਮ ਛੋਟੇ ਅਤੇ predictable ਰੱਖੋ:

• ਪਹਿਲਾਂ ਉਸ ਯੂਜ਼ਰ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਵਿਕਲਪ (saved card ਜਾਂ netbanking ਬੈਂਕ ਲਿਸਟ) ਨੂੰ ਡਿਫੌਲਟ ਕਰੋ ਸਿਰਫ਼ UPI fail ਹੋਣ 'ਤੇ।
• ਫ਼ੀਲਡ ਘੱਟ ਰੱਖੋ: ਕਾਰਡ ਨੰਬਰ, ਸਮਾਪਤੀ, CVV, ਅਤੇ ਨਾਮ ਜੇ ਲੋੜ ਹੋਵੇ।
• ਜਿੱਥੇ ਸੰਭਵ ਹੋ, ਮੋਬਾਈਲ ਉੱਤੇ autofill ਅਤੇ ਨੰਬਰ ਪੈਡ ਵਰਤੋ।
• ਗਲਤੀਆਂ ਸਪਸ਼ਟ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ ("CVV 3 ਅੰਕ ਦਾ ਹੈ") ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਫੀਲਡ ਦੇ ਕੋਲ ਰੱਖੋ।
• UPI ਤੇ ਇੱਕ ਟੈਪ ਨਾਲ ਵਾਪਸ ਜਾਣ ਦੀ ਆਗਿਆ ਦਿਓ ਬਿਨਾਂ ਇਨਪੁਟ ਸਾਫ਼ ਕੀਤੇ।

ਉਦਾਹਰਨ: ਇੱਕ ਖਰੀਦਦਾਰ "UPI ਨਾਲ ਭੁਗਤਾਨ" 'ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ, ਆਪਣੀ UPI ਐਪ ਨੂੰ ਧੱਕਾ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਵਾਪਸ ਆ ਕੇ “Payment not completed” ਵੇਖਦਾ ਹੈ। ਪਹਿਲਾਂ "Try again" ਦਿਖਾਓ। ਹੇਠਾਂ "Pay by card" ਅਤੇ "Netbanking" ਦਿਓ। ਜੇ ਉਹ ਕਾਰਡ ਚੁਣਦਾ ਹੈ, ਤਾਂ ਨਾਮ ਅਤੇ ਬਿਲਿੰਗ ਈਮੇਲ ਪੂਰਕ ਭਰੋ, ਕਾਰਟ ਨੂੰ ਬਦਲਿਆ ਨਾ ਜਾਵੇ, ਅਤੇ ਜੇ ਉਹ ਮਨ ਬਦਲੇ ਤਾਂ ਤੁਰੰਤ UPI 'ਤੇ ਵਾਪਸ ਆ ਸਕੇ।

ਮੋਬਾਈਲ 'ਤੇ drop-offs ਘਟਾਉਣ ਵਾਲੇ UI ਵਿਸਥਾਰ

ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਸਪਸ਼ਟ ਕਰੋ

ਮੋਬਾਈਲ ਚੈੱਕਆਉਟ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਸਕ੍ਰੀਨ ਖਰੀਦਦਾਰ ਤੋਂ ਸੋਚਣ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ। ਇੱਕ ਸਾਫ਼ ਪ੍ਰਾਇਮਰੀ ਐਕਸ਼ਨ ਚੁਣੋ ਅਤੇ ਹੋਰ ਸਭ ਕੁਝ ਸੈਕੰਡਰੀ ਬਣਾਓ। ਜੇ ਤੁਸੀਂ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਮੁੱਖ ਬਟਨ "UPI ਨਾਲ ਭੁਗਤਾਨ" ਜਾਂ "UPI ਐਪ ਖੋਲ੍ਹੋ" ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ vague "Continue"।

ਮੁਕਾਬਲੇ ਵਾਲੇ ਬਟਨਾਂ ਤੋਂ ਬਚੋ (ਉਦਾਹਰਨ: "Pay now", "Apply coupon", ਅਤੇ "Edit address" ਸਾਰਿਆਂ ਦਾ ਚੀਖਾ)। ਐਕਸਟ੍ਰਾ ਨੂੰ ਛੋਟੇ ਟੈਕਸਟ ਲਿੰਕ ਜਾਂ collapsible rows ਵਿੱਚ ਰੱਖੋ।

ਥੰਬ-ਫ੍ਰੈਂਡਲੀ spacing ਵਰਤੋ। ਜ਼ਿਆਦਾਤਰ ਟੈਪ ਇਕ ਹੱਥ ਨਾਲ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਬਟਨਾਂ ਨੂੰ ਕਾਫ਼ੀ ਉਚਾਈ ਦਿਓ ਅਤੇ ਥੱਲੇ ਦੇ ਬਹੁਤ ਕਿਨਾਰੇ ਤੋਂ ਦੂਰ ਰੱਖੋ ਜਿੱਥੇ gestures ਰੁਕਾਵਟ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ। ਪਾਠ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖੋ ਤਾਂ ਕਿ ਖਰੀਦਦਾਰ ਰਕਮ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ pinch-zoom ਨਾ ਕਰਨ।

ਟਾਈਪੀਂਗ ਅਤੇ ਸ਼ੱਕ ਘੱਟ ਕਰੋ

ਮੋਬਾਈਲ 'ਤੇ ਟਾਈਪਿੰਗ ਧੀਮੀ ਹੁੰਦੀ ਹੈ। ਜਿੰਨਾ ਹੋ ਸਕੇ pre-fill ਕਰੋ (ਅਕਾਉਂਟ ਤੋਂ ਫੋਨ ਅਤੇ ਈਮੇਲ, ਆਖਰੀ ਵਰਤੀ ਅਡਰੈੱਸ, ਸੇਵ ਕੀਤੀ UPI ID ਜੇ ਪਹਿਲਾਂ ਵਰਤੀ ਗਈ ਹੋ)। ਜਦੋਂ ਫੀਲਡ ਲੋੜੀਂਦੀ ਹੋਵੇ, ਇੱਕ ਸਕ੍ਰੀਨ 'ਤੇ ਇੱਕ ਫੀਲਡ ਰੱਖੋ ਅਤੇ ਸਹੀ ਕੀਬੋਰਡ ਟਾਈਪ ਦਿਖਾਓ (ਫੋਨ ਲਈ ਨੰਬਰ ਪੈਡ)।

ਗਲਤੀ ਸੁਨੇਹੇ ਛੋਟੇ, ਵਿਸ਼ੇਸ਼ ਅਤੇ ਅਗਲਾ ਕਦਮ ਦੱਸਣ ਵਾਲੇ ਹੋਣ। "ਕੁਝ ਗਲਤ ਹੋ ਗਿਆ" ਇੱਕ ਅੰਤ ਸਥਾਨ ਹੈ। ਇਕ ਵਧੀਆ ਪੈਟਰਨ: ਕੀ ਹੋਇਆ + ਹੁਣ ਕੀ ਕਰੋ।

ਹਲਕੀ trust cues ਲੰਮੇ ਪੈਰਾਗ੍ਰਾਫਾਂ ਨਾਲੋਂ ਵੱਧ ਮਦਦ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਛੋਟਾ "ਸੁਰੱਖਿਅਤ ਭੁਗਤਾਨ" ਨੋਟ ਦਿਖਾਓ, ਚੈੱਕਆਉਟ ਹੈੱਡਰ ਅਤੇ ਭੁਗਤਾਨ ਪ੍ਰਾਂਪਟ 'ਤੇ ਮਰਚੈਂਟ ਨਾਮ ਸਦਾ ਇਕੋ ਜਿਹਾ ਰੱਖੋ, ਅਤੇ ਮੁੱਖ ਬਟਨ ਦੇ ਕੋਲ ਆਖਰੀ ਭੁਗਤਾਨ ਦੀ ਰਕਮ ਹਮੇਸ਼ਾ ਦਿਖਾਓ।

ਇੱਕ ਛੋਟਾ UI ਚੈਕ ਜੋ ਜ਼ਿਆਦਾਤਰ drop-offs ਫੜ ਲੈਂਦਾ ਹੈ:

• ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਬਟਨ, ਸਪਸ਼ਟ ਲੇਬਲ
• ਵੱਡੇ ਟੈਪ ਟਾਰਗੇਟ (ਖਾਸ ਕਰਕੇ UPI ਐਪ ਚੋਣ ਲਈ)
• pre-filled ਸੰਪਰਕ ਫੀਲਡ ਅਤੇ ਘੱਟ ਟਾਈਪਿੰਗ
• ਵਿਸ਼ੇਸ਼ ਗਲਤੀਆਂ ਨਾਲ ਸਪਸ਼ਟ ਅਗਲਾ ਕਦਮ
• ਹਰ ਵੇਲੇ ਇੱਕੋ ਜਿਹਾ ਮਰਚੈਂਟ ਨਾਮ ਅਤੇ ਰਕਮ ਦਿਖਾਈ ਦੇਣਾ

ਕਨਵਰਜ਼ਨ ਨੁਕਸਾਨ ਵਾਲੀਆਂ ਆਮ ਗਲਤੀਆਂ

ਬਹੁਤ ਸਾਰੇ drop-offs ਕੀਮਤ ਜਾਂ ਭਰੋਸੇ ਦੀ ਗੱਲ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ payment flow ਛੋਟੀ ਸਕ੍ਰੀਨ 'ਤੇ ਅਣਿਸ਼ਚਿਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਚੰਗਾ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਇੱਕ ਲਗਾਤਾਰ ਕੰਮ ਵਰਗਾ ਲੱਗਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਯੂਜ਼ਰ UPI ਐਪ 'ਤੇ ਜਾ ਕੇ ਵਾਪਸ ਆਵੇ।

ਉਹ ਗਲਤੀਆਂ ਜੋ ਚੁਪਚਾਪ completion ਨੂੰ ਮਾਰ ਦਿੰਦੀਆਂ ਹਨ

ਇਹੋ ਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਭਾਰਤੀ ਮੋਬਾਈਲ ਚੈੱਕਆਉਟਸ ਵਿੱਚ ਬਾਰ-ਬਾਰ ਆਉਂਦੀਆਂ ਹਨ:

• UPI intent ਨੂੰ redirect ਵਜੋਂ ਵਰਤਣਾ ਜੋ ਚੈੱਕਆਉਟ ਨੂੰ "ਖਤਮ" ਕਰ ਦਿੰਦਾ। ਜੇ ਯੂਜ਼ਰ ਵਾਪਸ ਆ ਕੇ ਖਾਲੀ ਸਕ੍ਰੀਨ, ਰੀਸਟਾਰਟਡ ਕਾਰਟ ਜਾਂ ਲੌਗ-ਆਊਟ ਸਟੇਟ ਵੇਖਦਾ ਹੈ ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਛੱਡ ਦੇਂਦੇ ਹਨ। ਸੈਸ਼ਨ ਨੂੰ ਜਿਊਂਦਾ ਰੱਖੋ ਅਤੇ ਵਾਪਸੀ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ "Waiting for confirmation" ਸਥਿਤੀ ਦਿਖਾਓ।
• ਬੈਕ ਬਟਨ ਬਿਹੇਵਿਅਰ ਜੋ ਲੋਕਾਂ ਨੂੰ ਗਲਤੀ ਨਾਲ ਬਾਹਰ ਕੱਢ ਦਿੰਦਾ ਹੈ। Android 'ਤੇ, back ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ product page ਜਾਂ webview ਬੰਦ ਕਰਕੇ ਨਾ ਭੇਜੇ। back ਨੂੰ ਉਨ੍ਹਾਂ ਨੂੰ ਆਖਰੀ ਸੁਰੱਖਿਅਤ ਕਦਮ ਤੇ ਲੈ ਜਾਵੇ ਅਤੇ ਆਰਡਰ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਮੰਗੇ।
• Retry loops ਜੋ duplicates ਬਣਾਉਂਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ users ਨੂੰ "Pay again" ਦੀ ਆਜ਼ਾਦੀ ਦੇਦੇ ਹੋ ਬਿਨਾਂ ਪਿਛਲੀ ਕੋਸ਼ਿਸ਼ ਚੈੱਕ ਕੀਤੇ, ਤਾਂ ਤੁਸੀਂ double charges, duplicate orders, ਅਤੇ support tickets ਲਈ ਮੌਕਾ ਦਿੰਦੇ ਹੋ। ਤੇਜ਼-ਤੇਜ਼ ਦੁਹਰਾਉਂ ਨੂੰ ਰੋਕੋ ਅਤੇ ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ payment status ਚੈੱਕ ਕਰੋ।
• ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਦਿਖਾਉਣਾ। payment choices ਦੀ ਇੱਕ diwar ਸੋਚਣ ਅਤੇ ਸਕ੍ਰੋਲਿੰਗ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। UPI ਨੂੰ ਡਿਫੌਲਟ ਰੱਖੋ, ਫਿਰ ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਹੀ ਦਿਖਾਓ, ਸਪਸ਼ਟ ਲੇਬਲ ਨਾਲ।
• ਅਸਪਸ਼ਟ ਗਲਤੀਆਂ ਜਿਵੇਂ "Payment failed, try again." ਯੂਜ਼ਰ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਗਲੇ ਕੀ ਕਰਨ: "UPI ਐਪ ਨਹੀਂ ਖੁੱਲਿਆ", "Payment pending", "Bank server ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਿਹਾ", ਜਾਂ "ਤੁਸੀਂ ਕੈਂਸਲ ਕੀਤਾ"। ਹਰ ਇੱਕ ਦੇ ਨਾਲ ਇੱਕ ਸਪਸ਼ਟ ਕਾਰਵਾਈ ਜੋੜੋ।

ਇੱਕ ਮਿਸਾਲ: ਖਰੀਦਦਾਰ Pay 'ਤੇ ਟੈਪ ਕਰਦਾ ਹੈ, UPI ਐਪ 'ਤੇ ਸਵਿੱਚ ਕਰਦਾ ਹੈ, ਫਿਰ ਵਾਪਸ ਆ ਕੇ ਤੁਹਾਡੀ ਸਾਈਟ 'ਤੇ ਕਾਰਟ ਪੇਜ ਵੇਖਦਾ ਹੈ। ਉਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਪੈਸਾ ਕਟਿਆ ਗਿਆ ਕਿ ਨਹੀਂ, ਇਸ ਲਈ ਉਹ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਵਧੀਆ ਨਤੀਜਾ ਇੱਕ ਇਕਲ ਸਥਿਤੀ ਸਕ੍ਰੀਨ ਹੈ ਜੋ ਦੱਸਦੀ ਹੈ ਕਿ ਦੁਕਾਨ ਕੀ ਕਰ ਰਹੀ ਹੈ (payment ਚੈੱਕ ਕਰ ਰਹੀ ਹੈ) ਅਤੇ ਖਰੀਦਦਾਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ (ਰੁਕੋ, UPI ਐਪ ਚੈੱਕ ਕਰੋ, ਜਾਂ ਹੋਰ ਮੈਥਡ ਚੁਣੋ)।

ਅਸਲ ਕਾਰਨ ਜੋ drop-offs ਫੈਲ ਕਰਦੇ ਹਨ ਉਹ ਮਾਪੋ

ਇੱਕ ਚੈੱਕਆਉਟ "ਠੀਕ" ਲੱਗ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਖਰੀਦਦਾਰ ਗਵਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਛੋਟਾ ਕਦਮ ਮੋਬਾਈਲ 'ਤੇ fail ਹੋ ਰਿਹਾ ਹੈ। ਆਪਣੀ payment flow ਨੂੰ funnel ਵਾਂਗ ਵਰਤੋ ਅਤੇ ਸਪਸ਼ਟ events ਟਰੈਕ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਦੇਖ ਸਕੋ ਲੋਕ ਕਿੱਥੇ ਅਤੇ ਕਿਉਂ ਛੱਡ ਰਹੇ ਹਨ।

ਮੂਲ ਯਾਤਰਾ ਦਾ ਟਰੈਕਿੰਗ ਸ਼ੁਰੂ ਕਰੋ: payment method ਚੋਣ ਤੋਂ ਲੈ ਕੇ ਅੰਤਿਮ ਪੁਸ਼ਟੀ ਤੱਕ। ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ "ਯੂਜ਼ਰ ਨੇ ਆਪਣਾ ਮਨ ਬਦਲ ਲਿਆ" ਨੂੰ "ਫਲੋ ਟੁੱਟ ਗਿਆ" ਅਤੇ "ਬੈਂਕ/UPI ਨੈੱਟਵਰਕ ਸਲੋ ਸੀ" ਤੋਂ ਵੱਖਰਾ ਕੀਤਾ ਜਾਵੇ। UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਵਿੱਚ UPI ਐਪ ਨੂੰ ਹੱਥ ਦੇਣਾ ਸਭ ਤੋਂ ਨਜ਼ੁਕ ਬਿੰਦੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਵਧੇਰੇ ਧਿਆਨ ਨਾਲ measure ਕਰੋ।

ਕੁਝ ਮੁੱਖ events ਕੈਪਚਰ ਕਰੋ ਜੋ ਜ਼ਿਆਦातर ਨੁਕਸਾਨ ਦੀ ਵਜ੍ਹਾ ਸਮਝਾਉਂਦੇ ਹਨ:

• ਚੁਣਿਆ ਗਿਆ payment method, method switch ਦਰ, ਅਤੇ ਉਹ ਸਪਸ਼ਟ ਕਦਮ ਜਿੱਥੇ ਯੂਜ਼ਰ ਛੱਡਦਾ ਹੈ
• UPI ਐਪ ਉਪਲਬਧਤਾ (ਕਿੰਨੀਆਂ ਐਪਾਂ ਮਿਲੀਆਂ), intent launch success/failure, ਅਤੇ ਕੀ ਯੂਜ਼ਰ ਤੁਹਾਡੇ ਐਪ 'ਤੇ ਵਾਪਸ ਆਇਆ
• ਵਾਪਸੀ ਦੇ ਨਤੀਜੇ: ਸਫਲ, ਨਾਕਾਮ, ਯੂਜ਼ਰ ਨੇ ਰੱਦ ਕੀਤਾ, ਜਾਂ ਕੋਈ callback/ਅਣਜਾਣ ਨਹੀਂ
• Pending ਅਤੇ timeout ਦਰਾਂ, ਨਾਲ ਹੀ "Pay" ਤੋਂ ਅੰਤਿਮ ਸਥਿਤੀ ਤੱਕ ਦਾ ਸਮਾਂ (p50/p90)
• Retry ਵਤੀਰਾ: UPI ਨੂੰ ਕਿੰਨੀ ਵਾਰੀ retry ਕੀਤਾ ਜਾਂਦਾ ਹੈ vs ਕਾਰਡ/ਨੈਟਬੈਂਕਿੰਗ 'ਤੇ ਸਵਿੱਚ

ਸੰਖਿਆਂ ਬਿਨਾਂ ਸੰਦਰਭ ਧੋਖਾ ਦੇ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਆਪਣੇ ਡੇਟਾ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ। Funnels ਨੂੰ device (Android vs iOS, low-end vs high-end), ਨੈੱਟਵਰਕ ਕੁਆਲਟੀ (ਲੀਝ/ਅਸਥਿਰ vs ਵਧੀਆ), ਅਤੇ ਨਵੇਂ vs Returning ਗਾਹਕਾਂ ਦੇ ਅਨੁਸਾਰ ਵੰਡੋ। ਕਈ "conversion issues" ਅਸਲ ਵਿੱਚ "ਘੱਟ-ਮੇਮੋਰੀ ਫੋਨ + ਬੁਰਾ ਨੈੱਟਵਰਕ" ਦੀ ਸਮੱਸਿਆ ਹੁੰਦੇ ਹਨ।

ਬੇਸਲਾਈਨ ਬਣਾਓ ਅਤੇ ਇੱਕ-ਇੱਕ ਚੀਜ਼ ਦੀ A/B ਟੈਸਟਿੰਗ ਕਰੋ:

• ਬਟਨ ਕਾਪੀ (ਉਦਾਹਰਨ, “Pay via UPI app” vs “Open UPI app")
• ਡਿਫੌਲਟ ਮੈਥਡ ਕ੍ਰਮ (UPI ਪਹਿਲਾਂ vs ਆਖਰੀ ਵਰਤੀ ਮੈਥਡ ਪਹਿਲਾਂ)
• fallback ਕਦੋਂ ਦਿਖੇ (ਤੁਰੰਤ vs ਇੱਕ ਨਾਕਾਮ intent ਤੋਂ ਬਾਅਦ)
• ਨਾਕਾਮੀ ਤੋਂ ਬਾਅਦ "Retry UPI" ਦਾ phrasing ਅਤੇ ਸਥਿਤੀ
• Pending ਹੈਂਡਲਿੰਗ (wait screen vs ਹੌਲੀ-ਹੌਲੀ prompt to check status)

ਟੈਸਟ ਛੋਟੇ ਰੱਖੋ, failure ਅਤੇ pending ਦਰਾਂ ਨੂੰ ਵੇਖੋ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਵਧੇਰੇ unknown states ਵੇਖੋ ਤਾਂ ਜਲਦੀ ਰੋਕੋ। ਇੱਕ ਥੋੜਾ ਘੱਟ click-through ਠੀਕ ਹੈ ਜੇ ਇਹ stuck payments ਅਤੇ support tickets ਘਟਾਉਂਦਾ ਹੈ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਛੇਤੀ ਚੈੱਕਲਿਸਟ

ਇੱਕ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਸਿਰਫ਼ "ਤੇਜ਼" ਹੈ ਜਦੋਂ ਇਹ ਅਸਲੀ ਫੋਨਾਂ, ਅਸਲੀ ਨੈੱਟਵਰਕਾਂ, ਅਤੇ ਅਸਲੀ UPI ਐਪਾਂ 'ਤੇ predictable ਤਰੀਕੇ ਨਾਲ ਵਰਤਦਾ ਹੈ। ਇਹ ਪਾਸ ਘੱਟੋ-ਘੱਟ 2 Android ਡਿਵਾਈਸ (ਇੱਕ mid-range) ਅਤੇ ਇੱਕ slow network test ਨਾਲ ਕਰੋ।

ਪ੍ਰੀ-ਰਿਲੀਜ਼ ਚੈੱਕ (conversion + safety)

• ਯਕੀਨੀ ਕਰੋ ਕਿ UPI intent ਆਮ Android ਸੈਟਅਪ (Chrome + WebView) 'ਤੇ ਇੱਕ ਟੈਪ ਵਿੱਚ ਖੁਲਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਚੈੱਕਆਉਟ ਤੇ ਸਪਸ਼ਟ ਨਤੀਜੇ ਨਾਲ ਵਾਪਸ ਆਉਂਦੀ ਹੈ।
• "ਕੋਈ UPI ਐਪ ਨਹੀਂ ਇੰਸਟਾਲ" ਮਾਮਲੇ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਆਗੇ ਵਧਣ ਲਈ fallback ਦਿਖਾਓ: ਕਾਰਡ ਜਾਂ ਨੈਟਬੈਂਕਿੰਗ, ਬਿਨਾਂ dead ends ਦੇ।
• retries ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਓ: ਇੱਕ payment ਕੋਸ਼ਿਸ਼ ਇੱਕ ਆਰਡਰ ਵਿੱਚ ਮੈਪ ਹੋਵੇ, ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ duplicate orders ਜਾਂ duplicate charges ਨਾ ਬਣਾਏ।
• ਅਣਿਸ਼ਚਿਤ ਨਤੀਜਿਆਂ ਨੂੰ ਹੈਂਡਲ ਕਰੋ: ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਸਫਲਤਾ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ "Payment pending" ਸਥਿਤੀ ਦਿਖਾਓ ਜਿਸ ਨਾਲ ਇੱਕ ਅਗਲਾ ਨਿਰਦੇਸ਼ ਹੋਵੇ (ਉਦਾਹਰਨ "Check status" ਅਤੇ "Try another method").
• cancel/back ਬਿਹੇਵਿਅਰ ਦੀ ਜਾਂਚ ਕਰੋ: ਜੇ ਯੂਜ਼ਰ UPI ਐਪ ਤੋਂ ਵਾਪਸ ਆ ਕੇ ਬੈਕ ਕਰਦਾ ਹੈ, ਤੁਹਾਡੀ ਸਕ੍ਰੀਨ ਨੂੰ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਹੋਇਆ ਅਤੇ ਅਗਲਾ ਬਿਹਤਰ ਕਦਮ ਕੀ ਹੈ।

ਇਨ੍ਹਾਂ ਚੈੱਕਾਂ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਛੋਟੀ ਅੰਦਰੂਨੀ "fake sale" ਦਿਨ ਚਲਾਓ ਜਿੱਥੇ ਟੀਮ ਕੁਝ ਟੈਸਟ ਆਰਡਰ end-to-end ਰੱਖੇ ਅਤੇ ਕੋਈ ਵੀ ਗੁੰਝਲਦਾਰ ਮੋਹੜਾ ਨੋਟ ਕਰੇ।

ਪੋਸਟ-ਰਿਲੀਜ਼習惯

ਹਫ਼ਤੇ ਵਿੱਚ ਇੱਕ ਵਾਰੀ, ਆਪਣੇ ਸਭ ਤੋਂ ਵੱਡੇ failure ਕਾਰਨਾਂ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੇ drop-off ਵਾਲੇ ਇੱਕ-ਇੱਕ ਕਦਮ ਨੂੰ ਰਿਵਿਊ ਕਰੋ (ਅਕਸਰ UPI ਐਪ ਨੂੰ ਹੱਥ ਦੇਣਾ, ਵਾਪਸੀ to browser, ਜਾਂ pending ਸਕ੍ਰੀਨ)। ਸਭ ਤੋਂ ਵੱਡੀ ਰਿੱਪ ਨੂੰ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਮਾਪੋ।

ਭਾਰਤੀ D2C ਖਰੀਦਦਾਰ ਲਈ ਇੱਕ ਯਥਾਰਥ ਰਾਹ

Riya ਤੁਹਾਡੇ D2C ਸਟੋਰ ਤੋਂ ਪਹਿਲੀ ਵਾਰ ਖਰੀਦ ਰਹੀ ਹੈ। ਉਹ ਇੱਕ low-end Android ਫੋਨ 'ਤੇ ਹੈ, ਮੋਬਾਈਲ ਡੇਟਾ 'ਤੇ ਜੋ 4G ਅਤੇ 3G ਵਿਚਕਾਰ ਬਦਲਦਾ ਰਹਿੰਦਾ ਹੈ। ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਭੁਗਤਾਨ ਕਰ ਕੇ ਆਪਣਾ ਕੰਮ ਜਾਰੀ ਰੱਖਣਾ ਚਾਹੁੰਦੀ ਹੈ।

ਉਹ ਭੁਗਤਾਨ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਡਿਫੌਲਟ ਵੇਖਦੀ ਹੈ: UPI ਊਪਰ, ਇੱਕ ਛੋਟੀ ਟਿੱਪ: “ਆਪਣੀ UPI ਐਪ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰੋ। ਲੱਗਭਗ 10 ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ।” ਹੇਠਾਂ ਛੋਟੇ ਵਿਕਲਪ "Card" ਅਤੇ "Netbanking" ਦਿੱਖ ਰਹੇ ਹਨ। ਇਹ ਇੱਕ UPI-ਪਹਿਲਾ ਚੈੱਕਆਉਟ ਹੈ ਜੋ fallback ਨੂੰ ਛੁਪਾ ਕੇ ਨਹੀਂ ਰੱਖਦਾ।

ਖੁਸ਼ ਰਾਹ: UPI intent ਕੰਮ ਕਰਦਾ ਹੈ

Riya "UPI ਐਪ ਨਾਲ ਭੁਗਤਾਨ" 'ਤੇ ਟੈਪ ਕਰਦੀ ਹੈ। ਤੁਹਾਡੀ ਸਕ੍ਰੀਨ ਦਿਖਾਉਂਦੀ: “ਤੁਹਾਡੀ UPI ਐਪ ਖੋਲ੍ਹ ਰਹੇ ਹਾਂ…” ਅਤੇ ਇੱਕ ਹੀ ਕਾਰਵਾਈ: “UPI ਐਪ ਬਦਲੋ”。ਉਸਦੀ UPI ਐਪ ਖੁਲ ਜਾਦੀ ਹੈ, ਉਹ approve ਕਰਦੀ ਹੈ, ਅਤੇ ਵਾਪਸ ਭੇਜੀ ਜਾਂਦੀ ਹੈ।

ਤੁਹਾਡੇ ਸਟੋਰ 'ਤੇ ਵਾਪਸ ਆ ਕੇ ਸੁਨੇਹਾ ਸਧਾਰਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ: “Payment successful” ਨਾਲ “Order confirmed” ਅਤੇ ਇੱਕ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਆਰਡਰ ਨੰਬਰ। ਕੋਈ ਵਾਧੂ ਕਦਮ ਨਹੀਂ, ਕੋਈ ਵਧੇਰੇ ਫਾਰਮ ਨਹੀਂ।

ਉਹੀ ਖਰੀਦਦਾਰ, ਪਰ ਨੈੱਟਵਰਕ ਨੇ ਇਸਨੂੰ "Pending" ਬਣਾ ਦਿੱਤਾ

ਅਗਲੀ ਵਾਰ, approval UPI ਐਪ ਵਿੱਚ ਸਫਲ ਹੁੰਦੀ ਹੈ ਪਰ ਤੁਹਾਡੇ ਸਟੋਰ ਨੂੰ ਵਾਪਸੀ ਸਲੋ ਹੋ ਜਾਂਦੀ ਹੈ। ਕੇਵਲ ਇਸ ਲਈ "Failed" ਨਾ ਦਿਖਾਓ ਕਿ ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ ਤੁਰੰਤ callback ਨਹੀਂ ਮਿਲੀ। ਇੱਕ ਨਿਊਟ੍ਰਲ ਸਥਿਤੀ ਦਿਖਾਓ:

• “Payment status: Pending confirmation”
• “Back ਨਾ ਦਬਾਓ। ਇਹ 60 ਸਕਿੰਟ ਤੱਕ ਲੈ ਸਕਦਾ ਹੈ।”
• ਬਟਨ: “Check status” ਅਤੇ “Get help”
• ਛੋਟਾ ਟੈਕਸਟ: “ਜੇ ਤੁਹਾਡੇ ਖਾਤੇ ਤੋਂ ਰਕਮ ਕੱਟੀ ਗਈ ਹੈ, ਅਸੀਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਆਰਡਰ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਾਂਗੇ।”

ਇਹੀ ਥਾਂ ਬਹੁਤ ਸਾਰੇ ਸਟੋਰ ਲੋਕਾਂ ਨੂੰ ਗੁਆਂਦੇ ਹਨ: ਉਹ ਡਰਾਉਣ ਵਾਲੀ ਗਲਤੀ ਦਿਖਾਉਂਦੇ ਹਨ, ਜਾਂ ਤੁਰੰਤ retry ਕਰਵਾਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ double payments ਅਤੇ panic ਹੁੰਦੀ ਹੈ।

ਇੱਕ fallback ਜੋ ਸਜ਼ਾ ਵਰਗਾ ਮਹਿਸੂਸ ਨਹੀਂ ਹੁੰਦਾ

ਜੇ pending ਬਹੁਤ ਲੰਬਾ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵਿਕਲਪ ਦਿਓ ਜੋ Riya ਦੇ ਬੈਂਕ ਪਾਸੇ ਜੋ ਹੋ ਸਕ ਰਿਹਾ ਹੈ, ਉਸ ਨੂੰ ਸਤਿਕਾਰ ਦਿੰਦਾ ਹੈ:

“ਹੇਠਾਂ ਅਜੇ ਵੀ pending ਹੈ। ਵਿਕਲਪ ਚੁਣੋ:”

• “ਰੁਕੋ ਅਤੇ ਜਾਂਚ ਜਾਰੀ ਰੱਖੋ”
• “ਹੋਰ ਭੁਗਤਾਨ ਮੈਥਡ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ”

ਜੇ ਉਹ fallback ਚੁਣਦੀ ਹੈ ਤਾਂ ਉਸਦਾ ਕਾਰਟ ਅਤੇ ਪਤਾ ਲਾਕ ਰਹੇ। ਜੋ ਕੁਝ ਵੀ ਤੁਸੀਂ ਭਰਿਆ ਹੈ, ਉਸ ਨੂੰ ਪ੍ਰੀ-ਫਿਲ ਕਰੋ, "Card" ਅਤੇ "Netbanking" ਇੱਕ-ਟੈਪ 'ਤੇ ਦਿਓ, ਅਤੇ ਵਾਅਦਾ ਦਿਖਾਓ: “ਤੁਹਾਨੂੰ ਦੁਹਰਾਈ ਚਾਰਜ ਨਹੀਂ ਮਿਲੇਗਾ। ਜੇ ਪਹਿਲੀ ਭੁਗਤਾਨ ਪੁਸ਼ਟੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਸੀਂ ਇਸ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਰਦ ਕਰ ਦਿਆਂਗੇ।”

ਜਦੋਂ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਤਾਂ Riya ਨੂੰ ਦੋ ਚੀਜ਼ਾਂ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ: ਤੇਜ਼ੀ (UPI intent ਤੁਰੰਤ ਖੁਲਦਾ ਹੈ) ਅਤੇ ਸੁਰੱਖਿਆ (pending ਦੀ ਵਿਆਖਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਰ ਚੋਣ ਸਪਸ਼ਟ ਹੈ)।

ਅਗਲੇ ਕਦਮ: ਸ਼ਿਪ ਕਰੋ, ਸਿੱਖੋ, ਅਤੇ ਇਤਰੈਂਟ ਕਰੋ ਬਿਨਾਂ ਚੈੱਕਆਉਟ ਤੋੜੇ

ਆਪਣੀ ਪਹਿਲੀ ਰਿਲੀਜ਼ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ, conversion-ਕੇਂਦ੍ਰਿਤ ਬੇਸਲਾਈਨ ਵਜੋਂ ਮਾਨੋ: ਇੱਕ ਸਪਸ਼ਟ UPI-ਪਹਿਲਾ ਰਾਸ਼ਤਾ ਪਲੱਸ ਕਾਰਡ ਅਤੇ ਨੈਟਬੈਂਕਿੰਗ ਲਈ ਭਰੋਸੇਯੋਗ fallback। ਹਰ ਵਾਰ ਸਭ ਵੈਲੇਟ, offers, ਅਤੇ ਕੋਨੇ-ਕੋਨੇ ਦੇ UI ਦੇਸ਼ਾਂ ਬਣਾਉਣ ਤੋਂ ਬਚੋ। ਛੋਟਾ ਸਕੋਪ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਵੇਖੋ ਕੀ ਸਚਮੁਚ drop-offs ਘਟਾ ਰਿਹਾ ਹੈ।

ਕੋਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ, payment states ਲਈ ਇੱਕ ਸਫ਼ਾ spec ਲਿਖੋ ਅਤੇ ਹਰ ਇੱਕ ਸਥਿਤੀ ਵਿੱਚ ਤੁਹਾਡੀ ਐਪ ਕਿੱਦਾ ਵਿਵਹਾਰ ਕਰੇਗੀ ਇਹ ਦਰਸਾਓ। importHunImportant ਹਿੱਸਾ labels ਨਹੀਂ, ਨਿਯਮ ਹਨ: ਗਾਹਕ ਕੀ ਵੇਖਦਾ ਹੈ, ਆਰਡਰ ਸਥਿਤੀ ਕੀ ਬਣਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ retries ਨੂੰ ਕਿਵੇਂ ਆਗਿਆ ਦਿੰਦੇ ਹੋ।

ਇੱਕ ਸਧਾਰਣ ਸੇਟ ਜੋ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ:

• Success: ਪੁਸ਼ਟੀ ਦਿਖਾਓ, ਕਾਰਟ ਲਾਕ ਕਰੋ, ਆਰਡਰ ਬਣਾਓ।
• Failed: ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕਾਰਨ ਹੈ ਤਾਂ ਸਪਸ਼ਟ ਕਾਰਨ ਦਿਖਾਓ, retry ਅਤੇ fallback ਦੀ ਆਗਿਆ ਦਿਓ।
• Cancelled: ਯੂਜ਼ਰ ਨੇ ਮੰਨਿਆ, ਚੈੱਕਆਉਟ ਤੇ ਵਾਪਸ ਆਓ ਬਿਨਾਂ ਕਾਰਟ/ਪਤੇ ਨੂੰ ਗੁਆਉਣ।
• Pending: “ਅਸੀਂ ਪੁਸ਼ਟੀ ਕਰ رہے ਹਾਂ” ਦਿਖਾਓ, poll/refresh ਕਰੋ, ਅਤੇ "Check status" ਦੀ ਆਗਿਆ ਦਿਓ।
• Unknown: ਸਰਵਰ-ਸਾਈਡ ਤੱਕ verified ਹੋਣ ਤੱਕ pending ਵਾਂਗ ਦੇਖੋ, client ਤੋਂ paid ਨਾ ਮੰਨੋ।

ਫਿਰ ਅਸਲੀ ਡਿਵਾਈਸਾਂ 'ਤੇ ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਯੋਜਨਾ ਚਲਾਓ। emulators ਦਰਦ ਨੁਕਤੇ ਹਟਾ ਦਿੰਦੇ ਹਨ।

• 2 ਤੋਂ 3 UPI ਐਪਸ ਇੰਸਟਾਲ ਕੀਤੇ ਹੋਏ ਅਤੇ ਸਿਰਫ ਇੱਕ ਇੰਸਟਾਲ ਕੀਤਾ ਹੋਇਆ ਟੈਸਟ ਕਰੋ।
• slow network, network switch (Wi‑Fi to LTE), ਅਤੇ flow ਵਿਚ airplane mode ਆਜ਼ਮਾਓ।
• ਯੂਜ਼ਰ UPI ਐਪ ਤੋਂ ਦੇਰ ਨਾਲ ਵਾਪਸ ਆਉਂਦਾ ਤਾਂ ਵਿਹਾਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
• ਉਪਰੋਕਤ ਹਰ ਸਥਿਤੀ ਦੇ ਆਰਡਰ ਸਥਿਤੀ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਹੋਣ ਦੀ ਜਾਂਚ ਕਰੋ।
• ਕਿਸੇ ਵੀ UPI ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ fallback path ਨੂੰ ਮੁੜ-ਪੜਤਾਲ ਕਰੋ।

guardrails ਨਾਲ ship ਕਰੋ: ਹਰ ਕਦਮ ਲਈ event tracking, ਸਰਵਰ-ਸਾਈਡ payment verification, ਅਤੇ ਇੱਕ ਛੋਟੀ rollback ਯੋਜਨਾ। ਜੇ ਤੁਹਾਨੂੰ prototype ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਸੋਧ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਤੁਸੀਂ Koder.ai 'ਚ planning mode ਦੀ ਵਰਤੋਂ ਕਰਕੇ checkout ਸਕ੍ਰੀਨਾਂ ਅਤੇ backend ਲਾਜਿਕ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ snapshots ਅਤੇ rollback ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਛੋਟੀ-ਛੋਟੀ ਟੇਸਟਿੰਗ ਕਰ ਸਕਦੇ ਹੋ।