Method Detail

• onPaywallPresented

   Unit onPaywallPresented(String paywallId)

• onPaywallAction

   Unit onPaywallAction(String paywallId, PaywallAction action)

• onPaywallPurchaseStarted

   Unit onPaywallPurchaseStarted(String paywallId, String productId)

• onPaywallPurchaseCompleted

   Unit onPaywallPurchaseCompleted(String paywallId, String productId, TransactionInfo transaction)

• onPaywallPurchaseFailed

   Unit onPaywallPurchaseFailed(String paywallId, Throwable error)

• onPaywallPurchaseFailed

   Unit onPaywallPurchaseFailed(String paywallId, Throwable error, String errorType)

  SPEC-070-B — same failure, plus a stable machine-readable discriminator (userCancelled / productNotFound / verificationFailed / networkError / serverError / pending / providerNotAvailable / unknown).

  WHY: a Throwable does not survive a Flutter/RN bridge, so wrappers (and hosts that don't want to when over a sealed class) had no way to distinguish a user cancel from a declined card. Defaulted to the 2-arg overload so every existing conformer keeps working unchanged — the SDK calls THIS one; hosts that only override the 2-arg still receive it.

• onPaywallPurchaseFailed

   Unit onPaywallPurchaseFailed(String paywallId, Throwable error, String errorType, String productId)

  SPEC-070-B — same failure, plus the product the user was actually trying to buy.

  WHY: onPaywallPurchaseCompleted / onPaywallPurchaseStarted both carry productId, but the FAILURE callback did not — so a paywall selling two plans (monthly + annual) told the host only "a purchase failed on paywall X". The host could not retry the right product, could not attribute the failure, and could not tell which plan the card was declined on. The purchase_failed ANALYTIC always carried product_id; the delegate silently dropped it.

  productId is nullable: some failures happen before a product is in play (e.g. the paywall config itself is missing — PaywallManager.present). Null means "no product was selected", never "unknown product".

  Defaulted through the 3-arg overload so every existing conformer (which may override the 2-arg or the 3-arg form) keeps compiling and keeps receiving the callback unchanged. The SDK always calls THIS one.

• onPaywallDismissed

   Unit onPaywallDismissed(String paywallId)

• onPromoCodeSubmit

   Unit onPromoCodeSubmit(String paywallId, String code, Function1<Boolean, Unit> completion)

• onPaywallRestoreStarted

   Unit onPaywallRestoreStarted(String paywallId)

• onPaywallRestoreCompleted

   Unit onPaywallRestoreCompleted(String paywallId, List<String> productIds)

• onPaywallRestoreFailed

   Unit onPaywallRestoreFailed(String paywallId, Throwable error)

• onPostPurchaseDeepLink

   Unit onPostPurchaseDeepLink(String paywallId, String url)

  Fired after a successful purchase when post_purchase.on_success.action == "deep_link".

• onPostPurchaseNextStep

   Unit onPostPurchaseNextStep(String paywallId)

  Fired after a successful purchase when post_purchase.on_success.action == "next_step".