Nya Funktioner
1. Försök för prenumerationsbetalningar
Misslyckade prenumerationsförnyelsebetalningar kan nu automatiskt försökas på nytt för att återhämta intäkter, utan behov av integration. Aktivera det från Inställningar → Återhämtning, sätt ett återhämtningsfönster, och Dodo Payments försöker om förnyelsen enligt ett smart schema tills det lyckas eller fönstret stängs.
| Inställning | Beskrivning | Standard |
|---|
| Aktivera betalningsförsök | Försök automatiskt om misslyckade prenumerationsförnyelsebetalningar för att återhämta intäkter. | Av (opt-in) |
| Återhämtningsfönster (dagar) | Hur länge man ska fortsätta försöka en misslyckad betalning innan man ger upp (1–30). | 13 |
- En prenumerationsförnyelsebetalning misslyckas och prenumerationen flyttas till
on_hold.
- Om avslaget kan försöka om (ett mjukt avslag som otillräckliga medel eller ett tillfälligt nätverksfel), schemaläggs nästa försök automatiskt.
- Försök sker utanför sessionen enligt ett avlastningsschema, begränsat av ditt återhämtningsfönster.
- Vid första framgångsrika försök återgår prenumerationen till
active och nästa faktureringsdatum flyttas fram som vanligt.
Försöksschema
Försök avlastas successivt, förankrade till tidpunkten då den misslyckade fakturan skapades. Upp till 8 försök görs, så länge de ryms inom ditt återhämtningsfönster:
| Försök | Fördröjning efter föregående |
|---|
| 1 | 12 timmar |
| 2 | 24 timmar |
| 3 | 48 timmar |
| 4 | 72 timmar |
| 5 | 96 timmar |
| 6 | 120 timmar |
| 7 | 7 dagar |
| 8 | 7 dagar |
Endast mjuka avslag försöks om (t.ex. otillräckliga medel, generiskt avslag, bearbetnings- eller nätverksfel). Hårda avslag avslutar omförsökskedjan omedelbart, eftersom omförsök inte kommer att ändra resultatet.
2. Affärsprorateringsinställningar
Du kan nu ställa in standardbeteende för uppgradering och nedgradering på affärsnivå istället för att ange pro-rata-parametrar vid varje planändring. Dessa standardinställningar gäller när en kund ändrar sin plan från kundportalen, och du kan ändra dem per produktkategori.
Varje riktning (uppgradering och nedgradering) har två oberoende kontroller, plus en gemensam betalningsfelpolicy:
| Inställning | Fält | Standard (uppgradering) | Standard (nedgradering) |
|---|
| När den nya planen startar | effective_at_on_upgrade / effective_at_on_downgrade | immediately | next_billing_date |
| Hur kunden debiteras | proration_billing_mode_on_upgrade / proration_billing_mode_on_downgrade | difference_immediately | difference_immediately |
| Om kundens betalning misslyckas | on_payment_failure | apply_change | apply_change |
effective_at)
| Värde | Beteende |
|---|
immediately | Kunden övergår till den nya planen omedelbart. |
next_billing_date | Kunden förblir på sin nuvarande plan tills nästa faktureringsdatum, då byter de till den nya. |
proration_billing_mode)
| Värde | Beteende |
|---|
prorated_immediately | Debitera ett proraterat belopp nu, baserat på tiden som är kvar i den nuvarande faktureringscykeln. |
full_immediately | Debitera hela priset för den nya planen nu. |
difference_immediately | Debitera endast prisskillnaden mellan den nya planen och den nuvarande. |
do_not_bill | Debitera inget nu. Justeringar tillämpas på nästa faktura. |
on_payment_failure)
| Värde | Beteende |
|---|
prevent_change | Håll kunden kvar på sin nuvarande plan om betalningen inte går igenom. |
apply_change | Flytta kunden till den nya planen även om betalningen inte går igenom. Du kan driva in beloppet senare. |
per-request value (Change Plan API) → collection field (if set) → business field → system default
Ett värde som ställs in per förfrågan till Ändra Plan API (proration_billing_mode, effective_at, on_payment_failure) har alltid företräde framför både samlings- och företagsstandarder. De nya inställningarna ändrar bara vad som händer när inget uttryckligt värde anges — vilket är fallet för alla kundportal-ändringar av planer. customer_business_name så att fakturan återspeglar den inköpsenhet som köper.
När kunden väljer Köper som ett företag vid kassan, uppmanas de att ange både ett Företagsnamn och ett Skatte-ID-nummer.
Företagsnamnet visas på fakturan endast när alla tre villkor är uppfyllda:
- Transaktionen är B2B (
b2b = true)
- Ett
tax_id är närvarande
- Ett icke-tomt
customer_business_name har tillhandahållits
Annars används kundens personliga namn.
Samla in det vid kassan
Sätt customer_business_name direkt, och/eller aktivera allow_customer_editing_business_name för att låta kunden ange eller redigera det på kassasidan tillsammans med sitt skatte-ID:
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
customer: { email: 'buyer@acme.com' },
tax_id: 'GB123456789',
customer_business_name: 'Acme Corp Ltd',
feature_flags: {
allow_tax_id: true,
allow_customer_editing_business_name: true // let the customer enter/edit it
},
return_url: 'https://yoursite.com/return'
});
| Yta | Fält | Noteringar |
|---|
| Kassasessioner | customer_business_name, feature_flags.allow_customer_editing_business_name | Max 250 tecken; flaggan är standard till false |
| Betalningar | customer_business_name | Max 250 tecken |
| Prenumerationer | customer_business_name | Sätta eller ta bort via PATCH /subscriptions/{id} |
customer_business_name kan inte sättas utan ett tax_id. Att skicka ett företagsnamn utan ett skatte-ID avvisas. Att rensa tax_id rensar också företagsnamnet, eftersom de två är kopplade på fakturan.
Omgivande blanksteg trimmas, och värden som bara innehåller blanksteg behandlas som en explicit rensning — så lagrad data matchar alltid det som visas på fakturan.
Buggfixar & Förbättringar
- Små buggfixar och stabilitetsförbättringar över hela plattformen.
