Stripe webhook revenue events
Send Stripe webhook events to AttribIQ and understand how Stripe objects become attributed revenue events.
Webhooks are the reliable feed for Stripe revenue attribution. Stripe can send events directly to AttribIQ, or your backend can normalize events and post them through the Payment API.
- Choose the first Stripe events to send
- Understand idempotency and duplicate webhook delivery
- Understand AttribIQ's native Stripe event mapping
- Handle missing metadata without losing revenue
Stripe webhooks turn payment activity into a reliable revenue event stream.
Checkout redirects are useful for user experience, but revenue analytics should be driven by webhook events. Stripe sends events when checkout completes, invoices are paid, subscriptions change, and refunds occur. AttribIQ turns supported Stripe events into a smaller revenue event vocabulary that reports can understand.
Native receiver endpoint
For direct Stripe delivery, configure a Stripe webhook endpoint:
https://api.attribiq.com/v1/integrations/stripe/webhook
Use the API hostname for your deployment if you are not using the hosted AttribIQ service.
The Stripe object must include attribiq_project_id metadata so AttribIQ can route the revenue event to the right project. attribiq_visitor_id and attribiq_session_id are the strongest attribution links.
If your workspace does not yet expose self-serve Stripe signing-secret settings, ask support or your deployment operator to configure the endpoint secret, or use a customer-owned relay that sends normalized events to the Payment API.
Start with a small event set
For the current native AttribIQ receiver, start conservatively:
invoice.paidcustomer.subscription.deletedcharge.refunded
This set covers paid invoices, cancellations, and refunds while avoiding setup-mode checkout sessions and broad subscription updates.
Add these events only after you confirm that their semantics match your billing model:
checkout.session.completedcustomer.subscription.createdcustomer.subscription.updated
checkout.session.completed is useful for checkout completions, but setup-mode Checkout Sessions should not become purchases. customer.subscription.updated can mean upgrade, downgrade, status change, metadata change, or another non-revenue update.
If your backend needs exact control over those distinctions, use a Payment API relay instead of sending those raw Stripe events directly to AttribIQ.
Signature and idempotency
Stripe signs each webhook event with the endpoint secret. AttribIQ verifies signatures when that secret is configured for the receiver.
Stripe may retry events. AttribIQ stores processed Stripe event IDs and ignores duplicates so repeated deliveries do not duplicate purchases, renewals, or refunds.
Normalize into revenue events
AttribIQ's native Stripe receiver maps supported Stripe events into normalized revenue event types:
| Stripe signal | AttribIQ event type |
|---|---|
| Completed checkout for a new subscription | subscription_started |
| Completed checkout for a one-time payment | purchase |
| Paid recurring invoice | renewal |
| Plan amount increases | upgrade |
| Plan amount decreases | downgrade |
| Refunded charge | refund |
| Subscription cancelled or deleted | cancellation or churn |
The mapping should be explicit in code. Do not let every Stripe event become a new analytics event type. Reporting works better when event names are stable.
Current implementation note: broad Stripe events can be ambiguous. For example, customer.subscription.updated is not always an upgrade, and checkout.session.completed can represent setup-mode flows. Use the conservative event set first unless you have verified the mapping for your billing flow.
Extract attribution metadata
For the first checkout, attribution usually comes from checkout.session.metadata. For renewals and subscription lifecycle events, metadata should come from the Subscription. That is why passing attribution to Stripe Checkout copies the same identifiers into subscription_data.metadata.
The minimum fields are:
attribiq_project_idattribiq_visitor_idattribiq_session_id
If those fields are missing, the revenue event can still be valid. Mark it as unattributed and keep it in totals.
Handle refunds and churn carefully
Refunds should subtract money from the source that received the original credit. Churn should be tied back to the subscription or customer history so teams can see whether a channel creates poor-fit customers.
This does not mean every source with churn is bad. It means the dashboard should show revenue quality, not just first purchase volume.
Operational checks
Before going live:
- Send test webhooks from Stripe.
- Confirm duplicate events do not double-count revenue.
- Confirm metadata appears on subscriptions.
- Confirm missing metadata becomes unattributed revenue.
- Confirm refunds reduce net revenue.
Once this is stable, read connect Stripe to AttribIQ for the full setup checklist and UTM revenue attribution to understand how campaign reporting uses normalized events.
FAQ
Why not rely on the checkout success page?
A success page can be blocked, closed, or refreshed. Stripe webhooks are designed for asynchronous payment lifecycle processing.
What should be the idempotency key?
Use stable Stripe object IDs and event IDs. Store processed event IDs so duplicate deliveries do not create duplicate revenue.
Should failed invoices count as churn?
Not immediately. Failed invoices are payment risk. Churn should be recorded when the subscription is cancelled, deleted, or moves into a churn state you define.
What happens when attribution metadata is missing?
Record the revenue as unattributed and surface it as a data quality issue. Dropping valid revenue would make totals wrong.
Connect payments to the dashboard
Install the tracker, pass attribution into checkout, and report revenue by source, campaign, landing page, and path.
Related guides
Stripe revenue attribution for SaaS
Connect Stripe Checkout, subscriptions, invoices, refunds, and webhooks to source, campaign, landing page, and session reports.
What is a Stripe webhook?
A Stripe webhook is an HTTP notification Stripe sends to your backend when payments, subscriptions, invoices, refunds, and customer events happen.
What is checkout attribution?
Checkout attribution connects the visit, campaign, landing page, and session before checkout to the payment event that happens after checkout.
Connect Stripe to AttribIQ
Configure Stripe to send payment events to AttribIQ after your app has copied visitor and session identifiers into Stripe metadata.