پس از نصب، در درخواست نسخه SDK، پلتفرم و نتیجه موردنظر را بنویسید. لازم نیست credential، session token، receipt یا اطلاعات مشتری واقعی به ایجنت بدهید. نمونه‌های زیر برای فراخوانی صریح در Codex هستند؛ در ابزار دیگر Skill را با روش همان ابزار انتخاب کنید.
$inappify-sdk
این پروژه از inappify_sdk 0.2.1 استفاده می‌کند و هدف آن Android، iOS و Web است.
نسخه‌های resolveشده و مسیر مالک نشست را اول بررسی کن.
فراهم‌کننده وب @inappifylabs/web-sdk 0.2.0 است.
configure، ورود مناسب هر پلتفرم، نمایش placement به نام upgrade، خرید با Package
و بررسی premium را پیاده کن. قابلیت پشتیبانی‌نشده را صریح گزارش کن.
خرید، کش و بازیابی موجود را حفظ کن و پرداخت واقعی اجرا نکن.
$inappify-sdk
اتصال قدیمی اینپی‌فای را با API نسخه 0.2.1 هماهنگ کن.
اول dependencyها، wrapperهای میزبان و journal تلاش‌های نامشخص را پیدا کن.
از logIn، logOut، setAttributes و purchase با Package واقعی استفاده کن.
شناسه تلاش و context اصلی آن پس از restart، خطای شبکه و تغییر حساب حفظ شود.
روی Android حلقه بازیابی موازی نساز. هیچ کش یا موجودی را پاک نکن.
$inappify-sdk
در Android بعد از بسته‌شدن اپ، نتیجه یک تلاش خرید هنوز مشخص نیست.
فعلاً کد تغییر نده؛ مسیر saved attempt، purchaseUpdates و getPurchaseAttempt را بررسی کن.
lookup موفق با null یا نتیجه sync خالی را شکست خرید تلقی نکن.
پیشنهاد بده چطور فقط نتیجه همان تلاش و همان هویت reconcile شود.
$inappify-sdk
در Flutter Web، کد تخفیف باید برای offering انتخاب‌شده placement upgrade باشد.
شناسه offering را به getDiscountedPaymentLinksResult منتقل کن؛
از offering قیمت‌گذاری‌شده و code برگشتی در createCheckout استفاده کن.
شناسه نامعتبر نباید به default برگردد و catalog اصلی SDK نباید تغییر کند.
Android و iOS رفتار فعلی لینک تخفیف خود را حفظ کنند.
ایجنت باید نسخه واقعی، backend هر پلتفرم، متدهای انتخاب‌شده و محدودیت‌ها را توضیح دهد؛ برای کد از امضای public همان نسخه استفاده و آزمون متناسب انجام دهد. برای مثال، نباید combined sync یا cacheOnly را در پل Web فعلی پیاده‌شده فرض کند.
در پایان تفاوت «کامپایل/تست موفق» و «پرداخت زنده تأییدشده» روشن باشد. برای تغییرهای مالی، قواعد بازبینی و چک‌لیست SDK را مرور کنید.
