ما برای آمار بازدید از Google Analytics استفاده می‌کنیم. کوکیهای تحلیلی فقط در صورت پذیرش شما ثبت میشوند. بدون رضایت، آمار بر پایهی سیگنال‌های بدون کوکی تخمین زده میشود. سیاست کوکی.
Gateway · پرداخت‌ها
یک مثال کاربردی کل صفحه را طی میکند — Arc Studio SRL، سفارش 9F21-0716، €49.00. مشتری کارت، Apple Pay، Google Pay، USDC یا انتقال بانکی را انتخاب میکند و از سمت پذیرنده ماجرا در هر حالت یکی است: یک مرجع، یک رسید، یک مبلغ یورو.
تضمین‌ها
پراکندگی روشها مشکل پذیرنده است و روزبه‌روز بدتر میشود: پردازشگر کارت با داشبورد خودش، SDK کیف پول با چرخه انتشار خودش، گزینه کریپتویی در صفحهای دیگر که با هیچ‌چیز تطبیق نمی‌خورد. هر روشِ اضافه یعنی یک یکپارچهسازی دیگر، مجموعه گزارش دیگر و جایی دیگر برای گم‌شدن یک پرداخت. Gateway این همه را در یک صفحه و یک رکورد جمع میکند.
همان checkout در موبایل — کارت، کیف پول و USDC در یک صفحه. · رسید — 52.95 USDC دریافت، €49.00 تسویه، شفاف و ساده.
کارت، Apple Pay، Google Pay، USDC، انتقال بانکی و روش‌های محلیِ مورد انتظار خریداران روی یک صفحه میزبانیشده قرار می‌گیرند، به ترتیبی که مشتری پشت صفحه احتمالاً استفاده میکند. صفحه با دسکتاپ، موبایل و درون‌برنامه سازگار میشود؛ پذیرش یک روش جدید یک کلید است، نه یک پروژه.
بک‌آفیس لینک‌ها — هر لینک با وضعیتش، €2,304.50 وصول‌شده در این ماه.
USDC با نرخی که پیش از تأیید مشتری در صفحه نشان داده میشود قیمتگذاری میشود، به یورو تسویه میشود و در همان پرداخت تجمیعیِ کارتها می‌نشیند. هیچ‌وقت موقعیت توکنی نگه نمیدارید، واحد خزانه‌داری راه نمی‌اندازید و حسابدارتان ارز دومی نمی‌بیند. رسید تبدیل را در یک خط می‌گوید — مشتری کریپتو پرداخت کرد؛ دفاتر می‌گویند €49.00.
استرداد در جریان — روی سفارش، دلیل الزامی، بازگشت از همان مسیر اولیه.
همه‌چیز به سفارش وصل است، نه به روش پرداخت. سفارش 9F21-0716 اقلامش، کارمزد پردازش €0.50، مبلغ کل، نتیجه مجوزدهی، رسید و استردادهایش را با خود دارد. برای همین تطبیق یک جست‌وجوست، اختلاف یک صفحه است و استرداد به سفارش اشاره میکند، نه به کارت یا کیف پول یا زنجیره.
برندینگ checkout — لوگو، رنگها، فونت و گوشهها، با پیشنمایش زنده پیش از ذخیره.
کارتها در سمت ما نگهداری و با توکن ارجاع داده میشوند، پس مشتری بازگشتی با یک ضربه پرداخت میکند و سیستمهای شما فقط یک مرجع ذخیره میکنند، نه شماره کارت. اشتراکها طبق زمان‌بندیِ تعریف‌شده شما روی همان توکن اجرا میشوند، رد شدنهای soft را خودشان دوباره تلاش میکنند و با صدور مجدد کارت هم دارنده کارت را دنبال میکنند — هر دوره سفارش و رسید خودش را دارد.
پیکربندی روشها — روشن و خاموش‌کردن روشها برای هر checkout، با تسویه و مسیریابی در کنارشان.
ترافیک کارت از سیاست مسیریابی‌ای پیروی میکند که با اصطلاحات آشنا نوشته شده، رد soft را پیش از آنکه مشتری شکست ببیند روی مسیر جایگزین دوباره امتحان میکند، و فقط وقتی سیاست بخواهد، نه به‌طور پیشفرض، به 3-D Secure ارتقا میدهد. وقتی پرداختی واقعاً رد میشود، دلیلش به زبانی میرسد که اپراتور بتواند رویش اقدام کند، نه کد خام صادرکننده.
لوگو بارگذاری کنید، رنگها، فونت و گوشهها را تنظیم کنید و پیش از ذخیره، checkout واقعی را پیشنمایش ببینید. روی دامنه ما، دامنه خودتان یا داخل اپلیکیشن خودتان اجرا کنید — با پانویس powered-by یا کاملاً whitelabel. checkout دمو متعلق به Arc Studio SRL است و مال خودشان به نظر میرسد.
روشها
همه روش‌هایی که چکاوت ارائه میدهد، بسترهای پشت آن‌ها و ارزی که مبلغ به آن واریز میشود. نکته اصلی ستون سمت چپ است: مشتری هر روشی را که انتخاب کند، تسویه پذیرنده یک رقم یورویی واحد است.
یکپارچهسازی
سفارش را با کلید idempotency بسازید، به چکاوت میزبانیشده هدایت کنید و نتیجه امضاشده را دریافت کنید. کل یکپارچهسازی چند endpoint و یک وبهوک است.
بدون هیچ یکپارچهسازی — در بک‌آفیس لینکی یک‌بارمصرف یا جمع‌آوری‌کننده بسازید و بفرستید. پرداخت‌ها در همان جایی ثبت میشوند که پرداختهای API.
iOS و Android همین چکاوت را بهصورت نیتیو نمایش می‌دهند و مشتری در کیف پول‌ها و 3-D Secure هم داخل اپ شما میماند.
فروشگاه موجودتان را بدون برنامه‌نویس متصل کنید: نصب کنید، کلیدها را وارد کنید و با یک کارت sandbox پرداخت آزمایشی انجام دهید.
طراحی صفحه خودتان را حفظ کنید و فیلدهای پرداخت را در آن جاسازی کنید. این فیلدها در سمت ما میزبانی میشوند و مشمول PCI هستند، پس داده کارت باز هم به سرورهای شما نمی‌رسد.
یکپارچهسازی
بک‌اند شما با API سفارش می‌سازد: مبلغ، ارز، مرجع خودتان.
مشتری در صفحه میزبانیشده کارت، کیف پول یا USDC را انتخاب میکند.
وجه بررسی و بلوکه میشود؛ 3-D Secure فقط وقتی وارد میشود که سیاست بخواهد.
برداشت تکمیل میشود و در صف تسویه قرار می‌گیرد.
وبهوک امضاشده order.paid میرسد؛ امضا را راستی‌آزمایی کنید و سفارش را انجام دهید.
سفارشهای روز در یک بچ جمع و به EUR پرداخت میشوند — یک مرجع از چکاوت تا ردیف بانکی.
ویژگی‌ها
checkout میزبانیشده کارت، Apple Pay، Google Pay و USDC را کنار هم می‌گذارد. سفارش 9F21-0716 سمت چپ است — سه قلم، کارمزد پردازش €0.50 و مبلغ قابل پرداخت €49.00 — و انتخاب روش سمت راست. مشتری انتخاب میکند؛ صفحه خودش را وفق میدهد؛ پذیرنده فقط یک بار یکپارچهسازی کرده است.
همان URL چکاوت در چیدمان گوشی بازچینی میشود: سفارش به یک نوار خلاصه جمع میشود، دکمه‌های روشها سر جایشان می‌مانند و فرم کارت برچسب‌هایش را حفظ میکند. آنچه روی دسکتاپ ارائه میشود روی موبایل هم ارائه میشود — و اگر بخواهید پرداخت بهجای مرورگر درون اپ خودتان انجام شود، SDKهای iOS و Android همان checkout را روی همان سفارش بهصورت بومی نمایش می‌دهند.
پرداخت با USDC به رسیدی ختم میشود که حسابدار پذیرنده میتواند بخواند. روش: 52.95 USDC روی Base →︎ تسویه به EUR، با نرخ چاپ‌شده روی رسید، 1 EUR = 1.0807 USDC. شناسه‌ی پیگیری 9F21-0716، ایمیل‌شده برای مشتری و آماده‌ی دانلود در همان لحظه. مشتری کریپتو پرداخت کرد؛ دفاتر €49.00 می‌گویند.
لینک‌های پرداخت یک میز کار واقعی دارند: 8 لینک برای Arc Studio SRL در وضعیت‌های پرداخت‌شده، فعال و منقضی، با مبلغ، تعداد پرداخت و وضعیت در هر ردیف. کارتهای بالا امتیاز را نشان می‌دهند — 4 لینک فعال، €2,304.50 وصول‌شده در این ماه از 18 پرداخت لینکی، €49.00 پرداخت‌شده‌ی امروز. بساز، جست‌وجو کن، خروجی بگیر، تمام.
بازپرداخت به سفارش اشاره میکند، نه به روش پرداخت. کشو روی 9F21-0716 باز میشود با مبلغ از پیش تنظیم‌شده‌ی کامل €49.00، دلیل الزامی و یادداشت اختیاری که در خروجی‌ها و روی رسید مشتری می‌نشیند. وجه به‌طور خودکار از همان مسیر پرداخت اولیه برمیگردد — بازپرداخت کارت به کارت، سفارشهای USDC بهصورت تسویه‌ی EUR — معمولاً در 1 تا 3 روز کاری.
برندینگ یک صفحه‌ی تنظیمات است، نه یک پروژه‌ی خدماتی: لوگو آپلود کنید، رنگ‌های تأکید، متن و سطح را تعیین کنید، فونت و گردی گوشهها را انتخاب کنید. پیشنمایش زنده، checkout واقعی شما را — دسکتاپ یا موبایل — پیش از ذخیره نشان میدهد و رنگ تأکید روی فوکوس دکمه‌ی پرداخت، تیک‌های وضعیت و تب فعال اعمال میشود. آن را روی هاست checkout که همراه sandbox شما صادر میشود اجرا کنید، یا روی دامنه‌ی خودتان.
روش‌های پرداخت کلیدهایی هستند که ارائه‌دهندگانی پشتشان قرار دارند: کارت با 3-D Secure، Apple Pay و Google Pay به‌شکل دکمه‌ی کیف پول، USDC روی Ethereum، Base و Solana، انتقال بانکی SEPA با شناسه‌ی vIBAN. کنار آن‌ها، پنل تسویه قرارداد را روشن می‌گوید: مشتری پیش از تأیید تبدیل را میبیند؛ شما همیشه به EUR تسویه میکنید.
سفارش را بسازید، به صفحه‌ی میزبانیشده ریدایرکت کنید، نتیجه را دریافت کنید. Gateway رابط پرداخت، منطق روشها و رسیدها را بر عهده می‌گیرد. هیچ فرانت‌اند checkout نیست که تیم شما بسازد، وصله کند یا با تغییر روشها به‌روز نگه دارد.
همه‌چیز به سفارش وصل است، نه به روش پرداخت. سفارش 9F21-0716 اقلامش را دارد — یک اسپرینت هویت بصری €38.50، لایسنس فونت €6.00، تحویل فوری €4.00 — به‌علاوه‌ی کارمزد پردازش €0.50 و یک جمع کل. هر طور که پرداخت شود، همان شناسه است که با آن استعلام، مغایرت‌گیری و بازپرداخت میکنید.
تغییرات روشها و برندینگ برای نشست‌های جدید checkout اعمال میشود — همان‌جا که ذخیره‌شان میکنید این را می‌بینید. مشتری‌ای که وسط پرداخت است، هرگز صفحه را زیر دستش عوض‌شده نمی‌بیند.
مسیر کارت همان بخش خسته‌کننده است که حل شده: اعتبارسنجی درجا، 3-D Secure با احراز هویت قوی مشتری که در خود جریان تعبیه شده و سیاست مسیریابی خوانا دارد، و کارتهای آزمایشی جداگانه برای هر sandbox. پذیرش کریپتو هرگز جریان کارت را بدتر نمی‌کند.
کیف پول‌ها دکمه‌اند، نه پروژه. Apple Pay و Google Pay در همان صفحه به‌شکل شیت یک‌ضربه‌ای نمایش داده میشوند و با توکن دستگاه پرداخت میکنند — شماره‌ی واقعی کارت هرگز به صفحه نمی‌رسد — از همان سفارش و با همان رسید. فعال‌سازی‌شان یک کلید در صفحه‌ی روش‌هاست.
کریپتو با نرخی که در checkout نشان داده میشود قیمتگذاری و به یورو تسویه میشود. پذیرنده هرگز ناخواسته پوزیشن توکن در دست نمی‌گیرد؛ دفاتر در یک ارز می‌مانند.
روش USDC پشت یک کلید، Ethereum، Base و Solana را پوشش میدهد. مشتری روی شبکه‌ای که کیف پولش در آن است پرداخت میکند؛ سمت پذیرنده تغییری نمی‌کند.
پرداخت با انتقال، شناسه‌ی vIBAN دارد؛ پس هر پرداخت SEPA ورودی ذاتاً سفارش خودش را مشخص میکند. آن را برای مشتریانی روشن کنید که فاکتوری می‌خواهند که از بانک پرداخت شود، و مغایرت‌گیری خودکار میماند.
فراتر از کارت و کیف پول، checkout روش‌های حساب‌به‌حساب و محلی را که خریدار اروپایی انتظار دارد در خود دارد و آن‌ها را بر اساس کشور مشتری نشان میدهد، نه در یک فهرست بلند و درهم.
BNPL در همان ردیفی قرار دارد که بقیه‌ی روشها — مشتری پرداخت را تقسیم میکند، پذیرنده یک‌جا پول می‌گیرد و شناسه‌ی سفارش عوض نمیشود. یک کلید، همان رسید، همان مغایرت‌گیری.
صفحه روشها را بر اساس آنچه مشتری احتمالاً استفاده میکند مرتب میکند — کشور، زبان، دستگاه و اینکه قبلاً از شما خرید کرده یا نه — تا گزینه‌ی مرتبط اول باشد، نه چهارم.
مبلغ را به ارز مشتری نشان دهید و تبدیل را پیش از تأیید اعلام کنید، و در هر حال به EUR تسویه کنید. مشتری عددی آشنا میبیند؛ دفتر شما فقط یک عدد دارد.
صفحه‌ی میزبانیشده برچسب‌ها، خطاها و رسیدها را بومی‌سازی میکند. هیچ‌کس پرداخت را رها نمی‌کند چون دکمه به زبان اشتباهی بوده است.
مشتری بازگشتی با کارت ذخیرهشده با یک ضربه پرداخت میکند. کارت در سمت ما نگهداری میشود و با توکن ارجاع داده میشود؛ پس سیستمهای شما یک ارجاع ذخیره میکنند، نه PAN — و خرید دوم از اولی کوتاه‌تر است.
پرداختهای دوره‌ای طبق زمان‌بندی‌ای که شما تعریف میکنید — مبلغ، بازه، شروع و پایان — روی کارت توکنی اجرا میشوند. هر دوره سفارش و رسید خودش را دارد؛ پس اشتراک هم مثل بقیه خطبهخط مغایرت‌گیری میشود.
رد نرم یک پرداخت دوره‌ای بهجای حذف شدن طبق زمانبندی دوباره تلاش میشود و مشتری فقط وقتی مطلع میشود که لازم باشد. تمدیدهای ناموفق دیگر ریزش بی‌صدا نیستند.
کارتهای ذخیرهشده بهصورت توکن شبکه نگهداری میشوند و با صدور مجدد و انقضا همراه دارنده‌ی کارت می‌مانند. اشتراکی که با تعویض کارت قطع می‌شد، به شارژ ادامه میدهد.
سفارشها با API و کلیدهای idempotency ساخته میشوند — درخواست تکراری همان نتیجه‌ی اول را برمیگرداند، نه شارژ دوم — و بخش توسعه‌دهندگان کلیدها و مستندات را در خود دارد. checkout میزبانیشده است؛ یکپارچهسازی مشتی endpoint است که مستنداتش کنار تنظیمات قرار دارد.
بک‌اند شما لحظه‌ی وقوع پرداخت‌ها را می‌شنود: رویدادهای وبهوک امضاشده روی چرخه‌ی عمر سفارش — پرداخت‌شده، ناموفق، بازپرداخت‌شده — با راستی‌آزمایی امضا در سمت شما و محافظت در برابر replay در سمت ما.
اپ‌های بومی همان checkout را درون اپ نمایش می‌دهند، بهجای آنکه کاربر را به مرورگر بفرستند. SDK منطق روشها، شیت کیف پول‌ها و 3-D Secure را با خود دارد؛ سفارش و رسید همان‌هایی هستند که بک‌اند شما از قبل می‌شناسد.
افزونههای سبد خرید یک فروشگاه موجود را بدون توسعه‌دهنده به Gateway وصل میکنند — نصب، چسباندن کلیدها، یک پرداخت آزمایشی. سفارشها همان‌جا در همان بک‌آفیس می‌نشینند که سفارشهای API.
وقتی پرداخت باید درون چیدمان خودتان انجام شود، فیلدهای پرداخت را مستقیم جاسازی کنید: ورودی‌ها در سمت ما میزبانی میشوند و تحت PCI هستند، صفحه‌ی اطرافشان کاملاً مال شماست و داده‌ی کارت هرگز به سرورهای شما نمی‌رسد.
لینک میتواند پس از یک پرداخت بسته شود یا به دریافت پرداخت ادامه دهد. در دمو، صندلی کارگاه 3 پرداخت گرفته و ساعت مشاوره 6 پرداخت. لینک‌ها به‌طور پیشفرض پس از 30 روز منقضی میشوند و لینک منقضی‌شده این را صریح اعلام میکند، نه اینکه بی‌صدا خطا بدهد.
اجرای آزمایشی یکپارچهسازی روی نشست‌های تست و با کارت‌هایی انجام میشود که همراه کلیدهای sandbox صادر شده‌اند، پیش از آنکه پولی واقعاً جابهجا شود. جریانها یکسان‌اند، پس هرچه در تست قبول شود همان در تولید اجرا میشود.
ترافیک کارت از یک سیاست مسیریابی پیروی میکند که با مفاهیم آشنا نوشته شده است: برند کارت، کشور صادرکننده، ارز، مبلغ. نه یک جعبه سیاه. میتوانید در همان صفحهای که پرداخت را می‌بینید، ببینید از کدام مسیر عبور کرده است.
رد نرم (soft decline) در همان نشست checkout و از مسیری جایگزین دوباره امتحان میشود، پیش از آنکه مشتری خطایی ببیند. بیشتر پرداختهای نجات‌یافته پرداخت‌هایی‌اند که مشتری هرگز نفهمید در خطر بودند.
کدهای خام صادرکننده به دلایلی ترجمه میشوند که اپراتور بتواند روی آن‌ها اقدام کند، مثل کارت منقضی، موجودی ناکافی، ریسک صادرکننده. این دلایل گروه‌بندی هم میشوند تا الگوی میان چندین پرداخت به‌عنوان یک الگو دیده شود.
بیشتر پرداخت‌ها فقط با سیگنال‌های دستگاه و رفتار کاربر تأیید میشوند و چالش تأیید اضافی فقط وقتی ظاهر میشود که سیاست ایجاب کند. سیاست را شما تعیین میکنید: همیشه، مبتنی بر ریسک، یا معاف جایی که قوانین اجازه می‌دهند. صفحه هاست‌شده بقیه جریان را پیش میبرد.
Checkout، رسید و تسویه شناسه سفارش یکسانی دارند. هر کس 9F21-0716 را جست‌وجو کند یک ردیف €49.00 پیدا میکند، نه یک رکورد کارت در یک سیستم و یک رکورد کریپتو در سیستمی دیگر.
تسویه همان‌جا که تنظیمش میکنید به‌روشنی نوشته میشود: تبدیل خودکار به EUR، تسویه به RO49 •••• 0421، واریز روزانه ساعت 23:00. عددی که حسابدار فردا میبیند، امروز روی صفحهای تعیین میشود که پذیرنده میتواند بخواند.
هر واریز به سفارش‌هایی باز میشود که آن را تأمین کرده‌اند، با کارمزدهای تفکیک‌شده. ردیف بانکی با فهرستی که میتوانید خروجی بگیرید می‌خواند، پس بستن حساب پایان ماه یک جست‌وجوی ساده است، نه یک تحقیق.
مبلغ بازپرداخت تا سقف مبلغ اولیه قابل ویرایش است. پنل حداکثر مبلغ را نشان میدهد و هر مقدار کمتر را بازپرداخت جزئی در نظر می‌گیرد. ده بازپرداخت جزئی برای یک سفارش هم باز با یک شناسه مغایرت‌گیری میشوند.
هر بازپرداخت یک دلیل اجباری و یک یادداشت اختیاری دارد و یادداشت همراه آن می‌رود: در خروجی‌ها و روی رسید مشتری دیده میشود. شش ماه بعد، کسی لازم نیست به یاد بیاورد چرا برای سفارش 9F21-0716 جبران انجام شد.
رسیدها به ایمیل مشتری ارسال میشوند و همان لحظه قابل دانلودند. رسید بازپرداخت هم همین مسیر را می‌رود. پذیرنده هیچ‌وقت لازم نیست قالب رسید بسازد.
لغو پیش از بسته شدن بسته (batch) روز، بلوکه‌سازی مجوز را آزاد میکند و هیچ پولی جابهجا نمیشود: نه بازپرداخت، نه کارمزد، نه چیزی در صورتحساب مشتری که نیاز به توضیح داشته باشد.
پرداختهای کارتی با 3-D Secure و تحت سیاست مسیریابی قابل‌خواندن اجرا میشوند. پرداختهای کیف پول احراز هویت خود دستگاه را همراه دارند و رویدادهای webhook پیش از اعتماد، امضایشان بررسی میشود.
قوانین غربالگری مثل جمله خوانده میشوند، مثلاً مبلغ بیش از X از کشور Y با کارت بار اول، و بر اساس آن‌ها عمل میکنند: اجازه، چالش یا مسدودسازی. فهرست کارتها، ایمیل‌ها و آدرس‌های مطمئن و مسدود هم پشت همین صفحه است.
تلاش‌های مکرر از یک کارت، یک دستگاه یا یک آدرس را قوانین نرخ (rate rules) شناسایی میکنند، نه اینکه کسی بعداً متوجه شود. سیگنال‌ها روی خود پرداخت نشان داده میشوند، نه اینکه زیر یک امتیاز پنهان شوند.
chargeback همراه با سفارش مربوطه باز میشود: نتیجه احراز، نتیجه 3-D Secure، رسید، تحویل، سابقه بازپرداخت. از همین صفحه پاسخ بدهید و بسته مدارک از روی سابقه ثبتشده ساخته میشود، نه از روی حافظه.
صفحهای که اطلاعات کارت را می‌گیرد مال ماست، تحت PCI و میزبانیشده. چه مشتری روی دامنه ما پرداخت کند، چه دامنه شما، چه داخل اپ شما، سرورهای شما یک توکن و یک شناسه سفارش می‌بینند، نه شماره کارت.
دادههای پرداخت در حالت ذخیره رمزگذاری میشوند و در اتحادیه اروپا پردازش میشوند. برای پذیرنده اروپایی، محل نگهداری داده یک پاسخ است، نه یک پاورقی.
بازپرداخت، تغییر روش، تغییر برندینگ، چرخش کلید: هرکدام با نام اپراتور، زمان دقیق و دلیل در یک سابقه حسابرسی ثبت میشود. اقدامات سطح بالا پیش از اجرا دلیل می‌خواهند.
مالی واریزها را میبیند، پشتیبانی سفارشها را میبیند و بازپرداخت انجام میدهد، توسعه‌دهندگان کلیدها و لاگ‌ها را می‌بینند. دسترسی بر اساس نقش داده میشود، نه با اشتراک یک حساب کاربری.
پرداخت‌کنندگان در نمای مشتریان جمع میشوند: چه کسی پرداخت کرده، هر چند وقت، با چه روشی. به این ترتیب مشتری تکراری یک رکورد است، نه تصادفی از ایمیل‌های هم‌خوان در خروجی‌ها.
پرداخت را با لینک یا شناسه از کادر جست‌وجو پیدا کنید و هر وقت دفاتر لازم داشتند، نمای فعلی را به CSV خروجی بگیرید. بک‌آفیس با این فرض ساخته شده که حسابدار حتماً می‌پرسد.
حجم، نرخ تأیید، بازپرداخت‌ها و ترکیب روشها در بازه‌ای که انتخاب میکنید. کافی برای پاسخ به اینکه پول کجا رفت و ترویج کدام روش ارزش دارد، بدون اینکه چیزی را خروجی بگیرید.
Gateway به Protocore Center وصل میشود: بک‌آفیس لینک‌های پرداخت در آن، هر لینک را با انتقال تسویه‌اش نشان میدهد و یک لینک open-in-Tracer برای ردگیری کامل دارد. تیم عملیات شما از checkout تا دفتر کل را شفاف میبیند.
checkout دمو متعلق به Arc Studio SRL است: نام آن‌ها، نشان آن‌ها، سفارش آن‌ها. میتوانید با فوتر powered-by-Protocore اجرایش کنید یا کاملاً whitelabel. در هر دو حالت صفحه مال شما به نظر میرسد.
FAQ
پرداختهای کارتی دو مرحله دارند: اتوریزیشن مبلغ را هنگام خرید بلوکه میکند و تسویه آن را منتقل میکند. Gateway بهصورت خودکار capture میکند، سفارشهای هر روز را در یک بچ میبندد و در ساعت تسویه روزانهای که در تنظیمات مشخص کردهاید، به EUR به حساب ثبتشده شما پرداخت میکند.
زمان. پیش از تسویه، لغو فقط بلوکه اتوریزیشن را آزاد میکند و پولی جابهجا نمیشود. بعد از تسویه، اسمش بازپرداخت است — روی همان سفارش، کامل یا جزئی، از مسیر روش پرداخت اصلی برمیگردد و دلیلش ثبت میشود.
بهصورت سیاست، نه اصطکاک پیشفرض. بیشتر جریانها فقط با دادههای دستگاه و رفتار کاربر عبور میکنند؛ چالش تأیید اضافی تنها وقتی نمایش داده میشود که سیاست مسیریابی بخواهد. سیاست را شما تعیین میکنید و صفحه میزبانیشده جریان را پیش میبرد.
یورو. مبلغ USDC پیش از تأیید مشتری در صفحه قیمتگذاری میشود، با نرخ اعلامشده به EUR تسویه میشود و رسید تبدیل را ثبت میکند. چکاوت، رسید و تسویه یک مرجع سفارش مشترک دارند — شما هرگز موجودی توکن نگه نمیدارید.
سفارش، پرونده مستندات شماست. نتیجه اتوریزیشن، رسید، سابقه بازپرداخت و وضعیت ارسال وبهوک همگی به یک مرجع وصلاند — یک جستجو به اعتراض پاسخ میدهد و بازپرداخت از همان صفحه اغلب سریعترین راهحل است.
خیر. سفارشها با کلید idempotency ساخته میشوند، پس درخواست تکراری بهجای برداشت دوم، همان نتیجه اول را برمیگرداند — و وبهوکها در مسیر بازگشت امضا میشوند و در برابر بازپخش محافظت دارند.
صفحهای که جزئیات کارت را دریافت میکند مال ماست — میزبانیشده و مشمول PCI در سمت ما. سرورهای شما فقط یک توکن و مرجع سفارش دریافت میکنند، نه شماره کارت. این موضوع چه مشتری روی دامنه ما پرداخت کند، چه روی دامنه شما، چه در اپ شما، و چه از طریق فیلدهای پرداخت جاسازیشده در طراحی خودتان، برقرار است.
بله. میتوانید آن را روی هاست چکاوتی که همراه sandbox میگیرید، روی دامنه خودتان یا جاسازیشده در صفحه خودتان با فیلدهای پرداخت میزبانیشده اجرا کنید. برندینگ — لوگو، رنگها، فونت، گوشهها — یک صفحه تنظیمات با پیشنمایش زنده است و فوتر به انتخاب شما با نشان «powered by» یا کاملاً whitelabel است.
کارتها در سمت ما بهصورت توکن شبکه نگهداری میشوند و سیستمهای شما فقط یک مرجع دارند. اشتراک طبق زمانبندی شما از همان توکن برداشت میکند، رد شدنهای موقت را خودش دوباره تلاش میکند و با صدور مجدد کارت هم دنبال دارنده کارت میماند. هر دوره سفارش و رسید جداگانه دارد، پس اشتراک خطبهخط تطبیق میشود.
مبلغ را به ارز خودش میبیند، با اعلام تبدیل پیش از تأیید، و چکاوت به زبان خودش است. شما همچنان به EUR تسویه میکنید. اصل همان USDC است: سمت مشتری تطبیق پیدا میکند و دفتر کل شما در یک ارز میماند.
سهم شما یک مطالبه یورویی است. Gateway بخش کریپتو را انجام میدهد — قیمتگذاری، پرداخت آنچین و تبدیل — و آنچه به حساب شما میرسد EUR از یک مسیر تسویه تحت مقررات است که با نرخ اعمالشده روی رسید ثبت میشود. شما نه توکن نگهداری میکنید، نه کیف پول اداره میکنید، نه موجودی دارید، چون تبدیل پیش از تسویه انجام میشود، نه بعد از آن.
لینک پرداخت همان روزی که حساب دارید کار میکند. یکپارچهسازی API یعنی یک endpoint سفارش، یک ریدایرکت و یک وبهوک امضاشده — بیشتر تیمها همان هفته آن را در محیط تست اجرا میکنند و پس از یک پرداخت آزمایشی سرتاسری به محیط واقعی میروند. افزونههای فروشگاهی اصلاً به توسعه نیاز ندارند.
بله — هر دو را موازی اجرا کنید. سفارشهای جدید را به Gateway بفرستید تا ارائهدهنده قبلی تسویه و بازپرداخت سفارشهای خودش را تمام کند، چون بازپرداخت همیشه از همان مسیری برمیگردد که پرداخت را گرفته است. کارتهای ذخیرهشده بهصورت توکن منتقل میشوند، پس مشترکین مجبور نیستند دوباره اطلاعات کارت را وارد کنند.
فراخوانی سفارش و هندلر وبهوک. صفحه پرداخت، منطق روشها، برگههای کیف پول، 3-D Secure، رسیدها و هر روش جدیدی که بعداً اضافه شود، بهروزرسانیاش با ماست — فلسفه چکاوت میزبانیشده همین است.
قیمتگذاری
بدون هزینه پلتفرم شروع کنید — Gateway از پرداخت‌هایی که پردازش میکند درآمد دارد، پس هزینه با حجم عبوری از checkout هماهنگ است.
checkout را با برند خودتان اجرا کنید، با لایسنسی متناسب با ریل‌هایی که فعال میکنید و توان عملیاتی که برنامه‌ریزی کردهاید.
برند شما روی صفحه پرداخت، ریل‌های ما در زیرساخت، با راهبری ما — دامنه کار بر اساس روش‌های پرداختی است که روشن میکنید.
هزینه با حجم عبوری از checkout و ریل‌های فعال‌شده — تسویه کارت، کیف پول و USDC — هماهنگ است. مستقل یا کاملاً whitelabel.
ارزیابی
مثال کاربردی را با شما اجرا می‌کنیم — Arc Studio SRL، سفارش 9F21-0716 — با پرداخت از طریق کارت، کیف پول و USDC، و بک‌آفیس پذیرنده را پشت آن نشان می‌دهیم.
یک پذیرنده آزمایشی با کلیدهای API تا تیم شما بتواند سفارش بسازد، checkout میزبانیشده را اجرا کند و نتایج امضاشده را سرتاسری دریافت کند.
API سفارش، webhook مربوط به order.paid و راهنمای یکپارچهسازی — هر آنچه لازم است تا بهجای ساختن checkout، آن را به Gateway وصل کنید.
صفحه میزبانیشده با لوگو، رنگها و فونت شما، تا پیش از راهاندازی، checkout خودتان را ببینید.
مطالعه بیشتر
مستقل یا whitelabel — برند شما روی checkout، ریل‌های ما در زیرساخت.
PoS مدل سفارش Gateway را در فروشگاه فیزیکی به کار میبرد، vIBAN به سفارشهای پرداخت بانکی آن مرجع خودشناس میدهد، Chain پرداختهای USDC آن را به EUR تسویه میکند، Center کنسول اپراتور پشت چکاوت است و Agents همین مدل سفارش را برای پرداخت‌هایی که نرم‌افزار تحت سیاست انسانی آغاز میکند به کار می‌گیرد.
همه آنچه در بالا آمده در دموهای production اجرا میشود و می‌توانیم قدم‌به‌قدم نشانتان دهیم: مستقل، whitelabel یا بهصورت یک پلتفرم. بگویید چه می‌سازید تا کوتاه‌ترین مسیر را نشانتان دهیم.
