Troubleshooting connections

Most connection issues come down to a handful of causes. Work through the ones that match your symptom.

“Connected, but 0 brands” / disputes aren’t appearing

A processor connected at the workspace level still needs each brand pointed at its merchant account. Go to Brands → Connections and add the processor account with the correct merchant account ID for each brand. Until you do, no disputes route to that brand.

I can’t connect a processor

Connecting a payment processor requires a verified email. If the connect action is blocked, verify your email first (use Resend email if you never got the link).

The Test button fails

Double-check the credentials for typos or trailing spaces.
Confirm you used live keys for a live account (not test/sandbox), or vice-versa.
For Braintree, make sure the merchant ID and both keys are from the same Braintree account.

Webhooks aren’t arriving / are rejected

Confirm you registered the exact webhook URL shown in DisputeDash, including the workspace ID in the path for Stripe and Shopify Payments. See the webhook URL reference.
Stripe: confirm the signing secret (whsec_…) in DisputeDash matches the endpoint, and that the three charge.dispute.* events are selected.
PayArc: no webhook secret is needed — DisputeDash verifies each dispute by re-fetching it from PayArc’s API. If disputes aren’t arriving, confirm the webhook URL is registered in PayArc and that your API token is valid (use the Test button in Brands → Connections).
Shopify Payments: confirm the webhook secret matches and the disputes/create and disputes/update topics are subscribed.
Square: there’s nothing to configure — the connection and webhook are fully managed. If disputes aren’t arriving, re-run Connect Square for the brand to refresh its authorization, and confirm the brand shows a Square merchant account ID.
Adyen: confirm the HMAC key in DisputeDash matches the one on your Adyen Standard webhook (a mismatch means every notification is rejected), that the webhook URL is https://app.disputedash.com/api/webhooks/adyen, and that the brand’s merchant account matches the merchantAccount on your disputes. HMAC signing must be enabled on the webhook.
Checkout.com: confirm the signature key in DisputeDash matches the one on your Checkout.com webhook (a mismatch rejects every event), that you registered the exact webhook URL shown in DisputeDash — including the brand ID in the path — and that the dispute events are enabled. Also confirm the secret key matches the environment (sk_sbox_ for a sandbox webhook, sk_ for live).
Klarna: there’s no webhook to configure — disputes are pulled on a schedule. If they aren’t arriving, use the Test connection button in Brands → Connections to confirm the credentials reach Klarna, and check that the region and environment match your credentials (Playground and Production credentials are separate and not interchangeable). Use Sync now to pull immediately instead of waiting for the next scheduled sweep.
Airwallex: confirm the webhook secret in DisputeDash matches the one on your Airwallex webhook (a mismatch rejects every event), that you registered the exact webhook URL shown in DisputeDash — including the brand ID in the path — and that the dispute events are enabled. Use Test connection in Brands → Connections to confirm the Client ID + API key exchange a token and reach the Disputes API, and make sure the environment (Demo vs Production) matches your keys.
Finix: there’s no webhook secret to configure — set the webhook’s Authentication Type to None; DisputeDash verifies each event by re-fetching the dispute from Finix’s API. Register the exact webhook URL shown in DisputeDash — including the brand ID in the path — and enable the Dispute (Created + Updated) events. If disputes aren’t arriving, connect the Finix account for the brand first (the webhook resolves the brand from that account), use Test connection to confirm the API key reaches the Disputes API, make sure the environment (Sandbox vs Live) matches your keys, and use Sync now to pull immediately.

Stripe cases can’t find the order

DisputeDash reads the order ID from the Stripe charge’s metadata (order_id). If it’s missing, evidence can’t be gathered. Make sure your checkout writes the order ID into charge metadata. See Connect Stripe.

Zendesk returns no support history

Zendesk needs a per-brand Zendesk brand ID in addition to the workspace credentials. Without it, lookups for that brand do nothing. See Connect Zendesk.

Before you disconnect

Disconnecting an integration can stop active cases from gathering evidence for the brands that rely on it. DisputeDash warns you when a disconnect will affect connected brands — read the warning before confirming.