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

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

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

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

Отказ

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

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

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

• Отказ на плащане чрез API чрез изпращане на заявка reverse.do.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Плащане по връзка
  
• Интеграция чрез пренасочване
• Плащания директно
• 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

Връзката ще бъде създадена само след успешно плащане. След плащането ще можете да получите идентификатора на връзката чрез заявка getOrderStatusExtended.do в параметъра bindingId.

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

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

Създаване на връзка без плащане

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

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

  Научете повече за функцията VERIFY тук.

• Използвайте заявка за създаване на връзка без извършване на плащане createBindingNoPayment.do.

Принудително създаване на връзка

Ако предадете стойността 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 в системата на магазина (например с логина на плащащия). Такава връзка не може да се използва за показване на номера на картата на страницата за плащане (тъй като номерът на картата е токенизиран). Обаче тази връзка може да се използва в рекурентни плащания.

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

За да генерирате 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).

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 да се изпратят следните допълнителни параметри: