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