Meny

Payment Gateway Testing: Tester's Hands-on Guide with Checklist

payment gateway testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Tester's Guide to Payment Gateway Testing:

Hva er betalingsbehandlerne?

I henhold til Wikipedia, “En betalingsbehandler er et selskap (ofte en tredjepart) som er oppnevnt av en kjøpmann for å håndtere transaksjoner fra forskjellige kanaler som kredittkort og debetkort for kjøpende banker. Betalingsbehandleren vil både sjekke mottatte detaljer ved å videresende dem til det respektive kortets utstedende bank eller kortforening for bekreftelse, og også utføre en rekke svindelbekjempende tiltak mot transaksjonen. '

Noen vanlige betalingsportaler er Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments etc.

Det er mye litteratur tilgjengelig online og offline om betalingsportaler og tilhørende terminologi.

Guide for testing av betalingsgateway

I denne veiledningen har jeg prøvd å forenkle noe av den informasjonen og prøvd å legge til mine erfaringer.

Anbefalt lesing => Testing av investeringsbankapplikasjoner

I løpet av mitt første prosjekt var jeg klar over hvordan jeg skulle teste a betalingsport . Jeg lærte gradvis og jobbet med å lykkes med å implementere PayPal-, Braintree- og Authorize.net-integrasjoner med våre e-handelsapplikasjoner.

Vi vil diskutere vanlig terminologi, forstå transaksjonsflyt til slutt og nyttige tips og beste praksis.

Hva du vil lære:

Payment Gateway Terminology

La oss diskutere noen begreper vi vil bruke i denne artikkelen:

betalings-gateway-prosess 1

1) Kjøpmann - En kjøpmann er en person eller et selskap som selger produkter eller tjenester. Flipkart, Amazon, eBay er noen eksempler på selgere.

2) Kredittkort - Et plastkort som kan brukes til å kjøpe produkter eller tjenester gjennom en kredittkonto. Den har et 16-sifret kortnummer, en utløpsdato, hologram, magnetstripe, signaturpanel og et CVV-nummer (Card verification value).

Forsiden av kredittkortet:

Forsiden av kredittkortet

Baksiden av kredittkortet:

Baksiden av kredittkortet

(Kilde: about.com)

3) Ervervende bank - Acquiring Bank er en finansinstitusjon som vedlikeholder selgerens bankkonto og gjør det mulig for en selger å godta og behandle debet- og / eller kredittkorttransaksjoner i butikken sin.

4) Utstedende bank - Utstedende bank er finansinstitusjonen som utsteder kundens debet- eller kredittkort. Hver gang en kunde bruker et kreditt- eller debetkort for å foreta et kjøp, godkjenner eller avviser den utstedende banken transaksjonen basert på kortinnehaverens konto og sender den informasjonen til den anskaffende banken.

For eksempel, transaksjonen vil bli avvist hvis kortets utløpsdato er feil, eller hvis kjøpesummen er mer enn kortkredittgrensen osv.

5) Transaksjon - End-to-end-prosessen der selgeren mottar midler for en transaksjon med en kunde.

6) Autorisasjon - Det kreves autorisasjon når en kunde foretar et kjøp. Fullmakten er gitt av kundens utstedende bank og bekrefter kortinnehaverens gyldighet, betalingsevne og tilstedeværelse av tilstrekkelige midler osv. Når dette er fullført, holdes pengene tilbake og balansen trekkes fra kundens kredittgrense, men er ikke men overført til kjøpmannskontoen.

7) Fangst - I denne handlingen samler selgeren den relevante kundebetalingsinformasjonen og sender en forlik / fangstforespørsel til prosessoren. Prosessoren bruker denne informasjonen til å starte pengeoverføring mellom kundens kortkonto og selgerbankkontoen.

Les også => Testing av banksøknader

Forskjell mellom betalingsgateway og betalingsbehandlere

Det er mye litteratur tilgjengelig på nettet om det, og om betalingsportalen og betalingsprosessoren er forskjellige moduler med forskjellige funksjoner.

I løpet av prosjektene mine har jeg observert at betalingsbehandler og betalingsportaler brukes om hverandre uten noen egentlig forskjell. Selgerne refererer vanligvis til 'Payment Gateways' som betalingsbehandlere, da disse behandler alle betalingene.

‘Betalingsbehandlerne’ ser på seg selv som betalingsportaler, ettersom de fungerer som et middel til å behandle og fullføre den sikre betalingstransaksjonen.

Transaksjonsflyt

Følgende flytskjema oppsummerer hele flyten fra det øyeblikket en kunde legger inn en ordre til ordren blir vellykket eller avslått.

Transaksjonsflyt

Hvis en kunde ønsker å kansellere bestillingen, er følgende flyt:

kansellere bestillingen

Forskjellen mellom et tomrom og retur avhenger av om en transaksjon blir fanget opp eller ikke.

En ubetalt betaling kan annulleres, det betyr at de beholdte midlene blir kreditert tilbake til kortinnehaverens konto. Hvis en transaksjon allerede er avgjort eller fanget, startes en refusjon, noe som betyr at midlene tas fra selgerkontoen og krediteres tilbake til kortinnehaverens konto.

nettsteder for å laste ned video fra youtube

Hvorfor trenger vi å teste Payment Gateways?

Hvis vi skulle handle i en faktisk murstein- og mørtelbutikk, ville vi betale kontant eller sveipe kortet vårt (kreditt eller debet) gjennom maskinen under kassen for å fullføre transaksjonen.

Hvis du bruker kreditt- eller debetkort, vil POS ( Point of Sale testing ) maskinen vil indikere om betalingsbehandlingen vil bli godkjent eller avslått.

På samme måte må vi under online-transaksjoner ha et sammenlignbart system som godkjenner eller ikke godkjenner en transaksjon umiddelbart.

Fra et kundeperspektiv bør online betalingsbehandling på netthandelsnettstedet være sømløs. Kunden klikker på «Betal nå» -knappen og bør se at betalingen er vellykket eller avvist i løpet av de neste sekundene.

Fra e-handelsbutikkperspektivet, må selgeren sørge for at hele betalingssyklusen (å få transaksjoner fra nettbutikken, fange og autorisere, tilbakebetale, annullere) fungerer bra. Hvis noen av disse underkomponentene ikke fungerer som forventet, kan det være et problem for selgeren.

Fra selgerperspektivet tillater testfasen dem å bli vant til den valgte betalingsprosessorflyten og evaluere om det valgte alternativet faktisk passer best for deres applikasjon og virksomhet.

Typer testing er påkrevd

Avhengig av valget av betalingsprosessoren og produkt- / applikasjonskravet, kan du bli bedt om å utføre følgende typer testing

  • Funksjonell testing - Funksjonstesting er nødvendig for nyere, mindre etablerte betalingsportaler for å sikre at applikasjonen oppfører seg som den skal, dvs. den håndterer ordrer, beregninger, avgifter osv. Nøyaktig slik den skal. For mer etablerte betalingsbehandlere kan det hende at denne typen testing ikke er nødvendig.
  • Integrasjonstesting - Integrasjonstesting er viktig når du integrerer med en betalingsportal. Som tester må du bekrefte at integrasjonen av nettstedet ditt / nettbutikken / applikasjonen fungerer bra med de valgte betalingsportene. Som tester må du verifisere hele transaksjonsflyten:
    • Legg inn bestilling
    • Sjekk om midler mottas på selgerkonto
    • Bekreft om transaksjonen kan refunderes eller annulleres
  • Ytelsestesting - Det er viktig å teste nettstedet / nettbutikken / applikasjonen for ytelse. Betalingsbehandleren skal ikke mislykkes hvis flere brukere prøver å fullføre transaksjoner samtidig.
  • Sikkerhetstesting - I løpet av en transaksjon vil en kunde levere sensitiv informasjon som kredittkortnummer, CVV-nummer osv. Det er veldig viktig å sikre at all sensitiv informasjon overføres etter kryptering og at kanalen er sikker.

Hjelpsomme tips

Basert på min personlige erfaring er følgende noen nyttige tips for testere:

#1) Undersøk om et gratis sandkassemiljø (for prøve og utforskende formål) er tilgjengelig for Payment Gateway som må testes eller implementeres. Å ha en sandkasse tilgjengelig er definitivt nyttig og gir teamet den ekstra fleksibiliteten til å tilpasse verktøyet og teste så grundig som nødvendig.

#to) Forsikre deg om at transaksjonen blir testet fra slutt til slutt. I prosjektene våre testet og rapporterte vi mange feil relatert til datafangst og dataflyt fra applikasjon til Payment Gateway. Noen av de spesifikke feilene var:

  • Informasjon om kunde (kjøper) ble ikke fanget riktig
  • Kredittkortets utløpsdato ble tatt feil på grunn av en feil funksjon som førte til at transaksjonene ble avvist av den utstedende banken på grunn av feil kredittkortinformasjon.
  • Dupliserte transaksjoner som vises i betalingsbehandler

# 3) Undersøk begrensningene for betalingsgateway-sandkasser.

For eksempel, Authorize.net sandkasse støtter en valuta per sandkasse, så hvis du trenger å teste flere valutaer, må du konfigurere forskjellige sandkasser. Også med det vil du aldri kunne 'virkelig' teste hvordan systemet vil oppføre seg når Live Authorize.net-kontoen vil behandle transaksjoner med flere valutaer.

# 4) Hvis betalingen mislykkes under en transaksjon av en eller annen grunn, bør en passende melding vises til kunden. Enhver feilmelding som er for teknisk som 'Objekt ikke satt til forekomst' eller '404 feil' kan forvirre kunden og påvirke brukeropplevelsen.

Det er også en god ide å vise en generell melding som ‘Det ser ut til å være noe problem i behandlingen av transaksjonen, vennligst kontakt oss på 1-800-800-8000’.

# 5) For å bekrefte verifisering etter produksjon, må klienten (applikasjonsbedriftseier) opprette en live betalingsbehandler-konto, sette opp selger-ID osv.

Avhengig av betalingsprosessoren som er valgt, kan det ta alt fra to dager til noen uker å opprette kontoen. Dette skal kommuniseres av prosjektlederen til klienten på forhånd med tilstrekkelig tid til å sette opp live-kontoen før applikasjonen og betalingsprosessoren integreres.

Sjekkliste for testgateway og testtilfeller

Som alle andre applikasjoner innebærer testing av betalingsprosessorer riktig testplanlegging.

Følgende sjekkliste kan være nyttig for testere og kan brukes som referanse:

1) Sett opp sandkasse for betalingsprosessor.

hvordan du skriver uat test tilfeller

to) Samle tester kredittkortnumre som kan brukes til å teste forskjellige kredittkort. For eksempel kan slik informasjon for Braintree betalingsbehandler bli funnet på Braintree betalinger.

3) Bekreft oppførselen til applikasjonen når en transaksjon er vellykket.

4) Etter vellykket transaksjon, bekreft om betalingsporten returnerer til applikasjonen din for å vise en slags vellykket transaksjons- / bekreftelsesmelding.

5) Bekreft at kunden får en slags varsel om transaksjonsbekreftelse, for eksempel e-postbekreftelse via e-post, hvis transaksjonen er vellykket.

6) Sjekk hva som skjer hvis en betaling mislykkes eller betalingsbehandleren slutter å svare - er det noen feilmelding?

7) Bekreft applikasjonsatferden med popup-blokkering på og av. Dette kan være nyttig hvis noen bekreftelsesmeldinger vises i popup-vinduet.

8) Bekreft forskjellige svindelforebyggende / sikkerhetsinnstillinger.

For eksempel, hvis faktureringsinformasjon fra kunder ikke samsvarer med adressen som ble oppgitt til den utstedende banken, vil enhver uoverensstemmelse føre til at transaksjonen avtar.

9) Bekreft transaksjonsoppføringene i databasen hvis testeren har tilgang til applikasjonsdatabasen.

10) Sjekk hva som skjer når en kundeøkt utløper.

elleve) Kontroller konsollen under hele transaksjonen, og rapporter eventuelle konsollfeil som blir observert.

12) Bekreft at transaksjonen skjer på en sikker kanal.

Kassesidene kan for eksempel være HTTPS versus resten av nettstedet som er HTTP-sider.

1. 3) Kontroller at betalingsprosessorens valuta er riktig konfigurert.

For eksempel, hvis applikasjonen / nettstedet er et kanadisk selskap / forhandler, bør betalingsbehandleren være konfigurert til å akseptere CAD-valuta.

14) Hvis applikasjonene har flere betalingsalternativer som kredittkort og PayPal sammen, må begge betalingsalternativene testes individuelt fra slutt til slutt.

femten) Bekreft at tilbakebetaling eller ugyldig beløp (fra administratorportal for betalingsbehandler) er det samme som transaksjonsbeløpet. I intet tilfelle skal refusjons- / ugyldighetsbeløpet overstige transaksjonsbeløpet.

Les også => Testing av detaljbankbanken

Sette opp sandkasse: Braintree-betalingseksempel

1) Navigere til Hjemmeside for Braintree .

to) Klikk på “Prøv sandkassen” -knappen.

(Merk:Klikk på et hvilket som helst bilde for en forstørret visning)

Prøv sandkassen

3) Du blir omdirigert til nettstedet Braintree sandkasse. Fyll all nødvendig informasjon og registrer deg for sandkassen

registrer deg for sandkassen

4) Du vil motta et e-postvarsel på e-postadressen som ble oppgitt under registreringen angående bekreftelse på oppretting av konto

bekreftelse på oppretting av konto

5) Du må fylle ut brukerinformasjonsskjemaet for å behandle videre der du blir bedt om å velge passord. Klikk på 'Godta og opprett konto-knappen'

Godta og opprett konto-knappen

6) Du blir logget inn og omdirigert til Braintree Admin-portalen

Braintree Admin portal

7) Legg merke til Sandbox-tastene og bruk dem i applikasjonen din til å integrere med denne Braintree-sandkassen.

integrer med denne Braintree sandkassen

8) Etter integrering er sandkassen klar til bruk. Hvis du trenger å oppdatere innstillingene for sandkassen, kan du gjøre det ved hjelp av innstillingsmenyen.

innstillingsmenyen

Vanlig brukte innstillingsmenyalternativ:

innstillingsmenyen

Konklusjon

Betalingsprosessoren er en veldig viktig komponent for alle e-handelsapplikasjoner som er designet for å akseptere betalinger fra sine kunder. Derfor er det viktig å teste denne komponenten grundig. Ethvert savnet scenario kan påvirke selgerens salg / transaksjoner og påvirke brukeropplevelsen for kunden eller kjøperen negativt.

Testere må forberede eller sette opp testmiljøet (sandkasser, samle dummy kredittkortinformasjon, responskoder osv.) Og formulere en teststrategi - både for testmiljøet og live / post-release-utgivelsestesting.

Om forfatter: Denne nyttige artikkelen er skrevet av Neha. Hun jobber for tiden som kvalitetssikringsleder og spesialiserer seg i å lede og administrere interne og offshore QA-team.

Har du spørsmål eller vil du dele opplevelsen din med Payment Gateway Testing? Gi oss beskjed i kommentarene nedenfor.

Anbefalt lesing

^