ವೆಬ್‌ಹುಕ್ ಎಂದರೇನು? ಆ್ಯಪ್‌ಗಳು ಪರಸ್ಪರ ಹೇಗೆ ತಿಳಿಸುತ್ತವೆ

ವೆಬ್‌ಹುಕ್ ಎಂದರೆ ಏನಾದರೂ ನಡೆದ ತಕ್ಷಣ ಒಂದು ಸೇವೆ ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಕಳುಹಿಸುವ ಸ್ವಯಂಚಾಲಿತ ಸಂದೇಶ. ಗ್ರಾಹಕರ ಪಾವತಿ ಯಶಸ್ವಿಯಾದಾಗ, Stripe ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಒಂದು ವಿಳಾಸಕ್ಕೆ "ಪಾವತಿ ಯಶಸ್ವಿ, ವಿವರಗಳು ಇಲ್ಲಿವೆ" ಎಂದು ವೆಬ್‌ಹುಕ್ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಆ್ಯಪ್ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ — ಆರ್ಡರ್ ಅನ್ನು ಪಾವತಿಯಾದದ್ದು ಎಂದು ಗುರುತಿಸುತ್ತದೆ, ರಸೀದಿ ಕಳುಹಿಸುತ್ತದೆ, ಖಾತೆ ತೆರೆಯುತ್ತದೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ: API ಎಂದರೆ ನಿಮ್ಮ ಆ್ಯಪ್ ಇನ್ನೊಂದು ಸೇವೆಗೆ ಪ್ರಶ್ನೆ ಕೇಳುವುದು; ವೆಬ್‌ಹುಕ್ ಎಂದರೆ ಇನ್ನೊಂದು ಸೇವೆ ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಏನನ್ನಾದರೂ ತಿಳಿಸಲು ಕರೆ ಮಾಡುವುದು.

AI ಜೊತೆ ನಿರ್ಮಿಸುವಾಗ ಇದು ಏಕೆ ಮುಖ್ಯ

ನಿಮ್ಮ ಆ್ಯಪ್ ಪಾವತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ ತಕ್ಷಣ, ಇನ್ನೊಂದು ಸಾಧನದಿಂದ ಫಾರ್ಮ್ ಸಲ್ಲಿಕೆಗಳನ್ನು ಪಡೆದ ತಕ್ಷಣ, ಅಥವಾ GitHub, Shopify ಅಥವಾ ಕ್ಯಾಲೆಂಡರ್‌ನಂತಹ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಿಸಿದ ತಕ್ಷಣ, ನೀವು ವೆಬ್‌ಹುಕ್‌ಗಳನ್ನು ಎದುರಿಸುತ್ತೀರಿ. ಏನಾದರೂ ನಡೆದಿದೆ ಎಂದು ತಿಳಿಯಲು ಅವು ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾದ ಮಾರ್ಗ — ಆದರೆ AI ಆ್ಯಪ್‌ಗಳು ಸೂಕ್ಷ್ಮವಾಗಿ ತಪ್ಪಾಗುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಇಲ್ಲಿಯೇ:

• ಎಂಡ್‌ಪಾಯಿಂಟ್ ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ಒಪ್ಪುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾರಾದರೂ ನಕಲಿ "ಪಾವತಿ ಯಶಸ್ವಿ" ಘಟನೆಯನ್ನು ಕಳುಹಿಸಬಹುದು.
• ಆ್ಯಪ್ ವೆಬ್‌ಹುಕ್ ಬದಲು ಚೆಕ್‌ಔಟ್ ರೀಡೈರೆಕ್ಟ್ ಪುಟದಲ್ಲಿ ಪ್ರವೇಶ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಟ್ಯಾಬ್ ಬೇಗ ಮುಚ್ಚಿದವರಿಗೆ ತಾವು ಪಾವತಿಸಿದ್ದು ಸಿಗುವುದಿಲ್ಲ, ಮತ್ತು ಯಶಸ್ಸಿನ URL ಕಂಡುಕೊಂಡವರಿಗೆ ಉಚಿತವಾಗಿ ಸಿಗುತ್ತದೆ.
• ಅದೇ ಘಟನೆ ಎರಡು ಬಾರಿ ಬರುತ್ತದೆ, ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ಎರಡು ಆರ್ಡರ್‌ಗಳು ಅಥವಾ ಎರಡು ಇಮೇಲ್‌ಗಳು ಸಿಗುತ್ತವೆ.

ವೆಬ್‌ಹುಕ್‌ಗಳು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ತಿಳಿದರೆ, ನೀವು ಮುಂಚಿತವಾಗಿಯೇ ಆ ರಕ್ಷಣೆಗಳನ್ನು ಕೇಳಬಹುದು.

ದೈನಂದಿನ ಉದಾಹರಣೆ: ಡೆಲಿವರಿ ಸಂದೇಶ

ನಿಮ್ಮ ಪಾರ್ಸೆಲ್ ಬಂದಿದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಎರಡು ದಾರಿಗಳಿವೆ. ಪ್ರತಿ ಹತ್ತು ನಿಮಿಷಕ್ಕೆ ಮುಂಬಾಗಿಲಿಗೆ ಹೋಗಿ ನೋಡಬಹುದು (ಅದು ಪೋಲಿಂಗ್ — ನಿಮ್ಮ ಆ್ಯಪ್ ಪದೇ ಪದೇ API ಕರೆದು "ಹೊಸದೇನಾದರೂ ಇದೆಯೇ?" ಎಂದು ಕೇಳುವುದು). ಅಥವಾ ಕೊರಿಯರ್ ತಲುಪಿಸಿದಾಗ ನಿಮಗೆ ಸಂದೇಶ ಕಳುಹಿಸಬಹುದು (ಅದು ವೆಬ್‌ಹುಕ್).

ನೀವು ಅದನ್ನು ನಂಬಬಹುದಾದರೆ ಸಂದೇಶವೇ ಉತ್ತಮ. ಯಾರಾದರೂ "ಪಾರ್ಸೆಲ್ ತಲುಪಿಸಲಾಗಿದೆ" ಸಂದೇಶ ಕಳುಹಿಸಬಹುದಾದರೆ, ಅದು ನಿಜವಾಗಿ ಕೊರಿಯರ್‌ನಿಂದಲೇ ಬಂದಿದೆ ಎಂದು ತಿಳಿಯುವ ದಾರಿ ನಿಮಗೆ ಬೇಕು. ಮತ್ತು ಸಂದೇಶ ಬಂದಾಗ ನಿಮ್ಮ ಫೋನ್ ಆಫ್ ಇದ್ದರೆ, ಕೊರಿಯರ್ ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕೆಂದು ನೀವು ಬಯಸುತ್ತೀರಿ. ಆ ಎರಡು ಕಾಳಜಿಗಳು — ಪರಿಶೀಲನೆ ಮತ್ತು ಮರುಪ್ರಯತ್ನ — ವೆಬ್‌ಹುಕ್‌ಗಳನ್ನು ಕಠಿಣವಾಗಿಸುವ ಬಹುಪಾಲು ಅಂಶಗಳು.

ವೆಬ್‌ಹುಕ್ ಹಂತ-ಹಂತವಾಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

1. ನೀವು ಎಂಡ್‌ಪಾಯಿಂಟ್ ರಚಿಸುತ್ತೀರಿ ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಬ್ಯಾಕ್‌ಎಂಡ್‌ನಲ್ಲಿ: POST ವಿನಂತಿಗಳನ್ನು ಒಪ್ಪುವ https://yourapp.com/webhooks/stripe ನಂತಹ URL.
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 ಗೆ ತೋರಿಸುತ್ತೀರಿ. ಸಹಿ ರಹಸ್ಯವು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ಸೀಕ್ರೆಟ್‌ಗಳಿಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಲೈವ್ ಆ್ಯಪ್‌ನಲ್ಲಿ ಅದನ್ನು ಬದಲಿಸಿದರೆ, ಮತ್ತೆ ಪ್ರಕಟಿಸಿ. ವೆಬ್‌ಹುಕ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ದಸ್ತಾವೇಜು ಪಾಕವಿಧಾನದಲ್ಲಿ ಪ್ರಾರಂಭಿಕ ಪ್ರಾಂಪ್ಟ್ ಇದೆ, ಮತ್ತು ಪಾವತಿ ಸ್ವೀಕರಿಸುವ ಆ್ಯಪ್‌ಗಳಿಗೆ ಸ್ಟೋರ್ ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಉತ್ತಮ ಆರಂಭ ಬಿಂದು.

ಪ್ರಶ್ನೆಗಳು