कस्टम लाइसेंसिंग सिस्टम एकीकरण मार्गदर्शिका

वर्तमान स्रोत कोड दो लाइसेंस प्रदाताओं का समर्थन करता है: Licentivo और custom_http। व्यापारी सिस्टम सेटिंग → लाइसेंसिंग सिस्टम में एक प्रदाता चुनकर सक्षम करता है; सभी उत्पाद और sandbox/live वातावरण उसी प्रदाता का उपयोग करते हैं। कस्टम कनेक्शन और प्लान मैपिंग प्रत्येक उत्पाद और वातावरण के लिए अलग से कॉन्फ़िगर की जाती हैं। इस सुविधा में स्व-निर्मित लाइसेंसिंग सिस्टम शामिल नहीं है; व्यापारी अपनी लाइसेंसिंग सेवा और SDK का उपयोग जारी रखता है।

मौजूदा Licentivo खाता विनिमय, नौ-भाषा SDK और डिवाइस प्रबंधन अपनी वर्तमान प्रक्रिया का उपयोग जारी रखते हैं। कस्टम उत्पाद इस दस्तावेज़ के प्रोटोकॉल से खरीद की स्थिति सिंक्रनाइज़ करते हैं; ग्राहक खाता केंद्र में लाइसेंस डिलीवरी देखता है और Licentivo SDK प्रक्रिया में प्रवेश नहीं करता।

त्वरित शुरुआत

1. अपनी सेवा में नीचे दिए गए चार HTTP इंटरफ़ेस लागू करें और प्रत्येक कनेक्शन के लिए अलग HMAC हस्ताक्षर कुंजी तथा पहचानकर्ता कॉन्फ़िगर करें।
2. “लाइसेंसिंग सिस्टम” में “कस्टम लाइसेंसिंग सेवा” चुनें, नया कनेक्शन जोड़ें, पता, वातावरण, कनेक्शन पहचानकर्ता, key ID और मानक Base64 कुंजी भरें। सत्यापन के बाद सहेजें और “कस्टम लाइसेंसिंग सेवा सक्षम करें” पर क्लिक करें।
3. उत्पाद और बिक्री प्लान के ड्राफ़्ट बनाएँ। खरीद प्रकार और मूल्य Launch में प्रबंधित होते हैं; लाइसेंस नियम आपके अपने सिस्टम में प्रबंधित होते हैं।
4. उत्पाद और वातावरण चुनें, कनेक्शन चुनें, बाहरी उत्पाद और प्लान संदर्भ भरें और सहेजें। प्रदाता पूरे साइट के चयन से तय होता है; अन्य उत्पादों के लिए साथ में Licentivo सक्षम नहीं किया जा सकता।
5. बिक्री प्लान पृष्ठ पर परीक्षण संस्करण प्रकाशित करें, भुगतान, डिलीवरी, नवीनीकरण, अपग्रेड, रिफ़ंड और विफलता से पुनर्प्राप्ति का स्वीकृति परीक्षण पूरा करें, फिर उत्पादन वातावरण अलग से कॉन्फ़िगर करें।

बनाने के बाद पता, वातावरण, कनेक्शन पहचानकर्ता और नेटवर्क पहुँच नीति बदली नहीं जा सकती; आवश्यकता होने पर नया कनेक्शन बनाएँ। हस्ताक्षर कुंजी बदली जा सकती है; खाली छोड़ने पर पुरानी कुंजी बनी रहती है। दूसरे लाइसेंसिंग सिस्टम के ऑर्डर मौजूद होने पर पूरे साइट का प्रदाता सीधे नहीं बदला जा सकता; पहले माइग्रेशन पूरा करें। बदलाव के बाद पुराने प्लान केवल पूर्वावलोकन के लिए रह जाते हैं और उन्हें फिर प्रकाशित करना होता है; सहेजे गए कनेक्शन क्रेडेंशियल और मैपिंग बनी रहती हैं। जिन उत्पादों के ऑर्डर मौजूद हैं उनका कनेक्शन सीधे नहीं बदला जा सकता और बिक्री में उपयोग हो रही मैपिंग भी सीधे नहीं बदली जा सकती; नई कीमत या मैपिंग के लिए प्लान का नया संस्करण उपयोग करें।

API से कॉन्फ़िगर करते समय पहले PUT /api/v1/admin/licensing/provider कॉल करें, जिसका अनुरोध निकाय {"provider":"custom_http"} या {"provider":"licentivo"} हो, फिर उत्पाद मैपिंग सहेजें। जो प्रदाता सक्षम नहीं है उसके लिए उत्पाद लाइसेंस बाइंडिंग या Licentivo प्लान नीति मैपिंग सहेजी नहीं जा सकती।

कनेक्शन जाँच प्रोटोकॉल, प्रमाणीकरण, वातावरण और समर्थित खरीद प्रकारों की पुष्टि करती है; यह व्यापारी के लिए बाहरी प्लान बनाती या उसकी पुष्टि नहीं करती। वास्तविक भुगतान लेने से पहले वास्तविक बाहरी प्लान के साथ sandbox एकीकरण का स्वीकृति परीक्षण पूरा करना आवश्यक है।

3. व्यापारी एकीकरण प्रक्रिया

1. मौजूदा लाइसेंसिंग सिस्टम के सामने इस दस्तावेज़ के चार इंटरफ़ेस लागू करें; सिस्टम का मौजूदा लाइसेंस तर्क बनाए रखें।
2. Launch में नया “कस्टम लाइसेंसिंग सेवा” कनेक्शन बनाएँ और HTTPS पता, कनेक्शन पहचानकर्ता, वातावरण तथा हस्ताक्षर कुंजी कॉन्फ़िगर करें।
3. Launch क्षमता जाँच इंटरफ़ेस कॉल करके प्रोटोकॉल संस्करण, स्थायी/सीमित अवधि की खरीद के समर्थन और डिलीवरी विधि की पुष्टि करता है।
4. उत्पाद के लिए यह कनेक्शन चुनें; बिक्री प्लान संस्करण को बाहरी product_ref और plan_ref से मैप करें। बाहरी पहचानकर्ता व्यापारी की अपनी स्ट्रिंग हो सकते हैं; Licentivo UUID अनिवार्य नहीं है।
5. sandbox में भुगतान, नवीनीकरण, अपग्रेड, रिफ़ंड और विफलता से पुनर्प्राप्ति का स्वीकृति परीक्षण पूरा करें, फिर live कॉन्फ़िगरेशन अलग से प्रकाशित करें।
6. भुगतान सत्यापित करने के बाद Launch उसी डेटाबेस लेनदेन में ऑर्डर, खरीद कवरेज और भेजे जाने वाले कार्य सहेजता है।
7. बैकग्राउंड प्रक्रिया पूरा खरीद स्नैपशॉट कस्टम लाइसेंसिंग सेवा को भेजती है; वह सेवा प्राप्ति रिकॉर्ड स्थायी रूप से सहेजने के बाद प्राप्ति की पुष्टि करती है।
8. लाइसेंसिंग सेवा लक्ष्य स्थिति संसाधित करती है। Launch मूल इवेंट की रसीद पूछता है और केवल applied मिलने पर इस सिंक्रनाइज़ेशन को पूर्ण मानता है।
9. Launch लॉग इन कर चुके और इस खरीद के स्वामी ग्राहक के लिए डिलीवरी जानकारी पढ़ता है और ग्राहक केंद्र में लाइसेंस कोड, सक्रियण लिंक या सादा पाठ निर्देश दिखाता है। ऐप व्यापारी के अपने लाइसेंसिंग सिस्टम से जुड़ता है।
10. नवीनीकरण, अपग्रेड, रिफ़ंड, भुगतान वापसी, निलंबन और समाप्ति सभी पूरे स्नैपशॉट का नया संस्करण बनाते हैं। लाइसेंसिंग सेवा नवीनतम लक्ष्य स्थिति के अनुसार संसाधित करती है।

एक ही उत्पाद के sandbox/live अलग-अलग कनेक्शन से जुड़े होते हैं। खरीद मौजूद होने के बाद प्रदाता बदलने के लिए अलग माइग्रेशन प्रक्रिया चाहिए; पुराने ऑर्डर और कार्य बैकग्राउंड चयन के कारण चुपचाप नई सेवा को नहीं भेजे जा सकते।

4. कस्टम लाइसेंसिंग सेवा द्वारा लागू किए जाने वाले API

नीचे के सभी इंटरफ़ेस व्यापारी की लाइसेंसिंग सेवा प्राप्त करती है और Launch सर्वर कॉल करता है। base_url में स्थिर पथ उपसर्ग हो सकता है; तालिका के पथ उस उपसर्ग के बाद जोड़े जाते हैं।

पहले संस्करण में रसीद सक्रिय रूप से पूछी जाती है; ऑर्डर बदलने के लिए बाहरी कॉलबैक का नया प्रवेश बिंदु नहीं जोड़ा जाता। कस्टम सेवा को भुगतान की पुष्टि करने, कीमत बदलने या खरीद अवधि बदलने का अधिकार नहीं है।

4.1 सामान्य नियम और प्रमाणीकरण

• JSON में UTF-8 और समय के लिए UTC RFC 3339 का उपयोग करें; version एक धनात्मक पूर्णांक है।
• सफल प्रतिक्रिया {"data": {...}, "request_id": "..."} है; त्रुटि प्रतिक्रिया {"error": {"code": "...", "message": "..."}, "request_id": "..."} है।
• प्रत्येक वातावरण और कनेक्शन के लिए अलग कुंजी उपयोग करें। कुंजी कम से कम 32 यादृच्छिक बाइट की हो और Launch में मौजूदा एन्क्रिप्टेड कुंजी स्टोरेज को संदर्भित करे; इसे फ़्रंटएंड कॉन्फ़िगरेशन, उदाहरण या ऐप इंस्टॉलेशन पैकेज में न रखें।
• हर अनुरोध में X-Launch-Key-Id, X-Launch-Timestamp, X-Launch-Nonce, X-Launch-Signature शामिल होते हैं।
• टाइमस्टैम्प दशमलव Unix सेकंड में है। nonce कम से कम 128 बिट के यादृच्छिक मान का बिना पैडिंग वाला base64url एन्कोडिंग है; हर नेटवर्क प्रयास के लिए नया मान बनाएँ।

हस्ताक्षर इनपुट नीचे दी गई सात वस्तुओं को एक-एक न्यूलाइन से जोड़कर बने UTF-8 बाइट हैं; अंत में न्यूलाइन न जोड़ें:

v1
<key_id>
<timestamp>
<nonce>
<UPPERCASE HTTP method>
<encoded request path and raw query, including the base_url path prefix>
<lowercase hexadecimal SHA-256 digest of the exact request body>

X-Launch-Signature, v1= के बाद HMAC-SHA256 परिणाम का बिना पैडिंग वाला base64url एन्कोडिंग है। GET अनुरोध का निकाय खाली होता है। प्राप्तकर्ता पहले हस्ताक्षर और समय सीमा जाँचे, फिर डीसिरियलाइज़ करे; स्थिर समय तुलना उपयोग करे, डिफ़ॉल्ट रूप से दोनों दिशाओं में 300 सेकंड का अंतर स्वीकार करे और रीप्ले रोकने के लिए nonce कम से कम 600 सेकंड रखे। पुनः प्रयासों में nonce दोबारा उपयोग न करें, लेकिन इवेंट ID और व्यावसायिक अनुरोध निकाय अपरिवर्तित रहें।

हस्ताक्षर HTTPS का विकल्प नहीं है। अनुरोध में ग्राहक पासवर्ड, भुगतान कुंजी या Licentivo प्रशासन कुंजी नहीं होती; डिफ़ॉल्ट रूप से केवल अनाम खाता संदर्भ भेजा जाता है, ईमेल नहीं। सर्वर के HTTP क्लाइंट में टाइमआउट, प्रतिक्रिया आकार सीमा और क्रेडेंशियल के साथ रीडायरेक्ट का अनुसरण रोकने की व्यवस्था आवश्यक है। कस्टम पता कॉन्फ़िगर करते समय लक्ष्य पते की जाँच करें; आंतरिक नेटवर्क तक पहुँच प्रशासक द्वारा स्पष्ट रूप से कॉन्फ़िगर की गई डिप्लॉयमेंट क्षमता होनी चाहिए।

4.2 क्षमता जाँच

GET /launch/v1/capabilities HTTP 200 लौटाता है, उदाहरण के लिए:

{
  "data": {
    "protocol": "launch-external-licensing-v1",
    "connection_ref": "merchant-01-sandbox",
    "environment": "sandbox",
    "purchase_types": ["perpetual", "fixed_term"],
    "delivery_types": ["license_key", "activation_url", "instructions"],
    "devices": false,
    "identity_exchange": false
  },
  "request_id": "check-001"
}

protocol, connection_ref, environment, purchase_types, delivery_types अनिवार्य हैं। अंतिम दो गैर-रिक्त सरणियाँ होनी चाहिए; असमर्थित खरीद प्रकार बिक्री के लिए प्रकाशित नहीं किए जा सकते। पहले संस्करण में devices और identity_exchange का मान false होना चाहिए; विस्तारित अनुबंध और कार्यान्वयन पूरा होने के बाद ही समर्थन घोषित किया जा सकता है।

4.3 खरीद स्नैपशॉट

POST /launch/v1/events के अनुरोध का उदाहरण:

{
  "schema": "launch-external-licensing-v1",
  "event_id": "7bf84b91-2749-4b01-a6a7-bd527c488ee8",
  "connection_ref": "merchant-01-sandbox",
  "environment": "sandbox",
  "type": "entitlement.snapshot",
  "change_reason": "purchase",
  "account_ref": "customer_opaque_001",
  "entitlement_ref": "purchase_opaque_001",
  "launch_product_id": "c6dd463e-50f7-4b76-8239-0a8ec6fc304b",
  "launch_plan_version_id": "5459a073-9362-4b46-949d-9b0c5d84421a",
  "product_ref": "desktop-editor",
  "plan_ref": "professional-yearly-v1",
  "version": 1,
  "desired_state": "active",
  "valid_from": "2026-10-25T00:00:00Z",
  "valid_until": "2027-10-25T00:00:00Z"
}

ऊपर दिए गए उदाहरण के सभी फ़ील्ड अनिवार्य हैं। valid_until का null स्थायी खरीद दर्शाता है; अन्य मान valid_from के बाद होने चाहिए।

account_ref और entitlement_ref में 1–128 अक्षर, अंक, अंडरस्कोर या हाइफ़न होते हैं। schema और type उदाहरण के मानों पर स्थिर हैं। प्राप्तकर्ता desired_state और पूरी निरपेक्ष अवधि के अनुसार परिणाम लागू करता है; कारण के आधार पर खुद दिन नहीं जोड़ता या पूरा लाइसेंस रद्द नहीं करता।

विशेष रूप से रिफ़ंड के मामले में: नवीनीकरण या अपग्रेड ऑर्डर का रिफ़ंड देने के बाद भी वैध मूल खरीद रह सकती है। तब स्नैपशॉट active रह सकता है, लेकिन अवधि कम हो सकती है या प्लान बदल सकता है। केवल लेजर की पुनर्गणना के बाद कोई वैध खरीद कवरेज न रहने पर संबंधित समाप्ति स्थिति भेजी जाती है।

4.4 प्राप्ति, रसीद और पुनर्प्राप्ति

प्राप्तकर्ता को इवेंट ID, मूल अनुरोध निकाय का डाइजेस्ट और निष्पादन हेतु कार्य स्थायी रूप से सहेजने के बाद ही HTTP 202 लौटाना चाहिए; पहले ही सिंक्रनाइज़ हो चुके डुप्लिकेट अनुरोध पर HTTP 200 लौटाया जा सकता है। दोनों नीचे दी गई रसीद संरचना लौटाते हैं।

{
  "data": {
    "event_id": "7bf84b91-2749-4b01-a6a7-bd527c488ee8",
    "connection_ref": "merchant-01-sandbox",
    "environment": "sandbox",
    "entitlement_ref": "purchase_opaque_001",
    "version": 1,
    "payload_sha256": "<64-character lowercase hexadecimal SHA-256 digest of the exact event body>",
    "status": "pending",
    "error_code": null
  },
  "request_id": "receipt-001"
}

डाइजेस्ट प्लेसहोल्डर को वास्तविक डाइजेस्ट से बदलना आवश्यक है। रसीद में ऊपर दिए सभी फ़ील्ड अनिवार्य हैं; कोई त्रुटि न होने पर error_code का मान null है। GET /launch/v1/events/{event_id} पूछने पर वही संरचना HTTP 200 के साथ लौटती है; स्थिति इनमें से हो सकती है:

डिलीवरी स्थिति सिंक्रनाइज़ेशन रसीद से स्वतंत्र है; applied को ग्राहक ऐप की रनटाइम अनुमति सीधे नहीं मान सकते।

विश्वसनीयता आवश्यकताएँ:

• कम से कम एक बार डिलीवरी; प्राप्तकर्ता को व्यावसायिक इडेम्पोटेंसी सुनिश्चित करनी होगी; नेटवर्क स्तर पर “केवल एक बार कॉल” का वादा नहीं किया जा सकता।
• एक ही इवेंट ID और मूल अनुरोध निकाय पर मौजूदा परिणाम लौटाएँ; एक ही ID और अलग निकाय पर HTTP 409 IDEMPOTENCY_CONFLICT लौटाएँ।
• पुराना संस्करण नए को ओवरराइट नहीं कर सकता। एक ही खरीद संस्करण के अलग इवेंट या लक्ष्य चुपचाप स्वीकार नहीं होने चाहिए; जाँच के लिए HTTP 409 STATE_VERSION_CONFLICT लौटाएँ।
• POST प्रतिक्रिया खोने या प्रक्रिया पुनरारंभ होने के बाद Launch पहले मूल इवेंट का GET करता है; स्पष्ट EVENT_NOT_FOUND मिलने पर ही मूल ID और निकाय दोबारा भेजता है।
• दूरस्थ जारीकरण का वास्तविक परिणाम अस्पष्ट होने पर एकीकरणकर्ता को अपने स्थायी इडेम्पोटेंसी संदर्भ से भी जाँच करनी चाहिए; दोबारा भेजने पर दूसरा लाइसेंस नहीं बनाना चाहिए।
• HTTP 429 पर Retry-After का पालन करें; टाइमआउट और 5xx पर बैकऑफ़ से बहाल करें; सीमा पार होने पर मैनुअल जाँच। प्रमाणीकरण, कॉन्फ़िगरेशन और व्यावसायिक अस्वीकृति को सफल सिंक्रनाइज़ेशन न मानें।

सुझाए त्रुटि कोड: SIGNATURE_INVALID（401）、SIGNATURE_EXPIRED（401）、NONCE_REPLAYED（409）、SCOPE_MISMATCH（403）、EVENT_NOT_FOUND（404）、IDEMPOTENCY_CONFLICT（409）、STATE_VERSION_CONFLICT（409）、PLAN_UNKNOWN（422）、PURCHASE_TYPE_UNSUPPORTED（422）、RATE_LIMITED（429）、SERVICE_UNAVAILABLE（503）。 त्रुटि संदेश में क्रेडेंशियल नहीं होने चाहिए।

4.5 लाइसेंस डिलीवरी

GET /launch/v1/entitlements/{entitlement_ref}/delivery केवल उस कनेक्शन और वातावरण का मौजूदा डिलीवरी परिणाम पढ़ सकता है; क्वेरी को नया जारीकरण कमांड नहीं मानना चाहिए। HTTP 200 उदाहरण:

{
  "data": {
    "connection_ref": "merchant-01-sandbox",
    "environment": "sandbox",
    "entitlement_ref": "purchase_opaque_001",
    "version": 1,
    "status": "ready",
    "delivery": {
      "type": "license_key",
      "value": "EXAMPLE-ONLY-NOT-A-REAL-LICENSE",
      "expires_at": null
    }
  },
  "request_id": "delivery-001"
}

status का मान pending, ready या unavailable है; ready न होने पर delivery का मान null है। ready होने पर type घोषित license_key, activation_url या instructions होना चाहिए, value अधिकतम 4096 UTF-8 बाइट है और expires_at UTC समय या null है। सभी प्रतिक्रिया संबद्ध फ़ील्ड Launch के वर्तमान खरीद संस्करण से मेल खाने चाहिए; पुराने संस्करण की डिलीवरी वर्तमान परिणाम नहीं है।

लाइसेंस कोड संवेदनशील डेटा है; डिलीवरी प्रतिक्रिया Cache-Control: no-store उपयोग करती है, निकाय लॉग नहीं होता और स्थायी रखने पर एन्क्रिप्टेड स्टोरेज उपयोग करें। सक्रियण URL केवल कनेक्शन कॉन्फ़िगरेशन द्वारा अनुमत HTTPS ओरिजिन से स्वीकार करें; instructions सादे पाठ में दिखाएँ, HTML या स्क्रिप्ट न चलाएँ। निरस्त, पूर्ण रिफ़ंड या वैध खरीद रहित खाते Launch से डिलीवरी जानकारी नहीं ले सकते; पहले दी क्रेडेंशियल का वास्तविक अमान्यकरण बाहरी सिस्टम करता है।

Launch प्रशासन और ग्राहक API

ये इंटरफ़ेस व्यापारी द्वारा डिप्लॉय Launch origin के अंतर्गत हैं और बाहरी सेवा की HMAC कुंजी से प्रमाणित नहीं होते। व्यवस्थापक मौजूदा वेबसाइट सत्र उपयोग करता है, लेखन अनुरोध में X-CSRF-Token अनिवार्य है। ग्राहक केवल अपनी खरीद पढ़ सकता है।

नया कस्टम कनेक्शन जोड़ने का अनुरोध निकाय:

{
  "provider": "custom_http",
  "name": "My licensing service",
  "base_url": "https://licenses.example.com",
  "environment": "sandbox",
  "connection_ref": "merchant-01-sandbox",
  "key_id": "key-1",
  "signing_key": "<standard Base64 encoding of 32 to 128 random bytes>",
  "allow_private_network": false,
  "allow_local_http": false,
  "activation_origins": ["https://activate.example.com"]
}

प्रतिक्रिया का data संवेदनशील जानकारी हटाया कनेक्शन ऑब्जेक्ट है; हस्ताक्षर कुंजी या secret ID नहीं लौटता। allow_local_http केवल sandbox के localhost/लूपबैक पते के लिए है; निजी नेटवर्क HTTPS को स्पष्ट व्यवस्थापक अनुमति चाहिए। खाली कुंजी केवल मौजूदा कनेक्शन संपादन में अनुमत है। Licentivo अब भी POST /api/v1/admin/connections/licentivo से सेट होता है।

उत्पाद कॉन्फ़िगर करने का अनुरोध निकाय:

{
  "provider": "custom_http",
  "environment": "sandbox",
  "connection_id": "<id returned when creating the connection>",
  "mappings": [
    {
      "version_id": "<Launch plan version UUID>",
      "product_ref": "desktop-editor",
      "plan_ref": "professional-yearly-v1"
    }
  ]
}

Licentivo चुनते समय {"provider":"licentivo","environment":"sandbox","mappings":[]} भेजें, उसकी उत्पाद/नीति मैपिंग अब भी मूल इंटरफ़ेस उपयोग करती है। पहला बदलाव मौजूदा प्रकाशन को पूर्वावलोकन बनाता है; नए प्रदाता के अनुसार फिर जाँच और प्रकाशन आवश्यक है। mappings में केवल जोड़ने या रखने वाले संस्करण हो सकते हैं; छोड़ने से पुरानी मैपिंग नहीं हटती।

ग्राहक डिलीवरी HTTP 200 का मानक data envelope है; खरीद न होने पर 404, Licentivo उत्पाद पर 409 LICENSING_DELIVERY_UNSUPPORTED, सिंक न होने, निलंबन, समाप्ति या पूर्ण रिफ़ंड पर 409 ENTITLEMENT_NOT_READY, बाहरी सेवा अस्थायी अनुपलब्ध या रसीद बेमेल पर 503 लौटता है। ग्राहक केंद्र का “लाइसेंस डिलीवरी देखें” स्वामित्व और स्थिति फिर जाँचता है, क्रेडेंशियल URL या लॉग में नहीं लिखता।

कस्टम उत्पाद के Licentivo identity, device, integration-check इंटरफ़ेस 409 CUSTOM_LICENSING_SDK_REQUIRED लौटाते हैं। पुराना /credential अब भी 410 लौटाता है। ऐप व्यापारी का अपना SDK उपयोग करे, Launch की ready स्थिति को रनटाइम प्राधिकरण न माने।

उदाहरण और स्वीकृति

Python पतला एडाप्टर उदाहरण हस्ताक्षर, nonce, इवेंट डुप्लिकेट नियंत्रण और रसीद स्थायित्व का प्राप्तकर्ता ढाँचा देता है; वास्तविक लाइसेंसिंग के लिए व्यापारी सिस्टम से जुड़ना आवश्यक है।

कस्टम प्रोटोकॉल का OpenAPI और Launch का OpenAPI दोनों दिशाएँ अलग बताते हैं। प्राप्तकर्ता को Licentivo उत्पाद कैटलॉग, नीति कैटलॉग या पहचान विश्वास इंटरफ़ेस लागू करने की आवश्यकता नहीं है।

स्थानीय सत्यापन अलग MySQL, वास्तविक HTTP एडाप्टर और सिमुलेटेड लाइसेंसिंग/भुगतान सेवाएँ उपयोग करता है, प्रतिक्रिया खोना, पुनरारंभ, नवीनीकरण, अपग्रेड, रिफ़ंड, खाता अक्षम होना, रसीद बेमेल और डिलीवरी अलगाव कवर करता है। उत्पादन स्वीकृति में व्यापारी की अपनी लाइसेंसिंग सेवा और ऐप भी आवश्यक हैं। अघोषित डिवाइस, साझा खाता लॉगिन और ऑफ़लाइन क्षमताएँ Launch पूरी नहीं करता।