مستندات آسان پرداخت پرشین
پروفایل محدود ASANPARDAKHT_IPG_REST_V1 فقط خرید استاندارد را شبیه‌سازی می‌کند. قرارداد از راهنمای تاریخی نسخه ۱٫۶ آسان پرداخت و انتخاب‌های سازگاری SimLab ساخته شده است؛ گواهی درگاه زنده نیست. شناسه پذیرنده و usr و pwd ساختگی مخصوص اتصال را از داشبورد بگیرید و رمزها را فقط در سرور پذیرنده نگه دارید.
BASE=https://<simlab-host>/api/sandbox/asanpardakht/<connection-id>
TIME=$BASE/v1/Time
TOKEN=$BASE/v1/Token
PAYMENT_POST=$BASE/
TRAN_RESULT=$BASE/v1/TranResult
VERIFY=$BASE/v1/Verify
SETTLEMENT=$BASE/v1/Settlementتوکن و بازگشت
توکن یک درخواست JSON با serviceTypeId برابر ۱، merchantConfigurationId، localInvoiceId عددی یکتا، amountInRials، localDate با قالب YYYYMMDD HHMMSS، additionalData، callbackURL و paymentId برابر «0» می‌پذیرد. هدرهای usr و pwd لازم‌اند. پاسخ موفق یک رشته JSON حاوی RefId است. آن را در فرم POST با نام RefId به PAYMENT_POST بفرستید. توکن در SimLab ده دقیقه اعتبار دارد. نشانی callbackURL باید شماره فاکتور را در مسیر یا پارامتر نشانی داشته باشد؛ بازگشت مرورگر با GET و بدون فیلد افزوده انجام می‌شود و اثبات پرداخت نیست.
استعلام، تأیید و تسویه
پس از بازگشت، TranResult را با merchantConfigurationId و localInvoiceId بخوانید و refID و amount را با سفارش ذخیره‌شده مقایسه کنید. پاسخ موفق payGateTranID مستقل از شماره فاکتور را می‌دهد. همان شناسه در بدنه JSON تأیید و سپس تسویه استفاده می‌شود؛ هر دو با هدرهای usr و pwd. تأیید فقط مرحله موقت است و تسویه موفق پرداخت را نهایی می‌کند. بازه SimLab برای TranResult از پرداخت ۴۵ دقیقه و برای تأیید و تسویه سی دقیقه است. خطای تسویه تا سه تلاش محدود همان شناسه را موقت نگه می‌دارد. عملیات کارت واقعی، تقسیم تسویه، Cancel و برگشت در این نسخه پشتیبانی نمی‌شوند.
نمونه درخواست سروری
مقدارهای آغازشده با YOUR_ و جای‌نگهدارهای امضا یا پاکت رمزنگاری را پیش از ارسال با اعتبارنامه ساختگی اتصال خود و محاسبه صحیح جایگزین کنید. این نمونه اطلاعات هیچ حسابی را شامل نمی‌شود. زمان و تاریخ درخواست را هنگام ارسال تازه کنید و امضا را از روی همان بدنه نهایی بسازید. نشانی بازگشت نمونه را هم با نشانی سایت آزمایشی خود عوض کنید.
POST /v1/Token
Content-Type: application/json
usr: YOUR_usr
pwd: YOUR_pwd{
"serviceTypeId": 1,
"merchantConfigurationId": "YOUR_merchantConfigurationId",
"localInvoiceId": "9001",
"amountInRials": "250000",
"localDate": "20261005 155509",
"additionalData": "",
"callbackURL": "https://merchant.example.test/payment/callback?invoice=9001",
"paymentId": "0"
}چک‌لیست اتصال و نهایی‌سازی
شناسه اتصال و اعتبارنامه ساختگی را از صفحه همین درگاه در داشبورد بردارید. مسیر سرویس را به SimLab تغییر دهید؛ نشانی بازگشت باید متعلق به سایت آزمایشی شما و در مرورگر قابل دسترس باشد. حروف بزرگ و کوچک نام فیلدها، روش HTTP و نوع بدنه را دقیقاً مطابق همین پروفایل نگه دارید.
- شروع صفحه پرداخت
- RefId پاسخ را با فرم POST به / بفرستید.
- بازگشت به سایت
- GET مرورگر به callbackURL بدون فیلد افزوده؛ به تنهایی اثبات پرداخت نیست.
- اطلاعاتی که باید نگه دارید
- localInvoiceId، مبلغ و RefId را نگه دارید؛ TranResult را با فاکتور بخوانید و مبلغ/payGateTranID را تطبیق دهید.
- معیار نهایی موفقیت
- POST /v1/Verify و سپس /v1/Settlement با payGateTranId؛ فقط Settlement موفق نهایی است.
- درخواست تکراری
- فاکتور/درخواست یکسان همان توکن را می‌دهد؛ تغییر داده تعارض است. Settlement ناموفق تا سه تلاش همان هویت موقت می‌ماند.
- مهلت‌ها
- Token ده دقیقه؛ TranResult تا ۴۵ دقیقه، Verify و Settlement تا ۳۰ دقیقه پس از پرداخت.
- عملیات قابل استفاده
- دریافت شناسه، دریافت نتیجه، تأیید و تسویه
- خارج از محدوده
- لغو درخواست، برگشت، بازپرداخت، تسهیم و کارت واقعی
خطا در کدام مرحله رخ داده است؟
- پیش از دریافت توکن: مسیر، نوع بدنه، مبلغ و واحد پول، اعتبارنامه و امضای درخواست را بررسی کنید. پاسخ HTTP موفق به‌تنهایی کافی نیست؛ کد نتیجه داخل بدنه نیز باید مطابق قرارداد موفق باشد.
- هنگام ورود به صفحه پرداخت: توکن همان اتصال، روش GET یا POST و اعتبار زمانی آن را بررسی کنید. کلید سروری را در فرم مرورگر یا نشانی صفحه قرار ندهید.
- هنگام بازگشت: نشانی ثبت‌شده، روش فرم یا پارامترهای نشانی و تطابق شناسه سفارش را بررسی کنید. ایجاد فرم بازگشت به معنی دریافت آن توسط سایت شما نیست؛ مرورگر ممکن است بسته شود.
- هنگام تأیید: مرجع، مبلغ و پایانه را از سفارش ذخیره‌شده بخوانید و با پاسخ تطبیق دهید. ورودی بازگشت مرورگر قابل دست‌کاری است. خطای شبکه یا پایان مهلت را به پرداخت موفق تبدیل نکنید.
- پس از تأیید: اگر این پروفایل تسویه یا تأیید نهایی جدا دارد، آن را اجرا کنید. تکرار درخواست را طبق قواعد همین درگاه انجام دهید؛ برای همه درگاه‌ها قاعده تکرار یکسان وجود ندارد.
در تاریخچه درخواست‌ها، مرحله، کد HTTP و نتیجه فنی را کنار تراکنش مرتبط ببینید. شناسه درخواست برای پیگیری مفید است؛ کلید، رمز، توکن دسترسی و امضا را در پیام پشتیبانی قرار ندهید. رد شدن دسترسی ممکن است به حساب، اشتراک، اتصال یا اعتبارنامه مربوط باشد؛ پاسخ عمومی عمداً علت خصوصی حساب را افشا نمی‌کند.
سناریوهای آزمایش و دسترسی
درخواست ایجاد پرداخت را از سرور سایت خود بفرستید. در صفحه‌ی پرداخت آزمایشی، نتیجه‌ی دلخواه را همان‌جا انتخاب کنید: موفقیت، انصراف، خطای درگاه یا پایان مهلت. نتیجه از قبل انتخاب نمی‌شود. سپس بازگشت و تأیید سروری را در جزئیات همان پرداخت بررسی کنید.
پیش‌نمایش ادمین ورودی مبلغ، سفارش و خطای دلخواه دارد و حالت‌های نمایشی بیشتری را نشان می‌دهد؛ تراکنش یا بازگشت واقعی نمی‌سازد. حالت‌هایی مانند موجودی ناکافی یا رمز نامعتبر در آن، نمایش رابط‌اند و نباید به‌عنوان کد قطعی قرارداد همه درگاه‌ها تعبیر شوند. با پایان اشتراک، تعلیق حساب یا غیرفعال شدن اتصال، عملیات جدید و بازپخش درخواست‌های قبلی دوباره کنترل و ممکن است رد شوند؛ تاریخچه متعلق به شما خواندنی می‌ماند.
باز کردن اتصال و بخش آزمایش این درگاه · تاریخچه درخواست‌ها و تراکنش‌ها · راهنمای اولین اتصال
مرز ایمنی
هیچ اعتبارنامه محیط عملیاتی، کلید خصوصی یا اطلاعات کارت واقعی را برای این شبیه‌ساز استفاده نکنید. این قرارداد محدود SimLab ادعای گواهی همه نسخه‌های فعلی بانک نیست.
نمای عمومی درگاه