Skip to main content

Quick Start

Få igång din mobila betalningsintegrering i fyra enkla steg

Platform Examples

Fullständiga kodexempel för Android, iOS, React Native och Flutter

Checkout Customization

Konfigurera teman, förifyllning och 14 mobilspecifika parametrar

Mobile Recipes

Konfigurationer för checkout för fem vanliga mobila scenarier – kopiera och klistra in
Dodo Payments tillhandahåller ett officiellt checkout-SDK för Android, iOS, React Native, och Flutter. Var och en kapslar in mönstret som dokumenteras nedan (öppna checkout- URL:en, fånga returen och tolka resultatet) bakom ett enda typat start(...)-anrop, med återställning av övergivna sessioner inbyggd. Använd endast en manuell WebView om inget av SDK:erna passar din stack.

Förutsättningar

Innan du integrerar Dodo Payments i din mobilapp ska du se till att du har:
  • Dodo Payments-konto: Ett aktivt merchant-konto med API-åtkomst
  • API-uppgifter: API-nyckel och webhook secret key från din dashboard
  • Mobilappsprojekt: En Android-, iOS-, React Native- eller Flutter-applikation
  • Backend-server: För säker hantering av skapandet av checkout-sessioner

Integreringsflöde

Den mobila integreringen följer en säker process i fyra steg där din backend hanterar API-anropen och mobilappen hanterar användarupplevelsen.
Deep-linken status är endast en UI-ledtråd för vad som ska visas för användaren. Ge alltid åtkomst från payment.succeeded / subscription.active-webhooken på din backend – aldrig enbart från mobilresultatet.
1

Backend: Create Checkout Session

Checkout Session API Docs

Lär dig skapa en checkout-session i din backend med Node.js, Python och mer. Se fullständiga exempel och parameterreferenser i dokumentationen för Checkout Sessions API.
Säkerhet: Checkout-sessioner måste skapas på din backend-server, aldrig i mobilappen. Detta skyddar dina API-nycklar och säkerställer korrekt validering.
2

Mobile: Get Checkout URL

Mobilappen anropar din backend för att hämta checkout-URL:en. Autentisera begäran med den inloggade användarens eget sessionstoken.
Säkerhet: Mobilappar kommunicerar endast med din backend, aldrig direkt med Dodo Payments API.
3

Mobile: Open Checkout in Browser

Öppna checkout-URL:en i en säker webbläsare i appen för betalningshantering. Eller hoppa över hela den manuella konfigurationen med det officiella checkout-SDK:t för din plattform.

Pick your mobile SDK

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

Backend: Handle Payment Completion

Hantera slutförandet av betalningen via webhooks och redirect-URL:er för att bekräfta betalningsstatus.

Välj ditt SDK

Alla mobila SDK:n exponerar samma kontrakt: ett enda start(...)-anrop öppnar Dodos hostade checkout i plattformens inbyggda webbläsaryta och returnerar en typad CheckoutResult vars status är succeeded, failed, cancelled, pending eller expired. Inget av dem 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 Chrome 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 cores. Kräver React Native 0.76+.

Flutter

dodopayments_checkout, en Pigeon-kanal över båda native cores. Kräver Flutter 3.44+.
status som returneras är en UI-ledtråd, inte ett bevis på betalning. Bekräfta varje betalning från din backend via payment.succeeded / subscription.active- webhooken, eller genom att hämta betalningen med din secret key.

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.
Föredrar du att bygga det själv? Öppna checkout_url i plattformens system- webbläsare (Android Custom Tabs / iOS SFSafariViewController) och fånga navigeringen till din return_url. Läs sedan status och payment_id som query- parametrar. SDK:erna ovan gör exakt detta åt dig.
Öppna inte checkout i en inbäddad WebView (WKWebView / Android WebView). Detta är det vanligaste problemet vid mobil integrering: en inbäddad WebView inaktiverar Apple Pay och Google Pay och kan även bryta 3-D Secure-utmaningar och automatisk ifyllning av sparade kort – kunderna får då färre betalningsalternativ och fler misslyckanden. Använd alltid SDK:t eller öppna checkout_url i systemwebbläsaren (Custom Tabs / SFSafariViewController). Den inbyggda webbläsarytan är exakt anledningen till att Apple Pay och Google Pay fortsätter att fungera.

Anpassa utseendet

Alla SDK:n accepterar en valfri customization-parameter på start(...) / CheckoutParams som styr den inbyggda webbläsarytans utseende och beteende – verktygsfält, knappar och presentation. Detta är separat från checkout-sidans eget tema, som konfigureras server-side via customization.theme_config i checkout-sessionen. Alternativen är grupperade per plattform eftersom Androids Custom Tab och iOS:s SFSafariViewController exponerar olika inbyggda kontroller. Alla fält är valfria; om customization utelämnas helt används plattformens standardutseende.
Color
Bakgrundsfärg för verktygsfältet.
Color
Färg på navigeringsfältet.
Color
Avdelarfärg ovanför navigeringsfältet.
'default' | 'back'
default visar systemets “X”-ikon; back ritar 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 överflödesmenyn.
boolean
Visar “Ladda ned sidan” i överflödesmenyn.
'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'
pageSheet visas som ett kort som kan svepas bort; fullScreen täcker hela skärmen.
boolean
Låter verktygsfältet fällas ihop vid rullning. Visas endast när presentationStyle är fullScreenpageSheet håller fälten fast oavsett denna inställning.
'system' | 'light' | 'dark'
Tvingar fram ljust eller mörkt utseende oavsett enhetens systeminställning.

Anpassa checkout-sidan

Avsnittet Anpassa utseendet ovan styr den inbyggda webbläsarytan – verktygsfält, knappar och färgschema. Själva checkout-sidan – vilka fält som visas, temat och vilka betalningsmetoder som visas – konfigureras server-side när du skapar checkout-sessionen. Dessa parametrar har störst inverkan på mobil konvertering. Parametrarna nedan finns på tre olika platser i begäran om checkout-sessionen – kolumnen Var den ska placeras visar vilket objekt varje parameter hör till. Det vanligaste misstaget är att placera en parameter i fel objekt; då ignoreras den utan meddelande.
Skicka alltid billing_currency och billing_address.country tillsammans. Om någon av dem utelämnas kan Adaptive Currency i tysthet ändra faktureringsvalutan baserat på kundens IP-adress. En merchant såg en prenumeration i USD byta till EUR när kunden reste till Europa – eftersom faktureringslandet inte hade angetts uttryckligen.
Den största enskilda konverteringsökningen på mobil: ange show_order_details: false och minimal_address: true. Att flytta upp betalningsmetoderna och minska antalet formulärfält är de två förändringar som ger störst effekt.
Checkout sida vid sida: orderdetaljer expanderade (fält nedanför skärmens synliga del) jämfört med hopfä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 checkout 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.

Tillgängligheten för betalningsmetoder varierar beroende på produkttyp. Apple Pay och Cash App stöds för återkommande prenumerationer med ett belopp som inte är noll. För engångsbetalningar är alla aktiverade metoder tillgängliga.

Full checkout session parameter reference

Se alla tillgängliga parametrar, typer och standardvärden i guiden för Checkout Sessions.

Mobiloptimerade recept

Varje recept nedan är en komplett request body för en checkout-session. Kopiera det som matchar ditt scenario, byt ut mot ditt produkt-ID och skicka det till din backends endpoint för att skapa sessioner.
Använd detta när du vill ha ett så kort formulär som möjligt: betalningsmetoderna högst upp, endast postnummer krävs för adressen, inget rabattfält och temat matchar enheten.
Se Checkout Sessions för alla tillgängliga parametrar och deras standardvärden.
Använd detta när checkout-sidan ska kännas som en del av appen. Ange dina varumärkesfärger, ett anpassat typsnitt och en lokaliserad etikett på betalningsknappen.
Branded mobile checkout with a custom dark navy palette applied via theme_config
theme_config accepterar separata dark- och light-objekt så att paletten anpassas efter enhetens aktuella utseende. Se Checkout Sessions för en fullständig referens över färgnycklar.
Använd detta för inloggade användare som har betalat tidigare. Kombinera ett kund-ID, kundens sparade betalningsmetod och confirm: true för att hoppa över checkout-formuläret helt.
status i deep-link-returen är endast en UI-ledtråd. Bekräfta åtkomst genom att lyssna efter payment.succeeded-webhooken på din backend.
Använd detta för prenumerationsprodukter som erbjuder en kostnadsfri provperiod före den första faktureringscykeln.
Ge åtkomst till funktionen när din backend tar emot subscription.active-webhooken – inte när mobil-SDK:t returnerar. Se Subscription Integration Guide för det fullständiga webhook-flödet.
Använd detta för att tokenisera en kunds kort för senare debiteringar (påfyllning av wallet, pay-as-you-go och BNPL) utan att visa etiketten “subscription”. Kunden auktoriserar sin betalningsmetod en gång; därefter debiterar du varierande belopp vid behov.
Detta mönster används av appar som debiterar baserat på användning – till exempel en astrologiapp som debiterar per session från ett förauktoriserat kort i stället för enligt ett fast schema.
On-demand-debiteringar kräver minst 1 USD (100 cent). Belopp under 1 USD avvisas med "value out of range". För en auktorisering med beloppet noll använder du mandate_only: true enligt exemplet ovan och debiterar sedan minst 1 USD i efterföljande anrop.
Se On-Demand Subscriptions för det fullständiga debiteringsflödet, webhook-händelser och retry-policyer.

Prenumerationsflöden från mobil

Prenumerationer skapas genom samma checkout-sessionflöde som används för engångsbetalningar – mobil-SDK:t öppnar den hostade checkouten, kunden prenumererar och appen hanterar deep-link-returen. Prenumerationens livscykel hanteras därefter helt på backend.

Vanliga återkommande prenumerationer

För fakturering med fasta intervall (månadsvis eller årsvis) skapar du en checkout-session med en prenumerationsprodukt och en deep-link return_url. Din backend tar emot subscription.active när prenumerationen har bekräftats.
Apple Pay och Cash App stöds för återkommande prenumerationer med ett belopp som inte är noll.
Det fullständiga webhook-flödet på backend finns i Subscription Integration Guide.

On-demand-prenumerationer

On-demand-prenumerationer låter dig auktorisera en kunds betalningsmetod en gång och debitera varierande belopp senare – perfekt för påfyllning av wallet, pay-as-you-go och alla situationer där debiteringsbeloppet inte är känt i förväg. Se receptet On-Demand Mandate ovan för hela request body. Viktiga mobila överväganden:
  • Ange show_on_demand_tag: false så att checkout-sidan inte visar formuleringar om “subscription” eller “on-demand”. Vid användningsfall för korttokenisering förväntar sig kunderna inte prenumerationsterminologi.
  • När mandatet har auktoriserats tar din backend emot subscription.active. Spara subscription_id – du kommer att använda det för alla framtida debiteringar.
Minsta debitering är 1 USD (100 cent). On-demand-debiteringar under 1 USD avvisas med "value out of range". Debitera antingen minst 1 USD eller använd mandate_only: true för att auktorisera utan debitering och ta ut det första riktiga beloppet senare.
Undvik upprepade snabba försök. Om en tidigare debitering fortfarande behandlas misslyckas en ny debitering på samma prenumeration med "Cannot create new charge as previous payment is not successful yet". Detta är särskilt vanligt med indiska betalningsmetoder (UPI och indiska betal- och kreditkort), där RBI:s mandatregler kan hålla en transaktion i behandlingsläge i upp till 48 timmar. Lägg till en cooldown-kontroll i debiteringslogiken innan du försöker igen.
Se On-Demand Subscriptions för den fullständiga debiterings-endpointen, webhook-händelser och retry-policyer.

Prenumeration med kostnadsfri provperiod

Skicka subscription_data.trial_period_days i checkout-sessionen för att erbjuda en provperiod före den första faktureringscykeln. Kunden auktoriserar sin betalningsmetod när provperioden startar; den första debiteringen sker automatiskt när provperioden löper ut. Se receptet Subscription with Free Trial ovan för hela request body.

Uppgraderingar och nedgraderingar

Planändringar görs via API på din backend, inte genom en ny checkout-session. Dodo Payments beräknar pro rata automatiskt. Om du vill ge kunderna ett självbetjäningsalternativ kan du bädda in eller länka till Customer Portal.

Subscription Integration Guide

Full backend setup: webhook flow, access provisioning, cancellation

On-Demand Subscriptions

Mandate authorization, variable charges, and retry policies

Upgrade / Downgrade

Proration strategies, plan changes, and seat adjustments

Customer Portal

Self-service subscription management for your customers

Minska avhopp i checkout

Mobila checkout-flöden har fler avhopp än webben – mindre skärmar, fler distraktioner och längre formulär bidrar alla. De snabbaste förbättringarna kommer från själva konfigurationen av checkout-sessionen.

Optimera formuläret

Förifyll kunduppgifter

Varje fält som kunden slipper skriva in är en anledning mindre att avbryta:
  • Nya kunder – ange customer.email och customer.name från din auth-session.
  • Återkommande kunder – ange customer.customer_id för att automatiskt förifylla alla sparade uppgifter.
  • Valuta – skicka alltid billing_currency och billing_address.country tillsammans.

Återställningsverktyg

Abandoned Cart Recovery

Automated email sequences for incomplete checkouts

Payment Retries

Smart retry logic for failed subscription renewals

Subscription Dunning

Re-engagement emails for lapsed subscriptions

Recovery Overview

All recovery tools and their combined revenue impact
Testa e-postmeddelanden om övergivna kundvagnar innan du aktiverar dem. Skapa en checkout-session i live mode och ange ogiltiga kortuppgifter. Den misslyckade betalningen utlöser återställningsflödet via e-post, så att du kan förhandsgranska exakt vad dina kunder får.

Bästa praxis

  • Säkerhet: Skicka aldrig en API-nyckel i appen. Skapa checkout-sessioner på din backend och skicka endast den resulterande checkout_url till klienten.
  • Auktoritet: Behandla CheckoutResult.status som en UI-ledtråd. Ge åtkomst först när din backend har bekräftat betalningen.
  • Användarupplevelse: Visa ett laddningstillstånd medan din backend skapar sessionen och hantera cancelled som ett normalt resultat, inte som ett fel.
  • Testning: Använd test mode och testkort, och verifiera rundresan via return-URL på både en riktig enhet och en simulator.
  • Konvertering: Ange show_order_details: false och minimal_address: true för bästa slutförandegrad i mobil checkout. Att flytta upp betalningsmetoderna och minska antalet formulärfält är de två förändringar som ger störst effekt.
  • Valuta: Skicka alltid både billing_currency och billing_address.country uttryckligen – om någon saknas kan Adaptive Currency ändra faktureringsvalutan baserat på kundens IP-adress.
  • On-demand-fakturering: Ange show_on_demand_tag: false när du använder on-demand-prenumerationer för korttokenisering. Kunder som använder ett flöde för påfyllning av wallet förväntar sig inte att se formuleringar om “subscription”.
  • Återställning: Aktivera återställning av övergivna kundvagnar i din Dodo Payments-dashboard för att automatiskt återengagera kunder som inte slutför checkout.

Felsökning

Vanliga problem

  • Callback kommer aldrig fram: Schemat i returnUrl måste matcha det du registrerade. På Android är det manifestets dodoCallbackScheme-platshållare; på iOS och React Native är det Info.plist URL type.
  • Checkout återgår till webbläsaren i stället för appen (iOS): Du har inte vidarebefordrat den inkommande URL:en. Anropa DodoCheckout.handleOpenURL(url) från .onOpenURL, scene(_:openURLContexts:) eller en React Native Linking-lyssnare.
  • PLATFORM_ERROR på Android: Oftast beror det på att schemat inte matchar. Det kan även inträffa om din MainActivity anger android:taskAffinity="" (standardvärdet flutter create), vilket gör att vissa OEM-versioner tappar den pågående checkouten.
  • ALREADY_IN_PROGRESS: En checkout är fortfarande öppen. Vänta på eller stäng den föregående innan du startar en ny.
  • Bygget misslyckas med en olöst platshållare: Du lade till Android SDK men ställde aldrig in manifestPlaceholders["dodoCallbackScheme"].
  • Betalningen lyckades men åtkomst beviljades inte: Förväntat om du baserar dig på mobilresultatet. Ge i stället åtkomst från payment.succeeded / subscription.active-webhooken.
  • Apple Pay / Google Pay visas inte på mobil: Checkout laddas i en inbäddad WebView (WKWebView / Android WebView), vilket döljer wallets och kan bryta 3-D Secure. Öppna den i stället med SDK:t eller i systemwebbläsaren (Custom Tabs / SFSafariViewController).

Ytterligare resurser

Om du har frågor eller behöver support kan du kontakta support@dodopayments.com.
Senast ändrad 21 augusti 2026