# Test and troubleshoot Stripe attribution (https://talivia.com/docs/revenue-guides/stripe/testing-and-troubleshooting)



Start with the [shared payment testing setup](https://talivia.com/docs/revenue-guides/testing-payment-providers), then test the actual Stripe checkout path used by your product rather than sending only a generic webhook fixture.

## Minimum test matrix [#minimum-test-matrix]

| Scenario                       | Expected Talivia result                                         |
| ------------------------------ | --------------------------------------------------------------- |
| One-time Checkout Session      | One paid payment matched to the checkout session                |
| Direct Payment Intent          | One payment keyed by the `pi_...` ID                            |
| Payment Link                   | Payment matched through `client_reference_id` or the return URL |
| Delayed payment method         | No revenue before asynchronous success                          |
| Subscription signup            | One initial payment plus an active subscription                 |
| Subscription renewal           | One renewal connected to the original customer                  |
| Failed invoice                 | Subscription lifecycle changes without paid revenue             |
| Full or partial refund         | Original payment remains visible and net revenue is reduced     |
| Dispute                        | Dispute state is connected to the original payment              |
| Repeated or out-of-order event | No duplicate payment                                            |

## The connection succeeds but no payment appears [#the-connection-succeeds-but-no-payment-appears]

Check the Stripe Dashboard webhook delivery for the website endpoint. The relevant successful event must be one of:

* `checkout.session.completed` or `checkout.session.async_payment_succeeded`;
* `payment_intent.succeeded` for a direct Payment Intent;
* `invoice.paid` or `invoice.payment_succeeded` for an invoice.

Confirm the event belongs to the same test or live mode as the restricted key connected in Talivia.

## The payment appears but is unattributed [#the-payment-appears-but-is-unattributed]

Inspect the Stripe object used by your flow:

* Checkout Session: `metadata.talivia_session_id`;
* direct Payment Intent: `metadata.talivia_session_id`;
* Subscription: `metadata.talivia_session_id`;
* Payment Link Checkout Session: Talivia-like `client_reference_id` beginning with `s_`;
* return page: `?session_id=cs_...` and a working Talivia tracker.

If metadata is absent, confirm `window.talivia.getSessionId()` returned a value before your backend created checkout.

## Payment Link is not decorated [#payment-link-is-not-decorated]

Automatic decoration requires a normal anchor whose hostname is `buy.stripe.com`. Talivia preserves an existing `client_reference_id`. For custom domains, programmatic navigation, or an existing merchant reference, configure the tracked return URL with `{CHECKOUT_SESSION_ID}`.

## A renewal is unattributed [#a-renewal-is-unattributed]

Confirm the first subscription payment was attributed and that later invoices use the same Stripe Customer. Add `subscription_data.metadata` during signup and call `window.talivia.identify` with the Stripe Customer ID after authentication.

## Reconnect Stripe [#reconnect-stripe]

Pasting an updated restricted key makes Talivia reconcile the existing Stripe webhook URL and event list instead of creating a duplicate endpoint. If the original connection predates managed endpoint IDs, the first update creates and stores a new managed endpoint.