Skip to main content

Quick Start

De fyra stegen från din backend till checkouten och tillbaka.

Platform Examples

Kod för Android, iOS, React Native och Flutter.

Checkout Customization

De 14 viktigaste parametrarna för checkout-sessionen på mobil.

Mobile Recipes

Fullständiga request bodies för 5 vanliga mobilsituationer.
Din mobilapp öppnar Dodo Payments hostade checkout i plattformens systemwebbläsare och tar kunden tillbaka till appen när checkouten avslutas. Din backend skapar checkout-sessionen och beviljar åtkomst via webhooks.
Dodo Payments tillhandahåller ett officiellt checkout-SDK för Android, iOS, React Native och Flutter. Varje SDK öppnar checkout-URL:en, fångar returen och tolkar resultatet bakom ett typat start(...)-anrop. Alla SDK:n innehåller även återställning av övergivna sessioner. Bygg flödet manuellt endast om inget av SDK:n passar din stack.

Förutsättningar

Innan du börjar behöver du:
  • Ett Dodo Payments-konto.
  • En API-nyckel från Developer → API Keys och en webhook-signaturhemlighet från Developer → Webhooks.
  • En Android-, iOS-, React Native- eller Flutter-app.
  • En backend-server som skapar checkout-sessioner. API-nyckeln ska finnas kvar på denna server.

Integrationsflöde

Din backend gör alla Dodo Payments API-anrop. Appen ber endast din backend om en checkout-URL, öppnar den och visar resultatet.
status i deep linken talar om för appen vad som ska visas för kunden. Den är inte ett bevis på betalning. Bevilja åtkomst från payment.succeeded- eller subscription.active-webhooken på din backend, inte från mobilresultatet.
1

Backend: Create Checkout Session

Din backend skapar en checkout-session med din API-nyckel och returnerar dess checkout_url till appen. Ange sessionens return_url som den deep link som appen registrerar, till exempel myapp://checkout/return.

Checkout Session API Docs

Skapa en checkout-session från Node.js, Python och andra språk med den fullständiga parameterreferensen.
Säkerhet: Skapa checkout-sessioner på din backend-server, aldrig i mobilappen. Vem som helst kan extrahera en API-nyckel från en appbinär.
2

Mobile: Get Checkout URL

Appen anropar din backend för att hämta checkout-URL:en. Autentisera denna begäran med den inloggade användarens egen sessionstoken. I varje exempel är userSessionToken den token och CheckoutResponse din egen svarstyp.
Säkerhet: Appen kommunicerar endast med din backend, aldrig direkt med Dodo Payments API.
3

Mobile: Open Checkout in Browser

Öppna checkout-URL:en i plattformens systemwebbläsare. Det officiella checkout-SDK:t för din plattform gör detta åt dig och returnerar ett typat resultat.

Pick your mobile SDK

Installationssteg och konfigurationsinstruktioner för Android, iOS, React Native och Flutter.
4

Backend: Handle Payment Completion

Bevilja åtkomst när din backend tar emot payment.succeeded- eller subscription.active-webhooken. Använd resultatet från retur-URL:en endast för att uppdatera appens skärm.

Välj ditt SDK

Alla mobila SDK:n har samma kontrakt. Ett start(...)-anrop öppnar Dodo Payments hostade checkout i plattformens systemwebbläsare och returnerar en typad CheckoutResult vars status är succeeded, failed, cancelled, pending eller expired. Inget SDK innehåller en API-nyckel eller anropar Dodo Payments API, och alla fyra stöder återställning av övergivna sessioner.

Android

com.dodopayments.api:checkout-android öppnar en Custom Tab. Kräver minSdk 23.

iOS

dodopayments-mobile-sdk-ios öppnar SFSafariViewController. Kräver iOS 16+.

React Native

@dodopayments/react-native-checkout, en Turbo Module över båda native-kärnorna. Kräver React Native 0.77+ med New Architecture.

Flutter

dodopayments_checkout, en Pigeon-kanal över båda native-kärnorna. Kräver Flutter 3.44+.
Det returnerade status är en UI-indikering, inte ett bevis på betalning. Bekräfta varje betalning på din backend från payment.succeeded- eller subscription.active-webhooken, eller genom att hämta betalningen med din API-nyckel. Statusen cancelled betyder att kunden stängde webbläsaren innan retur-URL:en kom fram, så betalningen kan ändå ha lyckats. Visa den inte som ett misslyckande.

Registrera ett callback-URL-schema

Alla fyra SDK:n lämnar tillbaka kontrollen till appen via ett anpassat URL-schema som du väljer, till exempel myapp://checkout/return. Registrera det en gång per plattform:
android/app/build.gradle
SDK:ts eget manifest deklarerar redan redirect-aktiviteten, så du behöver inte lägga till någon manifest-XML. Schemat måste matcha schemat för returnUrl.
Om du bygger flödet själv öppnar du checkout_url i plattformens systemwebbläsare (en Custom Tab på Android, SFSafariViewController på iOS), fångar navigeringen till din return_url och läser query-parametrarna status och payment_id. SDK:na gör detta åt dig.
Öppna inte checkout i en inbäddad WebView (WKWebView eller Android WebView). En inbäddad WebView kan störa 3-D Secure-utmaningar och automatisk ifyllning av sparade kort, så att kunder ser fler misslyckade betalningar. Använd SDK:t eller öppna checkout_url i systemets webbläsaryta. På iOS öppnar du den i SFSafariViewController eller ASWebAuthenticationSession, eller i systemets webbläsare, så att Apple Pay är tillgängligt. På Android öppnar du den i en Custom Tab, som körs i kundens webbläsare, så att Google Pay fortsätter att fungera.

Anpassa utseendet

Alla SDK:n accepterar en valfri customization-parameter i start(...) eller CheckoutParams. Den styr systemwebbläsaren: verktygsfältet, knapparna och hur webbläsaren visas. Checkout-sidans eget tema är separat. Du anger det på servern med customization.theme_config när du skapar checkout-sessionen. Alternativen är grupperade per plattform eftersom en Custom Tab på Android och SFSafariViewController på iOS visar olika native-kontroller. Alla fält är valfria. Ett fält som inte anges lämnar plattformens standardvärde oförändrat.
Color
Bakgrundsfärg för verktygsfältet.
Color
Färg för navigeringsfältet.
Color
Avdelarfärg ovanför navigeringsfältet.
'default' | 'back'
default visar systemets “X”-ikon; back visar i stället en bakåtpil.
'start' | 'end'
Vilken sida av verktygsfältet stängningsknappen visas på.
boolean
Visar verktygsfältets delningsikon.
boolean
Visar sidans titel under URL:en i verktygsfältet.
boolean
Låter verktygsfältet döljas automatiskt när sidan rullas.
boolean
Visar “Bokmärk den här sidan” i menyn med fler alternativ.
boolean
Visar “Ladda ned sidan” i menyn med fler alternativ.
'system' | 'light' | 'dark'
Tvingar fram ljust eller mörkt utseende oavsett enhetens systeminställning.
'done' | 'close' | 'cancel'
Etikett eller ikon för avvisningsknappen.
'pageSheet' | 'fullScreen'
standard:"pageSheet"
pageSheet visar checkouten som ett kort som kunden kan svepa bort. fullScreen täcker hela skärmen.
boolean
Låter verktygsfältet fällas ihop vid rullning. Det syns endast när presentationStyle är fullScreen. Med pageSheet förblir fälten fixerade.
'system' | 'light' | 'dark'
Tvingar fram ljust eller mörkt utseende oavsett enhetens systeminställning.
Exemplen nedan anger en verktygsfärg och en stängningsknapp på Android samt en mörk presentation i helskärm på iOS. React Native och Flutter använder separata alternativgrupper för android och ios. Native-SDK:n använder endast alternativen för sin egen plattform.

Anpassa checkout-sidan

Själva checkout-sidan (vilka fält som visas, temat och vilka betalningsmetoder som visas) ställs in på servern när du skapar checkout-sessionen. Anpassa utseendet gäller endast webbläsaren runt omkring. Parametrarna nedan har störst effekt på mobil konvertering. Dessa parametrar finns på tre platser i begäran om checkout-sessionen: på toppnivån, i customization eller i feature_flags. Kolumnen Var den placeras anger objektet för varje parameter. Placera varje parameter i objektet som visas, eftersom en parameter i fel objekt inte har någon effekt.
Skicka billing_currency och billing_address.country tillsammans. Om du utelämnar någon av dem kan Adaptive Currency välja faktureringsvaluta utifrån kundens IP-adress. En kund från USA som reser i Europa kan till exempel faktureras i EUR när faktureringslandet inte har angetts.
Största ökningen av mobil konvertering: ange show_order_details: false och minimal_address: true. Tillsammans flyttar de upp betalningsmetoderna och tar bort de flesta adressfälten.
Checkout sida vid sida: orderdetaljer expanderade (fält nedanför skärmkanten) jämfört med ihopfällda (fält högst upp)

show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.

Ange minimal_address: true för att endast samla in ett postnummer i stället för fullständiga gatu-, stads- och delstatsfält:
Checkout sida vid sida: fullständigt faktureringsadressformulär jämfört med endast postnummer

minimal_address: true reduces the billing address to a single postcode field.

Ange theme: "system" så att checkouten följer enhetens inställning för ljust eller mörkt läge:
Checkout sida vid sida: samma sida återgiven i ljust och mörkt läge

With theme: system, the checkout follows the device's light or dark appearance automatically.

Betalningsmetoderna beror på produkttypen. Apple Pay och Cash App Pay stöder återkommande prenumerationer med ett belopp som inte är noll. Engångsbetalningar kan använda alla betalningsmetoder som är aktiverade för ditt företag. Se Payment Methods.

Full checkout session parameter reference

Varje parameter, typ och standardvärde i guiden för Checkout Sessions.

Mobiloptimerade recept

Varje recept är en komplett begäran om en checkout-session som din backend skickar. Välj det som motsvarar din situation och ersätt produkt-ID:t med ditt eget. Node.js- och Python-klienterna konfigureras i det första receptet, och de övriga återanvänder dem.
Använd detta recept för det kortaste formuläret: betalningsmetoder högst upp, endast postnummer för adressen, inget rabattkodsfält och ett tema som följer enheten.
Se Checkout Sessions för alla tillgängliga parametrar och deras standardvärden.
Använd detta recept när checkout-sidan måste se ut som en del av appen. Det anger dina varumärkesfärger, en hörnradie och en anpassad etikett på betalningsknappen.
Profilerad mobil checkout med en anpassad mörk marinblå palett via theme_config
theme_config accepterar separata objekt för dark och light, så att färgpaletten följer enhetens utseende. Information om varje färgnyckel och typsnittsalternativet finns i Checkout Sessions.
Använd detta recept för inloggade kunder som har betalat tidigare. Skicka kundens customer_id, deras sparade payment_method_id och confirm: true för att hoppa över checkout-formuläret. Med en payment_method_id debiterar sessionen den sparade metoden direkt och returnerar ingen checkout_url, så appen har inget att öppna. Ta reda på resultatet via webhooks.
Bevilja åtkomst när din backend tar emot payment.succeeded-webhooken. Alla status som appen visar är endast UI-indikeringar.
Använd detta recept för en prenumerationsprodukt med en kostnadsfri provperiod före den första debiteringen. trial_period_days anger provperiodens längd för denna session.
Bevilja åtkomst när din backend tar emot subscription.active-webhooken, inte när det mobila SDK:t returnerar. Se Subscription Integration Guide för hela webhook-flödet.
Använd detta recept för att spara en kunds betalningsmetod för senare debiteringar, till exempel påfyllning av plånbok, pay-as-you-go eller BNPL, utan att visa en prenumerationsetikett. Kunden godkänner betalningsmetoden en gång och du debiterar varierande belopp senare.
Appar som debiterar efter användning följer detta mönster. En astrologiapp kan till exempel debitera ett förgodkänt kort för varje session i stället för enligt ett fast schema.
En betalning på begäran måste vara minst 100 i den minsta valutaenheten ($1.00 för USD). API:t avvisar ett lägre product_price med "product_price: value out of range". Om du vill godkänna utan att debitera använder du mandate_only: true enligt exemplet ovan och debiterar minst minimibeloppet senare.
Se On-Demand Subscriptions för hela debiteringsflödet, webhook-händelser och policyer för nya försök.

Prenumerationsflöden från mobilen

En mobilapp startar en prenumeration med samma flöde för checkout-sessionen som en engångsbetalning. SDK:t öppnar den hostade checkouten, kunden prenumererar och appen hanterar returen via deep link. Din backend hanterar resten av prenumerationens livscykel.

Vanliga återkommande prenumerationer

För fakturering med ett fast intervall, till exempel månadsvis eller årsvis, skapar du en checkout-session med en prenumerationsprodukt och en deep link i return_url. Din backend tar emot subscription.active när prenumerationen startar.
Apple Pay och Cash App Pay stöder återkommande prenumerationer med ett belopp som inte är noll.
Se Subscription Integration Guide för hela webhook-flödet på backend.

Prenumerationer på begäran

En prenumeration på begäran godkänner kundens betalningsmetod en gång, så att du kan debitera varierande belopp senare. Använd den för påfyllning av plånbok, pay-as-you-go och debiteringar vars belopp du inte känner till i förväg. Se receptet On-Demand Mandate för hela request body. På mobil bör du tänka på följande:
  • Ange show_on_demand_tag: false så att checkout-sidan inte visar formuleringar om prenumeration eller betalning på begäran. Kunder som sparar ett kort för påfyllningar förväntar sig inte prenumerationsvillkor.
  • När kunden har godkänt medgivandet tar din backend emot subscription.active. Spara subscription_id, eftersom alla senare debiteringar använder det.
En betalning på begäran måste vara minst 100 i den minsta valutaenheten ($1.00 för USD). API:t avvisar ett lägre belopp med "product_price: value out of range". Debitera minst minimibeloppet eller använd mandate_only: true för att godkänna utan att debitera och samla in det första beloppet senare.Försök inte göra nya debiteringar med korta intervall. Medan en tidigare debitering på samma prenumeration fortfarande behandlas misslyckas en ny debitering med "Cannot create new charge as previous payment is not successful yet". Detta händer oftast med indiska betalningsmetoder (UPI samt indiska debet- och kreditkort), där avdraget görs 48 timmar efter att debiteringen startade. Kontrollera att den tidigare debiteringen är klar innan du försöker igen.
Se On-Demand Subscriptions för debiteringsendpointen, webhook-händelser och policyer för nya försök.

Prenumeration med kostnadsfri provperiod

Om du vill erbjuda en provperiod före den första debiteringen skickar du subscription_data.trial_period_days i checkout-sessionen. Kunden godkänner en betalningsmetod vid registreringen och Dodo Payments debiterar den när provperioden slutar. Se receptet Subscription with Free Trial för hela request body.

Uppgraderingar och nedgraderingar

Din backend ändrar planer via API:t, inte via en ny checkout-session. Dodo Payments beräknar proportioneringen med det proration-läge du väljer. Om du vill låta kunderna ändra planer själva länkar du till Customer Portal.

Subscription Integration Guide

Backendkonfiguration: webhook-flöde, åtkomsttilldelning och annullering.

On-Demand Subscriptions

Medgivande, varierande debiteringar och policyer för nya försök.

Upgrade / Downgrade

Proration-lägen, planändringar och justeringar av antal platser.

Customer Portal

Självbetjäning för prenumerationshantering för dina kunder.

Minska avhopp från checkout

På en liten skärm kräver varje formulärfält mer arbete att fylla i. Inställningarna för checkout-sessionen nedan förkortar formuläret och minskar avhoppen.

Optimera formuläret

Dessa inställningar förkortar checkout-formuläret på mobil:

Förifyll kunddata

Varje fält du förifyller är ett fält som kunden slipper skriva in:
  • Nya kunder: ange customer.email och customer.name från din auth-session.
  • Återkommande kunder: ange customer.customer_id för att använda kundens lagrade uppgifter.
  • Valuta: skicka billing_currency och billing_address.country tillsammans.

Återställningsverktyg

Återställningsverktyg tar tillbaka kunder vars checkout eller förnyelse inte slutfördes:

Abandoned Cart Recovery

E-postserier för övergivna eller misslyckade checkout-flöden.

Payment Retries

Automatiska nya försök för misslyckade prenumerationsförnyelser.

Subscription Dunning

E-postmeddelanden som återställer prenumerationer med misslyckade betalningar.

Recovery Overview

Alla återställningsverktyg och intäkterna de återvinner.

Bästa praxis

  • Säkerhet: Skicka aldrig med en API-nyckel i appen. Skapa checkout-sessioner på din backend och skicka endast checkout_url till appen.
  • Behörighet: Behandla CheckoutResult.status som en UI-ledtråd. Bevilja åtkomst först efter att din backend har bekräftat betalningen.
  • Användarupplevelse: Visa ett laddningstillstånd medan din backend skapar sessionen. Behandla inte cancelled som ett fel, eftersom betalningen fortfarande kan ha genomförts.
  • Testning: Använd testläge och testkort, och kontrollera retur-URL:ens rundresa på en riktig enhet såväl som i en simulator.
  • Konvertering: Ange show_order_details: false och minimal_address: true. Tillsammans flyttar de betalningsmetoderna ovanför vecket och tar bort de flesta adressfälten.
  • Valuta: Skicka både billing_currency och billing_address.country. Om du utelämnar någon av dem kan Adaptive Currency välja faktureringsvalutan från kundens IP-adress.
  • On-demand-betalning: Ange show_on_demand_tag: false när du använder on-demand-prenumerationer enbart för att spara ett kort. Kunder som fyller på en plånbok förväntar sig inte formuleringar om prenumerationer.
  • Återställning: Aktivera Abandoned Cart Recovery i instrumentpanelen för att skicka e-post till kunder som inte slutför checkout.

Felsökning

Vanliga problem

  • Callback anländer aldrig: Schemat i returnUrl måste matcha schemat du registrerade. På Android är det manifestets dodoCallbackScheme-placeholder. På iOS är det URL-typen Info.plist. React Native- och Flutter-appar behöver båda, och i Expo ställer config-pluginen in båda.
  • Checkout återgår till webbläsaren i stället för till din app (iOS): Din app vidarebefordrar inte den inkommande URL:en. Anropa DodoCheckout.handleOpenURL(url) från .onOpenURL, scene(_:openURLContexts:) eller en React Native Linking-lyssnare.
  • PLATFORM_ERROR på Android: Den vanligaste orsaken är att schemana inte matchar. Det inträffar också när din MainActivity anger android:taskAffinity="" (standardvärdet flutter create), vilket kan göra att vissa Android OEM-versioner tappar den pågående checkouten.
  • ALREADY_IN_PROGRESS: En checkout är fortfarande öppen. Vänta tills den föregående har slutförts eller stäng den innan du startar en ny.
  • Bygget misslyckas med en olöst placeholder: Du lade till Android SDK men angav inte manifestPlaceholders["dodoCallbackScheme"].
  • Betalningen lyckades men åtkomst beviljades inte: Din app beviljar åtkomst baserat på mobilresultatet. Bevilja i stället åtkomst från payment.succeeded- eller subscription.active-webhooken.
  • Apple Pay eller Google Pay visas inte på mobilen: Kontrollera om checkout laddas i en inbäddad WebView (WKWebView eller Android WebView). Öppna den med SDK:t eller i systemets webbläsaryta: en Custom Tab på Android eller SFSafariViewController eller ASWebAuthenticationSession på iOS.

Ytterligare resurser

Contact Support

Om du har frågor eller behöver support kan du mejla support@dodopayments.com.
Senast ändrad 26 september 2026