> ## Documentation Index > Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt > Use this file to discover all available pages before exploring further. # Manuell retry av betalning > Försök genomföra en misslyckad betalning för en prenumerationsförnyelse igen på begäran från kontrollpanelen eller API:et, i stället för att vänta på nästa automatiska försök. Med Manual Retry görs ett nytt försök med en misslyckad betalning för en **förnyelse** av en prenumeration så snart du begär det, från betalningens detaljsida eller via API:et. Betalningen debiteras från den betalningsmetod som sparats för prenumerationen och körs oberoende av schemat för automatiska [Payment Retries](/features/recovery/payment-retries). ## Vad är Manual Retry? När en betalning för en förnyelse misslyckas flyttas prenumerationen till `on_hold` och [Payment Retries](/features/recovery/payment-retries) försöker genomföra debiteringen igen enligt ett back-off-schema. Ibland vet du att betalningen kommer att gå igenom nu: kunden har bekräftat att hen har fyllt på sitt konto, eller så har ditt supportteam kontakt med kunden. Med Manual Retry kan du skicka ett försök direkt i stället för att vänta i timmar eller dagar på nästa schemalagda försök. * **Endast betalningar för förnyelser**: Manual Retry gäller prenumerationsfakturor för förnyelser medan prenumerationen är `on_hold`. Första betalningar, engångsbetalningar, debiteringar vid planändringar och debiteringar på begäran kan inte användas. * **Ingen åtgärd från kunden**: Debiteringen görs via den betalningsmetod som redan sparats för prenumerationen. * **Oberoende av automatiska försök**: En manuell retry förbrukar inte ett försök från det automatiska schemat, flyttar inte nästa schemalagda försök och fungerar även när Payment Retries är avstängt. * **Försöker med fakturan, inte betalningen**: En misslyckad betalning är endast utgångspunkten. Dodo Payments letar upp den öppna förnyelsefakturan bakom betalningen och debiterar skulden, så det spelar ingen roll vilken misslyckad betalning på fakturan du försöker igen från. ## Försöka igen från kontrollpanelen Gå till **Transactions → Payments** och klicka på den misslyckade betalningen för förnyelsen för att öppna sidan **Transaction details**. Klicka på **Retry Payment Manually** i det övre högra hörnet. Knappen är endast tillgänglig medan betalningen är [berättigad](#eligibility). En ny betalning skapas för försöket och visas i **Activity Log**. Om debiteringen lyckas återgår prenumerationen till `active` och nästa faktureringsdatum flyttas fram som vanligt. Om betalningsprocessorn ännu inte har slutfört debiteringen visas betalningen som pågående tills webhooken `payment.succeeded` eller `payment.failed` rapporterar resultatet. Sidan med transaktionsinformation för en misslyckad betalning som visar felkoden och felmeddelandet, en Activity Log och en Retry Payment Manually-knapp ## Behörighet En manuell retry skickas endast när alla kontroller nedan godkänns. Kolumnen **Reason code** visar vad API:et returnerar: i `reason` på `GET /payments/{payment_id}/retry` och som felet `code` på `POST /payments/{payment_id}/retry`. | Kontroll | Krav | Reason code | | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Betalningstyp | En betalning för en **förnyelse** av en prenumeration vars faktura fortfarande är öppen. Betalningar utan faktura, första betalningar, engångsbetalningar, debiteringar vid planändringar och debiteringar på begäran kan inte göras om. | `PAYMENT_NOT_RETRYABLE` | | Prenumerationsstatus | `on_hold` | `SUBSCRIPTION_INACTIVE` | | Schemalagd uppsägning | Prenumerationen är inte schemalagd att avslutas vid nästa faktureringsdatum. | `CHARGE_NOT_ALLOWED_FOR_SCHEDULED_CANCELLATION` | | Sparad betalningsmetod | Prenumerationen har en sparad betalningsmetod som kan debiteras. | `SUBSCRIPTION_HAS_NO_PAYMENT_METHOD` | | Senaste misslyckandet | Det senaste misslyckandet är ett **mjukt avslag**. Ett hårt avslag eller ett misslyckande utan klassificerad felkod kan inte göras om. | `MANUAL_RETRY_HARD_DECLINE` | | Inget pågående | Ingen betalning på fakturan är `processing` eller saknar registrerad status. Det här gäller ett manuellt eller automatiskt försök som just skickats men ännu inte rapporterats. Vänta först på resultatet. | `MANUAL_RETRY_IN_FLIGHT` | | Senaste betalningen misslyckades | Den senaste betalningen på fakturan har statusen `failed`. En senaste betalning i något annat tillstånd än `failed`, till exempel `requires_customer_action`, `requires_payment_method` eller `cancelled`, blockerar försöket även när inget pågår. | `PREVIOUS_PAYMENT_PENDING` | | Inte redan betald | Ingen betalning på fakturan har lyckats. | `MANUAL_RETRY_ALREADY_PAID` | | Retry-gräns | Färre än 3 manuella försök har skickats för fakturan och cooldown-perioden har löpt ut. Se [Retry Limits](#retry-limits). | `MANUAL_RETRY_LIMIT_REACHED` | | Kund | Kunden finns inte på din [blocklist](/features/customer-blocklist). | `PAYMENT_NOT_RETRYABLE` | | Betalningsanslutning | För prenumerationer med [BYOP](/features/byop) är anslutningen aktiverad. | `BYOP_CONNECTOR_DISABLED` | | Live-läge | I live-läge har ditt företag aktiverat livebetalningar. | `MERCHANT_NOT_LIVE` | Manual Retry är snävare än automatiska försök på en punkt: prenumerationen måste vara `on_hold`. Automatiska försök fortsätter för andra statusar som inte är aktiva; se [Subscription Status Transitions](/features/recovery/payment-retries#subscription-status-transitions). Att försöka igen med ett hårt avslag mot samma kort kan inte lyckas, och upprepade avslag försämrar din auktoriseringsgrad. När orsaken är `MANUAL_RETRY_HARD_DECLINE` ska du i stället be kunden uppdatera sin betalningsmetod. [Subscription Dunning](/features/recovery/subscription-dunning) gör detta automatiskt. ## Retry-gränser Varje förnyelsefaktura tillåter **3** manuella försök, med en cooldown-period mellan dem: | Manuell retry | Tillgänglig | | ------------- | ---------------------------------- | | 1 | Så snart betalningen är berättigad | | 2 | 1 timme efter det första | | 3 | 3 timmar efter det andra | Gränserna gäller både i testläge och live-läge. När en retry nekas av den här orsaken returnerar API:et `MANUAL_RETRY_LIMIT_REACHED` (HTTP `429`). Felmeddelandet innehåller endast `code` och `message`. Om du vill veta när nästa retry blir tillgänglig kan du [kontrollera retry-statusen](#check-whether-a-payment-can-be-retried) och läsa `retry_available_at`. Den är `null` när alla tre har förbrukats. Automatiska försök räknas inte mot den här gränsen, och manuella försök räknas inte mot det automatiska schemats 8 försök. ## Manuella kontra automatiska försök | | Manual Retry | Payment Retries | | ---------------------------------------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | **Utlösare** | Du, från kontrollpanelen eller API:et | Dodo Payments, enligt ett back-off-schema | | **Tidpunkt** | Omedelbart | 12 timmar efter misslyckandet och därefter med allt längre intervall | | **Försök** | 3 per faktura, med 1 timmes och sedan 3 timmars cooldown | Upp till 8 per faktura inom ditt återställningsfönster | | **Payment Retries måste vara aktiverat** | Nej | Ja | | **Påverkan på det andra** | Ingen. Ett manuellt misslyckande schemalägger eller flyttar inte ett automatiskt försök. | Ingen. Den automatiska kedjan fortsätter oavsett manuella försök. | | **Analys** | Räknas i mätvärdet **Payment retries** på fliken Recovery | Räknas i samma mätvärde | ## Försöka igen via API:et Kontrollera behörigheten först och skicka sedan retry-försöket. Båda endpoints tar ID:t för en misslyckad betalning. ### Kontrollera om en betalning kan göras om `GET /payments/{payment_id}/retry` misslyckas aldrig för en betalning som inte är berättigad. I stället returneras `can_retry: false` med koden `reason`, så att kontrollpanelen eller dina supportverktyg kan visa samma status som Dodo Payments-kontrollpanelen. Detta kräver rollen **Viewer**. ```typescript Node.js theme={null} import DodoPayments from 'dodopayments'; const client = new DodoPayments({ bearerToken: process.env.DODO_PAYMENTS_API_KEY, }); const state = await client.payments.retrieveRetryState('pay_0NmDtkE0iRvmeTcT6t0ol'); if (state.can_retry) { console.log(`Retry available. ${state.sends_used}/${state.sends_allowed} used.`); } else { console.log(`Cannot retry: ${state.reason}. Next window: ${state.retry_available_at}`); } ``` ```python Python theme={null} import os from dodopayments import DodoPayments client = DodoPayments(bearer_token=os.environ["DODO_PAYMENTS_API_KEY"]) state = client.payments.retrieve_retry_state("pay_0NmDtkE0iRvmeTcT6t0ol") if state.can_retry: print(f"Retry available. {state.sends_used}/{state.sends_allowed} used.") else: print(f"Cannot retry: {state.reason}. Next window: {state.retry_available_at}") ``` ```bash cURL theme={null} curl https://live.dodopayments.com/payments/pay_0NmDtkE0iRvmeTcT6t0ol/retry \ -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" ``` ```json Response theme={null} { "can_retry": false, "reason": "MANUAL_RETRY_LIMIT_REACHED", "sends_used": 1, "sends_allowed": 3, "retry_available_at": "2026-08-26T16:51:00Z" } ``` | Fält | Beskrivning | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | `can_retry` | `true` när en retry skulle skickas direkt. | | `reason` | Koden som retry-försöket skulle misslyckas med. `null` när `can_retry` är `true`. | | `sends_used` | Manuella försök som redan skickats för den här fakturan. | | `sends_allowed` | Alltid `3`. | | `retry_available_at` | När nästa manuella retry blir tillgänglig. `null` när inget försök återstår eller när avslaget inte beror på cooldown-perioden. | ### Skicka en manuell retry `POST /payments/{payment_id}/retry` skapar en ny betalning och debiterar den sparade betalningsmetoden. Detta kräver rollen **Editor**. ```typescript Node.js theme={null} const retry = await client.payments.retry('pay_0NmDtkE0iRvmeTcT6t0ol'); console.log(retry.payment_id, retry.status); ``` ```python Python theme={null} retry = client.payments.retry("pay_0NmDtkE0iRvmeTcT6t0ol") print(retry.payment_id, retry.status) ``` ```bash cURL theme={null} curl -X POST https://live.dodopayments.com/payments/pay_0NmDtkE0iRvmeTcT6t0ol/retry \ -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" ``` ```json Response theme={null} { "payment_id": "pay_2IjeQm4hqU6RA4Z4kwDee", "invoice_id": "inv_9Kp2mQ7vRt4LxYw3", "status": "processing", "retry_attempt": 1, "is_manual_retry": true, "sends_used": 1, "sends_allowed": 3, "retry_available_at": "2026-08-26T16:51:00Z" } ``` | Fält | Beskrivning | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `payment_id` | Den nya betalning som skapats för det här försöket. | | `invoice_id` | Förnyelsefakturan som debiterades. | | `status` | Resultatet av debiteringen. `processing` betyder att processorn ännu inte har slutfört den. `null` betyder att inget resultat registrerades innan svaret returnerades. I båda fallen rapporterar betalningswebhooks det slutliga resultatet. | | `retry_attempt` | Det här försökets position bland de manuella försöken på fakturan, med början på `1`. | | `is_manual_retry` | Alltid `true` på denna endpoint. | | `sends_used`, `sends_allowed`, `retry_available_at` | Status för retry-gränsen efter detta försök. `retry_available_at` gäller endast cooldown-klockan. Den anges även när debiteringen lyckas; i så fall är fakturan betald och ingen ytterligare retry blir tillgänglig. | ### Felsvar | HTTP-status | Koder | Åtgärd | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `404` | `NOT_FOUND` | Betalningen tillhör inte ditt företag. | | `409` | `MANUAL_RETRY_IN_FLIGHT`, `PREVIOUS_PAYMENT_PENDING`, `CHARGE_NOT_ALLOWED_FOR_SCHEDULED_CANCELLATION` | Tillfälligt fel, eller så måste något annat ändras först. Vänta tills den pågående eller väntande betalningen når ett slutligt tillstånd, eller ta bort den schemalagda uppsägningen. | | `422` | `PAYMENT_NOT_RETRYABLE`, `SUBSCRIPTION_INACTIVE`, `SUBSCRIPTION_HAS_NO_PAYMENT_METHOD`, `MANUAL_RETRY_HARD_DECLINE`, `MANUAL_RETRY_ALREADY_PAID`, `BYOP_CONNECTOR_DISABLED`, `MERCHANT_NOT_LIVE` | Den här betalningen kan inte göras om. Upprepa inte anropet. | | `429` | `MANUAL_RETRY_LIMIT_REACHED` | [Kontrollera retry-statusen](#check-whether-a-payment-can-be-retried) och vänta tills `retry_available_at`, eller sluta när alla tre försök har förbrukats. | Alla koder beskrivs i referensen [Error Codes](/api-reference/error-codes). ## Webhooks En manuell retry skapar en vanlig betalning, så samma webhooks utlöses som vid alla förnyelseförsök: | Händelse | Utlöses när | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `payment.succeeded` | Retry-försöket debiterades. `subscription.active` följer när prenumerationen återaktiveras. | | `payment.failed` | Retry-försöket nekades. Prenumerationen förblir `on_hold`, och ingen automatisk retry schemaläggs efter ett manuellt misslyckande. | | `payment.processing` | Processorn har godkänt debiteringen men ännu inte slutfört den. | På betalningsobjektet i dessa händelser är `retry_attempt` `1` eller högre och `subscription_id` är angiven, precis som vid en automatisk retry. Spara `payment_id` från retry-svaret om du behöver skilja ett manuellt försök från ett schemalagt. Fullständiga payload-scheman för betalningshändelser. ## Relaterat Det automatiska back-off-schemat som körs parallellt med manuella försök. Skicka e-post till kunden och be hen uppdatera sin betalningsmetod efter ett hårt avslag. Läs avslagskoderna och avgör när det är värt att försöka igen. Varje `MANUAL_RETRY_*`-kod, dess utlösare och meddelande.