payment gateway testing
Ръководството на тестера за тестване на шлюз за плащане:
Какви са процесорите за плащане?
Според Уикипедия, „Обработващ плащания е компания (често трета страна), назначена от търговец за обработка на транзакции от различни канали, като кредитни карти и дебитни карти за търговски банки, които придобиват. Процесорът за разплащане както ще провери получените данни, като ги препрати до банката-издател на съответната карта или асоциацията на картата за проверка, както и ще извърши поредица от мерки за борба с измамите срещу транзакцията. '
Някои често срещани платежни шлюзове са Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments и др.
Налице е много литература онлайн и офлайн за шлюзовете за плащания и свързаната с тях терминология.
В този урок се опитах да опростя част от тази информация и се опитах да добавя моя опит.
Препоръчително четене => Тестване на приложения за инвестиционно банкиране
По време на първия си проект не бях наясно как правилно да тествам a вход за плащане . Научих се постепенно и работех по успешно внедряване на интеграции на PayPal, Braintree и Authorize.net с нашите приложения за електронна търговия.
Ще обсъдим обща терминология, ще разберем потока от транзакции до край и полезни съвети и най-добри практики.
Какво ще научите:
- Терминология на платежния шлюз
- Разлика между платежния шлюз и процесорите за плащане
- Поток на транзакциите
- Защо трябва да тестваме Payment Gateways?
- Необходими видове тестване
- Полезни съвети
- Контролен списък за тестване на платежния шлюз и тестови случаи
- Настройване на пясъчник: Пример за плащания с Braintree
- Заключение
- Препоръчително четене
Терминология на платежния шлюз
Нека обсъдим някои термини, които ще използваме в тази статия:
1) Търговец - Търговецът е лице или компания, която продава продукти или услуги. Flipkart, Amazon, eBay са някои примери за търговци.
2) Кредитна карта - Пластмасова карта, която може да се използва за закупуване на продукти или услуги чрез кредитна сметка. Той има 16-цифрен номер на картата, срок на годност, холограма, магнитна лента, панел за подпис и номер за проверка на стойността на картата (CVV).
Отпред на кредитната карта:
Гърб на кредитна карта:
(Източник: about.com)
3) Придобиваща банка - Придобиващата банка е финансова институция, която поддържа банковата сметка на търговеца и дава възможност на търговеца да приема и обработва транзакции с дебитни и / или кредитни карти в техния магазин.
4) Емисионна банка - Емисионната банка е финансовата институция, която издава дебитната или кредитната карта на клиента. Винаги, когато клиент използва кредитна или дебитна карта за извършване на покупка, Издаващата банка или одобрява, или отказва транзакцията въз основа на състоянието на сметката на картодържателя и предава тази информация на Банката придобиваща.
Например, транзакцията ще бъде отхвърлена, ако датата на изтичане на картата е неправилна или ако сумата на покупката е по-голяма от кредитния лимит на картата и т.н.
5) Транзакция - Процес от край до край, чрез който търговецът получава средства за транзакция с клиент.
6) Разрешение - Изисква се разрешение, когато клиентът направи покупка. Това упълномощаване се предоставя от банката издател на клиента и потвърждава валидността на притежателя на картата, възможността за плащане и наличието на достатъчно средства и т.н. След като това приключи, средствата се задържат и остатъкът се приспада от кредитния лимит на клиента, но не се все пак прехвърлени в търговския акаунт.
7) Заснемане - В това действие търговецът събира съответната информация за плащане на клиента и изпраща заявка за сетълмент / улавяне на обработващия. Процесорът използва тази информация, за да инициира прехвърляне на средства между картовата сметка на клиента и търговската банкова сметка.
Прочетете също => Тестване на банкови приложения
Разлика между платежния шлюз и процесорите за плащане
Има много литература на разположение онлайн за това и дали шлюзът за плащане и процесорът за плащане са отделни модули с различни функционалности.
По време на моите проекти забелязах, че процесорът за плащане и платежните шлюзове се използват взаимозаменяемо, без никакво реално разграничение. Търговците обикновено наричат „Payment Gateways“ като платежни процесори, тъй като те обработват всички плащания.
„Обработващите плащания“ се смятат за платежни шлюзове, тъй като действат като средство за обработка и завършване на сигурната платежна транзакция.
Поток на транзакциите
Следващата диаграма на потока обобщава пълния поток от момента, в който клиентът направи поръчка, до поръчката, която е успешна или отхвърлена.
Ако клиент желае да отмени поръчката, потокът е следният:
Разликата между void и return се дължи на това дали транзакцията е уловена или не.
Неуреденото плащане може да бъде отменено, което означава, че задържаните средства се кредитират обратно в сметката на картодържателите. Ако транзакцията вече е уредена или уловена, тогава се инициира възстановяване, което означава, че средствата се взимат от сметката на търговеца и се кредитират обратно в сметката на притежателя на картата.
въпроси за интервю за техническа поддръжка и отговори за bpo
Защо трябва да тестваме Payment Gateways?
Ако трябваше да пазаруваме в действителен магазин за тухли и хоросани, щяхме да платим пари в брой или да прекараме картата си (кредит или дебит) през машината по време на плащане, за да завършим транзакцията.
Ако използвате кредитни или дебитни карти, POS ( Тестване на точка на продажба ) машината ще посочи дали обработката на плащането ще бъде одобрена или отхвърлена.
По същия начин, по време на онлайн транзакции, трябва да имаме сходна система, която незабавно да одобрява или неодобрява транзакция.
От гледна точка на клиента, обработката на онлайн плащания на уебсайта за електронна търговия трябва да бъде безпроблемна. Клиентът щраква върху бутона „Плати сега“ и трябва да види съобщение за успешно или отказано плащане през следващите няколко секунди.
От гледна точка на магазина за електронна търговия, търговецът трябва да гарантира, че пълният цикъл на плащане (получаване на транзакции от онлайн магазин, улавяне и упълномощаване, възстановяване на суми, анулиране) работи нормално. Ако някой от тези подкомпоненти не работи както се очаква, това може да е проблем за търговеца.
От гледна точка на търговеца, фазата на тестване им позволява да свикнат с избрания поток на процесор на плащане и да преценят дали избраната опция всъщност е най-подходяща за тяхното приложение и бизнес.
Необходими видове тестване
В зависимост от избора на процесора за плащане и изискването за продукт / приложение, може да се наложи да извършите следните видове тестване
- Функционално тестване - Необходимо е функционално тестване за по-нови, по-малко установени шлюзове за плащане, за да се гарантира, че приложението се държи както трябва, т.е.обработва поръчки, изчисления, данъци и т.н., точно както се предполага. За по-утвърдени процесори за плащане този вид тестване може да не се изисква.
- Интеграционно тестване - Интеграционното тестване е от решаващо значение при интегрирането с платежен шлюз. Като тестер ще трябва да проверите дали интеграцията на вашия уебсайт / онлайн магазин / приложение работи добре с избраните платежни шлюзове. Като тестер трябва да проверите целия поток на транзакциите:
- Направи поръчка
- Проверете дали средствата са получени в търговска сметка
- Проверете дали транзакцията може да бъде възстановена или анулирана успешно
- Тестване на производителността - От съществено значение е да тествате уебсайта / онлайн магазина / приложението за ефективност. Процесорът за плащане не трябва да се проваля, ако множество потребители се опитват да завършат транзакции едновременно.
- Тестване на сигурността - По време на транзакция клиентът ще предоставя чувствителна информация като номер на кредитната си карта, CVV номер и др. Много е важно да се гарантира, че цялата чувствителна информация се предава след криптиране и че каналът е защитен.
Полезни съвети
Въз основа на моя личен опит, ето няколко полезни съвета за тестери:
# 1) Проучете дали има свободна среда на пясъчника (за пробни и изследователски цели) за платежния шлюз, който трябва да бъде тестван или внедрен. Наличието на пясъчник определено е полезно и дава на екипа тази допълнителна гъвкавост да персонализира инструмента и да тества, както е необходимо, в дълбочина.
# две) Уверете се, че транзакцията е тествана от край до край. В нашите проекти тествахме и съобщавахме за многобройни грешки, свързани със събирането и потока на данни от приложението към шлюза за плащания. Някои от конкретните грешки бяха:
- Информацията за името на клиента (купувача) не се получава правилно
- Датата на изтичане на срока на валидност на кредитната карта се улавя неправилно поради неправилна функция, която води до отказ на транзакциите от банката издател поради грешна информация за кредитната карта.
- Показва се дублирана транзакция в процесора за плащане
# 3) Проучете ограниченията на пясъчниците на платежния шлюз.
Например, Sandhorize.net поддържа една валута за пясъчник, така че ако трябва да тествате множество валути, ще трябва да конфигурирате различни пясъчници. Освен това с това никога не бихте могли да „тествате“ истински как системата ще се държи, когато акаунтът на Live Authorize.net ще обработва транзакции с няколко валути.
# 4) Ако плащането се провали по време на транзакция по някаква причина, на клиента трябва да се покаже подходящо съобщение. Всяко съобщение за грешка, което е твърде техническо като „Обектът не е зададен за екземпляр“ или „Грешка 404“, може да обърка клиента и да повлияе на потребителския опит.
Също така е добра идея да се покаже общо съобщение като „Изглежда, че има някакъв проблем при обработката на транзакцията, моля, свържете се с нас на 1-800-800-8000“.
# 5) За целите на потвърждаването на пускането след производство, клиентът (собственик на бизнес приложение) ще трябва да създаде акаунт за обработка на плащания на живо, да настрои своя търговски идентификатор и т.н.
В зависимост от избрания процесор за плащане, настройването на акаунта може да отнеме от 2 дни до няколко седмици. Това трябва да бъде съобщено от мениджъра на проекта на клиента предварително с достатъчно време, за да се създаде акаунт на живо, преди приложението и интеграцията на процесора на плащане да стартират.
Контролен списък за тестване на платежния шлюз и тестови случаи
Както всяко друго приложение, тестването на процесори за плащане включва правилно планиране на теста.
Следният контролен списък може да бъде полезен за тестерите и може да се използва като справка:
1) Настройте пясъчника на процесора за плащане.
как да добавя към масив
две) Съберете тестови номера на кредитни карти, които ще се използват за тестване на различни кредитни карти. Като пример такава информация за процесора за плащане на Braintree може да бъде намерена в Braintree плащания.
3) Проверете поведението на приложението, когато транзакцията е успешна.
4) След успешна транзакция проверете дали шлюзът за плащане се връща към вашето приложение, за да покаже някакъв вид успешно съобщение за транзакция / потвърждение.
5) Уверете се, че клиентът получава някакво известие за потвърждение на транзакция като имейл за потвърждение на поръчката и др., Ако транзакцията е успешна.
6) Проверете какво се случва, ако плащането е неуспешно или процесорът за плащане спре да реагира - има ли съобщение за грешка?
7) Проверете поведението на приложението с включен и изключен блокиращ прозорец на браузъра. Това може да е полезно, ако в изскачащия прозорец се показват съобщения за потвърждение.
8) Проверете различни настройки за предотвратяване на измами / сигурност.
Например, ако данните за фактуриране на клиенти не съвпадат с адреса, предоставен на банката издател - всяко несъответствие ще доведе до отказ на транзакцията.
9) Проверете записите на транзакциите в базата данни, ако тестерът има достъп до базата данни на приложението.
10) Проверете какво се случва, когато сесията на клиента изтече.
единадесет) Проверете конзолата по време на цялата транзакция и докладвайте за всички конзолни грешки, които се наблюдават.
12) Проверете дали тази транзакция се извършва по защитен канал.
Например страниците за плащане могат да бъдат HTTPS спрямо останалата част от уебсайта, които са HTTP страници.
13) Проверете дали валутата на процесора за плащане е настроена правилно.
Например, ако приложението / уебсайтът е канадска компания / търговец на дребно, платежният процесор трябва да бъде настроен да приема CAD валута.
14) Ако приложенията имат множество опции за плащане като кредитна карта и PayPal заедно, и двете опции за плащане трябва да бъдат тествани индивидуално от край до край.
петнадесет) Уверете се, че сумата за възстановяване или невалидност (от администраторския портал на процесора за плащане) е същата като сумата на транзакцията. В никакъв случай сумата за възстановяване / невалидна сума трябва да надвишава сумата на транзакцията.
Прочетете също => Тестване на системата за банкиране на дребно
Настройване на пясъчник: Пример за плащания с Braintree
1) Отидете до Уебсайт на Braintree .
две) Кликнете върху бутона „Опитайте пясъчника“.
(Забележка:Щракнете върху всяко изображение за увеличен изглед)
3) Ще бъдете пренасочени към уебсайта на пясъчника Braintree. Попълнете цялата необходима информация и се регистрирайте за пясъчника
4) Ще получите известие по имейл на имейл адреса, предоставен по време на регистрацията, относно потвърждение за създаване на акаунт
5) Трябва да попълните формуляра за информация за потребителя, за да обработите по-нататък там, където би трябвало да изберете парола. Кликнете върху „Приемам и създавам вашия акаунт бутон“
6) Ще бъдете влезли в системата и ще бъдете пренасочени към администраторския портал Braintree
7) Обърнете внимание на клавишите на пясъчника и ги използвайте във вашето приложение, за да се интегрирате с тази пясъчник на Braintree.
8) След като интеграцията приключи, пясъчникът е готов за употреба. Ако трябва да актуализирате настройките на пясъчника, можете да го направите, като използвате менюто с настройки.
Често използвана опция от менюто за настройки:
Заключение
Процесорът за плащане е много важен компонент за всяко приложение за електронна търговия, което е предназначено да приема плащания от своите клиенти. Ето защо е от съществено значение да се тества добре този компонент. Всеки пропуснат сценарий може да повлияе на продажбите / транзакциите на продавача и да повлияе негативно на потребителското изживяване за клиента или купувача.
Тестерите трябва да подготвят или настроят тестовата среда (пясъчници, да съберат фиктивна информация за кредитни карти, кодове за отговор и т.н.) и да формулират стратегия за тестване - както за тестовата среда, така и за тестване на живо / след производство.
За автор: Тази полезна статия е написана от Неха. В момента тя работи като мениджър за осигуряване на качеството и е специализирана в ръководенето и управлението на вътрешни и офшорни екипи за осигуряване на качеството.
Имате запитвания или искате да споделите своя опит с тестването на Payment Gateway? Уведомете ни в коментарите по-долу.
Препоръчително четене
- Алфа тестване и бета тестване (Пълно ръководство)
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Функционално тестване срещу нефункционално тестване
- Идеално ръководство за възобновяване на тестване на софтуер (с проба за възобновяване на тестера на софтуер)
- Пълно ръководство за тестване за проверка на компилация (BVT тестване)
- Ръководство за начинаещи за тестване на SalesForce
- Изтегляне на eBook за тестване на Primer
- 68 основни ресурси, за да бъдете успешен тестер (не пропускайте!)