हम ट्रैफ़िक आँकड़ों के लिए Google Analytics का उपयोग करते हैं। Analytics कुकी तभी सेट होती हैं जब आप स्वीकार करें। सहमति के बिना, आँकड़े कुकी-रहित संकेतों से अनुमानित किए जाते हैं। कुकी नीति.
Gateway · Payments
एक worked example पूरे पेज से गुज़रता है — Arc Studio SRL, ऑर्डर 9F21-0716, €49.00। ग्राहक कार्ड, Apple Pay, Google Pay, USDC या बैंक ट्रांसफ़र चुनता है, और merchant की ओर की कहानी हर हाल में एक जैसी रहती है: एक reference, एक रसीद, एक यूरो राशि।
आश्वासन
तरीकों का बिखराव merchant की समस्या है, और यह बढ़ती जाती है: अपने dashboard वाला कार्ड processor, अपने release cycle वाला वॉलेट SDK, किसी और पेज पर रहने वाला crypto विकल्प जिसका कहीं reconciliation नहीं होता। हर नया तरीका एक और integration है, रिपोर्टों का एक और सेट, और एक और जगह जहाँ पेमेंट खो सकता है। Gateway इसे एक पेज और एक रिकॉर्ड में समेट देता है।
मोबाइल पर वही checkout — कार्ड, वॉलेट और USDC एक पेज पर। · रसीद — 52.95 USDC आए, €49.00 settle हुए, सीधे-सीधे लिखा हुआ।
कार्ड, Apple Pay, Google Pay, USDC, बैंक ट्रांसफ़र और आपके खरीदारों के अपेक्षित स्थानीय तरीके एक ही hosted पेज पर होते हैं, उस क्रम में जिसमें सामने बैठा ग्राहक उन्हें इस्तेमाल करने की सबसे ज़्यादा संभावना रखता है। पेज डेस्कटॉप, फ़ोन और in-app के अनुसार ढल जाता है; नया तरीका स्वीकार करना एक टॉगल है, प्रोजेक्ट नहीं।
Links back office — हर link अपनी स्थिति के साथ, इस महीने €2,304.50 वसूले गए।
USDC की कीमत उस रेट पर तय होती है जो ग्राहक के कन्फ़र्म करने से पहले पेज पर दिखता है, वह यूरो में settle होता है, और कार्ड की वसूली वाले उसी payout में पहुँचता है। आपके पास कभी टोकन पोज़िशन नहीं रहती, आपको treasury function नहीं खोलना पड़ता, और आपके अकाउंटेंट को दूसरी मुद्रा कभी नहीं दिखती। रसीद रूपांतरण एक पंक्ति में बताती है — ग्राहक ने crypto में भुगतान किया; बही-खाते में €49.00 है।
रिफ़ंड प्रक्रिया में — ऑर्डर के विरुद्ध, कारण अनिवार्य, मूल मार्ग से वापसी।
सब कुछ पेमेंट तरीके के बजाय ऑर्डर से जुड़ा है। ऑर्डर 9F21-0716 में उसकी line items, €0.50 का प्रोसेसिंग शुल्क, कुल राशि, authorization का नतीजा, रसीद और रिफ़ंड सब हैं। इसीलिए reconciliation एक lookup है, विवाद एक स्क्रीन, और रिफ़ंड किसी कार्ड, वॉलेट या chain की ओर नहीं, ऑर्डर की ओर इशारा करता है।
Checkout branding — लोगो, रंग, टाइप और कोने, सेव करने से पहले लाइव preview के साथ।
कार्ड हमारी ओर vault में रखे जाते हैं और token से संदर्भित होते हैं, इसलिए लौटता ग्राहक एक टैप में भुगतान करता है और आपके सिस्टम कार्ड नंबर नहीं, सिर्फ़ एक reference रखते हैं। Subscriptions उसी token पर आपके तय शेड्यूल से चलती हैं, अपने soft declines खुद दोबारा आज़माती हैं, और कार्ड दोबारा जारी होने पर भी कार्डधारक के साथ चलती रहती हैं — हर चक्र अपना ऑर्डर और अपनी रसीद बनाता है।
Methods config — हर checkout के लिए तरीके टॉगल करें, settlement और routing बगल में।
कार्ड ट्रैफ़िक उस routing policy पर चलता है जो आपकी समझ की भाषा में लिखी होती है, soft decline को ग्राहक को विफलता दिखने से पहले दूसरे मार्ग पर दोबारा आज़माता है, और 3-D Secure तभी लगाता है जब policy कहे, डिफ़ॉल्ट रूप से नहीं। जब कोई पेमेंट सचमुच अस्वीकार होता है, तो कारण ऐसी भाषा में आता है जिस पर ऑपरेटर कार्रवाई कर सके, कच्चे issuer कोड में नहीं।
लोगो अपलोड कीजिए, रंग, टाइप और कोने तय कीजिए, और सेव करने से पहले असली checkout का preview देखिए। इसे हमारे डोमेन पर चलाइए, अपने डोमेन पर, या अपने ही ऐप के भीतर — powered-by footer के साथ या पूरी तरह whitelabeled। डेमो checkout Arc Studio SRL का है, और वह उन्हीं का लगता है।
तरीके
चेकआउट में दिखने वाला हर तरीका, उसके पीछे के रेल, और वह करेंसी जिसमें रकम आती है। असली बात दाईं ओर के कॉलम में है: ग्राहक कुछ भी चुने, मर्चेंट का पेआउट एक ही यूरो राशि होता है।
इंटीग्रेशन
idempotency key के साथ ऑर्डर बनाएँ, hosted चेकआउट पर रीडायरेक्ट करें, और हस्ताक्षरित नतीजा पाएँ। पूरा इंटीग्रेशन मुट्ठी भर endpoints और एक webhook का है।
किसी इंटीग्रेशन की ज़रूरत नहीं — बैक ऑफ़िस में सिंगल-यूज़ या कलेक्टिंग लिंक बनाएँ और भेज दें। भुगतान उसी जगह आते हैं जहाँ API वाले आते हैं।
iOS और Android पर वही चेकआउट नेटिव रूप में खुलता है, और वॉलेट शीट व 3-D Secure के दौरान भी ग्राहक आपके ऐप के भीतर ही रहता है।
बिना डेवलपर के मौजूदा स्टोरफ़्रंट जोड़ें: इंस्टॉल करें, keys पेस्ट करें, और sandbox कार्ड से टेस्ट पेमेंट लें।
अपना लेआउट रखें और पेमेंट इनपुट एम्बेड करें। ये हमारी ओर hosted और PCI-scoped रहते हैं, इसलिए कार्ड डेटा फिर भी आपके सर्वर को नहीं छूता।
इंटीग्रेशन
आपका बैकएंड API से ऑर्डर बनाता है: राशि, करेंसी, आपका रेफ़रेंस।
ग्राहक hosted पेज पर कार्ड, वॉलेट या USDC चुनता है।
रकम सत्यापित होकर होल्ड होती है; 3-D Secure तभी आता है जब पॉलिसी माँगे।
चार्ज पूरा होता है और सेटलमेंट की कतार में जाता है।
हस्ताक्षरित order.paid webhook आता है; सिग्नेचर सत्यापित करें और ऑर्डर पूरा करें।
दिन के ऑर्डर बैच बनते हैं और EUR में पेआउट होता है — चेकआउट से बैंक लाइन तक एक ही रेफ़रेंस।
फ़ीचर्स
Hosted checkout में कार्ड, Apple Pay, Google Pay और USDC साथ-साथ दिखते हैं। बाईं ओर ऑर्डर 9F21-0716 — तीन line items, €0.50 प्रोसेसिंग शुल्क, €49.00 देय — और दाईं ओर भुगतान के तरीके का चुनाव। ग्राहक चुनता है; पेज उसके अनुसार ढलता है; merchant ने इंटीग्रेशन सिर्फ़ एक बार किया।
वही checkout URL फ़ोन के लेआउट में ढल जाता है: ऑर्डर एक सारांश बार में सिमट जाता है, भुगतान के बटन अपनी जगह रहते हैं, कार्ड फ़ॉर्म के लेबल बने रहते हैं। जो डेस्कटॉप पर चलता है वही मोबाइल पर चलता है — और जब आप चाहें कि भुगतान ब्राउज़र की जगह आपके अपने ऐप के भीतर हो, तब iOS और Android SDK उसी ऑर्डर पर वही checkout नेटिव रूप में दिखाते हैं।
USDC से भुगतान एक ऐसी रसीद पर खत्म होता है जिसे merchant का अकाउंटेंट आसानी से पढ़ सके। तरीका: Base पर 52.95 USDC →︎ EUR settlement, रसीद पर छपी दर से, 1 EUR = 1.0807 USDC। संदर्भ 9F21-0716, ग्राहक को ईमेल किया गया और तुरंत डाउनलोड के लिए उपलब्ध। ग्राहक ने crypto में भुगतान किया; बही-खाते में €49.00 दर्ज है।
Payment links को मिलता है एक असली डेस्क: Arc Studio SRL के 8 लिंक paid, active और expired में बँटे, हर पंक्ति पर राशि, भुगतानों की संख्या और स्टेटस। ऊपर के कार्ड हिसाब रखते हैं — 4 active लिंक, इस महीने 18 लिंक भुगतानों से €2,304.50 जमा हुए, आज €49.00 का भुगतान। बनाइए, खोजिए, export कीजिए, बस।
रिफंड ऑर्डर पर लागू होता है, भुगतान के तरीके पर नहीं। Drawer 9F21-0716 पर खुलता है, राशि पहले से पूरे €49.00 पर सेट, कारण अनिवार्य, और एक वैकल्पिक नोट जो exports में और ग्राहक की रसीद पर पहुँचता है। पैसा अपने-आप उसी मूल पेमेंट रेल से लौटता है — कार्ड का रिफंड कार्ड में, USDC ऑर्डर उनके EUR settlement के रूप में — आमतौर पर 1–3 कार्य-दिवसों में।
ब्रांडिंग एक सेटिंग पेज है, कोई सर्विस प्रोजेक्ट नहीं: लोगो अपलोड कीजिए, accent, ink और surface रंग तय कीजिए, टाइपफ़ेस और कोनों की शैली चुनिए। सेव करने से पहले लाइव प्रीव्यू आपका असली checkout दिखाता है — डेस्कटॉप या मोबाइल — और accent रंग पे बटन के फ़ोकस, स्टेटस टिक और सक्रिय टैब में दिखता है। इसे अपने sandbox के साथ मिले checkout होस्ट पर चलाइए, या अपने डोमेन पर।
भुगतान के तरीके टॉगल हैं, जिनके पीछे providers हैं: 3-D Secure वाले कार्ड, वॉलेट बटन के रूप में Apple Pay और Google Pay, Ethereum, Base और Solana पर USDC, और vIBAN संदर्भ के साथ SEPA बैंक ट्रांसफ़र। इनके बगल में settlement पैनल सौदा साफ़ बताता है: ग्राहक पुष्टि से पहले कन्वर्ज़न देखते हैं; आपका settlement हमेशा EUR में होता है।
ऑर्डर बनाइए, hosted पेज पर रीडायरेक्ट कीजिए, नतीजा पाइए। पेमेंट UI, तरीकों का लॉजिक और रसीदें Gateway संभालता है। आपकी टीम को न कोई checkout फ्रंटएंड बनाना है, न पैच करना है, न तरीके बदलने पर उसे अपडेट रखना है।
सब कुछ ऑर्डर से जुड़ा है, भुगतान के तरीके से नहीं। ऑर्डर 9F21-0716 में उसके line items हैं — €38.50 का brand identity sprint, €6.00 का typeface licensing, €4.00 की rush delivery — साथ में €0.50 प्रोसेसिंग शुल्क और एक कुल राशि। भुगतान चाहे जैसे हो, क्वेरी, reconcile और रिफंड इसी संदर्भ पर होते हैं।
तरीकों और ब्रांडिंग के बदलाव नए checkout सेशन पर लागू होते हैं — यह उसी स्क्रीन पर लिखा होता है जहाँ आप उन्हें सेव करते हैं। भुगतान के बीच में मौजूद ग्राहक के हाथों में पेज कभी नहीं बदलता।
कार्ड का रास्ता वह उबाऊ हिस्सा है जो पूरी तरह संभाला जा चुका है: inline validation, फ़्लो में बना strong customer authentication वाला 3-D Secure एक पढ़ने योग्य रूटिंग नीति के तहत, और इंटीग्रेशन टेस्ट के लिए हर sandbox के अपने टेस्ट कार्ड। Crypto स्वीकार करने से कार्ड फ़्लो कभी खराब नहीं होता।
वॉलेट बटन हैं, प्रोजेक्ट नहीं। Apple Pay और Google Pay उसी पेज पर वन-टैप शीट के रूप में आते हैं और डिवाइस टोकन से भुगतान करते हैं — असली कार्ड नंबर पेज तक कभी नहीं पहुँचता — उसी ऑर्डर और उसी रसीद के साथ। इन्हें चालू करना methods स्क्रीन पर एक टॉगल है।
Crypto की कीमत checkout पर दिखाई गई दर से तय होती है और settlement यूरो में होता है। Merchant के पास गलती से कोई टोकन पोज़िशन नहीं रह जाती; बही-खाता एक ही मुद्रा में रहता है।
USDC का तरीका एक ही टॉगल के पीछे Ethereum, Base और Solana को कवर करता है। ग्राहक उसी नेटवर्क पर भुगतान करता है जिस पर उसका वॉलेट है; merchant की तरफ़ कुछ नहीं बदलता।
Pay-by-transfer में vIBAN संदर्भ होता है, इसलिए आने वाला SEPA भुगतान अपने ऑर्डर की पहचान अपने-आप बता देता है। इसे उन ग्राहकों के लिए चालू कीजिए जो बैंक से चुकाने लायक इनवॉइस चाहते हैं, और reconciliation अपने-आप होता रहता है।
कार्ड और वॉलेट के अलावा, checkout में वे account-to-account और स्थानीय तरीके भी हैं जिन्हें यूरोपीय खरीदार देखने की उम्मीद करता है, और ये ग्राहक के देश के अनुसार दिखते हैं, एक लंबी सूची में ठूँसे हुए नहीं।
BNPL उसी तरीके की पंक्ति में बाकी सबके साथ है — ग्राहक भुगतान बाँट लेता है, merchant को एक बार में पैसा मिलता है, और ऑर्डर संदर्भ नहीं बदलता। एक टॉगल, वही रसीद, वही reconciliation।
पेज तरीकों को इस क्रम में रखता है कि ग्राहक के इस्तेमाल करने की संभावना किसकी ज़्यादा है — देश, भाषा, डिवाइस और क्या उसने पहले आपसे भुगतान किया है — ताकि काम का विकल्प पहला हो, चौथा नहीं।
राशि ग्राहक की मुद्रा में दिखाइए, पुष्टि से पहले कन्वर्ज़न बताते हुए, और settlement हर हाल में EUR में कीजिए। ग्राहक को जानी-पहचानी राशि दिखती है; आपके लेजर में एक ही रहती है।
Hosted पेज अपने लेबल, एरर और रसीदें स्थानीय भाषा में दिखाता है। बटन गलत भाषा में होने की वजह से कोई भुगतान अधूरा नहीं छोड़ता।
लौटने वाला ग्राहक सेव किए कार्ड से एक टैप में भुगतान करता है। कार्ड हमारी तरफ़ vault में रहता है और टोकन से संदर्भित होता है, इसलिए आपके सिस्टम में सिर्फ़ संदर्भ रहता है, PAN कभी नहीं — और दूसरी खरीदारी पहली से छोटी हो जाती है।
Recurring चार्ज आपके तय किए शेड्यूल पर चलते हैं — राशि, अंतराल, शुरुआत और अंत — tokenized कार्ड पर। हर चक्र का अपना ऑर्डर और अपनी रसीद बनती है, इसलिए सब्सक्रिप्शन बाकी सब की तरह पंक्ति-दर-पंक्ति reconcile होता है।
Recurring चार्ज पर soft decline को बट्टे खाते में डालने की जगह शेड्यूल पर दोबारा आज़माया जाता है, और ग्राहक को तभी बताया जाता है जब ज़रूरी हो। फ़ेल हुए रिन्यूअल अब चुपचाप churn नहीं बनते।
सेव किए कार्ड network tokens के रूप में रखे जाते हैं और कार्डधारक के साथ रीइश्यू और एक्सपायरी के बाद भी चलते रहते हैं। जो सब्सक्रिप्शन कार्ड बदलने पर टूट जाता था, वह अब चार्ज होता रहता है।
ऑर्डर API से idempotency keys के साथ बनते हैं — दोबारा भेजी गई रिक्वेस्ट मूल नतीजा लौटाती है, दूसरा चार्ज कभी नहीं — और developers सेक्शन में keys और docs हैं। Checkout hosted है; इंटीग्रेशन मुट्ठी भर endpoints का है, जो वहीं documented हैं जहाँ सेटिंग्स हैं।
आपके बैकएंड को भुगतान की खबर उसी पल मिलती है जब वह होता है: ऑर्डर लाइफ़साइकल पर signed webhook इवेंट — paid, failed, refunded — जिनमें signature verification आपकी तरफ़ और replay protection हमारी तरफ़ होता है।
नेटिव ऐप्स वही checkout ऐप के भीतर दिखाते हैं, यूज़र को ब्राउज़र में भेजे बिना। SDK तरीकों का लॉजिक, वॉलेट शीट और 3-D Secure संभालता है; ऑर्डर और रसीद वही हैं जो आपका बैकएंड पहले से जानता है।
Shopping-cart प्लगइन किसी मौजूदा स्टोर को बिना डेवलपर के Gateway से जोड़ देते हैं — इंस्टॉल कीजिए, keys पेस्ट कीजिए, टेस्ट पेमेंट लीजिए। वही ऑर्डर उसी बैक ऑफिस में आते हैं जिसमें API वाले आते हैं।
जब भुगतान आपके अपने लेआउट के भीतर ही होना हो, तो पेमेंट फ़ील्ड सीधे embed कीजिए: इनपुट हमारी तरफ़ hosted और PCI-scoped हैं, उनके आसपास का पेज पूरी तरह आपका है, और कार्ड डेटा आपके सर्वरों को कभी छूता नहीं।
एक लिंक एक भुगतान के बाद बंद हो सकता है या लगातार भुगतान लेता रह सकता है — डेमो की वर्कशॉप सीट पर 3 भुगतान आ चुके हैं, कंसल्टेशन आवर पर 6। लिंक डिफ़ॉल्ट रूप से 30 दिन बाद अपने आप एक्सपायर हो जाते हैं, और एक्सपायर हो चुका लिंक चुपचाप फ़ेल होने के बजाय साफ़ बताता है कि वह एक्सपायर हो चुका है।
इंटीग्रेशन रन टेस्ट सेशन पर होते हैं, आपकी sandbox कीज़ के साथ जारी किए गए कार्ड से, किसी भी असली लेन-देन से पहले। फ़्लो एक जैसे हैं, इसलिए जो टेस्ट में पास होता है, वही लाइव जाता है।
कार्ड ट्रैफ़िक एक रूटिंग पॉलिसी पर चलता है, जो उन शब्दों में लिखी है जिन्हें आप पहचानते हैं — कार्ड ब्रांड, जारीकर्ता देश, करेंसी, राशि — किसी ब्लैक बॉक्स में नहीं। भुगतान किस रूट से गया, यह उसी स्क्रीन पर दिखता है जहाँ भुगतान दिखता है।
सॉफ़्ट डिक्लाइन को उसी चेकआउट सेशन में वैकल्पिक रूट पर दोबारा आज़माया जाता है, ग्राहक को विफलता दिखने से पहले। ज़्यादातर रिकवर हुए भुगतान ऐसे होते हैं जिनके जोखिम में होने का ग्राहक को पता भी नहीं चलता।
इश्यूअर के कच्चे कोड ऐसे कारणों में बदले जाते हैं जिन पर ऑपरेटर कार्रवाई कर सके — कार्ड एक्सपायर, अपर्याप्त बैलेंस, इश्यूअर रिस्क — और उन्हें समूहित किया जाता है, ताकि कई भुगतानों में दिखने वाला पैटर्न पैटर्न की तरह ही नज़र आए।
ज़्यादातर भुगतान सिर्फ़ डिवाइस और व्यवहार संबंधी संकेतों पर पास हो जाते हैं; पॉलिसी की ज़रूरत होने पर ही स्टेप-अप चैलेंज आता है। पॉलिसी आप तय करते हैं — हमेशा, रिस्क-आधारित, या नियम अनुमति दें तो छूट के साथ — और होस्टेड पेज पूरा फ़्लो संभालता है।
चेकआउट, रसीद और सेटलमेंट पर एक ही ऑर्डर रेफ़रेंस रहता है। जो भी 9F21-0716 मिलाता है, उसे €49.00 की एक ही एंट्री मिलती है — एक सिस्टम में कार्ड रिकॉर्ड और दूसरे में क्रिप्टो रिकॉर्ड नहीं।
सेटलमेंट वहीं तय होता है जहाँ आप उसे कॉन्फ़िगर करते हैं: EUR में ऑटो-कन्वर्ट, RO49 •••• 0421 में सेटल, रोज़ 23:00 बजे पेआउट। अकाउंटेंट कल जो राशि देखेगा, वह आज मर्चेंट के पढ़ने लायक स्क्रीन पर तय होती है।
हर पेआउट खुलकर उन ऑर्डरों तक पहुँचाता है जिनसे वह बना, फ़ीस मदवार दिखाई जाती है। बैंक की लाइन उस सूची से मिलती है जिसे आप एक्सपोर्ट कर सकते हैं, इसलिए महीने का अंत जाँच-पड़ताल नहीं, बस एक लुकअप है।
रिफ़ंड राशि मूल चार्ज तक बदली जा सकती है — ड्रॉअर अधिकतम राशि दिखाता है और उससे कम को आंशिक रिफ़ंड मानता है। एक ऑर्डर पर दस आंशिक रिफ़ंड भी एक ही रेफ़रेंस से रिकॉन्सिल होते हैं।
हर रिफ़ंड में कारण देना ज़रूरी है और नोट वैकल्पिक, और वह नोट साथ चलता है: एक्सपोर्ट में और ग्राहक की रसीद पर दिखता है। छह महीने बाद किसी को याद नहीं रखना पड़ता कि ऑर्डर 9F21-0716 का पैसा क्यों लौटाया गया था।
रसीदें ग्राहक को ई-मेल की जाती हैं और तुरंत डाउनलोड भी हो सकती हैं; रिफ़ंड रसीदें भी इसी रास्ते जाती हैं। मर्चेंट को कभी रसीद टेम्पलेट नहीं बनाना पड़ता।
दिन का बैच जाने से पहले रद्द करने पर ऑथराइज़ेशन होल्ड हट जाता है और कोई पैसा नहीं हिलता — न रिफ़ंड, न फ़ीस, ग्राहक के स्टेटमेंट पर समझाने को कुछ नहीं।
कार्ड भुगतान ऐसी रूटिंग पॉलिसी के तहत 3-D Secure से चलते हैं जिसे आप पढ़ सकते हैं। वॉलेट भुगतान डिवाइस का अपना ऑथेंटिकेशन साथ लाते हैं, और webhook इवेंट पर भरोसा करने से पहले उनके सिग्नेचर सत्यापित किए जाते हैं।
स्क्रीनिंग नियम वाक्यों की तरह पढ़े जाते हैं — देश Y से पहली बार इस्तेमाल हुए कार्ड पर X से ऊपर की राशि — और उन पर कार्रवाई करते हैं: अनुमति, चैलेंज या ब्लॉक। भरोसेमंद और ब्लॉक किए गए कार्ड, ई-मेल और पतों की सूचियाँ इसी स्क्रीन के पीछे हैं।
एक कार्ड, एक डिवाइस या एक पते से बार-बार की गई कोशिशें रेट नियम पकड़ लेते हैं, किसी के बाद में नोटिस करने का इंतज़ार नहीं करना पड़ता। सिग्नल भुगतान पर ही दिखते हैं, किसी स्कोर में दबे नहीं होते।
चार्जबैक उसके पीछे के ऑर्डर के साथ खुलता है: ऑथराइज़ेशन नतीजा, 3-D Secure परिणाम, रसीद, डिलीवरी, रिफ़ंड इतिहास। उसी स्क्रीन से जवाब दें, और एविडेंस पैक याददाश्त से नहीं, रिकॉर्ड से तैयार होता है।
कार्ड विवरण लेने वाला पेज हमारा है — PCI-स्कोप्ड और होस्टेड। ग्राहक हमारे डोमेन पर भुगतान करे, आपके डोमेन पर या आपके ऐप के भीतर, आपके सर्वर को टोकन और ऑर्डर रेफ़रेंस दिखता है — कार्ड नंबर कभी नहीं।
भुगतान डेटा रेस्ट पर एन्क्रिप्टेड रहता है और EU में प्रोसेस होता है। यूरोपीय मर्चेंट के लिए डेटा कहाँ रहता है, यह फ़ुटनोट नहीं, जवाब है।
रिफ़ंड, मेथड में बदलाव, ब्रांडिंग में बदलाव, की रोटेशन — हर एक ऑडिट ट्रेल में दर्ज होता है, ऑपरेटर, टाइमस्टैम्प और कारण के साथ। विशेषाधिकार वाली कार्रवाइयाँ चलने से पहले कारण माँगती हैं।
फ़ाइनेंस पेआउट देखता है, सपोर्ट ऑर्डर देखता और रिफ़ंड जारी करता है, डेवलपर कीज़ और लॉग देखते हैं। एक ही लॉगिन साझा करने के बजाय एक्सेस रोल के अनुसार दिया जाता है।
भुगतानकर्ता ग्राहक व्यू में जुड़ते जाते हैं — किसने भुगतान किया, कितनी बार, किस मेथड से — ताकि दोबारा आने वाला ग्राहक एक रिकॉर्ड हो, एक्सपोर्ट में मेल खाते ई-मेल का संयोग नहीं।
सर्च बॉक्स से लिंक या रेफ़रेंस द्वारा भुगतान खोजें; बहीखाते को ज़रूरत हो तो मौजूदा व्यू CSV में एक्सपोर्ट करें। बैक ऑफ़िस यह मानकर चलता है कि अकाउंटेंट पूछेगा।
आपके चुने समय में वॉल्यूम, अप्रूवल रेट, रिफ़ंड और मेथड मिक्स। यह जानने के लिए काफ़ी कि पैसा कहाँ गया और कौन-सा मेथड बढ़ावा देने लायक है — कुछ एक्सपोर्ट किए बिना।
Gateway, Protocore Center से जुड़ता है: वहाँ का payment-links बैक ऑफ़िस हर लिंक को उसके सेटलमेंट ट्रांसफ़र के साथ दिखाता है, और पूरे ट्रेस के लिए open-in-Tracer लिंक देता है। आपकी ops टीम चेकआउट से लेकर लेजर तक सब देखती है।
डेमो चेकआउट Arc Studio SRL का है: उनका नाम, उनका मार्क, उनका ऑर्डर। इसे powered-by-Protocore फ़ुटर के साथ चलाएँ या पूरी तरह whitelabel — दोनों तरह पेज आपका ही लगता है।
FAQ
कार्ड पेमेंट दो चरणों में होता है: ऑथराइज़ेशन खरीद के समय रकम होल्ड करता है, और सेटलमेंट उसे ट्रांसफ़र करता है। Gateway अपने आप कैप्चर करता है, दिन के ऑर्डर एक बैच में बंद करता है, और सेटिंग्स में तय दैनिक पेआउट समय पर आपके नामित खाते में EUR में भुगतान करता है।
समय का। सेटलमेंट से पहले रद्द करने पर ऑथराइज़ेशन होल्ड हट जाता है और कोई पैसा नहीं हिलता। सेटलमेंट के बाद यह refund है — ऑर्डर के against जारी, पूरा या आंशिक, कारण दर्ज होकर उसी मूल पेमेंट मेथड से वापस जाता है।
पॉलिसी के रूप में, डिफ़ॉल्ट रुकावट के रूप में नहीं। ज़्यादातर फ़्लो सिर्फ़ डिवाइस और व्यवहार संबंधी डेटा से पास हो जाते हैं; step-up चैलेंज तभी आता है जब रूटिंग पॉलिसी माँगे। पॉलिसी आप तय करते हैं — फ़्लो hosted पेज संभालता है।
यूरो। USDC राशि की कीमत ग्राहक के पुष्टि करने से पहले पेज पर तय हो जाती है, बताई गई दर पर EUR में सेटल होती है, और रसीद में कन्वर्ज़न दर्ज रहता है। चेकआउट, रसीद और सेटलमेंट का एक ही ऑर्डर रेफ़रेंस होता है — आपके पास कभी टोकन पोज़िशन नहीं रहती।
ऑर्डर ही आपकी साक्ष्य फ़ाइल है। ऑथराइज़ेशन नतीजा, रसीद, refund इतिहास और webhook डिलीवरी — सब एक ही रेफ़रेंस से जुड़े होते हैं। एक लुकअप से विवाद का जवाब मिल जाता है, और उसी स्क्रीन से refund अक्सर तेज़ समाधान होता है।
नहीं। ऑर्डर idempotency keys के साथ बनते हैं, इसलिए दोबारा भेजा गया अनुरोध दूसरा चार्ज करने के बजाय मूल नतीजा लौटाता है — और वापसी में webhooks रीप्ले सुरक्षा के साथ हस्ताक्षरित होते हैं।
कार्ड विवरण लेने वाला पेज हमारा है — hosted और हमारी ओर PCI-scoped। आपके सर्वर को टोकन और ऑर्डर रेफ़रेंस मिलता है, कार्ड नंबर कभी नहीं। यह तब भी लागू रहता है जब ग्राहक हमारे डोमेन पर, आपके डोमेन पर, आपके ऐप में, या आपके अपने लेआउट में एम्बेड किए गए पेमेंट फ़ील्ड से भुगतान करे।
हाँ। इसे अपने sandbox के साथ मिले चेकआउट होस्ट पर, अपने डोमेन पर, या hosted पेमेंट फ़ील्ड के साथ अपने पेज में एम्बेड करके चलाएँ। ब्रांडिंग — लोगो, रंग, टाइपफ़ेस, कोने — एक सेटिंग्स स्क्रीन है जिसमें लाइव प्रीव्यू मिलता है, और फ़ुटर आपकी पसंद से powered-by या पूरी तरह whitelabel रहता है।
कार्ड हमारी ओर नेटवर्क टोकन के रूप में vault में रखे जाते हैं; आपके सिस्टम में सिर्फ़ रेफ़रेंस रहता है। सब्सक्रिप्शन आपके तय शेड्यूल पर उसी टोकन को चार्ज करता है, अपने soft declines खुद रीट्राई करता है, और कार्ड री-इश्यू होने पर भी कार्डधारक के साथ चलता है। हर साइकल का अपना ऑर्डर और रसीद बनती है, इसलिए सब्सक्रिप्शन पंक्ति-दर-पंक्ति रिकंसाइल होता है।
उसकी अपनी करेंसी में राशि, पुष्टि से पहले बताए गए कन्वर्ज़न के साथ, और उसकी भाषा में चेकआउट। आपका सेटलमेंट फिर भी EUR में होता है। सिद्धांत USDC जैसा ही है: ग्राहक की तरफ़ सब कुछ ढल जाता है, आपका लेजर एक ही करेंसी में रहता है।
आपकी तरफ़ यह यूरो की प्राप्य राशि है। क्रिप्टो वाला हिस्सा — प्राइसिंग, ऑन-चेन पेमेंट और कन्वर्ज़न — Gateway संभालता है, और आपके खाते में नियंत्रित सेटलमेंट रास्ते से EUR पहुँचता है, लागू दर के साथ रसीद में दर्ज। आप टोकन की कस्टडी नहीं रखते, वॉलेट नहीं चलाते और कोई पोज़िशन नहीं रखते, क्योंकि कन्वर्ज़न सेटलमेंट के बाद नहीं, पहले होता है।
खाता मिलने के दिन ही पेमेंट लिंक काम करने लगता है। API इंटीग्रेशन में एक ऑर्डर endpoint, एक रीडायरेक्ट और एक हस्ताक्षरित webhook होता है — ज़्यादातर टीमें उसी हफ़्ते टेस्ट में चला लेती हैं और शुरू से अंत तक टेस्ट पेमेंट लेने के बाद लाइव करती हैं। स्टोर प्लगइन में डेवलपमेंट की ज़रूरत ही नहीं पड़ती।
हाँ — दोनों साथ चलाएँ। नए ऑर्डर Gateway पर भेजें, जबकि पुराना प्रदाता अपने ऑर्डर का सेटलमेंट और refund पूरा करे, क्योंकि refund हमेशा उसी रेल से लौटते हैं जिसने भुगतान लिया था। सेव किए हुए कार्ड टोकन के रूप में माइग्रेट होते हैं, इसलिए आपके सब्सक्राइबर को कार्ड विवरण दोबारा नहीं डालना पड़ता।
ऑर्डर कॉल और webhook हैंडलर। पेमेंट पेज, मेथड लॉजिक, वॉलेट शीट, 3-D Secure, रसीदें और बाद में जुड़ने वाला हर नया तरीका — इन्हें अप-टू-डेट रखना हमारा काम है। hosted चेकआउट का यही मतलब है।
प्राइसिंग
बिना प्लेटफ़ॉर्म शुल्क के लाइव हों — Gateway उन पेमेंट्स पर कमाता है जिन्हें वह प्रोसेस करता है, इसलिए लागत checkout से गुज़रने वाले वॉल्यूम के साथ चलती है।
अपने ब्रांड के तहत checkout चलाइए, ऐसे license पर जो आपके चालू किए rails और अनुमानित throughput के अनुसार तय हो।
पेमेंट पेज पर आपका ब्रांड, नीचे हमारे rails, आपके लिए संचालित — दायरा इस पर निर्भर है कि आप कौन-से पेमेंट तरीके चालू करते हैं।
लागत checkout से गुज़रने वाले वॉल्यूम और आपके चालू किए rails पर निर्भर करती है — कार्ड, वॉलेट और USDC settlement। इसे standalone लें या पूरी तरह whitelabeled।
परखें
हम आपके साथ यह worked example चलाते हैं — Arc Studio SRL, ऑर्डर 9F21-0716 — कार्ड, वॉलेट और USDC से भुगतान करते हुए, और उसके पीछे का merchant back office भी दिखाते हैं।
API keys वाला एक टेस्ट merchant, ताकि आपकी टीम ऑर्डर बना सके, hosted checkout चला सके और signed नतीजे शुरू से अंत तक पा सके।
Order API, order.paid webhook और integration guide — checkout बनाने के बजाय उसे Gateway की ओर मोड़ने के लिए जो कुछ चाहिए, सब।
आपके लोगो, रंगों और टाइपफ़ेस में hosted पेज, ताकि लाइव होने से पहले आप अपना checkout देख सकें।
आगे पढ़ें
Standalone या whitelabel चलता है — checkout पर आपका ब्रांड, नीचे हमारे rails।
PoS काउंटर पर Gateway का ऑर्डर मॉडल साझा करता है, vIBAN उसके बैंक-ट्रांसफ़र ऑर्डर को स्वतः पहचाने जाने वाले रेफ़रेंस देता है, Chain उसके USDC भुगतानों को EUR में सेटल करता है, Center चेकआउट के पीछे का ऑपरेटर कंसोल है, और Agents वही ऑर्डर मॉडल उन भुगतानों पर लागू करता है जो मानवीय पॉलिसी के तहत सॉफ़्टवेयर शुरू करता है।
ऊपर का सब कुछ प्रोडक्शन डेमो में चलता है, जिसे हम आपको दिखा सकते हैं: स्टैंडअलोन, whitelabel या एक प्लेटफ़ॉर्म के रूप में। बताइए आप क्या बना रहे हैं, हम सबसे छोटा रास्ता दिखाएँगे।
