7 ਦਿਨਾਂ ਵਿੱਚ ਈ‑ਕਾਮਰਸ MVP: ਇੱਕ ਦਿਨ ਦਰ ਦਿਨ ਯੋਜਨਾ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਛੋਟਾ ਸਟੋਰ ਲਾਂਚ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ ਜੋ ਕੀਟਾਲੌਗ, ਚੈਕਆਊਟ, ਅਸਲ ਭੁਗਤਾਨ, ਬੇਸਿਕ ਐਡਮਿਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਿਲੀਜ਼ ਰੁੱਖ ਰੱਖਦਾ ਹੈ।
ਹਫਤੇ ਵਿੱਚ ਮੁਕੰਮਲ ਕਰਨ ਯੋਗ ਈ‑ਕਾਮਰਸ MVP ਲਈ, “ਰੀਅਲ ਪੇਮੈਂਟਸ” ਦਾ ਅਰਥ ਇੱਕ ਗੱਲ ਹੈ: ਇੱਕ ਅਜਨਬੀ ਗਾਹਕ ਭੁਗਤਾਨ ਕਰ ਸਕਦਾ ਹੈ, ਤੁਸੀਂ ਆਰਡਰ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ।
ਪਹਿਲੀ ਵਰਜ਼ਨ ਨਿਰਾਲੀ ਰੱਖੋ: ਇੱਕ ਦੇਸ਼, ਇੱਕ ਮੁਦਰਾ, ਅਤੇ ਇੱਕ ਭੁਗਤਾਨ ਢੰਗ (ਅਮੂਮਨ ਕਾਰਡ)। ਜੇ ਤੁਸੀਂ ਸਭ ਕੁਝ ਸਮਰਥਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਤਾਂ ਹਫਤੇ ਦੌਰਾਨ ਤੁਸੀਂ ਐਜ‑ਕੇਸਾਂ 'ਤੇ ਫਸ ਜਾਵੋਗੇ ਨਾ ਕਿ ਵਿਕਰੀ 'ਤੇ।
ਸਭ ਤੋਂ ਛੋਟਾ ਰਸਤਾ ਇੱਕ ਛੋਟੇ ਸਟੋਰ ਵੱਲੋਂ ਹੁੰਦਾ ਹੈ ਜੋ ਸਿਰਫ ਉਹ ਕਦਮ ਕਰਦਾ ਹੈ ਜੋ ਪੈਸਾ ਹਿਲਾਉਣ ਅਤੇ ਫੁਲਫਿਲਮੈਂਟ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਨ ਲਈ ਲੋੜੀਦੇ ਹਨ:
“ਮੁਕੰਮਲ” ਦਾ ਮਤਲਬ ਇੱਕ ਪਰਫੈਕਟ ਸਟੋਰਫਰੰਟ ਨਹੀਂ ਹੈ। “ਮੁਕੰਮਲ” ਮਤਲਬ ਹੈ ਇੱਕ ਆਰਡਰ ਲੈਣਾ, ਸਫਲ ਤਰੀਕੇ ਨਾਲ ਚਾਰਜ ਕਰਨਾ, ਅਤੇ ਇਕੋ ਦਿਨ ਵਿੱਚ ਜਦੋਂ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਆਧਾਰ ਤੇ ਇਸਨੂੰ ਫੁਲਫਿਲ ਕਰਨਾ। ਜੇ ਤੁਸੀਂ 10 ਆਰਡਰ ਲਗਾਤਾਰ ਬਿਨਾਂ ਮੈਨੂਅਲ ਸੋਧਾਂ ਦੇ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਕੰਮ ਕਰਦਾ MVP ਹੈ।
ਉਸ ਨਿਸ਼ਚੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ, ਪਹਿਲਾਂ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਬਾਹਰ-ਅਧੀਨ ਹੈ। ਇਹ ਫੀਚਰ ਆਮ ਮਹਿਸੂਸ ਹੁੰਦੇ ਨੇ ਪਰ ਇਸ ਹਫਤੇ ਭੁਗਤਾਨ ਲੈਣ ਲਈ ਸੁਰੂ ਕਰਨ ਵਿਚ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹਨ: ਵਿਸ਼ਲਿਸਟ, ਰਿਵਿਊਜ਼, ਐਡਵਾਂਸਡ ਸਰਚ, ਜਟਿਲ ਇੰਵੈਂਟਰੀ ਨਿਯਮ, ਕੂਪਨ, ਕਈ ਭੁਗਤਾਨ ਢੰਗ ਅਤੇ ਕਈ ਮੁਦਰਾਵਾਂ।
ਪਹਿਲਾਂ ਇੱਕ ਡਿਵਾਈਸ ਟਾਰਗੇਟ ਚੁਣੋ। ਜੇ ਜ਼ਿਆਦਾਤਰ ਖਰੀਦਦਾਰ ਸੋਸ਼ਲ ਐਡਸ ਤੋਂ ਆਉਂਦੇ ਹਨ ਤਾਂ ਮੋਬਾਇਲ‑ਫਰਸਟ ਵੈੱਬ ਚੁਣੋ। ਜੇ ਤੁਸੀਂ ਬਿਜਨੈੱਸ ਨੂੰ ਵੇਚ ਰਹੇ ਹੋ ਤਾਂ ਡੈਸਕਟਾਪ‑ਫਰਸਟ ਠੀਕ ਰਹਿ ਸਕਦਾ ਹੈ। ਕਿਸੇ ਇੱਕ ਸਕਰੀਨ ਸਾਈਜ਼ ਲਈ ਪਹਿਲਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ ਅਨੁਕੂਲ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਕੋਈ ਚੈਟ‑आਧਾਰਿਤ ਟੂਲ ਵਰਤ ਰਹੇ ਹੋ ਜਿਵੇਂ Koder.ai, ਤਾਂ ਸਕ੍ਰੀਨਾਂ ਅਤੇ ਫਲੋਜ਼ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਕੋਪ ਲਿਖ ਕੇ ਰੱਖੋ। ਇੱਕ ਸਖਤ ਸਕੋਪ “ਸਿਰਫ਼ ਇੱਕ ਹੋਰ ਫੀਚਰ” ਨੂੰ ਦਿਨ 8 ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਰੋਕਣ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਹੈ।
ਇਕ ਈ‑ਕਾਮਰਸ MVP “ਰੀਅਲ” ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਵਿਅਕਤੀ ਪ੍ਰੋਡਕਟ ਲੱਭ ਸਕੇ, ਭੁਗਤਾਨ ਕਰ ਸਕੇ, ਅਤੇ ਤੁਸੀਂ ਬਿਨਾਂ ਈ‑ਮੇਲ‑ਆਧਾਰਿਤ ਵਾਪਸੀ ਦੇ ਆਰਡਰ ਨੂੰ ਫੁਲਫਿਲ ਕਰ ਸਕੋ।
ਪ੍ਰੋਡਕਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਹਾਨੂੰ ਇੱਕ ਟਾਈਟਲ, ਕੀਮਤ, ਇੱਕ ਮੁੱਖ ਇਮੇਜ, ਇੱਕ ਛੋਟੀ ਵਰਣਨਾ, ਅਤੇ ਇੱਕ on/off switch ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਈਟਮ ਨੂੰ ਡਿਲੀਟ ਕੀਤੇ ਬਿਨਾਂ ਲੁਕਾ ਸਕੋ। ਵੈਰੀਐਂਟ, ਬੰਡਲ ਅਤੇ ਜਟਿਲ ਕੀਮਤਾਂ ਬਾਅਦ ਲਈ ਰੱਖੋ।
ਤੁਹਾਡਾ ਕੈਟਾਲੌਗ ਸਧਾਰਨ ਰਹਿ ਸਕਦਾ ਹੈ: ਇੱਕ ਪ੍ਰੋਡਕਟ ਲਿਸਟ ਪੇਜ ਅਤੇ ਇੱਕ ਪ੍ਰੋਡਕਟ ਡੀਟੇਲ ਪੇਜ। ਬੇਸਿਕ ਫਿਲਟਰ (ਜਿਵੇਂ ਸ਼੍ਰੇਣੀ ਜਾਂ in‑stock) ਠੀਕ ਹਨ, ਪਰ ਹਫਤੇ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਵਿੱਚ ਪੂਰਾ ਸਰਚ ਇੰਜਨ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।
ਕਾਰਟ ਅਤੇ ਚੈਕਆਊਟ ਬੋਰਿੰਗ ਅਤੇ ਪੇਸ਼ਗੋਈਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਕਾਰਟ ਨੂੰ add, remove, quantity change ਸਹਾਇਤਾ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਸਪੱਸ਼ਟ subtotal ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਸ਼ਿਪਿੰਗ ਅਤੇ ਟੈਕਸ ਲਈ ਪਹਿਲਾਂ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਚੁਣੋ (ਉਦਾਹਰਨ ਲਈ, ਫਲੈਟ ਸ਼ਿਪਿੰਗ ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੀ ਟੈਕਸ)।
ਇੱਕ ਨਿਊਨਤਮ end‑to‑end ਫਲੋ ਆਮ ਤੌਰ 'ਤੇ ਲੋੜੀਂਦਾ ਹੈ:
ਐਡਮਿਨ ਉਹ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ MVP ਅਕਸਰ ਫੇਲ ਹੁੰਦੇ ਨੇ। ਤੁਹਾਨੂੰ charts ਦੀ ਲੋੜ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਲੌਕ ਕੀਤੀ ਲੌਗਿਨ ਚਾਹੀਦੀ ਹੈ, ਉਤਪਾਦ ਜੋੜਣ/ਸੰਪਾਦਿਤ ਕਰਨ ਦਾ ਤਰੀਕਾ, ਅਤੇ ਇੱਕ orders ਲਿਸਟ ਜਿਸ 'ਚ ਤੁਸੀਂ ਸਥਿਤੀ ਬਦਲ ਸਕੋ (new, paid, shipped, refunded)।
ਉਦਾਹਰਨ: ਤੁਸੀਂ ਤਿੰਨ ਮੋਮੀਬੱਤੀਆਂ ਵੇਚ ਰਹੇ ਹੋ। ਹਰ ਇੱਕ ਦਾ ਇੱਕ ਫੋਟੋ ਅਤੇ ਇੱਕ ਕੀਮਤ ਹੈ। ਇੱਕ ਖਰੀਦਦਾਰ ਦੋ ਜੋੜਦਾ ਹੈ, $5 ਫਲੈਟ ਸ਼ਿਪਿੰਗ ਵੇਖਦਾ ਹੈ, ਆਪਣਾ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, ਫਿਰ ਤੁਸੀਂ ਲੇਬਲ ਪ੍ਰਿੰਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਆਰਡਰ ਨੂੰ shipped ਮਾਰਕ ਕਰ ਦਿੰਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਕਿਸੇ vibe‑coding ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਨਾਲ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ prompt ਸਖਤ ਰੱਖੋ: “ਸਿਰਫ਼ ਇਹੀ ਪੰਨੇ, ਸਿਰਫ਼ ਇਹੀ ਫੀਲਡ, ਕੋਈ ਅਕਾਉਂਟ ਨਹੀਂ, ਕੋਈ ਕੂਪਨ ਨਹੀਂ, ਕੋਈ ਵਿਸ਼ਲਿਸਟ ਨਹੀਂ।”
ਭੁਗਤਾਨ ਉਹ ਥਾਂ ਹੈ ਜਿਸ ਵਿੱਚ ਰਚਨਾ ਤੋਂ ਬਚਣਾ ਹੈ। ਇੱਕ ਪ੍ਰੋਵਾਈਡਰ ਚੁਣੋ ਜਿਸ 'ਚ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਓਨਬੋਰਡ ਹੋ ਸਕਦੇ ਹੋ ਅਤੇ ਸਿਰਫ਼ ਕਾਰਡ ਭੁਗਤਾਨ ਵਿਕਰੀ ਕਰੋ। ਡਿਜੀਟਲ ਵਾਲਟਾਂ, buy‑now‑pay‑later ਅਤੇ ਬੈਂਕ ਟ੍ਰਾਂਸਫਰ ਬਾਅਦ ਲਈ ਰੱਖੋ।
ਸਭ ਤੋਂ ਵੱਡਾ ਫੈਸਲਾ ਭੁਗਤਾਨ ਫਲੋ ਹੈ:
ਭੁਗਤਾਨਾਂ ਨੂੰ ਕੁਝ ਸਥਿਤੀਆਂ ਦੇ ਤੌਰ 'ਤੇ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਅਸਾਨੀ ਨਾਲ ਸਮਝ ਸਕੋ: created, paid, failed, canceled, refunded.
ਸਿਰਫ਼ ਉਹੀ ਡੇਟਾ ਸਟੋਰ ਕਰੋ ਜੋ reconciliation ਅਤੇ support ਲਈ ਲੋੜੀਦਾ ਹੈ: provider payment ID, optional provider customer/session ID, amount, currency, ਅਤੇ ਆਪਣਾ internal order ID. ਕਦੇ ਵੀ raw card data ਸਟੋਰ ਨਾ ਕਰੋ, ਅਤੇ ਨਾ ਹੀ ਆਪਣੇ ਅਪਨੇ ਭੁਗਤਾਨ ਫੀਲਡ ਬਣਾਓ ਜੇ ਲੋੜ ਸੱਚਮੁਚ ਨਹੀਂ।
Webhooks ਆਰਡਰਾਂ ਨੂੰ ਭਰੋਸੇਮੰਦ ਬਣਾਉਂਦੇ ਹਨ। ਚੈਕਆਊਟ ਮਗਰੋਂ, browser redirect ਨੂੰ “paid” ਮੰਨਣਾ ਨਾਂ ਕਰੋ। ਇੱਕ webhook ਹੈਂਡਲਰ ਜੋ ਇਵੈਂਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਮਿਲਦੇ ਆਰਡਰ ਨੂੰ paid ਮਾਰਕ ਕਰਦਾ ਹੈ, ਜੋ ਯਕੀਨੀ ਬਣਾਏ।
Retries ਹੇਠਾਂ ਸੁਰੱਖਿਅਤ ਬਣਾੋ। Webhooks ਵਾਰੰਵਾਰ ਡਿਲਿਵਰ ਹੋ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਹੈਂਡਲਰ idempotent ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਜੇ ਇੱਕ ਆਰਡਰ ਪਹਿਲਾਂ ਹੀ paid ਹੈ ਤਾਂ ਉਹ ਕੁਝ ਨਾ ਕਰੇ ਅਤੇ ਫਿਰ ਵੀ success ਵਾਪਸ ਕਰੇ।
ਜੇ ਤੁਸੀਂ ਤੁਰੰਤ ਬਣਾਉਣ ਲਈ chat‑driven builder ਜਿਵੇਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ payment states ਅਤੇ ਨਿਊਨਤਮ ਫੀਲਡ ਡਿਫਾਈਨ ਕਰੋ, ਫਿਰ webhook endpoint ਅਤੇ order update ਲਾਜਿਕ ਜਨਰੇਟ ਕਰੋ। ਇਹ ਸਪષ્ટਤਾ ਕਲਾਸਿਕ ਹਲਚਲ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ: paid ਗਾਹਕ, unpaid ਆਰਡਰ ਅਤੇ ਘੰਟਿਆਂ ਦੀ ਮੈਨੂਅਲ ਜਾਂਚ।
ਦਿਨ 1: ਸਕੋਪ ਲਾਕ ਕਰੋ। ਇੱਕ ਪੰਨੇ ਦਾ ਸਪੈੱਕ ਲਿਖੋ: ਖਰੀਦਦਾਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਐਡਮਿਨ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਬਾਹਰ ਹੈ। ਇੱਕ payment provider ਚੁਣੋ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ totals ਕਿਵੇਂ ਕੈਲਕੁਲੇਟ ਕਰੋਂਗੇ (ਹੁਣ ਟੈਕਸ/ਸ਼ਿਪਿੰਗ ਜਾਂ ਬਾਅਦ ਵਿੱਚ)। ਪੰਜ ਮੁੱਖ ਸਕ੍ਰੀਨਾਂ ਦਾ ਸਕੈਚ ਬਣਾਓ: catalog, product page, cart, checkout, payment result.
ਦਿਨ 2: ਕੈਟਾਲੌਗ ਲਾਂਚ ਕਰੋ। ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਫੀਲਡਾਂ ਨਾਲ products ਸਟੋਰ ਕਰੋ: name, price, currency, photo, short description, active flag. ਇੱਕ “ਸਾਰੇ ਉਤਪਾਦ” ਪੇਜ ਅਤੇ ਪ੍ਰੋਡਕਟ ਡੀਟੇਲ ਪੇਜ ਬਣਾਓ। ਅੰਦਾਜ਼ਨ ਲਈ ~10 ਟੈਸਟ ਪ੍ਰੋਡਕਟ ਸੀਡ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਰੀਅਲ ਫਲੋਜ਼ ਟੈਸਟ ਕਰ ਸਕੋ।
ਦਿਨ 3: ਕਾਰਟ ਅਤੇ ਆਰਡਰ ਡ੍ਰਾਫਟ। add/remove ਅਤੇ quantity change ਲਾਗੂ ਕਰੋ। ਜਦੋਂ checkout ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇੱਕ order draft ਬਣਾਓ ਅਤੇ prices ਨੂੰ snapshot ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰੋਡਕਟ ਸੰਪਾਦਨ ਪੁਰਾਣੇ ਆਰਡਰਾਂ ਨੂੰ ਨਹੀਂ ਬਦਲੇ। ਗਾਹਕ ਈ‑ਮੇਲ ਅਤੇ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਜਲਦੀ ਕੈਪਚਰ ਕਰੋ।
ਦਿਨ 4: ਟੈਸਟ ਮੋਡ ਵਿੱਚ ਭੁਗਤਾਨ। ਚੈਕਆਊਟ ਨੂੰ payment creation ਨਾਲ ਜੋੜੋ। success, canceled, ਅਤੇ failed payments ਨੂੰ ਸੰਭਾਲੋ। payment status ਨੂੰ order 'ਤੇ ਸੇਵ ਕਰੋ। ਇੱਕ ਸਪੱਸ਼ਟ confirmation page ਦਿਖਾਓ ਜਿਸ 'ਚ order number ਅਤੇ ਅਗਲੇ ਕਦਮ ਹੋਣ।
ਦਿਨ 5: ਫੁਲਫਿਲਮੈਂਟ ਲਈ ਬੇਸਿਕ ਐਡਮਿਨ। ਐਡਮਿਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ: product create/edit/disable, orders list with status updates (paid, packed, shipped, refunded), ਅਤੇ ਇੱਕ simple “view order” ਪੇਜ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਭੇਜਣ ਲਈ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਵੇਖ ਸਕੋ।
ਦਿਨ 6: ਡਿਪਲੋਇਮੈਂਟ ਅਤੇ ਸੁਰੱਖਿਆ। staging ਅਤੇ production ਵੱਖ‑ਵੱਖ ਸੈੱਟ ਕਰੋ, ਲੋਗਸ ਚਾਲੂ ਕਰੋ, ਅਤੇ ਟੈਸਟ ਕਾਰਡ ਨਾਲ ਪੂਰਾ ਫਲੋ ਰਿਹਰਸ ਕਰੋ। ਇੱਕ rollback ਯੋਜਨਾ ਲਿਖੋ ਪਹਿਲਾਂ ਹੀ ਕਿ ਜਦੋਂ ਲੋੜ ਪਏ ਉਸ ਵੇਲੇ ਵਰਤੀ ਜਾ ਸਕੇ।
ਦਿਨ 7: ਛੋਟੇ, ਨਿਯੰਤ੍ਰਿਤ ਤਰੀਕੇ ਨਾਲ ਲਾਈਵ ਹੋਵੋ। ਇੱਕ ਅਸਲੀ ਨਿੱਲ‑ਮੁੱਲ ਖਰੀਦਦਾਰੀ ਨਾਲ ਅੰਤਿਮ ਚੈੱਕ ਕਰੋ, ਈ‑ਮੇਲ/ਰਸੀਦਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਸਟੋਰ ਨੂੰ ਪਹਿਲਾਂ ਇੱਕ ਛੋਟੀ ਦਰਸ਼ਕ ਸਮੁਦਾਇ ਨੂੰ ਖੋਲ੍ਹੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਹਰ ਮੁੱਖ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲੈਣਾ ਯਕੀਨੀ ਬਣਾਓ ਤਾਂ ਜੋ ਜੇ ਚੈਕਆਊਟ ਟੁੱਟੇ ਤਾਂ ਤੇਜ਼ ਰਾਹ ਮੁਹੱਈਆ ਹੋਵੇ।
ਹਫਤੇ‑ਇੱਕ ਸਟੋਰ ਆਰਡਰ ਸਪੱਸ਼ਟਤਾ 'ਤੇ ਟਿਕਦਾ ਜਾਂ ਡਿਗਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਜਲਦੀ ਜਵਾਬ ਦੇਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਉਹ ਕੀ ਖਰੀਦਿਆ, ਕਿੱਥੇ ਭੇਜਣਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ ਸਥਿਤੀ ਕੀ ਹੈ?
ਇੱਕ ਛੋਟਾ, ਨਿਰਸ ਡੇਟਾ ਮਾਡਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇਹ ਪੰਜ ਰਿਕਾਰਡ ਲਗਭਗ ਸਭ ਕੁਝ ਕਵਰ ਕਰਦੇ ਹਨ:
ਐਡਰੈੱਸਾਂ ਨੂੰ ਘੱਟੋ‑ਘੱਟ ਰੱਖੋ ਤਾਂ ਕਿ ਚੈਕਆਊਟ ਤੇਜ਼ ਰਹੇ। ਆਮਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ name, line1, city, postal code, ਅਤੇ country ਹੀ ਚਾਹੀਦਾ ਹੈ। ਫ਼ੋਨ ਓਪਸ਼ਨਲ ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੈਰੀਅਰ ਨੂੰ ਲੋੜ ਨਾ ਹੋਵੇ।
Totals ਨੂੰ ਖਰੀਦ ਸਮੇਂ snapshot ਕਰਕੇ ਰੱਖੋ। ਬਾਅਦ ਵਿੱਚ Product ਟੇਬਲੋਂ totals ਨਾ ਦੁਬਾਰਾ ਕੈਲਕੁਲੇਟ ਕਰੋ। ਕੀਮਤਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਸ਼ਿਪਿੰਗ ਦਰਾਂ ਸੋਧੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਵੇਖੋਗੇ “ਗਾਹਕ ਨੇ X ਦਿੱਤਾ ਪਰ ਆਰਡਰ ਹੁਣ Y ਦਿਖਾ ਰਿਹਾ ਹੈ।” ਹਰ ਆਈਟਮ ਲਈ unit price, ਆਰਡਰ subtotal, shipping, tax (ਭਾਵ ਹੋਵੇ ਤਾਂ 0), ਅਤੇ grand total ਸਟੋਰ ਕਰੋ।
idsempotency ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਇਕੋ webhook ਕਈ ਵਾਰੀ ਜਾਂ ਆਊਟ‑ਆਫ‑ਆਰਡਰ ਆ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਵਾਈਡਰ ਤੋਂ ਇਕ unique event ID ਸਟੋਰ ਕਰੋ ਅਤੇ duplicates ਨੂੰ ਅਣਡਿੱਠਾ ਕਰੋ।
ਉਦਾਹਰਨ: ਇੱਕ webhook payment “succeeded” ਦੋ ਵਾਰ ਮਾਰਕ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੀ ਸਿਸਟਮ ਨੂੰ ਦੋ shipment ਬਣਾਉਣ ਜਾਂ ਦੋ ਪੁਸ਼ਟੀ ਈ‑ਮੇਲਾਂ ਭੇਜਣ ਤੋਂ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ Go ਬੈਕਐਂਡ ਅਤੇ PostgreSQL ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ (provider, raw_event_id) 'ਤੇ unique constraint ਅਤੇ status update ਦੇ ਆਲੇ‑ਦੁਆਲੇ transaction ਸਾਫ਼ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਐਡਮਿਨ “ਡੈਸ਼ਬੋਰਡ” ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਛੋਟੀ ਪਿੱਛੇ ਵਾਲੀ ਜਗ੍ਹਾ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਤਿੰਨ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹੋ: ਕੀ ਵਿਕਣ ਲਈ ਹੈ, ਕੀ ਪੈਡ ਹੋਇਆ, ਅਤੇ ਕੀ ਭੇਜਣਾ ਬਾਕੀ ਹੈ।
ਇਕ ਸਿੰਗਲ ਐਡਮਿਨ ਲੌਗਿਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਰੋਲ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ। ਮਜ਼ਬੂਤ ਪਾਸਵਰਡ, ਬੇਸਿਕ ਰੇਟ ਲਿਮਿਟਿੰਗ, ਅਤੇ ਛੋਟਾ ਸੈਸ਼ਨ ਟਾਈਮਆਉਟ ਵਰਤੋ। ਇਸ ਹਫਤੇ ਸਟਾਫ਼ ਮੈਨੇਜਮੈਂਟ ਅਤੇ permissions ਛੱਡ ਦਿਓ। ਜੇ ਇੱਕ ਹੋਰ ਵਿਅਕਤੀ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਪਹੁੰਚ ਦਿਓ ਅਤੇ ਬਾਦ ਵਿੱਚ ਪਾਸਵਰਡ ਰੋਟੇਟ ਕਰੋ।
ਉਤਪਾਦ ਪ੍ਰਬੰਧਨ ਸਧਾਰਨ ਰੱਖੋ: ਬਣਾਉ/ਸੰਪਾਦਿਤ/ਮੁੱਖ ਇਮેજ ਅੱਪਲੋਡ, ਕੀਮਤ ਸੈੱਟ ਕਰੋ, ਉਪਲਬਧਤਾ ਟੌਗਲ ਕਰੋ। ਇੰਵੈਂਟਰੀ ਗਿਣਤੀ ਸਿਰਫ਼ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਵਾਸ਼ਤਵਕ ਗਿਣਤੀ ਹੋਵੇ ਤਾਂ ਬਣਾਓ। ਇੱਕ in‑stock/out‑of‑stock switch ਆਮਤੌਰ 'ਤੇ overselling ਰੋਕਦਾ ਹੈ।
ਤੁਹਾਡੀ orders view packing slip ਵਾਂਗ ਪੜ੍ਹਣੀ ਚਾਹੀਦੀ ਹੈ। Order ID ਜਾਂ customer email ਨਾਲ serach ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਓ, ਫਿਰ ਦਿਖਾਓ:
Status ਕਾਰਵਾਈਆਂ ਨੂੰ ਦੋ ਬਟਨਾਂ ਤੱਕ ਰੱਖੋ: “Mark packed” ਅਤੇ “Mark shipped.” ਜਦੋਂ ਤੁਸੀਂ shipped ਮਾਰਕ ਕਰੋ, ਤਾਂ optionally tracking ਨੋਟ ਸਟੋਰ ਕਰੋ (carrier + tracking code, ਜਾਂ “Local pickup arranged”). Automated ਈ‑ਮੇਲਾਂ ਉਦੋਂ ਦੀਆਂ ਰਹਿਣ ਜਦੋਂ ਉਹ ਤੁਹਾਨੂੰ ਸਲਾਹਤ ਦੀ ਤਰ੍ਹਾਂ ਦੇਣਗੀਆਂ ਪਰ ਜੇ ਉਹ ਤੇਜ਼ੀ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਨ ਵਾਲੀਆਂ ਹਨ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਦਿਓ।
CSV export ਵਿਕਲਪੀ ਹੈ। ਸਿਰਫ਼ ਉਹੋ ਜੋ ਤੁਸੀਂ ਹਫਤੇ ਵਿੱਚ ਵਰਤੋਂਗੇ ਜੋੜੋ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਐਡਮਿਨ ਨੂੰ ਉਹੀ ਐਪ ਵਿੱਚ ਰੱਖੋ ਪਰ ਇਸ ਨੂੰ protected route ਦੇ ਪਿੱਛੇ ਗੇਟ ਕਰੋ ਅਤੇ ਇੱਕ ਵੈਧ ਸੈਸ਼ਨ ਦੀ ਲੋੜ ਰੱਖੋ।
ਟੈਸਟ ਮੋਡ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਹਾਡਾ ਲਕੜੀ ਉਦੇਸ਼ “ਇੱਕ checkout page” ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਆਰਡਰ ਹੈ ਜੋ ਭੁਗਤਾਨ ਕੀਤਾ ਗਿਆ, ਦਰਜ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਫੁਲਫਿਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ।
ਇੱਕ ਕਠੋਰ ਨਿਯਮ ਬਣਾਓ: ਕਦੇ ਵੀ raw card details ਆਪਣੇ ਸਰਵਰ 'ਤੇ ਸਟੋਰ ਨਾ ਕਰੋ। Hosted checkout ਜਾਂ client‑side tokenization ਵਰਤੋਂ ਤਾਂ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਸਿੱਧਾ payment provider ਨੂੰ ਜਾਵੇ।
payment errors ਨੂੰ ਐਸੇ context ਨਾਲ ਲੌਗ ਕਰੋ ਜੋ ਕਾਰਵਾਈਯੋਗ ਹੋਵੇ: order ID, session ID, customer email (ਜੇ ਉਪਲਬਧ), expected total, provider error code, ਅਤੇ ਇੱਕ ਛੋਟੀ ਸੁਨੇਹਾ ਜਿਵੇਂ “Amount mismatch” ਜਾਂ “Webhook signature invalid.”
ਉਦਾਹਰਨ: ਇੱਕ ਗਾਹਕ ਦੋ ਮੱਗ ਖਰੀਦਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਸਰਵਰ $24 + shipping ਕੈਲਕੁਲੇਟ ਕਰਦਾ ਹੈ, session ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ order ਨੂੰ pending ਰੂਪ ਵਿੱਚ ਦਰਜ ਕਰਦਾ ਹੈ। ਜੇ ਗਾਹਕ ਪੰਨਾ ਬੰਦ ਕਰ ਦੇਂਦਾ ਹੈ ਤਾਂ order canceled ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇ ਉਹ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ ਤਾਂ webhook ਇਸਨੂੰ paid ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਫੁਲਫਿਲ ਕਰ ਸਕਦੇ ਹੋ।
ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਕੇਵਲ ਇੱਕ ਹਫਤਾ ਹੋਵੇ, deployments ਅਕਸਰ ਉਹ ਚੀਜ਼ ਬਣ ਜਾਂਦੇ ਹਨ ਜੋ ਚੈਕਆਊਟ ਨੂੰ ਤੋੜ ਦਿੰਦੀਆਂ ਹਨ। ਮਕਸਦ ਵਧੀਆ DevOps ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਦੋਹਰਾਉਣ ਯੋਗ ਰੁਟੀਨ ਹੈ ਜੋ ਅਚਾਨਕੀਆਂ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇਕ ਨਿਕਾਸੀ ਰਸਤਾ ਦਿੰਦੀ ਹੈ।
ਦੋ environments ਸੈੱਟ ਕਰੋ: staging ਅਤੇ production. Staging ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ production ਵਰਗਾ ਬਣਾਓ: ਉਹੀ ਸੈਟਿੰਗ, ਉਹੀ ਟੈਮਪਲੇਟ, ਉਹੀ ਟੈਕਸ/ਸ਼ਿਪਿੰਗ ਨਿਯਮ, ਪਰ payment test mode ਵਿੱਚ। ਅੰਤਿਮ ਜਾਂਚ staging 'ਚ ਕਰੋ, ਫਿਰ ਬਿਲਕੁਲ ਇੱਕੋ ਹੀ build ਨੂੰ production 'ਚ ਪ੍ਰੋਮੋਟ ਕਰੋ।
ਵਰਜਨਡ ਰਿਲੀਜ਼ਾਂ ਵਰਤੋਂ। ਭਾਵੇਂ ਇਹ ਸਿਰਫ਼ v1, v2, v3 ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ, ਹਰ ਰਿਲੀਜ਼ ਨੂੰ ਟੈਗ ਕਰੋ ਅਤੇ ਪਿਛਲੇ ਨੂੰ ਰੈਡੀ ਰੱਖੋ। ਰੋਲਬੈਕ ਇੱਕ ਕਾਰਵਾਈ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ: ਪਿਛਲੇ build 'ਤੇ ਵਾਪਸ ਝਟਪਟ ਘੁਮਾਉਣਾ ਜਾਂ snapshot restore ਕਰਨਾ। ਜੇ ਤੁਹਾਡੀ ਪਲੇਟਫਾਰਮ snapshots ਅਤੇ rollback ਨੂੰ ਸਹੀਦਾ ਹੈ (Koder.ai ਕਰਦਾ ਹੈ), ਤਾਂ ਹਰ production ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲੈਣਾ ਆਦਤ ਬਣਾਇਓ।
Migrations ਨੂੰ MVP ਹਫਤੇ ਦੌਰਾਨ ਖਤਰਨਾਕ ਸਮਝੋ। backward‑compatible ਬਦਲਾਅ ਨੂੰ ਤਰਜੀਹ ਦਿਓ: ਨਵੇਂ ਟੇਬਲ ਜਾਂ ਕਾਲਮ ਜੋੜੋ, rename ਜਾਂ delete ਨਾ ਕਰੋ, ਅਤੇ ਨਵਾਂ ਕੋਡ ਪਥ ਤਕ ਸੁਰੱਖਿਅਤ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਡੇਟਾ backfill ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਉਹ ਨੂੰ ਇੱਕ ਅਲੱਗ ਜਾਇਬ ਜੌਬ ਵਿੱਚ ਕਰੋ, request ਦੇ ਅੰਦਰ ਨਹੀਂ।
ਸੌਖੇ ਸੁਰੱਖਿਅਤ ਕਦਮ:
ਰਿਲੀਜ਼ ਚੈਕਲਿਸਟ:
ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ 7‑ਦਿਨਾਂ ਦੇ ਲਕੜੀ ਲਕੜਨ ਤੋਂ ਰਹਿਣ ਦੇ ਲਈ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ “ਚੰਗੇ” ਫੀਚਰ ਬਣਾਉਣ ਲੱਗੋ ਜਿਹੜੇ ਚੁੱਪਚਾਪ ਪੈਸਾ ਲੈਣ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਤੋੜ ਦਿੰਦੇ ਹਨ। ਨੁੱਕੀ ਇਹ ਹੈ ਕਿ ਇੱਕ ਸਟੋਰ ਜੋ ਭੁਗਤਾਨ ਲੈਂਦਾ, ਇੱਕ ਭਰੋਸੇਯੋਗ ਆਰਡਰ ਬਣਾਉਂਦਾ, ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਭੇਜਣ ਦਿੰਦਾ।
ਇਕ ਆਮ ਗਲਤੀ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਆਖਰੀ ਕੀਮਤ ਨਿਰਧਾਰਤ ਕਰਨ ਦੇਣੀ ਹੈ। ਜੇ totals, discounts, ਜਾਂ shipping ਕਲਾਇੰਟ 'ਤੇ ਗਣਨਾ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਕਿਸੇ ਨੇ ਇਕ ਵਾਰ ਗ਼ਲਤ ਰਕਮ ਭਰੀ ਤਾਂ ਕੋਈ ਨਜ਼ਰ ਆਵੇਗੀ। ਸਰਵਰ ਨੂੰ single source of truth ਬਣਾਓ: product IDs ਅਤੇ quantities ਤੋਂ order ਨੂੰ ਮੁੜ ਬਣਾਓ, ਫਿਰ ਭੁਗਤਾਨ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ totals ਮੁੜ ਕੈਲਕੁਲੇਟ ਕਰੋ।
Shipping ਅਤੇ tax ਨਿਯਮਾਂ ਵੀ ਸਮਾਂ ਖਾ ਲੈਂਦੇ ਹਨ। ਟੀਮਾਂ ਕਈ ਦਿਨ ਗੁਆ ਲੈਂਦੀਆਂ ਹਨ ਹਰ ਦੇਸ਼ ਅਤੇ ਐਜ‑ਕੇਸ ਨੂੰ ਸਮਰਥਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ। ਹਫਤੇ ਦੇ ਪਹਿਲੇ ਹਿੱਸੇ ਲਈ ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਰਹੋ।
Payments ਚੈਕਆਊਟ ਵਿੱਚ “ਕੰਮ” ਕਰ ਸਕਦੇ ਹਨ ਪਰ operations ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦੇ ਹਨ ਜੇ webhooks ਗਾਇਬ ਹਨ। ਇੱਕ ਗਾਹਕ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਡੇਟਾਬੇਸ ਨੇ ਆਰਡਰ ਨੂੰ paid ਨਹੀਂ ਮਾਰਕ ਕੀਤਾ, ਇਸ ਲਈ ਫੁਲਫਿਲਮੈਂਟ ਰੁਕ ਜਾਂਦਾ ਹੈ। Webhook ਹੈਂਡਲਿੰਗ ਨੂੰ ਲਾਜ਼ਮੀ ਸਮਝੋ।
ਪੰਜ ਜਾਲ ਜਿਸ 'ਤੇ ਧਿਆਨ ਰਹੇ:
ਉਦਾਹਰਨ: ਇੱਕ ਗਾਹਕ ਭੁਗਤਾਨ ਪੂਰਾ ਕਰਦਾ ਹੈ, ਫਿਰ success page ਲੋਡ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਬ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। Webhooks ਬਿਨਾਂ, ਉਹ ਸਮਝਦਾ ਹੈ ਕਿ ਭੁਗਤਾਨ ਫੇਲ ਹੋ ਗਿਆ, ਫਿਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਦੁੱਗਣੇ ਚਾਰਜ ਆ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ Koder.ai ਨਾਲ ਬਣਾਉਂਦੇ ਹੋ, snapshots ਅਤੇ rollback ਨੂੰ ਆਪਣੀ ਰੁਟੀਨ ਦਾ ਹਿੱਸਾ ਬਣਾਓ: ਛੋਟੇ ਬਦਲਾਅ ਲਾਂਚ ਕਰੋ, ਇੱਕ ਜਾਣਿਆ‑ਪਛਾਣਤਾ ਵersion ਰੱਖੋ, ਅਤੇ ਜੇ ਕੁਝ ਟੁੱਟੇ ਤਾਂ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰ ਕਰੋ।
ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ staging ਵਿੱਚ ਕਰੋ, ਫਿਰ ਲਾਈਵ ਸਵਿੱਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੁਹਰਾਓ। ਲਕੜੀ ਉਦੇਸ਼ ਸਧਾਰਨ ਹੈ: ਇੱਕ ਗਾਹਕ ਇੱਕ ਵਾਰੀ ਭੁਗਤਾਨ ਕਰੇ, ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ ਦਰਜ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਫੁਲਫਿਲ ਕਰ ਸਕੋ।
Buyer path ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਇੱਕ ਪ੍ਰੋਡਕਟ ਨੂੰ ਕਾਰਟ ਵਿੱਚ ਜੋੜੋ, ਚੈਕਆਊਟ ਪੂਰਾ ਕਰੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਸੀਂ ਇੱਕ ਸਪੱਸ਼ਟ success page 'ਤੇ ਆਉਂਦੇ ਹੋ। Admin ਵਿੱਚ paid order ਨੂੰ ਸੇਵ ਹੋਇਆ ਵੇਖੋ ਅਤੇ totals ਸਹੀ ਹਨ।
ਫਿਰ webhooks ਨੂੰ ਸਖਤ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਕਰੋ: delays ਅਤੇ retries। Webhooks ਦੇਰੀ ਨਾਲ ਆ ਸਕਦੇ ਹਨ, ਦੋ ਵਾਰੀ ਆ ਸਕਦੇ ਹਨ, ਜਾਂ ਆਊਟ‑ਆਫ‑ਆਰਡਰ ਆ ਸਕਦੇ ਹਨ। ਤੁਹਾਡੀ order update logic idempotent ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਤਾਂ retries ਕਦੇ ਵੀ duplicate paid orders ਨਾ ਬਣਣ।
ਪ੍ਰੀ‑ਲਾਂਚ ਚੈਕਲਿਸਟ:
ਕਿਸੇ ਚੀਜ਼ ਦਾ ਐਲਾਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਅਸਲ live ਚਾਰਜ ਕਰੋ। ਇੱਕ ਅਸਲੀ ਕਾਰਡ, ਛੋਟੀ ਰਕਮ, ਅਤੇ ਆਪਣਾ ਸ਼ਿਪਿੰਗ ਐਡਰੈੱਸ ਵਰਤੋਂ। ਤੁਹਾਨੂੰ ਆਰਡਰ ਇੱਕ ਵਾਰੀ ਹੀ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਪੱਸ਼ਟ timestamp ਅਤੇ status ਨਾਲ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, snapshots ਨਾਲ ਇਹ ਅਭਿਆਸ ਕਰੋ: deploy ਕਰੋ, ਇੱਕ ਆਰਡਰ ਰੱਖੋ, rollback ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮੌਜੂਦਾ ਆਰਡਰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਲੋਡ ਹੁੰਦੇ ਹਨ।
ਕਲਪਨਾ ਕਰੋ ਇਕ ਛੋਟਾ ਕੌਫੀ ਰੋਸਟਰ ਜੋ 12 ਥੈਲੀਆਂ ਬੀੰਸ ਆਨਲਾਈਨ ਵੇਚਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਉਹਨੂੰ subscriptions, ਰਿਵਿਊਜ਼, ਜਾਂ loyalty ਪ੍ਰੋਗਰਾਮ ਨਹੀਂ ਚਾਹੀਦਾ। ਉਹਨੂੰ ਇੱਕ ਸਧਾਰਨ ਸਟੋਰ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸਲੀ ਪੈਸਾ ਲੈ ਸਕੇ ਅਤੇ ਸਾਫ਼ ਆਰਡਰ ਬਣਾਏ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਭੇਜ ਸਕੇ।
ਦਿਨ 2 ਤੱਕ, ਕੈਟਾਲੌਗ ਕਾਫ਼ੀ ਹੈ ਜੇ ਹਰ ਪ੍ਰੋਡਕਟ ਦੇ ਕੋਲ ਇੱਕ ਸਪੱਸ਼ਟ ਫੋਟੋ, ਕੀਮਤ, ਅਤੇ ਇੱਕ ਛੋਟੀ ਵਰਣਨਾ (roast level, tasting notes, bag size) ਹੋਵੇ। ਵਿਕਲਪਾਂ ਘੱਟ ਰੱਖੋ: ਹਰ ਪ੍ਰੋਡਕਟ ਲਈ ਇੱਕ ਸਾਈਜ਼ ਅਤੇ ਇੱਕ ਸ਼ਿਪਿੰਗ ਵਿਕਲਪ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਦੇਸ਼ ਵਿੱਚ ਫਲੈਟ‑ਰੇਟ) rakhō।
ਦਿਨ 4 ਤੱਕ, ਚੈਕਆਊਟ ਇੱਕ ਕੰਮ ਕਰਦਾ ਹੈ: ਸ਼ਿਪਿੰਗ ਵੇਰਵੇ ਇਕੱਠੇ ਕਰੋ, ਕਾਰਡ ਭੁਗਤਾਨ ਲਵੋ, ਅਤੇ ਇੱਕ ਪੁਸ਼ਟੀਕਰਨ ਪੇਜ ਦਿਖਾਓ ਜੋ ਗਾਹਕ ਸਕ੍ਰੀਨਸ਼ਾਟ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ order ID ਅਤੇ ਇੱਕ ਛੋਟਾ ਸਰੰਸ਼ (items, total, shipping address) ਦਿਖਾਓ। ਜੇ ਗਾਹਕ support ਨੂੰ ਈ‑ਮੇਲ ਕਰੇ, ਉਹ order ID ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਸਥਿਤੀ ਲੱਭਣ ਦਾ।
ਦਿਨ 5 ਤੱਕ, ਐਡਮਿਨ ਸਧਾਰਨ ਰਹਿੰਦਾ ਹੈ। ਰੋਸਟਰ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ, ਨਵੇਂ ਆਰਡਰ ਵੇਖਦਾ ਹੈ, ਅਤੇ orders ਨੂੰ paid, packed, shipped ਰਾਹੀਂ ਹਿਲਾਉਂਦਾ ਹੈ। ਟ੍ਰੈਕਿੰਗ ਬਾਅਦ ਵਿੱਚ ਆ ਸਕਦੀ ਹੈ। ਹਫਤੇ ਇਕ, ਇੱਕ ਨੋਟ ਜਿਵੇਂ “Shipped via postal service, label printed at 3:10pm” ਅਕਸਰ ਕਾਫੀ ਹੁੰਦੀ ਹੈ।
ਇਹ ਉਹਨਾਂ ਸਕੋਪਾਂ ਵਿੱਚੋਂ ਹੈ ਜੋ chat‑first builders ਜਿਵੇਂ Koder.ai ਨਾਲ ਵੀ ਚੰਗੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ: ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਸਕ੍ਰੀਨਾਂ, ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਟੇਬਲ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ ਵਰਕਫਲੋ।
ਹਫਤਾ 2 ਲਈ ਸੋਚਣ ਯੋਗ ਚੀਜ਼ਾਂ: discount codes, ਬਿਹਤਰ ਖੋਜ, ਇਨਵੈਂਟਰੀ counts, ਅਤੇ ਹੋਰ automated ਈ‑ਮੇਲ। ਉਹਨਾਂ ਨੂੰ ਸਿਰਫ਼ ਅਸਲ ਆਰਡਰਾਂ ਤੋਂ ਬਾਅਦ ਜੋੜੋ ਜੋ ਤੁਹਾਨੂੰ ਦੱਸਣ ਕਿ ਕੀ ਮਤਲਬ ਰੱਖਦਾ ਹੈ।
ਪਹਿਲਾ ਹਫਤਾ ਲਾਈਵ ਨੂੰ ਇੱਕ ਲਰਨਿੰਗ ਸਪ੍ਰਿੰਟ ਵਜੋਂ ਦੇਖੋ। ਅਸਲ ਆਰਡਰ ਪ੍ਰਾਪਤ ਕਰੋ, ਫਿਰ ਸਭ ਤੋਂ ਵੱਡੀ friction ਜੋ ਤੁਸੀਂ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹੋ ਉਹ ਹਟਾਓ।
ਇੱਕ ਛੋਟੀ ਪਾਇਲਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: 10 paid orders ਦਾ ਲਕੜੀ ਟਾਰਗਟ ਰੱਖੋ ਦੋਸਤਾਂ, ਸਹਿਕਰਮੀ, ਜਾਂ ਇੱਕ ਛੋਟੀ ਦਰਸ਼ਕ ਸਮੂਹ ਤੋਂ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸੰਦੇਸ਼ ਭੇਜ ਸਕਦੇ ਹੋ। ਹਰ ਵਿਅਕਤੀ ਤੋਂ ਪੁੱਛੋ ਕਿ ਉਹ ਕਿੱਥੇ ਹੇਸੀਟੇਟ ਕੀਤਾ। ਇੱਕ ਸਰਲ ਸ਼ੀਟ ਵਿੱਚ drop‑offs ਟਰੈਕ ਕਰੋ: product page -> cart -> checkout started -> payment success.
ਪਾਇਲਟ ਤੋਂ ਬਾਅਦ, ਹਰੇਕ ਵਾਰੀ ਸਿਰਫ਼ ਇੱਕ ਬਦਲਾਅ ਸ਼ਾਮਲ ਕਰੋ। ਸ਼ੁਰੂਆਤੀ ਬਿਹਤਰ ਉਨ੍ਨਤੀਆਂ ਆਮਤੌਰ 'ਤੇ ਸਧਾਰਨ ਹੁੰਦੀਆਂ ਹਨ: ਸਪੱਸ਼ਟ ਸ਼ਿਪਿੰਗ ਲਾਗਤ, ਬਿਹਤਰ ਪ੍ਰੋਡਕਟ ਫੋਟੋ, ਘੱਟ checkout ਫੀਲਡ। ਆਪਣੇ ਨੋਟਾਂ ਵਿੱਚੋਂ ਅਗਲਾ ਸਭ ਤੋਂ ਵੱਡਾ ਰੁਕਾਵਟ ਚੁਣੋ, ਉਸ ਨੂੰ ਠੀਕ ਕਰੋ, ਅਤੇ ਦੂਜਾ ਛੋਟਾ ਬੈਚ ਚਲਾਓ।
ਗਾਹਕ ਸਹਾਇਤਾ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਦੱਸ ਦੇਵੇਗੀ ਕਿ ਕੀ ਘਾਟ ਹੈ। ਆਮ ਸਵਾਲਾਂ ਲਈ ਛੋਟੇ ਜਵਾਬ ਸੰਭਾਲ ਕੇ ਰੱਖੋ: ਮੇਰਾ ਆਰਡਰ ਕਿੱਥੇ ਹੈ, ਕੀ ਮੈਂ ਰੱਦ ਕਰ ਸਕਦਾ ਹਾਂ, ਭੁਗਤਾਨ ਕਿਉਂ ਫੇਲ ਹੋਇਆ, ਸ਼ਿਪਿੰਗ ਕਿੰਨੀ ਅਤੇ ਕਦੋਂ ਪਹੁੰਚੇਗੀ, ਕੀ ਮੈਂ ਮੇਰਾ ਐਡਰੈੱਸ ਬਦਲ ਸਕਦਾ ਹਾਂ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇਤਰੈਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਬਿਨਾਂ ਚੈਕਆਊਟ ਜੋਖਮ ਵਿੱਚ ਪਾਏ, Koder.ai ਤੁਹਾਨੂੰ ਚੈਟ ਤੋਂ ਅੱਗੇ ਵਰਜਨ ਜਨਰੇਟ ਕਰਨ ਅਤੇ snapshots/rollback ਨਾਲ ਬਦਲਾਅ ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।
ਇਕ “ਰੀਅਲ” MVP ਉਹ ਹੈ ਜਿੱਥੇ ਕੋਈ ਅਜਨਬੀ ਸਫਲਤਾਪੂਰਵਕ ਭੁਗਤਾਨ ਕਰ ਸਕੇ, ਤੁਸੀਂ ਸਹੀ ਟੋਟਲ ਅਤੇ ਸ਼ਿਪਿੰਗ ਵੇਰਵੇਾਂ ਨਾਲ਼ ਇੱਕ ਭੁਗਤਾਨ ਕੀਤਾ ਆਰਡਰ ਦੇਖ ਸਕੋ, ਅਤੇ ਤੁਸੀਂ ਉਸੇ ਦਿਨ ਫੁਲਫਿਲ ਕਰ ਸਕੋ ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਉਂਦੇ।
ਜੇ ਤੁਸੀਂ 10 ਆਰਡਰ ਲਗਾਤਾਰ ਬਿਨਾਂ ਹੱਥੋਂ ਹੱਥ ਸੋਧਾਂ ਦੇ ਸੰਭਾਲ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਵਧੀਆ ਹਾਲਤ ਵਿੱਚ ਹੋ।
ਇੱਕ ਦੇਸ਼, ਇੱਕ ਮੁਦਰਾ, ਅਤੇ ਇੱਕ ਭੁਗਤਾਨ ਢੰਗ (ਅਮੂਮਨ ਕਾਰਡ) ਚੁਣੋ। ਸ਼ਿਪਿੰਗ ਅਤੇ ਟੈਕਸ ਲਈ ਇੱਕ ਸਿਰਫ਼ ਸਧਾਰਨ ਨਿਯਮ ਰਖੋ (ਜਿਵੇਂ ਫਲੈਟ ਸ਼ਿਪਿੰਗ ਅਤੇ ਜੇ ਮੁਮਕਿਨ ਹੋਵੇ ਤਾਂ ਟੈਕਸ = 0)।
ਸਕੋਪ ਛੋਟਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਹਰ ਫੈਸਲਾ ਇਹ ਸਮਰਥਨ ਕਰੇ: product → cart → checkout → paid order → fulfillment.
ਅਕਾਉੰਟਸ, ਵਿਸ਼ਲਿਸਟ, ਰਿਵਿਊਜ਼, ਕੂਪਨ, ਕਈ ਮੁਦਰਾਵਾਂ ਅਤੇ ਕਈ ਭੁਗਤਾਨ ਢੰਗ ਛੱਡ ਦਿਓ।
ਸਧਾਰਨ ਤੌਰ 'ਤੇ Hosted checkout 7‑ਦਿਨਾਂ ਦੇ MVP ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੋਵਾਈਡਰ ਜ਼ਿਆਦਾ ਨਜ਼ੁਕ UI ਹਿਸਿਆਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ।
Embedded card forms ਜ਼ਿਆਦਾ “ਨੈਟਿਵ” ਲੱਗ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਹੋਰ ਬੋਲ੍ਹੇ ਹਾਲਾਤ ਅਤੇ ਸੁਰੱਖਿਆ ਕੰਮ ਜੋੜ ਦਿੰਦੇ ਹਨ।
Webhook ਨੂੰ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਮੰਨੋ। Redirect ਪੰਨੇ UX ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਉਹ ਭਰੋਸੇਯੋਗ ਨਹੀਂ (ਟੈਬ ਬੰਦ ਹੋ ਸਕਦੇ ਨੇ, ਨੈੱਟਵਰਕ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ)।
ਇਵੈਂਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਰਕਮ/ਮੁਦਰਾ ਮਿਲਣ ਮਗਰੋਂ ਹੀ ਆਰਡਰ ਨੂੰ paid ਮਾਰਕ ਕਰੋ।
ਇਸ ਨਾਲ ਦੁੱਗਣੀਆਂ ਈ‑ਮੇਲਾਂ, ਦੁੱਗਣਾ ਸ਼ਿਪਮੈਂਟ ਅਤੇ “ਦੋ ਵਾਰੀ ਭੁਗਤਾਨ” ਵਰਗੀਆਂ ਗਲਤੀਆਂ ਰੁਕਦੀਆਂ ਹਨ।
ਖਰੀਦ ਸਮੇਂ snapshots ਸਟੋਰ ਕਰੋ:
ਆਪਣੇ Product ਟੇਬਲੋਂ ਬਾਅਦ ਵਿੱਚ totals ਨੂੰ ਮੁੜਨਿਕਾਲੋ ਨਾ, ਕਿਉਂਕਿ ਕੀਮਤਾਂ ਅਤੇ ਨਿਯਮ ਬਦਲਾਂਗੇ ਅਤੇ ਤੁਹਾਡੇ ਰਿਕਾਰਡ ਮਿਲਦੇ-ਜੁਲਦੇ ਨਹੀਂ ਰਹਿਣਗੇ।
ਸਧਾਰਨ ਅਤੇ fulfillment‑ਕੇਂਦਰਤ status ਰੱਖੋ:
ਐਡਮਿਨ ਨੂੰ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਤੇਜ਼ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਕੀ ਚੀਜ਼ ਵਿਕ ਰਹੀ ਹੈ, ਕੀ ਪੈਡ ਹੋਇਆ, ਅਤੇ ਕੀ ਭੇਜਣਾ ਬਾਕੀ ਹੈ।
ਘੱਟੋ‑ਘੱਟ ਫੀਚਰ:
ਹਫਤੇ ਵਿੱਚ charts ਅਤੇ ਲਵ‑ਪ੍ਰਕਾਰ ਦੀਆਂ ਰੋਲਜ਼ ਛੱਡ ਦਿਓ।
ਇਕ ਸਧਾਰਨ, ਸੁਰੱਖਿਅਤ ਰੂਟੀਨ:
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤਦੇ ਹੋ, ਹਰ ਵੱਡੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲਓ ਤਾਂ ਕਿ ਤੇਜ਼ ਰੋਲਬੈਕ ਹੋ ਸਕੇ।
new, paid, packed, shipped, canceled (ਸਿਰਫ਼ ਜਦੋਂ ਤੁਸੀਂ واقعی refunds ਦਾ ਸਹारा ਦਿੰਦੇ ਹੋ ਤਾਂ refunded ਜੋੜੋ)created, paid, failed, canceled, refundedਲਕਸ਼ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਨਜ਼ਰ ਵਿੱਚ ਜਾਣ ਸਕੋ ਕਿ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇ।