General Introduction
Payment Gateway overview
“Elecsnet Payment Gateway” (here and hereafter System, Payment Gateway or Elecsnet) 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:
API available on the Internet
POS-terminals
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:
Merchant |
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. |
Note
See all terms definitions in Glossary.
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.
Elecsnet 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 Elecsnet. 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:
Endpoint IDs per currency or Endpoint Group IDs for multicurrency integration (see reference schema below).
Merchant login.
Merchant control key.
Integration scenario documentation.
Connecting Party integration example
Sale Form - integrate hosted payment form processing of E-commerce sale transactions.
Return transactions - integrate processing of refunds.
Connecting Party callbacks - receive transaction data to CRM, BI and other systems.
Forms customization - brand hosted payment forms and provide them to Elecsnet support manager for installation.
Test the solution on sandbox with Elecsnet test scenarios.
Inform Elecsnet 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. Elecsnet 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 - Sale is a type of transaction, in which Payer receives goods or services from Connecting Party in exchange for money or other assets. Sale combines the pre-authorization and capture process in one transaction (final authorization). Credit card associations require that Connecting Party submits a sale transaction request only when the order is fulfilled immediately. For example, when selling an item over the counter in a retail store.
preauth - Preauthorization (also preauth) is a transaction type in which bank blocks the specified amount in the Payer’s card account and does not allow the cardholder to use this blocked money. The block remains for a definite period of time. The Preauth transaction is requested when the Payer makes a purchase. Successful Preauth confirms the cardholder’s ability to pay, ensuring that the Payer’s credit card account is in good standing with sufficient funds to complete the purchase with capture request later.
cancel - Unlocks the funds blocked by Preauth transaction.
capture - After providing a service/product to the Payer, Connecting Party uses the existing pre-authorization and submits a capture request to initiate a transfer of previously held funds between the Payer’s credit card account and Connecting Party checking account.
reversal - Returns the specified amount to the cardholder’s account.
void - A credit card purchase that a seller cancels after it has been authorized but before it has been settled.
Dispute management:
fraud - Marks fraudulent transaction.
retrieval - The card issuer asks the merchant for a copy of the actual ticket of a transaction.
chargeback - A chargeback occurs when a cardholder contacts their credit card issuing bank to initiate a refund for a purchase made on their credit card.
chargeback_reversal - When applicable, the acquirer may process a second presentment for a chargebacked transaction.
prearbitration - The issuer may initiate an arbitration chargeback after the second presentment (2nd chargeback).
arbitration - If the acquirer does not accept financial responsibility for the Prearbitration transaction, he may pursue Arbitration (2nd chargeback reversal).
Service transactions: