Введение

Payment Gateway overview

“ConnPay Payment Gateway” (here and hereafter System, Payment Gateway or ConnPay) is a PCI DSS certified platform, which provides accepting, processing, storage and transmitting of payment data between participants of payment processes.

Main participants:

Payers or Receivers

end customers of merchants.

Connecting Party

merchants themselves, PSP/Payment institutions which represent merchants, or third-party systems for data exchange (CRM, BI, monitoring).

Processors

integrated external payment institutions and payment providers.
Payment Gateway provides the following methods of accepting payment data:

  1. API available on the Internet

  2. POS-terminals

  3. Virtual terminal for manual entry of payment data, received by e-mail and phone

Payment Gateway provides access to user accounts. It has the following user roles. Each root entity, can have its own Employees who can get access to the data from the root entity, but with certain restrictions:

Мануал Торговца

provided to the merchant’s representatives (Connecting Party).

Reseller

provided to the agent, which engage merchants for Payment Gateway.

Manager

provided to the representatives of Payment Gateway.

Примечание

Все определения терминов содержатся в Глоссарии;

Connecting Party integration scenario

Depending on the PCI compliance and business requirements, Connecting party integrates to Payment Gateway via Server-to-Server APIs, Hosted payment form APIs or a combination of them. Each integration option is provided in API Use-Cases section, and each API Use-Case provides clear instructions which API commands to call on each stage of the payment flow and how to handle their results. All APIs are asynchronous. Common utilities section provides added value services which might be enabled by request. FAQ page helps to resolve common issues during Connecting Party integration.

ConnPay support manager configures Projects with connected Endpoints and Endpoint Groups (if needed) for one or multiple merchant accounts of Connecting Party in Payment Gateway. For API integration, Connecting party receives the following data from ConnPay. This data can be provided independently for sandbox (test) and production environment. Any additional required credentials are mentioned in relevant API Use-Cases.

Main required credentials are:

  1. Endpoint IDs per currency or Endpoint Group IDs for multicurrency integration (see reference schema below).

  2. Мануал Торговца

  3. Мануал Торговца

  4. Integration scenario documentation.

title Options for multi-currency processing integration package "Integration to Endpoint Group" { class "layoutHelper1" #ffe6cc;line:black;line.dotted class "Project\n currency A" #dae8fc;line:black;line.dotted class "Project\n currency B" #dae8fc;line:black;line.dotted class "Endpoint\n currency A" #ffe6cc;line:black;line.dotted class "Endpoint\n currency B" #ffe6cc;line:black;line.dotted class "Endpoint\nGroup" #ffe6cc;line:black;line.dotted } package "Integration to multiple Endpoints" { class "layoutHelper2\n" #ffe6cc;line:black;line.dotted class "Project\n currency C" #dae8fc;line:black;line.dotted class "Project\n currency D" #dae8fc;line:black;line.dotted class "Endpoint\n currency C" #ffe6cc;line:black;line.dotted class "Endpoint\n currency D" #ffe6cc;line:black;line.dotted } class "layoutHelper3" #ffe6cc;line:black;line.dotted class "Connecting Party\n (Мануал Торговца)" #e1d5e7;line:black;line.dotted "Connecting Party\n (Мануал Торговца)" -left-> "Endpoint\nGroup" "Connecting Party\n (Мануал Торговца)" -down-> "layoutHelper3" "Connecting Party\n (Мануал Торговца)" -down-> "Endpoint\n currency C" "Connecting Party\n (Мануал Торговца)" -down-> "Endpoint\n currency D" "Endpoint\nGroup" -down- "Endpoint\n currency A" "Endpoint\nGroup" -down- "Endpoint\n currency B" "Endpoint\n currency C" -down- "Project\n currency C" "Endpoint\n currency D" -down- "Project\n currency D" "Endpoint\n currency A" -down- "Project\n currency A" "Endpoint\n currency B" -down- "Project\n currency B" "Connecting Party\n (Мануал Торговца)" -left[hidden]- "layoutHelper1" "Connecting Party\n (Мануал Торговца)" -right[hidden]- "layoutHelper2\n" "layoutHelper1" -[hidden]- "Endpoint\n currency A" "layoutHelper1" -[hidden]- "Endpoint\n currency B" "layoutHelper2\n" -[hidden]- "Endpoint\n currency C" "layoutHelper2\n" -[hidden]- "Endpoint\n currency D" hide members hide circle hide layoutHelper1 hide layoutHelper2\n hide layoutHelper3

Connecting Party integration example

  1. Sale Form - integrate hosted payment form processing of E-commerce sale transactions.

  2. Return transactions - integrate processing of refunds.

  3. Connecting Party callbacks - receive transaction data to CRM, BI and other systems.

  4. Forms customization - brand hosted payment forms and provide them to ConnPay support manager for installation.

  5. Test the solution on sandbox with ConnPay test scenarios.

  6. Inform ConnPay support manager about successful finish of testing and request production credentials to start processing payments.

Payment Gateway Transaction Types

Transaction is the operation of money transfer between accounts. ConnPay payment solution supports all common types of transactions associated with bank card and alternative payments. Transactions can be initiated via API-commands mentioned in corresponding Use-Cases, Virtual terminal, and other methods.

Payments:

sale - Продажа является типом транзакции, в которой Плательщик получает товары или услуги от Присоединяющейся стороны взамен на денежные средства или другие активы. Продажа объединяет процесс предавторизации и списания в одну транзакцию (полная авторизация). Международные платёжные системы требуют, чтобы запрос на продажу поступал только тогда, когда заказ выполняется немедленно. Например, при продаже товара в розницу в магазине.

preauth - Предавторизация является типом транзакции, в которой банк-эмитент блокирует определенную сумму на карточном счёте Плательщика и не позволяет ему распоряжаться этой суммой некоторое время. Предавторизация осуществляется в момент оформления покупки и подтверждает платежеспособность держателя карты, гарантируя, что счет Клиента обеспечен достаточными средствами для последующего списания и завершения покупки.

cancel - Позволяет разблокировать средства по ранее совершенной предавторизации.

capture - После предоставления услуги/продукта Плательщику, информация из предавторизации представляется в запросе на списание, которое инициирует перевод средств между счетами карты Плательщика и Присоединяющейся стороны.

reversal - Возвращает указанную сумму на счет держателя карты.

void - Покупка с помощью банковской карты, которую Присоединяющаяся сторона отменяет после авторизации, но до финального расчёта (settlement).

transfer - Операция MasterCard MoneySend, Visa Money Transfer, или перевод на карту Получателя.

payout - Выплата является типом транзакции, которая приводит к переводу средств с расчётного счёта Присоединяющейся стороны на банковский счет или цифровой кошелёк Клиента (Получателя). Выплата в большинстве случаев используется для пополнения банковского счета.

Dispute and Service transactions:

fraud - Отмечает мошенническую операцию.

retrieval - Эмитент карты запрашивает у Торговца (Присоединяющейся стороны) дополнительные документы по факту совершения операции.

chargeback - Возвратный платеж происходит, когда держатель карты связывается с банком-эмитентом, чтобы инициировать принудительный возврат за покупку, сделанную с помощью этой карты.

chargeback_reversal - Когда это применимо, Банк-эквайер может подать повторное заявление по совершённой транзакции chargeback.

prearbitration - Эмитент может инициировать арбитражный возвратный платёж после повторного заявления от эквайера (2-й chargeback).

arbitration - Если Банк-эквайер не принимает финансовую ответственность за предварительный арбитраж транзакции, он может запросить арбитраж транзакции (2-й возврат chargeback).