Testfall för betalningsgateway: Typer och checklista
Thomas Hamilton
⚡ Smart sammanfattning
Testning av betalningsgateways verifierar att varje onlinetransaktion behandlas säkert, korrekt och snabbt. Den här sidan förklarar gatewaytyper, testmetoder, en förberedelsechecklista och tjugoen färdiga testscenarier som kvalitetssäkringsteam tillämpar på live-kassaflöden.
Payment Gateway Testning
Payment Gateway Testning är en testning av Payment Gateway i ett system för onlineköp och transaktioner av användarna. Syftet med testning av betalningsgateway är att säkerställa säkerheten, tillförlitligheten och prestandan för en betalningsgateway genom att kryptera och säkra betalningsinformationen mellan användare och handlare samtidigt som den ger en smidig betalningsupplevelse.
Ett betalningsgateway-system är ett e-handelsapplikationstjänst som godkänner kreditkortsbetalning för onlineköp. Betalningsgateways skyddar kreditkortsuppgifterna genom att kryptera känslig information som kreditkortsnummer, kontoinnehavaruppgifter och så vidare. Denna information överförs säkert mellan kunden och handlaren och vice versa. Moderna betalningsgateways godkänner även säkert betalningar via betalkort, elektroniska banköverföringar, kontantkort, belöningspoäng etc.
Eftersom gatewayen sitter mellan kund, handlare och bank, stoppar ett fel där intäkterna omedelbart.
Gå med i vårt Live Payment Gateway-testprojekt gratis
Typer av betalningsgatewaysystem
Gateways skiljer sig åt i var kunden anger kortuppgifter, som visas nedan.
Hosted Payment Gateway
Hosted betalningsgateway-system dirigerar kunden bort från en e-handelsplats till gatewaylänken under betalningsprocessen. När betalningen är gjord kommer den att föra en kund tillbaka till en e-handelssida. För en sådan typ av betalning behöver du inte ett säljar-ID, ett exempel på en värdbaserad betalningsgateway är PayPal, Noche och WorldPay.
Delad betalningsgateway
I en delad betalningsgateway hänvisas kunden till betalningssidan under behandlingen av betalningen och stannar kvar på e-handelssidan. När betalningsinformationen är ifylld fortsätter betalningsprocessen. Eftersom den inte lämnar e-handelssidan när betalningen behandlas är detta läge enkelt och mer att föredra, ett exempel på en delad betalningsgateway är eWay, Stripe.
Självhostade, API-hostade och mobila plånboksgateways är ytterligare varianter.
Varför testning av betalningsgateways är viktigt
En kassasida är det sista steget mellan en kund och intäkter, så alla fel där kostar pengar i samma ögonblick som de uppstår. Systematisk testning skyddar det steget genom att hitta problem innan kunderna möter dem.
- Skyddar intäkter: En misslyckad eller långsam transaktion gör att kunder överger varukorgen, och övergivna varukorgar kommer sällan tillbaka.
- Bygger förtroende: Maskerade kortfält, krypterad trafik och tydliga bekräftelsemeddelanden försäkrar köpare om att deras pengar hanteras korrekt.
- Förhindrar bedrägeriförluster: Verifiering av CVV-regler, adressverifiering och hastighetskontroller stoppar bedrägliga beställningar innan varorna skickas.
- Håller handlaren i ordning efterlevnaden: Kortsystem kräver stark kundautentisering, och tester är beviset på att dessa kontroller fungerar.
- Minskar supportkostnader: Dubbletter av betalningar, saknade kvitton och fastnade återbetalningar genererar dyra ärenden och återkrav.
- Upptäcker defekter tidigt: Att åtgärda ett integrationsfel i en sandlåda kostar en bråkdel av att åtgärda det efter ett produktionsavbrott.
Dessa fördelar beror på rätt blandning av testtyper, vilket beskrivs nedan.
Testtyper för betalningsdomän
Testning för Payment Gateway bör inkludera
funktions~~POS=TRUNC: Det är åtgärden att testa basfunktionaliteten för betalningsporten. Det är för att verifiera om applikationen beter sig på samma sätt som den ska vara som hantering av beställningar, beräkning, tillägg av moms enligt land mm.
Integration: Testa integrationen med din kreditkortstjänst.
Prestanda: Identifiera olika prestandamått som det högsta möjliga antalet användare som kommer genom gateways under en specifik dag och konverterar dem till samtidiga användare
Säkerhet: Du måste utföra ett djupt säkerhetspass för Payment Gateway.
Lägg till lokaliseringstestning för valuta och språk, kompatibilitetstestning för enheter, och regressionstestning efter varje uppdatering av leverantörens API.
Så här testar du Payment Gateway: Komplett checklista
Innan du börjar testa –
- Samla in korrekta testdata för dummy-kreditkortsnumret för maestro, visum, master etc.
- Samla in information om betalningsgateways, som till exempel Google Plånbok, Paypal eller annat
- Samla in betalningsgatewaydokument med felkoder
- Förstå sessionen och parametrarna som skickas genom applikations- och betalningsgatewayen
- Förstå och testa mängden relaterad information som skickas genom frågesträng eller variabel eller session
- Tillsammans med betalningsgateway-språket kontrollera applikationens språk
- Under de olika inställningarna för betalningsgateway som valutaformat, samlas abonnentdata in.
Dricks: Mappa varje förväntat fel till en dokumenterad leverantörsfelkod, så att ett vagt "betalningen fungerade inte"-fel blir ett reproducerbart ärende.
Hur man konfigurerar en testmiljö för en betalningsgateway
Tillförlitliga resultat börjar med en miljö som beter sig som produktion utan att flytta riktiga pengar. Nästan alla leverantörer levererar en sandlåda som speglar det aktuella API:et men inte reglerar något, och det är i den sandlådan som det mesta av testningen av betalningsgateways hör hemma.
- Begär inloggningsuppgifter för sandbox. Skaffa ett separat handlar-ID, API-nyckel och hemlighet och lagra dem utanför källkodsförrådet.
- Peka applikationen mot sandbox-slutpunkten. Bekräfta från nätverksloggen att ingen begäran når live-gatewayvärden.
- Ladda de officiella testkorten. Varje system publicerar siffror som tvingar fram ett fast resultat: godkännande, avslag, otillräckliga medel, utgånget kort eller blockering av förlorat kort.
- Kopiera aldrig produktionsdata. PCI Security Standards Council Regler förbjuder live-kortinnehavardata i testmiljöer, så maskera varje post.
- Aktivera 3D Secure-testläget. Utlös friktionsfritt flöde och utmaningsflödet så att omdirigerings-, timeout- och avbrytningsvägar utnyttjas.
- Registrera en webhook-mottagare. Betalningsstatus anländer ofta asynkront, så kontrollera att meddelanden om insamling, återbetalning och återkrav uppdaterar orderposten.
- Simulera nätverksfel. Ta bort eller fördröj svar via en proxy och bekräfta att ingen dubblettdebitering visas när kunden försöker igen.
- Återställ tillstånd mellan körningar. Rensa varukorgar, sessioner och lagrade tokens så att en inaktuell session inte maskerar en defekt.
Håll en kort runbook med sandbox-data URLs, testkortsnummer och förväntade svarskoder. Det låter nya testare reproducera vilket scenario som helst omedelbart och fungerar även som revisionsbevis.
Varning: Rikta aldrig en testsvit mot verkliga inloggningsuppgifter. En enstaka lös auktorisering på ett riktigt kort är både en ekonomisk incident och ett regelbrott.
Exempel på testfall för betalningsgateway
Följande är viktiga testscenarier/fall för att kontrollera Payment Gateway
| Sr# | Test Cases |
|---|---|
| 1 | Försök att ändra språket för betalningsgatewayen under betalningsprocessen |
| 2 | Efter framgångsrik betalning, testa alla nödvändiga komponenter, oavsett om de hämtas eller inte |
| 3 | Kontrollera vad som händer om betalningsgatewayen slutar svara under betalningen |
| 4 | Under betalningsprocessen kontrollera vad som händer om sessionen avslutas |
| 5 | Under betalningsprocessen kontrollera vad som händer i backend |
| 6 | Kontrollera vad som händer om betalningsprocessen misslyckas |
| 7 | Kontrollera databasposterna om de lagrar kreditkortsuppgifter eller inte |
| 8 | Under betalningsprocessen kontrollera felsidor och säkerhetssidor |
| 9 | Kontrollera inställningarna för popup-blockerare och se vad som händer om en popup-blockerare är på och av |
| 10 | Mellan betalningsgateway och applikationskontrollbuffertsidor |
| 11 | Kolla på lyckad betalning, en framgångskod skickas till applikationen och en bekräftelsesida visas för användaren |
| 12 | Kontrollera om transaktionen bearbetas omedelbart eller om bearbetningen sker till din bank |
| 13 | Efter framgångsrik transaktion kontrollera om betalningsgatewayen återgår till din applikation |
| 14 | Kontrollera alla format och meddelanden när betalningsprocessen är framgångsrik |
| 15 | Såvida du inte har ett auktoriseringskvitto från betalningsgatewayen ska varan inte skickas |
| 16 | Informera ägaren om alla transaktioner som behandlas via e-post. Kryptera innehållet i posten |
| 17 | Kontrollera beloppsformatet med valutaformat |
| 18 | Kontrollera om vart och ett av betalningsalternativen är valbart |
| 19 | Kontrollera om varje listat betalningsalternativ öppnar respektive betalningsalternativ enligt specifikation |
| 20 | Verifiera om betalningsgatewayen har det önskade betal-/kreditkortsalternativet som standard |
| 21 | Verifiera standardalternativet för rullgardinsmenyn för betalkort visar kortval |
Nästa beslut är vilket av dessa scenarier som förtjänar ett manus.
Manuell vs. automatiserad testning av betalningsgateways
Båda metoderna hör hemma i ett betalningsprogram, och den användbara frågan är vilka fall som passar vilken metod. Manuellt arbete är starkast vid nya integrationer och allt som kräver mänsklig bedömning. Automation förtjänar sin uppehälle på stabila, repetitiva vägar som måste passera vid varje byggnation.
| Aspect | Manuell testning | Automatiserad testning |
|---|---|---|
| Bäst lämpad för | Utforskande kontroller, förstagångsintegrationer, visuell och formulerad granskning | Regressionssviter och rökkontroller vid varje driftsättning |
| Fart | Långsam; en testare kör ett scenario i taget | Snabbt; många scenarier löper parallellt |
| Kostnadsprofil | Låg installationsansträngning, hög återkommande ansträngning | Hög installationsansträngning, låg återkommande ansträngning |
| Typiska verktyg | Verktyg för webbläsarutveckling och sandbox-instrumentpaneler | Selenium, Appium, Postman för API-kontroller |
| Huvudsaklig svaghet | Svårt att skala över många korttyper eller laddningsnivåer | Blind för layout- och användbarhetsproblem |
En praktisk uppdelning är att automatisera de framgångsrika, avvisade och återbetalningsvägarna för varje korttyp, och reservera manuella sessioner för nya gateway-versioner. Driva laddningsprofiler separat med JMeter.
Saker att tänka på innan du köper Gateway-paket
- Om du har köpt en butikping varukorgspaket, ta reda på dess kompatibilitet
- Om butikenping gateway-paketet förfaller, be betalningsgateway-leverantören om en lista över applikationer som stöds
- Gatewayen måste erbjuda adressverifieringssystemskydd
- Ta reda på vilka typer av transaktionsskydd som erbjuds
- Kontrollera vilka typer av betal- eller kreditkort som accepteras av din valda betalningsgateway
- Kontrollera transaktionsavgifterna som tas ut av en betalningsgateway
- Kontrollera om gateways samlar in betalningen direkt på formuläret eller direkt till en annan sida för att slutföra köpet
