ਵੈੱਬਹੁੱਕ ਕੀ ਹੈ? ਐਪਾਂ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਕਿਵੇਂ ਸੂਚਿਤ ਕਰਦੀਆਂ ਹਨ

ਵੈੱਬਹੁੱਕ ਇੱਕ ਆਟੋਮੈਟਿਕ ਸੁਨੇਹਾ ਹੈ ਜੋ ਕੋਈ ਸੇਵਾ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਉਸੇ ਪਲ ਭੇਜਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਗਾਹਕ ਦਾ ਭੁਗਤਾਨ ਸਫ਼ਲ ਹੁੰਦਾ ਹੈ, Stripe ਤੁਹਾਡੀ ਐਪ ਦੇ ਇੱਕ ਪਤੇ 'ਤੇ ਵੈੱਬਹੁੱਕ ਭੇਜਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਲਿਖਿਆ ਹੁੰਦਾ ਹੈ “ਭੁਗਤਾਨ ਸਫ਼ਲ, ਵੇਰਵੇ ਇਹ ਹਨ”, ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿੰਦੀ ਹੈ — ਆਰਡਰ ਨੂੰ ਭੁਗਤਾਨ ਹੋਇਆ ਨਿਸ਼ਾਨ ਲਾਉਂਦੀ ਹੈ, ਰਸੀਦ ਭੇਜਦੀ ਹੈ, ਖਾਤਾ ਖੋਲ੍ਹਦੀ ਹੈ। ਸੰਖੇਪ ਵਿੱਚ: API ਵਿੱਚ ਤੁਹਾਡੀ ਐਪ ਦੂਜੀ ਸੇਵਾ ਨੂੰ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ; ਵੈੱਬਹੁੱਕ ਵਿੱਚ ਦੂਜੀ ਸੇਵਾ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਕੁਝ ਦੱਸਣ ਲਈ ਕਾਲ ਕਰਦੀ ਹੈ।

AI ਨਾਲ ਬਣਾਉਂਦੇ ਸਮੇਂ ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

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

• ਐਂਡਪੌਇੰਟ ਕਿਸੇ ਵੀ ਬੇਨਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਨਕਲੀ “ਭੁਗਤਾਨ ਸਫ਼ਲ” ਘਟਨਾ ਭੇਜ ਸਕਦਾ ਹੈ।
• ਐਪ ਚੈੱਕਆਊਟ ਰੀਡਾਇਰੈਕਟ ਪੰਨੇ 'ਤੇ ਪਹੁੰਚ ਦਿੰਦੀ ਹੈ ਨਾ ਕਿ ਵੈੱਬਹੁੱਕ 'ਤੇ, ਇਸ ਲਈ ਜਿਹੜੇ ਲੋਕ ਟੈਬ ਜਲਦੀ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਉਹ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ ਜਿਸਦਾ ਉਹਨਾਂ ਭੁਗਤਾਨ ਕੀਤਾ, ਅਤੇ ਜਿਹੜੇ ਲੋਕ ਸਫ਼ਲਤਾ ਵਾਲਾ URL ਲੱਭ ਲੈਂਦੇ ਹਨ ਉਹਨਾਂ ਨੂੰ ਮੁਫ਼ਤ ਮਿਲ ਜਾਂਦਾ ਹੈ।
• ਇੱਕੋ ਘਟਨਾ ਦੋ ਵਾਰ ਆਉਂਦੀ ਹੈ ਅਤੇ ਗਾਹਕ ਨੂੰ ਦੋ ਆਰਡਰ ਜਾਂ ਦੋ ਈਮੇਲਾਂ ਮਿਲ ਜਾਂਦੀਆਂ ਹਨ।

ਵੈੱਬਹੁੱਕ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਇਹ ਜਾਣਨ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਇਹ ਸੁਰੱਖਿਆਵਾਂ ਮੰਗ ਸਕਦੇ ਹੋ।

ਰੋਜ਼ਾਨਾ ਦੀ ਮਿਸਾਲ: ਡਿਲੀਵਰੀ ਦਾ ਸੁਨੇਹਾ

ਤੁਸੀਂ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਪਤਾ ਲਾ ਸਕਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ ਪਾਰਸਲ ਆ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ। ਤੁਸੀਂ ਹਰ ਦਸ ਮਿੰਟ ਬਾਅਦ ਦਰਵਾਜ਼ੇ ਤੱਕ ਜਾ ਕੇ ਵੇਖ ਸਕਦੇ ਹੋ (ਇਹ ਪੋਲਿੰਗ ਹੈ — ਤੁਹਾਡੀ ਐਪ ਵਾਰ-ਵਾਰ ਇੱਕ API ਨੂੰ ਪੁੱਛਦੀ ਹੈ “ਕੁਝ ਨਵਾਂ ਹੈ?”)। ਜਾਂ ਕੋਰੀਅਰ ਤੁਹਾਨੂੰ ਡਿਲੀਵਰੀ ਹੋਣ 'ਤੇ ਸੁਨੇਹਾ ਭੇਜ ਸਕਦਾ ਹੈ (ਇਹ ਵੈੱਬਹੁੱਕ ਹੈ)।

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

ਵੈੱਬਹੁੱਕ ਕਦਮ-ਦਰ-ਕਦਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

1. ਤੁਸੀਂ ਇੱਕ ਐਂਡਪੌਇੰਟ ਬਣਾਉਂਦੇ ਹੋ ਆਪਣੀ ਐਪ ਦੇ ਬੈਕਐਂਡ ਵਿੱਚ: ਇੱਕ URL ਜਿਵੇਂ https://yourapp.com/webhooks/stripe ਜੋ POST ਬੇਨਤੀਆਂ ਸਵੀਕਾਰ ਕਰੇ।
2. ਤੁਸੀਂ ਉਹ URL ਪ੍ਰਦਾਤਾ ਕੋਲ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ ਅਤੇ ਚੁਣਦੇ ਹੋ ਕਿ ਕਿਹੜੀਆਂ ਘਟਨਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, “ਚੈੱਕਆਊਟ ਪੂਰਾ ਹੋਇਆ” ਅਤੇ “ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਰੱਦ ਹੋਈ”)।
3. ਪ੍ਰਦਾਤਾ ਤੁਹਾਨੂੰ ਇੱਕ ਦਸਤਖ਼ਤ ਕੁੰਜੀ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਸਰਵਰ 'ਤੇ ਇੱਕ ਸੀਕ੍ਰੇਟ ਵਜੋਂ ਸੰਭਾਲਦੇ ਹੋ — ਵੇਖੋ ਇਨਵਾਇਰਨਮੈਂਟ ਵੇਰੀਏਬਲ ਅਤੇ ਸੀਕ੍ਰੇਟਸ।
4. ਇੱਕ ਘਟਨਾ ਵਾਪਰਦੀ ਹੈ। ਪ੍ਰਦਾਤਾ ਤੁਹਾਡੇ URL 'ਤੇ ਇੱਕ HTTP ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ ਜਿਸਦੇ ਬਾਡੀ ਵਿੱਚ JSON ਹੁੰਦਾ ਹੈ ਜੋ ਘਟਨਾ ਦੱਸਦਾ ਹੈ, ਨਾਲ ਇੱਕ ਦਸਤਖ਼ਤ ਹੈਡਰ।
5. ਤੁਹਾਡੀ ਐਪ ਦਸਤਖ਼ਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ, ਘਟਨਾ ਦਾ ID ਦਰਜ ਕਰਦੀ ਹੈ, ਜਲਦੀ ਸਫ਼ਲਤਾ ਕੋਡ (200) ਨਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਕੰਮ ਕਰਦੀ ਹੈ।
6. ਜੇ ਤੁਹਾਡੀ ਐਪ ਸਫ਼ਲਤਾ ਨਾਲ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ, ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਦਾਤਾ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ।

ਦਸਤਖ਼ਤ

ਦਸਤਖ਼ਤ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਪ੍ਰਦਾਤਾ ਤੋਂ ਆਈ ਹੈ ਅਤੇ ਬਦਲੀ ਨਹੀਂ ਗਈ। ਉਦਾਹਰਨ ਲਈ, Stripe ਦਸਤਖ਼ਤ ਕੁੰਜੀ ਵਰਤ ਕੇ ਬੇਨਤੀ ਬਾਡੀ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਉੱਤੇ SHA-256 ਨਾਲ ਇੱਕ HMAC (ਕੁੰਜੀ-ਅਧਾਰਤ ਛਾਪ ਦੀ ਇੱਕ ਕਿਸਮ) ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ Stripe-Signature ਹੈਡਰ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਆਪਣੀ ਕਾਪੀ ਵਾਲੀ ਕੁੰਜੀ ਨਾਲ ਉਹੀ ਹਿਸਾਬ ਕਰਦੀ ਹੈ; ਜੇ ਨਤੀਜੇ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਬੇਨਤੀ ਅਸਲੀ ਹੈ। ਕਿਉਂਕਿ ਟਾਈਮਸਟੈਂਪ ਵੀ ਦਸਤਖ਼ਤ ਹੋਇਆ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਪੁਰਾਣੀਆਂ ਬੇਨਤੀਆਂ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਕਿਸੇ ਨੇ ਰਿਕਾਰਡ ਕਰਕੇ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਭੇਜੀਆਂ ਹੋਣ — Stripe ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦਾ ਡਿਫ਼ਾਲਟ, ਉਸਦੇ ਦਸਤਾਵੇਜ਼ਾਂ ਅਨੁਸਾਰ ਸਤੰਬਰ 2026 ਤੱਕ, ਪੰਜ ਮਿੰਟ ਦੀ ਸਹਿਣਸ਼ੀਲਤਾ ਹੈ।

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

ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼, ਦੁਹਰਾਅ ਅਤੇ ਕ੍ਰਮ

ਪ੍ਰਦਾਤਾ ਵੱਖ-ਵੱਖ ਹਨ, ਇਸ ਲਈ ਹਰੇਕ ਦੇ ਦਸਤਾਵੇਜ਼ ਵੇਖੋ। ਸਤੰਬਰ 2026 ਤੱਕ:

Stripe ਦੇ ਦਸਤਾਵੇਜ਼ ਇਹ ਵੀ ਕਹਿੰਦੇ ਹਨ ਕਿ ਘਟਨਾਵਾਂ ਦੇ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਆਉਣ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ, ਅਤੇ ਕਦੇ-ਕਦੇ ਇੱਕੋ ਘਟਨਾ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਵੀ ਆ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਘਟਨਾ ID ਟਰੈਕ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੰਦਾ ਹੈ।

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

ਇੱਕ ਕੰਮ ਕੀਤੀ ਮਿਸਾਲ: ਭੁਗਤਾਨ ਵਾਲਾ ਕੋਰਸ ਖੋਲ੍ਹਣਾ

ਤੁਸੀਂ ਇੱਕ ਔਨਲਾਈਨ ਕੋਰਸ ਵੇਚਦੇ ਹੋ। ਇੱਕ ਵਿਦਿਆਰਥੀ ਖ਼ਰੀਦੋ 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, Stripe ਦੇ ਹੋਸਟ ਕੀਤੇ ਚੈੱਕਆਊਟ ਪੰਨੇ 'ਤੇ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਸਾਈਟ 'ਤੇ ਵਾਪਸ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।

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

ਵੈੱਬਹੁੱਕ ਵਾਲਾ ਤਰੀਕਾ:

1. ਜਦੋਂ Stripe ਭੁਗਤਾਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਇਹ /webhooks/stripe ਨੂੰ checkout.session.completed ਘਟਨਾ ਭੇਜਦਾ ਹੈ।
2. ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਦਸਤਖ਼ਤ ਕੁੰਜੀ ਨਾਲ ਦਸਤਖ਼ਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਇਹ 400 ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਕਰਦਾ।
3. ਇਹ ਜਾਂਚਦਾ ਹੈ ਕਿ ਉਹ ਘਟਨਾ ID ਪਹਿਲਾਂ ਪ੍ਰੋਸੈਸ ਹੋ ਚੁੱਕੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਹਾਂ, ਤਾਂ ਇਹ 200 ਨਾਲ ਜਵਾਬ ਦੇ ਕੇ ਰੁਕ ਜਾਂਦਾ ਹੈ।
4. ਇਹ ਘਟਨਾ ID ਸੰਭਾਲਦਾ ਹੈ, 200 ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਫਿਰ ਵਿਦਿਆਰਥੀ ਨੂੰ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਵਾਗਤ ਈਮੇਲ ਭੇਜਦਾ ਹੈ।
5. ਧੰਨਵਾਦ ਪੰਨਾ ਸਿਰਫ਼ ਲਿਖਦਾ ਹੈ “ਭੁਗਤਾਨ ਮਿਲ ਗਿਆ — ਤੁਹਾਡਾ ਕੋਰਸ ਥੋੜ੍ਹੀ ਦੇਰ ਵਿੱਚ ਦਕਿਸੇਗਾ” ਅਤੇ ਵਿਦਿਆਰਥੀ ਦੀ ਪਹੁੰਚ ਦੀ ਸਥਿਤੀ ਜਾਂਚਦਾ ਹੈ।

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

ਮੁੱਖ ਸ਼ਬਦ

• ਐਂਡਪੌਇੰਟ: ਤੁਹਾਡੀ ਐਪ ਦਾ URL ਜੋ ਵੈੱਬਹੁੱਕ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
• ਘਟਨਾ / ਪੇਲੋਡ: ਕੀ ਹੋਇਆ, ਅਤੇ ਉਸਦਾ ਵੇਰਵਾ ਦੇਣ ਵਾਲਾ ਡੇਟਾ (ਆਮ ਤੌਰ 'ਤੇ JSON)।
• ਦਸਤਖ਼ਤ ਕੁੰਜੀ: ਦਸਤਖ਼ਤਾਂ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਸਾਂਝੀ ਗੁਪਤ ਕੁੰਜੀ।
• ਇਡੈਮਪੋਟੈਂਟ: ਇੱਕੋ ਨਤੀਜੇ ਨਾਲ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਚਲਾਉਣਾ ਸੁਰੱਖਿਅਤ।
• ਪੋਲਿੰਗ: ਵੈੱਬਹੁੱਕ ਦੀ ਉਡੀਕ ਕਰਨ ਦੀ ਬਜਾਏ, ਬਦਲਾਅ ਲਈ ਇੱਕ API ਨੂੰ ਵਾਰ-ਵਾਰ ਪੁੱਛਣਾ।
• ਟਨਲ: ਇੱਕ ਟੂਲ ਜੋ ਲੈਪਟਾਪ ਨੂੰ ਅਸਥਾਈ ਜਨਤਕ URL ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਵਿਕਾਸ ਦੌਰਾਨ ਵੈੱਬਹੁੱਕ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਣ।

ਆਮ ਗ਼ਲਤੀਆਂ ਅਤੇ ਗ਼ਲਤਫ਼ਹਿਮੀਆਂ

• ਦਸਤਖ਼ਤਾਂ ਦੀ ਪੁਸ਼ਟੀ ਨਾ ਕਰਨਾ। ਐਂਡਪੌਇੰਟ ਦਾ URL ਕੋਈ ਗੁਪਤ ਨਹੀਂ ਹੈ। ਪੁਸ਼ਟੀ ਹੀ ਬੇਨਤੀ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
• ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਹੌਲੀ ਕੰਮ ਕਰਨਾ। ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਈਮੇਲਾਂ ਭੇਜਣਾ ਜਾਂ PDF ਬਣਾਉਣਾ ਟਾਈਮਆਊਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਦੁਹਰਾਅ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ।
• ਮੰਨ ਲੈਣਾ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ, ਕ੍ਰਮ ਵਿੱਚ। ਘਟਨਾ ID ਦਰਜ ਕਰੋ ਅਤੇ ਆਉਣ ਦੇ ਕ੍ਰਮ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ।
• ਪ੍ਰੀਵਿਊ URL ਵਰਤਣਾ। ਵੈੱਬਹੁੱਕਾਂ ਨੂੰ ਇੱਕ ਸਥਿਰ, ਜਨਤਕ ਪਤਾ ਚਾਹੀਦਾ ਹੈ। ਨਿੱਜੀ ਪ੍ਰੀਵਿਊ ਅਤੇ localhost ਇੰਟਰਨੈੱਟ ਤੋਂ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੁੰਦੇ; ਆਪਣਾ ਪ੍ਰਕਾਸ਼ਿਤ URL ਵਰਤੋ (ਜਾਂ ਟੈਸਟ ਦੌਰਾਨ ਟਨਲ)।
• ਟੈਸਟ ਅਤੇ ਲਾਈਵ ਕੀਜ਼ ਮਿਲਾਉਣਾ। ਪ੍ਰਦਾਤਾ ਅਕਸਰ ਟੈਸਟ ਅਤੇ ਲਾਈਵ ਮੋਡ ਲਈ ਵੱਖ-ਵੱਖ ਦਸਤਖ਼ਤ ਕੁੰਜੀਆਂ ਦਿੰਦੇ ਹਨ। ਦੋਵੇਂ ਸੰਭਾਲੋ ਅਤੇ ਸਹੀ ਵਰਤੋ।
• ਮਹੱਤਵਪੂਰਨ ਫ਼ੈਸਲਿਆਂ ਲਈ ਪੇਲੋਡ 'ਤੇ ਅੰਨ੍ਹਾ ਭਰੋਸਾ ਕਰਨਾ। ਉੱਚ-ਦਾਅ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ, ਘਟਨਾ ਮਿਲਣ ਤੋਂ ਬਾਅਦ ਪ੍ਰਦਾਤਾ ਦੇ API ਤੋਂ ਤਾਜ਼ਾ ਹਾਲਤ ਲੈਣਾ ਵਾਜਬ ਹੈ।

ਆਪਣੇ AI ਬਿਲਡਰ ਤੋਂ ਕੀ ਮੰਗਣਾ ਹੈ

ਸਰਵਰ 'ਤੇ ਇੱਕ POST /webhooks/stripe ਐਂਡਪੌਇੰਟ ਜੋੜੋ। ਕੱਚੀ ਬੇਨਤੀ ਬਾਡੀ ਅਤੇ ਸੀਕ੍ਰੇਟ STRIPE_WEBHOOK_SECRET ਵਰਤ ਕੇ Stripe ਦਸਤਖ਼ਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਗ਼ਲਤ ਦਸਤਖ਼ਤਾਂ ਨੂੰ 400 ਨਾਲ ਰੱਦ ਕਰੋ। ਹਰ ਘਟਨਾ ID ਸੰਭਾਲੋ ਅਤੇ ਪਹਿਲਾਂ ਪ੍ਰੋਸੈਸ ਹੋ ਚੁੱਕੀਆਂ ਘਟਨਾਵਾਂ ਛੱਡ ਦਿਓ। ਜਲਦੀ 200 ਨਾਲ ਜਵਾਬ ਦਿਓ, ਫਿਰ checkout.session.completed ਨੂੰ ਸੰਭਾਲੋ ਜਿਸ ਵਿੱਚ ਆਰਡਰ ਭੁਗਤਾਨ ਹੋਇਆ ਨਿਸ਼ਾਨ ਹੋਵੇ ਅਤੇ ਰਸੀਦ ਭੇਜੀ ਜਾਵੇ। ਘਟਨਾ ਦੀ ਕਿਸਮ ਲੌਗ ਕਰੋ। ਚੈੱਕਆਊਟ ਸਫ਼ਲਤਾ ਪੰਨੇ ਤੋਂ ਪਹੁੰਚ ਨਾ ਦਿਓ।

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

Mythex 'ਤੇ ਵੈੱਬਹੁੱਕ

Mythex ਵੈੱਬਹੁੱਕਾਂ ਲਈ ਵੱਖਰੀ ਸੇਵਾ ਨਹੀਂ ਚਲਾਉਂਦਾ; ਤੁਸੀਂ ਏਜੰਟ ਨੂੰ ਆਪਣੀ ਐਪ ਦੇ ਆਪਣੇ ਬੈਕਐਂਡ ਵਿੱਚ ਵੈੱਬਹੁੱਕ ਐਂਡਪੌਇੰਟ ਜੋੜਨ ਲਈ ਕਹਿੰਦੇ ਹੋ, ਅਤੇ ਪ੍ਰਦਾਤਾ ਨੂੰ ਆਪਣੇ ਪ੍ਰਕਾਸ਼ਿਤ URL ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹੋ, ਕਿਉਂਕਿ ਵੈੱਬਹੁੱਕਾਂ ਨੂੰ ਜਨਤਕ ਪਤਾ ਚਾਹੀਦਾ ਹੈ। ਦਸਤਖ਼ਤ ਕੁੰਜੀ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਸੀਕ੍ਰੇਟਸ ਵਿੱਚ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਲਾਈਵ ਐਪ 'ਤੇ ਇਸਨੂੰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਵੈੱਬਹੁੱਕ ਸੰਭਾਲਣ ਬਾਰੇ ਡੌਕਸ ਰੈਸਿਪੀ ਵਿੱਚ ਇੱਕ ਸਟਾਰਟਰ ਪ੍ਰੋਂਪਟ ਹੈ, ਅਤੇ ਭੁਗਤਾਨ ਲੈਣ ਵਾਲੀਆਂ ਐਪਾਂ ਲਈ ਸਟੋਰ ਟੈਮਪਲੇਟ ਇੱਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤ ਹਨ।

ਸਵਾਲ