In-App Wall: Contextual Payment Recovery Inside Your Product

The in-app wall is a small script you embed in your web app. When a logged-in customer has an active recovery case, it shows a dismissible overlay with a message tailored to the failure and a button to the Stripe hosted invoice. When there is nothing to recover, it shows nothing.

By default the wall is a soft prompt: the customer can dismiss it and keep using your product, and the overlay reappears after a short cooldown while the payment is still outstanding. You can optionally enable hard lock, which removes the close button after a delay you choose, so the product stays blocked until the payment is fixed.

How it works

Your app loads wall.js and calls Airdun.identify() with the logged-in customer.
The script asks Airdun whether that customer has an active recovery case.
If they do — and the wall channel is enabled and a message template and pay link are ready — it injects a full-screen overlay with the recovery copy and a CTA to the Stripe hosted invoice (opened in a new tab).
Everything fails silently. A wall error never breaks your app; if anything is missing, nothing is shown.

Get your key

The wall authenticates with your workspace publishable key — an identifier that starts with awall_pk_live_. It is safe to ship in client-side code. In your Airdun dashboard, go to Auto-Pilot → Touchpoints → In-App (app.airdun.com/auto-pilot/touchpoints/in_app). The Installation section shows your key and a copy-ready snippet. The key is created on first view and does not change.

Install

1. Add the script

Add this to your app’s HTML, replacing the key with your own. The first inline script queues any identify() calls made before wall.js finishes loading.

<script>
  window.Airdun = window.Airdun || { q: [], identify: function (p) { this.q.push(p) } };
</script>
<script src="https://cdn.airdun.com/wall.js" data-api-key="awall_pk_live_your_key" async></script>

2. Identify the logged-in customer

Once you know who is logged in, call identify(). This is how the wall knows which customer to check.

Airdun.identify({
  email: currentUser.email,        // or: stripeCustomerId: 'cus_...'
  locale: navigator.language,      // optional — the customer's language
})

Call it on every page load, as soon as the customer’s identity is known. Calling it before wall.js has loaded is fine — the call is queued and replayed on init.

`identify()` parameters

Field	Required	Notes
`email`	One of `email` / `stripeCustomerId`	The customer’s email as held in Stripe.
`stripeCustomerId`	One of `email` / `stripeCustomerId`	The Stripe customer ID (`cus_…`). `customerId` is accepted as an alias.
`locale`	No	BCP-47 locale (e.g. `fr`, `en-US`). Used to pick the message language.

What you configure

Everything else is set in the dashboard, on the same In-App page — nothing beyond the key and identify() is configured in code.

Enable the channel — the wall only shows when the In-App channel is switched on.
Message templates — one per failure category (insufficient funds, expired card, authentication required, card declined, and so on). Each template is a title, description, and CTA label. Airdun seeds the copy from your product context; you can edit it.
Language — you author copy in one language; Airdun auto-translates per customer based on the locale you pass (falling back to the customer’s Stripe locale and country, then your workspace fallback language).
Hard lock — optionally remove the close button after a delay you choose (in days after the case opens). Before the delay the wall stays dismissible; after it, the overlay blocks the product until the payment is fixed. Hard-locked cases use a separate set of message templates so the copy can match the firmer tone.
Custom CSS — restyle the wall to match your product (see below). Without it, the overlay uses a fixed, neutral style so it reads as a system prompt.

Custom CSS

The wall renders inside a closed shadow DOM on your page, so your site’s stylesheets never affect it — and it never affects your site. To restyle it, add CSS in the dashboard (In-App → Preview section): your CSS is injected inside the wall, after the base stylesheet, so your rules win at equal specificity without !important. The editable surface is a small set of stable classes:

Class	Element
`.aw-overlay`	The backdrop covering the page
`.aw-card`	The dialog card
`.aw-icon`	The circled alert icon
`.aw-title`	The title
`.aw-desc`	The description paragraph
`.aw-cta`	The pay button
`.aw-close`	The close button (absent in hard-lock mode)

The editor shows a live preview as you type, and the Copy doc for LLM button copies a self-contained brief (the full base stylesheet, the markup, and the rules) that you can paste into a coding assistant such as Claude Code or Cursor and ask it to write the CSS matching your design system. Constraints: 20,000 characters maximum, @import is not allowed, and @font-face does not work inside a shadow DOM — but any font your app already loads can be referenced by font-family.

Test it on your site

Once the script is installed, you can render the wall on your own site without a real failed payment and without affecting any data.

Preview link — open any page of your app with #airdun-wall-preview appended to the URL. The dashboard’s Installation section has a small form that builds this link for you.
Browser console — run AirdunWall.preview() on any page where the script is loaded.
Preview a real case — pass a case ID to see exactly what that customer sees, including their failure category and pay link: #airdun-wall-preview=<caseId> or AirdunWall.preview('<caseId>'). The case ID is on the case page in your dashboard.

The preview renders the real overlay — your templates, your custom CSS, and the hard-lock variant if enabled — but records nothing: no wall events, no case changes, and clicks are not tracked. A Preview pill in the corner exits the preview and cleans the URL.

Behavior details

When it shows — automatically, whenever the identified customer’s most recent recovery case is still active and a template + Stripe pay link are available. There is no trigger to configure.
Dismissal — closing takes two steps (a confirm), and a dismissed wall reappears after a short cooldown if the payment is still outstanding.
The CTA — opens the customer’s Stripe hosted invoice in a new tab, where they update their card and pay.
No customer data required beyond identify — the wall reads the case from Airdun; you don’t send payment or case data from the browser.

Get Started

How It Works

Features

Configuration

Account

In-App Wall: Contextual Payment Recovery Inside Your Product

How it works

Get your key

Install

1. Add the script

2. Identify the logged-in customer

`identify()` parameters

What you configure

Custom CSS

Test it on your site

Behavior details

​How it works

​Get your key

​Install

​1. Add the script

​2. Identify the logged-in customer

​identify() parameters

​What you configure

​Custom CSS

​Test it on your site

​Behavior details

How it works

Get your key

Install

1. Add the script

2. Identify the logged-in customer

`identify()` parameters

What you configure

Custom CSS

Test it on your site

Behavior details