Dodo Payments

Import customers, subscriptions, payments and refunds into Revenue → MRR, Payments, Customers and Attribution. This connector is read-only: it never creates payments or refunds in Dodo.

1. In the Dodo Payments dashboard open Developer → API keys and create a key. Enable Test mode on the connector to use test.dodopayments.com with a test-mode key; unchecked, live.dodopayments.com is used.
2. In Revenue → Connectors → Add a connector, choose Dodo Payments. Enter a label, the API key and the webhook signing secret. Credentials are encrypted in the vault.
3. Copy the revealed URL into Developer → Webhooks → Add endpoint and store its whsec_… secret here. Enable payment.*, subscription.* and refund.* events.
4. Use Sync now, then inspect the last sync and event receipts. Verify a known payment and refund against the dashboard before relying on totals.

Signatures follow the Standard Webhooks scheme: webhook-id, webhook-timestamp and webhook-signature headers, HMAC-SHA256 over id.timestamp.rawBody, v1,<base64> signatures, five-minute replay tolerance. The webhook-id header doubles as the idempotency key. Webhooks.

Subscription MRR comes from recurring_pre_tax_amount × quantity at payment_frequency_interval. A trial (trial_period_days from created_at) is reported as trialing and never counted as MRR. on_hold maps to unpaid; paused stays out of MRR.

Payments are keyed on payment_id at total_amount in minor units. A refund event carries only its own amount, so refunds are reconciled at sync: succeeded refund rows mark their payment, the payment detail is re-fetched and its refunds rows are summed into cumulative refundedCents. Payments.

Sync pages page_number/page_size through /customers, /subscriptions, /refunds and /payments, filtered to the backfill window with created_at_gte when one is set. A refund on a payment outside the window still triggers a detail fetch so the stored row reflects the cumulative total.