Skip to main content
Version: v2.0.4 latest

Testing & Troubleshooting

How to test the flow​

  1. Configure for visibility. Set availablePaymentMethods to include ALIPAY and paymentMethodChoice = ON_SDK. In the example app, open Debug options, tick Pay with Super Qi, set selection to ON_SDK, and tap Apply config.
  2. Start a payment. Trigger the normal payment flow with a valid paymentId from your gateway.
  3. Confirm the chooser. The SDK's method screen should list "Pay with Super Qi" next to card.
  4. Open the Super Qi screen. Tap it and verify the first option matches your showFirst (QR or LINK).
  5. Exercise the fallbacks. With qrToDeepLinkFallback/deepLinkToQrFallback on, confirm the secondary option (open-app button or QR) is present.
  6. Complete or cancel. Approve in the Super Qi app to see the result screen; or back out to confirm the "close without saving?" dialog behaves as expected.
Watch the native logs

Both bridges log the resolved configuration. On Android: adb logcat | grep -i "payment methods" shows lines like Available payment methods: [CARD, ALIPAY], choice: ON_SDK. This is the fastest way to confirm your Dart arguments actually reached the SDK.

Troubleshooting​

Super Qi button doesn't appear​

Work down this list in order:

CheckFix
Is ALIPAY in availablePaymentMethods?It's off by default. Add it.
Is paymentMethodChoice = ON_SDK?The SDK only draws a chooser in ON_SDK. The default is ON_APP (no chooser).
Did the arguments reach native?Check logcat / Xcode console for the "Available payment methods" log line.
Did an empty list get sent?The bridges fall back to card-only when the list is empty — so Super Qi silently disappears. Ensure at least ALIPAY is included.
Is the SDK initialized with the new config?A runtime updatePaymentMethods only works after init. Re-initialize if needed.

ON_APP doesn't launch Super Qi​

In ON_APP mode the SDK does not show a chooser — your app must pass paymentType = ALIPAY in the payment details. The example app's processPayment only sets CARD or PAYMENT_TOKEN (it picks based on whether a saved token is present), so it cannot trigger Super Qi in ON_APP mode.

Fix: either use ON_SDK (recommended for this app), or extend processPayment on both native sides to accept and set PaymentType.ALIPAY / .ALIPAY.

Crash on payment: null accountId​

SDK 2.0.4 rejects a null accountId when constructing CustomerInfo. Symptoms appear right after starting a payment, not at init.

Fix: always pass a non-null account id. The Android bridge already guards this by falling back to a generated id when the customer id is blank (generateFakeAccountId() in MainActivity.kt). Make sure your own integration supplies a real account id in production.

QR shows but the Super Qi app never opens (same device)​

The customer is on the same phone and scanning a QR is awkward. Turn on qrToDeepLinkFallback so an "Open Super Qi" button appears alongside the QR — or set showFirst = LINK for same-device-first journeys.

Enable deepLinkToQrFallback so the SDK also shows a QR / download path when the app can't be opened.

Runtime update returns false / SDK_NOT_INITIALIZED​

You called updatePaymentMethods before the SDK was initialized. In the example app the service (payment_service.dart) handles this by storing the config and applying it at the next initialize. If you call the channel method directly, initialize first.

MissingPluginException / method not implemented​

The channel method isn't registered on one of the platforms. Confirm updatePaymentMethods exists in the channel when/switch in both MainActivity.kt and AppDelegate.swift. See Flutter Integration → native bridges.

Pre-release checklist​

  • ALIPAY included in availablePaymentMethods.
  • paymentMethodChoice matches your UX (ON_SDK for SDK-drawn picker).
  • showFirst matches your primary journey (QR for cross-device, LINK for same-device).
  • Fallback flags set appropriately for your audience.
  • accountId is always non-null in production payments.
  • Button label reads "Pay with Super Qi", never "ALIPAY", in every locale.
  • updatePaymentMethods registered on both native platforms (if you use runtime switching).
  • Tested success, cancel, and fallback paths on a real device.

See also​