UnoPayv1.0.0
  1. خانه
  2. چرخه حیات پرداخت

مفاهیم پایه

چرخه حیات پرداخت

پنج بازیگر، چهار پرش شبکه. UnoPay دو تای آن‌ها را پوشش می‌دهد و دو میانی را به پرداخت‌کننده می‌سپارد.

سرور شما

۱ · createPayment POST {baseUrl}/v4/payment/request.json — مبلغ به ریال تبدیل می‌شود، merchant_id و callback_url بیرون می‌روند و کل آبجکت metadata هم همراه می‌آید

زرین‌پال

۲ · درگاه کد ۱۰۰ می‌دهد یک آتوریتی برمی‌گردد؛ هر چیزی جز کد ۱۰۰ به GatewayProviderError با پاسخ روی cause تبدیل می‌شود

پرداخت‌کننده

۳ · ریدایرکت به StartPay ریدایرکت را کد شما انجام می‌دهد؛ تا وقتی پرداخت‌کننده در صفحه خود زرین‌پال تمام نکند، کسی تسویه نمی‌کند

زرین‌پال

۴ · کال‌بک به callbackUrl یک GET با Authority و Status (OK یا NOK)؛ پرداخت‌کننده‌ای که پرداخت را رها کند اصلاً این را تولید نمی‌کند

سرور شما

۵ · verifyCallback POST {baseUrl}/v4/payment/verify.json — کد ۱۰۰ یا ۱۰۱ یعنی تسویه شد؛ هر چیز دیگری یک بازگشت عادی با isSuccessful برابر false است، نه استثنا

تسویه در گام پنج اتفاق می‌افتد، نه گام یک

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

transactionId وسط کار معنا عوض می‌کند

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

transactionId در هر مرحله چه چیزی دارد
مرحله فیلد مقدار دارد
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.