Meny

Payment Gateway Testing: Testarens praktiska guide med checklista

  • Huvud
  • Webbtestning
  • Payment Gateway Testing: Testarens praktiska guide med checklista

payment gateway testing

Prova Vårt Instrument För Att Eliminera Problem

Testerns guide till Payment Gateway Testing:

Vad är betalningsbehandlarna?

Enligt Wikipedia, ”En betalningsbehandlare är ett företag (ofta en tredje part) som utses av en handlare för att hantera transaktioner från olika kanaler som kreditkort och betalkort för handelsförvärvande banker. Betalningsbehandlaren kommer både att kontrollera de mottagna uppgifterna genom att vidarebefordra dem till respektive kortets utfärdande bank eller kortförening för verifiering och även genomföra en serie åtgärder mot bedrägerier mot transaktionen. ”

Några vanliga betalningsportar är Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments etc.

Det finns mycket litteratur tillgänglig online och offline om betalningsportaler och relaterad terminologi.

Guide för testning av betalningsgateway

I denna handledning har jag försökt förenkla en del av den informationen och försökt lägga till mina erfarenheter.

Rekommenderad läsning => Testa investeringsbankansökningar

Under mitt första projekt hade jag ingen aning om hur man korrekt testade a betalningsportal . Jag lärde mig gradvis och arbetade med att framgångsrikt lansera PayPal-, Braintree- och Authorize.net-integrationer med våra e-handelsapplikationer.

Vi kommer att diskutera gemensam terminologi, förstå transaktionsflöde från slut till slut och användbara tips och bästa praxis.

Vad du kommer att lära dig:

Payment Gateway Terminology

Låt oss diskutera några termer som vi kommer att använda i den här artikeln:

betalning-gateway-process 1

1) Handlare - En handlare är en person eller ett företag som säljer produkter eller tjänster. Flipkart, Amazon, eBay är några exempel på köpmän.

2) Kreditkort - Ett plastkort som kan användas för att köpa produkter eller tjänster via ett kreditkonto. Det har ett 16-siffrigt kortnummer, ett utgångsdatum, hologram, magnetremsa, signaturpanel och ett CVV-nummer (Card verification value).

Fram på kreditkort:

Främre kreditkort

Kreditkorts baksida:

Baksidan av kreditkortet

(Källa: about.com)

3) Förvärvande bank - Förvärvande bank är en finansiell institution som underhåller handlarens bankkonto och gör det möjligt för en handlare att acceptera och behandla debet- och / eller kreditkortstransaktioner i sin butik.

4) Utgivande bank - Utgivande bank är den finansiella institution som utfärdar kundens betalkort eller kreditkort. När en kund använder ett kredit- eller bankkort för att göra ett köp, godkänner eller avvisar den utfärdande banken transaktionen baserat på kortinnehavarens konto och skickar den informationen till den förvärvande banken.

Till exempel, transaktionen kommer att avvisas om kortets utgångsdatum är felaktigt, eller om inköpsbeloppet överstiger kortkreditgränsen etc.

5) Transaktion - Slut-till-slut-processen genom vilken säljaren får medel för en transaktion med en kund.

6) Auktorisering - Auktorisering begärs när en kund gör ett köp. Denna auktorisering tillhandahålls av kundens utfärdande bank och bekräftar kortinnehavarens giltighet, betalningsförmåga och närvaro av tillräckliga medel etc. När detta är klart sparas medel och balansen dras från kundens kreditgräns men är inte ändå överförd till handelskontot.

7) Fånga - I den här åtgärden samlar köparen relevant kundbetalningsinformation och skickar en betalnings- / fångstbegäran till processorn. Processorn använder den här informationen för att initiera penningöverföring mellan kundens kortkonto och handelsbankens konto.

Läs också => Testning av bankansökan

Skillnad mellan betalningsgateway och betalningsprocessorer

Det finns mycket litteratur online om det och om betalningsgateway och betalningsprocessor är distinkta moduler med olika funktioner.

Under mina projekt har jag observerat att Payment Processor och Payment gateways används omväxlande utan någon egentlig skillnad. Handlarna hänvisar vanligtvis ”Payment Gateways” som betalningsbehandlare eftersom dessa behandlar alla betalningar.

”Betalningsprocessorerna” betraktar sig själva som Payment Gateways eftersom de fungerar som ett sätt att behandla och slutföra den säkra betalningstransaktionen.

Transaktionsflöde

Följande flödesdiagram sammanfattar hela flödet från det ögonblick som en kund gör en beställning till att beställningen lyckas eller avvisas.

Transaktionsflöde

Om en kund vill avbryta beställningen är följande flödet:

Avbryt beställningen

Skillnaden mellan tomrum och retur beror på om en transaktion fångas upp eller inte.

En oriktig betalning kan ogiltigförklaras, det innebär att de innehavda medlen krediteras tillbaka till kortinnehavarens konto. Om en transaktion redan är avvecklad eller fångad inleds en återbetalning vilket innebär att pengarna tas från handelskontot och krediteras tillbaka till kortinnehavarens konto.

webbplatser för att ladda ner video från youtube

Varför behöver vi testa Payment Gateways?

Om vi ​​skulle handla i en verklig tegelbutik skulle vi betala kontant eller svepa vårt kort (kredit eller debitering) genom maskinen under kassan för att slutföra transaktionen.

Om du använder kredit- eller bankkort, kommer POS ( Test av försäljningsstället ) kommer maskinen att ange om betalningsbehandlingen skulle godkännas eller avvisas.

På samma sätt måste vi ha ett jämförbart system på plats som online godkänner eller inte godkänner en transaktion direkt.

Ur ett kundperspektiv borde onlinebetalningshantering på e-handelswebbplatsen vara sömlös. Kunden klickar på 'Betala nu' -knappen och bör se att betalningen lyckas eller avvisas under de närmaste sekunderna.

Ur e-handelsbutiksperspektivet måste säljaren se till att hela betalningscykeln (att få transaktioner från onlinebutik, fånga och auktorisera, återbetala, annullera) fungerar bra. Om någon av dessa underkomponenter inte fungerar som förväntat kan det vara ett problem för säljaren.

Ur handlarperspektivet tillåter testfasen dem att vänja sig vid det valda betalningsbehandlingsflödet och utvärdera om det valda alternativet faktiskt passar bäst för deras applikation och verksamhet.

Typer av testning krävs

Beroende på valet av betalningsprocessor och produkt- / applikationskravet kan du bli tvungen att utföra följande typer av tester

  • Funktionell testning - Funktionell testning krävs för nyare, mindre etablerade betalningsgateways för att säkerställa att applikationen beter sig som den ska, dvs den hanterar order, beräkningar, skatter etc. exakt hur den ska. För mer etablerade betalningsbehandlare kanske denna typ av testning inte krävs.
  • Integrationstest - Integrationstestning är avgörande när man integrerar med en betalningsgateway. Som testare måste du verifiera att integrationen av din webbplats / webbutik / applikation fungerar bra med de valda betalningsportarna. Som testare måste du verifiera hela transaktionsflödet:
    • Beställa
    • Kontrollera om medel tas emot på handelskontot
    • Kontrollera om transaktionen kan återbetalas eller annulleras
  • Prestandatester - Det är viktigt att testa webbplatsen / webbutiken / applikationen för prestanda. Betalningsprocessorn bör inte misslyckas om flera användare försöker slutföra transaktioner samtidigt.
  • Säkerhetstestning - Under en transaktion kommer en kund att tillhandahålla känslig information som deras kreditkortsnummer, CVV-nummer etc. Det är mycket viktigt att se till att all känslig information överförs efter kryptering och att kanalen är säker.

Hjälpfulla tips

Baserat på min personliga erfarenhet är följande några användbara tips för testare:

# 1) Undersök om det finns en gratis sandlåda-miljö (för test- och utforskningsändamål) för betalningsgatewayen som behöver testas eller implementeras. Att ha en sandlåda tillgänglig är definitivt till hjälp och ger teamet den extra flexibiliteten att anpassa verktyget och testa så djupt som krävs.

#två) Se till att transaktionen testas från början till slut. I våra projekt testade och rapporterade vi många buggar relaterade till datafångst och dataflöde från applikation till Payment Gateway. Några av de specifika buggarna var:

  • Information om kund (köpare) fångades inte korrekt
  • Kundens kreditkorts utgångsdatum hämtades felaktigt på grund av en felaktig funktion som orsakade att transaktionerna avvisades av den utfärdande banken på grund av felaktig kreditkortsinformation.
  • Dubblettransaktion som visas i betalningsprocessorn

# 3) Undersök begränsningarna för betalning gateway sandlådor.

Till exempel, Authorize.net sandlåda stöder en valuta per sandlåda, så om du behöver testa flera valutor måste du konfigurera olika sandlådor. Med det skulle du aldrig kunna 'verkligen' testa hur systemet kommer att bete sig när Live Authorize.net-kontot kommer att behandla transaktioner med flera valutor.

# 4) Om betalningen misslyckas under en transaktion av någon anledning bör ett lämpligt meddelande visas till kunden. Alla felmeddelanden som är för tekniska som ”Object not set to instance” eller ”404 error” kan förvirra kunden och påverka användarupplevelsen.

Det är också en bra idé att visa ett generiskt meddelande som ”Det verkar finnas något problem i hanteringen av transaktionen, kontakta oss på 1-800-800-8000”.

# 5) I syfte att verifiera efterproduktionsrelease måste klienten (applikationsföretagare) skapa ett live-betalningsprocessorkonto, ställa in sitt sälj-ID etc.

Beroende på vilken betalningsprocessor som valts kan det ta allt från två dagar till några veckor att ställa in kontot. Detta bör meddelas av projektledaren till klienten i förväg med tillräckligt med tid för att ställa in live-kontot innan applikationen och betalningsprocessorn integreras.

Checklista för testgateway och testfall

Liksom alla andra applikationer innebär testning av betalprocessorer korrekt testplanering.

Följande checklista kan vara till hjälp för testare och kan användas som referens:

1) Ställ in betalningsprocessors sandlåda.

är nätverkssäkerhetsnyckeln samma som wifi-lösenordet

två) Samla testkreditnummer som skulle användas för att testa olika kreditkort. Som ett exempel kan sådan information för Braintree betalningsprocessor hittas på Braintree betalningar.

3) Kontrollera applikationens beteende när en transaktion lyckas.

4) Efter en lyckad transaktion verifierar du om betalningsgatewayen återvänder till din applikation för att visa ett slags lyckat transaktions- / bekräftelsemeddelande.

5) Kontrollera att kunden får någon form av transaktionsbekräftelsemeddelande som orderbekräftelsemail etc. om transaktionen lyckas.

6) Kontrollera vad som händer om en betalning misslyckas eller betalningsprocessorn slutar svara - finns det något felmeddelande?

7) Verifiera applikationsbeteendet med webbläsarens popup-blockerare på och av. Detta kan vara till hjälp om några bekräftelsemeddelanden visas i popup-fönstret.

8) Verifiera olika bedrägeribekämpning / säkerhetsinställningar.

Om kundens faktureringsinformation till exempel inte överensstämmer med adressen som ges till den utfärdande banken, kommer varje felaktig matchning att leda till transaktionsnedgång.

9) Verifiera transaktionsposterna i databasen om testaren har åtkomst till applikationsdatabasen.

10) Kontrollera vad som händer när en kundsession löper ut.

elva) Kontrollera konsolen under hela transaktionen och rapportera eventuella konsolfel som observeras.

12) Kontrollera att transaktionen sker på en säker kanal.

Till exempel kan kassasidorna vara HTTPS kontra resten av webbplatsen som är HTTP-sidor.

13) Kontrollera att betalningsprocessorns valuta är korrekt inställd.

Till exempel, om applikationen / webbplatsen är ett kanadensiskt företag / återförsäljare, ska betalningsbehandlaren vara inställd på att acceptera CAD-valuta.

14) Om applikationerna har flera betalningsalternativ som kreditkort och PayPal tillsammans måste båda betalningsalternativen testas individuellt från slut till slut.

femton) Kontrollera att återbetalning eller ogiltigt belopp (från administrationsportalen för betalningsprocessorn) är samma som transaktionsbeloppet. I inget fall bör återbetalnings- / ogiltighetsbeloppet överstiga transaktionsbeloppet.

Läs också => Testar detaljhandelns banksystem

Ställa in Sandbox: Exempel på Braintree-betalningar

1) Navigera till Braintree-webbplats .

två) Klicka på knappen 'Testa sandlådan'.

(Notera:Klicka på valfri bild för en förstorad vy)

Testa sandlådan

3) Du kommer att omdirigeras till webbplatsen Braintree sandbox. Fyll all nödvändig information och registrera dig för sandlådan

registrera dig för sandlådan

4) Du kommer att få ett e-postmeddelande på den e-postadress som anges under registreringen angående bekräftelse på att kontot har skapats

bekräftelse på skapande av konto

5) Du måste fylla i formuläret för användarinformation för att bearbeta vidare där du skulle behöva välja ett lösenord. Klicka på 'Godkänn och skapa ditt konto-knapp'

Godkänn och skapa ditt konto-knapp

6) Du kommer att vara inloggad och omdirigeras till Braintree Admin-portalen

Braintree Admin portal

7) Lägg märke till Sandbox-tangenterna och använd dem i din applikation för att integrera med den här Braintree-sandlådan.

integrera med denna Braintree sandlåda

8) När integrationen är klar är sandlådan redo att användas. Om du behöver uppdatera sandlådans inställningar kan du göra det med inställningsmenyn.

inställningsmenyn

Vanligt använda inställningsmenyalternativ:

inställningsmenyn

Slutsats

Betalningsprocessorn är en mycket viktig komponent för alla e-handelsapplikationer som är utformade för att acceptera betalningar från sina kunder. Därför är det viktigt att testa denna komponent noggrant. Varje missat scenario kan påverka säljarens försäljning / transaktioner och påverka användarupplevelsen för kunden eller köparen negativt.

Testare måste förbereda eller ställa in testmiljön (sandlådor, samla falsk kreditkortsinformation, svarkoder etc.) och formulera en teststrategi - både för testmiljön och live / post-release-testning.

Om författare: Den här användbara artikeln är skriven av Neha. Hon arbetar för närvarande som kvalitetssäkringschef och specialiserat sig på att leda och leda interna och offshore-kvalitetsgrupper.

Har du frågor eller vill dela din erfarenhet av Payment Gateway Testing? Låt oss veta i kommentarerna nedan.

Rekommenderad läsning

^