वे चार क्षमताएं जो मायने रखती हैं
Section titled “वे चार क्षमताएं जो मायने रखती हैं”| क्षमता | इसका मतलब | बिना इसके उत्पाद क्यों रुक जाते हैं |
|---|---|---|
| लाइव दरें और उपलब्धता | वर्तमान कीमतें और वास्तव में क्या बुक किया जा सकता है, प्रति तिथि सीमा | कैश की गई दरें पुष्टि पर विफल होती हैं और विश्वास कम करती हैं |
| बुकिंग निर्माण | एक वास्तविक आरक्षण बनाएं जिसे होटल प्राप्त करता है | इसके बिना आप एक रेफरल लिंक हैं, उत्पाद नहीं |
| भुगतान | बुकिंग के हिस्से के रूप में पैसा लें | किसी अन्य साइट पर भेजना कन्वर्ज़न को खत्म कर देता है |
| पुष्टि और वेबहुक्स | अतिथि, होटल और आपकी प्रणाली को बताएं कि क्या हुआ | अन्यथा समर्थन लोड और मेल-मिलाप में अंतर होता है |
अधिकांश “होटल APIs” जो डेवलपर पाते हैं वे पहली और कभी-कभी दूसरी को कवर करते हैं। लेनदेन कठिन हिस्सा है, और यह तय करता है कि आपके पास उत्पाद है या नहीं।
आप किसकी आपूर्ति एकीकृत कर रहे हैं?
Section titled “आप किसकी आपूर्ति एकीकृत कर रहे हैं?”यह सवाल आगे की सभी चीज़ों को आकार देता है। एक श्रृंखला के माध्यम से पुनर्विक्रय की गई आपूर्ति दर में मार्कअप के साथ आती है, पुरानी उपलब्धता होती है, और बुकिंग प्रश्न के लिए होटल तक कोई रास्ता नहीं होता। जो आपूर्ति सीधे होटल से आती है, वह होटल की अपनी दर, लाइव उपलब्धता, और एक होटल जो बुकिंग के अस्तित्व को जानता है, वह लेकर आती है।
जहां भी यात्री होटल की अपनी वेबसाइट से तुलना करेगा — जो अधिकांश चीजें हैं — होटल-नियंत्रित आपूर्ति उस असहज क्षण से बचाती है जब आपकी कीमत खराब होती है।
मर्चेंट ऑफ रिकॉर्ड कौन है
Section titled “मर्चेंट ऑफ रिकॉर्ड कौन है”यदि आप खुद होटल बुकिंग बनाते हैं, तो मर्चेंट ऑफ रिकॉर्ड बनने का मतलब है भुगतान जिम्मेदारी, चार्जबैक, रिफंड, कर प्रबंधन और अक्सर प्रत्येक बाजार में ट्रैवल-एजेंसी लाइसेंस लेना।
Wink पर होटल मर्चेंट ऑफ रिकॉर्ड रहता है और भुगतान होटल के लिए एकत्र किया जाता है, इसलिए एक इंटीग्रेटर को वह जिम्मेदारी नहीं मिलती। मर्चेंट-ऑफ-रिकॉर्ड व्यवस्थाएं API इंटीग्रेशन पर उपलब्ध हैं जहां पार्टनर को वास्तव में खुद भुगतान लेना होता है, और उस मार्ग के अपने लाइसेंसिंग आवश्यकताएं होती हैं।
एकीकरण के तीन स्तर
Section titled “एकीकरण के तीन स्तर”- वेब कॉम्पोनेंट्स। एक मौजूदा पेज में बुक करने योग्य खोज, रूम सूची या चेकआउट डालें। कोई बैकएंड काम नहीं; लेआउट पर सबसे कम नियंत्रण।
- REST API। खोज, दरें, बुकिंग निर्माण और पुष्टि पर पूर्ण नियंत्रण, OAuth2 के साथ प्रमाणित। इसका उपयोग तब करें जब बुकिंग फ्लो आपके उत्पाद के अपने अनुभव का हिस्सा हो।
- MCP सर्वर। AI एजेंट्स के लिए समान क्षमताएं प्रदान करता है, ताकि एक सहायक खोज, मूल्य निर्धारण और बुकिंग पूरा कर सके बजाय उपयोगकर्ता को वेबसाइट पर भेजने के।
तीनों आपस में अलग नहीं हैं — एक उत्पाद आमतौर पर मार्केटिंग सतह के लिए कॉम्पोनेंट्स और अपने मुख्य फ्लो के लिए API का उपयोग करता है।
पहले क्या बनाएं
Section titled “पहले क्या बनाएं”- एक शहर और एक तिथि सीमा के लिए खोज और मूल्य। कुछ भी डिजाइन करने से पहले वास्तविक दरें प्राप्त करें।
- एक परीक्षण बुकिंग अंत से अंत तक बनाएं, जिसमें भुगतान और पुष्टि शामिल हो।
booking.createdऔर रद्दीकरण इवेंट्स की सदस्यता लें इससे पहले कि आप कोई UI बनाएं।- अपना एट्रिब्यूशन मॉडल जल्दी तय करें — स्रोत संदर्भ को बुकिंग के साथ जाना चाहिए, नहीं तो बाद में आपकी रिपोर्टिंग अनुमान होगी।
- असफलता के मामलों को संभालें: कोट और बुकिंग के बीच उपलब्धता खो जाना, भुगतान अस्वीकृत होना, आंशिक रिफंड।
डेवलपर को जानने योग्य मूल्य निर्धारण
Section titled “डेवलपर को जानने योग्य मूल्य निर्धारण”Consumer और Booking Engine APIs मुफ्त हैं। Partner API में प्रति माह 10,000 होटल-रातें मुफ्त शामिल हैं, फिर प्रति यूनिट बिलिंग होती है। पुष्टि की गई बुकिंग पर होटल का 1.5% प्लेटफ़ॉर्म शुल्क और कार्ड प्रोसेसिंग लागत लगती है, और 10% डिफ़ॉल्ट कमीशन लागू होता है जब आपका उत्पाद बुकिंग को प्रेरित करता है — जो एक इंटीग्रेटर के लिए कमाई का तरीका है, भुगतान का नहीं।
सामान्य गलतियां
Section titled “सामान्य गलतियां”- कैश की गई दरों पर निर्माण। वे विकास में ठीक लगती हैं और उत्पादन में विफल होती हैं।
- भुगतान को रीडायरेक्ट पर छोड़ देना। हर हैंडऑफ बुकिंग खो देता है।
- लॉन्च तक वेबहुक्स को नजरअंदाज करना। मेल-मिलाप एक मैनुअल काम बन जाता है।
- जरूरत न होने पर मर्चेंट ऑफ रिकॉर्ड बन जाना। यह एक लाइसेंसिंग और जिम्मेदारी का निर्णय है, केवल तकनीकी नहीं।
- स्रोत संदर्भ पास न करना। एट्रिब्यूशन बाद में पुनर्निर्मित नहीं किया जा सकता।