مستندات SimLab / راهنمای درگاه‌ها

فهرست مستندات
آماده شبیه‌سازیREST v4

مستندات زرین‌پال

پروفایل محدود ZARINPAL_REST_V4 خرید ریالی را شبیه‌سازی می‌کند. این درگاه آزمایشی به پرداخت واقعی اشتراک SimLab متصل نیست و گواهی سازگاری با همه پذیرندگان زرین‌پال نیست. merchant_id و SimLabMerchantProof ساختگی را فقط در سرور پذیرنده نگه دارید.

مسیرهای اتصال

BASE=https://<simlab-host>/api/sandbox/zarinpal/<connection-id>
REQUEST=$BASE/pg/v4/payment/request.json
START=$BASE/pg/StartPay/<authority>
VERIFY=$BASE/pg/v4/payment/verify.json
INQUIRY=$BASE/pg/v4/payment/inquiry.json

درخواست و بازگشت

درخواست JSON شامل merchant_id، amount ریالی حداقل ۱۰۰۰، callback_url ایمن و description است. هدر X-SimLab-Merchant-Proof فقط برای درخواست‌های سروری است. پاسخ موفق data.code=100 و authority دارد. هر درخواست معتبر، حتی با محتوای یکسان، پرداخت مستقلی می‌سازد چون این پروفایل شناسه سفارش اجباری در پیام فنی ندارد. صفحه آزمایشی اطلاعات کارت نمی‌گیرد و مرورگر با GET شامل Authority و Status=OK یا NOK بازمی‌گردد. این بازگشت فقط راهنما است.

تأیید و استعلام

سرور پذیرنده تأیید را با merchant_id، authority، مبلغ اصلی و proof فراخوانی می‌کند. data.code=100 موفقیت نخست و 101 تأیید تکراری است؛ تکرار تراکنش یا پرداخت جدید نمی‌سازد. استعلام وضعیت فعلی را در فیلد status مخصوص پروفایل SimLab بدون تغییر پرداخت برمی‌گرداند. خطاهای SIMLAB_ نیز قرارداد همین شبیه‌ساز هستند، نه کدهای تأییدشده درگاه واقعی. پنجره آغاز ده دقیقه و تأیید سی دقیقه پس از پرداخت، سیاست SimLab است. کارت واقعی، برگشت وجه و ارسال به زرین‌پال واقعی پشتیبانی نمی‌شوند.

نمونه درخواست سروری

مقدارهای آغازشده با YOUR_ و جای‌نگهدارهای امضا یا پاکت رمزنگاری را پیش از ارسال با اعتبارنامه ساختگی اتصال خود و محاسبه صحیح جایگزین کنید. این نمونه اطلاعات هیچ حسابی را شامل نمی‌شود. زمان و تاریخ درخواست را هنگام ارسال تازه کنید و امضا را از روی همان بدنه نهایی بسازید. نشانی بازگشت نمونه را هم با نشانی سایت آزمایشی خود عوض کنید.

روش، مسیر و هدرهای درخواست

POST /pg/v4/payment/request.json
Content-Type: application/json
X-SimLab-Merchant-Proof: YOUR_SimLabMerchantProof
بدنه درخواست آزمایشی

{
  "merchant_id": "YOUR_merchant_id",
  "amount": 1000,
  "callback_url": "https://merchant.example.test/payment/callback",
  "description": "SimLab test payment"
}

چک‌لیست اتصال و نهایی‌سازی

شناسه اتصال و اعتبارنامه ساختگی را از صفحه همین درگاه در داشبورد بردارید. مسیر سرویس را به SimLab تغییر دهید؛ نشانی بازگشت باید متعلق به سایت آزمایشی شما و در مرورگر قابل دسترس باشد. حروف بزرگ و کوچک نام فیلدها، روش HTTP و نوع بدنه را دقیقاً مطابق همین پروفایل نگه دارید.

شروع صفحه پرداخت
authority پاسخ را با GET به /pg/StartPay/<authority> در مرورگر ببرید.
بازگشت به سایت
GET مرورگر با Authority و Status=OK/NOK؛ موقت است.
اطلاعاتی که باید نگه دارید
authority و مبلغ اصلی را نگه دارید و Authority بازگشت را تطبیق دهید.
معیار نهایی موفقیت
POST /pg/v4/payment/verify.json با merchant_id، authority، amount و proof؛ data.code=100 نخست و 101 تکرار موفق نهایی است.
درخواست تکراری
هر Request معتبر پرداخت مستقل می‌سازد؛ Verify تکراری پرداخت جدید نمی‌سازد.
مهلت‌ها
Start ده دقیقه؛ Verify سی دقیقه پس از پرداخت.
عملیات قابل استفاده
ایجاد درخواست، صفحه پرداخت، تأیید و استعلام وضعیت فعلی
خارج از محدوده
بازپرداخت، برگشت و کارت واقعی

خطا در کدام مرحله رخ داده است؟

  • پیش از دریافت توکن: مسیر، نوع بدنه، مبلغ و واحد پول، اعتبارنامه و امضای درخواست را بررسی کنید. پاسخ HTTP موفق به‌تنهایی کافی نیست؛ کد نتیجه داخل بدنه نیز باید مطابق قرارداد موفق باشد.
  • هنگام ورود به صفحه پرداخت: توکن همان اتصال، روش GET یا POST و اعتبار زمانی آن را بررسی کنید. کلید سروری را در فرم مرورگر یا نشانی صفحه قرار ندهید.
  • هنگام بازگشت: نشانی ثبت‌شده، روش فرم یا پارامترهای نشانی و تطابق شناسه سفارش را بررسی کنید. ایجاد فرم بازگشت به معنی دریافت آن توسط سایت شما نیست؛ مرورگر ممکن است بسته شود.
  • هنگام تأیید: مرجع، مبلغ و پایانه را از سفارش ذخیره‌شده بخوانید و با پاسخ تطبیق دهید. ورودی بازگشت مرورگر قابل دست‌کاری است. خطای شبکه یا پایان مهلت را به پرداخت موفق تبدیل نکنید.
  • پس از تأیید: اگر این پروفایل تسویه یا تأیید نهایی جدا دارد، آن را اجرا کنید. تکرار درخواست را طبق قواعد همین درگاه انجام دهید؛ برای همه درگاه‌ها قاعده تکرار یکسان وجود ندارد.

در تاریخچه درخواست‌ها، مرحله، کد HTTP و نتیجه فنی را کنار تراکنش مرتبط ببینید. شناسه درخواست برای پیگیری مفید است؛ کلید، رمز، توکن دسترسی و امضا را در پیام پشتیبانی قرار ندهید. رد شدن دسترسی ممکن است به حساب، اشتراک، اتصال یا اعتبارنامه مربوط باشد؛ پاسخ عمومی عمداً علت خصوصی حساب را افشا نمی‌کند.

سناریوهای آزمایش و دسترسی

درخواست ایجاد پرداخت را از سرور سایت خود بفرستید. در صفحه‌ی پرداخت آزمایشی، نتیجه‌ی دلخواه را همان‌جا انتخاب کنید: موفقیت، انصراف، خطای درگاه یا پایان مهلت. نتیجه از قبل انتخاب نمی‌شود. سپس بازگشت و تأیید سروری را در جزئیات همان پرداخت بررسی کنید.

پیش‌نمایش ادمین ورودی مبلغ، سفارش و خطای دلخواه دارد و حالت‌های نمایشی بیشتری را نشان می‌دهد؛ تراکنش یا بازگشت واقعی نمی‌سازد. حالت‌هایی مانند موجودی ناکافی یا رمز نامعتبر در آن، نمایش رابط‌اند و نباید به‌عنوان کد قطعی قرارداد همه درگاه‌ها تعبیر شوند. با پایان اشتراک، تعلیق حساب یا غیرفعال شدن اتصال، عملیات جدید و بازپخش درخواست‌های قبلی دوباره کنترل و ممکن است رد شوند؛ تاریخچه متعلق به شما خواندنی می‌ماند.

باز کردن اتصال و بخش آزمایش این درگاه · تاریخچه درخواست‌ها و تراکنش‌ها · راهنمای اولین اتصال

مرز ایمنی

هیچ اعتبارنامه محیط عملیاتی، کلید خصوصی یا اطلاعات کارت واقعی را برای این شبیه‌ساز استفاده نکنید. این قرارداد محدود SimLab ادعای گواهی همه نسخه‌های فعلی بانک نیست.

نمای عمومی درگاه