Sandboksmiljø
Utviklerførste API-er, webhooks og dokumentasjon for å integrere prosessering av flere innløsere direkte i produktet ditt.
- Kategori
- Utvikler
- Funksjoner
- 10
- Tilgjengelig på
- Alle abonnementer
Cardflos sandboksmiljø lar utviklere integrere og teste betalingsløsninger uten å påvirke live transaksjoner. Dette isolerte rommet gjenspeiler vårt produksjonsmiljø, og muliggjør grundig testing av alle Cardflo-funksjoner, fra betalingstransaksjoner til webhooks og API-interaksjoner, noe som sikrer en smidig overgang til live drift.
API-er er versjonerte, idempotente og dokumentert med faktiske "payloads", og "webhooks" er signert slik at du kan stole på dem i produksjonsflyter. Sandbox speiler live-atferd, inkludert avvisninger, tvister og 3DS-utfordringer.
Oversikten
Et sandboksmiljø fungerer som en ikke-produksjonsforekomst av en betalingsgateway eller orkestreringsplattform, og lar utviklere modellere hele transaksjonslivssyklusen uten å flytte reelle midler. Det fungerer som en kopi av live API, inkludert komponenter for autorisasjon, fangst og oppgjør.
Innenfor denne isolerte beholderen kan tekniske team verifisere sin integrasjonslogikk, forespørselsstrukturer og autentiseringshoder mot strenge valideringsregler. Ved å bruke testlegitimasjon og simulerte kortidentifikasjonsnumre (BIN-er), kan handelsmenn evaluere hvordan deres backend reagerer på ulike svar, for eksempel vellykkede betalinger, myke avvisninger eller 3DS-autentiseringsforespørsler.
Sandboksen sitter mellom handelsapplikasjonen og den simulerte innløseren, og gir et trygt rom for å sikre at koden håndterer ekstreme tilfeller, for eksempel manglende midler eller utløpte kort,
før den flyttes til et live produksjonsmiljø der feil kan føre til tap av inntekter eller økte chargeback-forhold.
Slik fungerer det
Generering og autentisering av legitimasjon
Utviklere får et spesifikt sett med API-nøkler eller Bearer-tokener som er utpekt for testmiljøet. Disse legitimasjonene ruter forespørsler til en falsk prosessor i stedet for de live betalingssystemene. Dette sikrer at ingen MID (Merchant Identification Number) faktureres for behandlingsgebyrer, og ingen reelle kortholderdata kommer inn i produksjonssystemene.
Simulert transaksjonsbehandling
Forhandleren sender en betalingsforespørsel ved hjelp av forhåndsdefinerte testkortnumre som utløser spesifikke utfall. For eksempel kan bruk av en BIN simulere en vellykket autorisasjon, mens en annen utløser et CVV-misforhold eller en hard avvisning. Sandboksen returnerer en identisk JSON-responsstruktur til live API for å sikre kompatibilitet.
Webhook-hendelsesvarsel
Når en transaksjonsstatus endres i sandboksen, genererer systemet asynkrone webhooks. Forhandlerserveren mottar disse varslene på et angitt endepunkt for å verifisere at systemet deres riktig oppdaterer den interne databasen. Dette trinnet er kritisk for å teste automatisk ordreoppfyllelse eller abonnementshåndteringslogikk i sanntid.
Tilstandsendring og oppgjør
Brukere kan manuelt eller programmatisk overføre tilstanden til en transaksjon fra autorisert til avregnet eller refundert i testdashboardet. Dette gjør det mulig å verifisere etterkjøpsarbeidsflyter, inkludert håndtering av gjenfinningforespørsler eller delvise refusjoner, og sikrer at forhandlerens brukergrensesnitt gjenspeiler riktig finansiell tilstand.
Hvorfor det er viktig
Risikoreduksjon under distribusjon
Implementering av nye betalingsstrømmer direkte i produksjon skaper høy operasjonell risiko. Ved å bruke en sandboks kan utviklere identifisere logiske feil eller feilformede API-forespørsler som ellers ville ført til mislykkede utsjekk. Denne isolasjonen beskytter integriteten til det live Merchant Identification Number og forhindrer utilsiktet utløsning av anti-svindelfiltre som kan oppstå under aggressiv testing av ny kortbasert eller kortfri integrasjonslogikk.
Validering av kompleks logikk
Moderne betalinger involverer ofte flertrinns prosesser som Strong Customer Authentication (SCA) eller gjentakende fakturering. En sandboks muliggjør grundig testing av kortholder-initierte og forhandler-initierte transaksjoner uten de økonomiske kostnadene ved reelle transaksjoner. Det sikrer at systemet riktig tolker ulike avvisningskoder og responsmeldinger fra utstedere, noe som gjør det mulig å forbedre dunning-logikken og gjentaksstrategiene for å optimalisere eventualle konverteringsrater.
Bruksområder
Initial API-integrasjon
Nye handelsmenn bruker sandboksen til å kartlegge sine interne ordrehåndteringssystemer til betalingsgatewayens API-endepunkter. Dette bekrefter at datafelt som valutakoder og MCC-koder er riktig formatert for autorisasjon.
Verifisering av gjentakende fakturering
Abonnementsbaserte virksomheter tester dunning-sekvensene sine ved å simulere kortutløp eller mangel på midler. Dette sikrer at systemet korrekt forsøker gjentakelser og sender passende varsler til kunden før tjenesteopphør.
Feilsøking av Webhook-endepunkt
Utviklere bruker testmiljøet til å verifisere at brannmur- og serverkonfigurasjonene deres tillater innkommende webhook-varsler. Dette forhindrer problemer der bestillinger forblir 'ventende' til tross for vellykket autorisasjon på oppkjøpsnivå.
Testing av alternative betalingsmetoder
Før aktivering av lokale betalingsmetoder kan handelsmenn simulere omadresseringene som kreves for APM-er. Dette sikrer at brukeropplevelsen forblir konsekvent når kunden sendes til en tredjeparts lommebok eller bankportal.
I tall
Typiske effektivitetsgevinster observert av tekniske team ved bruk av en omfattende sandboks sammenlignet med manuell dokumentasjonsgjennomgang og direkte produksjonstesting.
Estimert reduksjonsområde i feil etter distribusjon relatert til betalingslogikk når grundig sandbokstesting implementeres som en del av CI/CD-pipelinen.
Bransjestandard responstid for falske API-endepunkter, som muliggjør rask iterasjon under programvareutviklingslivssyklusen.
Relaterte begreper
Snakk med teamet vårt om en live utrulling på rails-ene til våre acquiring-partnere.
Hva du får med Sandboksmiljø
- Verifiser API-forespørsel og responsstrukturer mot offisiell dokumentasjon i et sikkert miljø.
- Simuler spesifikke avvisningsårsaker for autorisasjon for å validere feilhåndtering og kundemeldinger.
- Utløs og motta webhook-varsler for statusoppdateringer som fangst, refusjon og tvist.
- Test 3-D Secure-autentiseringsflyter for å sikre samsvar med PSD2- og SCA-krav.
- Valider håndtering av nettverkstokener og kontooppdateringsvarsler uten reelle data.
- Utfør belastningstester på integrasjonslogikk før du går over til produksjonsmiljøer med høyere volum.
- Konfigurer flere selgerprofiler for å teste valutakonvertering og innenlandsk versus internasjonal behandling.
- Revider loggføringen av transaksjons-ID-er, ARN-er og tidsstempler for intern finansiell avstemming.
- Modeller oppførselen til delvise fangster og flere refusjoner på en enkelt transaksjon.
- Undersøk virkningen av MCC-koder på simulerte autorisasjonsrater og gebyrstrukturer.
A short scoping call, then a written plan for your MIDs.
Spørsmål om Sandboksmiljø
Viser sandbokstransaksjoner på virkelige bankutskrifter eller pådrar de seg nettverksgebyrer?
Nei, transaksjoner behandlet innenfor et sandboksmiljø interagerer ikke med faktiske betalingssystemer som Visa eller Mastercard. De håndteres av en falsk prosessor som simulerer utstederens respons.
Følgelig flyttes ingen reelle midler, ingen kortholder blir belastet, og forhandleren pådrar seg ingen interbankgebyrer eller nettverksgebyrer. Miljøet er fullstendig isolert for å forhindre finansiell innvirkning.
Kan jeg teste Strong Customer Authentication (SCA) og 3D Secure i sandboksen?
Ja, høykvalitets sandboksmiljøer gir spesifikke testkort eller flagg for å utløse 3DS-flyter. Dette gjør at utviklere kan teste omadressering til en simulert Access Control Server (ACS) og håndtere de resulterende autentiseringsresultatene, for eksempel suksess, feil eller omgåelse.
Det er et viktig skritt for europeiske handelsmenn for å sikre overholdelse av PSD2-mandater for elektroniske betalinger.
Hvordan simulerer jeg en hard avvisning versus en myk avvisning under testing?
Simulering oppnås vanligvis ved å bruke forskjellige testkortnumre eller transaksjonsbeløp spesifisert i dokumentasjonen. En spesifikk BIN kan være knyttet til en 'Tapt eller stjålet'-respons (hard avvisning), mens en annen kan utløse 'Manglende midler' (myk avvisning).
Testing av disse variantene er avgjørende for utviklere for å implementere riktig gjentakslogikk og for å skille mellom permanente og midlertidige feil.
Er lagrede kortholderdata i sandboksen underlagt PCI-DSS-samsvar?
Selv om sandboksen ikke skal inneholde ekte kortholderdata, er sikkerheten til API-nøklene og de simulerte dataene fortsatt viktig. De fleste sandboksmiljøer bruker pseudodata som ligner på ekte PAN-er, men som feiler Luhn-algoritmesjekker eller tilhører uallokerte områder.
Imidlertid bør utviklere opprettholde god sikkerhetspraksis og aldri bruke ekte kundedata i et testmiljø for å unngå potensielle datalekkasjerisikoer.
Vil mine webhook-endepunkter motta samme nyttelast som produksjonsmiljøet?
JSON- eller XML-nyttelasten som leveres til din webhook-URL i sandboksen, skal gjenspeile produksjonsskjemaet nøyaktig. Dette inkluderer de samme feltene for transaksjons-ID, beløp, valuta og statuskoder.
Testing av dette sikrer at din backend-parser er riktig konfigurert til å håndtere den live datastrømmen uten å måtte gjøre kodeendringer under overgangen til produksjon.
Kan jeg teste oppgjørs- og avstemmingsprosessen i sandboksen?
Du kan simulere overgangene som fører til oppgjør, for eksempel å flytte en transaksjon fra 'autorisert' til 'fanget'. Noen sandkasser lar deg generere falske rapporter som ligner oppgjørsfilene levert av innløsere.
Dette hjelper med å bygge automatiserte avstemmingsverktøy som samsvarer interne ordre-ID-er med transaksjonsreferansene levert av betalingstjenesteleverandøren.
Relaterte funksjoner.
Relatert guider.
Klar for å forbedre betalingsløsningen din?
Fortell oss om bedriften din. Vi finner de rette innløsningspartnerne og den rette ruten for deg, vanligvis innen en uke.