وضعیت پرداخت، تراکنش ناموفق و بازپرداخت
تفاوت وضعیت سفارش و پرداخت را ببینید و اقدام بعدی را انتخاب کنید.
وضعیت پرداخت را مستقل از وضعیت سفارش بررسی کنید. سفارش یک درخواست خرید است؛ Payment نتیجه و مسیر مالی آن در درگاه را نگه میدارد؛ فیش واریزی رسیدی است که مشتری برای پرداخت خارج از درگاه میفرستد؛ اختلاف یا Chargeback پروندهای است که provider پس از پرداخت ثبت میکند. اینها چهار رکورد و مسیر جدا هستند. تأیید یک فیش، ثبت یک dispute و درخواست refund کارهای متفاوتیاند و هر کدام اثر مالی خاص دارند.
از پنل «پرداختها» را باز کنید. سربرگ سه میانبر دارد: «فیشهای واریزی»، «اختلافات پرداخت» و «درگاهها». بدنه اصلی فهرست تراکنشهاست و بهصورت فقطخواندنی بر اساس تاریخ جدیدتر مرتب میشود. ستونهای مهم شامل شماره سفارش، gateway، status، مبلغ، مرجع درگاه و زمان ساخت است؛ جستوجو میتواند با شماره سفارش، authority یا ref_id انجام شود. در جزئیات خام پاسخ gateway برای همه نقشها قابل مشاهده نیست؛ داده خام را از مسیر عمومی کپی نکنید.
وضعیت یک تراکنش درگاه
رکورد Payment در آناما میتواند در وضعیتهای created (ساختهشده)، redirected (فرستادهشده به درگاه)، paid (موفق)، failed (ناموفق)، reversing (درحال برگشت) یا reversed (برگشتشده) باشد. این وضعیت را با Order.payment_status یکی نگیرید: order نیز وضعیت پرداخت خود را دارد و مدل Payment نتیجه یک تلاش/تراکنش درگاه است. سفارش همچنین status گردش تجاری جداگانه دارد.
هنگام خواندن ردیف، مبلغ، نام gateway و شناسه مرجع را به همان سفارش تطبیق دهید. authority شناسه درخواست درگاه و ref_id مرجع پرداخت موفق است. هر دو ممکن است خالی باشند، پس خالیبودن مرجع را از روی مبلغ مشابه پر نکنید. کارت PAN یا hash در مدل داده حساساند و raw response برای UI عمداً پنهان است؛ آنها را در یادداشت یا پیام کپی نکنید.
بررسی فیش واریزی مشتری
پرداخت بانکی/کارتبهکارت ممکن است با فیشی که مشتری ارسال کرده وارد صف «فیشهای واریزی» شود. در ردیف، سفارش، مبلغ، مرجع، نام پرداختکننده و زمان ارسال را بررسی کنید؛ خود رسید فایل خصوصی است و باید فقط در پنل مجاز دیده شود. وضعیتهای فیش pending، approved و rejected هستند. در رکورد، review note، بررسیکننده و زمان بررسی نیز نگه داشته میشود.
برای تأیید، این موارد را کنار هم قرار دهید:
- شماره سفارش و فضای کاری درست را بررسی کنید.
- مبلغ و روش پرداخت را با دستور پرداخت ثبتشده روی همان سفارش تطبیق دهید.
- مرجع/رسید را با سند قابل دسترس از حساب بانکی سازمان تطبیق دهید؛ تصویر ارسالی مشتری بهتنهایی مدرک واریز قطعی نیست.
- اگر واریز هنوز در حساب بانکی قابل مشاهده نیست یا مبلغ مغایر است، فیش را تأیید نکنید؛ از بررسی مالی سازمان استفاده کنید.
- پس از تطبیق، اقدام «تأیید فیش و پرداخت» را اجرا کنید و یادداشت بررسی را خلاصه و غیرحساس ثبت کنید.
این action پیام تأیید دارد، چون پس از تأیید سفارش پرداختشده میشود و موجودی رزروشده commit میشود. بنابراین تأیید فیش فقط تغییر وضعیت نیست؛ روی موجودی قابل فروش هم اثر دارد. اگر فیش نادرست یا تکراری است، «رد فیش» را بهکار ببرید و علت را در یادداشت لازم ثبت کنید تا بعداً کاربر بعدی بداند چرا. پس از رد، مشتری ممکن است نیاز به ارسال رسید معتبر دیگری داشته باشد؛ سفارش و پرداخت دیگری نسازید مگر گردش سیستم صریحاً نیاز داشته باشد.
اقدام «تأیید پرداخت دستی» روی سفارش
در جزئیات سفارش، action مستقل mark_manual_paid ممکن است برای مدیر دارای مجوز ظاهر شود. این اقدام برای پرداخت دستیای است که بیرون از درگاه انجام شده و با reference و یادداشت ثبت میشود. تأییدش باعث پرداختشدهشدن سفارش و قطعیشدن موجودی رزروشده است. آن را بهعنوان راه میانبر برای تراکنش created یا callback نامشخص درگاه به کار نبرید؛ اول نتیجه درگاه را پیدا کنید تا پرداخت دوباره ثبت نشود.
تأیید دستی و بررسی فیش هر دو میتوانند سفارش را paid کنند، اما مبنای دادهشان فرق دارد. برای واریز بانکی مشتری در صف فیش، ابتدا submission را بررسی کنید. برای نوع پرداخت دستی بدون فیش، action سفارش را فقط بعد از تطبیق سند مالی استفاده کنید.
پرداخت ناموفق، منقضی یا نامشخص
اگر مشتری میگوید مبلغ از حسابش کم شده اما سفارش ناموفق است، ابتدا تراکنش همان order را با authority یا ref_id و زمان تطبیق دهید. وضعیت provider را از درگاه یا گزارش معتبر بگیرید. تا وقتی نتیجه روشن نیست، دوباره درخواست پرداخت یا تأیید دستی نکنید. وضعیت reversing و reversed را با failed یکی نگیرید: اولیها نشان میدهند برگشت وجه در جریان است یا تکمیل شده. بانک یا provider ممکن است زمانبندی خودش را داشته باشد؛ در پنل فقط وضعیت ثبتشده در Anama را میبینید.
سفارشهای awaiting_payment نیز با تراکنشهای created، redirected, failed یا expired تفاوت دارند. یک سفارش بدون payment success را برای آمادهسازی عملیاتی ارسال نکنید مگر راهحل پرداخت اعتباری یا دستی آن صریحاً تأیید شده باشد. برای خرید B2B با مهلت پرداخت، on_account یک مسیر اعتباری است و مثل کارتبهکارت مدیریت نمیشود.
بازپرداخت را با dispute اشتباه نگیرید
بازپرداخت زمانی آغاز میشود که فروشگاه تصمیم گرفته مبلغ را به مشتری برگرداند؛ dispute/chargeback زمانی است که provider از طرف مشتری اختلاف ثبت کرده است. یک dispute باز میتواند اثر debit مالی داشته باشد و بعدها نتیجه won/lost داشته باشد. وضعیت تجاری dispute و financial_status آن جدا هستند؛ بازبودن یا برندهشدن dispute بهتنهایی ثابت نمیکند بدهی حسابداری ثبت یا برگشت وجه settle شده است.
از میانبر «اختلافات پرداخت» پرونده را باز کنید، status و financial status، مبلغ، reason و شناسه provider را ببینید. ثبت dispute روی Payment فقط پرونده provider را ایجاد میکند؛ طبق confirmation تعبیهشده در اقدام، refund یا journal حسابداری ساختگی ایجاد نمیکند. اگر هشدار overlap بازپرداخت نمایش داده میشود، آن را پیش از هر جبران مالی بررسی کنید؛ ممکن است همان مبلغ از مسیر دیگری قبلاً به مشتری یا provider رسیده باشد.
Refund مرجوعی از زبانه «مرجوعی و تعویض» و پرونده Return مدیریت میشود، نه با تغییر دستی Payment. روند مرجوعی ممکن است ابتدا دریافت فیزیکی و بررسی کالا را بخواهد، سپس درخواست refund بسازد. برای روش wallet، دیجیپی یا بانک، وضعیتهای settlement و inquiry میتوانند چندمرحلهای باشند؛ ایجاد درخواست با پرداخت نهایی یکی نیست. برای فروش اعتباری B2B مسیر Credit Note دارد. از دکمهای با نام Refund در زمینه نامرتبط برای ساخت پرداخت خیالی استفاده نکنید.
درگاهها و اتصال
میانبر «درگاهها» فهرست تنظیمهای provider را باز میکند. تنظیمات نمایشدادهشده را با owner یا مسئول مالی هماهنگ کنید. وضعیت کلید یا اتصال را از برچسب امن خود پنل بخوانید؛ secret را در متن، تصویر راهنما یا گزارش پشتیبانی کپی نکنید. اگر callback یا پرداخت تازه در پنل نمیآید، زمان تراکنش، شماره سفارش و مرجع غیرحساس را ثبت کنید و درگاه فعال و event مربوط را با مسئول فنی پیگیری کنید.
عیبیابی مرحلهای
مشتری رسید داده اما سفارش همچنان پرداختنشده است
فهرست فیشها را با order number فیلتر کنید و وضعیت submission را بخوانید. اگر pending است، مبلغ و مرجع را از حساب بانکی تطبیق دهید و بعد approve/reject کنید. اگر فیش در آن فهرست نیست، در جزئیات سفارش روش پرداخت را بررسی کنید؛ شاید مشتری از provider آنلاین استفاده کرده باشد یا فایل در submission دیگری ثبت شده باشد. اطلاعات کارت را از مشتری نخواهید.
Payment موفق است اما order در حال انتظار است
پرداخت و سفارش را با شناسه order و مرجع provider جفت کنید. Payment paid باید از پاسخ واقعی درگاه آمده باشد؛ وضعیت خلاصه سفارش را تازه کنید و تاریخچه اقدام را ببینید. اگر تراکنش موفق روی order اشتباه یا تکراری دیده میشود، دستی order را mark paid نکنید؛ با transaction reference و شناسه order برای پشتیبانی مالی/فنی گزارش کنید.
مشتری دوباره پرداخت کرده یا پول برنگشته است
تلاشهای پرداخت همان order را با زمان و gateway کنار هم بگذارید؛ authority و ref_id را ثبت کنید، اما داده کارت یا پاسخ خام را منتشر نکنید. وضعیت reversal را دنبال کنید و بهجای شروع Refund جداگانه، اول اطمینان حاصل کنید که تراکنش قبلی چه نتیجهای داشته است. زمان نهایی برگشت را تنها از وضعیت provider/بانک بگیرید.
dispute و refund همزمان دیده میشوند
از مبلغ و order به پروندههای مرتبط برسید. وضعیت business dispute، financial status، refund overlap و وضعیت settlement را جداگانه بخوانید. هیچکدام را با تغییر دستی دیگری حل نکنید؛ موضوع را به finance owner ارجاع دهید تا از پرداخت دوباره جلوگیری شود.
مثال: فیش صحیح ولی سفارش هنوز بسته نشده
یک مشتری کارتبهکارت کرده و سفارش در awaiting_payment است. او مبلغ و فیش را بارگذاری میکند. همکار مالی submission را در صف باز میکند، شماره سفارش و مبلغ را با گردش بانکی تطبیق میدهد، سپس با یادداشت کوتاه فیش را تأیید میکند. آناما وضعیت پرداخت سفارش را بهروز و رزرو موجودی را قطعی میکند. تیم انبار پس از آن سفارش را از صف آمادهسازی برمیدارد. اگر حساب بانکی هنوز مبلغ را نشان نمیداد، فیش در حالت pending میماند یا با علت رد میشد؛ انبار نباید صرفاً بر مبنای تصویر رسید بسته را ارسال میکرد.
قدم بعدی
برای پیگیری سفارش از پرداخت تا ارسال راهنمای گردش سفارش را بخوانید. اگر بازپرداخت از درخواست مرجوعی آغاز شده است، پرونده را در ثبت و پیگیری مرجوعی ادامه دهید؛ وضعیت dispute یا فیش پرداخت را جایگزین پرونده مرجوعی نکنید.