एसडीके (सॉफ्टवेयर डेवलपमेंट किट) लीक किए बिना प्रदाता अमूर्त: गेटवे की सीमा (Provider Abstraction Without Leaking Sdks)

पिछले अनुभाग में, हमने भुगतान साक्ष्य और भुगतान स्थिति के बीच अंतर देखा: पीएसपी से साक्ष्य सिस्टम के अपने निर्णय से कुछ अलग है। इस खंड का प्रश्न एक अधिक मौलिक सीमा के बारे में है: क्या चेकआउट ऑर्केस्ट्रेटर को पीएसपी का एसडीके देखना चाहिए?

संक्षिप्त जवाब नहीं है। ऑर्केस्ट्रेटर को बस यही पता होना चाहिए: एक भुगतान का अनुरोध किया गया, एक परिणाम लौटाया गया। किस पीएसपी ने किस एसडीके संस्करण और किस HTTP क्लाइंट के साथ यह परिणाम तैयार किया; यह ऑर्केस्ट्रेटर का काम नहीं है, बल्कि प्रदाता गेटवे की ज़िम्मेदारी है।```text Checkout Orchestrator │ ChargeRequest (semantik) ▼ Provider Gateway │ PSP SDK / HTTP client ▼ PSP A veya PSP B

## पहले उल्लेख पर अवधारणाएँ```text
📦 Provider Gateway
PSP SDK'sını, kimlik doğrulamasını ve provider'a özgü akışları sahiplenen tek servis.

📦 Semantik Arayüz
Orchestrator'ın gördüğü, hiçbir provider tipine referans vermeyen sözleşme.

📦 Anti-Corruption Layer
Dış sistemin veri modelinin, kendi domain dilinizi kirletmesini engelleyen çeviri katmanı.

📦 Adapter
Provider'a özgü isteği semantik isteğe, provider'a özgü yanıtı semantik sonuca çeviren kod.
```'एसडीके लीक' यहां कोई तकनीकी बात नहीं है: जिस क्षण PSP का `ChargeObject` प्रकार ऑर्केस्ट्रेटर कोड में दिखाई देता है, उस PSP को बदलने का मतलब अब एक फ़ाइल को बदलना नहीं है, बल्कि ऑर्केस्ट्रेटर के भीतर गहराई से छूना है।

## क्यों एसडीके लीक एक गुप्त ऋण है

प्रदाता गेटवे सेट करते समय, सबसे छोटा तरीका PSP के SDK ऑब्जेक्ट को ऑर्केस्ट्रेटर में ले जाना है: `ChargeResponse` प्रकार आयात करें और इसे सीधे उपयोग करें, फ़ील्ड पढ़ें, स्थिति जांचें। पहले सप्ताह में इसमें तेजी है. लेकिन जैसे ही यह प्रकार ऑर्केस्ट्रेटर के हस्ताक्षर में प्रवेश करता है, दो सेवाओं के बीच एक छिपा हुआ संस्करण बांड बनाया जाता है: एसडीके अद्यतन किया जाता है, डोमेन नाम बदलता है, ऑर्केस्ट्रेटर को एक संकलन त्रुटि, या इससे भी बदतर, एक मूक तर्क त्रुटि का सामना करना पड़ता है।```text
❌ Orchestrator kodu
if (pspResponse.charges.data[0].outcome.network_status === 'approved') { ... }

✓ Orchestrator kodu
if (chargeResult.status === ChargeStatus.Captured) { ... }
```दूसरी पंक्ति में किसी प्रदाता का नाम नहीं है. प्रदाता गेटवे जानता है कि किस पीएसपी के किस क्षेत्र को देखना है; ऑर्केस्ट्रेटर केवल अर्थपूर्ण परिणाम जानता है।

## क्यों कार्ड और वॉलेट प्रवाह समान इंटरफ़ेस साझा करते हैं लेकिन समान प्रवाह नहीं

कार्ड से भुगतान अधिकतर समकालिक होता है: अनुरोध चला जाता है, अधिकृत/अस्वीकार परिणाम कुछ सौ मिलीसेकंड के भीतर वापस आ जाता है। वॉलेट या बैंक-निर्देशित भुगतान (प्रवाह जहां उपयोगकर्ता को पीएसपी पेज पर रीडायरेक्ट किया जाता है) अतुल्यकालिक हैं: पहला अनुरोध केवल 'लंबित' स्थिति और रीडायरेक्ट यूआरएल लौटाता है; वास्तविक परिणाम कुछ मिनट बाद वेबहुक के माध्यम से आता है।```text
Kart akışı
  ChargeRequest → [senkron çağrı] → ChargeResult (Captured/Declined)

Wallet akışı
  ChargeRequest → ChargeResult (Pending + redirectUrl)
         ...
  Webhook → ChargeResult (Captured/Failed) [asenkron, sonradan]
```सिमेंटिक इंटरफ़ेस दोनों को समान आकार `ChargeResult` के साथ दर्शाता है; अंतर रखने वाला क्षेत्र `status` है (`Pending` तीसरे मामले के रूप में मौजूद है)। ऑर्केस्ट्रेटर को 'क्या यह पीएसपी रीडायरेक्ट का उपयोग करता है' प्रश्न की बिल्कुल भी परवाह नहीं है; यह केवल इस प्रश्न का उत्तर देता है कि 'क्या परिणाम अब अंतिम है या लंबित है?'

## इंटरफ़ेस डिज़ाइन करते समय किन फ़ील्ड्स को कभी भी पार नहीं किया जाना चाहिए

प्रदाता-विशिष्ट त्रुटि कोड, प्रदाता-विशिष्ट ऑब्जेक्ट आईडी (उदाहरण के लिए पीएसपी का आंतरिक चार्ज आईडी प्रारूप), प्रदाता-विशिष्ट मेटाडेटा संरचनाएं कभी भी सिमेंटिक इंटरफ़ेस से लीक नहीं होनी चाहिए। इसके बजाय, गेटवे इस जानकारी को अपने स्वयं के लॉग में, अपने स्वयं के निदान क्षेत्र में रखता है; ऑर्केस्ट्रेटर केवल उसके सहसंबंध आईडी से मेल खाने वाला परिणाम लौटाता है।```text
Gateway içinde tutulan (dışarı sızmaz)
  provider_raw_code, provider_object_id, provider_response_headers

Orchestrator'a geçen (semantik)
  ChargeResult { status, amount, currency, providerRef }
````providerRef` एकमात्र अपवाद है: यह एक अपारदर्शी संदर्भ स्ट्रिंग है, जो समर्थन और निदान के लिए संग्रहीत है, लेकिन कभी भी शाखाबद्ध नहीं होती है।

## अक्सर भ्रमित होने वाले भेद```text
❌ SDK'yı bir sınıfa sarmak (wrap) yeterlidir
✓ Sarmalama tip sızıntısını çözmez; davranış hâlâ provider'a özgü kalabilir

❌ Abstraction = interface tanımlamak
✓ Abstraction = orchestrator'ın hiçbir zaman bilmemesi gereken şeyi seçmek

❌ Tek PSP varsa abstraction gereksizdir
✓ Tek PSP'de bile abstraction, test edilebilirlik ve mock'lanabilirlik sağlar
```## रैपर और वास्तविक अमूर्तता के बीच अंतर

| कसौटी | पतला आवरण | शब्दार्थ अमूर्तन |
| --- | --- | --- |
| टिप लीक | आमतौर पर होता है | कोई नहीं |
| क्या पीएसपी बदले जाने पर ऑर्केस्ट्रेटर प्रभावित होता है? | हाँ | नहीं |
| कार्ड/वॉलेट अंतर का प्रबंधन कौन करता है | आर्केस्ट्रा | गेटवे |
| परीक्षण योग्यता | पीएसपी मॉक अवश्य | छद्मअर्थी परिणाम ही पर्याप्त है |

## इंटरफ़ेस डिज़ाइन करते समय चेकलिस्ट

1. क्या किसी PSP का नाम, डोमेन या त्रुटि कोड सीधे `ChargeResult` में उल्लिखित है?
2. क्या ऑर्केस्ट्रेटर यह जाने बिना कि स्ट्रीम रीडायरेक्ट का उपयोग करता है या नहीं, `Pending` केस को सही ढंग से संभाल सकता है?
3. क्या नया पीएसपी जोड़ते समय ऑर्केस्ट्रेटर कोड में एक पंक्ति को बदलने की आवश्यकता है? यदि आवश्यक हो तो अमूर्तता लीक हो जाती है।
4. क्या गेटवे का परीक्षण वास्तविक पीएसपी से जुड़े बिना सभी सिमेंटिक अवस्थाओं को दोहरा सकता है?
5. क्या `providerRef` के अलावा कोई अपारदर्शी फ़ील्ड ऑर्केस्ट्रेटर के निर्णय तर्क में प्रवेश करती है?

इन सवालों के हां-नहीं के जवाब वास्तुकला संबंधी बहस को 'स्वच्छ कोड' के एक अमूर्त मामले से घटाकर मापने योग्य सीमा परीक्षण तक सीमित कर देते हैं।

## इस लेख से आपको क्या याद रखना चाहिए

1. प्रदाता गेटवे एसडीके और प्रत्येक प्रदाता-विशिष्ट विवरण का एकमात्र स्वामी है।
2. ऑर्केस्ट्रेटर केवल आशय (चार्ज रिक्वेस्ट) और सिमेंटिक परिणाम (चार्ज रिज़ल्ट) जानता है।
3. कार्ड और वॉलेट प्रवाह समान इंटरफ़ेस साझा करते हैं; अंतर `status` फ़ील्ड में `Pending` स्थिति है।
4. `providerRef` के अलावा कोई भी अपारदर्शी या प्रदाता-विशिष्ट फ़ील्ड सीमा पार नहीं करनी चाहिए।

> एक अमूर्तता का वास्तविक परीक्षण यह है कि जब आप एक नया प्रदाता जोड़ते हैं तो ऑर्केस्ट्रेटर कोड बिल्कुल नहीं बदलता है।

अगले भाग में, हम इस सीमा को इवेंट पक्ष में ले जाएंगे: क्या गेटवे द्वारा उत्पन्न वेबहुक ऑर्केस्ट्रेटर को कच्चे प्रदाता पेलोड के रूप में या सिमेंटिक इवेंट के रूप में पहुंचना चाहिए?