Subscription Upgrade & Downgrade Guide - Dodo Payments Documentation

Change Plan API

Full API docs for updating subscriptions.

Plan Change Preview

See charge amounts before changing plans.

Integration Guide

Step-by-step subscription setup.

¿Qué es una actualización o degradación de una suscripción?

Cambia el plan de suscripción de un cliente para moverlo entre niveles, ajustar la cantidad de productos basados en asientos o migrarlo a un producto nuevo. La API calcula automáticamente los prorrateos y los cargos según el modo de facturación elegido.

Plan changes can trigger an immediate charge depending on the proration mode you choose.

Cuándo usar cambios de plan

Upgrade when a customer needs more features, usage, or seats
Downgrade when usage decreases
Migrate users to a new product or price without cancelling their subscription

Plan Change Flow

Prerequisites

Before implementing subscription plan changes, ensure you have:

A Dodo Payments merchant account with active subscription products
API credentials (API key and webhook secret key) from the dashboard
An existing active subscription to modify
Webhook endpoint configured to handle subscription events

Para obtener instrucciones detalladas de configuración, consulta la Guía de integración.

Step-by-Step Implementation Guide

Follow this comprehensive guide to implement subscription plan changes in your application:

Understand Plan Change Requirements

Before implementing, determine:

Which subscription products can be changed to which others
What proration mode fits your business model
How to handle failed plan changes gracefully
Which webhook events to track for state management

Test plan changes thoroughly in test mode before implementing in production.

Choose Your Proration Strategy

Select the billing approach that aligns with your business needs:

prorated_immediately
difference_immediately
full_immediately
do_not_bill

Ideal para: aplicaciones SaaS que desean acreditar el tiempo no utilizado del plan anterior.

Acredita la parte no utilizada del ciclo actual, prorrateada según el tiempo restante
Después cobra un ciclo completo del plan nuevo; el precio del plan nuevo nunca se prorratea
Cargo neto = ciclo nuevo completo − (fracción restante × ciclo anterior completo)

Implement the Change Plan API

Use the Change Plan API to modify subscription details:

string

requerido

The ID of the active subscription to modify.

string

requerido

El nuevo ID de producto al que se cambiará la suscripción.

integer

requerido

Número de unidades del nuevo plan (para productos basados en asientos).

string

requerido

Cómo gestionar la facturación inmediata: prorated_immediately, full_immediately, difference_immediately o do_not_bill.

array

Complementos opcionales para el nuevo plan. Omitir este campo, enviar null o enviar un array vacío elimina cualquier complemento existente, por lo que debes incluir los complementos actuales para conservarlos.

string

Controla el comportamiento cuando falla el pago del cambio de plan:

prevent_change: Mantener la suscripción en el plan actual hasta que el pago se complete
apply_change (predeterminado): Aplicar el cambio de plan inmediatamente independientemente del resultado del pago

If not specified, uses the business-level default setting.

boolean

Cobra el importe del cambio de plan mediante un enlace de pago en lugar de cargar el método de pago guardado de la suscripción. El cliente paga en una página de checkout alojada.Requiere que la empresa tenga habilitada la capacidad allow_plan_change_via_payment_link (Settings → Subscriptions → Collect Plan Change Payments by Payment Link), effective_at: immediately y on_payment_failure: prevent_change. Consulta Cobrar pagos mediante un enlace de Checkout. La ruta de vista previa lo ignora.

string

La URL que recibe al cliente después de pagar el enlace de pago. La redirección añade subscription_id, payment_id y status. Requiere collect_via_payment_link: true; de lo contrario, la solicitud falla con 422. Consulta Redirigir al cliente después del pago.

boolean

predeterminado:"false"

Cancela el enlace de pago impagado de un cambio de plan pendiente, de modo que esta solicitud lo reemplace. Un pago completado o en curso devuelve 409. Consulta Reemplazar un enlace de pago pendiente. La ruta de vista previa ignora este campo.

array

Códigos de descuento acumulables opcionales que se aplicarán al nuevo plan (máximo 20, aplicados en el orden del array). El comportamiento depende de lo que envíes:

No proporcionado / null — los descuentos existentes con preserve_on_plan_change=true se conservan si son aplicables al nuevo producto.
[] (array vacío) — elimina todos los descuentos existentes de la suscripción.
["CODE_A", "CODE_B", ...] — reemplaza los descuentos existentes con este conjunto acumulable.

string

obsoleto

Obsoleto — para nuevas integraciones, se recomienda discount_codes. Este campo aún funciona por compatibilidad con versiones anteriores, pero no se puede combinar con discount_codes en la misma solicitud.

string

predeterminado:"immediately"

Cuándo aplicar el cambio de plan:

immediately (predeterminado): Aplicar el cambio de plan inmediatamente
next_billing_date: Programar el cambio para la próxima fecha de facturación. El cliente conserva su plan actual hasta que finalice el período de facturación. Úsalo para downgrades, de modo que los clientes mantengan los beneficios de su plan actual hasta el final del período de facturación.

Handle Webhook Events

Configura la gestión de webhooks para realizar un seguimiento de los resultados del cambio de plan:

subscription.active: Cambio de plan exitoso, suscripción actualizada
subscription.plan_changed: Plan de suscripción cambiado (upgrade/downgrade/actualización de addon)
subscription.on_hold: Falló el cargo del cambio de plan, renovaciones detenidas
payment.succeeded: Cargo inmediato del cambio de plan exitoso
payment.failed: Falló el cargo inmediato

Verifica siempre las firmas de los webhooks e implementa un procesamiento idempotente de eventos.

Update Your Application State

Según los eventos de webhook, actualiza tu aplicación:

Concede o revoca funcionalidades según el nuevo plan
Actualiza el panel del cliente con los detalles del nuevo plan
Envía correos de confirmación sobre los cambios de plan
Registra los cambios de facturación con fines de auditoría

Test and Monitor

Prueba exhaustivamente tu implementación:

Prueba todos los modos de prorrateo con distintos escenarios
Verifica que la gestión de webhooks funcione correctamente
Supervisa las tasas de éxito de los cambios de plan
Configura alertas para los cambios de plan fallidos

Tu implementación del cambio de plan de suscripción ya está lista para usarse en producción.

Previsualizar cambios de plan

Antes de confirmar un cambio de plan, usa la API de vista previa para mostrar a los clientes exactamente cuánto se les cobrará:

Node.js SDK
Python SDK

const preview = await client.subscriptions.previewChangePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
});

// Show customer the charge before confirming
console.log('Immediate charge:', preview.immediate_charge.summary.total_amount, preview.immediate_charge.summary.currency);
console.log('New plan details:', preview.new_plan);

preview = client.subscriptions.preview_change_plan(
    subscription_id="sub_123",
    product_id="pdt_pro",
    quantity=1,
    proration_billing_mode="prorated_immediately"
)

# Show customer the charge before confirming
print("Immediate charge:", preview.immediate_charge.summary.total_amount, preview.immediate_charge.summary.currency)
print("New plan details:", preview.new_plan)

Usa la API de vista previa para crear diálogos de confirmación que muestren a los clientes el importe exacto que se les cobrará antes de confirmar un cambio de plan.

En immediate_charge.summary, customer_credits es el cambio neto en el saldo de crédito del cliente, en la moneda indicada por customer_credits_currency. Esta es la moneda de la billetera de crédito del cliente, que corresponde a la moneda de la suscripción. Puede ser distinta de currency del resumen, que se aplica a total_amount y tax. Por ejemplo, un cliente que paga en INR por una suscripción en USD ve los créditos en USD.

API de cambio de plan

Usa la API de cambio de plan para modificar el producto, la cantidad y el comportamiento del prorrateo de una suscripción activa.

Ejemplos de inicio rápido

Node.js SDK
Python SDK
Go SDK
HTTP

import DodoPayments from 'dodopayments';

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

async function changePlan() {
  // change-plan returns 200 with a ChangePlanResponse body (payment_id, payment_link,
  // client_secret, expires_on) — all null for an ordinary off-session change.
  await client.subscriptions.changePlan('sub_123', {
    product_id: 'pdt_new',
    quantity: 3,
    proration_billing_mode: 'prorated_immediately',
    on_payment_failure: 'prevent_change', // Optional: control behavior on payment failure
  });
  console.log('Plan change accepted; awaiting webhooks');
}

changePlan();

import os
from dodopayments import DodoPayments

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

# change_plan returns 200 with a ChangePlanResponse body (payment_id, payment_link,
# client_secret, expires_on) — all None for an ordinary off-session change.
client.subscriptions.change_plan(
    subscription_id="sub_123",
    product_id="pdt_new",
    quantity=3,
    proration_billing_mode="prorated_immediately",
    on_payment_failure="prevent_change",  # Optional: control behavior on payment failure
)
print("Plan change accepted; awaiting webhooks")

package main

import (
  "context"
  "fmt"
  "github.com/dodopayments/dodopayments-go"
  "github.com/dodopayments/dodopayments-go/option"
)

func main() {
  client := dodopayments.NewClient(option.WithBearerToken("YOUR_TOKEN"))
  // ChangePlan returns a SubscriptionChangePlanResponse alongside the error.
  _, err := client.Subscriptions.ChangePlan(context.TODO(), "sub_123", dodopayments.SubscriptionChangePlanParams{
    UpdateSubscriptionPlanReq: dodopayments.UpdateSubscriptionPlanReqParam{
      ProductID:            dodopayments.F("pdt_new"),
      Quantity:             dodopayments.F(int64(3)),
      ProrationBillingMode: dodopayments.F(dodopayments.UpdateSubscriptionPlanReqProrationBillingModeProratedImmediately),
      OnPaymentFailure:     dodopayments.F(dodopayments.UpdateSubscriptionPlanReqOnPaymentFailurePreventChange), // Optional
    },
  })
  if err != nil { panic(err) }
  fmt.Println("Plan change applied")
}

curl -X POST "$DODO_API_BASE/subscriptions/sub_123/change-plan" \
  -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "pdt_new",
    "quantity": 3,
    "proration_billing_mode": "prorated_immediately",
    "on_payment_failure": "prevent_change"
  }'

Un cambio de plan exitoso devuelve 200 OK inmediatamente, antes de que se liquide cualquier cargo. El contenido del cuerpo (ChangePlanResponse) depende de cómo se haya cobrado el cambio:

Caso	`payment_id` / `payment_link` / `client_secret` / `expires_on`
Cambio programado (`effective_at: next_billing_date`)	Todo `null` — todavía no se cobra nada
`proration_billing_mode: do_not_bill`	Todo `null` — no hay nada que cobrar
Cargo inmediato ordinario (método de pago guardado)	Todo `null`
`collect_via_payment_link: true` (enlace emitido)	Todo completado — identificadores de checkout para el cliente

Esta respuesta confirma que la solicitud fue aceptada, no que el cargo se haya completado correctamente. Para un cargo inmediato ordinario, el resultado se resuelve fuera de sesión justo después de la llamada. Para una solicitud collect_via_payment_link, la suscripción permanece en su plan actual hasta que el cliente complete el pago.Confirma el resultado mediante webhook (payment.succeeded, payment.failed, subscription.plan_changed) o volviendo a leer la suscripción con GET /subscriptions/{subscription_id}. Consulta Qué ocurre mientras el enlace está impagado para el caso del enlace de pago.

Si falla el cargo inmediato, la suscripción puede pasar al estado subscription.on_hold hasta que se complete el pago.

Cobrar mediante un enlace de checkout

De forma predeterminada, un cambio de plan inmediato carga directamente el método de pago guardado de la suscripción. Establece collect_via_payment_link: true para enviar al cliente a una página de checkout alojada; resulta útil cuando no hay un método de pago guardado o cuando quieres que el cliente confirme activamente el nuevo precio.

Esto controla el interruptor Cobrar cambios de plan mediante enlace de pago en Settings → Subscriptions, que dirige el flujo de cambio de plan del Customer Portal a través del checkout.

Requisitos

collect_via_payment_link: true solo funciona correctamente cuando se cumplen todas las condiciones siguientes; de lo contrario, la solicitud falla con 422:

El negocio tiene habilitada la capacidad allow_plan_change_via_payment_link (Settings → Subscriptions → Collect Plan Change Payments by Payment Link).
effective_at es immediately (el valor predeterminado). Un cambio programado (next_billing_date) nunca necesita una página de checkout.
La solicitud establece on_payment_failure: prevent_change. Un apply_change explícito falla con 422.

collect_via_payment_link se aplica a cualquier cambio inmediato que produzca un cargo, incluidos los downgrades, siempre que se cumplan los requisitos anteriores.

Si el cambio resulta en cero o en un crédito, no se emite ningún enlace de pago: payment_link y los demás campos de checkout regresan como null, y el cambio se aplica inmediatamente. Esto no es un 422. Llama primero a Previsualizar cambio de plan para comprobar el importe antes de solicitar un enlace.

Node.js SDK
Python SDK
HTTP

const response = await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  effective_at: 'immediately',
  on_payment_failure: 'prevent_change',
  collect_via_payment_link: true,
});

// Hand response.payment_link to your frontend and send the customer there
console.log(response.payment_link);

response = client.subscriptions.change_plan(
    subscription_id="sub_123",
    product_id="pdt_pro",
    quantity=1,
    proration_billing_mode="prorated_immediately",
    effective_at="immediately",
    on_payment_failure="prevent_change",
    collect_via_payment_link=True,
)

# Hand response.payment_link to your frontend and send the customer there
print(response.payment_link)

curl -X POST "$DODO_API_BASE/subscriptions/sub_123/change-plan" \
  -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "pdt_pro",
    "quantity": 1,
    "proration_billing_mode": "prorated_immediately",
    "effective_at": "immediately",
    "on_payment_failure": "prevent_change",
    "collect_via_payment_link": true
  }'

Una solicitud exitosa devuelve los identificadores de checkout:

{
  "payment_id": "<payment_id>",
  "payment_link": "https://checkout.dodopayments.com/...",
  "client_secret": "<client_secret>",
  "expires_on": "<expires_on>"
}

Qué ocurre mientras el enlace está impagado

La suscripción permanece en su plan actual; product_id, recurring_pre_tax_amount y next_billing_date no se modifican hasta que se pague el enlace.
Una solicitud posterior de change-plan se rechaza con 409 PendingPlanChangeExists mientras el enlace está pendiente. Para reemplazar el cambio pendiente, envía la nueva solicitud con cancel_older_payment_link: true. Consulta Reemplazar un enlace de pago pendiente.
Para reintentar después de un pago rechazado, vuelve a llamar a change-plan para obtener un nuevo enlace.
Si el enlace nunca se paga, deja de funcionar después de expires_on; la suscripción queda automáticamente disponible para aceptar una nueva solicitud de cambio de plan poco después.
Si ya existía un cambio programado y lo reemplazas con cancel_scheduled_change_plan: true, la programación original permanece mientras el enlace está impagado y solo se cancela cuando se paga el enlace, en la misma transacción que aplica el nuevo plan.

Una vez emitido un cambio inmediato mediante enlace de pago, todas las solicitudes posteriores de cambio de plan para esa suscripción, incluida la vista previa sin efectos secundarios, quedan bloqueadas hasta que se resuelva el enlace. Una solicitud change-plan puede reemplazar el enlace estableciendo cancel_older_payment_link: true. La vista previa ignora este campo, por lo que permanece bloqueada.

Redirigir al cliente después del pago

Establece return_url para devolver al cliente a tu sitio después de que pague el enlace:

{
  "product_id": "pdt_pro",
  "quantity": 1,
  "proration_billing_mode": "prorated_immediately",
  "on_payment_failure": "prevent_change",
  "collect_via_payment_link": true,
  "return_url": "https://example.com/billing/done"
}

Después del checkout, el cliente accede a return_url con estos parámetros de consulta:

Parámetro	Valor
`subscription_id`	La suscripción para la que se realiza el cambio de plan.
`payment_id`	El pago del cambio de plan.
`status`	El estado del pago del cambio de plan, no el de la suscripción: `active` cuando se ha pagado, `failed` cuando se rechaza, `pending` mientras está en curso.

Cuando falla el pago, la suscripción permanece activa en su plan actual. El nuevo plan puede aplicarse poco después de la redirección, cuando llega el webhook de pago, así que vuelve a leer la suscripción antes de mostrar el nuevo plan. return_url requiere collect_via_payment_link: true. Sin él, la solicitud falla con 422.

Reemplazar un enlace de pago pendiente

Si el cliente abandona el checkout sin pagar, establece cancel_older_payment_link: true en la siguiente solicitud change-plan. Dodo Payments cancela el enlace impagado y el nuevo cambio de plan reemplaza al pendiente. El enlace cancelado ya no acepta pagos, ni siquiera en una página de checkout que ya esté abierta.

{
  "product_id": "pdt_pro",
  "quantity": 1,
  "proration_billing_mode": "prorated_immediately",
  "on_payment_failure": "prevent_change",
  "collect_via_payment_link": true,
  "cancel_older_payment_link": true
}

La solicitud se valida antes de cancelar el enlace, por lo que una solicitud no válida conserva el enlace del cliente. El enlace solo se cancela si el cliente no ha comenzado a pagar:

Pago anterior	Respuesta
No abierto, abierto pero no pagado o rechazado	`200` con el nuevo enlace.
El cliente está pagando ahora, por ejemplo durante 3D Secure	`409` `PLAN_CHANGE_PAYMENT_IN_PROGRESS`. Reintenta después de que el pago se complete o falle.
Ya pagado	`409` `PLAN_CHANGE_PAYMENT_ALREADY_COMPLETED`. No reintentes: se aplica el cambio de plan anterior.
No se pudo cancelar el enlace	`503` `PLAN_CHANGE_LINK_CANCEL_FAILED`. No se modificó nada, así que puedes reintentarlo.

Cada solicitud change-plan emite su propia factura. El cambio de plan reemplazado y su factura se cancelan. Si no hay ningún cambio de plan pendiente, cancel_older_payment_link no tiene efecto.

Una comprobación que se ejecuta después de la validación, como el importe mínimo del cargo, aún puede fallar después de cancelar el enlace. La suscripción permanece entonces en su plan actual sin ningún enlace abierto. Envía de nuevo la solicitud para emitir un nuevo enlace.

Gestionar addons

Al cambiar los planes de suscripción, también puedes modificar los addons:

// Add addons to the new plan
await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [
    { addon_id: 'addon_123', quantity: 2 }
  ]
});

// Remove all existing addons
await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [] // Empty array removes all existing addons
});

Los addons se incluyen en el cálculo del prorrateo y se cobran según el modo de prorrateo seleccionado.

Aplicar códigos de descuento

Aplica uno o varios códigos de descuento acumulables al cambiar los planes de suscripción (máximo 20, aplicados en el orden del array):

Node.js SDK
Python SDK
HTTP

// Apply stacked discount codes during plan change
await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  discount_codes: ['UPGRADE20']
});

# Apply stacked discount codes during plan change
client.subscriptions.change_plan(
    subscription_id="sub_123",
    product_id="pdt_pro",
    quantity=1,
    proration_billing_mode="prorated_immediately",
    discount_codes=["UPGRADE20"]
)

curl -X POST "$DODO_API_BASE/subscriptions/sub_123/change-plan" \
  -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "pdt_pro",
    "quantity": 1,
    "proration_billing_mode": "prorated_immediately",
    "discount_codes": ["UPGRADE20"]
  }'

Comportamiento de los descuentos al cambiar de plan

Valor de `discount_codes`	Comportamiento
No proporcionado / `null`	Los descuentos existentes con `preserve_on_plan_change=true` se conservan automáticamente si son aplicables al nuevo producto.
`[]` (array vacío)	Se eliminan todos los descuentos existentes de la suscripción.
`["CODE_A", "CODE_B", ...]`	Reemplaza los descuentos existentes con este conjunto acumulable, validado y aplicado en el orden del array.

El campo singular discount_code de este endpoint está obsoleto, pero sigue funcionando por compatibilidad con versiones anteriores; las integraciones existentes no necesitan cambiarlo de inmediato. No se puede combinar con discount_codes en la misma solicitud. Migra al formato de array cuando te resulte conveniente.

Usa la API de vista previa del cambio de plan con discount_codes para mostrar a los clientes exactamente cuánto ahorrarán antes de confirmar el cambio de plan.

Modos de prorrateo

Elige cómo cobrar al cliente al cambiar de plan:

`prorated_immediately`

Acredita la parte no utilizada del ciclo actual — plan base, cantidad y addons — prorrateada según el tiempo restante
Después cobra un ciclo completo con el nuevo plan, cantidad y addons. El cargo nunca se prorratea
Cargo inmediato neto = (ciclo nuevo completo) − (fracción restante × ciclo antiguo completo)
Si el crédito supera el cargo del nuevo ciclo (algo habitual en los downgrades), la diferencia se conserva como crédito asociado a la suscripción para futuras renovaciones
Si está en período de prueba, cobra inmediatamente y cambia al nuevo plan en ese momento

`full_immediately`

Cobra inmediatamente el importe completo del nuevo plan
Ignora el tiempo restante del plan anterior; no hay crédito por el ciclo actual

Los créditos creados por prorated_immediately y por downgrades que usan difference_immediately están asociados a la suscripción y son distintos de las prestaciones de Credit-Based Billing. Se aplican automáticamente a futuras renovaciones de la misma suscripción y no se pueden transferir entre suscripciones.

`difference_immediately`

Upgrade: cobra inmediatamente la diferencia de precio entre los planes anterior y nuevo
Downgrade: añade el valor restante como crédito interno a la suscripción y lo aplica automáticamente en las renovaciones

`do_not_bill`

No se calculan cargos ni créditos
El cliente cambia inmediatamente al nuevo plan sin ningún ajuste de facturación
El ciclo de facturación no cambia
Ideal para migraciones de cortesía, cambios a planes gratuitos o para absorber diferencias de coste

Funcionalidad	`prorated_immediately`	`difference_immediately`	`full_immediately`	`do_not_bill`
Cargo por upgrade	Ciclo nuevo completo menos el crédito por el tiempo no utilizado	Diferencia de precio completa entre los planes	Precio completo del nuevo plan	Sin cargo
Crédito por downgrade	Crédito por el tiempo no utilizado menos un ciclo nuevo completo	Diferencia de precio completa como crédito	Sin crédito	Sin crédito
Ciclo de facturación	Se reinicia hoy	Se reinicia hoy	Se reinicia hoy	Sin cambios
Comportamiento en prueba	Finaliza la prueba y cobra inmediatamente	Finaliza la prueba y cobra inmediatamente	Finaliza la prueba y cobra el importe completo	Mantiene la fecha de finalización de la prueba, sin cargo
Ideal para	Acreditar tiempo no utilizado	Cálculos sencillos de upgrade/downgrade	Reiniciar ciclos de facturación	Migraciones gratuitas o cambios de cortesía
Complejidad	Media (cálculo por día)	Baja (resta sencilla)	Baja (cargo completo)	Ninguna

Escenarios de ejemplo

Usa estos valores canónicos de forma coherente:

Plan actual: Basic a $30/mes
Objetivo de upgrade: Pro a $80/mes
Objetivo de downgrade (desde Pro): Starter a $20/mes
Ciclo de facturación: 30 días, iniciado el 1 de enero
El cambio de plan ocurre el 16 de enero (quedan 15 días y se han utilizado 15 días)

Upgrade: Basic ($30) → Pro ($80) with prorated_immediately

Step 1: Credit the unused time on the current plan
  Unused days = 15 out of 30 days
  Credit = $30 × (15/30) = $15.00

Step 2: Charge a full cycle at the new plan
  New plan cost = $80.00 (never prorated)

Step 3: Calculate immediate charge
  Charge = Full new cycle − Credit
  Charge = $80.00 − $15.00 = $65.00

→ Customer pays $65.00 now
→ Customer starts a full month of Pro today
→ Billing cycle resets to today (January 16)
→ Next renewal (Feb 15): $80.00/month

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
})

Downgrade: Pro ($80) → Starter ($20) with prorated_immediately

Step 1: Credit the unused time on the current plan
  Unused days = 15 out of 30 days
  Credit = $80 × (15/30) = $40.00

Step 2: Charge a full cycle at the new plan
  New plan cost = $20.00 (never prorated)

Step 3: Net the two
  Net = $20.00 − $40.00 = −$20.00

→ No charge — $20.00 credit added to subscription
→ Billing cycle resets to today (January 16)
→ Credit auto-applies to future renewals
→ Next renewal (Feb 15): $20.00 − $20.00 (from credit) = $0.00 (credit exhausted)
→ Following renewal (Mar 15): $20.00

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_starter',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
})

Upgrade: Basic ($30) → Pro ($80) with difference_immediately

Immediate charge = New plan price − Old plan price
                 = $80 − $30
                 = $50.00

→ Customer pays $50.00 now (regardless of cycle position)
→ Billing cycle resets to today (January 16)
→ Next renewal (Feb 15): $80.00/month

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})

Downgrade: Pro ($80) → Starter ($20) with difference_immediately

Credit = Old plan price − New plan price
       = $80 − $20
       = $60.00

→ No charge — $60.00 credit added to subscription
→ Credit auto-applies to future renewals
→ Next renewal: $20.00 − $20.00 (from credit) = $0.00
→ Following renewal: $20.00 − $20.00 (from credit) = $0.00
→ Third renewal: $20.00 − $20.00 (from remaining credit) = $0.00

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_starter',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})

Upgrade: Basic ($30) → Pro ($80) with full_immediately

Immediate charge = Full new plan price = $80.00

→ Customer pays $80.00 now
→ No credit for unused time on old plan
→ Billing cycle resets to today (January 16)
→ Next renewal: February 16 at $80.00/month

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'full_immediately'
})

Mid-cycle upgrade with add-ons using prorated_immediately

Current: Basic plan ($30/month), no add-ons
New: Pro plan ($80/month) + Extra Seats add-on ($10/seat × 3 seats = $30/month)
Change on day 16 of 30 (15 days remaining)

Step 1: Credit the unused time on the current plan
  Credit = $30 × (15/30) = $15.00

Step 2: Charge a full cycle at the new plan + add-ons
  New plan = $80.00
  Add-ons  = $30.00
  Total new = $110.00 (never prorated)

Step 3: Immediate charge
  Charge = $110.00 − $15.00 = $95.00

→ Customer pays $95.00 now
→ Next renewal: $80.00 + $30.00 = $110.00/month

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  addons: [
    { addon_id: 'addon_seats', quantity: 3 }
  ]
})

Cómo procesa la facturación cada modo

Elige prorated_immediately para acreditar el tiempo no utilizado del plan anterior mientras cobras un ciclo completo del nuevo; elige full_immediately para reiniciar la facturación; usa difference_immediately para upgrades sencillos y crédito automático en downgrades; o usa do_not_bill para cambiar de plan sin ningún ajuste de facturación.

Gestionar fallos de pago

Controla lo que ocurre cuando falla el pago de un cambio de plan mediante el parámetro on_payment_failure.

Modos de fallo de pago

prevent_change (Recommended for critical upgrades)
apply_change (Default)

Comportamiento: Mantener la suscripción en su plan actual hasta que el pago se complete.

El cambio de plan se marca como “pendiente”
El cliente conserva el acceso a su plan actual
La suscripción pasa al estado active solo después de un pago exitoso
Es útil cuando quieres garantizar el pago antes de conceder funcionalidades mejoradas

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  on_payment_failure: 'prevent_change'
});

Comportamiento: Aplicar el cambio de plan inmediatamente independientemente del resultado del pago.

El cambio de plan se aplica incluso si falla el pago
El cliente obtiene acceso inmediato al nuevo plan
La suscripción puede pasar al estado on_hold si falla el pago
Es adecuado para upgrades no críticos o cuando confías en el cliente

await client.subscriptions.changePlan('sub_123', {
  product_id: 'pdt_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately',
  on_payment_failure: 'apply_change' // This is the default
});

Si no se especifica, el parámetro on_payment_failure utiliza la configuración predeterminada a nivel de negocio configurada en el dashboard.

Cuándo usar cada modo

Escenario	Modo recomendado	Motivo
Upgrade a funcionalidades premium	`prevent_change`	Garantizar el pago antes de conceder acceso
Aumento de cantidad (más asientos)	`prevent_change`	Evitar el uso sin pago
Downgrade de planes	`apply_change`	El cliente está reduciendo su gasto
Clientes empresariales de confianza	`apply_change`	Menor riesgo de impago
Conversión de prueba a pago	`prevent_change`	Momento de pago crítico

Valores predeterminados del negocio y de la colección

Establece el comportamiento predeterminado para upgrades y downgrades a nivel de negocio en Settings → Subscriptions. Estos valores se aplican a todos los cambios de plan del portal del cliente y se pueden sobrescribir por colección de productos. Existen valores predeterminados independientes para upgrades y downgrades:

Configuración	Campo (upgrade / downgrade)	Valor predeterminado (upgrade)	Valor predeterminado (downgrade)
Cuándo comienza el nuevo plan	`effective_at_on_upgrade` / `effective_at_on_downgrade`	`immediately`	`next_billing_date`
Cómo se cobra al cliente	`proration_billing_mode_on_upgrade` / `proration_billing_mode_on_downgrade`	`difference_immediately`	`difference_immediately`
Si falla el pago del cliente	`on_payment_failure`	`apply_change`	`apply_change`

Configura los valores predeterminados del negocio en Settings → Subscriptions y las sobrescrituras de cada colección de productos en la colección correspondiente. Cada campo de colección es independiente: déjalo sin establecer para heredar el valor predeterminado del negocio o establece un valor para sobrescribirlo.

Orden de resolución

Para cualquier cambio de plan, cada configuración se resuelve en este orden:

per-request value (Change Plan API) → collection field (if set) → business field → system default

Un valor enviado explícitamente a la API de cambio de plan siempre tiene prioridad. Los valores predeterminados del negocio y de la colección solo se aplican cuando no se proporciona ningún valor explícito, como ocurre con todos los cambios de plan iniciados desde el portal del cliente.

Una configuración habitual es mantener los upgrades en immediately + difference_immediately para que los clientes paguen la diferencia y obtengan acceso de inmediato, y mantener los downgrades en next_billing_date para que conserven su plan actual hasta que termine el ciclo.

Gestionar webhooks

Realiza un seguimiento del estado de las suscripciones mediante webhooks para confirmar cambios de plan y pagos.

Tipos de eventos que se deben gestionar

subscription.active: suscripción activada
subscription.plan_changed: plan de suscripción cambiado (upgrade/downgrade/cambios de addon)
subscription.on_hold: cargo fallido, renovaciones detenidas
subscription.renewed: renovación exitosa
payment.succeeded: pago del cambio de plan o renovación exitoso
payment.failed: pago fallido

Basa la lógica de negocio en los eventos de suscripción y usa los eventos de pago para la confirmación y conciliación.

Verificar firmas y gestionar intenciones

Next.js Route Handler
Express.js

import { NextRequest, NextResponse } from 'next/server';

export async function POST(req) {
  const webhookId = req.headers.get('webhook-id');
  const webhookSignature = req.headers.get('webhook-signature');
  const webhookTimestamp = req.headers.get('webhook-timestamp');
  const secret = process.env.DODO_PAYMENTS_WEBHOOK_KEY;

  const payload = await req.text();
  // verifySignature is a placeholder – in production, use a Standard Webhooks library
  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });

  switch (event.type) {
    case 'subscription.active':
      // mark subscription active in your DB
      break;
    case 'subscription.plan_changed':
      // refresh entitlements and reflect the new plan in your UI
      break;
    case 'subscription.on_hold':
      // notify user to update payment method
      break;
    case 'subscription.renewed':
      // extend access window
      break;
    case 'payment.succeeded':
      // reconcile payment for plan change
      break;
    case 'payment.failed':
      // log and alert
      break;
    default:
      // ignore unknown events
      break;
  }

  return NextResponse.json({ received: true });
}

import express from 'express';

const app = express();
app.post('/webhooks/dodo', express.raw({ type: 'application/json' }), async (req, res) => {
  const webhookId = req.header('webhook-id');
  const webhookSignature = req.header('webhook-signature');
  const webhookTimestamp = req.header('webhook-timestamp');
  const secret = process.env.DODO_PAYMENTS_WEBHOOK_KEY;
  const payload = req.body.toString('utf8');

  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return res.status(400).send('Invalid signature');

  // handle events like above
  res.json({ received: true });
});

app.listen(3000);

Para consultar los esquemas detallados de las cargas útiles, consulta las cargas útiles de webhook de suscripción y las cargas útiles de webhook de pago.

Prácticas recomendadas

Estrategia de cambio de plan

Prueba exhaustivamente: prueba siempre los cambios de plan en modo de prueba antes de producción
Elige cuidadosamente el prorrateo: selecciona el modo de prorrateo que se ajuste a tu modelo de negocio
Gestiona los fallos correctamente: implementa una gestión de errores y una lógica de reintentos adecuadas
Supervisa las tasas de éxito: realiza un seguimiento de las tasas de éxito y fallo de los cambios de plan e investiga los problemas

Implementación de webhooks

Verifica las firmas: valida siempre las firmas de los webhooks para garantizar su autenticidad
Implementa la idempotencia: gestiona correctamente los eventos de webhook duplicados
Procesa de forma asíncrona: no bloquees las respuestas de los webhooks con operaciones pesadas
Regístralo todo: mantén registros detallados para depuración y auditoría

Experiencia de usuario

Comunica con claridad: informa a los clientes sobre los cambios de facturación y sus tiempos
Proporciona confirmaciones: envía correos de confirmación para los cambios de plan exitosos
Gestiona los casos límite: considera los períodos de prueba, los prorrateos y los pagos fallidos
Actualiza la interfaz inmediatamente: refleja los cambios de plan en la interfaz de tu aplicación

Problemas comunes y soluciones

Resuelve los problemas habituales que se producen durante los cambios de plan de suscripción:

Charge created but subscription not updated

Síntomas: la llamada a la API se completa correctamente, pero la suscripción permanece en el plan anteriorCausas comunes:

El procesamiento del webhook falló o se retrasó
El estado de la aplicación no se actualizó después de recibir los webhooks
Problemas de transacción de la base de datos durante la actualización del estado

Soluciones:

Implementa la gestión de webhooks con lógica de reintentos
Usa operaciones idempotentes para actualizar el estado
Añade supervisión para detectar y alertar sobre eventos de webhook perdidos
Verifica que el endpoint de webhook sea accesible y responda correctamente

Credits not applied after downgrade

Síntomas: el cliente realiza un downgrade, pero no ve el saldo de créditoCausas comunes:

Expectativas sobre el modo de prorrateo: los downgrades acreditan la diferencia total de precio del plan con difference_immediately, mientras que prorated_immediately acredita el tiempo no utilizado del ciclo anterior y después cobra un ciclo completo del nuevo plan; por eso, el saldo de crédito solo permanece cuando ese crédito supera el precio del nuevo plan
Los créditos son específicos de cada suscripción y no se transfieren entre suscripciones
El saldo de crédito no es visible en el panel del cliente

Soluciones:

Usa difference_immediately para downgrades cuando quieras créditos automáticos
Explica a los clientes que los créditos se aplican a futuras renovaciones de la misma suscripción
Implementa el portal del cliente para mostrar los saldos de crédito
Comprueba la vista previa de la próxima factura para ver los créditos aplicados

Webhook signature verification fails

Síntomas: los eventos de webhook se rechazan debido a una firma no válidaCausas comunes:

Clave secreta de webhook incorrecta
El cuerpo sin procesar de la solicitud se modificó antes de verificar la firma
Algoritmo de verificación de firma incorrecto

Soluciones:

Verifica que utilizas el DODO_PAYMENTS_WEBHOOK_KEY correcto del dashboard
Lee el cuerpo sin procesar de la solicitud antes de cualquier middleware de análisis JSON
Usa la biblioteca estándar de verificación de webhooks para tu plataforma
Prueba la verificación de firmas de webhook en el entorno de desarrollo

Plan change fails with 422 error

Síntomas: la API devuelve un error 422 Unprocessable EntityCausas comunes:

ID de suscripción o ID de producto no válido
La suscripción no está en estado activo
Faltan parámetros obligatorios
El producto no está disponible para cambios de plan

Soluciones:

Verifica que la suscripción exista y esté activa
Comprueba que el ID de producto sea válido y esté disponible
Asegúrate de proporcionar todos los parámetros obligatorios
Consulta la documentación de la API para conocer los requisitos de los parámetros

Immediate charge fails during plan change

Síntomas: se inició el cambio de plan, pero falla el cargo inmediatoCausas comunes:

Fondos insuficientes en el método de pago del cliente
Método de pago caducado o no válido
El banco rechazó la transacción
La detección de fraude bloqueó el cargo

Soluciones:

Gestiona correctamente los eventos de webhook payment.failed
Notifica al cliente que actualice su método de pago
Implementa una lógica de reintentos para fallos temporales
Considera permitir cambios de plan con cargos inmediatos fallidos

Subscription on hold after plan change

Síntomas: falla el cargo del cambio de plan y la suscripción pasa al estado on_holdQué ocurre: Cuando falla el cargo de un cambio de plan, la suscripción pasa automáticamente al estado on_hold. La suscripción no se renovará automáticamente hasta que se actualice el método de pago.Solución: actualiza el método de pago para reactivar la suscripciónPara reactivar una suscripción en estado on_hold después de un cambio de plan fallido:

Actualiza el método de pago mediante la API de actualización del método de pago
Creación automática del cargo: la API crea automáticamente un cargo por los importes pendientes
Generación de la factura: se genera una factura para el cargo
Procesamiento del pago: el pago se procesa con el nuevo método de pago
Reactivación: tras un pago exitoso, la suscripción se reactiva al estado active

// Reactivate subscription from on_hold after failed plan change
async function reactivateAfterFailedPlanChange(subscriptionId) {
  // Update payment method - automatically creates charge for remaining dues
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    payment_method: { type: 'new', return_url: 'https://example.com/return' }
  });
  
  if (response.payment_id) {
    console.log('Charge created for remaining dues:', response.payment_id);
    console.log('Payment link:', response.payment_link);
    
    // Redirect customer to payment_link to complete payment
    // Monitor webhooks for:
    // 1. payment.succeeded - charge succeeded
    // 2. subscription.active - subscription reactivated
  }
  
  return response;
}

// Or use existing payment method if available
async function reactivateWithExistingPaymentMethod(subscriptionId, paymentMethodId) {
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    payment_method: { type: 'existing', payment_method_id: paymentMethodId }
  });
  
  // Monitor webhooks for payment.succeeded and subscription.active
  return response;
}

# Reactivate subscription from on_hold after failed plan change
def reactivate_after_failed_plan_change(subscription_id):
    # Update payment method - automatically creates charge for remaining dues
    response = client.subscriptions.update_payment_method(
        subscription_id=subscription_id,
        payment_method={"type": "new", "return_url": "https://example.com/return"},
    )
    
    if response.payment_id:
        print("Charge created for remaining dues:", response.payment_id)
        print("Payment link:", response.payment_link)
        
        # Redirect customer to payment_link to complete payment
        # Monitor webhooks for:
        # 1. payment.succeeded - charge succeeded
        # 2. subscription.active - subscription reactivated
    
    return response

# Or use existing payment method if available
def reactivate_with_existing_payment_method(subscription_id, payment_method_id):
    response = client.subscriptions.update_payment_method(
        subscription_id=subscription_id,
        payment_method={"type": "existing", "payment_method_id": payment_method_id},
    )
    
    # Monitor webhooks for payment.succeeded and subscription.active
    return response

Eventos de webhook que se deben supervisar:

subscription.on_hold: suscripción puesta en espera (se recibe cuando falla el cargo del cambio de plan)
payment.succeeded: pago de los importes pendientes exitoso (después de actualizar el método de pago)
subscription.active: suscripción reactivada después de un pago exitoso

Prácticas recomendadas:

Notifica inmediatamente a los clientes cuando falle el cargo de un cambio de plan
Proporciona instrucciones claras sobre cómo actualizar el método de pago
Supervisa los eventos de webhook para realizar un seguimiento del estado de reactivación
Considera implementar una lógica de reintentos automáticos para fallos de pago temporales

Update Payment Method API Reference

Consulta la documentación completa de la API para actualizar métodos de pago y reactivar suscripciones.

Probar tu implementación

Prueba exhaustivamente tu implementación del cambio de plan de suscripción:

Set up test environment

Usa claves de API y productos de prueba
Crea suscripciones de prueba con distintos tipos de plan
Configura un endpoint de webhook de prueba
Configura la supervisión y el registro

Test different proration modes

Prueba prorated_immediately con distintas posiciones del ciclo de facturación
Prueba difference_immediately para upgrades y downgrades
Prueba full_immediately para reiniciar los ciclos de facturación
Prueba do_not_bill para cambios de plan sin cargo ni crédito
Verifica que los cálculos de crédito sean correctos

Test webhook handling

Verifica que se reciban todos los eventos de webhook relevantes
Prueba la verificación de firmas de webhook
Gestiona correctamente los eventos de webhook duplicados
Prueba escenarios de fallo en el procesamiento de webhooks

Test error scenarios

Prueba con IDs de suscripción no válidos
Prueba con métodos de pago caducados
Prueba fallos de red y tiempos de espera agotados
Prueba con fondos insuficientes

Monitor in production

Configura alertas para cambios de plan fallidos
Supervisa los tiempos de procesamiento de webhooks
Realiza un seguimiento de las tasas de éxito de los cambios de plan
Revisa los tickets de soporte al cliente relacionados con problemas de cambios de plan

Gestión de errores

Gestiona correctamente los errores habituales de la API en tu implementación:

Códigos de estado HTTP

200 OK

La solicitud de cambio de plan se procesó correctamente. El cuerpo de respuesta es un ChangePlanResponse con payment_id, payment_link, client_secret y expires_on. Los cuatro valores aceptan null, por lo que el cuerpo se serializa como {} para un cambio ordinario fuera de sesión; se rellenan para una solicitud collect_via_payment_link exitosa, que devuelve identificadores de checkout. Consulta Cobrar mediante un enlace de checkout. Si on_payment_failure=prevent_change, el cambio de plan permanece pendiente hasta que el pago se complete.

400 Bad Request

Parámetros de solicitud no válidos. Comprueba que todos los campos obligatorios estén presentes y tengan el formato correcto.

401 Unauthorized

Clave de API no válida o ausente. Verifica que tu DODO_PAYMENTS_API_KEY sea correcta y tenga los permisos adecuados.

409 Conflict

Ya existe un cambio de plan pendiente para esta suscripción (PendingPlanChangeExists). Para un cambio programado, cancélalo con DELETE /subscriptions/{subscription_id}/change-plan/scheduled antes de enviar uno nuevo. Para un cambio mediante enlace de pago pendiente, envía la nueva solicitud con cancel_older_payment_link: true para reemplazarlo. Consulta Reemplazar un enlace de pago pendiente.Con cancel_older_payment_link: true, un 409 significa que el cliente está pagando el enlace anterior (PLAN_CHANGE_PAYMENT_IN_PROGRESS) o ya lo ha pagado (PLAN_CHANGE_PAYMENT_ALREADY_COMPLETED).

503 Service Unavailable

Con cancel_older_payment_link: true, el enlace de pago anterior no se pudo cancelar (PLAN_CHANGE_LINK_CANCEL_FAILED). No se modificó nada, así que puedes reintentar la solicitud.

422 Unprocessable Entity

La suscripción está inactiva o es bajo demanda, o la solicitud no cumple los requisitos para collect_via_payment_link: el negocio no tiene habilitada la capacidad, effective_at no es immediately o on_payment_failure no es prevent_change. Consulta Requisitos. Un ID de suscripción que no existe o no pertenece a tu cuenta devuelve 404 con el código NOT_FOUND.

500 Internal Server Error

Se produjo un error del servidor. Reintenta la solicitud después de una breve espera.

Formato de respuesta de error

Los errores devuelven un cuerpo JSON con un code y un message legible para las personas:

{
  "code": "INACTIVE_SUBSCRIPTION_PLAN_CHANGE_NOT_SUPPORTED",
  "message": "Changing plans is not supported for inactive subscriptions"
}

Consulta Códigos de error para obtener la lista completa.

Próximos pasos

Consulta la API de cambio de plan
Explora Credit-Based Billing
Implementa alertas para subscription.on_hold
Consulta la Guía de integración de webhooks

Change Plan API

Plan Change Preview

Integration Guide

​¿Qué es una actualización o degradación de una suscripción?

​Cuándo usar cambios de plan

​Plan Change Flow

​Prerequisites

​Step-by-Step Implementation Guide

​Previsualizar cambios de plan

​API de cambio de plan

​Ejemplos de inicio rápido

​Cobrar mediante un enlace de checkout

​Requisitos

​Qué ocurre mientras el enlace está impagado

​Redirigir al cliente después del pago

​Reemplazar un enlace de pago pendiente

​Gestionar addons

​Aplicar códigos de descuento

​Comportamiento de los descuentos al cambiar de plan

​Modos de prorrateo

​prorated_immediately

​full_immediately

​difference_immediately

​do_not_bill

​Escenarios de ejemplo

​Cómo procesa la facturación cada modo

​Gestionar fallos de pago

​Modos de fallo de pago

​Cuándo usar cada modo

​Valores predeterminados del negocio y de la colección

​Orden de resolución

​Gestionar webhooks

​Tipos de eventos que se deben gestionar

​Verificar firmas y gestionar intenciones

​Prácticas recomendadas

​Estrategia de cambio de plan

​Implementación de webhooks

​Experiencia de usuario

​Problemas comunes y soluciones

Update Payment Method API Reference

​Probar tu implementación

​Gestión de errores

​Códigos de estado HTTP

​Formato de respuesta de error

​Próximos pasos

¿Qué es una actualización o degradación de una suscripción?

Cuándo usar cambios de plan

Plan Change Flow

Prerequisites

Step-by-Step Implementation Guide

Previsualizar cambios de plan

API de cambio de plan

Ejemplos de inicio rápido

Cobrar mediante un enlace de checkout

Requisitos

Qué ocurre mientras el enlace está impagado

Redirigir al cliente después del pago

Reemplazar un enlace de pago pendiente

Gestionar addons

Aplicar códigos de descuento

Comportamiento de los descuentos al cambiar de plan

Modos de prorrateo

`prorated_immediately`

`full_immediately`

`difference_immediately`

`do_not_bill`

Escenarios de ejemplo

Cómo procesa la facturación cada modo

Gestionar fallos de pago

Modos de fallo de pago

Cuándo usar cada modo

Valores predeterminados del negocio y de la colección

Orden de resolución

Gestionar webhooks

Tipos de eventos que se deben gestionar

Verificar firmas y gestionar intenciones

Prácticas recomendadas

Estrategia de cambio de plan

Implementación de webhooks

Experiencia de usuario

Problemas comunes y soluciones

Probar tu implementación

Gestión de errores

Códigos de estado HTTP

Formato de respuesta de error

Próximos pasos