Testguide til Betalingsport med 10 Eksempler på testscenarier

Testguide til Betalingsport med 10 Eksempler på testscenarier

en overbevisende Guide til test af betalingsportal + eksempler på testcase

i dag, med et stadigt voksende antal forbrugere, bør e – handelsplatforme være klar til at levere sikre og brugervenlige betalingsportaler, der kan stå til rådighed for alle, der ønsker at høje belastninger uden fejl i ydeevne. Før de implementerer onlinebetalinger, skal virksomheder således være sikre på, at deres e-handelsplatforme problemfrit kan integreres med en port og give en fremragende brugeroplevelse.

når det kommer til udvikling eller modernisering af betalingsportaler og dens videre implementering, spiller test en vigtig rolle. Før du går live, hjælper det med at verificere mange vigtige aspekter, der påvirker programmets funktionalitet, sikkerhed og ydeevne. Alle disse ting har stor indflydelse på din kundetilfredshed med det serviceniveau, din virksomhed leverer.

i denne artikel lærer du, hvad en betalingsport er, hvordan den fungerer, hvorfor den skal testes, før du interagerer med slutbrugere og får reelle betalinger. Derudover er der ti eksempler på testscenarier og en oversigt over Stripes retningslinje for test af betalingsportaler. I slutningen af artiklen får du et samlet billede af betalingsportens test.

Hvad er en betalingsportal?

en betalingsportal er en programapp, som tjenesteudbydere bruger til at behandle betalinger for onlinekøb foretaget på den erhvervsdrivendes hjemmeside. Porten ligner en grænseflade, der betjener en mellemmand mellem en købmand og en overtagende bank. Traditionelt behandler betalingsportaler betalinger foretaget med kreditkort, men moderne applikationer er bygget til at arbejde med elektroniske overførsler, betalingskort, bonusser osv.

følsomme kortoplysninger krypteres for at sikre online betalingssikkerhed. Når en kunde foretager køb på hjemmesiden via en betalingsport, udfører sidstnævnte mange opgaver for at behandle betalingen. Når en kunde vælger “pay” eller “checkout”, omdirigerer købmandens hjemmeside ham til betalingssiden for at indtaste kortoplysningerne.

det er afgørende, at købmanden er helt i overensstemmelse med sikkerhedsstandarder, da betalingsportaler indsamler og gemmer følsomme data som kortet og betalingsoplysningerne på deres servere. Når alle oplysninger er indsamlet, sendes de derefter til den overtagende bank til godkendelse. Når den er godkendt, sender banken en bekræftelse tilbage til købmandens side og kunden.

for at illustrere, hvordan det fungerer nedenfor, er PayPals øjeblikkelige betalingsstrøm.

kilde: PayPal

mange forhandlere bruger betalingsportaler, da dette er den mest populære måde at behandle betalinger let på. Kun store virksomheder har kapacitet til at forbinde arbejde med at erhverve banker direkte. Denne betalingsløsning er omkostningseffektiv, da gebyrerne er ret overkommelige. Moderne porte er ikke begrænset til betalingsbehandling, men tilbyder også andre nyttige funktioner som tilpasset rapportering. Som nævnt giver de nyeste løsninger muligheder for at arbejde med forskellige typer kort.

traditionelt har betalingsportaler følgende struktur:

betalingsmetode. Disse oplysninger vises på en købmands hjemmeside, e-butik eller en mobilapp. Normalt indeholder disse data virksomhedens navn, summen af køb og betalingskommentarer. Efter bekræftelse overføres klienten til betalingsporten.

betalingsside. Her ser klienten de vigtigste detaljer i hans køb og er i stand til at annullere ordren, godkende eller vælge en anden mulighed i menuen.

Status side. Denne side er placeret på købmandens side. Klienten omdirigeres her, hvis betalingen er bestået eller ikke bestået.

betalings resultat side. Denne side er også placeret på købmandens side og udløses af betalingsportalens bot for at vise resultaterne af betalingen.

før vi definerer test af betalingsportaler, er det afgørende at forstå, at hver tjenesteudbyder kan have forskellige transaktionsstrømme. For eksempel har Stripe, en af de bedste online betalingstjenesteudbydere, følgende strøm for standard online betalingsscenariet:

kilde: Stripe

ifølge betalingsformål tilbyder Stripe andre API ‘ er, såsom opsætning af senere betalinger, lagring af et kort under betaling, tilbageholdelse af et kort, 3D-sikker godkendelse, ignorering af bankgodkendelse osv.

som alle andre programmer skal betalingsportaler testes for at sikre, at de opfylder både købmænds og kunders behov og forventninger. Hver API, hvert scenarie, hver funktion, som dem, der leveres af Stripe, skal kontrolleres for ydeevne, sikkerhed, funktionalitet og integration.

fra en forbrugers perspektiv forventes online betaling at være let og brugervenlig. Transaktionen tager et par sekunder, betalingssiden genereres hurtigt, brugeren får besked om den vellykkede betaling eller andet.

fra købmandens perspektiv skal en komplet transaktionsstrøm fungere fremragende for at imødekomme brugernes forventninger til hurtigt og problemfrit online køb. Alle job, der udføres af betalingsporten, skal fungere korrekt, hvorfor det er vigtigt at udføre test.

test gør det muligt for handlende at blive sikre på, at deres program fungerer efter behov, ikke kun når applikationen implementeres, men selv når de allerede har det på plads. I sidstnævnte tilfælde kan test hjælpe en købmand med at kontrollere, om den implementerede løsning fungerer korrekt, og om der er måder at forbedre den på.

brug for betaling Port test? Tjek vores e-handel Test tjenester.

vigtige aspekter af Betalingsportaltestning af Transaktionsstrøm

så du skal teste en e-butik, der har en betalingsport. Test af en transaktionsstrøm skal vise, at betalinger er bestået, og ordrer bekræftes. Før test skal der udvikles en omfattende teststrategi og plan. Under forberedelsen til test af programmer og under udførelsen skal du overveje tjeklisterne nedenfor.

sikkerhed

sikkerhedstest har til formål at sikre, at alle data, der behandles i applikationen, er beskyttet mod forskellige sårbarheder som cyberangreb, krypteret og transmitteres sikkert. Her er nogle eksempler på aspekter, der er inkluderet i sikkerhedstest:

  • porten er sikker fra spoofing, cross-site scripting angreb og injektioner.
  • Applikationen indeholder autorisationsstyring og brugerroller.
  • ved hvert transaktionstrin implementeres alle de krævede SSL-certifikater.

ydeevne

Ydelsestest bruges til at kontrollere, om applikationen ikke mislykkes, hvis et stort antal brugere sender betalinger samtidigt. For eksempel kan en testingeniør teste, om porten kan håndtere belastningen på 100 køb på 1 sekund uden systemfejl. Andre eksempler er som følger:

  • porten fungerer korrekt under belastningstider.
  • applikationen kan fungere i forskellige miljøer.
  • for passende arbejde har porten nok plads og hukommelse.

Integration

integrationstest handler om at kontrollere, at en betalingsport er problemfrit integreret med en købmands hjemmeside eller applikation. Testingeniører tester her en komplet transaktionsstrøm for at sikre, at bestilling, betalingsbehandling og verifikation fungerer efter behov. Her er nogle ting at teste:

  • porten anmoder om og giver de rigtige data.
  • det rigtige format for Valuta er sat op.
  • transaktionsstrømmen og behandlingstiden er korrekte.

funktionalitet

funktionel test udføres hovedsageligt til nyudviklede porte. De testes mod de foruddefinerede funktionelle krav, dvs.testere kontrollerer, om appen fungerer som forventet. Følgende aspekter bør overvejes:

  • porten beregner alle gebyrer korrekt.
  • brugere og forhandlere får besked om den godkendte transaktion via e-mail.
  • under brugerens anmodning ændrer systemet valuta-og sprogformater.

under porttestningen er det også afgørende at teste det for datakvalitet, datafangst og datastrøm. Blandt de hyppigste fejl relateret til data er kundens data og betalingsoplysninger fanget forkert, duplikattransaktioner, der vises i processoren, kreditkortdata fanget forkert osv.

porten bør også testes for Brugervenlig grænseflade og brugeroplevelse. For eksempel, hvis transaktionen af en eller anden grund mislykkes, skal brugeren få en øjeblikkelig meddelelse, der indeholder en kort og klar besked om fejlen.

du kan være interesseret i at oprette en ideel kvalitetssikringsproces til startups. Tjek vores guide!

hvad du har brug for for at begynde at teste Betalingsportaler

før du tester et programprodukt, skal du være godt forberedt og have alle data, der kræves til enhver type test, du planlægger at udføre. Nedenfor er en nyttig liste over ting, du har brug for:

  1. betalingsport dokumentation, der kan findes enten på tjenesteudbydernes hjemmesider eller leveres af brugerdefinerede udviklere
  2. fejlkoder liste
  3. Processor sandkasse
  4. testdata med alle krævede testkortnumre
  5. en liste over betalingsmetoder
  6. en god forståelse af alle vilkår relateret til betalingsport
  7. væsentlig viden om, hvordan en transaktionsstrøm fungerer
  8. enhver databaseinformation og/eller adgang til den
  9. en testplan og-strategi
  10. interessenter fra købmandens side for at være involveret i test

testcases til Betalingsport

før du bruger en port til reelle betalinger, skal den testes af testingeniører ved hjælp af et vist antal testscenarier og testcases. Lad os først definere begge for at forstå forskellen.

et testscenarie er enhver funktion eller funktionalitet, der skal testes; det kan bestå af flere testcases. En testsag er en sekvens af handlinger, der udføres for at kontrollere, om funktionaliteten fungerer efter behov. Nedenfor kan du se en liste over mulige testscenarier.

  1. Kontroller, at alle obligatoriske felter på betalingssiden er gyldige. Betalingsbehandling bør ikke fortsætte, hvis der mangler obligatoriske data.
  2. Test porten ved hjælp af et gyldigt kreditkort med gyldig sikkerhedskode og udløbsdato.
  3. Test porten ved hjælp af et ugyldigt kreditkort med gyldig sikkerhedskode og gyldig udløbsdato.
  4. Kontroller, om systemet fungerer korrekt med hver af de mulige betalingsmuligheder, for eksempel kreditkort, PayPal, betalingskort osv.
  5. Test, om porten fungerer korrekt, når sprogformat eller valutaformat ændres.
  6. Test transaktionsstrømmen ved hjælp af de blokerede kortdata.
  7. kontroller systemets opførsel, når internetforbindelsen er afbrudt under betalingsbehandling.
  8. Kontroller, om en kunde og en købmand får e-mail-meddelelse om en vellykket/mislykket transaktion.
  9. Kontroller, om dobbeltbetalinger forekommer.
  10. Test sikkerhedskrav som svindelforebyggelsesmønstre.

dette er de mest almindelige testscenarier. Selvfølgelig adskiller de sig fra platform til platform.

for at illustrere, hvordan betalingsportprøvning fungerer på et levende eksempel, har vi valgt Stripe. Før du går live og får rigtige betalinger ved hjælp af Stripe, skal du teste, hvordan dine eksisterende systemer integreres med Stripe. For at teste integration kan du bruge Stripes retningslinjer. Nedenfor er en kort oversigt.

Vær først opmærksom på, at Stripe tilbyder no-code muligheder for at teste deres port for ikke-udviklere. Du kan dog søge efter en testleverandør for at få professionel hjælp.

Stripe giver alle de nødvendige oplysninger og testdata for at kontrollere, at integrationen udføres som forventet. Du kan også teste forskellige scenarier for at validere den korrekte transaktionsstrøm.

i deres retningslinjer giver Stripe testoplysninger til betalingsformål API og afgifter API. Der kan du tjekke, hvilke punkter der skal dækkes. Stripe giver også alle de nødvendige kortdata: grundlæggende kortnumre til Visa, Mastercard, Amerikansk Ekspres, opdage, Diners Club, JCB, Union Pay, alt sammen med enhver 3 cifre CVC og enhver fremtidig dato. Internationale kortnumre og regulatoriske (3D secure) kortnumre og tokens til test er også tilgængelige.
der er også kort til at simulere tvister og specifikke svar, for eksempel “Charge lykkes, men verifikationen mislykkes.


kilde: Stripe betaling test side

du kan også finde oplysninger om Sats grænser og kilder. Stripe giver mulighed for at bruge forskellige betalingsmekanismer og metoder via Sources API. Afhængigt af hvordan købers midler behandles, kategoriseres betalingsmetoder som pull and push. Ifølge metoden følger en kunde en vis strømning. Alle mulige strømme kan findes her og er defineret som ingen, omdirigering, kodebekræftelse, modtager. Sådan ser en kundehandlingsstrøm ud:

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.