Skip to main content
The managed Biqli Stripe App joins a browser click to Stripe’s server-confirmed payment lifecycle. Your website captures the click and registers a Checkout Session. Stripe then sends signed events to Biqli, which records only conversions with a safe workspace-scoped attribution. This design keeps the responsibilities separate:
  • the browser proves which Biqli click started Checkout;
  • your server creates Stripe customers and Checkout Sessions with its Stripe secret key;
  • Stripe webhooks prove payment, trial, invoice, and refund state;
  • Biqli connects those objects without exposing private credentials to the browser.

​
End-to-end flow

  1. A visitor opens a conversion-enabled Biqli short link.
  2. The browser SDK captures bq_id under your consent policy.
  3. Your application optionally creates a Stripe Customer and records a signup lead.
  4. Your server creates a Stripe Checkout Session.
  5. Before redirecting, the browser calls storeStripeSession() with the connected Stripe account, environment, and cs_... ID.
  6. The customer completes, delays, declines, authenticates, or abandons payment in Stripe.
  7. Stripe sends the selected event to the Biqli event destination.
  8. Biqli resolves the exact Stripe object mapping and records an eligible trial, sale, renewal, or refund.
Never record a Stripe sale from the success page. A success URL can be revisited or forged. The verified Stripe event is the payment authority.

​
Supported events

Configure the Stripe event destination for connected accounts with snapshot payloads and the API version shown by the Biqli app configuration.

​
Supported outcomes

The integration covers:
  • paid one-time Stripe Checkout Sessions;
  • delayed one-time payment success and failure;
  • paid subscription Checkout;
  • subscriptions with free trials;
  • first paid invoices after trials;
  • recurring paid invoices and renewal labels;
  • partial and full refunds;
  • duplicate event delivery;
  • out-of-order Checkout, subscription, invoice, and refund events;
  • isolated live, test-mode, and sandbox connections.

​
Attribution requirements

A conversion needs all of the following:
  • an active Stripe App connection for the Stripe account and environment;
  • a valid, unexpired Biqli click from the same workspace;
  • a successful storeStripeSession() call before Checkout navigation;
  • a supported Stripe event with an exact mapped object, or the narrowly defined unique-email fallback;
  • conversion tracking enabled for the workspace.
Biqli does not scan a Stripe account and attach old sales to recent visitors. Direct Dashboard payments, old subscriptions, and arbitrary invoices remain unattributed unless their Stripe object hierarchy was established by an eligible Checkout flow.

​
Security model

Biqli validates the publishable key, allowed hostname, click workspace, Stripe account, connection environment, Checkout mode, event signature, event identity, and object hierarchy before recording a conversion.

​
Choose the right implementation

Use the native Stripe App when Stripe Checkout is your payment surface and you want managed subscriptions, trials, renewals, and refunds. Use the generic server tracking API instead when:
  • you use Stripe PaymentIntents without Checkout and already preserve bq_id in your order database;
  • you use a different payment processor;
  • you need a custom revenue definition that differs from Stripe’s paid Checkout or invoice amount;
  • you need to attribute an offline or manually approved sale.
Do not send the same financial event through both paths. Doing so creates two independently identified sales.

​
Implementation path

  1. Install and connect the Stripe App.
  2. Implement click attribution and customer identity.
  3. Register and launch Stripe Checkout.
  4. Handle subscriptions, trials, renewals, and refunds.
  5. Test and operate the integration.
For the exact browser endpoint, read Store a Stripe Checkout Session.