> ## Documentation Index > Fetch the complete documentation index at: https://documentation.idenfy.com/llms.txt > Use this file to discover all available pages before exploring further. # BigCommerce > Add identity verification to your BigCommerce store. Choose when shoppers verify, set a cart rule, and hold orders until customers are verified, all from the BigCommerce control panel with no theme edits. ## Overview The iDenfy BigCommerce app adds identity verification to your store. Decide **when** shoppers verify (4 flows), **which carts** need it (an optional custom rule), and keep orders from unverified customers **on hold** until they verify, all from the BigCommerce control panel. > [card] [Install the App](#quick-start) > > Install from the BigCommerce App Marketplace and connect your iDenfy account. > [card] [Pick a Verification Flow](#verification-flows) > > After registration, before checkout, custom, or after checkout. > [card] [Set a Custom Rule](#custom-rule) > > Ask for verification only when the cart reaches an amount or holds specific products or categories. > [card] [Hold Orders](#order-hold) > > Every flow keeps orders from unverified customers on hold until they verify. *** ## How It Works The app runs inside the BigCommerce control panel and opens from the **Apps** menu. It has a **Home** page and a **Settings** page with three tabs: **Connection**, **Verification settings**, and **Customers**. The **Help** link in the app header opens [iDenfy support](https://idenfy-ivs.atlassian.net/servicedesk/customer/portal/1). When you pick a verification flow, the app sets up these parts through the BigCommerce API. There is no theme to edit. | Part | What it does | | - | - | | **Storefront script** | Runs on your storefront pages. It asks shoppers to verify at the moment your flow sets, and shows a banner to shoppers who still need to. | | **Order confirmation script** | Shows a shopper whose order is on hold a panel to verify from. | | **Order webhooks** | Tell the app about new orders, so it can hold orders from unverified customers. | Nothing runs on the checkout page where shoppers pay. Verification opens iDenfy's hosted UI in a modal on your store, so the shopper never leaves your site. iDenfy then sends the result back to the app, which: * stores the result and shows it on the **Customers** tab; * writes an `idv_status` attribute on the BigCommerce customer; * releases that customer's held orders, if the result is Approved. Shoppers are identified by their BigCommerce customer account, so **only signed-in shoppers can be verified**. Guests have no customer ID. The storefront proves who the shopper is with BigCommerce's signed customer token, so a browser can't start or check a verification for another customer. Each verification reaches iDenfy with the client ID `bc:{storeHash}:{customerId}`. Search for it in the iDenfy dashboard to find a shopper's verification. Documents, photos, and biometric data stay with iDenfy; see [Data and Privacy](#data-and-privacy) for what the app keeps. > [!NOTE] > > **You don't need to manage any of the moving parts.** The app installs and removes its scripts and webhooks, receives results from iDenfy, and holds and releases orders. This section is here so you know what to look for when something doesn't behave as expected. *** ## Quick Start > [!NOTE] > > **Requirements** > > * An iDenfy account ([see pricing](https://idenfy.com/pricing-plans-v4/)). Use your **production** API keys for live shoppers. > * A BigCommerce store on a **Stencil theme**, using the **default storefront** (channel 1) and BigCommerce's **Optimized One-Page Checkout** > * **Customer accounts at checkout.** Guests can't be verified or held, so turn off guest checkout (step 5) > [!WARNING] > > **Not supported:** Catalyst or other headless storefronts, and additional Multi-Storefront channels. Orders placed on other channels are never held. **1. Install the iDenfy App** Install the app from the BigCommerce App Marketplace and approve the requested permissions. The app then opens in your control panel. | Permission | Level | Why the app needs it | | - | - | - | | **Customers** | Modify | Write the `idv_status` customer attribute and read customer names and emails | | **Orders** | Modify | Register the order webhooks, and move orders into and out of hold | | **Products** | Read-only | Search products and categories for the custom rule | | **Content** | Modify | Install the storefront script | | **Checkout Content** | Modify | Install the order confirmation script | | **Checkouts** | Read-only | Read your guest checkout setting, for the **Guests bypass verification** warning | **2. Connect Your iDenfy Account** On the app's **Home** page, click **Connect iDenfy** and choose one of two methods. If you don't have an iDenfy account yet, use the **Create an account** link in the dialog. > [tab] Sign in with iDenfy (Recommended) > > Enter your iDenfy dashboard **Username or email** and **Password**, then click **Connect**. If your account uses two-factor authentication, an **Authenticator (2FA) code** field appears. > > The app creates a new API key pair in your iDenfy account and **registers the results webhook for you**, so you can skip step 3. > > * The app signs in from its own server. The first time, iDenfy may email you to confirm a sign-in from a new location. Confirm it, then click **Connect** again. > * If your iDenfy account only accepts sign-ins from approved IP addresses, use **Enter manually** instead. > [tab] Enter Manually > > Paste the **API Key** and **API Secret** from [Dashboard → Settings → API Keys](https://documentation.idenfy.com/guides/dashboard/settings/api-keys.md), then click **Save & validate**. The app checks the pair with iDenfy before saving it. > > The dialog also shows the **Webhook receiver URL** you need in step 3, with a copy button. > > > [!WARNING] > > > > The API secret is encrypted in storage and **cannot be read back** after saving. Keep a copy somewhere safe: you also need it as the webhook signing key in step 3. Once connected, the Home page shows **Choose when shoppers verify**, a **Connected** badge, your masked API key, and the **Choose a verification flow** and **Reconnect** buttons. **3. Set Up the iDenfy Webhook (Manual Connect Only)** Skip this step if you connected with **Sign in with iDenfy**. On the [iDenfy Dashboard → Webhooks](https://admin.idenfy.com/settings/v2/system-notifications), add a webhook: * **Receiver:** `https://bigcommerce.idenfy.com/api/idenfy/webhook`. It's the same for every store, and the app also shows it on **Settings → Connection** under **Results webhook**. * **Event type:** **ID VERIFICATION**, listed as *ID VERIFICATION (Legacy)*. It's the one event that carries every result, including manual reviews and expired sessions. This is also the event that **Sign in with iDenfy** registers. * **Signing key:** your iDenfy **API secret**. > [!WARNING] > > **Use the API secret, not the API key, as the signing key.** The app checks every result's signature against your API secret. With any other signing key, every result is rejected and no verifications appear in the app. **4. Choose a Verification Flow** Click **Choose a verification flow** on the Home page, or go to **Settings → Verification settings**, and click one of the four flow cards. See [Verification Flows](#verification-flows) for how they differ. The change takes effect immediately; there is no Save button. The Home page then shows **You're all set** and the active flow. **5. Turn Off Guest Checkout** Require shoppers to have an account: in the BigCommerce control panel, go to **Settings → Checkout** and turn off guest checkout. Guest orders carry no customer ID, so no flow can verify or hold them. Until you do, the app shows a [warning](#guest-checkout-warning). **6. Test It** Sign in to your storefront with a customer account that hasn't been verified, and go through the flow you picked. The result appears on the app's **Customers** tab. To test without real documents, connect with your **sandbox** API key pair using **Enter manually**, and set up the webhook as in step 3. See [Testing and Sandbox](https://documentation.idenfy.com/guides/testing-sandbox.md). Reconnect with your production keys before going live. > [!NOTE] > > Only **store administrators** can change settings or act on verifications: the user who installed the app, and the store owner. Other control panel users with access to the app can view it, but see *"Only store administrators can perform this action."* when they try to make a change. *** ## Verification Flows Choose the flow under **Settings → Verification settings → Verification flow**. Pick the one moment in your store where shoppers are asked to verify: * Exactly **one** flow is active at a time. Selecting a flow turns off the others. * Clicking the active card turns verification **off**. * Each card shows **Updating…** while a change applies, then **Active** or **Off**. * Until your iDenfy account is connected, the tab shows *"Connect iDenfy first"* instead. | Flow | When the shopper is asked | Orders held | | - | - | - | | **After account registration** | Right after sign-up, then by a banner and at checkout until they verify | All orders from unverified customers | | **Before checkout** | When they click a checkout button | All orders from unverified customers | | **Custom** | When they click a checkout button and the cart matches your [rule](#custom-rule) | Orders that match your rule | | **After checkout** | After placing the order, on the order confirmation page | All orders from unverified customers | In every flow: * A customer whose status is **Approved** is never asked again. Verification happens once per customer, not once per order. * Every other status counts as unverified: Pending, Reviewing, Suspected, Denied, Expired, Revoked, and customers who never started. * Orders from unverified customers are [held](#order-hold). The prompts on your storefront are how shoppers are asked; the order hold is what enforces it. > [!WARNING] > > **The storefront prompt can be bypassed; the order hold can't.** The prompts run in the shopper's browser: > > * If the app can't respond within 3 seconds, checkout goes ahead. > * Express payment buttons and direct links to the checkout page don't go through a checkout button. > * Guests can choose **Continue as guest**. > > Orders from signed-in shoppers that get past the prompt are held until they verify. Guest orders can't be held, so turn off guest checkout. > [accordion] After Account Registration > > Card text: *"Shoppers verify right after they create an account, and can't check out until they do."* > > On the first store page a shopper opens after creating an account, a modal opens: > > * **Verify your identity**: "Your account has been created. To finish, please complete a quick identity verification powered by iDenfy. You'll need it to check out." > * Button: **Start verification**. There is no skip option; the **×** in the corner or **Esc** closes the modal. > > Until they verify: > > * A [banner](#the-verification-banner) under your store's header reads **Verify your identity.** "Please complete a quick identity verification, powered by iDenfy, before you check out." In this flow it has no **×**. A shopper who goes to their account pages straight after sign-up sees this banner instead of the modal. > * Checkout buttons ask them to verify, as in [Before checkout](#verification-flows). > * Orders that get past the prompt are held. > > Customers who registered before you turned this flow on see the banner and the checkout prompt the next time they sign in. > > On the Customers tab, verifications started from the modal or the banner show Flow = **Registration**, and those started at checkout show **Checkout**. > [accordion] Before Checkout > > Card text: *"Signed-in shoppers verify once, before their first checkout."* > > On any storefront page, including the cart page and the header mini-cart, when a signed-in, unverified shopper clicks a checkout button, a modal opens: > > * **Verify your identity to check out**: "This store requires a quick identity verification (powered by iDenfy) before your first order." > * Button: **Start verification**. The **×** in the corner closes the modal, and checkout stays blocked. > > Once the shopper is approved, checkout continues automatically. > > **Guests** who click checkout see **Identity verification required**: "This store requires identity verification before checkout. Please sign in or create an account to verify your identity." Buttons: **Sign in**, **Continue as guest**, and **Close**. > > The app recognizes standard Stencil (Cornerstone) checkout buttons: links to `/checkout`, `.button--checkout`, `[data-cart-checkout-button]`, and `#checkout-app-button`. These can't be changed in the app. > > Orders that get past the prompt, for example through an express payment button, are held. The shopper can verify from the order confirmation page or the [banner](#the-verification-banner). > > On the Customers tab, these verifications show Flow = **Checkout**. > [accordion] Custom > > Card text: *"Like Before checkout, but only when the cart matches your rule."* > > The same experience as Before checkout, but only when the cart matches your [custom rule](#custom-rule). > > * The cart is checked again on **every checkout click**, so quantity changes made on the cart page count. > * Guests whose cart matches see the sign-in prompt. Category matching needs a signed-in shopper, so guests are matched on the cart total and specific products only. > * With no rule fields filled in, Custom behaves exactly like Before checkout. > * Only orders that match the rule are held. The app checks the placed order against the same rule. > * On the order confirmation page, the panel appears once the app has held the order, which can take a few seconds. If the shopper already has an order on hold, the panel counts their held orders instead: "You have an order on hold. It will be processed once you complete a quick identity verification." > > On the Customers tab, these verifications show Flow = **Checkout**. > [accordion] After Checkout > > Card text: *"Hold new orders from unverified customers until they verify."* > > The shopper checks out normally, and the app moves the order to **Manual Verification Required**. See [Order Hold](#order-hold). > > On the **order confirmation page**, a panel appears inside the order details: > > * **Identity verification required**: "Your order is on hold and will be processed once you complete a quick identity verification." > * Button: **Verify your identity**. It opens iDenfy directly, without an intro screen, and has an **×** to close it. > > After approval, the panel changes to **Identity verified**: "Thank you — your identity has been verified and your order will be processed shortly." The order returns to its previous status automatically. > > A shopper who leaves without verifying can verify later from the [banner](#the-verification-banner), or from a link you send them (see [Send a Verification Link](#send-a-verification-link)). > > On the Customers tab, these verifications show Flow = **Checkout**. ### The Verification Banner A signed-in shopper with an order on hold sees a banner under your store's header until they verify. It appears on home, category, product, cart, search, and content pages. * **Identity verification required.** "You have an order on hold. It will be processed once you complete a quick identity verification." With more than one held order, it gives the count: "You have 2 orders on hold. They will be processed…" * **Verify your identity** opens iDenfy directly. * The **×** (*Not now*) hides the banner until the shopper's next visit. * After approval, the banner turns green: "Thank you — your identity has been verified and your order will be processed shortly." In **After account registration**, the banner shows for every signed-in customer who isn't verified, with the text **Verify your identity.** "Please complete a quick identity verification, powered by iDenfy, before you check out." It has no **×** in that flow. The banner doesn't appear on My Account, Login, or checkout pages: BigCommerce doesn't load the storefront script there. On phones, when the theme's header is fixed to the top of the screen, the banner sits at the top of the page content instead. ### What Shoppers See After Verifying Every verification in a modal ends on one of these screens: | Screen | Text | | - | - | | **Verification complete** | "Thanks — your identity has been verified." with a **Continue** button | | **Verification pending review** | "Your verification needs further review. We will be in touch shortly." | | **Verification not completed** | "We could not verify your identity. You can try again at any time." | | **Too many attempts** | "You have reached the limit of verification attempts for now. Please try again later." See [Credits and Attempt Limits](#credits-and-attempt-limits). | *** ## Storefront Setup There is nothing to enable in your theme. Choosing a flow installs two scripts, listed in your store's **Script Manager**: | Script | Loads on | | - | - | | **iDenfy identity verification** | Storefront pages: home, category, product, cart, search, and content pages | | **iDenfy identity verification on order confirmation** | The order confirmation page | Switching flows replaces the scripts, turning verification off removes them, and BigCommerce removes them automatically when you uninstall the app. Don't edit or delete them by hand; if they're missing or outdated, the app offers an [update](#maintenance-banners). * **Checkout page.** No script loads on the checkout page where shoppers pay. The checkout prompt acts on the button that leads there. * **Cookie consent.** Both scripts are registered in the **Essential** cookie category, so they load before the shopper accepts cookies. Without this, the checkout prompt wouldn't load for shoppers who haven't accepted. You may want to mention it in your cookie policy. * **Look and feel.** The modal, banner, and order panel can't be customized: there are no style settings and no editable text. The modal carries iDenfy branding (the iDenfy logo, a purple button, and a "Powered & trusted by iDenfy" footer). The banner and order panel use your theme's font. Their text is in **English only**. * **Verification UI.** The verification steps inside the modal follow your iDenfy dashboard settings, including languages and branding. * **Accessibility.** The modal is a keyboard-accessible dialog: **Esc** closes it, and focus stays inside it while it's open. > [accordion] Debug Mode > > To see what the script is doing on a page, add `?idenfy_debug=1` to any storefront URL, or run `localStorage.idenfy_debug = '1'` in the browser console and reload. > > The console then shows `[idenfy]` lines: the flow loaded, whether the shopper is a guest or signed in, their verification status, the cart summary, the cart check result, and the final decision. If no `[idenfy]` lines appear, the script isn't loading. *** ## Custom Rule The rule panel appears below the flow cards when **Custom** is active. Verification is required at checkout when the cart matches **any** of these conditions. Leave them all blank to require verification for every checkout. | Field | Behavior | | - | - | | **Cart total** | Ask for verification once the cart total reaches this amount, in your store currency. Leave blank for no threshold. | | **Specific products** | Search your catalog by name, SKU, or description (up to 20 matches per search). Choose up to 50 products. Any of them in the cart triggers verification. | | **Product categories** | Search your store's categories by name; the search covers the first 250. Choose up to 50 categories. Any product in the cart from one of them triggers verification. | * The conditions are combined with **OR**. * **Save rule** is enabled only when something has changed. On success, the panel shows *"Rule saved."* * The same rule decides which orders are [held](#order-hold). * A product matches only the categories it's **directly assigned to**. Choosing a parent category doesn't cover products assigned only to its subcategories. * The cart total is the amount after discounts and coupons, including tax where it applies, and before shipping. It's compared as a number in the **cart's currency**, so on a multi-currency store the threshold applies to whichever currency the shopper is using. *** ## Identity Check Settings ### Which Checks Run The identity checks themselves, such as accepted document types, liveness, AML, and age, are configured in the [iDenfy dashboard](https://documentation.idenfy.com/guides/dashboard/settings/configuration.md) for the connected API key, not in the app. Under **Result handling**, the app has two switches. Each is saved as soon as you change it, and the tab shows *"Saved."* ### Match the Name on the Customer's Account When this is on, the app sends the customer's first and last name from their BigCommerce account to iDenfy with each new verification. If the name doesn't match the ID document, iDenfy returns **Suspected**. The app reads the name from BigCommerce when the verification starts and doesn't store it. Off by default. When it's off, no names are sent. ### Accept Suspected Verifications This decides what happens to results that iDenfy flags as Suspected: * **Off (default):** a Suspected result stays Suspected. The customer counts as unverified, and held orders stay held until you decide on the **Customers** tab. * **On:** a Suspected result is recorded as **Approved** and marked *auto-approved (suspected)* on the Customers tab. The shopper sees the success screen, and held orders are released. ### Guest Checkout Warning When a flow is active and your store allows guest checkout, the Verification settings tab shows a **Guests bypass verification** warning: *"This store allows checkout without an account. Guest orders carry no customer ID, so they cannot be verified or held. Require shoppers to create an account at checkout to close this gap."* Click **Open checkout settings** to change the setting in BigCommerce. If the app can't read the setting, it shows a neutral **Check your guest checkout setting** note instead. ### Credits and Attempt Limits * Each new iDenfy verification session uses a verification credit. * A shopper's unfinished session is reused at no extra cost for 24 hours. If they don't start it in that time, it expires, and the next prompt creates a new one. * A shopper can start at most **5 new sessions in 24 hours**. After that, they see **Too many attempts** and can try again later. * Links you create with **Copy verification link** don't count toward that limit. * Connecting doesn't create a verification session: the app checks your API keys with a read-only request. Only if iDenfy doesn't answer that request does the app create a test session instead, with a client ID starting `bc-validate-`. *** ## Order Hold The order hold is on in **every flow**. It's the step that stops orders from unverified customers, whatever happened on the storefront: * **After checkout:** the hold is the flow itself. * **Before checkout** and **After account registration:** it catches orders that got past the storefront prompt. * **Custom:** it holds only orders that match your rule. An order is held when **all** of these are true: * the customer was signed in (guest orders are never held); * the order was placed on the default storefront (channel 1); * the order status isn't **Incomplete**, **Refunded**, **Cancelled**, or **Declined**; * the customer's verification status isn't **Approved**; * in **Custom**, the order matches your rule. For card payments, BigCommerce creates the order as **Incomplete** until the payment goes through. The app holds the order as soon as it leaves Incomplete. **1. Order Placed** The app moves the order to BigCommerce's built-in **Manual Verification Required** status and remembers the status it had before. The customer is listed on the Customers tab as **Pending**. **2. Shopper Prompted** The shopper sees the verification panel on the order confirmation page, and the [banner](#the-verification-banner) on your storefront afterwards. No email is sent; you can [send a verification link](#send-a-verification-link) yourself. **3. On Approval — Auto-Release** The order returns to its previous status. Approval can come from iDenfy, or from you setting the customer's status to **Approved** on the Customers tab. All of that customer's held orders are released together. An order you've already moved out of Manual Verification Required keeps the status you gave it. **4. Any Other Result — Stays Held** Orders stay on hold for Denied, Suspected, or Expired results, or when the shopper never tries. Cancel or refund them yourself in BigCommerce. > [!WARNING] > > Orders are held until the customer is approved. The app doesn't cancel or refund orders, and there is no timeout. > [!WARNING] > > **Payment methods that confirm payment later.** Some payment providers update an order's status after it's placed, once the payment clears. That update can move a held order out of Manual Verification Required before the customer verifies. Check the customer's status on the Customers tab before fulfilling orders paid this way. ### Releasing Held Orders Without Verification If you turn verification off or disconnect iDenfy, new orders are no longer held, but orders already held stay in Manual Verification Required. Each is still released if its customer is approved. While such orders remain, the Home and Settings pages show a **N orders are still on hold** notice with a **Release all** button. It returns each order to its previous status, whether or not its customer verified, then reports how many were released. Orders you've already moved out of Manual Verification Required are left as they are. To release one customer's orders, set their status to **Approved** on the Customers tab. > [accordion] Edge Cases > > * The hold needs BigCommerce's built-in **Manual Verification Required** order status. If the app can't find it, choosing a flow fails with *Could not resolve the "Manual Verification Required" order status.* > * Changing a customer from Approved to another status doesn't hold orders that were already released. Their **future** orders are held. > * **Revoke** and **Revoke & erase iDenfy data** leave that customer's held orders on hold. > * Switching between flows keeps the hold on. Turning verification off stops new holds. > * If you change a held order's status yourself, the app leaves it as you set it. *** ## Managing Verifications The **Settings → Customers** tab lists every customer who has been asked to verify, with their current iDenfy verification status. A customer appears once they **start** a verification, an order of theirs is **held**, or a result arrives. A shopper who only saw a prompt isn't listed. Search by email (partial and case-insensitive), and show 10, 20, 50, or 100 rows per page, most recently updated first. | Column | Shows | | - | - | | **Customer** | Name over email. The name is read from the BigCommerce account each time the list loads; the app doesn't store it. | | **Status** | The current status, as a colored dropdown you can change | | **Flow** | **Registration**, **Checkout**, or **Manual** (a link you sent) | | **Updated** | When the record last changed | ### Changing a Status Use the **Status** dropdown to set **Approved**, **Denied**, **Suspected**, or **Reviewing**. * Setting **Approved** releases the customer's held orders. * Moving a customer away from Approved asks for confirmation: **Change status from Approved?** They're asked to verify again on future orders, and orders that were already released stay released. ### Send a Verification Link To reach a shopper yourself, open the **⋯** menu on their row and choose **Copy verification link**. It isn't offered for Approved customers. The **Verification link** dialog shows a link to send by email or however you usually reach the customer. They verify on iDenfy's page, the result appears on the Customers tab automatically, and any order of theirs on hold is released once they're approved. Under the link, the dialog shows the date and time it stops working: *"Works until … , or until it is used."* * The app reuses the customer's unfinished session if it has at least 12 hours left. Otherwise it creates a new one, which uses a credit and sets the status to **Pending**. * These links don't count toward the shopper's [attempt limit](#credits-and-attempt-limits). * Verifications started this way show Flow = **Manual**. ### Revoke The **⋯** menu also has two ways to revoke a customer. Both ask you to confirm first, set the status to **Revoked**, and ask the customer to verify again next time. Held orders stay held. * **Revoke** marks the customer as unverified. Their verification data stays in iDenfy. * **Revoke & erase iDenfy data** also **permanently deletes their photos and document data from iDenfy**. It can't be undone. ### Customer Details Click the eye icon on a row to see: * **Contact:** name, email, and customer ID. * **Verification:** status; how it was set (*From iDenfy / verification flow*, *Auto-approved (suspected)*, or *Manually set*, with the ID of the user who set it); flow; the raw iDenfy status; scan reference; first seen; last updated; and session created. * **Risk signals:** suspicion reasons, fraud tags, and mismatch tags from iDenfy. * **Recent orders:** the last 5, each linking to the order in your control panel. ### What the App Writes to BigCommerce * **Customer:** an `idv_status` customer attribute (text), created the first time it's needed. It's set when a final result arrives, when you change the status, or when you revoke: `APPROVED`, `DENIED`, `SUSPECTED`, `EXPIRED`, `REVIEWING`, or `REVOKED`. It isn't set while a session is only pending. Other apps and integrations can read it through the BigCommerce Customers API. * **Order:** only the status change to and from **Manual Verification Required**. Nothing else is written: no order notes, tags, or other fields, and the customer's name, email, and phone aren't changed. *** ## Connection, Disconnect and Uninstall The **Settings → Connection** tab shows a **Connected** or **Not connected** badge and your masked API key. The API secret is encrypted and can't be displayed after saving; reconnect to replace your credentials. Under **Results webhook**, the tab shows either *"Set up automatically in your iDenfy account when you signed in"*, or, for a manual connect, the **Receiver URL** to add in iDenfy, with a copy button. * **Reconnect** opens the same dialog as the first connection. With **Sign in with iDenfy**, it creates a new API key and webhook, then deletes the previous ones the app created in your iDenfy account. If reconnecting fails, your existing setup keeps working. * **Disconnect** asks you to confirm, then removes the storefront scripts and order webhooks and clears your saved credentials. Shoppers stop being asked right away, and new orders are no longer held. Verification records are kept, and orders already on hold stay held (release them from the [notice](#releasing-held-orders-without-verification)). The API key and webhook stay in your iDenfy account; delete them there if you no longer need them. Afterwards no flow is active, so pick one again after reconnecting. * **Uninstalling** the app makes BigCommerce remove the storefront scripts. The app deletes everything it holds for your store: credentials, settings, verification records, and held-order records. > [!WARNING] > > **Before you uninstall**, release any orders still in **Manual Verification Required**: the app can't change orders once it's uninstalled. Turn verification off by clicking the active flow card, then click **Release all** on the notice that appears. > > Uninstalling also leaves behind the API key and webhook in your iDenfy account, and the `idv_status` customer attribute and its values. ### Maintenance Banners The Settings page shows a banner when the app's setup in your store needs attention: * **Update your storefront setup**: your scripts or order webhooks were set up by an earlier version of the app. Click **Update now** so verification works on every page and every order is held. * **App URL has changed**: the scripts and webhooks point to an old address of the app. Click **Repair now**. If you connected with Sign in with iDenfy, reconnect afterwards to re-register the iDenfy webhook. *** ## Data and Privacy The app keeps only what it needs to remember each customer's verification status and the orders it holds. | Stored by the app | Details | | - | - | | **Verification record** | BigCommerce customer ID, email, status, the raw iDenfy status, scan reference, iDenfy's suspicion, fraud, and mismatch tags, the flow, and timestamps. While a session is unfinished, also its iDenfy session token and link. | | **Held-order record** | Order ID, customer ID, the order's previous status, and when it was held and released | | **Store connection** | Your iDenfy API key and secret, and the app's BigCommerce access token. The secret and the token are encrypted at rest (AES-256-GCM). | * **Not stored:** names, documents, photos, biometric data, or document numbers. Documents, photos, and biometric data stay in your iDenfy account. Names are read from BigCommerce when you open the Customers tab and, with [name matching](#identity-check-settings) on, sent to iDenfy when a verification starts. * **Shopper contact:** the app sends no emails or messages to shoppers. * **Erasing:** **Revoke & erase iDenfy data** deletes a customer's verification data in iDenfy. Uninstalling deletes everything the app stores for your store. *** ## Reference ### Verification Statuses | Status | Meaning | Set by | | - | - | - | | **Pending** | A session was created, or an order was held, and there's no result yet | The app | | **Reviewing** | iDenfy sent an interim result, for example while a manual review is in progress | iDenfy or you | | **Approved** | Verified | iDenfy or you | | **Denied** | Verification failed | iDenfy or you | | **Suspected** | Verified but flagged for review. Recorded as Approved when **Accept suspected verifications** is on | iDenfy or you | | **Expired** | The session expired before the shopper finished, or iDenfy returned another final status | iDenfy | | **Revoked** | You used **Revoke** or **Revoke & erase iDenfy data** | You | | *(not listed)* | The customer never started a verification and has no held order; treated as unverified | — | ### Troubleshooting > [accordion] Results Never Show Up (Manual Connect) > > * Check the webhook's receiver URL against the one on **Settings → Connection**. > * The event type must be **ID VERIFICATION**. > * The signing key must be your **API secret**. With the API key or any other value, every result is rejected. > * Or reconnect with **Sign in with iDenfy**, which sets up the webhook for you. > [accordion] Sign In with iDenfy Fails > > | Message | What to do | > | - | - | > | "Invalid iDenfy email or password. If iDenfy has just emailed you to confirm a new sign-in, confirm it there, then click Connect again." | Check your iDenfy dashboard credentials, and any confirmation email from iDenfy. | > | "iDenfy didn't recognise where this sign-in came from and emailed you a link to confirm it…" | Open the email, confirm the sign-in, then click **Connect** again. The email may show the app server's location, not yours. | > | "Your iDenfy account only accepts sign-ins from approved IP addresses, so the app can't sign in for you…" | Use **Enter manually** with an API key pair from your iDenfy dashboard. | > | "This iDenfy account is inactive. Contact iDenfy support to reactivate it." | Contact [iDenfy support](https://idenfy-ivs.atlassian.net/servicedesk/customer/portal/1). | > | "Enter your authenticator (2FA) code to continue." | Enter the code from your authenticator app. | > | "Invalid authenticator code. Please try again." | Enter a fresh code. | > | "Two-factor authentication is required but not set up. Log in at admin.idenfy.com once to configure 2FA, then try again." | Sign in at [admin.idenfy.com](https://admin.idenfy.com) once to set up 2FA. | > | "API key limit reached. Delete an unused key in your iDenfy dashboard (Settings → API Keys) and try again." | Delete an unused key under [Settings → API Keys](https://documentation.idenfy.com/guides/dashboard/settings/api-keys.md). | > | "A webhook with this name already exists in iDenfy. Delete it in your dashboard (Settings → Webhooks) and try again." | Delete the existing webhook in the iDenfy dashboard. | > [accordion] Choosing a Flow Fails > > * **"BigCommerce refused this request (…). The app may be missing an OAuth scope — reinstall the app to grant it."** A store keeps the permissions it was installed with. Uninstall and reinstall the app to grant the current ones (release held orders first). > * **"Could not resolve the "Manual Verification Required" order status."** The app can't find BigCommerce's built-in Manual Verification Required status. Contact iDenfy support. > * Other BigCommerce errors name the call that failed. Try again; if it keeps failing, send the message to iDenfy support. > [accordion] The Verification Prompt Doesn't Appear > > Common reasons: > > * The shopper is a guest, or is already **Approved**. This is common with test accounts. > * The theme's checkout button doesn't use standard Stencil markup. > * The shopper used an express payment button. Their order is held instead. > * In **After account registration**, the shopper opened My Account first after sign-up. They see the banner instead of the modal. > > Turn on [debug mode](#storefront-setup) to see which. To test again with an approved customer, set their status to **Denied** on the Customers tab. > [accordion] An Order Wasn't Held > > * The order was placed by a guest, came from another channel, or has **Incomplete**, **Refunded**, **Cancelled**, or **Declined** status. > * The customer is already Approved. > * In **Custom**, the order doesn't match your rule. > * Verification was turned off when the order was placed. > * The Settings page shows **Update your storefront setup**. Click **Update now**: holds set up by an earlier version of the app miss card payments. > [accordion] A Held Order Left Manual Verification Required > > The customer was approved, someone changed the order's status, or a payment provider updated it after confirming payment. See [Payment methods that confirm payment later](#order-hold). The app only moves orders it holds back to their previous status. > [accordion] The Shopper Verified, but the Order Is Still on Hold > > * Check the customer's status on the Customers tab. Only **Approved** releases orders; **Suspected** and **Reviewing** keep them held. > * If the customer isn't listed with a result at all, the result didn't reach the app. See *Results Never Show Up*. > * To release the orders yourself, set the status to **Approved**. > [accordion] Guests Get Through > > Guests can't be verified or held. Turn off guest checkout under **Settings → Checkout** in BigCommerce. > [accordion] Shopper Sees “Too Many Attempts” > > The shopper started 5 new sessions within 24 hours. They can try again later, or you can [send them a verification link](#send-a-verification-link), which doesn't count toward the limit. > [accordion] Suspected Verifications > > Suspected results stay Suspected, and the customer's orders stay held. Decide on the **Customers** tab, or turn on **Accept suspected verifications**. ### FAQ > [accordion] Can I use more than one flow? > > No. One flow is active at a time. Every flow holds orders from unverified customers. > [accordion] Do approved customers verify again? > > No, unless you revoke them or change their status away from Approved. > [accordion] Does the app send emails? > > No. The app sends no emails to shoppers or to you. To reach a shopper, [copy a verification link](#send-a-verification-link) and send it yourself. > [accordion] Does it work with guest checkout? > > No. Guests have no customer ID, so they can't be verified or held. Turn off guest checkout. > [accordion] Does the app run on the checkout page? > > No. Nothing loads on the page where shoppers pay. The checkout prompt acts on the button that leads there, and the order hold covers the rest. > [accordion] Does it work with Catalyst, headless, or Multi-Storefront? > > No. Only the default Stencil storefront (channel 1) is supported. > [accordion] Can I change the prompt's text or design? > > No. The modal, banner, and order panel have fixed English text. The verification steps inside follow your iDenfy dashboard settings. > [accordion] Where are the documents and photos? > > In iDenfy. Find a verification in the iDenfy dashboard by its scan reference or by the client ID `bc:{storeHash}:{customerId}`. > [accordion] What happens when I uninstall the app? > > See [Connection, Disconnect and Uninstall](#connection-disconnect-and-uninstall). *** ## What's Next? > [card] [iDenfy Dashboard — KYC Settings](https://documentation.idenfy.com/guides/dashboard/settings/configuration.md) > > Tune document types, liveness, languages, and branding for every verification started from BigCommerce. > [card] [Webhook Payload Reference](https://documentation.idenfy.com/kyc/webhooks.md) > > Full payload spec for the verification results the app receives. > [card] [Testing & Sandbox](https://documentation.idenfy.com/guides/testing-sandbox.md) > > Simulate APPROVED / DENIED / SUSPECTED results before going live. > [card] [Other Plugins](https://documentation.idenfy.com/integrations/overview.md) > > Browse iDenfy's other no-code integrations. ## Related topics - [No-Code Integrations](https://documentation.idenfy.com/integrations/overview.md) - [Adobe Commerce](https://documentation.idenfy.com/integrations/adobe-commerce.md) - [WooCommerce](https://documentation.idenfy.com/integrations/woocommerce.md) - [Shopify](https://documentation.idenfy.com/integrations/shopify.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.