قوانین فروشگاه اینترنتی در ایران؛ مجوز، مالیات و حقوق مشتری

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

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

نقشه کلی الزامات فروشگاه آنلاین

به‌جای یک Checklist یکسان برای همه، فروشگاه را در هشت لایه ببینید:

وجود یک مورد، دیگری را حذف نمی‌کند. اینماد جای مجوز تخصصی کالا، پرونده مالیاتی، قرارداد درست یا امنیت پرداخت را نمی‌گیرد.

قوانین پایه‌ای که باید بشناسید

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

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

مرحله صفر: مدل حقوقی فروشگاه را روی یک صفحه بنویسید

پیش از درخواست مجوز، یک Legal brief بسازید:

• فروشنده شخص حقیقی است یا شرکت؟ صاحب دامنه و حساب تسویه چه کسی است؟
• فروش مستقیم دارید، Marketplace هستید، واسطه معرفی می‌کنید یا اشتراک می‌فروشید؟
• کالا فیزیکی، فایل دیجیتال، خدمت زمان‌دار، رزرو، آموزش یا محصول سلامت است؟
• موجودی متعلق به خود شماست یا فروشنده ثالث؟ چه کسی فاکتور و ضمانت می‌دهد؟
• فروش از وب‌سایت، اپ، شبکه اجتماعی یا ترکیب آن‌ها انجام می‌شود؟
• پول را چه کسی دریافت و Refund می‌کند؟ تسویه چندمرحله‌ای است؟
• مشتری مصرف‌کننده نهایی است یا معامله B2B هم دارید؟
• کدام داده و Third-partyها در سفارش، تبلیغات و پشتیبانی دخیل‌اند؟

این پاسخ‌ها مجوز، مالیات، متن قرارداد و مسئولیت را عوض می‌کنند. اگر پلتفرم فروشندگان ثالث دارید، Terms یک فروشگاه ساده برای شما کافی نیست.

اینماد چیست و چه چیزی را ثابت نمی‌کند؟

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

اما اینماد را «تضمین کیفیت همه کالاها»، «گواهی امنیت کامل»، «بیمه معامله» یا جایگزین همه مجوزها معرفی نکنید. کاربر باید بتواند روی نشان کلیک کند و پروفایل همان دامنه، وضعیت، مالک و تاریخ را ببیند؛ تصویر ثابت نشان قابل راستی‌آزمایی نیست.

برای اقدام چه کنید؟

1. مالک دامنه، فروشنده، پرونده مالیاتی و حساب تسویه را از ابتدا هم‌راستا کنید.
2. شرایط جاری، نوع نشان، رتبه، مدارک و محدودیت کالا را در سامانه رسمی اینماد ببینید.
3. شرط‌های پذیرنده PSP یا پرداخت‌یار را از قرارداد همان ارائه‌دهنده بگیرید.
4. پس از صدور، Link نشان و Profile را در Production تست و انقضا/تعلیق را پایش کنید.

به‌جای حکم کلی «اینماد همیشه الزامی/اختیاری است»، Scope فروش، نوع پذیرندگی و آخرین رویه رسمی را بررسی کنید. شرط دریافت درگاه نیز ممکن است با نوع خدمت و ارائه‌دهنده متفاوت باشد.

پروانه کسب و مجوز تخصصی را با اینماد یکی ندانید

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

ماتریس مجوز بسازید

فروش مواد غذایی، آرایشی/بهداشتی، مکمل، دارو، تجهیزات پزشکی، محصولات فرهنگی، طلا/دارایی مالی و کالاهای محدودشده را با یک عبارت عمومی پاسخ ندهید. نوع دقیق محصول، نقش شما و مجوز زنجیره تأمین را از مرجع تخصصی و درگاه ملی بررسی کنید. داشتن مجوز تأمین‌کننده لزوماً مجوز عرضه‌کننده یا تبلیغ‌کننده را ثابت نمی‌کند.

کالای ممنوع یا محدود؛ Gate پیش از Catalog

کنترل مجوز نباید پس از دریافت شکایت انجام شود. در فرایند ورود محصول، فیلدهای زیر را اجباری کنید:

• نام و دسته دقیق کالا، تولیدکننده/واردکننده و منبع تأمین
• شماره مجوز/شناسه اصالت و تاریخ اعتبار در صورت لزوم
• شرایط نگهداری، حمل، محدودیت سنی یا نسخه در صورت وجود
• ادعاهای مجاز و شواهد Claim؛ به‌ویژه سلامت و عملکرد
• مسئول Approval و تاریخ بازبینی
• Kill switch برای توقف فوری فروش/تبلیغ و اطلاع به مشتریان

Marketplace باید Onboarding فروشنده، Moderation فهرست، مسیر گزارش، Takedown و نگهداری شواهد را نیز تعریف کند. نوشتن «مسئولیت کامل با فروشنده است» به‌تنهایی تمام ریسک پلتفرم را حذف نمی‌کند.

مالیات فروشگاه اینترنتی؛ چهار موضوع جدا

اینترنتی بودن به‌خودی‌خود معافیت مالیاتی ایجاد نمی‌کند، اما از این گزاره هم نباید نتیجه گرفت همه فروشگاه‌ها تکلیف و نرخ یکسان دارند. چهار جریان را جدا کنید:

1. تشکیل و نگهداری پرونده: هویت مؤدی، فعالیت، نشانی، حساب/درگاه و اطلاعات پایه.
2. مالیات عملکرد: برای شخص حقیقی یا حقوقی با قواعد، معافیت‌ها و هزینه‌های قابل قبول مربوط.
3. مالیات و عوارض ارزش افزوده: فقط در صورت شمول کالا/خدمت و تکلیف ثبت‌نام/فراخوان؛ نه صرفاً به‌دلیل آنلاین بودن.
4. سامانه مودیان و صورتحساب الکترونیکی: دامنه، زمان‌بندی و نوع صورتحساب بر اساس قانون و آخرین اطلاعیه‌های مؤدی.

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

تراکنش درگاه با درآمد مشمول مالیات یکی نیست

گزارش یک تراکنش پرداخت به معنی تشخیص خودکار سود خالص یا صدور خودکار صورتحساب همه سناریوها نیست. Refund، سفارش لغوشده، وجه عبوری Marketplace، تسویه فروشنده، هزینه ارسال و Chargeback باید در دفاتر و Reconciliation با ماهیت درست ثبت شوند. برای مدل پیچیده، Mapping حسابداری را پیش از Launch طراحی کنید.

VAT را بدون احراز تکلیف دریافت نکنید

همه کالاها/خدمات وضعیت یکسان ندارند و نرخ/معافیت می‌تواند تغییر کند. دریافت مبلغی با عنوان ارزش افزوده بدون مبنای درست، یا جذب آن در قیمت بدون ثبت صحیح، ریسک می‌سازد. برای هر SKU/Service، Tax code، شمول، نرخ جاری، تاریخ اثر و منبع تصمیم را نگه دارید.

تقویم مالیاتی عملیاتی

• مالک پرونده و مشاور مالیاتی
• مهلت اظهار، پرداخت و صورتحساب بر اساس وضعیت مؤدی
• کنترل اتصال درگاه/حساب به پرونده صحیح
• Reconciliation روزانه سفارش، درگاه، Refund و تسویه
• آرشیو فاکتور خرید، قرارداد، هزینه تبلیغ، ارسال و خدمات
• Change log برای نرخ/معافیت و تنظیمات نرم‌افزار فروش

عدد نرخ یا مهلت را از مقاله وبلاگی کپی نکنید؛ آخرین اعلان پرونده و Portal رسمی را مبنا قرار دهید.

اطلاعاتی که باید پیش از خرید نمایش دهید

مواد ۳۳ تا ۳۵ قانون تجارت الکترونیکی، ارائه به‌موقع و روشن اطلاعات مؤثر تصمیم را لازم می‌دانند. حداقل‌های ماده ۳۳ شامل ویژگی فنی و کاربردی، هویت و نشانی فروشنده، راه تماس، همه هزینه‌های خرید، مدت اعتبار پیشنهاد و شرایط پرداخت/تحویل/لغو/مرجوعی/خدمات پس از فروش است.

ماده ۳۵ بر «واسط بادوام»، وضوح، حسن نیت و ملاحظه افراد دارای معلولیت و کودکان تأکید می‌کند. یک Tooltip ناپایدار یا متن خاکستری ریز که پس از خرید قابل بازیابی نیست، انتخاب امنی برای اطلاعات اصلی نیست.

برای جای‌گذاری صحیح هزینه، ارسال و خطا، راهنمای Checkout فروشگاه ایرانی را ببینید.

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

پس از سفارش، ماده ۳۴ اطلاعات تکمیلی مانند نشانی کاری برای شکایت، خدمات پس از فروش و ضمانت، شرایط حق انصراف و لغو خدمت را مطرح می‌کند. تأییدیه را فقط در صفحه‌ای که بسته می‌شود نگذارید؛ نسخه قابل نگهداری در حساب کاربر، ایمیل یا کانال توافق‌شده ارائه کنید.

حداقل Order confirmation

• شناسه سفارش، زمان، فروشنده و راه تماس
• قلم، تعداد، ویژگی انتخاب‌شده و قیمت هر جزء
• تخفیف، مالیات/عوارض در صورت شمول، ارسال و مبلغ نهایی
• نشانی/روش تحویل با Mask مناسب در کانال پیام
• روش پرداخت و وضعیت «موفق/ناموفق/در حال بررسی»
• بازه تحویل و مسیر پیگیری
• نسخه شرایط معامله و لینک سیاست مرجوعی جاری هنگام خرید

Terms را نسخه‌دار کنید و Hash/Version آن را کنار سفارش نگه دارید؛ اما Log محرمانه را برای مشتری یا کارکنان غیرمجاز قابل مشاهده نکنید.

حق انصراف هفت روز کاری؛ تعریف دقیق

ماده ۳۷ برای معامله از راه دور حداقل هفت روز کاری حق انصراف بدون جریمه و بدون ارائه دلیل پیش‌بینی می‌کند؛ تنها هزینه‌ای که طبق این ماده می‌تواند به مصرف‌کننده تحمیل شود، هزینه بازپس‌فرستادن کالا است. شروع مهلت طبق ماده ۳۸ برای کالا از تحویل و برای خدمت از انعقاد قرارداد است، و در هر حال پس از ارائه اطلاعات الزامی مواد ۳۳ و ۳۴ آغاز می‌شود.

سیاست فروشگاه نباید این حداقل را با عبارتی مانند «کالای فروخته‌شده پس گرفته نمی‌شود» حذف کند. ماده ۴۶ شروط خلاف این بخش و شروط غیرمنصفانه به زیان مصرف‌کننده را بی‌اثر می‌داند.

حق انصراف با ایراد یا ارسال اشتباه فرق دارد

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

استثناهای حق انصراف را حدس نزنید

فهرست استثناها در مصوبه موارد فقدان حق انصراف آمده است. از جمله:

• خدمتی که با توافق مصرف‌کننده پیش از پایان هفت روز کاری شروع شده باشد؛
• تحویل مواد غذایی یا کالاهای مصرف روزانه در قالب خدمت مربوط؛
• کالا/خدمتی که قیمت آن با نوسان بازار مالی خارج از اختیار تأمین‌کننده تعیین می‌شود؛
• کالای ساخته‌شده با مشخصات شخصی، به‌وضوح شخصی‌سازی‌شده، ذاتاً غیرقابل بازگشت یا سریع‌الفساد؛
• نوار صوتی/تصویری و نرم‌افزار بسته‌بندی‌شده که بسته آن باز شده، و کارت اشتراک رمزدار بازشده؛
• روزنامه، نشریه و مجله مطابق تعریف قانونی.

عبارت «کالای بهداشتی» در نسخه قدیمی این مقاله به‌صورت استثنای عام آمده بود، اما متن استثناها را باید با مصداق واقعی تطبیق داد؛ برچسب فروشگاه به‌تنهایی حق انصراف را حذف نمی‌کند. همچنین شروع زودهنگام خدمت نیازمند توافق مصرف‌کننده است. متن Checkout باید این انتخاب را روشن و قابل اثبات ثبت کند.

فرایند مرجوعی و Refund را اجرایی کنید

Policy خوب بدون Workflow عملی کافی نیست. مسیر باید روی موبایل و بدون تماس اجباری طولانی کار کند.

1. درخواست با شناسه سفارش و دلیل اختیاری/الزامی متناسب ثبت شود.
2. سیستم نوع پرونده را تفکیک کند: انصراف، ایراد، ارسال اشتباه، خسارت حمل یا گارانتی.
3. مهلت، استثنا و شواهد با Rule نسخه‌دار بررسی شود.
4. روش بازگشت، هزینه و نشانی به‌صورت پایدار اعلام شود.
5. وضعیت دریافت، بررسی و Refund به مشتری اطلاع داده شود.
6. بازپرداخت به مسیر معتبر و با Reconciliation انجام شود.
7. اختلاف با کد پیگیری و Escalation به مسئول حقوقی/پشتیبانی برود.

برای جلوگیری از Refund تکراری، Order state، Payment state و Return state را جدا نگه دارید. اتصال فنی صحیح در راهنمای اتصال امن درگاه پرداخت توضیح داده شده است.

موجودی، تحویل و جایگزینی کالا

ماده ۳۹ در صورت عدم امکان اجرای تعهد به‌دلیل نبود کالا/خدمت، بازپرداخت فوری را اصل می‌داند، مگر در حالت محدود کالای کلی/تعهدی که اجرای آن برای همیشه ناممکن نیست و مخاطب آماده انتظار باشد. این رضایت را از سکوت کاربر استنباط نکنید؛ ماده ۴۳ سکوت را قبول نمی‌داند.

ماده ۴۰ اجازه پیشنهاد کالای/خدمت هم‌کیفیت و هم‌قیمت را در صورت اطلاع قبل یا حین معامله مطرح می‌کند. «ارسال خودکار جایگزین» بدون گزینه روشن، طراحی امنی نیست. کاربر باید بتواند Refund، انتظار یا جایگزین را آگاهانه انتخاب کند.

قیمت، تخفیف و ادعای تبلیغاتی

مواد ۵۰ تا ۵۵ بر پرهیز از فریب، توصیف دقیق، روشن بودن هویت تبلیغ‌کننده و امکان انتخاب دریافت پیام تأکید دارند. برای تیم Marketing یک Claim register بسازید:

Countdown که دوباره شروع می‌شود، موجودی ساختگی، هزینه پنهان، Checkbox از پیش انتخاب‌شده و سخت کردن لغو، هم اعتماد را کم می‌کنند و هم می‌توانند شرط/تبلیغ فریبنده بسازند. راهنمای طراحی اخلاقی الگوهای رابط را پوشش می‌دهد.

حریم خصوصی و داده شخصی؛ از Inventory شروع کنید

مواد ۵۸ تا ۶۱ قانون تجارت الکترونیکی درباره داده شخصی و حساس قواعدی دارند. ماده ۵۹ پس از رضایت شخص، هدف مشخص و روشن، جمع‌آوری در حد لازم، استفاده فقط برای هدف اعلام‌شده، صحت/به‌روزی و امکان دسترسی، اصلاح و درخواست حذف را مطرح می‌کند. ماده ۵۸ برای دسته‌های حساس، رضایت صریح را برجسته می‌کند و سوابق پزشکی/سلامت در ماده ۶۰ تابع مقررات مربوط‌اند.

Data inventory حداقلی

وجود Privacy Policy به‌تنهایی انطباق نمی‌سازد. متن باید با SDK، Tag manager، Log، CRM، پشتیبان‌گیری و Vendorهای واقعی مطابق باشد. دسترسی Export یا درخواست اصلاح/حذف نیز باید Workflow، احراز هویت، استثناهای نگهداری و SLA داشته باشد.

برای Event و حداقل‌سازی داده در تحلیل محصول، راهنمای UX داده‌آگاه را ببینید.

امنیت داده و فروشگاه

قانون و قرارداد بدون کنترل فنی کافی نیست. اطلاعات کارت را خودتان جمع‌آوری نکنید؛ کاربر را به مسیر پرداخت معتبر بفرستید و نتیجه را Server-to-server Verify کنید. کنترل‌های پایه:

• MFA و نقش حداقلی برای پنل، Refund و تغییر حساب تسویه
• رمزنگاری مسیر، مدیریت Secret و Rotation دسترسی
• Update امن پلتفرم و افزونه، WAF و Rate limit متناسب
• Log دسترسی و تغییر سفارش بدون افشای داده حساس
• Backup قابل بازیابی و تمرین Restore
• Vendor due diligence برای ارسال، پیامک، CRM و Analytics
• Incident runbook برای نشت داده، تصاحب حساب و تقلب Refund

چک‌لیست امنیت فروشگاه‌ساز SaaS جریان سفارش، API، Webhook و Reconciliation را عمیق‌تر بررسی می‌کند.

بازاریابی پیامکی و ایمیلی؛ امکان انتخاب و خروج

تلفن یا ایمیل سفارش، مجوز نامحدود تبلیغ نیست. ماده ۵۵ بر فراهم کردن ترتیبات انتخاب دریافت تبلیغات تأکید دارد. Consent را از پذیرش Terms یا انجام سفارش جدا کنید و هدف/کانال را روشن بنویسید.

• Checkbox تبلیغ از پیش انتخاب‌شده نباشد.
• لغو پیامک/ایمیل ساده، قابل اجرا و ثبت‌شده باشد.
• فهرست منع ارسال در همه ابزارها Sync شود.
• اثبات Source، زمان و متن رضایت نسخه‌دار نگهداری شود.
• پیام عملیاتی سفارش با Marketing مخلوط نشود.
• خرید فهرست شماره/ایمیل بدون مبنای معتبر انجام نشود.

فروش در اینستاگرام و Marketplace قانون‌گریز نیست

فروش روی شبکه اجتماعی یا پلتفرم شخص ثالث، قواعد مربوط به هویت فروشنده، اطلاعات تصمیم خرید، کالاهای تنظیم‌شده، مالیات و حقوق مصرف‌کننده را خودبه‌خود حذف نمی‌کند. اما اینکه دقیقاً چه نشان، پروانه یا روش پرداختی برای آن Channel لازم است، باید از Scope مقررات و Portal جاری استخراج شود.

برای فروش Social این موارد را ثبت کنید

• هویت قابل استعلام و راه تماس/شکایت
• قیمت نهایی، ارسال، موجودی، مرجوعی و ضمانت پیش از پرداخت
• رسید سفارش و تأیید قابل نگهداری
• روش پرداخت معتبر و Reconciliation
• Consent و حفظ داده در Direct/پیام‌رسان/CRM
• مجوز کالا و محدودیت تبلیغ همان Channel

عبارت قدیمی «اینماد مخصوص صفحه اینستاگرام» را بدون استناد جاری تکرار نکنید. سامانه رسمی اینماد، درگاه ملی مجوزها و Provider پرداخت را برای مدل دقیق خود بررسی کنید.

شرایط استفاده و سیاست مرجوعی چگونه نوشته شوند؟

Template عمومی را کپی نکنید. سند باید آنچه سیستم واقعاً انجام می‌دهد توصیف کند و با قانون تعارض نسازد.

بخش‌های ضروری Terms فروش

• هویت و اطلاعات تماس فروشنده/پلتفرم
• تعریف مشتری، سفارش، پذیرش و زمان تشکیل قرارداد
• قیمت، مالیات/عوارض در صورت شمول و خطای قیمت
• پرداخت، وضعیت نامشخص، Verify و Refund
• موجودی، جایگزینی، ارسال، تحویل و خسارت حمل
• حق انصراف، استثناهای دقیق و مرجوعی معیوب/اشتباه
• ضمانت، خدمات پس از فروش و مسیر شکایت
• مالکیت فکری، محتوای کاربر و کالاهای ممنوع برای Marketplace
• محدودیت مسئولیت معقول؛ بدون حذف حقوق آمره مصرف‌کننده
• نسخه، تاریخ اثر، تغییرات و قانون/مرجع حل اختلاف با بازبینی وکیل

لینک Terms و Privacy را در فوتر سایت قابل یافتن کنید، اما هزینه، مرجوعی و شروط مؤثر تصمیم را در Context محصول و Checkout نیز نمایش دهید.

شکایت و پشتیبانی؛ مسیر قابل پیگیری بسازید

کاربر باید بداند کجا درخواست می‌دهد، چه کدی می‌گیرد و چه زمانی پاسخ می‌شنود. Ticket خوب شامل شناسه سفارش، موضوع، Timeline، فایل‌ها، پاسخ‌ها و وضعیت است. اطلاعات بیش از حد و مدرک هویتی غیرضروری نگیرید.

سایت رسمی اینماد به سامانه شکایت از کسب‌وکار و گزارش تخلف لینک می‌دهد. این مسیر جای حل داخلی سریع را نمی‌گیرد. Linkهای شکایت و پروفایل اینماد را در QA دوره‌ای کنترل کنید.

پرونده شواهد؛ چیزی که در اختلاف لازم می‌شود

«در سایت نوشته بود» بدون نسخه و زمان اثبات ضعیفی است. برای هر سفارش، حداقل این شواهد را با کنترل دسترسی نگه دارید:

• شناسه، زمان و فروشنده/خریدار مرتبط
• Snapshot یا نسخه قیمت، مشخصات و Terms پذیرفته‌شده
• موجودی و وعده تحویل هنگام سفارش
• Payment request/Verify/Reference و Refund؛ بدون داده کارت
• پیام تأیید، ارسال، تحویل و پیگیری
• درخواست لغو/مرجوعی، دلیل، تصویر و تصمیم
• Consentهای Marketing/Data و تاریخ لغو
• Log تغییرات با زمان و کاربر مسئول

Retention را بر اساس نیاز قراردادی، مالیاتی، شکایت و داده شخصی تعیین کنید؛ «همیشه نگه داریم» سیاست خوبی نیست. داده‌های مالی و شخصی باید دسترسی و حذف/اصلاح کنترل‌شده داشته باشند.

RACI انطباق فروشگاه

در تیم کوچک یک نفر ممکن است چند نقش داشته باشد، اما Approval و شاهد حذف نشوند. هیچ تغییر سراسری در Tax، Refund یا Checkout بدون Owner منتشر نشود.

سه Gate پیش از راه‌اندازی فروشگاه

Gate ۱: اجازه فعالیت و فروش

• شخص فروشنده، عنوان فعالیت و نشانی روشن است.
• مجوز پایه و تخصصی در Portal رسمی استعلام و مستند شده است.
• دامنه، اینماد، پذیرنده، حساب تسویه و پرونده مالیاتی هم‌راستا هستند.
• کالای ممنوع/محدود و Claim سلامت Gate دارد.

Gate ۲: قرارداد و تجربه خرید

• قیمت کل، موجودی، تحویل، فروشنده و شروط پیش از پرداخت روشن‌اند.
• Order confirmation پایدار و نسخه Terms ثبت می‌شود.
• انصراف، ایراد، ارسال اشتباه و عدم موجودی Workflow جدا دارند.
• Checkout موبایل و دسترس‌پذیری آزموده شده است.

Gate ۳: عملیات و شواهد

• صورتحساب، مالیات، VAT و Reconciliation با مشاور بررسی شده‌اند.
• Data inventory، Access، Retention و Vendorها ثبت شده‌اند.
• Payment/Refund/Complaint/Incident Runbook تمرین شده است.
• Owner، Alert، Backup و Rollback مشخص‌اند.

برنامه ۳۰روزه اصلاح فروشگاه موجود

روز ۱ تا ۷: کشف ریسک

• مدل فروش، مجوز، Tax، Product، Data و Payment را Inventory کنید.
• یک سفارش واقعی از Product تا Refund را مستند کنید.
• Policyها را با رفتار واقعی و متن مواد ۳۳ تا ۶۱ مقایسه کنید.
• ریسک بحرانی مانند کالای بدون مجوز یا Refund ناممکن را متوقف کنید.

روز ۸ تا ۱۵: اصلاح مسیر خرید

• هویت، هزینه، تحویل، موجودی و مرجوعی را در Context اضافه کنید.
• تأییدیه سفارش و نسخه Terms را پایدار کنید.
• Return types و Statusهای Payment/Refund را جدا کنید.
• Dark patternهای Consent و تخفیف را حذف کنید.

روز ۱۶ تا ۲۳: مالیات، داده و امنیت

• پرونده/درگاه/حساب، تکلیف صورتحساب و VAT را با متخصص تأیید کنید.
• Reconciliation و آرشیو اسناد را راه‌اندازی کنید.
• Data inventory، دسترسی، Retention و Opt-out را اجرا کنید.
• MFA، Backup restore و Incident runbook را تست کنید.

روز ۲۴ تا ۳۰: آزمون و حاکمیت

• سه سناریوی خرید، انصراف و کالای اشتباه را End-to-end اجرا کنید.
• لینک اینماد/مجوز/شکایت و Policy را در Production بررسی کنید.
• RACI، تقویم بازبینی و Change approval را تصویب کنید.
• پرونده شواهد نمونه را با وکیل و مشاور مالیاتی مرور کنید.

چک‌لیست نهایی قوانین فروشگاه اینترنتی

• شخص فروشنده، صاحب دامنه، پذیرنده و حساب تسویه مشخص و هماهنگ‌اند.
• عنوان مجوز پایه و شروط جاری از درگاه ملی استخراج شده است.
• برای هر دسته محصول، مجوز/محدودیت/ادعای مجاز مستند است.
• اینماد قابل کلیک، متعلق به همان دامنه و دارای وضعیت جاری است.
• پرونده مالیاتی، صورتحساب، VAT و تقویم تکلیف موردی تأیید شده‌اند.
• تراکنش، سفارش، صورتحساب و سود به‌اشتباه یک چیز فرض نشده‌اند.
• هویت، ویژگی، همه هزینه‌ها، اعتبار پیشنهاد و تحویل پیش از پرداخت روشن‌اند.
• تأیید سفارش در واسط بادوام و با نسخه Terms ارائه می‌شود.
• حق انصراف هفت روز کاری و شروع مهلت درست توضیح داده شده است.
• استثناها از مصوبه گرفته شده‌اند، نه Label دلخواه فروشگاه.
• انصراف، ایراد، کالای اشتباه، گارانتی و عدم موجودی تفکیک شده‌اند.
• Refund، جایگزینی و انتظار نیازمند انتخاب و شواهد روشن‌اند.
• Claim، تخفیف، Countdown و Badge شواهد و مالک دارند.
• Data inventory، هدف، حداقل‌سازی، دسترسی، اصلاح/حذف و Retention تعریف شده‌اند.
• پیام عملیاتی از Marketing جدا و Opt-out اجرا می‌شود.
• درگاه Server-side Verify، Refund کنترل‌شده و Reconciliation دارد.
• مسیر شکایت داخلی کدپیگیری، SLA و Escalation دارد.
• مجوز، Policy، Tax و Security دوره‌ای و پس از هر تغییر بازبینی می‌شوند.

پرسش‌های متداول

آیا همه فروشگاه‌های اینترنتی دقیقاً یک مجوز واحد لازم دارند؟

نه. عنوان و مرجع مجوز به نوع فعالیت، کالا/خدمت، نقش فروشنده یا پلتفرم، محل و Channel بستگی دارد. اینماد، پروانه صنفی و مجوز تخصصی محصول کارکردهای متفاوت دارند. شناسنامه جاری مجوز را در درگاه ملی مجوزها بررسی کنید.

آیا اینماد برای دریافت درگاه پرداخت کافی است؟

اینماد یکی از مؤلفه‌های رایج احراز کسب‌وکار اینترنتی است، اما پذیرنده پرداخت ممکن است پرونده مالیاتی، هویت، حساب تسویه، دامنه، قرارداد و شروط ریسک خود را نیز بخواهد. نیاز دقیق را از سامانه اینماد و PSP/پرداخت‌یار منتخب بگیرید.

حق انصراف خرید اینترنتی چند روز است؟

قانون برای معامله از راه دور حداقل هفت روز کاری مقرر کرده است. برای کالا از تحویل و برای خدمت از انعقاد قرارداد محاسبه می‌شود و در هر حال پس از ارائه اطلاعات مواد ۳۳ و ۳۴ آغاز می‌شود. استثناهای مصوب و وضعیت خاص پرونده باید جدا بررسی شوند.

آیا همه فروشگاه‌های آنلاین باید ارزش افزوده بگیرند؟

نه صرفاً به‌دلیل آنلاین بودن. شمول مؤدی و کالا/خدمت، معافیت، فراخوان و نرخ جاری باید بررسی شود. مبلغ VAT را بدون تأیید تکلیف دریافت نکنید و وضعیت هر SKU/Service را با مشاور مالیاتی و Portal رسمی ثبت کنید.

فروش در اینستاگرام از این قوانین مستثناست؟

خیر؛ تغییر Channel معمولاً هویت فروشنده، حقوق مصرف‌کننده، مالیات و مجوز محصول را حذف نمی‌کند. اما نوع پروانه، نشان و پرداخت لازم برای Social commerce را نباید حدس زد؛ مدل دقیق خود را در مراجع رسمی استعلام کنید.

جمع‌بندی

انطباق فروشگاه اینترنتی یک فایل PDF نیست؛ سیستم زنده‌ای از مجوز، اطلاعات محصول، Checkout، سفارش، پرداخت، مرجوعی، داده، مالیات و شواهد است. از مدل یک‌صفحه‌ای کسب‌وکار و License matrix شروع کنید، مواد ۳۳ تا ۶۱ را به Requirementهای محصول تبدیل کنید، هر تغییر را با Owner و Version منتشر کنید و برای تصمیم موردی از مرجع رسمی و متخصص واجدصلاحیت کمک بگیرید.