مرحلهٔ نامرئی قیف درآمد: چرا پرداخت قبل از تبدیل‌شدن به درآمد گم می‌شود؟

بین «کاربر قصد پرداخت دارد» و «درآمد قطعی ثبت شد» چند وضعیت مهم وجود دارد. اگر داشبورد آن‌ها را نبیند، مشتری واقعی در یک مرحلهٔ نامرئی گیر می‌کند.

قیف درآمد فقط بازدید تا خرید نیست

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

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

از شمارنده به ماشین حالت بروید

راه‌حل، افزودن یک شمارندهٔ دیگر نیست؛ باید مسیر پرداخت را به وضعیت‌های صریح تبدیل کرد. Stripe در چرخهٔ PaymentIntent وضعیت‌هایی مانند requires_payment_method، requires_confirmation، requires_action و succeeded را جدا نگه می‌دارد. محصول شما نیز باید معادل کسب‌وکاری این وضعیت‌ها را تعریف کند.

برای پرداخت دستی می‌توان از این نمونه استفاده کرد:

intent_created → instructions_shown → proof_received → awaiting_review → approved → revenue_recorded

مسیرهای rejected، expired و needs_customer_action نیز باید مشخص باشند. نام‌ها مهم‌اند، اما مهم‌تر این است که هر رکورد فقط یک وضعیت جاری و تاریخچهٔ تغییرات داشته باشد.

قابل مشاهده بودن کافی نیست؛ قابل اقدام باشد

یک جدول پر از payment pending هنوز مشکل را حل نمی‌کند. هر وضعیت میانی باید owner، next_action، due_at و reason داشته باشد. به‌جای اینکه داشبورد بگوید «هفت پرداخت در انتظار»، بگوید «سه رسید نیازمند بررسی حسابداری، دو کاربر منتظر اطلاعات بانکی و دو تلاش منقضی شده‌اند».

نمای «امروز چه چیزی به تو نیاز دارد؟» از همین منطق می‌آید. سیستم باید رکوردهایی را بالا بیاورد که مهلتشان رسیده، وضعیتشان بیش از حد مانده یا مدرک جدید گرفته‌اند.

متریک‌هایی که باید جدا بمانند

Payment intent count، proof received count، approved payment count و recognized revenue چهار عدد متفاوت‌اند. نرخ تبدیل نیز باید مرحله‌به‌مرحله محاسبه شود. ترکیب این اعداد باعث می‌شود رشد ظاهری با درآمد واقعی اشتباه گرفته شود.

دو زمان را ثبت کنید: event_time، یعنی زمان رخداد واقعی، و observed_at، یعنی زمانی که سیستم آن را دیده است. این تفاوت برای انتقال بانکی و backfill مهم است؛ ممکن است پرداخت دیروز انجام شده اما امروز وارد سیستم شده باشد.

آزمون سناریو قبل از اعتماد

با دادهٔ ساختگی دست‌کم این مسیرها را اجرا کنید: موفقیت فوری، نیاز به اقدام کاربر، ارسال رسید و تأیید دستی، رد رسید، انقضا و بازگشت از وضعیت خطا. بعد بررسی کنید هیچ مسیر بدون owner یا next_action باقی نمی‌ماند و revenue فقط در وضعیت نهایی افزایش می‌یابد.

در پایان هر روز reconciliation انجام دهید: وضعیت provider یا بانک، رکورد پرداخت و دفتر درآمد باید با هم تطبیق داده شوند. اختلاف باید هشدار بسازد، نه اینکه با مقدار پیش‌فرض پنهان شود.

پاسخ‌های کوتاه

آیا هر payment created باید درآمد شمرده شود؟

نه. ایجاد قصد پرداخت، شروع فرایند است. درآمد فقط زمانی باید شمرده شود که وضعیت نهایی و سیاست حسابداری شما آن را قطعی بداند.

بهترین وضعیت برای پرداخت دستی چیست؟

یک وضعیت صریح مانند awaiting_review یا proof_received که مالک، مهلت و اقدام بعدی داشته باشد؛ نه pending مبهم و بدون مسئول.

جمع‌بندی

مرحلهٔ نامرئی زمانی ساخته می‌شود که سیستم فقط ابتدا و انتهای پرداخت را می‌بیند. با ماشین حالت، صف اقدام و reconciliation، هر مشتری در مسیر باقی می‌ماند تا تکلیف پرداخت واقعاً مشخص شود.

منبع رسمی

Stripe: چرخهٔ PaymentIntent https://docs.stripe.com/payments/paymentintents/lifecycle