Sandlådemiljö
Cardflos sandlådemiljö gör det möjligt för utvecklare att integrera och testa betalningslösningar utan att påverka live-transaktioner. Detta isolerade utrymme speglar vår produktionsmiljö, vilket möjliggör grundlig testning av alla Cardflo-funktioner, från betalningshantering till webhooks och API-interaktioner, vilket säkerställer en smidig övergång till live-drift.
- Kategori
- Utvecklare
- Funktioner
- 10
- Tillgänglig på
- Alla planer
Översikten
En sandlådemiljö fungerar som en icke-produktionsinstans av en betalningsgateway eller orkestreringsplattform, vilket gör det möjligt för utvecklare att modellera hela transaktionslivscykeln utan att flytta riktiga medel. Den fungerar som en replika av live-API:et, inklusive komponenter för auktorisering, fångst och avräkning.
Inom denna isolerade container kan tekniska team verifiera sin integrationslogik, förfrågningsstrukturer och autentiseringshuvuden mot strikta valideringsregler. Genom att använda testuppgifter och simulerade kortidentifieringsnummer (BIN) kan handlare utvärdera hur deras backend reagerar på olika svar, såsom framgångsrika betalningar, mjuka avvisningar eller 3DS-autentiseringsprompter.
Sandlådan sitter mellan handlarapplikationen och den simulerade förvärvaren, vilket ger ett säkert utrymme för att säkerställa att koden hanterar gränsfall, såsom otillräckliga medel eller utgångna kort, innan den flyttas till en live-produktionsmiljö där fel kan leda till förlust av intäkter eller ökade chargeback-kvoter.
Så fungerar det
Generering och autentisering av uppgifter
Utvecklare erhåller en specifik uppsättning API-nycklar eller Bearer-tokens avsedda för testmiljön. Dessa uppgifter dirigerar förfrågningar till en mock-processor snarare än de live-betalningssystemen.
Detta säkerställer att inget handlaridentifikationsnummer (MID) debiteras för behandlingsavgifter och ingen riktig kortinnehavardata kommer in i produktionssystemen.
Simulerad transaktionshantering
Handlaren skickar en betalningsförfrågan med fördefinierade testkortnummer som utlöser specifika resultat. Till exempel kan användning av ett BIN simulera en framgångsrik auktorisering, medan ett annat utlöser en CVV-matchningsfel eller en hård avvisning.
Sandlådan returnerar en identisk JSON-svarsstruktur till live-API:et för att säkerställa kompatibilitet.
Webhook-händelsemeddelande
När en transaktionsstatus ändras i sandlådan genererar systemet asynkrona webhooks. Handlarservern tar emot dessa meddelanden vid en angiven slutpunkt för att verifiera att deras system korrekt uppdaterar den interna databasen.
Detta steg är avgörande för att testa automatisk orderuppfyllelse eller prenumerationshanteringslogik i realtid.
Tillståndsändring och avräkning
Användare kan manuellt eller programmatiskt övergå transaktionens tillstånd från auktoriserad till avräknad eller återbetald inom testpanelen. Detta möjliggör verifiering av efterköpsarbetsflöden, inklusive hantering av hämtningsförfrågningar eller partiella återbetalningar, vilket säkerställer att handlarens användargränssnitt återspeglar det korrekta finansiella tillståndet.
Varför det spelar roll
Riskreducering under driftsättning
Att implementera nya betalningsflöden direkt i produktion skapar hög operativ risk. Genom att använda en sandlåda kan utvecklare identifiera logiska fel eller felaktigt formulerade API-förfrågningar som annars skulle leda till misslyckade utcheckningar.
Denna isolering skyddar integriteten hos det live-handlaridentifikationsnumret och förhindrar oavsiktliga utlösare av anti-bedrägerifilter som kan uppstå under aggressiv testning av ny kort-närvarande eller kort-inte-närvarande integrationslogik.
Validering av komplex logik
Moderna betalningar involverar ofta flerstegsprocesser som Stark Kundautentisering (SCA) eller återkommande fakturering. En sandlåda möjliggör rigorös testning av kortinnehavarinitierade och handlarinitierade transaktioner utan den finansiella kostnaden för riktiga transaktioner.
Den säkerställer att systemet korrekt tolkar olika avvisningskoder och svarsmeddelanden från utfärdare, vilket möjliggör förfining av dunning-logik och återförsöksstrategier för att optimera eventuella konverteringsgrader.
Användningsfall
Initial API-integration
Nya handlare använder sandlådan för att mappa sina interna orderhanteringssystem till betalningsgatewayens API-slutpunkter. Detta bekräftar att datafält som valutakoder och handlarkategorikoder är korrekt formaterade för auktorisering.
Verifiering av återkommande fakturering
Prenumerationsbaserade företag testar sina dunning-sekvenser genom att simulera kortutgång eller otillräckliga medel. Detta säkerställer att systemet korrekt försöker återförsök och skickar lämpliga meddelanden till kunden innan tjänsten avbryts.
Felsökning av Webhook-slutpunkt
Utvecklare använder testmiljön för att verifiera att deras brandväggs- och serverkonfigurationer tillåter inkommande webhook-meddelanden. Detta förhindrar problem där order förblir 'väntande' trots framgångsrik auktorisering på förvärvarnivå.
Testning av alternativa betalningsmetoder
Innan lokala betalningsmetoder aktiveras kan handlare simulera de omdirigeringsflöden som krävs för APM:er. Detta säkerställer att användarupplevelsen förblir konsekvent när kunden skickas till en tredjepartsplånbok eller bankportal.
I siffror
Typiska effektivitetsvinster som observerats av tekniska team när de använder en omfattande sandlåda jämfört med manuell dokumentationsgranskning och direkt produktionstestning.
Uppskattat intervall för minskning av buggar efter driftsättning relaterade till betalningslogik när rigorös sandlådetestning implementeras som en del av CI/CD-pipelinen.
Branschstandard svarstid för mock API-slutpunkter, vilket möjliggör snabb iteration under programvaruutvecklingslivscykeln.
Relaterade termer
Talk to our team about a live rollout on your acquiring stack.
Vad du får med Sandlådemiljö
- Verifiera API-förfrågnings- och svarsstrukturer mot officiell dokumentation i en säker miljö.
- Simulera specifika avvisningsorsaker för auktorisering för att validera felhantering och kundmeddelanden.
- Utlös och ta emot webhook-meddelanden för statusuppdateringar som fångst, återbetalning och tvist.
- Testa 3-D Secure-autentiseringsflöden för att säkerställa efterlevnad av PSD2- och SCA-kraven.
- Validera hanteringen av nätverkstokens och kontouppdateringsmeddelanden utan verklig data.
- Utför belastningstestning på integrationslogik innan övergång till produktionsmiljöer med högre volym.
- Konfigurera flera handlarprofiler för att testa valutaomvandling och inhemsk kontra internationell bearbetning.
- Granska loggningen av transaktions-ID:n, ARN:er och tidsstämplar för intern finansiell avstämning.
- Modellera beteendet för partiella fångster och flera återbetalningar på en enskild transaktion.
- Undersök effekten av handlarkategorikoder på simulerade auktoriseringsgrader och avgiftsstrukturer.
A short scoping call, then a written plan for your MIDs.
Frågor om Sandlådemiljö
Visas sandlådetransaktioner på riktiga bankutdrag eller medför de systemavgifter?
Nej, transaktioner som behandlas inom en sandlådemiljö interagerar inte med faktiska betalningssystem som Visa eller Mastercard. De hanteras av en mock-processor som simulerar utfärdarens svar.
Följaktligen flyttas inga riktiga medel, ingen kortinnehavare debiteras, och handlaren ådrar sig inga utbytes- eller systemavgifter. Miljön är helt isolerad för att förhindra finansiell påverkan.
Kan jag testa Stark Kundautentisering (SCA) och 3D Secure i sandlådan?
Ja, högkvalitativa sandlådemiljöer tillhandahåller specifika testkort eller flaggor för att utlösa 3DS-flöden. Detta gör det möjligt för utvecklare att testa omdirigeringen till en simulerad Access Control Server (ACS) och hantera de resulterande autentiseringsresultaten, såsom framgång, misslyckande eller bypass.
Det är ett viktigt steg för europeiska handlare att säkerställa efterlevnad av PSD2-mandat för elektroniska betalningar.
Hur simulerar jag en hård avvisning kontra en mjuk avvisning vid testning?
Simulering uppnås vanligtvis genom att använda olika testkortnummer eller transaktionsbelopp som specificeras i dokumentationen. Ett specifikt BIN kan mappas till ett 'Förlorat eller Stulet'-svar (hård avvisning), medan ett annat kan utlösa 'Otillräckliga Medel' (mjuk avvisning).
Att testa dessa varianter är avgörande för utvecklare att implementera korrekt återförsökslogik och att skilja mellan permanenta och tillfälliga fel.
Är lagrad kortinnehavardata i sandlådan föremål för PCI-DSS-efterlevnad?
Även om sandlådan inte bör innehålla riktig kortinnehavardata, är säkerheten för API-nycklarna och den simulerade datan fortfarande viktig. De flesta sandlådemiljöer använder pseudodata som liknar riktiga PAN men misslyckas med Luhn-algoritmkontroller eller tillhör odefinierade intervall.
Utvecklare bör dock upprätthålla goda säkerhetsrutiner och aldrig använda riktig kunddata i en testmiljö för att undvika potentiella risker för dataläckage.
Kommer mina webhook-slutpunkter att ta emot samma nyttolast som produktionsmiljön?
JSON- eller XML-nyttolasten som levereras till din webhook-URL i sandlådan bör spegla produktionsschemat exakt. Detta inkluderar samma fält för transaktions-ID, belopp, valuta och statuskoder.
Att testa detta säkerställer att din backend-parser är korrekt konfigurerad för att hantera live-dataströmmen utan att behöva göra kodändringar under övergången till produktion.
Kan jag testa avräknings- och avstämningsprocessen i sandlådan?
Du kan simulera övergångarna som leder till avräkning, såsom att flytta en transaktion från 'auktoriserad' till 'fångad'. Vissa sandlådor låter dig generera mock-rapporter som liknar avräkningsfilerna som tillhandahålls av förvärvare.
Detta hjälper till att bygga automatiserade avstämningsverktyg som matchar interna order-ID med transaktionsreferenserna som tillhandahålls av betaltjänstleverantören.
Relaterade funktioner.
Redo för fart?
Berätta om ditt företag. Vi matchar dig med rätt inlösenpartners och rätt rutt, vanligtvis inom en vecka.