Skip to main content

Förutsättningar

För att integrera Dodo Payments API behöver du:
  • Ett Dodo Payments handelskonto
  • API-uppgifter (API-nyckel och webhook hemlig nyckel) från instrumentpanelen
För en mer detaljerad guide om förutsättningarna, kolla in den här sektionen.

API-integration

Utcheckningssessioner

Använd Checkout Sessions för att sälja prenumerationsprodukter via en säker, värdhanterad kassa. Skicka din prenumerationsprodukt i product_cart och omdirigera kunderna till den returnerade checkout_url.
Mixed Checkout: Du kan kombinera prenumerationsprodukter med engångsprodukter i samma kassasession. Detta möjliggör användningsfall som installationsavgifter tillsammans med prenumerationer, hårdvarupaket med SaaS och mer. Se Checkout Sessions guide för exempel.

API-svar

Följande är ett exempel på svaret:
Omdirigera kunden till checkout_url.

Webhooks

När du integrerar prenumerationer kommer du att få webhooks för att spåra prenumerationslivscykeln. Dessa webhooks hjälper dig att hantera prenumerationsstatusar och betalningsscenarier effektivt. För att ställa in din webhook-slutpunkt, följ vår Detaljerade integrationsguide.

Prenumerationseventtyper

Följande webhook-händelser spårar ändringar i prenumerationsstatus:
  1. subscription.active - Prenumerationen aktiveras framgångsrikt.
  2. subscription.updated - Prenumerationsobjektet uppdaterades (utlöses vid alla fältändringar).
  3. subscription.on_hold - Prenumerationen sätts på paus på grund av misslyckad förnyelse.
  4. subscription.failed - Skapandet av prenumerationen misslyckades under skapandet av mandatet.
  5. subscription.renewed - Prenumerationen förnyas för nästa faktureringsperiod.
För pålitlig hantering av prenumerationslivscykeln rekommenderar vi att spåra dessa prenumerationsevent.
Använd subscription.updated för att få realtidsnotifikationer om alla prenumerationsändringar och hålla din applikationsstatus synkroniserad utan att poll:a API:et.

Betalningsscenarier

De webhooks du tar emot och deras timing beror på om produkten har en provperiod. Omedelbar debitering (0 provdagar):
  1. subscription.active: medgivandet auktoriseras och prenumerationen aktiveras.
  2. payment.succeeded: bekräftar den första debiteringen. Förvänta dig detta inom 2–10 minuter efter checkout.
Med en provperiod:
  1. Vid provperiodens start (checkout): subscription.active utlöses när betalningsmetoden har auktoriserats. Ingen återkommande debitering görs ännu. Den första riktiga debiteringen skjuts upp tills provperioden är slut.
  2. Vid provperiodens slut: det återkommande beloppet debiteras och du tar emot payment.succeeded tillsammans med subscription.renewed.
Varje efterföljande förnyelse:
  • subscription.renewed: utlöses vid varje faktureringsperiod när förnyelsebetalningen dras, alltid tillsammans med payment.succeeded. Den innehåller även den uppdaterade next_billing_date.
Varje gång pengar faktiskt dras för en prenumerationsprodukt får du subscription.renewed och payment.succeeded. Använd subscription.renewed (i stället för endast payment.succeeded) som signal för att förlänga åtkomsten till nästa period.
Scenarier för misslyckade betalningar
  1. Prenumerationsfel
  • subscription.failed – Det gick inte att skapa prenumerationen eftersom ett medgivande inte kunde skapas.
  • payment.failed – Anger en misslyckad betalning.
  1. Prenumeration pausad
  • subscription.on_hold – Prenumerationen pausas på grund av en misslyckad förnyelsebetalning eller en misslyckad debitering för planändring.
  • När en prenumeration pausas förnyas den inte automatiskt förrän betalningsmetoden har uppdaterats.
Bästa praxis: För att förenkla implementeringen rekommenderar vi att du främst spårar prenumerationshändelser för att hantera prenumerationens livscykel.
För en fullständig genomgång av hur du läser error_code/error_message, avgör när du ska försöka igen och visar fel för kunder, se Hantera misslyckade betalningar.

subscription.failed jämfört med subscription.on_hold

Dessa två händelser är lätta att blanda ihop, men de kräver helt olika hantering:
subscription.failed är slutgiltig. Prenumerationen kan inte återaktiveras. Kunden måste skapa en ny prenumeration. Ge aldrig behörigheter när denna händelse utlöses.

Hantera pausad prenumeration

När en prenumeration övergår till tillståndet on_hold måste du uppdatera betalningsmetoden för att återaktivera den. Det här avsnittet förklarar när prenumerationer pausas och hur du hanterar dem.

När prenumerationer pausas

En prenumeration pausas när:
  • Förnyelsebetalningen misslyckas: Den automatiska förnyelsedebiteringen misslyckas på grund av otillräckliga medel, ett utgånget kort eller att banken nekar betalningen
  • Debiteringen för planändringen misslyckas: En omedelbar debitering under en upp- eller nedgradering av planen misslyckas
  • Auktorisering av betalningsmetoden misslyckas: Betalningsmetoden kan inte auktoriseras för återkommande debiteringar
Prenumerationer i tillståndet on_hold förnyas inte automatiskt. Du måste uppdatera betalningsmetoden för att återaktivera prenumerationen.

Återaktivera prenumerationer från pausat tillstånd

För att återaktivera en prenumeration från tillståndet on_hold använder du API:t Update Payment Method. Detta gör automatiskt följande:
  1. Skapar en debitering för återstående belopp
  2. Genererar en faktura för debiteringen
  3. Behandlar betalningen med den nya betalningsmetoden
  4. Återaktiverar prenumerationen till tillståndet active när betalningen har genomförts
1

Handle subscription.on_hold webhook

När du tar emot en webhook av typen subscription.on_hold uppdaterar du applikationens tillstånd och meddelar kunden:
2

Update payment method

När kunden är redo att uppdatera sin betalningsmetod anropar du API:t Update Payment Method:
Du kan även använda ett befintligt ID för betalningsmetoden om kunden har sparade betalningsmetoder:
3

Monitor webhook events

När du har uppdaterat betalningsmetoden övervakar du följande webhook-händelser:
  1. payment.succeeded – Debiteringen för återstående belopp genomfördes
  2. subscription.active – Prenumerationen har återaktiverats

Exempel på payload för prenumerationshändelse


Ändra prenumerationsplaner

Du kan uppgradera eller nedgradera en prenumerationsplan med API-endpointen för planändring. Detta låter dig ändra prenumerationens produkt och antal samt hantera proportionell debitering.

Change Plan API Reference

Mer detaljerad information om hur du ändrar prenumerationsplaner finns i vår API-dokumentation för Change Plan.

Alternativ för proportionell debitering

När du ändrar prenumerationsplaner har du två alternativ för hur den omedelbara debiteringen ska hanteras:

1. prorated_immediately

  • Beräknar det proportionella beloppet baserat på den återstående tiden i den aktuella faktureringsperioden
  • Debiterar kunden endast skillnaden mellan den gamla och den nya planen
  • Under en provperiod växlar användaren omedelbart till den nya planen och kunden debiteras direkt

2. full_immediately

  • Debiterar kunden hela prenumerationsbeloppet för den nya planen
  • Ignorerar eventuell återstående tid eller krediter från den föregående planen
  • Användbart när du vill återställa faktureringsperioden eller debitera hela beloppet oavsett proportionell debitering

3. difference_immediately

  • Vid uppgradering debiteras kunden omedelbart skillnaden mellan de två planbeloppen.
  • Om den aktuella planen till exempel kostar 30 dollar och kunden uppgraderar till en plan på 80 dollar debiteras de $50 direkt.
  • Vid nedgradering läggs det outnyttjade beloppet från den aktuella planen till som en intern kredit och används automatiskt vid framtida förnyelser av prenumerationen.
  • Om den aktuella planen till exempel kostar 50 dollar och kunden byter till en plan på 20 dollar krediteras de återstående $30 och används under nästa faktureringsperiod.

4. do_not_bill

  • Tillämpas planändringen omedelbart men debiterar ingenting vid ändringstillfället.
  • Den uppdaterade planen (samt antal/tillägg) faktureras vid nästa schemalagda förnyelse, och det ursprungliga faktureringsdatumet bevaras.
Alla tre lägena för “debitera nu” återställer faktureringsperioden. prorated_immediately, difference_immediately och full_immediately flyttar prenumerationens next_billing_date till ändringsdatumet. Endast do_not_bill behåller det ursprungliga förnyelsedatumet, men tillämpar ingen omedelbar debitering.

Beteende

  • När du anropar detta API initierar Dodo Payments omedelbart en debitering baserat på det valda alternativet för proportionell debitering
  • Om planändringen är en nedgradering och du använder prorated_immediately beräknas krediter automatiskt och läggs till i prenumerationens kreditsaldo. Dessa krediter gäller endast den prenumerationen och används bara för att kvitta framtida återkommande betalningar för samma prenumeration
  • Alternativet full_immediately kringgår kreditberäkningar och debiterar hela beloppet för den nya planen
Välj alternativet för proportionell debitering noggrant: Använd prorated_immediately för rättvis debitering som tar hänsyn till outnyttjad tid, eller full_immediately när du vill debitera hela beloppet för den nya planen oavsett aktuell faktureringsperiod.

Debiteringsbehandling

  • Den omedelbara debiteringen som initieras vid planändringen slutförs vanligtvis på mindre än 2 minuter
  • Om denna omedelbara debitering misslyckas av någon anledning pausas prenumerationen automatiskt tills problemet har lösts

On-demand-prenumerationer

Create Subscription

API-referens för att skapa prenumerationsprodukter och hantera prenumerationens livscykel

Change Subscription Plan

API-referens för att uppgradera, nedgradera eller ändra prenumerationsplaner med prorateringsalternativ

Update Payment Method

API-referens för att uppdatera betalningsmetoder och återaktivera prenumerationer som är i vänteläge

Patch Subscription

API-referens för att uppdatera prenumerationsdetaljer och konfiguration
Så här skapar du en on-demand-prenumeration: För att skapa en on-demand-prenumeration använder du API-endpointen POST /subscriptions och inkluderar fältet on_demand i request body. Detta låter dig auktorisera en betalningsmetod utan en omedelbar debitering eller ange ett anpassat startpris. Så här debiterar du en on-demand-prenumeration: För efterföljande debiteringar använder du endpointen POST /subscriptions//charge och anger det belopp som ska debiteras kunden för transaktionen.
För en fullständig steg-för-steg-guide (inklusive exempel på request/response, säkra retry-policyer och webhook-hantering), se guiden för on-demand-prenumerationer.

Viktigt att känna till om prenumerationsfakturering

Ange en längre prenumerationsperiod än betalningsfrekvensen. Om prenumerationsperioden är lika lång som betalningsfrekvensen (t.ex. period = 1 månad, frekvens = 1 månad) gäller prenumerationen under en enda period och övergår sedan till expired i stället för att förnyas. För en löpande månadsplan anger du en lång prenumerationsperiod (t.ex. 20 år) med månadsvis betalningsfrekvens.
Valutan låses vid den första lyckade debiteringen. Ange alltid billing_currency och billing_address.country uttryckligen när du skapar checkout. Om de utelämnas identifieras de utifrån kundens IP (Adaptive Currency), och när prenumerationen debiteras för första gången är valutan fast under hela dess livstid. En kund som senare reser kan inte byta valuta.
Provperioder innebär en auktorisering på $0, inte en debitering. När en prenumeration har en provperiod skapar provperiodens start en medgivandeauktorisering på $0 för att spara kortet; den första riktiga debiteringen sker när provperioden slutar. I betalningslistan visas en prenumeration under provperiod med exakt en betalning med amount: 0.
Prenumerationens livscykel: on_hold = en förnyelse misslyckades (kan återställas: be kunden uppdatera sin betalningsmetod; dunning-försök tillämpas). expired = perioden avslutades utan förnyelse och kan inte återaktiveras. Kunden måste prenumerera igen. cancelled = avslutad av kunden eller handlaren. De flesta misslyckade förnyelser beror på avslag från kortutgivaren (otillräckliga medel, nekade kort), inte på ett Dodo-fel.
Indiska kort använder ett RBI-e-mandat. Off-session-debiteringar (förnyelser och debiteringar för planändringar) kan ta upp till cirka 48 timmar att avräknas, och återkommande autogirodebiteringar över ₹15,000 kräver ny kundautentisering (så en uppgradering som överskrider gränsen kan inte använda det befintliga medgivandet). Så länge en debitering fortfarande har processing misslyckas en andra debitering på samma prenumeration med “Cannot create new charge as previous payment is not successful yet.” Icke-indiska kort bekräftas nästan omedelbart.
Prenumerationsdebiteringar har ett minimibelopp på $1 (eller motsvarande i annan valuta). Belopp på $0.01–$0.99 avvisas med product_price: value out of range; endast $0 är tillåtet via en on-demand mandate_only-konfiguration.

Relaterad API-referens

Create Subscription

API-referens för att skapa prenumerationsprodukter och hantera prenumerationens livscykel

Change Subscription Plan

API-referens för att uppgradera, nedgradera eller ändra prenumerationsplaner med alternativ för proportionell debitering

Update Payment Method

API-referens för att uppdatera betalningsmetoder och återaktivera pausade prenumerationer

Patch Subscription

API-referens för att uppdatera prenumerationsuppgifter och konfiguration
Senast ändrad 31 juli 2026