مستندات پرداخت الکترونیک پاسارگاد
پروفایل محدود PEP_DORSA1 فقط خرید Dorsa1 را برای تست شبیه‌سازی می‌کند. username، password و توکن Bearer ساختگی را فقط در سرور نگه دارید. مبلغ در این پروفایل به ریال است؛ این انتخاب SimLab است و گواهی پایانه زنده پاسارگاد نیست.
BASE=https://<simlab-host>/api/sandbox/pep/<connection-id>/dorsa1
TOKEN=$BASE/token/getToken
PURCHASE=$BASE/api/payment/purchase
INQUIRY=$BASE/api/payment/payment-inquiry
VERIFY=$BASE/api/payment/verify-transactions
CONFIRM=$BASE/api/payment/confirm-transactions
REVERSE=$BASE/api/payment/reverse-transactionsجریان خرید
با username و password ساختگی توکن بگیرید؛ پاسخ توکن را تا ۱۰ دقیقه با هدر Bearer برای سرویس‌ها بفرستید. درخواست purchase شامل amount، invoice، invoiceDate، serviceCode برابر ۸، serviceType برابر PURCHASE، callbackApi و terminalNumber است. پاسخ موفق urlId و url می‌دهد. مرورگر به url می‌رود و بدون ورود کارت نتیجه آزمایشی را انتخاب می‌کند.
بازگشت مرورگر با GET و کلیدهای پارامتر نشانی شامل invoiceId و status و در موفقیت referenceNumber و trackId انجام می‌شود. SimLab درخواست سروری به پذیرنده ارسال نمی‌کند. بازگشت به‌تنهایی اثبات پرداخت نیست؛ پذیرنده باید از سرور خود استعلام و سپس تأیید را فراخوانی کند.
تأیید و برگشت
تأیید موقت است. پس از تأیید موفق، Confirm پرداخت را نهایی می‌کند یا برگشت پیش از Confirm آن را برمی‌گرداند. Confirm برگشت‌ناپذیر است. لینک پرداخت در SimLab تا ۲۰ دقیقه از ایجاد و تأیید، Confirm یا برگشت تا ۲۵ دقیقه از پرداخت آزمایشی معتبرند. این نسخه فقط زیرمجموعه محدود رفتار Dorsa1 را شبیه‌سازی می‌کند؛ API قدیمی RSA، پرداخت واقعی و داده کارت ندارد.
نمونه درخواست سروری
مقدارهای آغازشده با YOUR_ و جای‌نگهدارهای امضا یا پاکت رمزنگاری را پیش از ارسال با اعتبارنامه ساختگی اتصال خود و محاسبه صحیح جایگزین کنید. این نمونه اطلاعات هیچ حسابی را شامل نمی‌شود. زمان و تاریخ درخواست را هنگام ارسال تازه کنید و امضا را از روی همان بدنه نهایی بسازید. نشانی بازگشت نمونه را هم با نشانی سایت آزمایشی خود عوض کنید.
پاسخ این درخواست Bearer ده‌دقیقه‌ای است. سپس POST /dorsa1/api/payment/purchase با amount، invoice، invoiceDate جلالی، serviceCode=8، serviceType=PURCHASE، callbackApi و terminalNumber همین اتصال را ارسال کنید.
POST /dorsa1/token/getToken
Content-Type: application/json{
"username": "YOUR_username",
"password": "YOUR_password"
}چک‌لیست اتصال و نهایی‌سازی
شناسه اتصال و اعتبارنامه ساختگی را از صفحه همین درگاه در داشبورد بردارید. مسیر سرویس را به SimLab تغییر دهید؛ نشانی بازگشت باید متعلق به سایت آزمایشی شما و در مرورگر قابل دسترس باشد. حروف بزرگ و کوچک نام فیلدها، روش HTTP و نوع بدنه را دقیقاً مطابق همین پروفایل نگه دارید.
- شروع صفحه پرداخت
- urlId خرید را در مرورگر با GET به مسیر پرداخت پاسخ ببرید.
- بازگشت به سایت
- GET مرورگر با invoiceId، status و در موفقیت referenceNumber و trackId؛ اثبات پرداخت نیست.
- اطلاعاتی که باید نگه دارید
- invoice، amount و urlId را نگه دارید و Inquiry را با سفارش تطبیق دهید.
- معیار نهایی موفقیت
- Verify موقت است؛ ConfirmTransactions موفق نتیجه نهایی را ثبت می‌کند. Reverse پیش از Confirm مسیر جایگزین است.
- درخواست تکراری
- invoice یکسان با داده یکسان بازپخش می‌شود؛ بدنه متفاوت تعارض است.
- مهلت‌ها
- Bearer ده دقیقه؛ لینک پرداخت بیست دقیقه و Verify/Confirm/Reverse تا بیست‌وپنج دقیقه پس از پرداخت.
- عملیات قابل استفاده
- دریافت شناسه، پرداخت، استعلام، تأیید، تسویه و برگشت پیش از تسویه
- خارج از محدوده
- بازپرداخت و کارت واقعی
خطا در کدام مرحله رخ داده است؟
- پیش از دریافت توکن: مسیر، نوع بدنه، مبلغ و واحد پول، اعتبارنامه و امضای درخواست را بررسی کنید. پاسخ HTTP موفق به‌تنهایی کافی نیست؛ کد نتیجه داخل بدنه نیز باید مطابق قرارداد موفق باشد.
- هنگام ورود به صفحه پرداخت: توکن همان اتصال، روش GET یا POST و اعتبار زمانی آن را بررسی کنید. کلید سروری را در فرم مرورگر یا نشانی صفحه قرار ندهید.
- هنگام بازگشت: نشانی ثبت‌شده، روش فرم یا پارامترهای نشانی و تطابق شناسه سفارش را بررسی کنید. ایجاد فرم بازگشت به معنی دریافت آن توسط سایت شما نیست؛ مرورگر ممکن است بسته شود.
- هنگام تأیید: مرجع، مبلغ و پایانه را از سفارش ذخیره‌شده بخوانید و با پاسخ تطبیق دهید. ورودی بازگشت مرورگر قابل دست‌کاری است. خطای شبکه یا پایان مهلت را به پرداخت موفق تبدیل نکنید.
- پس از تأیید: اگر این پروفایل تسویه یا تأیید نهایی جدا دارد، آن را اجرا کنید. تکرار درخواست را طبق قواعد همین درگاه انجام دهید؛ برای همه درگاه‌ها قاعده تکرار یکسان وجود ندارد.
در تاریخچه درخواست‌ها، مرحله، کد HTTP و نتیجه فنی را کنار تراکنش مرتبط ببینید. شناسه درخواست برای پیگیری مفید است؛ کلید، رمز، توکن دسترسی و امضا را در پیام پشتیبانی قرار ندهید. رد شدن دسترسی ممکن است به حساب، اشتراک، اتصال یا اعتبارنامه مربوط باشد؛ پاسخ عمومی عمداً علت خصوصی حساب را افشا نمی‌کند.
سناریوهای آزمایش و دسترسی
درخواست ایجاد پرداخت را از سرور سایت خود بفرستید. در صفحه‌ی پرداخت آزمایشی، نتیجه‌ی دلخواه را همان‌جا انتخاب کنید: موفقیت، انصراف، خطای درگاه یا پایان مهلت. نتیجه از قبل انتخاب نمی‌شود. سپس بازگشت و تأیید سروری را در جزئیات همان پرداخت بررسی کنید.
پیش‌نمایش ادمین ورودی مبلغ، سفارش و خطای دلخواه دارد و حالت‌های نمایشی بیشتری را نشان می‌دهد؛ تراکنش یا بازگشت واقعی نمی‌سازد. حالت‌هایی مانند موجودی ناکافی یا رمز نامعتبر در آن، نمایش رابط‌اند و نباید به‌عنوان کد قطعی قرارداد همه درگاه‌ها تعبیر شوند. با پایان اشتراک، تعلیق حساب یا غیرفعال شدن اتصال، عملیات جدید و بازپخش درخواست‌های قبلی دوباره کنترل و ممکن است رد شوند؛ تاریخچه متعلق به شما خواندنی می‌ماند.
باز کردن اتصال و بخش آزمایش این درگاه · تاریخچه درخواست‌ها و تراکنش‌ها · راهنمای اولین اتصال
مرز ایمنی
هیچ اعتبارنامه محیط عملیاتی، کلید خصوصی یا اطلاعات کارت واقعی را برای این شبیه‌ساز استفاده نکنید. این قرارداد محدود SimLab ادعای گواهی همه نسخه‌های فعلی بانک نیست.
نمای عمومی درگاه