تبدیل سایت موجود به فروشگاه؛ Embed، افزونه یا مهاجرت؟

یک دکمه خرید در سایت شرکتی قرار می‌گیرد و همان روز اولین سفارش می‌آید. دو هفته بعد قیمت صفحه محتوا با Checkout فرق دارد، موجودی تمام‌شده هنوز قابل خرید است، پرداخت موفق در CRM ثبت نشده و تیم پشتیبانی میان سه پنل دنبال وضعیت سفارش می‌گردد. افزودن Commerce به سایت موجود فقط Embed کردن یک Button نیست؛ اتصال چند Source of truth و ساخت چرخه کامل سفارش است.

این راهنما برای سایت Brownfield است: وبلاگ، پورتفولیو، سایت شرکتی، سایت‌ساز SaaS یا HTML سفارشی که اکنون باید محصول، خدمت یا محتوای دیجیتال بفروشد. چهار مسیر Hosted link، Embedded commerce، قابلیت بومی و Commerce backend جدا را مقایسه می‌کنیم و Trigger مهاجرت کامل را می‌سازیم. برای تعریف Requirementهای عمومی فروشگاه، ابتدا امکانات ضروری فروشگاه اینترنتی را به‌عنوان Checklist مکمل ببینید.

«تبدیل سایت به فروشگاه» دقیقاً یعنی چه؟

Commerce یک Feature واحد نیست. حداقل این Capabilityها باید مالک و قرارداد داشته باشند:

• Catalog، Product/Variant، Price، Discount و Availability؛
• Cart، Shipping، Tax/Invoice و Checkout؛
• Payment initiation، Redirect/Callback/Verify و Reconciliation؛
• Order state، Inventory reservation، Fulfillment، Delivery و Return/Refund؛
• Customer identity، Consent، Support، Notification و Data rights؛
• Product URL، Structured data، Sitemap، Analytics و Attribution؛
• Security، Admin access، Logs، Incident response، Backup و Exit.

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

پیش از انتخاب ابزار، Commerce scope را ببندید

«فعلاً فقط ده محصول داریم» کافی نیست. Variant، Stock، Shipping zone، Refund و تعداد Order peak مهم‌تر از تعداد Cardها هستند. یک محصول سفارشی با Configurator می‌تواند از ۵۰۰ SKU ساده پیچیده‌تر باشد.

چهار الگوی اصلی اتصال Commerce

۱. Hosted payment/product link

کاربر از صفحه موجود به صفحه Product/Checkout میزبانی‌شده Provider می‌رود. برای Pilot محصول محدود یا فروش خدمت با Fulfillment ساده، سریع‌ترین Boundary است.

• مزیت: سطح کد و Scope پرداخت روی سایت کمتر، Rollback ساده‌تر.
• هزینه: تغییر Domain/UX، محدودیت Branding، Analytics cross-domain و وابستگی Provider.
• شرط: قیمت/موجودی در صفحه اصلی نباید با Provider Drift کند؛ Link و Offer version لازم است.

۲. Buy Button یا Store Embed

Widget یا JavaScript روی صفحه فعلی Product/Card/Cart را رندر می‌کند و Checkout در همان Context یا Provider ادامه می‌یابد. این روش برای چند محصول و حفظ محتوای فعلی جذاب است، اما Script، Cookie، Accessibility، Performance و SEO را وارد Boundary می‌کند.

۳. ارتقای بومی سایت‌ساز یا نصب افزونه Commerce

سایت‌ساز فعلی Plan/Module فروشگاهی دارد، یا CMS مانند WordPress با افزونه‌ای مثل WooCommerce به Commerce تبدیل می‌شود. Admin و Theme یکپارچه‌تر می‌مانند، ولی Hosting، Extension compatibility، Update، Backup، Security و Day-two operations بر عهده تیم است.

۴. Commerce backend جدا با Frontend موجود

سایت از API/SDK یک Commerce engine برای Catalog/Cart/Order استفاده می‌کند و UI را خودش کنترل می‌کند. این Headless/Composable boundary آزادی بیشتری می‌دهد، اما Integration، Cache، Webhook، Contract، Preview، Observability و تیم فنی بالغ می‌خواهد. برای یک Pilot ساده، پیچیدگی اضافی است.

۵. Replatform به‌جای وصله بیشتر

وقتی پلتفرم فعلی Route، Server-side rendering، Checkout، Role، Integration یا Export لازم را نمی‌دهد، اضافه‌کردن Embedهای بیشتر بدهی را تشدید می‌کند. در این حالت Replatform یک گزینه معماری است؛ نه شکست پروژه. فرایند تصمیم و Cutover در راهنمای مهاجرت از سایت‌ساز پوشش داده شده است.

ماتریس انتخاب؛ اسم ابزار را بعد از Boundary انتخاب کنید

این جدول رتبه‌بندی نیست. Hosted link ممکن است برای فروش یک کارگاه بهترین و برای فروشگاه چندانباره بدترین باشد. برای مقایسه کامل Providerها بر اساس TCO/Pilot/Exit، مقاله انتخاب فروشگاه‌ساز با TCO و Pilot مالک آن Intent است.

Source of truth را Field به Field مشخص کنید

بزرگ‌ترین شکست Brownfield، دو نسخه از Product truth است: عنوان و قیمت در CMS، موجودی در Spreadsheet و Order در Provider. یک Data ownership map بسازید:

Sync نباید فقط Cron مبهم باشد. Direction، latency target، retry، idempotency، conflict resolution، dead-letter و alert لازم است. اگر Price API قطع شد، نمایش قیمت Cache‌شده همراه تاریخ بهتر است یا Block خرید؟ پاسخ به ریسک و Contract وابسته است.

Catalog و URL؛ مالک Search را دوباره نسازید

سایت فعلی ممکن است صفحات محتوا با رتبه و Backlink داشته باشد. افزودن Store نباید همان محصول را روی Main domain، Subdomain و Provider URL بدون Canonical/مالکیت روشن تکثیر کند.

تصمیم URL

• برای هر Product/Category یک Search owner انتخاب کنید.
• URL پایدار و لینک واقعی href از Navigation/Category بدهید.
• Fragment مثل #product-1 را صفحه Product مستقل فرض نکنید.
• Canonical، Sitemap، Breadcrumb، Pagination و Variant policy را یک‌دست کنید.
• Product structured data باید با Price/Availability قابل مشاهده هم‌خوان باشد.
• Provider/Subdomain thin page را Noindex/Canonical/Redirect بر اساس نقش واقعی تصمیم دهید.

Google در راهنمای Ecommerce URL روی URL crawlable و رابطه Product/Variant تأکید دارد و هشدار می‌دهد Fragment برای Index شدن محتوای مستقل استفاده نمی‌شود. Embed جاوااسکریپتی را در HTML رندرشده، موبایل و بدون Action انسانی آزمایش کنید؛ «Provider برای SEO بهینه است» جای QA را نمی‌گیرد. برای ارزیابی خروجی واقعی، سنجش SEO Fit سایت‌ساز روش Pilot دارد.

Product truth را میان CMS و Commerce دو بار ننویسید

اگر CMS توضیح غنی و Commerce عنوان/قیمت/موجودی دارد، Composition contract بنویسید. Page می‌تواند Copy را از CMS و Commerce facts را از API بگیرد؛ اما ID مشترک، Preview و Atomic publish لازم است.

Page release gate =
CMS content approved
AND commerce SKU exists
AND price/availability readable
AND canonical/schema/sitemap consistent
AND checkout path passes synthetic test

ویرایش دستی قیمت در دو پنل ممنوع شود. اگر Business مجبور است، Drift monitor و اولویت Source باید مشخص باشد. Cache purge نیز باید با تغییر Price/Stock هدفمند انجام شود.

Cart و Session در مرز دو Domain

Embed یا Hosted checkout ممکن است Cookie، Local storage، Popup، New tab یا Redirect داشته باشد. این موارد را تست کنید:

• Cart پس از Navigation، Refresh، Back و بازگشت از Checkout باقی می‌ماند؟
• Third-party cookie محدودشده چه اثری دارد؟
• Login سایت و Customer account فروشگاه یکی‌اند یا صریحاً جدا؟
• قیمت/ارز/زبان و Campaign context هنگام انتقال حفظ می‌شود؟
• در New tab کاربر می‌فهمد کجا رفته و چگونه برگردد؟
• Consent پیش از بارگذاری Scriptهای غیرضروری چگونه اعمال می‌شود؟

SSO برای Pilot الزام نیست؛ همگام‌سازی غلط هویت از دو حساب جدا بدتر است. Guest checkout با Order lookup امن می‌تواند انتخاب کم‌پیچیدگی‌تری باشد.

Checkout را Flow مالی بدانید، نه صفحه زیبا

Checkout باید Price، Discount، Shipping، Tax/هزینه، آدرس، روش پرداخت، Terms و نتیجه را با Stateهای کامل اداره کند. صفحه Provider لزوماً با فارسی/RTL، شماره همراه، کدپستی و آدرس ایران سازگار نیست.

Stateهای حداقلی

cart → checkout_started → order_created → payment_pending
→ authorized/verified → paid → fulfillment_pending
→ shipped/delivered → returned/refunded/closed

failure paths: cancelled | expired | failed | unknown | duplicate_callback

Redirect بدون پاسخ، وضعیت «Unknown» است؛ Failed فرض نکنید. با Verify server-side و Idempotency، نتیجه را روشن کنید. طراحی عمیق فرم، هزینه، Guest flow و Recovery در راهنمای بهینه‌سازی Checkout آمده است.

پرداخت Hosted مسئولیت را صفر نمی‌کند

HTTPS فقط انتقال را رمز می‌کند؛ صحت Business logic، Script، Admin، Webhook و Endpointهای شما را تضمین نمی‌کند. Boundary پرداخت را یکی از این‌ها انتخاب کنید:

PCI SSC در FAQ جاری خود برای برخی سناریوهای Embedded payment page روی Scriptهایی که می‌توانند صفحه Merchant را تحت تأثیر قرار دهند و تأیید Controlهای Provider تأکید می‌کند؛ دامنه دقیق Eligibility باید با نسخه و Acquirer/پردازشگر خود بررسی شود. این چارچوب کارت بین‌المللی جایگزین الزام‌های PSP و حقوق ایران نیست، اما یک درس معماری دارد: Iframe، صفحه میزبان را بی‌خطر نمی‌کند.

روش‌های درگاه، Wallet، BNPL و مرزهای مالی در راهنمای روش‌های پرداخت فروشگاه مقایسه شده‌اند.

Webhook، Callback و Order باید Idempotent باشند

• Signature/secret و Timestamp/Replay window را Validate کنید.
• Event ID و Transaction ID یکتا ذخیره کنید.
• State transition نامعتبر را رد و ثبت کنید.
• Callback Browser را منبع قطعی Paid ندانید؛ Verify server-to-server کنید.
• Retry با Backoff و Dead-letter داشته باشد؛ دوباره Fulfill نکند.
• Daily reconciliation میان PSP، Order و Ledger اجرا شود.
• Secret در Frontend، Log یا Repository قرار نگیرد.

if event_id already_processed: acknowledge_without_side_effect
verify signature and transaction
lock order
apply allowed transition once
write ledger + outbox event
commit
dispatch fulfillment asynchronously

Exactly-once شبکه‌ای را ادعا نکنید؛ Idempotent effect و Reconciliation هدف عملی هستند.

موجودی، رزرو و Fulfillment را پس از خرید اختراع نکنید

ویترین فقط آغاز کار است. برای کالای فیزیکی باید مشخص باشد:

• On-hand، reserved، available-to-promise و damaged چگونه محاسبه می‌شوند؛
• رزرو در Add-to-cart، Order create یا Payment چه زمانی و تا کی است؛
• Oversell، Partial fulfillment و Backorder چه Policy دارند؛
• Shipping zone، Weight، Carrier، SLA و Tracking از کجا می‌آیند؛
• Cancel/Return/Exchange/Refund چگونه Stock و مالی را Reconcile می‌کند؛
• محصول دیجیتال چگونه Entitlement، Expiry و Revoke دارد.

اگر Provider Store Order را می‌سازد ولی انبار با Spreadsheet کار می‌کند، همان روز اول Export/Import و Cutoff را تعریف کنید. مسیر حرفه‌ای Inventory، WMS، ارسال و بازگشت در راهنمای Fulfillment فروشگاه آمده است.

امنیت Embed و Plugin را لایه‌ای ببینید

CSP مفید است اما Policy بد یا Wildcard ضمانت نیست؛ Scriptهای Provider ممکن است Domainهای متعدد و تغییرپذیر داشته باشند. تغییرات Integration را در Staging و Synthetic journey آزمایش کنید. Security responsibility پلتفرم‌های فروشگاهی SaaS در راهنمای امنیت فروشگاه‌ساز SaaS تفصیل دارد.

Accessibility و RTL باید کل Journey را پوشش دهند

صفحه اصلی ممکن است WCAG-friendly باشد و Widget/Checkout نباشد. تست End-to-end شامل این موارد است:

• Keyboard، Focus order، Focus trap/return و Escape در Cart/Modal؛
• Accessible name دکمه خرید، Variant، Quantity و Remove؛
• Error summary، ارتباط Error با Field و حفظ داده؛
• Zoom/Reflow، Contrast، Touch target و Live region وضعیت Cart؛
• فارسی/RTL، Bidi برای SKU/URL/شماره، ارقام و ریال/تومان؛
• Redirect/New tab/Domain change و پیام بازگشت روشن؛
• Timeout، OTP، شبکه ضعیف و مسیر Recovery.

«Widget دسترس‌پذیر است» را از Vendor نپذیرید مگر Version، Scope و Test evidence روشن باشد. Custom CSS نیز ممکن است Focus یا Contrast پیش‌فرض سالم را خراب کند.

Analytics و Attribution در دو Domain

Journey باید از Content page تا Kept order قابل اتصال باشد، بدون اینکه PII بی‌دلیل منتقل شود:

view_product → add_to_cart → begin_checkout → payment_redirect
→ payment_return → purchase_verified → fulfilled → refunded/kept

• Cross-domain/session linking و unwanted referral را آزمایش کنید.
• transaction_id یکتا و Event خرید فقط پس از قرارداد مشخص باشد.
• Provider order ID، internal order ID و PSP transaction را Map کنید.
• Consent و purpose را در Domain/Scriptها هم‌راستا کنید.
• Frontend event را با OMS/Finance outcome Reconcile کنید.
• Render/error/redirect/return نرخ هر Device و Network را پایش کنید.

Click خرید Outcome نیست. Paid، Fulfilled، Returned و Kept باید با Window مناسب دیده شوند.

TCO؛ هزینه Embed صفر نیست

قیمت Plan امروز تصمیم سه‌ساله نیست. Fee درصدی با فروش رشد می‌کند، ارز و Eligibility تغییر می‌کنند و یک Integration ارزان ممکن است Manual work دائمی بسازد.

Product snapshot را به‌جای توصیه ابدی ثبت کنید

در تاریخ این بازبینی، مستندات رسمی Shopify «Buy Button» را Channel موجود در Subscription planها معرفی می‌کند و استفاده آن را وابسته به Payment gateway پشتیبانی‌شده در کشور/منطقه می‌داند؛ نام قدیمی Shopify Lite را نباید Plan جاری فرض کرد. Ecwid نیز در مستندات فعلی مسیرهای Embed کل Catalog، Category، Product card و Buy Button را توضیح می‌دهد، اما Plan/Feature/Payment availability باید همان روز خرید بررسی شود.

WooCommerce یک Plugin رایگان Core است، نه عملیات رایگان. مستندات Server requirements آن با نسخه‌ها به‌روز می‌شود؛ پیش از نصب باید Hosting/PHP/DB/HTTPS/memory و نیاز Extensionهای واقعی را روی صفحه رسمی جاری تطبیق دهید. هیچ نام محصولی «بهترین گزینه» عمومی نیست.

ریسک‌های ایران را قبل از Commit مالی بررسی کنید

• Provider خارجی ایران را برای Account، Payment gateway، Payout و Support می‌پذیرد؟
• پرداخت، تمدید Plan و خرید Extension با مسیر قانونی/پایدار ممکن است؟
• Export کامل Product/Customer/Order/Media و Backup خارج Provider دارید؟
• درگاه ایرانی، Callback/Verify، ریال/تومان و Refund جزئی پشتیبانی می‌شوند؟
• SMS، Carrier، پست/پیک، کدپستی، شماره +۹۸ و آدرس فارسی Integrate می‌شوند؟
• فاکتور، شرایط فروش، حریم خصوصی، مرجوعی و مجوزها با مشاور حقوقی ایران بررسی شده‌اند؟
• Network/Provider outage و Multi-ISP access چه Fallbackی دارند؟

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

Pilot چهارده‌روزه؛ قبل از Rollout عمومی

Scope Pilot

• یک تا پنج Product نماینده، یک Variant ساده و یک مورد پیچیده؛
• یک روش پرداخت و دو Shipping zone واقعی؛
• Guest journey و Order lookup/Support؛
• Refund/Cancel/Stockout و Payment unknown؛
• موبایل/دسکتاپ، RTL، Keyboard، شبکه کند و Cache cold.

Acceptance test

Pilot فقط سفارش موفق نیست؛ شکست‌های عمدی را هم اجرا کنید. Backup restore، Provider outage و Key rotation را متناسب با ریسک تمرین کنید.

Triggerهای مهاجرت کامل

• Product/Price/Stock دائماً میان دو پنل Drift می‌کند.
• Checkout/Payment/Shipping ایران با Provider Fit نیست.
• SEO به URL/Render/Canonical کنترل‌ناپذیر برخورد کرده است.
• Custom code برای دورزدن محدودیت از خود پلتفرم بیشتر شده است.
• Manual reconciliation و Support هزینه/خطای تکراری دارد.
• Role، Audit، Security یا Data residency نیاز کسب‌وکار را پوشش نمی‌دهد.
• Fee متغیر و App stack از TCO گزینه جایگزین عبور کرده است.
• Export/Exit نامطمئن و Vendor risk قابل پذیرش نیست.

قبل از Replatform، Goal و Cutover/rollback/redirect/data-reconciliation plan لازم است. «کنترل کامل» نیز بدون تیم عملیات مزیت خالص نیست.

برنامه ۳۰، ۶۰ و ۹۰روزه

روز ۱ تا ۳۰: Contract و انتخاب Boundary

• Offer/Catalog/Order/Fulfillment/Market/Risk/Growth را بنویسید.
• چهار الگو را با TCO، Payment fit، SEO، Security و Exit Shortlist کنید.
• Source-of-truth map، URL ownership و Order state machine بسازید.
• Provider/Extension را با Snapshot تاریخ‌دار و Evidence ارزیابی کنید.

روز ۳۱ تا ۶۰: Vertical slice

• Catalog→Cart→Payment→Order→Fulfillment→Refund را برای چند Product بسازید.
• Webhook/idempotency/reconciliation، Analytics و Alert را وصل کنید.
• SEO/Accessibility/RTL/Performance/Security test را اجرا کنید.
• Runbook و Kill switch/rollback را آماده کنید.

روز ۶۱ تا ۹۰: Pilot و Go/No-Go

• Pilot محدود را با سفارش واقعی کنترل‌شده اجرا کنید.
• Truth drift، Payment success، Reconciliation، Fulfillment، Support و Kept outcome را بسنجید.
• Go/Hold/Replatform را با Evidence و ظرفیت عملیات تصمیم بگیرید.
• اگر Scale می‌کنید، Ownership/RACI، Release gate و Quarterly exit test را تثبیت کنید.

Runbookهای ضروری

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

آیا می‌توان به هر سایتی فروشگاه اضافه کرد؟

از نظر فنی اغلب می‌توان Hosted link یا Embed افزود، اما Fit به امکان Script/HTML، Payment region، URL/SEO، Cookie، Accessibility، Performance و عملیات Order بستگی دارد. «قابل Embed» معادل «آماده فروش پایدار» نیست.

Buy Button برای شروع کافی است؟

برای چند Offer ساده و Pilot ممکن است کافی باشد، به شرط اینکه Price/Stock، Checkout، پرداخت، Order، Fulfillment، Refund، Analytics و Support آزموده شوند. با Variant/Inventory/Integration پیچیده، Button به‌تنهایی Architecture نیست.

افزونه Commerce بهتر است یا فروشگاه میزبانی‌شده؟

پاسخ عمومی ندارد. افزونه کنترل و Integration بومی بیشتری می‌دهد اما Hosting/Update/Security می‌خواهد؛ Hosted service عملیات زیرساخت را کم می‌کند اما محدودیت Region/Payment/UX/Export دارد. TCO و Pilot تعیین‌کننده‌اند.

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

می‌تواند سالم یا مشکل‌دار باشد. Search owner، URL، لینک crawlable، Rendered content، Canonical، Schema، Sitemap، Variant و Duplicate provider page را آزمایش کنید. افزودن Product page خودکار رتبه یا تازگی مثبت نمی‌سازد.

چه زمانی باید به پلتفرم فروشگاهی کامل مهاجرت کنیم؟

وقتی Drift داده، محدودیت پرداخت/SEO/Role/Security، Manual operations، Fee/TCO یا Exit risk تکراری از هزینه مهاجرت بیشتر شده است. تصمیم باید با Pilot مقصد، Cutover، Redirect، Reconciliation و Rollback همراه باشد.

منابع فنی و Product snapshot

• Shopify Help: Buy Button؛ قابلیت و محدودیت جاری، نه Plan قدیمی Lite
• Ecwid Help: راه‌های افزودن Commerce به سایت موجود
• WooCommerce Server Requirements؛ نسخه جاری را هنگام اجرا بررسی کنید
• Google Ecommerce URL Structure
• PCI SSC FAQ 1588 برای Script boundary در Embedded payment page؛ Scope را با Acquirer/Provider تأیید کنید

جمع‌بندی: بهترین راه تبدیل سایت موجود به فروشگاه، کوتاه‌ترین کد Embed نیست؛ کوچک‌ترین Boundaryای است که Product truth، پرداخت، سفارش، Fulfillment، SEO، امنیت و Exit را قابل کنترل نگه می‌دارد و در Pilot واقعی شواهد قبولی می‌سازد.