Menu

Payment Gateway Testing: Testers praktisk vejledning med tjekliste

  • Vigtigste
  • Webtest
  • Payment Gateway Testing: Testers praktisk vejledning med tjekliste

payment gateway testing

Prøv Vores Instrument Til At Fjerne Problemer

Testers guide til betaling gateway test:

Hvad er betalingsbehandlerne?

I henhold til Wikipedia, ”En betalingsbehandler er et selskab (ofte en tredjepart), der er udpeget af en købmand til at håndtere transaktioner fra forskellige kanaler såsom kreditkort og betalingskort til købmandskøbende banker. Betalingsbehandleren vil både kontrollere de modtagne detaljer ved at videresende dem til det respektive korts udstedende bank eller kortforening til verifikation og også udføre en række foranstaltninger til bekæmpelse af svig mod transaktionen. '

Nogle almindelige betalingsgateways er Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments osv.

Der er en masse litteratur tilgængelig online og offline om betalingsgateways og relateret terminologi.

Vejledning til test af betalingsgateway

I denne vejledning har jeg forsøgt at forenkle nogle af disse oplysninger og forsøgt at tilføje mine oplevelser.

Anbefalet læsning => Test af investeringsbankansøgninger

Under mit første projekt var jeg klar over, hvordan man korrekt testede en betalingsportal . Jeg lærte gradvist og arbejdede med succes med at implementere PayPal-, Braintree- og Authorize.net-integrationer med vores e-handelsapplikationer.

Vi diskuterer almindelig terminologi, forstår transaktionsflow fra slutning til slut og nyttige tip og bedste praksis.

Hvad du vil lære:

Betalingsgateway-terminologi

Lad os diskutere nogle udtryk, som vi vil bruge i denne artikel:

betalings-gateway-proces 1

1) Købmand - En købmand er en person eller et firma, der sælger produkter eller tjenester. Flipkart, Amazon, eBay er nogle eksempler på handlende.

2) Kreditkort - Et plastkort, der kan bruges til at købe produkter eller tjenester via en kreditkonto. Det har et 16-cifret kortnummer, en udløbsdato, hologram, magnetstrimmel, signaturpanel og et CVV-nummer (Card verification value).

Foran på kreditkort:

Foran på kreditkort

Bagsiden af ​​kreditkortet:

Bagsiden af ​​kreditkortet

(Kilde: about.com)

3) Erhvervende bank - Erhvervende bank er en finansiel institution, der vedligeholder købmandens bankkonto og gør det muligt for en købmand at acceptere og behandle debet- og / eller kreditkorttransaktioner i deres butik.

4) Udstedende bank - Udstedende bank er den finansielle institution, der udsteder kundens debet- eller kreditkort. Hver gang en kunde bruger et kredit- eller betalingskort til at foretage et køb, godkender den udstedende bank enten eller afviser transaktionen på baggrund af kortindehaverens status og videregiver disse oplysninger til den erhvervende bank.

For eksempel, transaktionen afvises, hvis kortets udløbsdato er forkert, eller hvis købsbeløbet overstiger kortkreditgrænsen osv.

5) Transaktion - Slut-til-slut-processen, hvorigennem forhandleren modtager penge til en transaktion med en kunde.

6) Autorisation - Der anmodes om tilladelse, når en kunde foretager et køb. Denne autorisation gives af kundens udstedende bank og bekræfter kortindehaverens gyldighed, betalingsevne og tilstedeværelsen af ​​tilstrækkelige midler osv. Når dette er afsluttet, holdes pengene tilbage, og saldoen trækkes fra kundens kreditgrænse, men er ikke endnu overført til købskontoen.

7) Capture - I denne handling indsamler købmanden de relevante kundebetalingsoplysninger og sender en afviklings- / opsamlingsanmodning til processoren. Processoren bruger disse oplysninger til at igangsætte pengeoverførsler mellem kundens kortkonto og købmandens bankkonto.

Læs også => Bankansøgningstest

Forskel mellem betalingsgateway og betalingsprocessorer

Der er en masse litteratur tilgængelig online om det, og om betalingsgateway og betalingsprocessor er forskellige moduler med forskellige funktioner.

I løbet af mine projekter har jeg observeret, at Betalingsprocessor og Betalingsgateways bruges om hinanden uden nogen egentlig forskel. Sælgerne henviser normalt til 'Payment Gateways' som betalingsprocessorer, da disse behandler alle betalinger.

'Betalingsbehandlerne' betragter sig selv som betalingsgateways, da de fungerer som et middel til at behandle og gennemføre den sikre betalingstransaktion.

Transaktionsflow

Følgende flowdiagram opsummerer den komplette flow fra det øjeblik en kunde afgiver en ordre til ordren er vellykket eller afvist.

Transaktionsflow

Hvis en kunde ønsker at annullere ordren, er følgende flowet:

annullere ordren

Forskellen mellem et tomrum og retur afhænger af, om en transaktion er fanget eller ej.

En uafviklet betaling kan annulleres, hvilket betyder, at de tilbageholdte midler krediteres tilbage til kortindehaverens konto. Hvis en transaktion allerede er afviklet eller indfanget, initieres en refusion, hvilket betyder, at pengene tages fra købskontoen og krediteres tilbage til kortholderens konto.

automatiseringstest interview spørgsmål og svar pdf

Hvorfor skal vi teste Payment Gateways?

Hvis vi skulle handle i en egentlig murstensbutik, ville vi betale kontant eller stryge vores kort (kredit eller debet) gennem maskinen under kassen for at gennemføre transaktionen.

Hvis du bruger kredit- eller betalingskort, er POS ( Test af salgsstedet ) vil maskinen angive, om betalingsbehandlingen ville blive godkendt eller afvist.

På samme måde skal vi under online-transaktioner have et sammenligneligt system, der godkender eller afviser en transaktion med det samme.

Fra et kundeperspektiv skal online betalingsbehandlingen på e-handelswebstedet være problemfri. Kunden klikker på knappen 'Betal nu' og skal se, at betalingen er vellykket eller afvist i de næste par sekunder.

Fra e-Commerce-butiksperspektivet skal forretningen sikre, at den komplette betalingscyklus (at få transaktioner fra onlinebutik, opsamling og godkendelse, refusion, annullering) fungerer fint. Hvis nogen af ​​disse underkomponenter ikke fungerer som forventet, kan det være et problem for købmanden.

Fra forhandlerperspektivet giver testfasen dem mulighed for at vænne sig til den valgte betalingsprocessorflow og evaluere, om den valgte mulighed faktisk er den bedste pasform til deres applikation og forretning.

Typer af test kræves

Afhængigt af valget af betalingsprocessor og produkt / applikationskravet kan du blive bedt om at udføre følgende typer test

  • Funktionel test - Funktionstest er påkrævet for nyere, mindre etablerede betalingsgateways for at sikre, at applikationen opfører sig som den skal, dvs. den håndterer ordrer, beregninger, afgifter osv. Nøjagtigt hvordan den skal. For mere etablerede betalingsprocessorer er denne type test muligvis ikke påkrævet.
  • Integrationstest - Integrationstest er afgørende, når det integreres med en betalingsgateway. Som tester skal du kontrollere, at integrationen af ​​dit websted / onlinebutik / applikation fungerer fint med de valgte betalingsportaler. Som tester skal du kontrollere hele transaktionsflowet:
    • Angiv bestilling
    • Kontroller, om der modtages midler på en handelskonto
    • Kontroller, om transaktionen kan refunderes eller annulleres
  • Test af ydeevne - Det er vigtigt at teste webstedet / onlinebutikken / applikationen for ydeevne. Betalingsprocessoren bør ikke mislykkes, hvis flere brugere forsøger at gennemføre transaktioner på samme tid.
  • Sikkerhedstest - Under en transaktion leverer en kunde følsomme oplysninger som deres kreditkortnummer, CVV-nummer osv. Det er meget vigtigt at sikre, at alle de følsomme oplysninger transmitteres efter kryptering, og at kanalen er sikker.

Nyttige tip

Baseret på min personlige erfaring er følgende nogle nyttige tip til testere:

# 1) Undersøg, om der er et gratis sandkassemiljø (til prøve- og udforskningsformål) til den betalingsgateway, der skal testes eller implementeres. At have en sandkasse til rådighed er bestemt nyttigt og giver holdet den ekstra fleksibilitet til at tilpasse værktøjet og teste så dybtgående som nødvendigt.

#to) Sørg for, at transaktionen testes end til ende. I vores projekter testede og rapporterede vi adskillige fejl relateret til datafangst og datastrøm fra applikation til betalingsgateway. Nogle af de specifikke bugs var:

  • Oplysninger om kunde (køber) navn blev ikke fanget korrekt
  • Kundens kreditkortudløbsdato blev fanget forkert på grund af en forkert funktion, der fik transaktionerne til at blive afvist af den udstedende bank på grund af forkerte kreditkortoplysninger.
  • Kopi af transaktion, der vises i betalingsprocessor

# 3) Undersøg begrænsningerne i betalingsgateway-sandkasser.

For eksempel, Authorize.net sandkasse understøtter en valuta pr. Sandkasse, så hvis du har brug for at teste flere valutaer, skal du konfigurere forskellige sandkasser. Også med det ville du aldrig være i stand til 'virkelig' at teste, hvordan systemet opfører sig, når Live Authorize.net-kontoen behandler transaktioner med flere valutaer.

# 4) Hvis betalingen mislykkes under en transaktion af en eller anden grund, skal kunden vise en passende besked. Enhver fejlmeddelelse, der er for teknisk som 'Objekt ikke indstillet til forekomst' eller '404-fejl', kan forvirre kunden og påvirke brugeroplevelsen.

Det er også en god ide at vise en generisk besked som 'Der ser ud til at være noget problem i behandlingen af ​​transaktionen, bedes du kontakte os på 1-800-800-8000'.

# 5) I forbindelse med verifikation efter frigivelse efter produktion skal klienten (applikationsvirksomhedsejer) oprette en live betalingskonto, konfigurere deres Merchant ID osv.

Afhængigt af den valgte betalingsprocessor kan det tage alt fra 2 dage til få uger at oprette kontoen. Dette skal meddeles af projektlederen til klienten på forhånd med tilstrækkelig tid til at oprette live-kontoen, før applikationen og betalingsprocessorintegrationen sættes i live.

Checkliste for testgateway og testtilfælde

Som enhver anden applikation involverer test af betalingsprocessorer korrekt testplanlægning.

Følgende tjekliste kan være nyttigt for testere og kan bruges som reference:

1) Opret betalingsprocessors sandkasse.

forskel mellem kvalitetskontrol og sikkerhed

to) Indsaml testkreditkortnumre, der vil blive brugt til at teste forskellige kreditkort. Sådanne oplysninger til Braintree betalingsprocessor kan som et eksempel findes på Braintree betalinger.

3) Kontroller applikationens opførsel, når en transaktion er vellykket.

4) Efter en vellykket transaktion skal du kontrollere, om betalingsgatewayen vender tilbage til din applikation for at vise en slags vellykket transaktion / bekræftelsesmeddelelse.

5) Bekræft, at kunden får en slags meddelelse om transaktionsbekræftelse, f.eks. E-mail med ordrebekræftelse osv., Hvis transaktionen er vellykket.

6) Tjek hvad der sker, hvis en betaling mislykkes, eller betalingsbehandleren holder op med at svare - er der nogen fejlmeddelelse?

7) Bekræft applikationsadfærd med browser-popup-blokering til og fra. Dette kan være nyttigt, hvis der vises pop op-bekræftelsesmeddelelser.

8) Bekræft forskellige indstillinger for forebyggelse af svig / sikkerhed.

For eksempel, hvis kundens faktureringsoplysninger ikke stemmer overens med den adresse, der er angivet til den udstedende bank, vil enhver uoverensstemmelse resultere i transaktionsnedgang.

9) Bekræft transaktionsposter i databasen, hvis testeren har adgang til applikationsdatabasen.

10) Kontroller, hvad der sker, når en kundesession udløber.

elleve) Kontroller konsollen under hele transaktionen, og rapporter eventuelle konsolfejl, der observeres.

12) Kontroller, at transaktionen sker på en sikker kanal.

For eksempel kan checkout-siderne være HTTPS versus resten af ​​webstedet, der er HTTP-sider.

13) Kontroller, at betalingsprocessorens valuta er konfigureret korrekt.

For eksempel, hvis applikationen / webstedet er en canadisk virksomhed / forhandler, skal betalingsbehandleren være indstillet til at acceptere CAD-valuta.

14) Hvis applikationerne har flere betalingsmuligheder som kreditkort og PayPal sammen, skal begge betalingsmuligheder testes individuelt fra ende til slut.

femten) Kontroller, at refusion eller ugyldigt beløb (fra betalingsbehandlingsadministratorportal) er det samme som transaktionsbeløbet. Under ingen omstændigheder skal restitutions- / ugyldighedsbeløbet overstige transaktionsbeløbet.

Læs også => Test af detailbanksystem

Opsætning af sandkasse: Braintree-betalingseksempel

1) Naviger til Braintree-websted .

to) Klik på knappen 'Prøv sandkassen'.

(Bemærk:Klik på et hvilket som helst billede for at se et forstørret billede)

Prøv sandkassen

3) Du bliver omdirigeret til Braintree-sandkasses websted. Udfyld alle de krævede oplysninger, og tilmeld dig sandkassen

tilmeld dig sandkassen

4) Du modtager en e-mail-underretning på den e-mail-adresse, der er angivet under tilmeldingen, vedrørende bekræftelse af oprettelse af konto

bekræftelse af oprettelse af konto

5) Du skal udfylde brugeroplysningsskemaet for at behandle videre, hvor du bliver bedt om at vælge en adgangskode. Klik på 'Accepter og opret din konto-knap'

Enig og Opret din konto-knap

6) Du bliver logget ind og omdirigeret til Braintree Admin-portalen

Braintree Admin portal

7) Bemærk Sandbox-tasterne, og brug dem i din applikation til at integrere med denne Braintree-sandkasse.

integrer med denne Braintree sandkasse

8) Når integrationen er udført, er sandkassen klar til brug. Hvis du har brug for at opdatere sandkasseindstillingerne, kan du gøre det ved hjælp af indstillingsmenuen.

indstillingsmenu

Almindeligt anvendte indstillingsmenupunkt:

indstillingsmenu

Konklusion

Betalingsbehandleren er en meget vigtig komponent for enhver e-handelsapplikation, der er designet til at acceptere betalinger fra sine kunder. Derfor er det vigtigt at teste denne komponent grundigt. Ethvert ubesvaret scenario kan påvirke sælgerens salg / transaktioner og negativt påvirke brugeroplevelsen for kunden eller køberen.

Testere er nødt til at forberede eller indstille testmiljøet (sandkasser, indsamle dummy kreditkortoplysninger, svarkoder osv.) Og formulere en teststrategi - både til testmiljøet og live / post-produktionstest.

Omkring forfatter: Denne nyttige artikel er skrevet af Neha. Hun arbejder i øjeblikket som kvalitetssikringschef og har specialiseret sig i at lede og styre interne og offshore QA-teams.

Har du spørgsmål eller vil du dele din oplevelse med Payment Gateway Testing? Giv os besked i kommentarerne nedenfor.

Anbefalet læsning

^