पेमेंट गेटवे इंटीग्रेशन सर्विस

नहीं, और छूनी भी नहीं चाहिए। हम प्रोसेसर के होस्टेड कार्ड फ़ील्ड या SDK इस्तेमाल करते हैं ताकि कच्चे कार्ड नंबर आपके बैकएंड से कभी न गुज़रें। यह सुरक्षित तरीका भी है और वह भी जो आपको PCI-DSS कंप्लायंस के सबसे भारी दायरे से बाहर रखता है।

जी हाँ। ट्रायल अवधि, प्लान बदलने पर प्रोरेशन, फ़ेल रिन्यूअल भुगतान की डनिंग और कैंसिलेशन फ़्लो, ये सब मानक सब्सक्रिप्शन-बिलिंग ज़रूरतें हैं जिन्हें हम बनाते हैं, वही पैटर्न जो हमारा अपना Invoex वेब ऐप चलाता है।

अक्सर अकेले Stripe या PayPal ही हैरानी की हद तक कई देशों को अच्छी तरह कवर कर लेते हैं। जहाँ वे किसी बाज़ार को ठीक से सर्व नहीं करते, वहाँ हम उसी बाज़ार के लिए क्षेत्रीय प्रोसेसर जोड़ते हैं, किसी एक गेटवे से वह काम करवाने की ज़िद नहीं करते जिसके लिए वह बना नहीं है।

वेबहुक सिग्नेचर वेरिफ़िकेशन पक्का करता है कि इवेंट सच में प्रोसेसर से आए हैं, और idempotency key नेटवर्क रीट्राई पर ग्राहक को दो बार चार्ज होने से रोकती हैं। दोनों डिफ़ॉल्ट रूप से बनी होती हैं, ऐसा कोई अपवाद नहीं जिसे हम पूछने पर ही संभालें।

जी हाँ। हर भुगतान का एक हिस्सा कई विक्रेताओं या ठेकेदारों तक पहुँचाना, रिफ़ंड और पेआउट के समय की सही हैंडलिंग के साथ, एक ऐसा पैटर्न है जिसे हमने पहले लागू किया है और जिसकी नुकीली जगहें हम जानते हैं।

वेब या मोबाइल बिल्ड में एक जोड़ के रूप में, जटिलता के हिसाब से आमतौर पर चार अंकों के निचले से मध्य बजट में (सिंगल गेटवे बनाम मल्टी-करेंसी बनाम मार्केटप्लेस पेआउट)। हर प्रोजेक्ट की तरह कोटेशन तय और escrow-सुरक्षित होता है।

जी हाँ। छोटे असली लेन-देन (बाद में रिफ़ंड किए गए) या प्रोसेसर का टेस्ट मोड पूरे परिदृश्य की वॉकथ्रू के साथ डिलीवरी चेकलिस्ट का हिस्सा हैं, ताकि अंतिम भुगतान रिलीज़ होने से पहले आप इसे सच में चलते देख लें।