Testing And Go Live

Testing and Go-Live

This skill covers test mode, test payment methods, webhook testing, and the production launch checklist. Use it when building payment flows that need verification before going live, or when preparing to switch from test to production.

When to use this skill

• You need to test card success/decline scenarios, subscription renewals, or regional payment methods.
• You're setting up webhook testing locally or in a staging environment.
• You're preparing to launch to production and need a go-live checklist.
• You want to verify that test and live environments are properly isolated.
• You're copying products from test to production.

Core concepts

Test vs. live mode: Dodo Payments maintains two completely separate environments. Each has its own base URL, API keys, webhooks, products, customers, and transactions. Data does not carry over between them.

• Test mode: https://test.dodopayments.com
• Live mode: https://live.dodopayments.com

Each environment requires separate API keys issued from the dashboard. The SDK defaults to live_mode if you don't specify environment, which is a real footgun in development.

Test payment methods: Dodo documents specific card numbers, VPAs, and payment method scenarios for testing. These only work in test mode.

Webhook testing: The CLI provides commands to listen for webhooks locally and trigger test events without making real payments.

Setting up test mode

Always explicitly set environment: 'test_mode' during development. The default is live_mode.

import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode', // REQUIRED — defaults to 'live_mode'
});

import os

from dodopayments import DodoPayments

client = DodoPayments(
    bearer_token=os.environ.get("DODO_PAYMENTS_API_KEY"),
    environment="test_mode",  # defaults to "live_mode"
)

client := dodopayments.NewClient(
    option.WithBearerToken("dodo_test_..."),
    option.WithEnvironmentTestMode(), // defaults to WithEnvironmentLiveMode()
)

Get your test API key from the Dodo dashboard. Test keys are prefixed dodo_test_.

Test payment methods

Card success and decline scenarios

Use these card numbers in test mode with expiry 06/32 (or 12/34) and CVV 123.

Only use cards listed on the Testing Process page; other Stripe-style test numbers (for example "lost card" variants) are not documented for Dodo.

Subscription renewal failure

To test subscription renewal failures, use this card:

Create the subscription with a success card first, then switch its payment method to this card in the Customer Portal.

UPI (India)

Test UPI success and failure with these VPAs. The billing country must be IN and the currency INR (non-Indian merchants also need Adaptive Currency enabled):

BNPL, wallets, and regional methods

BNPL, Apple Pay, Google Pay, and European payment methods (Giropay, iDEAL, Bancontact) are available in test mode. Exact test scenarios vary by method. Refer to the Testing Process documentation for the current test matrix.

Testing subscription renewals

To force a subscription to renew on a specific date without waiting, update the next_billing_date:

await client.subscriptions.update('sub_123', {
  next_billing_date: '2026-05-03T00:00:00Z',
});

client.subscriptions.update(
    'sub_123',
    next_billing_date='2026-05-03T00:00:00Z'
)

// NextBillingDate is param.Field[time.Time], not a string. Passing a string
// literal compiles to param.Field[string] and will not type-check.
client.Subscriptions.Update(ctx, "sub_123", dodopayments.SubscriptionUpdateParams{
    NextBillingDate: dodopayments.F(time.Date(2026, time.May, 3, 0, 0, 0, 0, time.UTC)),
})

This immediately schedules the renewal. If you used the subscription-renewal-failure card, the failed charge emits payment.failed and the affected subscription enters on_hold, which emits subscription.on_hold.

Webhook testing

The CLI ships separately from the SDKs:

npm install -g dodopayments-cli
dodo login

dodo login opens the API Keys page, accepts a pasted key, and asks whether it is Test Mode or Live Mode. One key of each can stay authenticated at the same time.

Listen for webhooks locally

dodo wh listen http://localhost:3000/webhook

This forwards real test-mode events to your local URL over an outbound relay. It is not a tunnel: nothing listens publicly and no URL is printed for you to paste into the dashboard. If you need a registerable HTTPS URL, use ngrok instead — that flow is described in the webhook-integration skill.

Two constraints to know before running it:

• A Test Mode key is required. Live Mode keys are not supported by the listen flow.
• The URL argument is required in direct mode. Bare dodo wh listen only works inside the interactive TUI as /wh listen, which opens a wizard.

Events arriving this way carry valid signatures, so verify them normally with webhooks.unwrap().

Trigger mock webhook events

dodo wh trigger payment.success http://localhost:3000/webhook

Sends a realistic mock payload for a chosen event. It runs offline and works even while logged out — which is the tell for the part that matters: these payloads are unsigned. unwrap() rejects them because there is no valid signature to verify.

Use unsafeUnwrap() for triggered events only, and never on an endpoint that also receives real traffic. Trigger names are <category>.<event>, for example payment.success, subscription.active, or dispute.opened.

Trigger names are not always the payload type. payment.success delivers type: "payment.succeeded", refund.success delivers refund.succeeded, and licence.created delivers license_key.created. Switch on the payload types in your handler; a case 'payment.success' never matches.

As with listen, both arguments are required in direct mode; /wh trigger inside the TUI opens a wizard instead.

Webhook signature verification

Covered in the webhook-integration skill. Verify every webhook that arrives over the network, in test mode as well as live. The single exception is the unsigned payloads produced by dodo wh trigger above.