خطاها و چک‌لیست آزمون SDK
خطای ساختاریافته، آفرینگ خالی، نتیجه خرید نامشخص، قابلیت پشتیبانی‌نشده و چک‌لیست امن انتشار.
موفقیت فراخوانی، نبود انتخاب و شکست شبکه را جدا نگه دارید. خطای شبکه را «کد تخفیف نامعتبر» یا «اشتراک ندارد» ترجمه نکنید.
خواندن نتیجه
Flutter: ابتدا result.isSuccess، سپس result.data یا result.failure را بخوانید؛ failure شامل code، message، isRetryable و details است. Kotlin از InappifyResult.Success یا Failure.error با همین مفهوم استفاده می‌کند. بعضی جست‌وجوهای موفق null می‌دهند. JavaScript Promise را reject می‌کند؛ با isInAppifyError(error) خطای SDK را از خطاهای دیگر جدا کنید.
پیام diagnostic را بدون بررسی به کاربر نمایش ندهید. retryable مجوز تکرار کورکورانه پرداخت نیست؛ همان تلاش و context قبلی را حفظ کنید. credential، receipt، ticket و URL کامل پرداخت را در لاگ یا تیکت عمومی قرار ندهید.
نشانه‌های متداول
| نشانه | بررسی |
|---|---|
| configuration / notConfigured | کلید عمومی همان اپ، شناسه پکیج/bundle و انتظار تا پایان configure |
| unauthorized | نشست و برنامه درست؛ توکن دست‌ساز یا fallback حساب دیگر ممنوع |
| network / timeout | وضعیت موقت؛ برای خرید، reconcile پیش از پرداخت بعدی |
| purchaseCancelled | پیام خنثی لغو؛ بدون grant |
UI_HOST_NOT_SUPPORTED | FlutterFragmentActivity یا AndroidX Activity معتبر |
PURCHASE_IN_PROGRESS | جلوگیری از شروع هم‌زمان و کلیک تکراری |
PRODUCT_TYPE_REQUIRED | catalog تازه و نوع محصول معتبر؛ نوع را حدس نزنید |
PURCHASE_PACKAGE_CONTEXT_REQUIRED | Package کامل برگشتی از آفرینگ |
RATE_LIMITED_NO_CACHE | رعایت سقف ۵/۶۰؛ استفاده از retry timing |
| unsupportedOperation | پشتیبانی واقعی پلتفرم، نه فقط وجود امضای متد |
| bridgeUnavailable روی وب | فراهم‌کننده JS bundle و پیش از Flutter بارگذاری شده باشد |
نام enumهای Kotlin و Flutter یکسان نیست؛ جزئیات native یا reason ممکن است داخل details باشند. مقدار نامشخص را به‌عنوان موفقیت مالی حدس نزنید.
آفرینگ خالی
کلید، محصول/پکیج، SKU، آفرینگ جاری، placement، شرایط هدف‌گذاری و مجوز feature وب را بررسی کنید. برای targeting مبتنی بر ویژگی، از مسیر sync پشتیبانی‌شده استفاده کنید. getOffering(id) نامعتبر نباید default را جایگزین کند.
پرداخت شده ولی نتیجه مشخص نیست
پرداخت دوم را خودکار شروع نکنید. Android همان attempt ذخیره‌شده را با history/events و در صورت نیاز syncStorePurchases() بررسی می‌کند. iOS از CustomerInfo جاری و Direct delivery پشتیبانی‌شده استفاده می‌کند؛ وب checkout ID را از سرور پیگیری می‌کند. وضعیت مشتری و تراکنش در پنل نیز به تشخیص کمک می‌کند. تحویل مصرفی ممکن است منتظر grant میزبان باشد.
چک‌لیست پیش از انتشار
- شروع مهمان و کاربر واردشده، restart، logout و تغییر حساب بدون داده حساب قبلی.
- current، placement، شناسه آفرینگ دقیق و نبود انتخاب؛ نمایش واحد قیمت دریافتی بدون تبدیل حدسی ریال/تومان.
- ثبت/حذف ویژگی و رفرش در سهمیه، صف خالی، خطای شبکه و محدودیت ۵/۶۰.
- خرید موفق، لغو، کلیک تکراری، قطع شبکه بعد از پرداخت و بسته‌شدن اپ.
- lookup نامشخص و رویداد نامرتبط بدون پاک‌کردن journal یا پرداخت دوباره.
- مصرفی با grant ماندگار، شکست confirm و restart بدون دوبرابرشدن موجودی.
- انقضای اشتراک، حق دسترسی غیرفعال و failure بدون ادعای دسترسی قطعی.
- وب با ticket/OTP، انتخاب آفرینگ تخفیف متفاوت و return جعلی بدون grant.
تست‌های عادی باید fake باشند و OTP یا خرید واقعی اجرا نکنند. بررسی زنده استور را با حساب/محصول آزمایشی مجاز انجام دهید؛ نمونه مستندات رایگان‌بودن تراکنش را تضمین نمی‌کند. بیلد و unit test، تأیید پرداخت واقعی یا استقرار backend نیستند.