- خانه
- چرخه حیات پرداخت
مفاهیم پایه
چرخه حیات پرداخت
پنج بازیگر، چهار پرش شبکه. UnoPay دو تای آنها را پوشش میدهد و دو میانی را به پرداختکننده میسپارد.
سرور شما
POST {baseUrl}/v4/payment/request.json — مبلغ به ریال تبدیل میشود، merchant_id و callback_url بیرون میروند و کل آبجکت metadata هم همراه میآید
زرینپال
پرداختکننده
زرینپال
سرور شما
POST {baseUrl}/v4/payment/verify.json — کد ۱۰۰ یا ۱۰۱ یعنی تسویه شد؛ هر چیز دیگری یک بازگشت عادی با isSuccessful برابر false است، نه استثنا
تسویه در گام پنج اتفاق میافتد، نه گام یک
یک createPayment موفق فقط ثابت میکند درگاه صفحه پرداخت را باز کرده است. هیچ پولی جابهجا نشده. اگر فرایند شما سفارش را همان زمان ساخت پرداخت بهعنوان پرداختشده علامت بزند، پرداختکنندهای که تب را میبندد برای شما سفارش پرداختشده بدون وجه باقی میگذارد.
transactionId وسط کار معنا عوض میکند
همان نام فیلد بسته به زمان خواندن، دو مقدار متفاوت حمل میکند. این محتملترین منبع باگ حسابداری در یکپارچهسازی UnoPay است.
| مرحله | فیلد | مقدار دارد |
|---|---|---|
After createPayment |
PaymentResult.transactionId |
The authority — a pre-verification token, 36 characters, S… in sandbox |
After createPayment |
PaymentResult.providerToken |
The same authority string. ZarinPal has no separate verify token. |
After verifyCallback |
VerificationResult.transactionId |
The ref_id — the bank's reference for the settled payment |
After verifyCallback |
VerificationResult.settledAmount |
The amount echoed back from the callback, not a gateway-confirmed settlement figure |
وقتی درگاه ref_id برنگرداند، ZarinpalAdapter به آتوریتی برمیگردد، پس transactionId میتواند خاموشانه همان رشته در دو طرف باشد. اگر مرجع بانک را مشخصاً میخواهید، assert کنید که همان آتوریتی ارسالی نیست.
idempotency رایگان میآید، با یک شرط
زرینپال بار اول کد 100 و در وریفای مجدد همان آتوریتی کد 101 میدهد. آداپتور هر دو را موفق میداند، پس پرداختکنندهای که صفحه کالبک را رفرش میکند، یا مرورگری که درخواست را دوبار میفرستد، خطای کاذب تولید نمیکند. شرط سمت شماست: دو بار صدا زدن متد وریفای با idempotent کردن بهروزرسانی سفارش یکی نیست. ببینید وبهوک و idempotency.