Troubleshooting
The messages below are what the SDK and the automation engine actually emit.
Session and setup
| Message | What it actually means | What to do |
|---|---|---|
SDK has not been initialized. Call OfInAppShoppingSdk.init(application) first. | A session call was made before init. | Call OfInAppShoppingSdk.init once at application start. See SDK setup. |
No active session. Call startSession first. | Either startSession was never called, or the session was closed or expired. | Check onSessionExpired is wired up. If it fired, mint a fresh exchange token from your backend and start again; tokens are single-use. |
No session keypair; call startSession first. | The device keypair is missing, which means the session never started successfully. | Same as above. Check CheckoutListener.onError for the underlying reason. |
WebView has no current URL. | The WebView had not finished loading anything when the call was made. | Wait for startSession to return, then drive your payment entry point from onCheckoutReady. |
Order and payment
| Message | What it actually means | What to do |
|---|---|---|
No payment flows. Request order details first. | Usually not what it says. readOrder most often was called, but on a page no configured payment flow matches, so no steps were prepared. | Check you are calling readOrder from the payment page, driven by onCheckoutReady, and not from a cart or voucher screen. See Call it from the page the customer is on. If detection is firing on the wrong page, the merchant's configuration needs narrowing; tell Open Fabric. |
Payment automation is already running. | pay was called twice concurrently. | Disable your pay control while a run is in flight. Retry only after a terminal callback. |
No card available for automation. | The cardFetchToken was blank or missing. | Confirm your backend returned card_fetch_token from the create-transaction call and that your app forwarded it intact. |
No payment flow completed. | Every configured flow was attempted and none finished. Surfaces via onFailure. | Nothing to fix in your integration. The merchant most likely changed their checkout; Open Fabric is notified automatically. Make sure your fallback lets the customer pay with the merchant's own methods. |
Element not found: <selector> | An automation step could not find the element it needed. Comes from the automation engine, not the SDK. | Same as above: a merchant-side change. Report it if it persists across sessions. |
Behaviours that look like bugs
onCheckoutReady fires once and never again. Expected. It fires on entering the checkout state, not on every navigation within it. On a single-URL SPA checkout that means once for the whole visit. See Detect checkout.
onCheckoutReady never fires on a merchant that clearly has a checkout. The DOM readiness conditions are not holding, most often because the merchant's pay control is still disabled, which is the intended behaviour. If it never becomes payable, the merchant's configuration is stale; tell Open Fabric.
onPaymentStatus fires twice. Expected when a 3DS or OTP challenge appeared. The first call carries REQUIRES_ACTION, which is not terminal. See Payment outcome.
Every payment reports UNCONFIRMED. The merchant has no payment_status_detection configured, or none of its outcomes match their current pages. Your integration is fine and the payments may well be settling. Confirm against the settlement events and raise the merchant with Open Fabric.
The customer taps a link and nothing happens. The SDK blocks navigations that are not http/https (intent://, wallet deep links and app handoffs) because a payment WebView must not hand control to an arbitrary app. The navigation is dropped silently. If a merchant's flow depends on one, tell Open Fabric which merchant and which scheme.
The merchant rejects the card form with a missing cardholder name. Open Fabric's virtual cards carry no cardholder name, so a merchant that requires one will not accept the automated fill. Report the merchant; these need handling in the merchant's configuration.
Getting help
When raising an issue, include: the merchant domain, the session_id, the payment_attempt_id if the payment stage was reached, the SDK version, and the callback and message you received. Those five let Open Fabric find the run.