Vad är Mjuk beskrivning?
Handlarens namn och kontaktuppgifter som visas på kortinnehavarens kontoutdrag.
En mjuk beskrivning är den anpassade text som visas på en kortinnehavares kontoutdrag för en specifik transaktion, vilken dynamiskt kan ställas in per transaktion.
Den skiljer sig från en ”hård beskrivning”, som är det statiska, juridiska företagsnamnet registrerat hos inlösaren och kopplat till Merchant ID (MID).
Den mjuka beskrivningen gör det möjligt för en handlare att ge mer sammanhang om ett köp, såsom produktnamn eller webbplats, vilket hjälper kortinnehavaren att känna igen debiteringen och minskar sannolikheten för en ”vänlig bedrägeri”-Chargeback.
Denna data skickas från handlarens betalningsgateway till inlösaren inom auktoriseringsförfrågan, vanligtvis i Data Element 43 i ISO 8583-meddelandet.
Ett vanligt format kombinerar ett igenkännbart handelsnamn med en produktidentifierare, separerade med en asterisk, till exempel `CARDFLO*ANALYTICS`. Den totala längden begränsas av kortsystemens regler, vanligtvis runt 22-25 tecken.
Inlösaren skickar sedan denna information via systemen till utfärdaren, som slutligen visar den på kortinnehavarens kontoutdrag. En ofta missförstådd nyans är att inte alla inlösare effektivt stöder dynamiska mjuka beskrivningar.
Vissa kan trunkera dem, ignorera dem helt, eller åsidosätta dem med den hårda beskrivningen, vilket undergräver en handlares ansträngningar att förhindra tvister. Detta gör det viktigt att testa beskrivningar över en uppsättning med flera inlösare.
Praktiskt exempel
Ett brittiskt SaaS-företag, ”Analytics Widgets Ltd”, säljer två produkter: ”DataMiner” och ”ReportGen”, var och en för 50 £/månad. Om de förlitar sig på sin hårda beskrivning kommer kundens kontoutdrag att visa ett generiskt ”Analytics Widgets”.
En kund som köpte ”ReportGen” kanske inte känner igen detta och lämnar in en Chargeback. Med dynamiska mjuka beskrivningar visas ett ”ReportGen”-köp som ”DataMiner*ReportGen”, medan ett ”DataMiner”-köp visas som ”DataMiner*MainTool”.
När kortinnehavaren granskar sitt kontoutdrag klargör det specifika produktnamnet omedelbart debiteringen på 50 £, vilket förhindrar ett samtal till deras bank. Detta undviker en potentiell Chargeback, vilket sparar transaktionsvärdet på 50 £ och en Chargeback-avgift på 15 £.
Beskrivningen skickas i API-anropet vid auktoriseringstillfället.
Noteringar från kortnätverken
Systemregler styr format och längd för mjuka beskrivningar. Mastercard begränsar fältet till 22 tecken, medan Visa tillåter upp till 25.
Båda systemen rekommenderar ett prefix som identifierar handlarens varumärke, följt av en asterisk och sedan en produktspecifik identifierare. American Express ger lite mer flexibilitet men uppmuntrar starkt att inkludera ett kundtjänsttelefonnummer inom beskrivningsfälten för att underlätta direktkontakt vid tvister.
Systemen kräver inte användning av dynamiska beskrivningar, men deras ramverk för tvistlösning, som Visas VCR, gynnar implicit handlare som använder tydliga beskrivningar som en bästa praxis för att förhindra tvister.
Varför det spelar roll för handlare
En effektiv strategi för mjuka beskrivningar är ett av de mest kostnadseffektiva verktygen för att minska tvistkvoterna. Genom att förhindra tvister som uppstår på grund av kundförvirring sparar handlare på kortreklamationsavgifter, undviker intäktsförluster och minskar den operativa bördan av bevisföring.
För företag med flera produktlinjer, webbplatser eller prenumerationstjänster som körs på ett enda MID är dynamiska beskrivningar avgörande för tydlighet.
Att använda en leverantör av betalningsorkestrering som Cardflo gör det möjligt för handlare att normalisera beskrivningsformat och säkerställa att de skickas korrekt till olika inlösare i deras nätverk, vilket undviker vanliga problem som trunkering eller inlösaråsidosättningar som kan upphäva beskrivningens fördel.
Vanliga frågor
Vilken är teckengränsen för en typisk mjuk beskrivning?
De flesta kortsystem och inlösare begränsar beskrivningen till mellan 20 och 25 tecken. Att överskrida denna gräns resulterar vanligtvis i att strängen trunkeras, vilket kan ta bort viktig kontaktinformation och potentiellt öka frekvensen av reklamationer på grund av bristande tydlighet.
Kan dynamiska beskrivningar användas för varje betalningstyp?
Medan de flesta moderna gateways tillåter dynamiska mjuka beskrivningar för standard e-handelstransaktioner, kan viss äldre hårdvara eller specifika högrisksbehandlingsavtal begränsa detta.
Det är lämpligt att verifiera med din inlösare om ditt MID stöder åsidosättningar per transaktion, särskilt när du hanterar flera undermärken under ett enda handlarkonto.
Vilka är de exakta teckengränserna för mjuka beskrivningar?
Gränserna fastställs av systemen och inlösarna, men standardreglerna är 22 tecken för Mastercard och 25 för Visa. Det är viktigt att notera att stadsfältet, som ibland läggs till, också har gränser, ofta runt 13 tecken.
Du bör alltid bekräfta den exakta stödda längden med din inlösande bank, eftersom vissa kan införa strängare gränser än systemen själva.
Min dynamiska mjuka beskrivning visas inte korrekt. Vad är problemet?
Detta är ett vanligt problem. Problemet ligger vanligtvis hos den inlösande banken.
Vissa inlösare stöder antingen inte dynamiska beskrivningar eller har ett system som felaktigt åsidosätter det dynamiska fältet med den statiska hårda beskrivningen kopplad till ditt MID.
För att lösa detta måste du kontakta din inlösares tekniska support för att säkerställa att ditt konto är korrekt konfigurerat för att skicka data från ISO 8583-fält DE43 till systemen.
Vilket är det bästa formatet att använda för en prenumerationstjänst?
För prenumerationer är tydlighet och konsekvens nyckeln. Ett bra format är `VARUMÄRKE*PRODUKTNAMN`.
Till exempel kan en månatlig kaffeprenumeration vara `QUICKCOFFEE*SUB`. Undvik att ändra beskrivningen för återkommande betalningar om det inte är nödvändigt, eftersom detta kan orsaka förvirring.
Att lägga till ett kundtjänstnummer är också en stark bästa praxis om teckengränserna tillåter, men detta skickas ofta i ett separat fält.
Finns det en skillnad mellan en mjuk beskrivning och en kontoutdragsbeskrivning?
Termerna används ofta omväxlande. Men ”kontoutdragsbeskrivning” är en bredare term som kan hänvisa till antingen den mjuka beskrivningen (dynamisk) eller den hårda beskrivningen (statisk).
En mjuk beskrivning är specifikt den anpassade, transaktionsnivåidentifieraren, medan en hård beskrivning är det standardiserade företagsnamnet som tillämpas på alla transaktioner på ett MID om en mjuk beskrivning inte tillhandahålls eller stöds.
Kan jag inkludera ett transaktions- eller order-ID i den mjuka beskrivningen?
Även om det tekniskt är möjligt om det ryms inom teckengränsen, är det generellt sett inte en rekommenderad praxis. Kortinnehavare kommer inte att känna igen ett internt order-ID som `VARUMÄRKE*A84XYZ-1`, vilket motverkar syftet med beskrivningen.
Målet är mänsklig läsbarhet. Det är bättre att använda ett igenkännbart produkt- eller tjänstnamn.
Det unika transaktions-ID:t skickas redan i andra datafält och är tillgängligt för utfärdaren.
See how Mjuk beskrivning plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Relaterade termer
En tvingande återföring av en kortbetalning initierad av kortinnehavarens utfärdande bank.
En reklamation som lämnats in av en verklig kortinnehavare för en transaktion de faktiskt gjorde, ofta för att de inte känner igen beskrivningen eller vill ha en återbetalning utan att kontakta handlaren.
En unik identifierare utfärdad av en inlösare som kopplar transaktioner till ett specifikt handlarkonto.
Systemdefinierad kod som identifierar grunden för ett återkrav (t.ex. Visa 10.4 för kortinnehavare ej auktoriserad, 13.1 för varor ej mottagna) som dikterar vilken bevisning som krävs för att försvara den.
Relaterade guider.
Redo att förbättra din betalningsinställning?
Berätta om ditt företag. Vi matchar dig med rätt inlösenpartners och rätt väg, vanligtvis inom en vecka.