Sandkassemiljø
Cardflo-sandkassemiljøet giver udviklere mulighed for at integrere og teste betalingsløsninger uden at påvirke live-transaktioner. Dette isolerede rum afspejler vores produktionsmiljø, hvilket muliggør grundig test af alle Cardflo-funktioner, fra betalingsbehandling til webhooks og API-interaktioner, hvilket sikrer en problemfri overgang til live-drift.
- Kategori
- Udvikler
- Funktioner
- 10
- Tilgængelig på
- Alle abonnementer
Overblikket
Et sandkassemiljø fungerer som en ikke-produktionsinstans af en betalingsgateway eller orkestreringsplatform, der giver udviklere mulighed for at modellere hele transaktionslivscyklussen uden at flytte reelle midler. Det fungerer som en kopi af den live API, inklusive komponenter til godkendelse, indfangning og afregning.
Inden for denne isolerede container kan tekniske teams verificere deres integrationslogik, anmodningsstrukturer og autentificeringsheaders mod strenge valideringsregler. Ved at bruge testlegitimationsoplysninger og simulerede kortidentifikationsnumre (BIN'er) kan forhandlere evaluere, hvordan deres backend reagerer på forskellige svar, såsom vellykkede betalinger, bløde afvisninger eller 3DS-autentificeringsprompter.
Sandkassen sidder mellem forhandlerapplikationen og den simulerede indløser og giver et sikkert sted at sikre, at koden håndterer kanttilfælde, såsom utilstrækkelige midler eller udløbne kort, før den flyttes til et live produktionsmiljø, hvor fejl kan resultere i tab af indtægter eller øgede chargeback-forhold.
Sådan fungerer det
Generering og autentificering af legitimationsoplysninger
Udviklere får et specifikt sæt API-nøgler eller Bearer-tokens, der er udpeget til testmiljøet. Disse legitimationsoplysninger dirigerer anmodninger til en mock-processor i stedet for de live betalingssystemer.
Dette sikrer, at intet forhandleridentifikationsnummer (MID) faktureres for behandlingsgebyrer, og ingen reelle kortholderdata kommer ind i produktionssystemerne.
Simuleret transaktionsbehandling
Forhandleren sender en betalingsanmodning ved hjælp af foruddefinerede testkortnumre, der udløser specifikke resultater. For eksempel kan brug af et BIN simulere en vellykket godkendelse, mens et andet udløser et CVV-mismatch eller en hård afvisning.
Sandkassen returnerer en identisk JSON-svarstruktur til den live API for at sikre kompatibilitet.
Webhook-begivenhedsmeddelelse
Når en transaktionsstatus ændres i sandkassen, genererer systemet asynkrone webhooks. Forhandlerserveren modtager disse meddelelser på et udpeget endepunkt for at verificere, at deres system korrekt opdaterer den interne database.
Dette trin er afgørende for at teste automatisk ordreopfyldelse eller abonnementsstyringslogik i realtid.
Tilstandsændring og afregning
Brugere kan manuelt eller programmatisk overføre en transaktions tilstand fra autoriseret til afregnet eller refunderet inden for testdashboardet. Dette giver mulighed for verifikation af efterkøbsarbejdsgange, herunder håndtering af genfindingsanmodninger eller delvise refusioner, hvilket sikrer, at forhandlerens brugergrænseflade afspejler den korrekte finansielle tilstand.
Hvorfor det betyder noget
Risikoreduktion under implementering
Implementering af nye betalingsflows direkte i produktion skaber høj operationel risiko. Ved at bruge en sandkasse kan udviklere identificere logiske fejl eller fejlformede API-anmodninger, der ellers ville føre til mislykkede kasser.
Denne isolation beskytter integriteten af det live Merchant Identification Number og forhindrer utilsigtet udløsning af anti-svindel-filtre, der kunne opstå under aggressiv test af ny kort-tilstedeværende eller kort-ikke-tilstedeværende integrationslogik.
Validering af kompleks logik
Moderne betalinger involverer ofte flertrinsprocesser som Strong Customer Authentication (SCA) eller tilbagevendende fakturering. En sandkasse giver mulighed for grundig test af kortholder-initierede og forhandler-initierede transaktioner uden de finansielle omkostninger ved reelle transaktioner.
Det sikrer, at systemet korrekt fortolker forskellige afvisningskoder og svarmeddelelser fra udstedere, hvilket muliggør forfining af dunning-logik og genforsøgsstrategier for at optimere eventuelle konverteringsrater.
Anvendelser
Initial API-integration
Nye forhandlere bruger sandkassen til at kortlægge deres interne ordrestyringssystemer til betalingsgatewayens API-endepunkter. Dette bekræfter, at datafelter som valutakoder og forhandlerkategorikoder er korrekt formateret til godkendelse.
Verifikation af tilbagevendende fakturering
Abonnementsbaserede virksomheder tester deres dunning-sekvenser ved at simulere kortudløb eller utilstrækkelige midler. Dette sikrer, at systemet korrekt forsøger genforsøg og sender passende meddelelser til kunden, før tjenesten suspenderes.
Fejlfinding af webhook-endepunkt
Udviklere bruger testmiljøet til at verificere, at deres firewall- og serverkonfigurationer tillader indgående webhook-meddelelser. Dette forhindrer problemer, hvor ordrer forbliver 'afventende' på trods af vellykket godkendelse på indløserniveau.
Test af alternative betalingsmetoder
Før aktivering af lokale betalingsmetoder kan forhandlere simulere de omdirigeringsflows, der kræves for APM'er. Dette sikrer, at brugeroplevelsen forbliver konsistent, når kunden sendes til en tredjeparts wallet eller bankportal.
I tal
Typiske effektivitetsgevinster observeret af tekniske teams ved brug af en omfattende sandkasse sammenlignet med manuel dokumentationsgennemgang og direkte produktionstest.
Estimeret reduktionsområde i fejl efter implementering relateret til betalingslogik, når grundig sandkassetest implementeres som en del af CI/CD-pipelinen.
Branchestandard svartid for mock API-endepunkter, hvilket muliggør hurtig iteration under softwareudviklingslivscyklussen.
Relaterede termer
Talk to our team about a live rollout on your acquiring stack.
Hvad du får med Sandkassemiljø
- Verificer API-anmodnings- og svarstrukturer mod officiel dokumentation i et sikkert miljø.
- Simuler specifikke afvisningsårsager for godkendelse for at validere fejlhåndtering og kundebeskeder.
- Udløs og modtag webhook-meddelelser for statusopdateringer som indfangning, refusion og tvist.
- Test 3-D Secure-autentificeringsflows for at sikre overholdelse af PSD2- og SCA-krav.
- Valider håndteringen af netværkstokens og kontopdateringsmeddelelser uden reelle data.
- Udfør belastningstest på integrationslogik, før du overgår til produktionsmiljøer med højere volumen.
- Konfigurer flere forhandlerprofiler for at teste valutaomregning og indenlandsk versus international behandling.
- Gennemgå logningen af transaktions-ID'er, ARN'er og tidsstempler for intern finansiel afstemning.
- Modeller adfærden af delvise indfangninger og flere refusioner på en enkelt transaktion.
- Undersøg virkningen af forhandlerkategorikoder på simulerede godkendelsesrater og gebyrstrukturer.
A short scoping call, then a written plan for your MIDs.
Spørgsmål om Sandkassemiljø
Viser sandkassetransaktioner sig på rigtige bankudtog eller medfører de gebyrer?
Nej, transaktioner behandlet inden for et sandkassemiljø interagerer ikke med faktiske betalingssystemer som Visa eller Mastercard. De håndteres af en mock-processor, der simulerer udstederens svar.
Derfor flyttes der ingen reelle midler, ingen kortholder opkræves, og forhandleren pådrager sig ingen interchange- eller systemgebyrer. Miljøet er fuldstændig isoleret for at forhindre finansiel indvirkning.
Kan jeg teste Strong Customer Authentication (SCA) og 3D Secure i sandkassen?
Ja, sandkassemiljøer af høj kvalitet tilbyder specifikke testkort eller flag til at udløse 3DS-flows. Dette giver udviklere mulighed for at teste omdirigeringen til en simuleret Access Control Server (ACS) og håndtere de resulterende autentificeringsresultater, såsom succes, fejl eller omgåelse.
Det er et vigtigt skridt for europæiske forhandlere at sikre overholdelse af PSD2-mandater for elektroniske betalinger.
Hvordan simulerer jeg en hård afvisning versus en blød afvisning under test?
Simulering opnås normalt ved at bruge forskellige testkortnumre eller transaktionsbeløb specificeret i dokumentationen. Et specifikt BIN kan være knyttet til et 'Mistet eller stjålet' svar (hård afvisning), mens et andet kan udløse 'Utilstrækkelige midler' (blød afvisning).
Test af disse varianter er afgørende for udviklere for at implementere korrekt genforsøgslogik og for at skelne mellem permanente og midlertidige fejl.
Er lagrede kortholderdata i sandkassen underlagt PCI-DSS-overholdelse?
Selvom sandkassen ikke bør indeholde reelle kortholderdata, er sikkerheden af API-nøglerne og de simulerede data fortsat vigtig. De fleste sandkassemiljøer bruger pseudo-data, der ligner reelle PAN'er, men som fejler Luhn-algoritmekontroller eller tilhører ikke-tildelte områder.
Udviklere bør dog opretholde god sikkerhedspraksis og aldrig bruge reelle kundedata i et testmiljø for at undgå potentielle datalækagerisici.
Vil mine webhook-endepunkter modtage den samme payload som produktionsmiljøet?
JSON- eller XML-payload'en, der leveres til din webhook-URL i sandkassen, skal afspejle produktionsskemaet nøjagtigt. Dette inkluderer de samme felter for transaktions-ID, beløb, valuta og statuskoder.
Test af dette sikrer, at din backend-parser er korrekt konfigureret til at håndtere live-datastreamen uden at skulle foretage kodeændringer under overgangen til produktion.
Kan jeg teste afregnings- og afstemningsprocessen i sandkassen?
Du kan simulere de overgange, der fører til afregning, såsom at flytte en transaktion fra 'autoriseret' til 'indfanget'. Nogle sandkasser giver dig mulighed for at generere mock-rapporter, der ligner de afregningsfiler, der leveres af indløsere.
Dette hjælper med at opbygge automatiserede afstemningsværktøjer, der matcher interne ordrenumre med de transaktionsreferencer, der leveres af betalingstjenesteudbyderen.
Relaterede funktioner.
Klar til fart?
Fortæl os om din virksomhed. Vi matcher dig med de rigtige ’acquiring’-partnere og den rigtige rute, typisk inden for en uge.