ਆਪਣੀ ਐਪ ਵਿੱਚ ਭੁਗਤਾਨ ਕਿਵੇਂ ਜੋੜੀਏ: ਚੈੱਕਆਉਟ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਵੈਬਹੁੱਕ

ਐਪ ਵਿੱਚ ਭੁਗਤਾਨ ਜੋੜਨ ਦਾ ਸਭ ਤੋਂ ਸਰਲ ਤਰੀਕਾ Stripe ਹੈ: ਜੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ "Buy" ਬਟਨ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਆਰਡਰ ਹੱਥੀਂ ਸੰਭਾਲ ਸਕਦੇ ਹੋ ਤਾਂ Payment Link, ਜੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿਸ ਨੇ ਭੁਗਤਾਨ ਕੀਤਾ ਅਤੇ ਆਪਣੇ ਆਪ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣੀ ਹੈ ਤਾਂ Stripe Checkout, ਅਤੇ ਆਵਰਤੀ ਬਿਲਿੰਗ ਲਈ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮੋਡ ਵਿੱਚ Checkout ਅਤੇ Stripe ਦਾ ਗਾਹਕ ਪੋਰਟਲ। ਸਧਾਰਨ ਮਾਮਲੇ ਨੂੰ ਛੱਡ ਕੇ ਹਰ ਹਾਲਤ ਵਿੱਚ ਵੈਬਹੁੱਕ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਯਾਨੀ ਇੱਕ ਸਰਵਰ ਐਂਡਪੌਇੰਟ ਜੋ Stripe ਭੁਗਤਾਨ ਸਫਲ ਹੋਣ 'ਤੇ ਬੁਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਲਾਈਵ ਕੁੰਜੀਆਂ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ Stripe ਦੀਆਂ ਟੈਸਟ ਕੁੰਜੀਆਂ ਅਤੇ ਟੈਸਟ ਕਾਰਡਾਂ ਨਾਲ ਜਾਂਚੋ।

ਇਹ ਗਾਈਡ ਹਰ ਵਿਕਲਪ ਸਮਝਾਉਂਦੀ ਹੈ, ਉਹ ਵੈਬਹੁੱਕ ਵਾਲਾ ਹਿੱਸਾ ਜੋ ਜ਼ਿਆਦਾਤਰ ਟਿਊਟੋਰੀਅਲ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਅਸਲ ਪੈਸੇ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ। Stripe ਦੇ ਵੇਰਵੇ ਸਤੰਬਰ 2026 ਤੱਕ ਦੇ ਉਸ ਦੇ ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਹਨ।

ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਕਿਉਂ ਵਰਤੀਏ

ਆਪਣੇ ਫਾਰਮਾਂ ਵਿੱਚ ਕਦੇ ਵੀ ਕਾਰਡ ਨੰਬਰ ਇਕੱਠੇ ਨਾ ਕਰੋ। ਕੱਚਾ ਕਾਰਡ ਡੇਟਾ ਸੰਭਾਲਣ ਨਾਲ ਤੁਸੀਂ PCI DSS (ਕਾਰਡ ਉਦਯੋਗ ਦਾ ਸੁਰੱਖਿਆ ਮਿਆਰ) ਦੇ ਦਾਇਰੇ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹੋ ਅਤੇ ਇਹ ਵੱਡੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ। Stripe ਵਰਗਾ ਭੁਗਤਾਨ ਪ੍ਰਦਾਤਾ ਭੁਗਤਾਨ ਫਾਰਮ ਹੋਸਟ ਕਰਦਾ ਹੈ, ਕਾਰਡ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਬੈਂਕ ਦੀ ਪੁਸ਼ਟੀ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਨਤੀਜਾ ਦੱਸਦਾ ਹੈ। ਤੁਹਾਡੀ ਐਪ ਸਿਰਫ਼ ਇਹ ਦੇਖਦੀ ਹੈ ਕਿ "ਗਾਹਕ X ਨੇ Y ਲਈ ਭੁਗਤਾਨ ਕੀਤਾ"।

ਇਹ ਗਾਈਡ Stripe ਵਰਤਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਦਸਤਾਵੇਜ਼ਬੱਧ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ AI ਐਪ ਬਿਲਡਰਾਂ ਵਿੱਚ ਸਮਰਥਿਤ ਹੈ। ਹੋਰ ਪ੍ਰਦਾਤਾ ਵੀ ਹਨ, ਅਤੇ ਕੁਝ "merchant of record" ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਵਿਕਰੀ ਟੈਕਸ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਆਪਣੇ ਉੱਤੇ ਲੈਂਦੇ ਹਨ; ਜੇ ਟੈਕਸ ਪਾਲਣਾ ਤੁਹਾਨੂੰ ਫ਼ਿਕਰ ਹੈ ਤਾਂ ਉਹ ਮਾਡਲ ਵੀ ਤੁਲਨਾ ਕਰਨ ਯੋਗ ਹੈ।

Stripe ਨਾਲ ਭੁਗਤਾਨ ਲੈਣ ਦੇ ਤਿੰਨ ਤਰੀਕੇ

Payment Links

Payment Link ਇੱਕ Stripe-ਹੋਸਟ ਕੀਤਾ ਭੁਗਤਾਨ ਪੰਨਾ ਹੈ ਜੋ ਤੁਸੀਂ Stripe Dashboard ਵਿੱਚ ਬਿਨਾਂ ਕੋਡ ਦੇ ਬਣਾਉਂਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਇੱਕ URL ਮਿਲਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਐਪ ਵਿੱਚ ਬਟਨ ਦੇ ਪਿੱਛੇ ਲਗਾ ਸਕਦੇ ਹੋ, ਈਮੇਲ ਵਿੱਚ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ QR ਕੋਡ ਵਜੋਂ ਦਿਖਾ ਸਕਦੇ ਹੋ। Stripe ਦੇ ਦਸਤਾਵੇਜ਼ ਦੱਸਦੇ ਹਨ ਕਿ Payment Links ਇੱਕ ਉਤਪਾਦ, ਇੱਕ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਵੇਚ ਸਕਦੇ ਹਨ, ਜਾਂ ਦਾਨ ਸਵੀਕਾਰ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਗਾਹਕਾਂ ਨੂੰ ਚੁਣਨ ਦੇ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਭੁਗਤਾਨ ਕਰਨਾ ਹੈ ਜਾਂ ਖਰੀਦਾਂ ਦੀ ਗਿਣਤੀ ਸੀਮਤ ਕਰ ਸਕਦੇ ਹੋ।

ਫੜ ਇਹ ਹੈ: ਤੁਹਾਡੀ ਐਪ ਆਪਣੇ ਆਪ ਨਹੀਂ ਜਾਣਦੀ ਕਿ ਕੋਈ ਖਾਸ ਲੌਗ-ਇਨ ਯੂਜ਼ਰ ਨੇ ਭੁਗਤਾਨ ਕੀਤਾ। ਦਾਨ ਵਾਲੇ ਪੰਨੇ ਜਾਂ ਛੋਟੀ ਦੁਕਾਨ ਲਈ, ਜਿੱਥੇ ਤੁਸੀਂ Stripe ਦੀਆਂ ਈਮੇਲ ਸੂਚਨਾਵਾਂ ਤੋਂ ਹੱਥੀਂ ਆਰਡਰ ਪੂਰੇ ਕਰਦੇ ਹੋ, ਇਹ ਠੀਕ ਹੈ। "Pro ਫੀਚਰ ਖੋਲ੍ਹਣ ਲਈ ਭੁਗਤਾਨ ਕਰੋ" ਲਈ ਇਹ ਠੀਕ ਨਹੀਂ।

Stripe Checkout

Checkout ਇੱਕ ਭੁਗਤਾਨ ਪੰਨਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਸਰਵਰ ਮੰਗ ਅਨੁਸਾਰ ਕਿਸੇ ਖਾਸ ਖਰੀਦ ਲਈ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਹਾਡਾ ਸਰਵਰ Stripe ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਖਰੀਦਿਆ ਜਾ ਰਿਹਾ ਹੈ (ਅਤੇ ਜੇ ਚਾਹੋ ਤਾਂ ਕਿਹੜਾ ਗਾਹਕ ਖਰੀਦ ਰਿਹਾ ਹੈ), Stripe ਇੱਕ URL ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਗਾਹਕ ਨੂੰ ਉੱਥੇ ਭੇਜਦੇ ਹੋ। Stripe ਦੇ ਦਸਤਾਵੇਜ਼ ਇਸ ਨੂੰ ਇੱਕ-ਵਾਰੀ ਅਤੇ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਦੋਵਾਂ ਲਈ ਸਮਰਥਿਤ ਦੱਸਦੇ ਹਨ: Stripe-ਹੋਸਟ ਕੀਤਾ ਪੂਰਾ ਪੰਨਾ, ਤੁਹਾਡੀ ਸਾਈਟ ਵਿੱਚ ਏਮਬੈੱਡ ਕੀਤਾ ਪੰਨਾ, ਜਾਂ ਏਮਬੈੱਡ ਕੀਤਾ ਫਾਰਮ।

ਪ੍ਰਵਾਹ ਇਹ ਹੈ:

1. ਗਾਹਕ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ Buy 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ।
2. ਤੁਹਾਡਾ ਸਰਵਰ ਤੁਹਾਡੀ ਸੀਕਰੇਟ ਕੁੰਜੀ ਵਰਤ ਕੇ Checkout Session ਬਣਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇੱਕ ID ਹੁੰਦੀ ਹੈ ਜੋ ਇਸ ਨੂੰ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਜਾਂ ਆਰਡਰ ਨਾਲ ਜੋੜਦੀ ਹੈ।
3. ਗਾਹਕ ਨੂੰ Stripe 'ਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ।
4. Stripe ਗਾਹਕ ਨੂੰ ਤੁਹਾਡੇ ਸਫਲਤਾ ਵਾਲੇ ਪੰਨੇ 'ਤੇ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।
5. Stripe ਇੱਕ checkout.session.completed ਘਟਨਾ ਤੁਹਾਡੇ ਵੈਬਹੁੱਕ ਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡਾ ਸਰਵਰ ਆਰਡਰ ਨੂੰ ਭੁਗਤਿਆ ਦੱਸਦਾ ਹੈ ਜਾਂ ਪਹੁੰਚ ਖੋਲ੍ਹਦਾ ਹੈ।

ਕਦਮ 2 ਸਰਵਰ 'ਤੇ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਡੀ ਸੀਕਰੇਟ ਕੁੰਜੀ ਵਰਤਦਾ ਹੈ। Checkout ਨੂੰ ਬੈਕਐਂਡ ਦੀ ਲੋੜ ਦਾ ਇਹੀ ਮੁੱਖ ਕਾਰਨ ਹੈ।

ਸਬਸਕ੍ਰਿਪਸ਼ਨ

ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਈ Checkout ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮੋਡ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ Stripe ਵਿੱਚ ਤੁਹਾਡੀ ਬਣਾਈ ਆਵਰਤੀ ਕੀਮਤ ਹੁੰਦੀ ਹੈ। ਪਹਿਲਾ ਭੁਗਤਾਨ ਉੱਪਰ ਦੇ ਪ੍ਰਵਾਹ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਨਵੀਨੀਕਰਨ, ਫੇਲ੍ਹ ਹੋਏ ਕਾਰਡ, ਅੱਪਗ੍ਰੇਡ ਅਤੇ ਰੱਦ ਕਰਨਾ ਸਮੇਂ ਦੇ ਨਾਲ ਹੁੰਦੇ ਹਨ, ਅਕਸਰ ਉਦੋਂ ਜਦੋਂ ਗਾਹਕ ਤੁਹਾਡੀ ਐਪ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਤੁਹਾਡੀ ਐਪ ਇਹਨਾਂ ਬਾਰੇ ਸਿਰਫ਼ ਵੈਬਹੁੱਕ ਰਾਹੀਂ ਜਾਣਦੀ ਹੈ।

ਗਾਹਕ ਨੂੰ ਆਪਣੀ ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਖੁਦ ਸੰਭਾਲਣ ਦੇਣ ਲਈ Stripe ਇੱਕ ਹੋਸਟ ਕੀਤਾ ਗਾਹਕ ਪੋਰਟਲ ਦਿੰਦਾ ਹੈ। Stripe ਦੇ ਦਸਤਾਵੇਜ਼ ਮੁਤਾਬਕ ਗਾਹਕ ਉੱਥੇ ਭੁਗਤਾਨ ਤਰੀਕਾ ਅਤੇ ਬਿਲਿੰਗ ਵੇਰਵੇ ਬਦਲ ਸਕਦੇ ਹਨ, ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਬਦਲ ਜਾਂ ਰੱਦ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਨਵੌਇਸ ਦੇਖ ਅਤੇ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਨੂੰ Stripe Dashboard ਵਿੱਚ ਸੰਰਚਿਤ ਕਰਦੇ ਹੋ ਅਤੇ "Manage billing" ਬਟਨ ਜੋੜਦੇ ਹੋ ਜੋ ਗਾਹਕ ਨੂੰ ਉੱਥੇ ਭੇਜਦਾ ਹੈ। ਇਸ ਨਾਲ ਉਹ ਸਕ੍ਰੀਨਾਂ ਖੁਦ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ।

ਵੈਬਹੁੱਕ: ਉਹ ਹਿੱਸਾ ਜੋ ਛੱਡਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ

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

ਸੰਭਾਲਣ ਯੋਗ ਘਟਨਾਵਾਂ

ਸਹੀ ਵੈਬਹੁੱਕ ਹੈਂਡਲਰ ਦੇ ਨਿਯਮ

ਇਹ ਸਿੱਧੇ Stripe ਦੇ ਵੈਬਹੁੱਕ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਹਨ, ਅਤੇ AI ਨਾਲ ਬਣੇ ਹੈਂਡਲਰ ਕਈ ਵਾਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਖੁੰਝਾ ਦਿੰਦੇ ਹਨ:

• ਦਸਤਖ਼ਤ ਦੀ ਜਾਂਚ ਕਰੋ। ਹਰ ਘਟਨਾ ਵਿੱਚ Stripe-Signature ਹੈਡਰ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਹੈਂਡਲਰ ਇਸ ਨੂੰ endpoint ਦੇ ਸਾਈਨਿੰਗ ਸੀਕਰੇਟ ਨਾਲ ਜਾਂਚਦਾ ਹੈ (ਜੋ whsec_ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ)। ਇਸ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਸਰਵਰ ਨੂੰ ਨਕਲੀ "ਭੁਗਤਾਨ ਸਫਲ" ਭੇਜ ਸਕਦਾ ਹੈ।
• ਕੱਚਾ ਬੇਨਤੀ ਬਾਡੀ ਵਰਤੋ। ਜੇ ਤੁਹਾਡਾ ਫਰੇਮਵਰਕ ਪਹਿਲਾਂ ਬਾਡੀ ਨੂੰ ਪਾਰਸ ਜਾਂ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਦਸਤਖ਼ਤ ਦੀ ਜਾਂਚ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦੀ ਹੈ।
• ਜਲਦੀ 2xx ਜਵਾਬ ਦਿਓ, ਫਿਰ ਹੌਲੀ ਕੰਮ ਕਰੋ। ਟਾਈਮਆਊਟ ਵੀ ਫੇਲ੍ਹ ਗਿਣੇ ਜਾਂਦੇ ਹਨ।
• ਦੁਹਰਾਅ ਸੰਭਾਲੋ। Stripe ਇੱਕੋ ਘਟਨਾ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਭੇਜ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਸੈੱਸ ਹੋਈਆਂ ਘਟਨਾ ID ਰਿਕਾਰਡ ਕਰੋ, ਜਾਂ ਪੂਰਤੀ ਨੂੰ ਦੋ ਵਾਰ ਚੱਲਣ 'ਤੇ ਵੀ ਸੁਰੱਖਿਅਤ ਬਣਾਓ।
• ਕ੍ਰਮ ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ। Stripe ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਘਟਨਾਵਾਂ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਆਉਣਗੀਆਂ ਜਿਸ ਵਿੱਚ ਵਾਪਰੀਆਂ।
• ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਉਮੀਦ ਰੱਖੋ। ਲਾਈਵ ਮੋਡ ਵਿੱਚ Stripe ਫੇਲ੍ਹ ਹੋਈ ਡਿਲਿਵਰੀ ਨੂੰ ਤਿੰਨ ਦਿਨਾਂ ਤੱਕ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਛੋਟਾ ਆਊਟੇਜ ਭੁਗਤਾਨ ਨਹੀਂ ਗੁਆਉਂਦਾ, ਪਰ ਤੁਹਾਡਾ ਹੈਂਡਲਰ ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਸੰਭਾਲਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਵੈਬਹੁੱਕਾਂ ਨੂੰ ਇੱਕ ਜਨਤਕ HTTPS ਪਤਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਹੀ ਚੱਲਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਪ੍ਰਕਾਸ਼ਿਤ ਹੋਵੇ (Stripe ਦਾ CLI ਡਿਵੈਲਪਰਾਂ ਲਈ ਘਟਨਾਵਾਂ ਲੋਕਲ ਮਸ਼ੀਨ ਵੱਲ ਭੇਜ ਸਕਦਾ ਹੈ)।

ਪੂਰੇ ਪ੍ਰਵਾਹ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਂਪਟ

"Pro pack" ਲਈ Stripe Checkout ਨਾਲ ਇੱਕ-ਵਾਰੀ ਖਰੀਦ ਜੋੜੋ (ਕੀਮਤ ID STRIPE_PRICE_ID ਵਿੱਚ)। Checkout Session ਸਰਵਰ 'ਤੇ ਸੀਕਰੇਟ ਵਿੱਚੋਂ STRIPE_SECRET_KEY ਵਰਤ ਕੇ ਬਣਾਓ, ਅਤੇ ਸੈਸ਼ਨ ਵਿੱਚ ਲੌਗ-ਇਨ ਯੂਜ਼ਰ ਦਾ ID ਸ਼ਾਮਲ ਕਰੋ। ਇੱਕ POST /api/stripe/webhook endpoint ਜੋੜੋ ਜੋ STRIPE_WEBHOOK_SECRET ਨਾਲ Stripe ਦਸਤਖ਼ਤ ਦੀ ਜਾਂਚ ਕੱਚੀ ਬੇਨਤੀ ਬਾਡੀ ਤੋਂ ਕਰੇ, checkout.session.completed ਸੰਭਾਲੇ, ਅਤੇ ਉਸ ਯੂਜ਼ਰ ਨੂੰ Pro pack ਵਾਲਾ ਦੱਸੇ। ਜੇ ਇੱਕੋ ਘਟਨਾ ਦੋ ਵਾਰ ਆਵੇ ਤਾਂ ਵੀ ਸੁਰੱਖਿਅਤ ਰਹੇ। ਸਫਲਤਾ ਅਤੇ ਰੱਦ ਕਰਨ ਵਾਲੇ ਪੰਨੇ। ਸੀਕਰੇਟ ਕੁੰਜੀ ਕਦੇ ਵੀ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਨਾ ਦਿਖਾਓ।

ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਈ ਸ਼ਾਮਲ ਕਰੋ: "STRIPE_PRICE_ID ਨਾਲ subscription mode ਵਰਤੋ। invoice.paid, invoice.payment_failed, customer.subscription.updated ਅਤੇ customer.subscription.deleted ਸੰਭਾਲੋ। ਇੱਕ Manage billing ਬਟਨ ਜੋੜੋ ਜੋ Stripe ਗਾਹਕ ਪੋਰਟਲ ਖੋਲ੍ਹੇ।"

ਟੈਸਟ ਮੋਡ

Stripe ਦੇ ਸੈਂਡਬਾਕਸ (ਟੈਸਟ) ਅਤੇ ਲਾਈਵ ਵਾਤਾਵਰਣ ਵੱਖਰੀਆਂ ਕੁੰਜੀਆਂ ਨਾਲ ਹਨ। ਸੈਂਡਬਾਕਸ ਕੁੰਜੀਆਂ pk_test_, sk_test_ ਜਾਂ rk_test_ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ; ਲਾਈਵ ਕੁੰਜੀਆਂ pk_live_, sk_live_ ਜਾਂ rk_live_ ਨਾਲ। ਟੈਸਟ ਲੈਣ-ਦੇਣ ਪੈਸੇ ਨਹੀਂ ਹਿਲਾਉਂਦੇ।

Stripe ਦੇ ਟੈਸਟਿੰਗ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਕੁਝ ਉਪਯੋਗੀ ਟੈਸਟ ਕਾਰਡ (ਕੋਈ ਵੀ ਭਵਿੱਖੀ ਮਿਆਦ, ਕੋਈ ਵੀ ਤਿੰਨ ਅੰਕਾਂ ਵਾਲਾ CVC):

ੱਟੋ-ਘੱਟ ਇਹ ਟੈਸਟ ਕਰੋ:

• ਸਫਲ ਭੁਗਤਾਨ ਸਹੀ ਯੂਜ਼ਰ ਲਈ ਸਹੀ ਚੀਜ਼ ਖੋਲ੍ਹਦਾ ਹੈ
• ਰੱਦ ਕੀਤਾ ਕਾਰਡ ਸਾਫ਼ ਸੁਨੇਹਾ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਖੋਲ੍ਹਦਾ
• ਭੁਗਤਾਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਬੰਦ ਕਰਨ 'ਤੇ ਵੀ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ (ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਵੈਬਹੁੱਕ ਕੰਮ ਕਰਦਾ ਹੈ, ਸਿਰਫ਼ ਸਫਲਤਾ ਵਾਲਾ ਪੰਨਾ ਨਹੀਂ)
• Stripe ਪੰਨੇ 'ਤੇ ਰੱਦ ਕਰਨ ਨਾਲ ਯੂਜ਼ਰ ਐਪ ਵਿੱਚ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵਸੂਲਿਆ ਨਹੀਂ ਜਾਂਦਾ
• ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਲਈ: ਗਾਹਕ ਪੋਰਟਲ ਵਿੱਚ ਰੱਦ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪਹੁੰਚ ਸਹੀ ਸਮੇਂ 'ਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ

ਲਾਈਵ ਹੋਣਾ

1. ਆਪਣਾ Stripe ਖਾਤਾ ਸਰਗਰਮ ਕਰੋ ਆਪਣੇ ਕਾਰੋਬਾਰ ਅਤੇ ਬੈਂਕ ਵੇਰਵਿਆਂ ਨਾਲ।
2. ਲਾਈਵ ਕੁੰਜੀਆਂ ਲਗਾਓ ਆਪਣੀ ਐਪ ਦੇ ਸੀਕਰੇਟ ਵਿੱਚ। Stripe ਸਿਰਫ਼ ਲੋੜੀਂਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਵਾਲੀਆਂ ਪ੍ਰਤਿਬੰਧਿਤ (restricted) ਕੁੰਜੀਆਂ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖੁੱਲ੍ਹੀ ਸੀਕਰੇਟ ਕੁੰਜੀ।
3. ਲਾਈਵ ਵੈਬਹੁੱਕ endpoint ਬਣਾਓ ਜੋ ਤੁਹਾਡੀ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ। ਇਸ ਦਾ ਆਪਣਾ ਸਾਈਨਿੰਗ ਸੀਕਰੇਟ ਹੈ, ਟੈਸਟ ਵਾਲੇ ਤੋਂ ਵੱਖਰਾ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ।
4. ਲਾਈਵ ਮੋਡ ਵਿੱਚ ਉਤਪਾਦ ਅਤੇ ਕੀਮਤਾਂ ਦੁਬਾਰਾ ਬਣਾਓ; ਟੈਸਟ ਮੋਡ ਦੇ ID ਉੱਥੇ ਨਹੀਂ ਹੁੰਦੇ।
5. ਇੱਕ ਅਸਲ ਛੋਟੀ ਖਰੀਦ ਕਰੋ ਅਤੇ ਉਸ ਦੀ ਰਕਮ ਵਾਪਸ ਕਰੋ।

ਹਰ ਕੁੰਜੀ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਸੀਕਰੇਟ ਵਿੱਚ ਰੱਖੋ, ਕਦੇ ਵੀ ਕੋਡ ਜਾਂ ਚੈਟ ਵਿੱਚ ਨਹੀਂ। ਸਾਡੀ ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ ਕੁੰਜੀਆਂ ਅਤੇ ਵੈਬਹੁੱਕ ਦੀ ਜਾਂਚ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ ਦਿੰਦੀ ਹੈ।

ਟੈਕਸ, ਰਿਫੰਡ ਅਤੇ ਕਾਗਜ਼ੀ ਕਾਰਵਾਈ

ਭੁਗਤਾਨ ਨਾਲ ਅਜਿਹੀਆਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਕੋਡ ਹੱਲ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਟੈਕਸ ਸਲਾਹ ਨਹੀਂ ਹੈ; ਕਿਸੇ ਲੇਖਾਕਾਰ ਨਾਲ ਗੱਲ ਕਰੋ।

• ਵਿਕਰੀ ਟੈਕਸ, VAT ਅਤੇ GST। ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਕਿ ਤੁਸੀਂ ਅਤੇ ਤੁਹਾਡੇ ਗਾਹਕ ਕਿੱਥੇ ਹੋ, ਤੁਹਾਨੂੰ ਰਜਿਸਟਰ ਹੋਣਾ, ਟੈਕਸ ਵਸੂਲਣਾ ਅਤੇ ਫਾਈਲ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ। Stripe Tax ਚੈੱਕਆਉਟ 'ਤੇ ਟੈਕਸ ਦੀ ਗਣਨਾ ਅਤੇ ਵਸੂਲੀ ਕਰ ਸਕਦਾ ਹੈ, ਦੇਖ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਵਿਕਰੀਆਂ ਕਿੱਥੇ ਜ਼ਿੰਮੇਵਾਰੀ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਤੇ ਫਾਈਲਿੰਗ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜ਼ਿੰਮੇਵਾਰੀ ਤੁਹਾਡੀ ਹੀ ਰਹਿੰਦੀ ਹੈ। Merchant-of-record ਪ੍ਰਦਾਤਾ ਇੱਕ ਬਦਲ ਹਨ ਜੋ ਇਸ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਆਪਣੇ ਸਿਰ ਲੈਂਦੇ ਹਨ।
• ਰਿਫੰਡ ਅਤੇ ਵਿਵਾਦ। ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਰਿਫੰਡ ਨੀਤੀ ਤੈਅ ਕਰੋ ਅਤੇ ਆਪਣੀ ਸਾਈਟ 'ਤੇ ਲਗਾਓ। ਵਿਵਾਦ (chargebacks) ਹੁੰਦੇ ਹਨ; ਜੋ ਖਰੀਦਿਆ ਅਤੇ ਦਿੱਤਾ ਗਿਆ, ਉਸ ਦੇ ਰਿਕਾਰਡ ਰੱਖੋ।
• ਰਸੀਦਾਂ ਅਤੇ ਇਨਵੌਇਸ। Stripe ਰਸੀਦਾਂ ਈਮੇਲ ਕਰ ਸਕਦਾ ਹੈ; ਕਾਰੋਬਾਰਾਂ ਨੂੰ ਸਹੀ ਇਨਵੌਇਸ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ।
• ਫੀਸਾਂ। ਹਰ ਪ੍ਰਦਾਤਾ ਹਰ ਲੈਣ-ਦੇਣ 'ਤੇ ਫੀਸ ਲੈਂਦਾ ਹੈ। ਲੇਖਾਂ ਦੇ ਅੰਕੜਿਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਪ੍ਰਦਾਤਾ ਦਾ ਮੌਜੂਦਾ ਕੀਮਤ ਪੰਨਾ ਦੇਖੋ।

ਤੁਹਾਡੀ ਐਪ ਲਈ ਕਿਹੜਾ ਸੈੱਟਅੱਪ ਢੁੱਕਵਾਂ ਹੈ

• ਦਾਨ ਜਾਂ ਕੁਝ ਉਤਪਾਦ: Payment Links। ਵੇਖੋ ਗੈਰ-ਲਾਭਕਾਰੀ ਦਾਨ ਵੈੱਬਸਾਈਟ ਕਿਵੇਂ ਬਣਾਈਏ।
• ਕਾਰਟ ਵਾਲੀ ਦੁਕਾਨ: ਲਾਈਨ ਆਈਟਮਾਂ ਅਤੇ ਵੈਬਹੁੱਕ ਨਾਲ Checkout। ਵੇਖੋ ਆਨਲਾਈਨ ਦੁਕਾਨ ਕਿਵੇਂ ਬਣਾਈਏ।
• SaaS ਜਾਂ ਮੈਂਬਰਸ਼ਿਪਾਂ: ਸਬਸਕ੍ਰਿਪਸ਼ਨ ਮੋਡ ਵਿੱਚ Checkout, ਵੈਬਹੁੱਕ ਅਤੇ ਗਾਹਕ ਪੋਰਟਲ। ਵੇਖੋ SaaS MVP ਕਿਵੇਂ ਬਣਾਈਏ ਅਤੇ SaaS ਉਤਪਾਦ ਦੀ ਕੀਮਤ ਕਿਵੇਂ ਤੈਅ ਕਰੀਏ।
• ਇੱਕ ਮਾਰਕੀਟਪਲੇਸ ਜੋ ਵੇਚਣ ਵਾਲਿਆਂ ਨੂੰ ਭੁਗਤਾਨ ਕਰੇ: ਇੱਕ ਵੱਖਰਾ, ਵਧੇਰੇ ਨਿਯੰਤ੍ਰਿਤ ਸੈੱਟਅੱਪ (Stripe Connect ਜਾਂ ਇਸ ਵਰਗਾ)। ਇਸ ਲਈ ਵੱਖਰੀ ਯੋਜਨਾ ਬਣਾਓ।

Mythex ਵਿੱਚ ਭੁਗਤਾਨ ਜੋੜਨਾ

Mythex 'ਤੇ ਬਣਾਈਆਂ ਐਪਾਂ ਵਿੱਚ ਭੁਗਤਾਨ ਤੁਹਾਡੇ ਆਪਣੇ Stripe ਖਾਤੇ ਅਤੇ ਕੁੰਜੀਆਂ ਵਰਤਦੇ ਹਨ; ਤੁਹਾਡੀ ਐਪ ਲਈ ਕੋਈ ਇੱਕ-ਕਲਿੱਕ "Connect Stripe" ਨਹੀਂ ਹੈ। ਆਮ ਪ੍ਰਵਾਹ:

1. Stripe ਦੀਆਂ ਟੈਸਟ ਕੁੰਜੀਆਂ ਲਓ।
2. STRIPE_SECRET_KEY (ਅਤੇ ਵੈਬਹੁੱਕ ਸੀਕਰੇਟ ਬਾਅਦ ਵਿੱਚ) ਪ੍ਰੋਜੈਕਟ ਸੀਕਰੇਟ ਵਿੱਚ ਜੋੜੋ, ਜਿਵੇਂ /secrets ਰਾਹੀਂ, ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ, ਜਾਂ ਜਦੋਂ ਏਜੰਟ ਕੁੰਜੀ ਮੰਗੇ ਤਾਂ ਦਿਖਣ ਵਾਲੇ ਸੀਕਰੇਟ ਕਾਰਡ ਰਾਹੀਂ।
3. ਏਜੰਟ ਨੂੰ ਉੱਪਰ ਵਰਗੇ ਪ੍ਰੋਂਪਟ ਨਾਲ Checkout ਮੰਗੋ।
4. Preview ਵਿੱਚ ਟੈਸਟ ਕਾਰਡਾਂ ਨਾਲ ਜਾਂਚੋ। ਵੈਬਹੁੱਕ ਰਜਿਸਟਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਤੁਹਾਡਾ ਜਨਤਕ URL ਚਾਹੀਦਾ ਹੈ।
5. ਲਾਈਵ ਕੁੰਜੀਆਂ 'ਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਲਾਈਵ ਐਪ ਉਹਨਾਂ ਨੂੰ ਚੁੱਕੇ, ਇਸ ਲਈ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ।

ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ Accept payments with Stripe ਅਤੇ Handle webhooks in your backend ਦੇਖੋ।

ਸਵਾਲ