След плащането

След извършване на плащането можете да го управлявате в личния кабинет на портала на продавача или чрез API. Прочетете разделите по-долу, за да научите повече.

Отказ и връщане на плащане

Ако искате да отмените плащане, можете да изпълните една от двете операции, в зависимост от статуса на поръчката: отказ или връщане. Тези операции са описани по-долу.

Отказ

Отказът означава, че транзакцията се отменя и всички средства, резервирани по сметката на клиента, се отблокират. Тази операция може да се прилага към двуетапни транзакции, когато средствата са резервирани, но още не са получени (статус Потвърден). След отказа транзакцията получава статус Отменен.

Достъпни са следните начини за отказ:

• Отказ на плащане в портала на продавача. Осъществява се чрез натискане на бутона Връщане на страницата с детайли на операцията. Този бутон работи както за отказ на плащане, така и за връщане на средства – в зависимост от статуса на транзакцията. Ако това е възможно, се случва отказ на плащане, а ако не, то се осъществява връщане на средства. Подробнее четете тук.
• Отказ на плащане чрез API чрез изпращане на заявка reverse.do.
• Отказ на всички двустадийни плащания автоматично след изтичането на определено време. Ако имате нужда от тази функционалност, обърнете се към службата за поддръжка на банката.

Отказът може да бъде извършен само до края на текущия банков ден.

Връщане на средства

Връщането означава връщане на клиента на вече списаните средства. Тази операция може да се прилага към едностадийни и двустадийни транзакции, когато средствата вече са списани (статус Завършен). Системата позволява връщането на средства повече от един път, но общо не повече от първоначалната сума на завършването.

Възможни са следните начини за оформяне на връщане:

• Връщане на средства в личния кабинет чрез натискане на бутона Връщане в детайлите на транзакцията. Този бутон работи както за отказ на плащане, така и за връщане на средства – в зависимост от статуса на транзакцията. Ако това е възможно, се случва отказ на плащане, а ако не, то се осъществява връщане на средства. Подробнее четете тук.
• Връщане на средства чрез API чрез изпращане на заявка refund.do.

Както отменянето, така и възстановяването на средства могат да бъдат назначени от тригери на callback-уведомления. Повече четете тук.

Получаване на статуса на поръчката

Можете да проверите статуса на поръчката по всяко време. Например, можете да го проверите след плащането, за да се убедите, че поръчката наистина е платена. Статусът на поръчката е достъпен на портала на продавача, а също така може да бъде получен чрез API.

Изясняване на статуса на поръчката на портала на продавача

Статусът на поръчката може да се види на страницата Сведения за транзакцията на съответната транзакция.

Статус Deposited означава успешно плащане.

Изясняване на статуса на поръчката чрез API

За получаване на статуса на поръчката интернет магазинът изпраща към платежния шлюз заявка getOrderStatusExtended.do. Заявката съдържа или orderId (уникален номер на поръчката в платежния шлюз), или orderNumber (уникален номер на поръчката в системата на интернет магазина). Ако в заявката се предават и двата параметъра, приоритетът на orderId е по-висок.

Платежният шлюз връща статуса на поръчката в параметъра orderStatus. Статус 2 означава успешно плащане.

Допълнителни възможности

Двуетапни плащания

Видове плащания

В зависимост от спецификите на бизнеса компанията може да използва два вида плащания:

• Едноетапни - операции за плащане на стоки/услуги, извършвани през Интернет с използване на банкови карти, които не изискват допълнително потвърждение, т.е. блокирането и списването на паричните средства се извършва в един етап. Този вид плащане е за предпочитане, ако стоката или услугата се предоставя веднага след плащането.
• Двуетапни - операции за плащане на стоки/услуги, извършвани през Интернет с използване на банкови карти, изискващи допълнително потвърждение, т.е. плащането се извършва в два етапа. На първия етап се извършва проверка на наличието и блокиране (резервиране) на средствата на платеца (предавторизация); след това на втория етап компанията или потвърждава списването на средствата, или отменя блокирането на средствата.

Сумата на завършването може да бъде по-малка от сумата на задържането. Също така има възможност да се правят завършвания на сума, превишаваща размера на задържането (в рамките на настройваемите лимити). Ако искате да използвате тази функционалност, свържете се с нашата служба за поддръжка.

Двуетапните плащания следва да се използват, ако между вземането на решение за плащане от купувача и доставката на избраната стока или услуга минава известно време.

За да бъде плащането двуетапно, поръчката трябва да бъде регистрирана чрез заявка registerPreAuth.do, а не register.do.

Двуетапното плащане е възможно при всеки начин на интеграция:

• Плащане по връзка
• [Интеграция чрез пренасочване] (/integration/structure/redirect-integration.html#redirect-integration)
• Директни плащания
• CMS
• SDK

За вариантите на директна интеграция, интеграция чрез пренасочване, CMS, SDK е възможна регистрация и оформяне на поръчка чрез API.

Завършвания

Завършването се извършва на втория етап от двуетапното плащане, когато предварително резервираните средства се списват от сметката на притежателя на картата. Веднага щом се извърши списването, поръчката става завършена и преминава в статус DEPOSITED. Сумата на завършването може да бъде по-голяма или по-малка от сумата на предварителната авторизация. Също така е налично поетапно частично завършване. Ако не предадете сума, ще бъде списана цялата сума.

Има три начина да се направи завършване:

• Завършване на плащане в портала на продавача
• Завършване на плащане чрез API
• Автоматично завършване на всички двуетапни плащания след някакво време

Също така има възможност да се направи частично завършване. В този случай поръчката ще бъде завършена на по-малка сума (от сумата на авторизацията).

Завършване и отменяне на поръчки автоматично

Ако нашата служба за поддръжка е включила тази функция за вас, можете да конфигурирате своята интеграция така, че всички предварително оторизирани (в статус Потвърден) двуетапни поръчки да бъдат завършени или отменени автоматично след изтичане на определен период от време. В този случай не е необходимо да обработвате всяка поръчка ръчно в личния кабинет. Също така няма необходимост да извиквате API-методите deposit.do и/или reverse.do.

За да включите автозавършването на поръчка в личния кабинет:

1. Извършете вход в личния кабинет.
2. В контролния панел отляво отидете в раздел Настройки. .
3. Отидете на таб Общи.
4. В раздел Автозавършване, отбележете Автозавършване включено.
5. В полето Срок за завършване (в часове) въведете броя часове след регистрацията, след които двуетапната поръчка трябва да бъде завършена автоматично.

Можете също така да включите автоотмяна на поръчки. При това всички предаторизирани (в статус Потвърден) двуетапни поръчки ще бъдат автоматично отменяни след изтичане на зададения период от време. Отмяната означава, че транзакцията се отменя и всички средства, резервирани по сметката на клиента, се отблокират.

Можете да зададете дата и час за автозавършване и автоотмяна по API с помощта на параметрите autocompletionDate и autoReverseDate в API-заявките registerPreAuth.do и instantPayment.do. Използваният часови пояс: UTC+0.

По-долу се дава описание на логиката на работа на автозавършването и автоотмяната.

Когато поръчка е регистрирана и за нея е установено автозавършване:

• Ако статусът на поръчката остава Създаден в момента на настъпване на времето за автозавършване, с поръчката няма да се случи нищо: в крайна сметка срокът ѝ на действие ще изтече и тя ще бъде затворена. Ако поръчката бъде завършена след изтичане на зададения период, автозавършването няма да се задейства.
• Ако поръчката е предварително оторизирана и не е завършена до изтичане на предварително определения период за завършване, поръчката ще бъде изцяло изпълнена, т.е. предварително оторизираната сума ще бъде автоматично зачислена в пълен обем.
• Ако поръчката е предварително оторизирана и завършена до изтичане на зададения период за завършване, статусът на поръчката ще се промени в съответствие с обичайния ѝ жизнен цикъл.
• Ако до изтичане на зададения период за завършване към поръчката се приложи възвръщане/отмяна, автозавършването няма да се задейства.

Когато поръчка е регистрирана и за нея е установена автоотмяна:

• Ако статусът на поръчката остава Създадена към момента на настъпване на времето за автоматично отменяне, с поръчката няма да се случи нищо: в крайна сметка срокът й ще изтече и тя ще бъде затворена. Ако поръчката бъде завършена след изтичане на зададения период, автоматичното отменяне няма да се задейства.
• Ако поръчката е предварително упълномощена и не е завършена до изтичане на предварително определения период за отменяне, поръчката ще бъде напълно отменена, т.е. предварително упълномощената сума ще бъде автоматично анулирана в пълен обем.
• Ако поръчката е предварително упълномощена и завършена до изтичане на зададения период за отменяне, статусът на поръчката ще се промени в съответствие с обичайния й жизнен цикъл.
• Ако до изтичане на зададения период за отменяне към поръчката се приложи връщане/отменяне, автоматичното отменяне няма да се задейства.

Операции със съхранени платежни данни

Транзакция със съхранени платежни данни се използва, когато притежателят на карта разрешава на продавача да съхранява платежните данни за бъдещи плащания. Например, платецът може да избере запазване на своята карта при оформяне на поръчка. В този случай се създават съхранени платежни данни (CoF, credential on file), уникален защитен токен, генериран от платежния шлюз, който свързва номера на картата на платеца (PAN) с неговия идентификатор в системата на магазина (например, с логина на платеца).

Създаване на съхранени платежни данни

Можете да създадете съхранени платежни данни чрез API или чрез личния кабинет (независимо от типа интеграция). Подробности вижте по-долу.

Създаване на съхранени платежни данни чрез API

За да запазите карта (създадете съхранени платежни данни) в платежния шлюз чрез API, трябва да предадете параметъра clientId в заявката за регистрация на поръчка или инициация на плащане. clientId - това е идентификаторът на вашия клиент (притежател на карта), към този номер ще бъдат свързани всички карти на клиента. За целите на тестването можете да използвате всеки номер като clientId. Този параметър може да се предава в следните заявки:

• register.do
• registerPreauth.do
• instantPayment.do
• /applepay/payment.do
• /google/payment.do

Съхранените платежни данни ще бъдат създадени само след успешно плащане. След плащането ще можете да получите идентификатора на съхранените платежни данни (параметър bindingId) по следните начини:

• чрез заявка за статус на поръчка getOrderStatusExtended.do

• чрез заявка за съхранените платежни данни на клиента getBindings.do

• чрез callback-известяване за създаване на съхранени платежни данни, например:

  https://mybestmerchantreturnurl.com/callback?orderNumber=46046&clientId=9fa029b8-f5d1-4ca7-85e8-317670810cd1&bindingId=7bd483f4-d20d-77eb-b777-2def0169bdc0&mdOrder=7b3491ff-d03d-7305-aa8a-c6470169bdc0&operation=bindingCreated&status=1

  При това параметрите bindingId и clientId трябва да бъдат отделно включени в настройките на callback-известяванията в Платежния шлюз (за включване на тези параметри се свържете с нашата служба за поддръжка).

Създаване на съхранени платежни данни чрез личния кабинет

За създаване на съхранени платежни данни при плащане чрез потребителския интерфейс отидете в личния кабинет, изпратете сметка на електронна поща с указване на параметъра Идентификатор на клиента. Ако укажете този параметър, клиентът ще види отметката Запази моята карта на страницата за плащане. Ако клиентът постави тази отметка, след завършване на плащането ще бъдат създадени съхранени платежни данни, и клиентът няма да се нуждае от въвеждане на данните на картата следващия път. Подробности четете тук.

Принудително създаване на съхранени платежни данни

Ако предадете стойността FORCE_CREATE_BINDING в блока features на платежната заявка, съхранените платежни данни ще бъдат създадени принудително, дори ако клиентът реши да не запазва данните на картата на платежната страница.

Стойността FORCE_CREATE_BINDING не може да се предаде в заявка с съществуващ bindingId или при bindingNotNeeded = true (ще предизвика грешка при проверка). За предаване на тази стойност също се изисква предаване на параметъра clientId.

Ако в блока features са предадени и двете стойности FORCE_CREATE_BINDING и VERIFY, то поръчката ще бъде създадена САМО за създаване на съхранени платежни данни (без плащане).

Провеждане на плащане със съхранени платежни данни

Работа със съхранени платежни данни чрез API

След създаването на съхранени платежни данни можете да работите с тях чрез API (при наличие на разрешение на ниво продавач). Достъпни са следните методи:

• paymentOrderBinding.do – провеждане на плащане със съхранени платежни данни
• getBindings.do – получаване на списък със съхранени платежни данни на клиента
• getBindingsByCardOrId.do – получаване на списък с всички съхранени платежни данни на банкова карта
• unBindCard.do – деактивиране на съществуващи съхранени платежни данни
• bindCard.do – повторно активиране на преди деактивирани съхранени платежни данни
• extendBinding.do — удължаване на срока на действие на съхранените платежни данни.

Използване на съхранени платежни данни в повтарящи се плащания

Можете да използвате съхранени платежни данни за повтарящи се плащания. В този случай параметърът bindingId се използва в обичайната заявка за регистрация на поръчка. Подробности четете тук.

Избор на съхранени платежни данни при плащане

Когато клиентът извършва плащане на платежната страница, му е достъпен избор на едни от запазените съхранени платежни данни за плащане.

Използване на съхранени платежни данни при плащане с портфейли

Можете също така да създавате съхранени платежни данни при плащания чрез портфейлите Apple Pay и Google Pay. За това е необходимо да предадете параметъра clientId в платежната заявка или в заявката за оформяне на поръчка (вж. описанието на API-заявките за портфейли).

В този случай съхранените платежни данни ще свържат номера на токенизираната карта на платеца (DPAN) с неговия ID в системата на магазина (например, с логина на платеца). Такива съхранени платежни данни не могат да се използват за показване на номера на картата на платежната страница (тъй като номерът на картата е токенизиран). Въпреки това тези съхранени платежни данни могат да се използват в повтарящи се плащания.

Създаване на съхранени платежни данни без плащане

При наличие на съответните потребителски права, можете да създадете съхранени платежни данни чрез API без провеждане на плащане. Това може да се направи по следните начини:

• Предайте стойността VERIFY в блока features на всяка платежна заявка заедно с параметъра clientId. В този случай от притежателя на картата няма да се събира никаква сума. Отговорът ще съдържа идентификатора на създадените съхранени платежни данни в параметъра bindingId. Този идентификатор на съхранените платежни данни може да се използва в последващи заявки вместо запазените реквизити на картата. Научете повече за функцията VERIFY тук.
• Използвайте заявката за създаване на съхранени платежни данни без провеждане на плащане createBindingNoPayment.do.

Industry Practice операции

Въведение

Към MIT (Merchant-initiated Transaction) Industry Practice транзакциите, извършвани след инициираща CIT (Cardholder-initiated Transaction) транзакция, се отнасят транзакции от следния вид:

• Incremental Authorization Transaction (увеличаване на сумата)
• Resubmission Transaction (повторно изпращане на транзакция)
• Delayed Charges Transaction (транзакция за отложено плащане)
• Reauthorization Transaction (транзакция за повторна оторизация на плащане)
• No Show Transaction (транзакция за плащане при неявяване)

Настоящият функционал е достъпен при наличие на съответното разрешение. За активирането му се обърнете към службата за техническа поддръжка.

Условия за възможност за извършване на Industry Practice плащания:

1. Разрешението за провеждане на Industry Practice плащания е активирано.
2. Първоначалното плащане е било извършено с използване на 3DS 2.0/2.1/2.2 автентикация с тип frictionless/challenge за Resubmission, Reauthorization транзакции и challenge за Incremental, Delayed charges, No show.
3. Първоначалното плащане представлява едностадийна поръчка в грешни статуси за Resubmission, Reauthorization транзакции, както и в статус Завършен за Incremental, Delayed charges, No show операции.
4. Първоначална поръчка с токенизирано *.Pays плащане.
5. Първоначална CIT транзакция с tii = CI, RI, II, F (подробно за типовете CIT транзакции е описано тук).
6. При Търговеца функционалът за връзки е деактивиран или се използват връзки V2 (използват се такива връзки, като обикновени, рекурентни и разсрочване).

Извършването на Industry Practice плащания е невъзможно за следните типове първоначални операции с:

• 3RI тип.
• MIT тип.
• SSL плащане.
• Двустадийна схема на плащане. Включително единични или множествени завършвания.
• С tii = R, I, U.
• С използване на 3DS 1.0 автентикация.
• С features = VERIFY, където след проверката на картовите данни отсъства финансова оторизация или тя е била отменена.
• В случай че при Търговеца се използват връзки V1.

API-заявка

За плащане на поръчка с признаци на Industry Practice транзакция се използва заявка /industryPractice/paymentOrder.do.

Особености при извършване на плащане

За всеки от видовете Industry Practice плащане са присъщи свои условия за успешно извършване.

Industry Practice Incremental

• Извършването е възможно само в същия бизнес-ден по отношение на първоначалната операция (чиято сума подлежи на увеличаване).
• Изпълнението е възможно от Мърчанти със следните МСС:
  
  • 3351-3500, 7512 Car Rental;
  • 3501-3999, 7011 Lodging;
  • 4111 Local and Suburban Commuter Passenger Transportation, including Ferries;
  • 4112 Passenger Railways;
  • 4121 Taxicabs and Limousines (Card-Absent Environment only);
  • 4131 Bus Lines;
  • 4411 Steamship and Cruise Lines;
  • 5411 Grocery Stores;
  • 5552 Electric Vehicle Charging;
  • 5812 Eating Places and Restaurants;
  • 5813 Drinking Places (Alcoholic Beverages), Bars, Taverns, Cocktail Lounges, Nightclubs and Discotheques;
  • 7033 Trailer Parks and Campgrounds;
  • 7394 Equipment, Tool, Furniture and Appliance Rental;
  • 7513 Truck Rentals;
  • 7519 Motor Home and Recreational Vehicle Rentals;
  • 7523 Parking Lots, Parking Meters and Garages;
  • 7996 Amusement Parks, Carnivals, Circuses, Fortune Tellers;
  • 7999 Recreation Services.
• Количеството изпълнявани Incremental операции не е ограничено.

Industry Practice Resubmission

• В случай на използване на *.Pays или друго токенизирано плащане в изходната операция изпълнението на Resubmission операция е възможно в течение на 14 дни от момента на първоначалната авторизация.
• В случай на използване на обичайно плащане на изходната операция изпълнението на Resubmission операция е възможно в течение на 30 дни от момента на първоначалната авторизация.
• Сумата на Resubmission операцията трябва да съответства напълно на сумата на изходната поръчка.
• Възможно е успешно изпълнение само на една Resubmission операция.

Industry Practice Delayed Charges

• Изпълнението на Delayed Charges операция е възможно в течение на 90 дни от момента на първоначалната авторизация.
• Количеството изпълнявани Delayed Charges операции не е ограничено.

Industry Practice Reauthorization

• В случай на използване на *.Pays или друго токенизирано плащане в изходната операция изпълнението на Reauthorization операция е възможно в течение на 90 дни от момента на първоначалната предавторизация, с изключение на Мърчантите (вж. списъка MCC по-долу), които могат да изпратят повторна авторизация в течение на 120 дни от датата на първоначалната предавторизация:
  
  • 3351–3500 Car Rental Agencies;
  • 3501–3999 Lodging Hotels, Motels, Resorts;
  • 4411 Steamship and Cruise Lines;
  • 4457 Boat Rentals and Leasing;
  • 7011 Hotels, Motels, Resorts, Central Reservations Services (Not Elsewhere Classified);
  • 7033 Trailer Parks and Campgrounds;
  • 7394 Equipment, Tool, Furniture, and Appliance Rental and Leasing;
  • 7512 Car Rental Agencies (Not Elsewhere Classified);
  • 7513 Truck and Utility Trailer Rentals;
  • 7519 Motor Home and Recreational Vehicle Rentals;
  • 7999 Recreation Services (Not Elsewhere Classified).
• В случай на използване на използването на обичайно плащане в хода на изходната операция изпълнението на Reauthorization операция е възможно в течение на 180 дни от момента на първоначалната авторизация.
• Сумата на Reauthorization операцията трябва да съответства напълно на сумата на изходната поръчка.
• Възможно е успешно изпълнение само на една Reauthorization операция.

Industry Practice No Show

• Изпълнението е възможно в течение на една календарна година от момента на първоначалната авторизация.
• Количеството изпълнявани No Show операции не е ограничено.

Изпълнение на отмени и възстановявания

За Industry Practice операция с тип Incremental:

• Сумата на отмяната не може да превишава съвкупната сума на изходната операция и всички свързани с нея Incremental операции.
• Сумата за връщане не може да надвишава съвкупната сума на първоначалната операция и всички свързани с нея Incremental операции.
• В случай, че по-рано по транзакционната верига със свързаните(ата) Inremental плащане(я) вече е била извършена частична отмяна, то сумата на частичното връщане не може да надвишава amount на първоначалното плащане, сумирана с amount на всички свързани с него Inremental операции, и с изваждане на amount на частичните(ата) отмени(я).
• Отмени и връщания за Incremental верига могат да се изпълняват само по първоначалната поръчка. Изпълнението на отмени и връщания за обособените Incremental плащания е забранено.

Изпълнението на отмени и връщания по Industry Practice операции с тип, различен от Incremental, не имат никакви отлики от действащата функционална реализация - изпълняват се отделно в рамките на обособените поръчки.

Верификация на притежателя на карта

Притежателят на карта може да бъде верифициран без таксуване на каквото и да е плащане. За това предайте стойността VERIFY в блока features на всяка заявка за плащане.

Когато се използва функцията VERIFY, платежната карта ще бъде проверена, за да се убедим, че се използва от нейния законен притежател. Ако за картата е достъпен 3-D Secure, то ще бъде извършена верификация 3-D Secure. При това параметърът amount на верифициращата заявка може да бъде равен само на 0. Дори ако някаква сума на плащане бъде предадена в заявката, тя няма да бъде дебитирана от сметката на клиента. След успешна регистрация поръчката веднага се прехвърля в статус REVERSED (отменена).

Ако функцията VERIFY се предава заедно с параметъра clientId, тя може да се използва за създаване на връзка без плащане. Подробно четете в раздела Връзки.

Токен Open ID

Можете да генерирате токен Open ID. Този токен може да се използва вместо потребителските данни за идентификация на търговеца в платежния шлюз.

Токенът Open ID не е частен, може да се публикува или вгради в уеб страница. Например, може да се използва, когато поръчката се оформя директно от браузъра. В този случай няма риск от разкриване на лични данни, тъй като само платежният шлюз може да разшифрова токена.

Можете да използвате токена Open ID за удостоверяване на търговеца при изпращане на API заявки към платежния шлюз. За това предайте токена Open ID в параметъра token вместо предаване на userName и password. Можете да използвате параметъра token в следните заявки:

• register.do
• registerPreAuth.do
• getOrderStatusExtended.do
• instantPayment.do
• verifyCard.do

За да генерирате токен Open ID, отидете в личния кабинет, изберете Настройки в страничното меню, а след това изберете Общи настройки в блока Търговец. Натиснете Генериране до полето Публичен ключ. Ако вече знаете токена си, можете да го въведете ръчно.

Подробно четете тук.

Пренасочване към ACS

Ако се изисква 3-D Secure, то след получаване на отговор на заявката за плащане, клиентът трябва да бъде пренасочен към ACS. Съществуват два начина за пренасочване: обичайно и опростено.

Обичайно пренасочване

Ако плащането се извършва с помощта на 3-D Secure, търговците трябва да пренасочват своите клиенти в ACS по адреса, посочен в параметъра acsUrl, получен в отговора на заявката за плащане. Тялото на заявката трябва да включва MD=mdorder&PaReq=paReq&TermUrl=termUrl, където:

• MD - уникален идентификатор на поръчката в платежния шлюз;
• PaReq - параметър paReq, получен в отговора на заявката за плащане. Това е съобщение, което трябва да бъде изпратено в ACS заедно с пренасочването и съдържа данните, необходими за удостоверяване;
• TermUrl - параметър termUrl, получен в отговора на заявката за плащане. Това е URL-адрес, към който ACS пренасочва притежателя на картата след удостоверяване.

Това трябва да бъде POST заявка (не GET).

В зависимост от конфигурацията, съгласувана с банката, купувачът след удостоверяване в ACS ще бъде пренасочен или в магазина, или към платежния шлюз.

Пример за POST-заявка за обичайно пренасочване:

<html>
<head><title>ACS Redirect</title></head>
<body onload="document.forms['acs'].submit()">
ACS Redirect
<form id="acs" method="post" action="[result.acsUrl]">
    <input type="hidden" id="MD" name="MD" value="[MD]"/>
    <input type="hidden" id="PaReq" name="PaReq" value="[result.PaReq]"/>
    <input type="hidden" id="TermUrl" name="TermUrl" value="[result.TermUrl]"/>
</form>
</body>
</html>

Опростено пренасочване

Също така Интернет-магазинът може да използва метода на шлюза acsRedirect.do, който ще изпълни същото пренасочване на притежателя на картата към ACS на емитента.

Плащане с помощта на собствен MPI/3DS Server

Merchant Plugin Interface (MPI)/3DS Server — това е компонент на технологията 3D Secure, който може да бъде реализиран в платежния шлюз или от ваша страна. Ако имате собствен MPI/3DS Server, можете да го използвате за самостоятелна авторизация 3D Secure, а в API заявките само да указвате факта за провеждане на такава авторизация. За да включите тази функционалност, обърнете се към службата за техническа поддръжка.

Ако използвате собствен MPI/3DS Server, то в платежните заявки (например, paymentOrder, paymentOrderBinding.do , или instantPayment.do) предавайте допълнителни параметри в блок jsonParams: eci, cavv, xid, threeDSProtocolVersion и threeDsType. Тези параметри са описани по-долу.

eci

eci — индикатор на електронната търговия (ECI), получен от вашия сървър 3-D Secure. Показва нивото на сигурност, използвано при плащането. Задава се от DS-сървъра според получените резултати от автентификацията и в съответствие с особеностите на процеса на проверка на магазина. Параметърът се предава в блок jsonParams в двуразряден формат, например, "eci": "02".

Кодовете ECI могат да се различават в зависимост от платежната система. По-долу се привежда разшифровката на най-често използваните ECI-кодове:

cavv, xid

Ако стойността на ECI се различава от тези, които се използват за SSL-авторизация, също е необходимо да предадете следните параметри:

• cavv - стойност на автентификацията на притежателя на картата;

• xid - идентификатор на транзакцията за 3DS-автентификация на собственика на картата на 3DS сървъра (стойност ARes.dsTransID, получена от ACS).

  • Формат xid за 3DS 1: Base64 низ, максимум 28 символа (пример: f7X9N3aB1k8vM2pZqR5wL0xYtK8);
  • Формат xid за 3DS 2: UUID (пример: 8f3d2a71-6c4b-4e92-a15f-3b8c9d0e1f2a).

threeDSProtocolVersion

Освен това можете да предадете в платежната заявка параметър threeDSProtocolVersion (версия на протокол 3DS). Той може да приема следните стойности:

• 2.1.0 - за 3DS 2
• 2.2.0 - за 3DS 2

Ако в заявката не се предава threeDSProtocolVersion, то по подразбиране неговата стойност се приема равна на 2.1.0 - за 3DS 2.

threeDsType

Параметърът threeDsType (тип автентификация на плащането) е необходим за плащане чрез вашия MPI/3DS Server с 3DS 2.

За плащания със SSL този параметър е незадължителен и се определя автоматично в зависимост от стойността на ECI.

Пример за заявка

curl --request POST \\
  --url https://uat.dskbank.bg/payment/rest/paymentorder.do \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data userName=test_user \\
  --data password=test_user_password \\
  --data MDORDER=0140dda0-71ed-7706-a61f-36bd00a7d8c0 \\
  --data '$PAN=4000001111111118' \\
  --data '$CVC=123' \\
  --data YYYY=2030 \\
  --data MM=12 \\
  --data 'TEXT=TEST CARDHOLDER' \\
  --data language=en \\
  --data 'jsonParams={
  "eci": "02",
  "cavv": "AkZO5XQAA0rhBxoaufa+MAABAAA=",
  "xid": "5010857f-8d3f-74e1-9c5a-54a000cc4110",
  "threeDSProtocolVersion": "2.2.0",
  "threeDsType": "5"
}'

Ако използвате собствен MPI/3DS Server, отговорът на съответната API-заявка за плащане не съдържа параметри, свързани с 3D Secure, като redirect, termUrl, acsUrl и paReq.

Пример за отговор

{
  "redirect": "https://uat.dskbank.bg/payment/merchants/temp/finish.html?orderId=01493844-d4d3-703f-9f7e-a73900a7d8c0&lang=en",
  "info": "Your order is proceeded, redirecting...",
  "errorCode": 0
}

Управление на периодични задължения

Платежният gateway позволява настройването на задачи за периодични задължения. Настроените задължения в последствие автоматично се изпълняват в съответствие с зададеното разписание.

Ако тази възможност е включена за вас от нашата група за поддръжка, можете да правите следното:

• Създавате периодични задачи с указване данните на картата и разписанието
• Редактирате периодични задачи
• Прекратявате изпълнението на една или няколко задачи
• Активирате периодични задачи
• Изключвате изпълнението на определено плащане в периодична задача

Можете да управлявате периодични задължения с помощта на API. Подробнее вж. раздел API на периодични задължения.

3-D Secure оторизация

Какво е 3-D Secure

3-D Secure (наричан също 3DS) - технически стандарт, създаден от Visa и MasterCard, който позволява извършването на допълнителна оторизация на притежателя на картата от страна на банката-емитент. За завършване на транзакцията на притежателя на картата се предлага да потвърди самоличността си чрез въвеждане на уникална парола, SMS код или временен PIN код.

Терминът 3DS означава 3 Domain Server. Това название се обяснява с факта, че във всяка 3-D Secure транзакция участват три страни:

1. Домейн на ъкуайъра. Изпълнява ролята на 3DS requestor – инициатор на процеса на оторизация.
2. Домейн на емитента. Включва в себе си ACS (Access Control Server), който осигурява потвърждение на самоличността на платеца от банката-емитент.
3. Домейн на взаимодействието. Изпълнява ролята на свързващо звено между първите два домейна. Обикновено това е платежната система.

Версии на протокола

Платежният шлюз поддържа 3-D Secure оторизация, за да ви защити вас и вашите клиенти от заплахата от платежни измами.

За транзакции в браузъра ние използваме 3-D Secure v2 (наричан също 3DS2) - обновената версия на протокола 3-D Secure, която осигурява по-добро взаимодействие между трите участника в транзакцията. Протоколът за проверка на автентичността 3DSv2 в зависимост от настройките на ACS на банkata-емитент позволява извършване на проверка на автентичността без участието на клиента (схема Frictionless). В този случай от клиента няма да се изисква да извършва действия за автентикация, като въвеждане на еднократна парола или други действия.

Сценарии за интеграция

Ако платежната страница се намира от страна на платежния шлюз, търговецът не се изисква да извършва каквито и да било допълнителни действия и може да използва стандартния API на платежния шлюз.

Ако платежната страница е разположена от страна на търговеца, при използване на автентикация на клиента по протокола 3DSv2 за всяка транзакция търговецът трябва да изпрати редица допълнителни API заявки към платежния шлюз.

Схемите за интеграция са описани тук.

3RI оторизация

3RI – това е тип оторизация 3DS 2, която се инициира от продавача без заявка за потвърждение на плащането от притежателя на картата. Фактически, 3RI плащането - това е MIT плащане с tii=R или tii=I, т.е. рекурентно плащане или плащане на вноски (вж. Връзки и типове транзакции) с 3DS 2 frictionless оторизация.

3RI рекурентно плащане или плащане на вноски е възможно само в случай, когато инициращата транзакция, при която се запазва връзката, е била изпълнена с оторизация 3DS 2.

Ако се изпълнява някое от условията:

• инициращата транзакция се извършваше не чрез платежния шлюз,
• инициращата транзакция се извършваше със собствен MPI/3DS Server,
• инициращата транзакция се извършваше без запазване на връзката,

то е необходимо в блока jsonParams да се изпратят следните допълнителни параметри: