Getting Started

Introduction

FYST Overview

FYST is an payment gateway solution that provides a full range of processing services compliant with PCI DSS. A more detailed description of the business functions of the system is available on the website https://fyst.com

FYST Users

FYST users are divided into the following groups:

Managers - the companies that provide services for processing online payments to merchants using FYST software platform. It can be banks or brokers who have a contract with the acquiring banks and are ready to take on the financial side of business.
Merchants – the companies that supply goods or provide services to their customers with payment via the Internet. The merchant signs a contract with a Manager for the service of online payments.
A bank-acquirer is another important participant who is not presented as a user in FYST system. Bank-acquirer is responsible for the transactions to transfer funds from bank cards of Merchant’s clients to Manager’s accounts that are opened in this bank for subsequent payments to Merchants.
A Bank-acquirer provides a software interface PGI (Payment Gateway Interface) to receive payments which are used by FYST to carry out transactions in the Bank-acquirer.

FYST Objects

To make payments through the FYST system for a Merchant it is necessary to create and configure the following system objects:

Processor – a software system component that is responsible for interaction with the PGI of a Bank-acquirer. FYST System accepts a Merchant’s incoming transaction and forwards it to the PGI of a Bank-acquirer for the actual charge-off of a credit card customer’s issuing bank account to an account at a Bank-acquirer.
Gateway – Gateway can be represented as a virtual merchant account at a Bank-acquirer. With the help of the Gateway a Manager can control the flow of transactions and their type (3DS/non-3DS), as well as their monthly and total volume. The Gateway uses the processor for the interaction with a Bank-acquirer.
Project – The project brings together Merchants, Resellers, Terminals and Gateways for the solution of any business task in acquiring. Usually a project is created for one Merchant and includes his several Terminals. His transactions are processed by the Gateways that are created only for him and are connected to this very Project.
Processing strategy – The strategy of processing is set at the Project level and defines the rules by which transactions will be distributed to the Gateway.
Endpoint – Merchant uses Endpoint when using API FYST to carry out transactions. Usually Endpoint is created for each Web site of the Merchant. The Endpoint is connected with the project, which binds it with the processing strategy and allows you to split up a transaction arriving at the terminal, according to different gateways.
Merchant’s software uses FYST API for processing transactions of its customers. Merchant provides the client with a user-friendly interface, e.g a shopping cart, to make payments for goods / services. The user initiates the payment through online store dealers, and Merchant’s software makes the appropriate calls to API FYST.

The picture below shows the objects/items of FYST that are necessary for processing Merchants’ transactions.

node Merchant {
    [Merchant Server] -> HTTP
}

node FYST {
    HTTP -> [End Point]
    [End Point] --> [Project]
    [Project] -> [Gate One]: balancing
    [Project] -> [Gate Two]: balancing
    [Gate One] ..> [Processor One]: use
    [Gate Two] ..> [Processor Two]: use
}

 cloud "Payment Service Provider One" {
      [PSP API One]
    }

 cloud "Payment Service Provider Two" {
       [PSP API Two]
     }

     [Processor One] --> [PSP API One]
     [Processor Two] --> [PSP API Two]

Merchant starts the transaction from its Web site to the Endpoint, using the FYST API. The Endpoint accepts the transaction and transmits it to the processing strategy customized for the Project owner. The processing strategy redirects the transaction to any one connected to its gateway. Gateway makes a call to PGI by CPU and leaves transactional records in acquiring banks. Getting a response from the Bank, FYST charges a fee to manager and resellers (if available) according to the configured rate.

See more details in FYST User Manual

EndPoint or EndPointGroup

EndPoint or EndPointGroup is an entry point for incoming Merchant’s transactions and is actually the only FYST object which is exposed via API. Merchant sends HTTPS POST requests to the appropriate URL in order to process transactions

Transactions

Transaction is the operation of money transfers between accounts. FYST payment solution supports all common types of transactions associated with bank card payments.

For example, the merchant initiates a Sale transaction, when a customer has entered card details and clicked on the Pay button in the online store of the Merchant. FYST system registers the incoming transaction and makes the actual payment through bank acquirer. If the client has requested a refund for any reason, a merchant can initiate a Reversal transaction, and the acquiring banks will transfer money back to the client.

Types of Transactions

Transaction Description
sale A sale combines the authorization and capture process in one transaction. Credit card associations require that you submit a sale transaction request only when you fulfill an order immediately. For example, when selling an item over the counter in a retail store. See Sale Transactions
reversal Returns the specified amount to the cardholder’s account. See Return Transactions
preauth You request an authorization when a customer makes a purchase. An authorization, provided by the customer’s card issuing bank, confirms the cardholder’s ability to pay, ensuring that the customer’s credit card account is in good standing with sufficient funds to complete the purchase. See Preauth/Capture Transactions
capture After providing a service/product to the customer, you capture the relevant information from the authorization and submit it in a capture/settlement request that your processor uses to initiate a funds transfer between the customer’s credit card account and your checking account. See Preauth/Capture Transactions
cancel Enables funds blocked by Preauth transaction. See Return Transactions
fraud Marks fraudulent transaction. See MC/VISA/AmEx Fraud Regulation
chargeback A chargeback occurs when a credit cardholder contacts their credit card-issuing bank to initiate a refund for a purchase made on their credit card. See Chargeback flow and transaction types
retrieval The card issuer asks the merchant for a copy of the actual ticket of a transaction. See Chargeback flow and transaction types
void A credit card purchase that a seller cancels after it has been authorized but before it has been settled. See Return Transactions
account_verification Zero Dollar Value Authorization Request (CVV check). See Account Verification
chargeback_reversal When applicable, the acquirer may process a second presentment for a chargebacked transaction. See Chargeback flow and transaction types
prearbitration The issuer may initiate an arbitration chargeback after the second presentment (2nd chargeback). See Chargeback flow and transaction types
arbitration If the acquirer does not accept financial responsibility for the prearbitration Transaction, he may pursue Arbitration (2nd chargeback reversal). See Chargeback flow and transaction types
transfer MasterCard MoneySend or Visa Money Transfer transaction
payout Payout is a type of transaction which results in funds transfer from merchant banking account to customer (receiver) banking account or digital wallet. Payout transaction in most cases is used for bank account funding.