Senast uppdaterad 29 oktober 2024.

Den 15 mars 2024 reviderades en uppsättning branschriktlinjer som sammanfattar säkerhetsåtgärder för företag som genomför kortbetalningar i Japan (Credit Card Security Guidelines Version 5.0).

I riktlinjerna för kreditkortssäkerhet fastställs att handlare som bedriver onlineförsäljning (Stripe-användare) måste aktivera 3D Secure-autentisering senast i slutet av mars 2025 i syfte att bekämpa bedrägerier.

3D Secure-autentisering (3DS) är en teknik som ger ytterligare ett autentiseringslager vid kreditkortsbetalningar och skyddar företag från ansvar vid bedrägliga kortbetalningar.

Stripes tidslinje för lansering av 3DS

Stripe kommer att kräva att 3DS används på alla tillämpliga betalningar från och med 31 mars 2025. I vissa fall kan du bestämma om 3DS ska användas eller ej.

I januari 2025 började Stripe att införa krav på 3DS på en liten andel betalningar. Därefter kommer andelen gradvis att öka och den 31 mars 2025 kommer 3DS att krävas på alla betalningar, exklusive vissa undantag. Du måste göra de nödvändiga ändringarna i din Stripe-integration senast i slutet av 2024 för att undvika misslyckade betalningar.

Om du behöver mer tid för att förbereda dig efter december 2024 kan du begära att exkluderas från lanseringen i januari, men Stripe kommer dock att kräva 3DS på alla tillämpliga betalningar från den 1 april 2025.

Även kreditkortsbetalningar på äldre API:er som inte har stöd för 3DS (Charges API och Orders API) kommer att börja kräva det, och kommer därför att misslyckas från och med april 2025. Till 30 juni 2025 kommer alla kreditkortsbetalningar på dessa API:er att misslyckas.

Tillämpliga betalningar

I vissa fall kan du bestämma om 3DS ska användas eller ej. I fall då ett undantag tillämpas och betalningar görs utan 3DS gäller inte ansvarsförskjutning för bedrägliga betalningar. Se vår dokumentation för att läsa mer om hur Stripe tillämpar undantag från 3DS.

Kontrollera din integration

Om du redan använder Stripe kan du behöva kontrollera din integration för att säkerställa att den har stöd för 3DS.

Vi föreslår att du använder Stripes testkortnummer för att se om din integration fungerar med 3DS. Läs mer om hur du testar i vår dokumentation.

Om du använder Charges API och Orders API

Varken Charges API eller Orders API har stöd för 3D Secure 2. Om ditt konto använder de här förlegade API:erna kommer betalningar med kreditkort därför att misslyckas. Vi rekommenderar starkt att du migrerar till Payment Intents API så snart som möjligt för att undvika problem.

Om du använder Payment Intents API

Du måste kontrollera att din integration kan hantera tillståndet requires_action för att uppmana kunderna att autentisera sina betalningar. Du kan behöva uppdatera din integration för att hantera kortautentisering.

Om du dessutom slutför betalningar på servern behöver du vidta ytterligare åtgärder för att visa 3DS-autentiseringsflödet hos klienten. Läs den här guiden för mer information.

Om du använder Billing med en API-version som är äldre än 2019-03-04

För att se till att de första betalningarna från kundernas abonnemang autentiseras måste du antingen uppgradera till version 2019-03-14 eller nyare av API:t, alternativt använda parametern payment_behavior enligt den här guiden.

Om du använder Stripe via en tredjepartsintegration eller en tredjepartsplattform måste du kontakta dem för att höra om de är redo.

Kommunicera med dina kunder

Var förberedd på att kunderna ställer frågor om 3DS. Se också till att ha eventuellt supportinnehåll redo där du förklarar kravet om 3DS.

Användning av Radar och Radar for Fraud Teams

Stripe Radar hjälper till att förebygga bedrägerier genom att analysera betalningsdata från över en miljon företag i hela världen, samt identifiera och blockera bedrägliga betalningar. Radar använder maskininlärning för att genomföra riskbedömningar som baseras på hundratals signaler, inbegripet korttyp, land, enhet och beteende. Stripe har tre standardinställda Radar-regler som dynamiskt begär 3DS. Genom att ange dessa regler i Dashboard kan ytterligare autentisering begäras för kunder när deras kortutfärdande företag kräver 3DS.

Med Radar for Fraud Teams kan man ange anpassade regler. Det betyder att företag kan skräddarsy sina egna, unika riskhanteringsinställningar för 3DS. 3DS-begäranden kan göras baserat på risknivåer eller specifika metadata. Detta ser till att legitima betalningar inte blockeras och minskar antalet nekade betalningar, vilket kan hjälpa till att maximera intäkterna.

Radar kan bidra till att färre konverteringar misslyckas samtidigt som det möjliggör ett riskbaserat skydd mot bedrägeri. Dessutom kan Radar användas för att genomföra den obligatoriska riskanalysen för betalningar som initieras av kunden jämfört med sparade kort.

Vanliga frågor

Omfattas fysiska kreditkortstransaktioner?

Transaktioner där ett fysiskt kort används i fysisk miljö omfattas inte.

Handlare i Japan måste vidta säkerhetsåtgärder enligt lagen om försäljning på avbetalning, men får man en straffavgift om man inte följer kraven?

Det finns ingen straffavgift, men en utredning kan inledas av Stripe eller inlösaren. De kan instruera handlaren att vidta nödvändiga säkerhetsåtgärder om handlaren inte har vidtagit lämpliga steg för att förebygga bedräglig användning och skydda kreditkortsnummer. Om de inte vidtar dessa åtgärder trots att de har blivit tillsagda kan de bli avregistrerade som handlare.

Tillkommer det några avgifter för 3DS?

I de flesta fall tillkommer inga extra avgifter för 3DS. Om ditt konto har en anpassad prisplan kan du dock bli föremål för avgifter för varje 3DS-försök.

Hur fungerar det om jag använder Stripe via en tredjepartsintegration?

Om du använder Stripe via en tredjepartsintegration eller ett insticksprogram kan du behöva göra ändringar för att uppfylla de nya 3DS-kraven. Vilka steg som krävs beror på din tredjepartsleverantörs implementering. Vi rekommenderar att du kontaktar din leverantör så snart som möjligt för att bekräfta att de är förberedda på de nya reglerna och för att få information om eventuella uppdateringar som du kanske behöver göra.

Hur kan jag testa att 3DS fungerar korrekt?

Du kan använda en test-API-nyckel tillsammans med testkort för att skapa testtransaktioner. Genom att använda testkort som kräver autentisering kan du validera 3DS-autentiseringen.

Är det obligatoriskt även om jag tar emot betalningar från kunder utanför Japan?

Konton i Japan måste följa de nya 3DS-kraven för både nationella och internationella kort. Konton utanför Japan omfattas inte av det här kravet.

Hur kan jag utlösa 3DS manuellt?

Även om det inte finns undantag för 3DS kan det vara önskvärt att skapa en ansvarsförskjutning genom att manuellt utlösa 3DS vid misstänkta bedrägerier. Du kan göra detta med hjälp av Radar-regler i Dashboard eller med hjälp av API:t.

• Stripe tillhandahåller standardinställda Radar-regler och du kan lägga till anpassade 3DS-regler med hjälp av Radar for Teams.
• När du skapar eller bekräftar ett PaymentIntent eller SetupIntent för ett API eller när du skapar en Checkout-session kan du ställa in payment_method_options[card][request_three_d_secure] till "any" eller "challenge" (autentiseringsfråga) beroende på ditt optimeringsmål för att utlösa 3DS manuellt.

Kommer autentiseringen att hamna i autentiseringsfrågeflödet eller det friktionsfria flödet?

I princip avgörs detta av den riskbedömning som kortutfärdaren gör.

• Autentiseringsfrågeflödet är en ytterligare autentisering som utförs när en transaktion bedöms ha hög risk. Normalt skickas ett engångslösenord via e-post från kortutfärdaren till kortinnehavaren som därefter anger lösenordet på betalningsskärmen.
• Om kortutfärdaren bedömer att transaktionen har låg risk kan de välja att inte kräva ytterligare autentisering. Detta kallas för ett friktionsfritt flöde.

Båda scenarierna utmynnar i en ansvarsförskjutning. Om du vill ange autentiseringsfrågeflödet i Payment Intents API ska du ställa in ‘request_three_d_secure’ till "challenge".

Vad ska jag göra om jag vill samla in kortuppgifter från kunder i förväg och fakturera dem senare?

Om din verksamhet sparar kort i förväg måste du verifiera att kunden som loggar in verkligen är kontoinnehavaren. Du måste införa strikt kontohantering och åtgärder mot otillåtna inloggningar.

Du kan implementera detta med hjälp av Setup Intents API, vilket gör att Stripe automatiskt utlöser 3DS under följande villkor, eller använda konfigureringsläget i Checkout för att utlösa 3DS som standard vid kortregistrering.

• usage: off_session (default)
• usage: on_session & payment_method_options.card.request_three_d_secure: any

Om 3DS-autentiseringen har slutförts under kortregistreringen kommer den att vara undantagen för senare transaktioner. Du bör dock bedöma bedrägeririsken för varje transaktion baserat på transaktionsbelopp, varor/tjänster, egenskaper och beteendeanalys, samt om så krävs utföra 3DS-autentisering igen. I dessa fall använder du SetupIntent igen.

Vad ska jag göra om min affärsmodell omfattar engångsbetalningar från kunder?

Börja med att verifiera att ditt befintliga betalningsflöde fungerar korrekt med 3DS-testkort.

Även om det inte krävs något ytterligare grundarbete rekommenderas att du verifierar att ditt system behandlar 3DS.

Vad ska jag göra om jag accepterar abonnemang?

Börja med att verifiera att ditt befintliga betalningsflöde fungerar korrekt med 3DS-testkort.

• Om du vill utlösa 3DS när kortuppgifterna anges ska du läsa avsnittet ”Vad ska jag göra om jag vill samla in kortuppgifter från kunder i förväg och fakturera dem senare?"
• Om du inte utlöser 3DS när kortuppgifterna anges och vill utlösa det under den första betalningen ska du ange användningen som on_session.

Om du använder Subscriptions API och inte skapar ett SetupIntent-objekt manuellt efter kortuppgifterna anges kommer ett att skapas automatiskt för dig om 3DS krävs. Du behöver hantera detta i din frontend för att tillåta användaren att slutföra 3DS-autentisering.

Om 3DS-autentisering för återkommande betalningar har slutförts vid tidpunkten för kortregistreringen eller den första betalningen kan det undantas för alla följande betalningar och du behöver då inte utföra 3DS-autentisering. Om det förekommer interaktioner med kunder relaterade till avtalsändringar eller ytterligare köp behöver du dock utföra 3DS-autentisering på nytt.